Re: [Gnumed-devel] Waiting list improvements needed

[Karsten Hilbert]

On Thu, Jul 16, 2009 at 11:52:44AM -0700, Jim Busser wrote:

> I am noticing that wxWidgets always sizes the right-most column "hugely" 
> at the expense of crowding the others, perhaps because this column 
> *potentially* hold the most content.

The list columns are auto-sized to their content unless they
do not hold any rows. In that case they are autosized to
their column header. The last column is told to occupy the
remaining space.

> I am wondering whether to display a "trimmed" value (trimmed of blank  
> space) would provide better default sizings among columns?

There is nothing to trim that I know of.

> Or would that hobble the user by refusing them (on edit) access to the full 
> storage 
> which the backend table (column) definition would have otherwise 
> accommodated?

The backend storage capability got nothing to do with the
list column size.

> Do the widgets support column clicking as a determiner of sort order

no

> or are the headings static

no, they are hardcoded in the GUI

> i.e. unlinked to the middleware?

yes

> Can we improve on the current (cvs rc4) GUI labeling inside this plugin?
>
> - in the column names, the "!" seems to me insufficiently informative... 
> all the other columns have words, can we use "Urgency" because this is 
> the same label as is used anyway inside the editing area?

Done.

> - among the buttons, we do not have a consistency in what they relate  
> to... I would have thought that (unless clearly labeled otherwise) the 
> buttons would pertain to the Waiting list items however:
>
> - - the Activate and Activate ± buttons do not activate the waiting list 
> items, they activate the patient

That seems entirely obvious to me. What would it *mean* to
"activate a waiting list item" ?

The tooltips clearly explain what the buttons do.

> - - the Activate ± does not "plus minus",

It is "Activate+", not "+/-". The - only comes about because
the + is the active letter for the button.

"Activate+" meaning "Activate (like Activate) and them some".

"Activate and remove from list" seemed a tad too longish.

> it Activates the patient and -- 
> without confirmation -- "minuses" the waiting list item.

Exactly: "and them some". What "some" means is detailed in
the tooltip. I am all for sensible GUI labelling but I must
say I have little sympathy for people blindly pressing
buttons here and there.

> The user who did not realize this has now *lost* whatever
> was to be done.

I am not sure I follow with the "lost" but for some values
if it - yes - *once*. They'll never forget again.

> What approach could most suitably allow a "removed" item to be re- 
> examined?

A removed item is gone. That's why it got removed. It is
copied to the audit table, however.

> Could the v12 schema

yes

> (or v11 with fixups)

no

> be altered to create a column "Status"? My suggestion would be a default of 
> "NULL" with the 
> ability to store "+1" (1) to denote "completed" and "-1" to denote 
> "removed".

There already are "zone" and "comment".

> - change Activate ± to
>       Activate Person ±
> *and*, when this button is clicked, present to the user the dialog
>       "Activating… also remove this waiting list item?" (Default "Yes")

That would be counterintuitive in the presence of two
Activate buttons.

> NB: can the user still see what it was that they had clicked, in focus, 
> as they would answer the above dialog, in case the user had made an 
> incorrect click?

If the dialog was placed appropriately.

> Also, after Activating a patient, it is annoying that it is the waiting 
> list that may contain the task that needs work *after* patient 
> activation, but the focus has since switched to some different plugin as 
> a consequence of post-search activation settings.

I would have read the task *before* activating+ the patient ?

> 1) can Waiting list patient activation ignore post-search settings  

no

> 2) I can imagine other situations where an office helper or doctor  
> wishes to remain inside the same plugin (which is different than their 
> post-search setting) across multiple different patients. However there is 
> no way in
>       GNUmed > Preferences > User interface > Patient search > Initial plugin
> to "unset" a selection which would be the way I think this could be  
> handled. Wishlist? Difficulty?

That's an idea. Wishlist, yes, medium-complexity I'd say.

> "Remove" button. SInce it does not remove the Person (it removes the  
> waiting list item) it could do with "Remove waiting list item" but I  
> would accept to leave it as it stands, "implied".

Ah, now I see what the inconsistency is that you referred
to. Now, who'd think that "Remove" in a waiting list would
"delete the patient the entry refers to" ? Nonetheless, I
renamed the button to "Delist".

> "Properties" button... too technical, and unclear. This IMO is not the 
> right word, as we are not always "fixing" the item (as implied by the 
> wrench icon) nor necessarily altering the "Properties" since we may only 
> be updating the textual details, while keeping urgency and zone the same. 
> Therefore can we just name this button "Edit"?

Done. Both here and with Remove we'll use the graphics.

> "Up" "Down"... I incorrectly predicted that these would move the focus up 
> or down the list, whereas what they seem to do is to alter the "float 
> level"

List position. That's what the tooltip says.

> of the selected item within the list on some (non-visible) basis, 

Yes, the list position is saved in the backend. It allows
for arbitrary ordering of items.

> even over-riding the "Urgency". If any item were to be moved up using 
> such a tool, with the result that the item newly rests among items with a 
> higher urgency it would seem to me that the urgency should be 
> auto-upgraded, But I do not know what it would mean when as a consequence 
> of these button pushes the item could cross through some zone.

Now the waiting list is an entirely arbitrary tool. People
can, will, and should implement whatever strategy they see
fit with it. GNUmed shouldn't meddle in enforcing arbitrary
policy upon people in that area.


> Also re the Up Down buttons:  any item that was selected, upon being  
> acted on, loses focus, and needs re-acquisition of focus after each  
> button push. Keeping of focus despite the Up, Down, and Edit (and  
> Activate) clicks would be helpful but maybe the wxObject does not  
> support this by virtue of refreshing the display with no option but to 
> lose the focus. But maybe there exists a way to "remember" the item and 
> if it remains in the listing, to re-acquire the focus.

I know, that would be good. That's a todo.

We are getting *waaay* overboard re the "first iteration"
approach here.

> Also can the "Remove" and "Edit" and "Up and "Down" buttons all be made 
> smarter so that if no "Waiting list" item is in focus when clicked, the 
> status area reports
>
>       No waiting list item selected.

See above.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346