UI Questions

[Derek O'Connell]

Hi all,

these are some of my thoughts when navigating the UI. Not complete, probably some overlap and by no means in-depth so I welcome your opinions...

1) Does it facilitate the users way of working?

- I notice there can't be more than one patients details open at a time. Do clinicians have "case/workload files" for their own group of patients or is that what the full list of patients represents?

- The UI doesn't distinguish between patient related data and other data, eg, drug data (I call it "ref data" for now) so the ref data pane disappears on selecting a different patient.

- Would a clinician expect the same panes to re-open when re-selecting the same patient?

- Does the UI need to be appropriate to different types of users? Maybe not an immediate concern.


2) Is it intuitive? / Is it familiar?

- The first view an Au user sees (atm) has three apparent ways of searching, each without any indication of differences in functionality (if any) or even what is being searched for.

- Why is the user not immediately presented with a list of patients and maybe an A-Z short-cut index?

- If not searching, then (again, atm) I imagine the user either wants to add a new patient or, eg, look up ref data. That's three possible tasks that shouldn't require any thought on behalf of the user to initiate, ie, the options available to the user should be clear at every stage. This is partly related to...

- Does the UI make the user think to much? Back to the obvious about accessing specific functionality but a little more subtle. There's a topic in User Interface Design call "context switching" (mental, to be minimised). So be on the look out for times when a user knows what they want to do but has to stop to figure out how to do it and/or they are about to do something but it's not clear what the consequences will be. An example of the latter is given above, eg, looking at one patient (maybe editing) and, oh, I'll just switch to so-and-so's record to add a note I forgot... oop's where's the original patient gone (and maybe edits-in-progress).

- Should there be a browser-like "back" button? Users expect this even when the URL doesn't change. The bane of web developers ;-)

- Style & presentation aside, the app will be very similar in functionality to many other app's. Does it work the same way as those other app's? Eg, does it auto-save if I'm in the middle of editing, can I undo changes, etc, etc.

- Style & presentation specifically, does it look and generally behave like all the other app's I use? The current trend is "flat" coloured design, simplified, shallow functionality (think smart phones, tablets, even some OS's). Whether you like it or loath it, there milage to be gained from the familiar.


3) Is it efficient for the user? / Does it flow?

- Is the user guided through multi-step tasks / is the path to an objective clear and obvious?

- Is there excessive mouse mileage/ too many clicks?...

- Are controls grouped together so they are convenient and logically presented?

- Does it "scan" easily? Somewhat cultural, for westerners like me that means left-to-right, top-to-bottom in reading fashion.


4) Is it space-efficient? / Is it flexible?

- Are controls or information too tightly clustered or, equally bad, spread too far apart (too much white-space)?

- Could the UI easily adapt to different cultural expectations (see last point, last section)?

- Do lined borders eat up valuable space?

- Will the UI adapt to different screen sizes?

- Will it adapt to different input methods.


-D

[Easwar TR]

Hi,
Thanks Derek for your thoughts.

> - I notice there can't be more than one patients details open at a time. Do clinicians have "case/workload files" for their own group of patients or is that what the full list of patients represents?

This is intentional. This was discussed by me and Richard very early on and it was a concious decision to keep one window per patient and also have the Patient name and identifying number right at the top.

"Caseload / worklist" is easily implemented. I am waiting for work on the visit to finish to implement a Physician based / advanced patient search, which has been requested by Richard on Github. This is also part of "Dashboard" app that is next up on TODO list.

> - The UI doesn't distinguish between patient related data and other data, eg, drug data (I call it "ref data" for now) so the ref data pane disappears on selecting a different patient.

See above. However, for read only data like Drugs of ICD10 the pane can remain open. The main reason for closing the panes is not to confuse on patient data with another if the Physician multitasks. The scenario Richard gave me was "imagine a Physician typing in notes when a phone call comes from a Nurse asking for some patient detail...." . in such a scenario, with current UI he has to open another tab and look it up to answer the phone call. The existing note will still be there and he can continue. Chance of error is much less. If it were to open in same UI, then there is chance of mixing things up. So, the dictum we have worked on is "One Window  - One Patient"

> - Would a clinician expect the same panes to re-open when re-selecting the same patient?

Well the Search box is implemented on "onChange" event. So it catches a change in value. It would only repoen an exisitng pane ( refresh it in other words ) if we use the keybord arrow keys and select another patient and go back to the first one and press enter. The pane refreshes only when enter is pressed.

> - Does the UI need to be appropriate to different types of users? Maybe not an immediate concern.

