Re: [Gnumed-devel] Comments on a running 0.1 version

[Karsten Hilbert]

On Wed, Aug 31, 2005 at 07:21:09PM +1000, Richard wrote:

> Add Patient
> =======
> **********************************************
> *major problems with focus of gui elements exist*
> **********************************************
> -see specific comments below however
> -THE FINISH BUTTON HAS BEEN GIVEN FOCUS AT BOOTUP OF THIS DIALOG, AND 
> MAINTAINS IN FOCUS TO RECEIVE THE <ENTER> KEYPRESS EVENT
<putting on hearing protectors>

this is default wxPython behaviour

> EVEN WHEN USER 
> CLICKS ANOTHER ELEMENT SUCH AS A TEXT BOX!!!
> -TABBING OFF LISTS  DOES NOT 'GIVE FOCUS' TO THE NEXT LOGICAL GUI ELEMENT, 
> THE 
> <ENTER> FOCUS EVENT IS STILL LURKING WITH THE FINISH BUTTON.
why of course, see above

> As there is no 
> flashing cursor in the next text box to alert the user he must stop, think, 
> pick up the mouse and re-focus OR hit the tab key again.
I find this annoying, too. However, it's default wxPython.
Feel free to change it.

> IE you must 
> programmatically ensure that when a list is selected the cursor is placed on 
> the next logical gui-element.
This is one way of doing it. However, some human computer
interface people argue against it. They argue that moving to
the next input field should be a deliberate and consistent
act no matter what was done in the input field. The reason
being that this way one can be absolutely sure of input
focus position on BLIND data entry (eg not looking at the
screen - which I tend to do often - I listen to/look at the
patient while typing the history).

> ****************************************
> *major problems with data validation exist*
> ****************************************
> In general what comes up in the pop up lists is not easily transferable to 
> the 
> text box without triggering the enter key. So when 'male' pops up, and the 
> user tabs to the next box, however you are doing the underlying validation 
> does not match up 'male' as being 'male', and so on down through the various 
> popup lists. Sample of this type of error message when attempting to update 
> the datbase follow (exuse the junk in other fields, I was just seeing what it 
> allowed) - though the 'gender' says None, the text box did in fact have 
> 'male' in it.
There definitely is room for improvement here - and room for
lots of help.

> Names:
> =====
> -needs autocapitlise on field start]
please help

> -try this. Type in a surname and hit the <enter key>. Yes the enter key, 
> which 
> is the intuitive keypress to go from field to field  (not the tab, though of 
> course both should work) - up comes the date validation routine!!!!
why of course, hitting enter activates the "default button"
for this widget - which happens to be the "finish" one -
which happens to trigger validation of all fields - which
happens to fail on a "wrong" date

"default button for widget" - this is default wxPython
behaviour - feel free to change it

> Date
> ===
> -the incorrect date lost focus event is erratic in its triggering even on the 
> date field- may go purple, but gives no indication of why 19/01/2004 is not a 
> valid date. How can one configure for non-european date format?
not yet but that will happen sometime, please help to make
it happen faster

> Next type in a proper date - and 
> when the date box loses focus up comes a message saying 'A text object must 
> contain some text - consult the error log' ????? Where is this coming from.
from the validator, should not happen, though

> Sex
> ===
> the drop down combo box isn't high enough to see the entries.
known erratic behaviour of the phrasewheel, I have never yet
been able to find the reason, please help

> If I select the 
> sex by arrowing down and hitting the enter key then the whole dialog decides 
> that I don't want to add anymore of the fields below and adds the patient as 
> a new patient.
> ditto for title
not here

> Title
> ===
> Limited choice, eg Mr doesn't come up and it accepts junk as title of any 
> lengh
Well, it's self-learning, eg it uses what's in the database.
And "Mr." isn't in the database. It is not installed by
default because "Mr" isn't a title in the first place. We
could indeed name the field better, eg. academic_title.

> Country
> ====
> similar problems - if type in austra, and up comes autralia highlighted in 
> the 
> listbox, can't hit enter or tab to accept it without problems.
enter works for me
tab -> TODO

> city
> ===
> Whilst it brings up australian cities, it won't accept australian states.
Of course. Why would you want to put states into the city field ?

> State
> ====
> Interestingly though hitting enter after a simple surname/firstname/dob will 
> let you save the record, having an almost completed record won't
well, you can't put in a half-baked address - either none or
a sufficiently complete one

> - it insists 
> on a state, and when one won't conform to what it wants - it;s no go. IN AU 
> we never use NEW SOUTH WALES ETC, always the abbreviations NSW,
-> TODO

> so fixing that in the database is needed.
No. The SQL code driving the match provider for this
phrasewheel needs enhancement.

> Saving
> ====
> When the save bombs out there is no indication to the user that his data 
> entry 
> was not successful.
It does show error messages on my machine.

> Also once back in the program there seem several screens to be able to modify 
> patient details - I assume this is an anomoly on my local machine.
There is only one plugin - demographics - which logically
groups parts of the patient details into a notebook.

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