[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] GNUmed screen standardization proposal
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] GNUmed screen standardization proposal |
Date: |
Wed, 1 Jul 2009 12:16:08 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
That is, while desirable, *endless* hours of work which will
have to be done by someone else.
Any glaring problems will need to be rectified, however.
One of the more worthwhile goals, IMO, is to *reduce* the
number of dialogs by integrating widgets better.
Karsten
On Tue, Jun 30, 2009 at 09:40:39PM -0700, Jim Busser wrote:
> X-Mailer: Apple Mail (2.753.1)
> Subject: [Gnumed-devel] GNUmed screen standardization proposal
>
> I recently made a suggestion that was either overlooked, or maybe having
> to be thought about, on standardizing any of the windows that GNUmed
> would open. Plugins already fully utilize whatever space has been given
> to the client (by the user), so I am talking more about the various
> non-plugin windows which would ideally be larger and better-positioned.
>
> In the case of confirmatory dialogs, it may be sensible to open at the
> centre of the screen and they only need to be large enough to support the
> string and buttons. But even so, it may be good to avoid 10 different
> sizes of dialog boxes and maybe decide on small and medium, or small and
> medium and large. I would prefer some consistency of size and appearance,
> even if some sizes had a bit of empty space in the bottoms.
>
> The other kinds of windows that are evoked are data viewing / entry /
> editing widgets. I think these would be really good to present to the
> user in a consistent way. If we take as an example the list of
> encounters (see screenshot "default")
>
> 1) It presently opens to a width of only maybe 500 pixels. The top
> partly obscures some of the patient name spelling, age and caveat and
> while these are still readable it is distracting. If it is deliberately
> distracting to make obvious to the user it is modal, the screen might
> better be moved down to cover the plugin tabs to remove the temptation to
> click them.
>
> 2) It is too narrow to show enough information to decide which encounter
> to select, at least in some cases.
>
> Now compare screenshot "optimized"...
>
> I would suggest that:
>
> - no confirmatory dialog or data viewing / entry / editing screen by
> default obscure any of what I like to call the "patient banner", meaning
> the "band" that includes the photo and everything to the right of it
>
> - confirmatory dialog screens be considered to follow the other
> suggestions above
>
> - data viewing / entry / editing screens (as per screenshot):
> - - begin tidily just below the photo
> - - use the full width that is being used by the client
> - - extend downward, in the case of "modal" screens, to cover the plugin
> tabs, or if non-modal to allow the tabs to remain clickable
>
> It appears to me that the client can "remember", between sessions (maybe
> not in the case of forced quits) the size that it was last given by the
> user. If I zoom it to full screen size, and exit, my next launch opens
> the client to full screen. If I resize the client to any other size, then
> it will open next time at that size, although it seems to be set to
> always open the client centred on the screen. I tested this by
> repositioning a less-than-full screen-size client to various edges of the
> screen before exiting, and each time the client re-opens centred.
>
> Is wxWidgets able to know the current display resolution, the current
> client size (it seems it must have some ability at this) and the ability
> to open new windows relative to a window that is already open?
>
> Thus far there are perhaps only a dozen data display / entry / viewing
> screens which I would offer as higher-value to improve. I am less pressed
> to ask retooling of existing confirmatory dialogs but maybe any new ones
> could be deployed under the given suggestions, and older ones retooled
> only if they (or nearby code) was being tweaked for other reasons or when
> someone would down the road do minor little cleanups?
>
> The original pngs of the screenshots together were > 200K and rejected by
> the list, accordingly reduced-quality PDFs which I hope still make the
> examples clear:
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346