Introduction

We had a terrific meeting regarding the UI on Friday 2/29/08. Below is a summary of what we agreed upon. I'm sure I've probably missed a few points so if you find I've noted anything here you think is inaccurate, please add your notes here and/or let's discuss on the developers list. Thanks! -Bob

In attendance: Hamish, Darius, Christian, Mike, Dave, Joaquin, Bob, Paul, Burke, Ben, Brian, Paul English, Vinay, IBM guy, other guy (sorry - could someone please add the correct names here?)

= Immediate Goals =

*We want program managers to want to use OpenMRS. This means that they have a useful tailored homepage that allows them quick access to the stuff they really need (like reports)

Specifics

*Links above the tabbed menu for all pages: username, role, logout, my profile, print, help, report an error (This is not presently shown on the mockups. The implementation of this should ideally make the user feel like their feedback is immediately being sent out - perhaps it's a widget that lets the user send a screenshot of the offending page at the same time )

*Patients

• *Patients submenu - 3 fixed areas: patient summaries, patient details, and create/find patient area
  • The list of*patient summaries should be tailorable - either by adding weight to each summary module, or fixing it in a global property. A drop down menu allows for infinite expansion.
  • The list of*Patient details should be similarly expandable. Default detail pages should include: basic details, meds, encounters, labs. Other possible pages - photos, food program details.
  • *Find patient should be a pop up widget so that the user can search for patients without leaving the page their on. Found patients should open in the same view.
• *Patient Summary should have the following elements:
  • • Narrow left hand column should be common to all patient screens and include photograph and patient-understandable data that gives the patient a sense of ownership over the system. Professional photographers should be used to train staff to take really good pictures of patients. (PE)
    • Right side column can be subdivided into two equal sized columns containing patient data - ex, graphs, alerts, meds summary, labs, recent notes...
    • We need a default patient view page that is not specific to HIV or MDR. It should be possible to add new patient summary pages with modules. In the future, it would be ideal to have a module that creates a patient summary screen that is completely customizable by the user
• *Patient Detail Screens not fully discussed, but mockup ideas were generally accepted. It should be possible to add new detail pages with modules
• *New patient creation also not fully discussed, but really should be simplified into a 2 step, rather than a 3 step process with no duplicated data entry as shown in the mockups to achieve the "less sucktastic" goal

• *Group submenu. Everyone was on board with putting the data export and the reports into a more prominent position in the submenu.
• *Data Export and Reports - people were generally okay with the layouts in the mockup, but we didn't have much discussion on these sections.
• *Build new group There was a lot of discussion surrounding this. We identified the need for a simple search w/ very limited variables vs a very advanced search w/ every possible variable. Various schemes were discussed. A lot more work needs to be done with this & it may affect the organization of the whole "Groups" section.
• *Group summary screens is still a work in progress, but everyone agreed that if we wanted them, they'd live under this tab

*Message bar should appear as a horizontal section either at the top or under the sub-menu for system messages, alerts, etc

*Colors - everyone would like it to CSS-based and customizable, but all feel that a version similar to the blue/gray sample would be best as a default (no decision on the new logo)

• • We reached a consensus that JQuery should be used rather than Dojo and that PIH felt strongly enough about this to replace existing dojo widgets (with the form schema builder being the last thing to be replaced). Some researh still needs to be done about how JQuery will work with Dojo in the interim
  • We also need to decide which template system to use to make the code easier to add to. Paul English recommends Velocity because of its speed. (PE went on to explain in a very compelling way how speed makes a HUGE difference in user satisfaction.) Other options include Tapestry, Tiles, Sitemesh etc