If you are talking about permissions, yes, it needs to be slightly different. No different if the "look" but certainly different role based UI elements will be present. There are already lot of places where I do check for user permissions and many forms would not display if opened by other users, but I have not specifically provided alternate UI for the user groups like "Doctor", "secretary", "receptionist", "Nurse", "Admin", "Accounting", "Pharmacist" etc.. May be for version 2.

> 2) Is it intuitive? / Is it familiar?

I thnk Richard is the best person to rank this for familarity. I have not nearly used as many EMRs. From my limited experience it certainly seems more polished. I would like to reduce the number of clicks to get things done and chain a few data entry details like "patient registration" and "contact, demographics and phone entry". One valid form submission leading to display of the other linked forms...but again, early on there was discussion between chaining of work ( workflow) and ability to randomly do things as in paper chart. Paperchart gives you the flexibility to just leaf over a couple of pages add a random entry jump back to some other page and do some editing. Richard had strong views on this and in some ways chaining was not done keeping these in mind. Chaining would imply a linear workflow. If user does not want to chain he would be forced to click "Cance" button everytime a chained form pops up. That would also be irritating. A via-media would be to provide more buttons while submitting the form. For eg: "Save", "Save and Add Contact", "Cancel",  etc... so the user can opt to chain it. This would be especially true if its a first time data entry with patient in front of him.

> - The first view an Au user sees (atm) has three apparent ways of searching, each without any indication of differences in functionality (if any) or even what is being searched for.

yes, this will be sorted out. This is a relic from past - from those those un-pluggable days....
What would be implemented is "Simple Search", "Advanced Search" and "DashBoard". This would open on startup. Search in this context is searching for Patients. Simple search would search by Name ( any name, full, first, last or middle) and Advanced search is when you want to filter duplicates with other criteria like "city", "phone" etc...

> - Why is the user not immediately presented with a list of patients and maybe an A-Z short-cut index?

Actually this was done in previous versions..
Please see the demo here: http://aushadha-experimental.herokuapp.com/

It serves no purpose. The same effect can be achived with a filtering search box.

There are couple of advantages. In a scenario where there are say 20,000 patients to search, for a Grid to populate listing them all it would take unnecessary DB hits. The Physician would on opening the EMR know which paitent he /she wants to retrieve data for OR he / she would want to create a new patient registration. Hence the Grid option was left out. This may come back in when Advanced search is implemented, but again listing all the patients would not be an optimal way of doing it.

> - If not searching, then (again, atm) I imagine the user either wants to add a new patient or, eg, look up ref data. That's three possible tasks that shouldn't require any thought on behalf of the user to initiate, ie, the options available to the user should be clear at every stage. This is partly related to...

Read above.

Only clickable elements on startup is the search bar and "add patient" button at the top right corner. Originally that button was just to the left side of the search bar. May be a more intuitive place can be chosen.

Ref data like Drugs, ICD10 can and should be accessible without choosing a patient chart.

This is a good point and should do into our wiki / github as an issue.

> - Does the UI make the user think to much? Back to the obvious about accessing specific functionality but a little more subtle. There's a topic in User Interface Design call "context switching" (mental, to be minimised). So be on the look out for times when a user knows what they want to do but has to stop to figure out how to do it and/or they are about to do something but it's not clear what the consequences will be. An example of the latter is given above, eg, looking at one patient (maybe editing) and, oh, I'll just switch to so-and-so's record to add a note I forgot... oop's where's the original patient gone (and maybe edits-in-progress).

I perfectly understand.
Please read above why the patient disappears.

I would cetainly implement an alert box which warns the patinet that this will close the current active patient.

> - Should there be a browser-like "back" button? Users expect this even when the URL doesn't change. The bane of web developers ;-)

Oh dear. That with an RIA app would be painful to implement. Just thinking about that hurts :(

> - Style & presentation aside, the app will be very similar in functionality to many other app's. Does it work the same way as those other app's? Eg, does it auto-save if I'm in the middle of editing, can I undo changes, etc, etc.

A Google like autosave and undo is what Richard (or was it you Derek ? ) has spotted on Google Docs and wanted me to implement. Would take that up once version 1 is done. I dont want to add more to version 1 TODO list unless that feature is a make of break.

> - Style & presentation specifically, does it look and generally behave like all the other app's I use? The current trend is "flat" coloured design, simplified, shallow functionality (think smart phones, tablets, even some OS's). Whether you like it or loath it, there milage to be gained from the familiar.

Yes,
Did think about that.

Styling Dojo dijits is something that I have not taken much of look at. Infact there are a few bundled themes ( not nearly as many as jQueryUI for eg..) but they are not great. The best theme is "Claro" and thats whats currently on.

It is a little old world in terms of what we see with explosion of touch devices and Win8 Flat styles.

