Recently, the BayCHI mailing list had an interesting discussion regarding a very common input mechanism with which many of us have grown accustomed: selecting from a group of available items and adding to a congruent set of chosen items. The polemical issue that arises with this selection tool is in its implementation, specifically “should we collect items from left-to-right or from right-to-left?” The easy answer that many will throw out is that for the Western world, we read from left to right and therefore this is the correct way to present it for us Westerners. True, but there is more than meets the eye and by investigating this aspect further, we can reveal other supporting arguments for this presentation.
Here is a case in point of this mechanism:
In the example above, users would be instructed to move items from the list on the left to the list on the right. In this case the user would highlight an item on the left and click on the “Add” button in the center. Another popular implementation of this input method employs drag and drop functionality. Let’s examine both the click and drag methods.
Click to Add an Item
In the case of clicking the items followed by the “add” button, the argument for reading from left to right is a strong one. Here the user creates a sentence through action, picking the subject on the left and choosing the action in the middle, with the collection or target list being the object, such as “I choose apple to add to my collection list.” In order to undo this action, an understandable backward-flowing sentence is created as if walking backwards through the first action, such as ” I choose apple in my collection list as the item to be removed and placed in the available list“.
There is a stronger argument still which requires looking at this problem from a greater distance. We should understand that this mechanism is usually part of a greater form or input set. Additionally, these items as with all other input items require a label with instructions to their completion. The following shows an example of such a layout:
In the above example, we have employed a vertical layout of labels and fields in order to keep a straight line from start to end. In this case, the user would be making all entries in the leftmost position of the page. By keeping the available list left-justified, we minimize mouse and eye movements from the last entry field to the first click within the list.
Another association here is the connection between the label and the action of inputting data. Compare the layout above to the following example:
Here the directions for inputting data are diagonal to the action required. Based on this presentation, users may be led to believe that the ability to select from the list on the right is a peripheral action, and that typing into the “My Favorites” field is a permissible option.
Drag to Add an Item
For dragging and dropping items, the notion of creating a sentence flowing from left to right is not as applicable. The factors which must be taken into account are:
- What is the dexterity of the user in pulling items from right to left versus from left to right?
- How do we reduce the mouse movements of the user in making selections?
What is the user’s dexterity in moving the mouse in a particular direction?
The dexterity of motion relies on a few factors such as:
- Which hand is the user navigating with: left or right?
- What precision is required to drop the item in the target destination?
- What is the distance between the list boxes?
It is evident that the smaller the distance between the boxes, and the larger the target area, the greater ease a user will have accomplishing the task (see Fitt’s Law). In terms of the fluidity of motion from right-to-left versus left-to-right in relation to handedness, there is still much to research to be done in this area, and I was unable to turn up anything that argued in favor of one.
How do we reduce the mouse movements of the user in making selections?
Reducing mouse movements again rests on the distance between the list boxes along with the likely starting point of the mouse in relation to the boxes. In the example shown above, when the selection mechanism is preceded by instructions (as it should be) or apart of a larger form, it is best to keep the act of selecting in line with the other inputs and its directions. This supports a left justification of the available list, and thus supports a left-to-right motion.
There may be a viable argument for presenting the available list on the right to reduce mouse movements when the user is likely to have just scrolled down the page, and thus have the mouse in the rightmost edge of the screen. Although, this could be true; there are many who use the mouse to read along with text, and thus would move the mouse across the screen before making a selection. In keeping the selection close to the instructions, we can account for this kind of behavior. In addition we can make the required action more apparent by spatially tying the instructions to the immediately following point of action.
In sum, then, for the Western world, regardless of the mechanism employed (clicking or dragging), the layout of left-to-right for select list boxes proves to be generally more logical, intuitive and usable than its counterpart which guides motion in the opposite direction.