Usability – Amount Ordering Control (Part 2)
In the first part of this mini-series I set out the basic problem and made the first sketch of a solution. In this next part I will open up the design and discuss how the parts are put together the components required to finalise the solution. The wireframe of the solution is shown below. There are only three items in the list, however it can be imagined that this will increase over time and that some sort of list would suffice. As we can fully style the list items the possibility of showing a graphic as well as a selection button or check-box is a simple matter. The amount field will be a textbox that only allows the entry of numeric characters based on the order increment value. Range input will be in the form of a slider that indicates the min, max and warning ordering amount levels associated with the selected item. Additionally the slider shall be colour coded to indicate the okay, warning and error ranges using green, amber and red accordingly. There is an interaction between the numeric input and the slider such that changes in one will result in changes in the XX changes in the other. With respect to the Order button, it will only be enabled when an item is selected and a valid selection has been made in either the amount field or using the slider. During access to the database, either during loading or saving, the control “real-estate” will be disabled using a busy indication of some sort. The basic design can be seen below.
Forget Programmability think Usability
Now let us consider the essential part of the design – the usability. Normally, this type of dialog with the user would be split into either a reactive dialog allows the user to enter anything into the conversation and have the validation take place after the Order button has been pressed or a proactive where errors are indicated at that time they happen. In this case a proactive design will disable the Order button whenever the data input conflicts a rule or constraint. For example, entering a value greater than the clearly indicated maximum allowed amount or that no decision has been made as to which item should be selected.
I will reject the reactive design as it makes the user feel “naughty” or “foolish” having entered data that is invalid. Moreover, the user is frustrated in the sense that their time has been wasted entering data only to find that out at a later stage. However, the proactive approach may also lead to user annoyance if the proactive feedback is in anyway “aggressive” i.e. messages incorrectly phrased or the use of harsh colours (especially red in western society).
To overcome the above issues I will inform the user as to the aim of the dialog and its operation up front. This can be achieved using a banner description above the active dialog content similar to that found in Microsoft Money. The proactive validation feedback will be displayed interactively reinforcing the aims of the dialog. In this case exceeding the maximum will result in the Order button being disabled and a text enforcing this – “The maximum amount has been exceeded. Please reduce your wished amount below XX to enable ordering of the YY item”. Similarly for the selection of an item in the list of possible choices could be similar to “Currently no item has been selected. Your order cannot be processed until an item from the above list has been selected”. The banner description will therefore be along the lines of “Your order cannot be processed until an item has been selected from the list of available items and that the wished amount does not exceed the maximum allowable. Order amounts that are above those normally encountered but do not exceed the maximum will be possible. However, those amounts will be displayed as lying in the amber area of the amount indicator.”
The final validation handling will only result in a friendly and helpful message being displayed and the Order button being disabled and the user is free to enter whatever values they wish and to make a conscious decision on ordering more than the normally ordered amounts.
One last usability consideration come when the number of options available to choose from cannot be displayed given the real-estate available for those items. The problem is such; given that the available real-state for the items will only allow three to be displayed at a time and that more than that number of items that are available for selection is significantly more, 20 say, how will the currently selected item remain in focus when the user scrolls away such that the currently selected item moves out of view? The approach taken here is that of elasticity, i.e. the selected item will be pulled back into view after a certain inactivity delay and that the selected item is out of view.
Finally, we need only to consider the placement of the helpful and dynamic informational message. Attaching the message to the display element in error leads to the user searching the dialog for an entry field in error. More helpful is to situate the message close to the “acceptance” input, in this case the Order button. Hence this message will appear either above or below the Order button as this button will have the user’s focus when the user believes that the dialog has been correctly filled out.