> 3) Is it efficient for the user? / Does it flow?

Workflow is what I initially started out to achieve. Richard has some great points that forced me to think and we had altered the UI just to allow random addings, editings and viewings. This is to force a paper chart like behaviour. Still the number of clicks may be a little too much for Richard and I will work on that.

> - Is the user guided through multi-step tasks / is the path to an objective clear and obvious?

Ye. Not much guiding is there ? I did put some Tooltips on mouseover over some elements but thats only on the loading screen. By now I am not fit to even comment about the UI usability as I use it everyday. Somebody should have a fresh look and let me know. Let me see if I can host the latest 'master' branch as a demo.

> - Is there excessive mouse mileage/ too many clicks?...

yes, there is. I dont mind some clicks here and there. But I do think there is plenty of scope for reducing the clicks. A balance of click-and-scroll should do the trick.

> - Are controls grouped together so they are convenient and logically presented?

Hm. Right now Au does mostly CRUD stuff.
Things like "Messaging", "Faxing", "Pharmacy Requests", "Billing" etc.. are other things an EMR would do and that would require a more controls and we would revisit this question.

> - Does it "scan" easily? Somewhat cultural, for westerners like me that means left-to-right, top-to-bottom in reading fashion.

Again, I use it every day. You get used. That should be evaluated by a first time user. I would  try to host a fresh demo and let group know.

> 4) Is it space-efficient? / Is it flexible?

fairly space efficient I would think.

Flaxible ? yes, I thnk it is flexibile. Ui layouts resize well, it is responsive on smaller screens. ( not phones)

> - Are controls or information too tightly clustered or, equally bad, spread too far apart (too much white-space)?

I lke minimalism. Let me throw this at you. When I first had a look at Mac I didnt have a clue as to what to do. I didnt see any menu, no familiar buttons, even close-minimise buttons where on the opposite side. There was also too much white space. But it looked damn cute. I like white space. I also like information in small columns for easy scanned readings like a news papers. I like Portlet suggestions by Richard and this is something that I have started work today, a custom AuPortlet widget for flexible layout. The user can also choose what portlet he wants displayed on load.

> - Could the UI easily adapt to different cultural expectations (see last point, last section)?

left-right traditional western reading it would adapt.
I would not think this layout would suit far-east asia expectations.

> - Do lined borders eat up valuable space?

See above for Dojo styling comments. In addition, I have removed some borders and made others rounded. I will try to remove some more, but plenty of work to be done in other areas means this figures lower down in list of todo things.

> - Will the UI adapt to different screen sizes?

I have checked with iPad 10".
It is ok. Some parts of touch and scroll does not work.
Currently however, I am focussing on desktop.
I stand corrected, but entering a medical record by typing on tablet would be pain.

> - Will it adapt to different input methods.

Currently Keyboard and Mouse are preferred input types and Deskop is the optimal device.

I guess, that finishes all the comments Derek has made.

Looking forward to hearing others view on this.

I would try and quickly set up a demo with the latest version and then update you guys.

Those of you who are a little put off by the Postgres switch and are not keen to set it up would find that easier.

Cheers,

Easwar

--
 
Dr. Easwar T.R  MBBS, DNB(Orth.), MNAMS
   Fellowship Paediatric Orthopaedics & Deformity Correction( Sing., Kor.)
   Fellowship Spine & Scoliosis Surgery (Kor.),  
   Spinal Microsurgery (Ger.)
 Consultant Paediatric Orthopaedic & Spine Surgeon

     Ph:      91-98407-24924  
    Web:   www.dreaswar.com
    Email: drea...@gmail.com

[richard kim]

Is http://aushadha-experimental.herokuapp.com/ up to date?  I have not been able to setup postgres, so I have not been able to install aushadha for a while.  Could I ask for a version identification on the demo, so we can tell which version we are using? 

I've been learning to program in the meantime, but it's really going slowly.

Richard

--
You received this message because you are subscribed to the Google Groups "AuShadha" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aushadha+u...@googlegroups.com.
To post to this group, send email to aush...@googlegroups.com.
Visit this group at http://groups.google.com/group/aushadha.
For more options, visit https://groups.google.com/d/optout.

[Easwar TR]

No Richard. Its really old and out of date. Ill have to change and put up a new demo.

Meanwhile, you can still use SQLite. I have left some portions in settings.py commented. This would be under the entry for DATABASES.

Once you change that you can syncdb like before and continue using SQLite.

As for postgres, I did foresee difficulties. Can you please put specific issues you are having in a new thread so that we can try and solve it.

Dr. Easwar T. R. DNB(Orth.), MNAMS

Consultant Paediatric Orthopaedic & Spine Surgeon

www.dreaswar.com