Re: [Gnumed-devel] GNUmed screen standardization proposal

[Karsten Hilbert]

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