[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Comments on a running 0.1 version
From: |
Richard Terry |
Subject: |
[Gnumed-devel] Comments on a running 0.1 version |
Date: |
Wed, 31 Aug 2005 19:21:09 +1000 |
User-agent: |
KMail/1.8.2 |
Ok (sigh) after much angst, de-installing wxpython unicode, recompiling ansi
version, checking postgres tables, checking the python bootup code, the penny
dropped and I read the default .conf file and guess what (Yeah, you knew it
after all) - it was looking for database gnumed_v1 not gnumed (Duh!!!!).
Having spent a couple of hours playing with this, you will not be pleased with
my comments because I've made most of them before, so heap the flak, shit and
flame upon me, so here goes.
I'm also assuming I'm running the correct thing, so here is what I did:
1) Fresh cvs update
2) Created the gnumed_v1 database using sh redo_v1.sh
3) Ran the finished product by sh gm-0.1_from-cvs.sh
4)Logged onto my local machine.
If this is incorrect, then everything below could be not correct!!!!!
So it is running, and some comments in no particular order
bootup
=====
Saying yes or no to the popup box about language settings seems to not alter
its behaviour next time around.
Searching:
=======
- I still find the 'enter name here' tag unnecessary and annoying because
giving focus to that window does not necessarily highlight the text needing
often a doubleclick to highlight it to delete it
-typing in '*' fails to bring up all names, just brings up error message
telling the poor user to consult the error log for gory details. The wildcard
* should work by itself.
- searching for a non-existant name andwhen no results returned it assumes you
want to add a patient and brings up add patient screen. The commonest error I
make in my medical records program is to mis-spell the name I'm after. Don't
really want to have to continually cancel an add patient, how about an option
button on this dialog or a default behaviour.
-If I've added two patients say peter smith and petra smith and type in
'smith' to seach by, doubleclicking on the list searches and brings in the
patient. Clicking the activate button simply drops the dialog off and leaves
only a surname.
-Is the 'addnew' meant to bring up the add new patient dialog?
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 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. 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. IE you must
programmatically ensure that when a list is selected the cursor is placed on
the next logical gui-element.
****************************************
*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.
[ERROR]
(/home/richard/gnumed/gnumed/Gnumed/wxpython/gmDemographicsWidgets.py:address@hidden):
cannot create identity from {'town': u'sydney', 'address_number':
u'dsdffddffddfdffddfdfd', 'title': u'mrdfadfdffdfdfdfdfdfdfdfdfdfdfdf',
'dob': <DateTime object for '2001-01-01 00:00:00.00' at b55e67c8>, 'gender':
None, 'phone': u'', 'nick': u'', 'state': 'NSW', 'street': u'2222dddd',
'firstnames': u'michael', 'country': 'AU', 'lastnames': u'smith', 'zip_code':
u'22222aaaaa', 'occupation': u'
Names:
=====
-needs autocapitlise on field start]
-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!!!!
-if the surname exists eg Smith and I select it then the date validation
routine triggers
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?. It's not
intuitive for use to type 2004-01-19. Various date formats should be
accepted. As one starts typing up comes a small drop down list containing
text like 'second day of'.... if one arrows down to select this, it is not
accepted as a date (why should it anyway). 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.
Sex
===
the drop down combo box isn't high enough to see the entries. 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
Title
===
Limited choice, eg Mr doesn't come up and it accepts junk as title of any
lengh
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.
city
===
Whilst it brings up australian cities, it won't accept australian states.
State
====
Interestingly though hitting enter after a simple surname/firstname/dob will
let you save the record, having an almost completed record won't - 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, so fixing
that in the database is needed.
Saving
====
When the save bombs out there is no indication to the user that his data entry
was not successful.
I could go on and on about this screen, but it is extremely disappointing to
see that something as basic as a data input screen for names and addresses is
so flawed in an initial release.
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.
Tabs at the bottom.
============
PROGRESS NOTES
===========
General: The gui doesn't resize properly, so that it often doesn't have the
save etc buttons showing on the bottom of the screen. the gui-elements do not
visually update properly eg you can add a problem, save it, and it dosn't
appear on the active problem list (mind you I don't know why an urti should
anyone - there should be a mechanism to designate if the added encounter is
an active problem). However if you grab the corner of the window and gently
resize the screen - the urti becomes visible on the adjacent active problem
list.
After saving one patient records having added a progress note, try clicking on
the search patient box (I'll leave aside my long standing strenous objection
to leaving the previous patient's records visible on the screen). After
selecting a patient from the popup list, hey presto - the previous patients
problem list is still visible. - that is until you gently re-size the window
again and they disppear. Also if you load in a new patient his actual problem
list will not replace the last patients visually unless you re-size the
screen.
It is possible to add a new episode title and click save and it appears on the
active problem list without any notes having been entered. However nothing is
listed in either the EMRdump, tree, or journal at all.
I still fail to understand the logic of these progress notes.
If one adds a new episode and saves it and it appears on the active problem
list and then one double clicks on this it adds a new tab. If you add another
episode and it adds it to the active problem list (and say you have put in
hypertension using the phx popup dialog ) and then you double click on one of
the active problem list members the behaviour is different - this time it
pops up a dialog and the description corresponding the hypertension in the
active list is 'past medical history', which rather than hypertension, which
after all would seem to my logic to be the past history item one is trying to
add notes to.
If one has then say made a mistake there is no obvious way to remove the tab,
save clicking the save button.
Anyway, having played with this for some 2 1/2 hours trying various
combinations and permutations, I'm just as confused as usual. though Karsten
will no doubt blast me for what he sees as unconstructive criticism, I find
this whole thing relativley unfunctional and un-intuitive and currently
unusable. This is the end result of lack of functional planning, and not
having an overall management plan, of not allowing a team to function as a
team, and not allowing the various talents of people who have tried
desperately to help gnuMed to talk part. It is no wonder the core developemtn
team is down to a couple of people, because those with interest and talent
such as myself eventually give up. As I've said many times, its is no good
having a robust backend if there is no overall design/function.
It is no good saying put up or shut up. What myself and many others have tried
to give to the group has by and large been ignored. Just because we have no
interest in the nuts and bolts of good code, doesn't mean our contributions
are not equally worthy.
Bring on the usual flak.
Richard
- [Gnumed-devel] Comments on a running 0.1 version,
Richard Terry <=