Re: [Gnumed-devel] An Analysis of Demographics - Comments RT

[Karsten Hilbert]

> What we want to see here is a combination of functionality
> and logical screen design
Time and again I have said that I don't believe this is true.

For patient *input* we want a UI that allows the most rapid
data entry possible. The UI in the attached PNG is just too
elaborate for that. Why not make the basic screen this ?

name
dob
address

Each on subsequent "lines".

What you are showing here is a patient demographics *editing*
widget, eg. when you want to change some details about a
patient. I would certainly hate to have to put in new patients
with this widget. But then I also said that it might suffice
for 0.1.

> and I suspect given the differences in country we will need to trade 
> these two off to get a balance.
Second and more screens can be configured to follow the first
basic screen.

> The current solution of the modal popup box doesn't work well for the 
> following reason.
If I understand correctly this is not at all the fault of the
demographics widget. The popup is popped up by the top panel
patient search field.

> biggest single thing I notice about modal windows (not just in 
> gnuMed/wxPython etc) but in many programs - is that they are easily 'lost' 
> amongst the clutter of linux pop up windows.
Hm, that is true.

> in this case - the window is tiny - not an easily recognisable size, and the 
> columns of the grid are all crushed together.
They shouldn't. They aren't, here, either.

> Often when we have multiple names to select from in a popup box, we may need 
> ancillary information to make the selection, which may not be visible in 
> small popup box.
Sure. If someone tells me how to tell the box to resize to the
size of the encapsulated list ... I was unable to learn how to
do that.

> There is an elegant and good looking solution to this within the bounds of 
> our 
> current screen design, namely that (with re-organising the list containing 
> the grid of medicare/dva/whatever numbers) of adding a grid in the remaining 
> area of the screen - below the existing wigits(or above which would be my 
It looks good. Technically it needs thought. The multiple
patients found popup is entirely separate from the
demographics editor. What would you propose to do when some
other widget is on display and multiple patients are found ?

> If those of you doing the backend have done the job properly, changing the 
> gui-around to the above specs shouldn't be that onerous
backend-wise, no worries, the backend doesn't foster for any
one particular UI (or it tries not to make this cardinal
mistake)

> Also I would be keen to here from those of us in different countries about 
> the 
> extent of differences on the clerical side of demographics - ie we have the 
> medicare number, dva number, health entitlement cards.
Let's just say they are totally different ?

> Note in the original 
> QT mockup I included  a tab for clerical as a possible solution to this.
Which I like. This is about the same idea as with the
"subsequent pages" I mentioned above.

> All text boxes should be cleared at start of new patient search;
No, they should be cleared at activation of new patient.

> -self.txt_preferred is not cleared so next patient has same salutation as the 
> -self.cb_preferredname not reset
> self.cb_addressresidence not reset
> self.cb_addresspostal not reset
> Surname               Changing spelling not possible (to database)
> Firstname.    change spelling not possible (to database)
> Title                 Changeing not possible (to database)
> Sex                   changing not possible (to database)
> Street/Suburb display Not sure what happened to this in the iterations, I 
> Suburb                        this field should auto-capitalise
> Postcode                      Allows input of numbers (is this needed in some 
> countries??)
> Addresstype           Looks shitty I will redesign-move-make better
> Birthdate                     no validation on input (come on!!!!)
Of course there is validation. The backend will kick your ass.
That's why we don't use MySQL.

> Occupation:   - not saved
> combo_relationship            only filled with mother/father
> Mitgliedsnummer - etc         I presume this is meant to be country specific 
> ID 
> Photo's
> Next Of Kin
Well, see, getting all these right in 0.1 is a lot of work.
Why not stick with the basics and refine past that ? The
problem is wanting everything right now.

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