gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] overview - drilldown


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] overview - drilldown
Date: Thu, 15 Dec 2011 16:55:18 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Dec 15, 2011 at 01:45:55AM +0000, Jim Busser wrote:

> >> What about double click for opening the plugin, and shift double click for 
> >> edit or vice versa ?
> > 
> > I'll do it the other way round but that's a good idea.
> 
> I may prefer what Sebastian proposed.
> 
> It would associate the more general stimulus (double-clicking) with the 
> more-general response (i.e. opening the relevant area) namely
> - a plug-in if exists, else
> - a list-and-edit-create window assuming that is possible.

OK, I agree with this conceptual distinction.

> We already understand that each overview item may have too
> little space to show all existing items.

Indeed.

> For double-click to
> proceed directly to the edit of an item risks to support a
> user to alter a clinical value without awareness that other
> items in the list exist.

This does not follow from the above. If the above holds true
- not enough space to hold all items - a scrollbar will let
the user know that other items *exist*.

However, the concern is partially true and needs to be taken
into account - some panels may simply not load all the
potential items but rather only a distinct subset (think
latest among vaccinations).

> Do we really want to support someone going directly in to
> change a medication item without first viewing the patient's
> *other* medication items?

I agree that this item type should go to the plugin rather
than the item editor.

Remember that we can decide on the actions per item type, no
need for a global decision.

The current meds area now does this:

        - double-click: go to current medication plugin
        - ctrl-double-click: edit the focussed substance intake item

> Another advantage of
> 
>       double-click opens plugin
> 
> is that this can maybe achieve a consistent outcome without depending on 
> whether the double-click was on a list item, or on white space (which may not 
> alway exist).

Hm, that does sound reasonable as well.

> I would there suggest:
> 
> - double-click
> 
>       opens the plug-in AND (if possible)
>       pre-determines that focus will be set on the item, once it opens
> 
> - shift-double click
> 
>       is less important to support than the double-click
>       may be nice to have, provided the "running blind" caveat is respected 
>       could go unadvertised among praxis users until seasoned praxis 
> clinicians
>               are satisfied with their newer clinicians' knowledge and 
> respect for the caveat

Where I work even the most seasoned clinician uses only a
third of what I do with the software that's installed :-)

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

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