[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] the id_name debate

From: Richard Terry
Subject: Re: [Gnumed-devel] the id_name debate
Date: Fri, 3 Sep 2004 19:57:09 +1000
User-agent: KMail/1.5.4

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



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
> > 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:
> type-password
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]