Andreas Saeger wrote:
I'd rather see the GUI improved than abandon it as a bad deal and expect the general user to be conversant with SQL (any brand!).
You want to improve a GUI on top of a house of cards? Base is a
Nope. But a good user interface expresses what people need to do, in
ways that make sense to them, and the implementation details are a
completely different issue. The framework in which those are expressed
can be modified in any number of ways, from fairly trivial (add a new
menu item/structure that invokes an existing dialog, which might be a
reasonable response to the original issue here) to replacing a whole
engine (move away from HSQLdb and create fully functional SQL based on
intelligent dialogs with the user). One of my father's favorite
expressions, usually when helping with math homework, was "The picture
works the problem." If you can understand the issue well enough to
present it graphically, you generally can find a way to work out the
solution. People's use of pictures came long before their use of written
language, so GUIs (though they generally depend on written language, but
primarily for presenting available choices for selection) tend to be
more intuitive than code (which is far more abstract, relying on an
understanding of its syntax rules and supplying field names and so on
without prompting). I'm a programmer by training, so I'm certainly not
biased against code - but GUIs provide a helpful (and for many people
necessary) way to create code or trigger its use. I'm sure you've had
the same kinds of problems I have in trying to explain how to code
something to somebody who just doesn't think that way.
development tool. General User works with the forms and reports you
develop. I've seen quite often general users beeing intelligent and
patient enough to get behind the concept of a database, but wasting too
much time filing issues and developing macros (Dinbandhu on this list
and dba.devel, several users on oooforum.org). SQL is not the reason why
people give up using Base. SQL is easy enough. Particulary when seeking
help in a forum or list, SQL is easier to communicate than screenshots.
SQL can be copied and pasted. SQL is the most simple computer language
that helps you to build, maintain and operate *any* database. SQL can do
when the GUI must fail due to nested, conditional, recursive tasks or
when you need to use the database engine.
I think the normal person using one of the common database applications
like Access (whether you consider that person a general user or a
developer of forms and reports) is able to accomplish fairly complex
tasks without having to know SQL -- and correct me if I'm wrong, but
aren't there quite a few divergent implementations of SQL, so that if
you know one you can't necessarily just plug the commands from it into
another one? There's nothing that inherently prohibits a GUI from
creating the SQL commands that you are describing, and allowing that SQL
to be captured for communications.
How far can you get with spreadsheets when you don't know the formula
language? From my experience some people get too far. They start writing
convoluted Basic macros because they do not understand what the
application could do for them. In Base you reach that point very quickly
simply because the application can't do it (calculate a date/time, link
foreign tables, copy a record, set default values in form controls,
filter by listbox, call a form, call a report, customize error messages,
click hyperlinks in fields, ... just to mention a few).
Right, it's just that I don't see this as an either/or proposition: GUI
or SQL. It's a both/and. I just don't think it's desirable to have to
say, "Oh, the Base GUI can't handle that, just write the SQL commands."
In any case, as you've indicated, there is a need for good and readily
accessible documentation. In my experience, the most productive help
information describes how to accomplish specific tasks, including
discussions of why you would choose a particular method when there are
several different ones that might serve but that are not equivalent, for
whatever reason.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
