Re: [Gnumed-devel] the id_name debate

[Richard Terry]

I think its time to drop the debate as it is wasting our time and never the 
twain shall meet. 

Regards

Richard

On Fri, 3 Sep 2004 07:31 pm, Karsten Hilbert wrote:
> Richard,
>
> several things I don't understand. Here are my thoughts:
>
> - Bare schemata aren't intended for end users.
> - visual query designers allow more convenient query design
> - the sum of the above doesn't mean schemata now *are* for end
>   users after all
> - it rather means that end users who want to get to the bottom
>   of the datastore need to learn at least a minimum about DBs
> - same for end-user car drivers -- if they want to tune the
>   machine they need to learn about the car -- they can,
>   however, use golden wrenches with digital torque display if
>   they so desire -- this doesn't relieve them of the necessity
>   to know the nut they are applying that torque to
>
> Hence we will design the schema so it makes sense for the
> average DB-person.
>
> The naming of some of the tables could be improved, no doubt.
>
> > They do - see the png attatched - it is the IMHO crappy naming scheme
> > which makes it painfully unclear!
>
> I see no problem whatsoever in the png ?
>
> > Take a look at the notablehead.png (I've wiped out the table headings)
>
> This *is* confusing and unhelpful. However, this is akin to a
> wrench with no gauge imprinted (eg a faulty tool) -- one would
> always have to try and test several on the nut that needs to
> come off -- just like you describe.
>
> > As you are looking at it you've not much clue as to which ID links to
> > which have you (of course not there are not headings), but you would
> > immediately if the primary key was named id_address, id_street etc. You
> > wouldn't need the headings.
>
> Do you want wrenches to be imprinted with "this is a wrench" ?
> What good are broken shreds of a wrench that you find laying
> around somehwere even though you can still read the 10'' gauge
> imprint on one of the pieces ? Are you going to use it ?
>
> > Now, look at the second png with the headings. Of course, you can easily
> > identify which id in which table links to which names external key in
> > which table, BUT- AS YOU ARE DOING THIS NOTICE YOUR EYE MOVEMENTS   - to be
> > able to
>
> Now, *there* you have a point. It requires more eye movement.
> However, this is the fault of the visual query designer. Why
> does it not prepend or append the name of the table to each of
> the field names ?!? (of course that's kind of ugly but goes
> along the same lines of reasoning)
>
> > know which id links to which you have to look up to the top of the table
> > heading and them back down to where you want to link to - This is slow,
> > confusing and a total pain - you wouldnt have to do this if they were
> > properly named.
>
> Single-minded policies for naming are not the proper tool to fix
> the display of (one) (apparently suboptimal) visual query
> designer). Fixing the query designer is. Being explicit
> doesn't mean being verbose.
>
> > This extends to every bit of design/gui design.
>
> True.
>
> > The current gnuMed gui design is a total pain as well
>
> Here you have a much better point ! Since the goal of the GUI
> *is* to make use of information convenient (notice how this is
> precisely the same with visual query designers).
>
> > - because whovever stuck in the tabbed system at the
> > bottom just dosn't realise that.
>
> a) perhaps for that person it is not that much of an
>    unbearable pain ?
> b) perhaps it was a 0.1 compromise ?
>
> > I've always made my designs so one needs as
> > minimal as possible eye movement to get around.
>
> This is exactly why I try to keep you interested. To keep your
> experience in the project.
>
> > This is the same sort of
> > argument I put forth when I modified the login screen some time ago (and
> > it was rejected).
>
> Did I miss your patch ?
>
> Also, I start GnuMed several times per day. The login GUI
> requires of me THREE non-password keypresses:
>
> TAB
> type-password
> TAB
> ENTER
>
> This is certainly sub-optimal but by no means painful.
>
> > Also screen design placements make navigating with a mouse which one
> > often has to do easy or hard. IN the current gnumed - one types in a name
> > at the top, and then has to mouse travel all the way to the bottom of the
> > screen to change tabs, then back to the top etc.
>
> Good point. We could make the tabs appear at the top at a
> moments notice. Or even configurably so.
>
> > Anyway - hope this makes some impression and not necessarily a bad one.
>
> Not a bad one.
>
> Karsten