Concerns of Usability and User Interface Principles

Prompted by Dan Johnson

This weekend, when the brain went on idle for a few moments, I found myself reviewing the primitive user interface that's up with this app, and realized that perhaps we need to discuss the cognitive principles that create usability, so that the 'usability hooks' are designed in even as the work continues to stay away from user-interface concerns.

To do this, we need to consider entry to the tool from the point of view of a naive user who does have experience with a standard mouse-driven user interface.

Operant Issues

What will be that users' functional expectations for the mouse/keyboard?

Presently the default behavior of Eclipse/SWT components is assumed for most of the user interface elements, and where we had to develop our own, we tried to mimic that standard behavior. For example:

• Left-click mouse action to select, open, etc.
  • on menues it is the usual behavior (left-click and hold to arm then release to select)
  • on lists we have revised the behavior to be more in line with common expectations:
    • single left-click will "arm" (or preselect) an item (without opening it)
    • hitting enter-key will open the armed item
    • double-click will select&open any list item
• single right-click-hold for context menu, single-left click to select menu item
• tab to advance focus to next logical entry field
• in lists allow pre-select and cursor up/down movement

The current ideal goal is that the application should be usable by mouse and as much as possible by keyboard also, avoiding the need for the hand to have to leave the keyboard to pick up the mouse. However, not all functions can be reached by keyboard yet, most notably no Alt+Letter to select main menu-bar item, and no shortcut keys to select drop-down menu items.

What actions will the user be needing to perform quickly and directly?

The current idea is that once a patient is selected, the the user has the problem list and medication list always open. A click on either lists's item opens an edit task in the main dialog area. The dialog area is tabbed allowing multiple detail views to be open at the same time.

Since the focus is still on prescription writing, the medication editor is the main function (and unfortunately still also the function which has the most bugs).

Connecting problem list item with medicine is to be done easily by typing or dragging the problem onto the prescription.

What actions constitute 'refinement' of an action, that should appear at a secondary level?

Presently there is no secondary level other than where we have begun to display sub-items. For instance the ingredient list is there, and the dispense (supply) event list. One may consider the ingredient list of lesser value and should perhaps leave it collapsed by default.

Dan Johnson has proposed that renewals/refills should be created for a whole series of medicines. This should be doable by allowing multiple selects from the medication list and a right-click context menu item saying "refill selected prescription(s)". However, this is not implemented yet.

Perceptual Issues

What will the user perceive with each screen and prompt?

Currently the idea is that a task-specific "perspective" is seen which consists of a main (tabbed) dialog area for any detail edits, and a number of lists and tools surrounding it. That is informed by the common look and feel of workbench style applications as well as from the paper-based "Kardex" which Gunther Schadow had used in hospital care or the paper folders he's seen in outpatient practice. The good thing is that the system is designed so that these perspectives can be changed per user-request. It is now the time to address this question with Daniel Johnson and Martha Adams' specific ideas and wishes.

How can we influence that perception?

What distractions or misunderstandings afflict the presentation?

Perceptual Tools

Rhetoric (expected user dialect)

We have a very formalized terminology for the logical object model from HL7. But most of that terminology can be (and currently is) hidden to the user. Some of the words we chose instead of the HL7 words are not terribly useful in their own right. The good thing is we can call things on the surface whatever our users like to call it, as long as such naming does not conflict with the logical principles behind those names.

While we have a quite flexible approach to adapting the presentation of the logical model to user conventions, we also think that the logical model, having been agreed on in principles with analysts and domain experts, holds a guiding value even if it sometimes appears unexpected.

Look and Feel

Color, layout, borders, etc. is standard Eclipse/SWT which adapts to the look and feel of the underlying platform (and its configuration). For instance, I use Windows Classic, so for me the look is classic (rectangular, flat, silvery surfaces). One of our developers uses Windows XT new style, so for him it looks like that (3d, rounded, colored surfaces.) If run under Linux, again, it is expected to adopt the configured style. This is a built-in feature of the basic Eclipse/SWT infrastructure which we depend on at this time. So, deviations from this can be supported, but there is a penalty of manageability to such special configurations.

Layout

We have the greatest flexibility with the overall layout. So, while few constraints exist from the underlying Eclipse/SWT tools, a lot can be rearranged.

Borders and whitespace

Color

Typography

We do realize that the font sizes may need to be adjustable, but we do not do anything special about sizes. (This notwithstanding there is currently some "fine print" which can be seen in the application which we leave in to validate the data logic and help in debugging while testing.) This fine print may eventually become invisible (while probably still accessible.)

Non-Abbreviated Prompts

An abbreviated prompt is simply a (strange) name. While agreeing on the names visible on the user interface, we would have automatically agreed on whether or not (and if so how) to abbreviate.

Mouse-Rollover Elaboration or Instructions

These are available, but only used spotty and not as complete as they could be. However, we are improving and setting the folowing design guideline for ourselfs: DataEntryFormatHelp