Alex Thurgood wrote:
Andrew Jensen wrote:
The question really is this : Is it the interface or the
documentation, or a combination of both.
IMHO, what lacks most is the handholding or the learn by example
templates. In other Office Suites, such as FileMaker Pro, Access or
Lotus Approach, the software editors include templates and working
functional mini-DB apps that let you get off the ground very quickly
and then enable you to progress onto greater things. OOo is different
in this respect in that it doesn't include a single functional db app
in its download package. OK, it includes the tables that let you set
up such an app (Invoicing, Personal, Business, Collections, etc), but
once the initial tables are created and the ODB setup done, there is
nothing to show you how to do the magic of gluing all of the
components together, and the references to the documentation are,
well, spartiate and dispersed, at the best.
That is a good point about the documentation, or in this case lack of
examples. It is not that there are none, for there are some around. As
you point out however finding them is a different matter. I can think of
at least 4 example databases that are available on the net for download.
I would suspect threre are more. I can also think of a couple of
tutorial sites that cover some Base functionality.
But here is a problem. Go to your favorite search engine and type in
something like 'MS Access example database'...voila ...you are presented
with more then a few good sites. Try the same thing with 'Base example
database' or 'OOOBase example database', or 'OpenOffice Base
example'...mostly what I find is links to articles comparing OOOBase to
MSA or links to the OpenOffice code snippet page with the word Base in
the description. I suppose this can be chalked up to Base being so new,
but perhaps someone needs to try and find a way to get the stuff that is
available now listed by the search engines?
As for the actual example database files, it seems to me that this is
precisely the kind of thing that could be handled by a separate group,
consisting of the kinds of people that hang out on list servers like
this one... ;-) ... anybody want to volunteer.
So maybe that's the reason why questions like thos of the OP come up
so often here and on the forums. Try telling a newbie that in order to
validate data entry from a drop down combobox control that he has
bound to a table, he has to write a macro to write the corresponding
data into the table using programming objects he'd never even dreamed
of, and then bind that macro to the on_click event of the control.
Most newbies eyes will simply glaze over ;-)
True enough. I have had the experience of trying to help someone with a
task that required the creation of a tiny basic macro ( 2 - 4 lines )
and this sent the user into a tail spin. There are always going to be
those that will shrink from the word macro, but my feeling is that for
most it is as much a prblem with the current UI as the term. This is a
situation that I call 'You had to know you needed it, before you needed
problem'. ( One might look at the responses that I posted up from the
survey questions posted on the forum board to find just this sentiment
from a number of folks there )
A couple of examples:
Drop a button onto a form, go to assign the 'When initalizing' event
to...hmm..to what. Well to a sub procedure or function of course. But
that sub procedure or function must already exist. If you have not
created it, you must back out and go create it. Then come back and
assign it. ( The question as to where to create it is for a seperate
thread..) Now, why not allow the user to have a way to open the editor
directly from the spot where you need to assign the sub procedure, have
it stubbed in and when you close the editor the name of the newly
created sub is filled in for you?
Add a list box as a column in a table grid. Open the property editor.
Want to use a query as the list source...oops, needed that query to have
been made already. Oh, you can enter a select statement by hand. But
then if we are focusing on a user that needs the query designer that is
rather self defeating, isn't it? So what now..back out ( actually you
can switch windows, but I bet that focusing on our user again they will
not do that. ) go to the query designer, create a query and then go back
to the form, open the property editor again and select the query. Why
not allow the user to bring up the query designer window from any place
that accepts the name of a query?
Those two examples are failry simple, IMO, but are the types of things
that can make a new user's experience much more trying then needs be.
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
