gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Patient screen concerns (labeling and search)


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Patient screen concerns (labeling and search)
Date: Sun, 20 Jan 2008 21:01:32 +0100
User-agent: Mutt/1.5.17 (2007-11-01)

On Sat, Jan 19, 2008 at 09:49:52AM -0800, James Busser wrote:

> The patient search was really bothering me and I think I now know better 
> why.... it is because it is possible, in the search input, to type a name 
> other than the current patient. if you take a screen shot, or you are 
> interrupted before committing the search, you have on-screen text appearing 
> next to the photo and field label "Patient" that does *not* relate to the 
> current patient.
That is, indeed, an undesirable situation. I have done the
following: whenever the patient search widget looses focus
it redisplays the active patient's name. This will, however,
have its own inconveniences at times: imagine you want to
activate a patient in GNUmed which you've been working on in
another program. Since you aren't quite sure of how to spell
the name you switch back to the other app for checking after
starting to type a fragment into the search box but before
hitting enter. GNUmed loses focus - and so does the search
box. This will then reinstate the currently active patient
name display.

> Also, the current patient is not necessarily a patient. It may be a member 
> of the praxis staff (since even these, without ever having been a patient, 
> are required to be in the database).
That's part of the paradigm or design principle: a person is
a person is a person. It foregoes redundancy in the
database. The fact that staff can only be activated in the
client as if a patient is just an implementation detail --
the frontend simply does not offer activating a person
explicitely as a non-patient.

> Also, after accepting the name of a patient in a search result, the search 
> text is replaced by the currently-active identity of the patient. There is 
> some benefit to this, however the user then loses how they searched for 
> this person, which has value when:
> 1) they may need to stay aware of a relevant alias for example on a 
> hospital or test result
> 2) in case this was not the patient they wanted, would make it easier to 
> revise the previous search
> 3) maybe has education value - supervisor or colleague could observe by 
> looking on screen that the search was inefficient

Oh, you can always recall the most recent search fragment by
hitting UP-ARROW in the patient search box ;-)

> Proposal:
> - change the text next to the search box to be "Search"
You mean "Patient" -> "Search" ?

> - change what was previously "Patient" to be "Found" (since it may be a 
> member of office staff)
Not sure I can follow particularly with the statement above
this one.

> - display the currently active identity of the found person next to "Found" 
> in a type that is larger / bolder or otherwise has more emphasis than the 
> search text (sorry I was not able to achieve this in the screenshot mockup)
Not sure what you mean exactly.

> - change the onFocus behaviour of the search text box to select-all instead 
> of cursor insertion, if it is agreed that users will more often search for 
> a new patient than edit/correct a previous search
Strangely enough it should already do this. Will re-check.

> - when no match was found, it requires two steps to search again... one to 
> dismiss the dialog that gives you no choice except to be taken to the "New 
> Patient" wizard, and another to cancel out of the "New Patient" wizard. Can 
> that first dialog be modified to offer a second button -- even if it is not 
> the default -- that says "Go back" or "Search again",
Will do.

> and in place of "New 
> Wizard" to say "Register new person" since that is, in fact, the window bar 
> label in that next wizard?
Done.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]