Hi,
This email is a follow up to the "Where is Base" email from a while
back. There are two main issues that it deals with:
Goals
Requirements
Goals:
Recently on the user list Ariel asked a question regarding "a normal use
for Base", the context of which was dealing with a user trying to
produce a report against a 20,000 record table.
A few weeks or so ago on the documentation mailing list, while
discussing the mid-level Base tutorial, Joe Smith entered this:
Are there any plans to include a section comparing, in practical
terms, which database type to choose for some typical projects?
E.g. if you need a database that's a single file and can be easily
e-mailed to another office, you probably want the embedded engine
(HSQLDB for now).
Or, if you need a database that can be easily edited or massaged en
mass, a spreadsheet might be the best option (if you can live with the
no-update bug).
Or, if you have 500,000 records, to be accessed concurrently by 20
employees, you probably don't want to use csv files.
This is a critical choice that the current UI gives almost no help
with. It then falls to written documentation to explain the concepts
and assist in choosing the right one.
The answer was no by the way as this tutorial will deal strictly with an
embedded database file, Jean Hollis Weber rightfully pointed out that it
should be included in the Base Users Guide and the outline for that will
be updated accordingly.
It strikes me that there is no real way to answer these questions. One
reason being that there is no openly available statement of purpose for
this project. No where have I found a reference to a use case for
different users or uses of the package that clearly says: This is who
the targeted user of an embedded Base file is, and this is the expected
uses they would put it to.
Now I doubt that this is really the case, that there is no idea of what
the goals here are, or as to who the target user(s) are for the Base
module. But I am left to wonder about it quite honestly.
Requirements:
This question has two parts - placing requirements into the context of
the goals of the project, logistics for handling requirements.
I'll start with the second part of that - logistics.
I ran a query against the issue tracker for items marked as
requirements. In looking at these issues one thing becomes apparent IMO,
assigning an issue to requirements appears to be a dead end event, for
all intent and purpose, to the users perspective. There is no one that
then takes ownership of the issue, there seems to be no real attempt to
solicit input from the person requesting the enhancement or feature for
ideas or comments. It just goes off to whoever, at where ever and maybe
at some point it will come back to life. I am sure there are exceptions
to that statement, and perhaps it is just wrong and would be i would be
happy if that is the case.
It may also be that this is the wrong place to raise this and if so I
will do so at QA or UX or where ever is best.
Now for context.
Let me give a simple example.
When Base first shipped there was a default action for date controls,
such that the control automatically set the value to the current date. A
number of people raised this as an issue. So it was fixed. The fix was
to make it so that there was no default value. I was inactive at the
time this happened, but in researching this I don't see any where a
question to anyone about what the best solution was, it was just changed.
Fine right - I say no it was not fine. Here is why. The ability to
override the default behavior was easily done using a couple of lines of
Basic. Indeed the needed lines where available at the code snippet
repository at the OpenOffice.org and almost immediately at the code
snippet repository at OooForum. The problem really was that for class of
user any use of a macro was a hindrance. So now with the fix, if you
actually want the control to default to the current date, something that
is not all that rare, again you need to apply a couple of lines of basic
and assign this to an event on the control. In other words the same
hindrance to to the same class of user still exists, just not as readily
apparent.
I am wondering then how when a request for a change like this comes into
the core group is the decision made for the proper course of action. Is
there some mechanism that says - ok, this is a requirement for a
specific use case of the package, and therefore for this class of user
the solution must not require use of a macro attached to an event (
since that is actually IMO the route problem here). Looked at from this
perspective then the fix is no fix at all. The fix would require a new
option to the control and that of course means a change to the UI and
that has expanding implications. Change to help files, etc etc. Which
all means more work by more people and more sign offs vs a couple of
minutes in a developers editor and a check in.
This then brings the goals and the requirements coming in from the users
together. Only by having a well defined set of user classes and use
cases for those users can you actually decide what appropriate solutions
are to users requests for fixes, enhancements or features, and what
emphasis to give these requests in relation to targets and goals.
Another place this came up recently, IMO, was the request that came in
about some students offering to work on one of the todo list items. In
offering suggestions about the best one for them to work on can anyone
say what particular goal, use case for the package, is met by which of
these todo items and therefore which yields the most return to projects
going forward to meet those goals. ( That is a question regarding
decision making not the suggestions that where actually made to them, so
please don't take that the wrong way. )
Well, again this email is not intended to spawn specific responses to
any examples used but rather to stimulate some thought and perhaps
discussion on how the goals for Base and requirements needed to meet
those goals might be made more open to the user community at large.
Thanks for your time and your consideration of these ideas.
Sincerely
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
