Contextuality on mobile devices

In my last entry I mentioned contextuality. What is it? Can it be precisely defined? Why is it important? Let's answer all those questions.

Well, it's a term that I coined, and it means:

Showing sufficient context for the information that the user is reading or editing.

If a UI lacks contextuality, it doesn't display the context of the information the user's interested in. Let's continue with the iPhone as an example:

In the calendar, editing an entry involves selecting the entry and going into an "entry edit mode" (in Symbian, especially UIQ, this is called the "edit view"). The problem with the entry edit mode is that you can only see information relating to the current entry. Unfortunately, for calendar entries, the relevant context includes the other entries in that day. Hiding the rest of the day from the user means that when they make changes to that entry, they don't know how that will interact with other entries. (Will it cause a conflict? Will it provide enough time to move from activity to activity?)

This is a common mistake, particularly on mobile devices because of their limited screen real estate. But it's a mistake that's often made even on the desktop. A good example of how it should be done is, again, provided by Mac OS X, with iCal. iCal has a slide out pane that provides edit controls for editing activities. This pane slides out from the day/week/month view, which stays visible, keeping the activities in that view updated with changes in the edit pane (and vice-versa).

This toolpane concept has been around for a long time. I first encountered it on Artworks running under RiscOS on Acorn's Archimedes machines (the first ARM-based computers) back around 1991. It still works brilliantly on Artworks' descendant, Xara Xtreme (my favourite drawing application, available here).

Most other tools, such as anything from Adobe, Macromedia, MS, etc. tended to violate contextuality by dumping you into a dialog to do anything, which robbed you of the context of what your changes did to your document. (Dialogs have another problem: preventing "direct manipulation", but that's a subject for another post.)

Fortunately everyone seems to be cottoning on to contextuality on desktop apps (although a lot of Web 2.0 apps, such as this one courtesy of Google, set us back several years). However, the same can't be said in the mobile world.

Because of the space limitations of mobile screens, it's very important to understand how much context is enough. Desktop apps can be profligate with their screen space, but we can't. So how much context is enough?

The minimal context for a piece of data can be found by
determining the smallest amount of surrounding data which cannot
be completely reordered without significantly changing its meaning.

So, for example, a single contact record is the smallest chunk of context for contact information. Whole contacts can be reordered without changing their meaning (and, indeed, all contact applications support this -- it's called changing the sorting order). But fields within a contact cannot be reordered to the extent that they end up in other contacts, because that would change their meaning. So a single contact is the context of contact information.

What about for calendar activities? Well, this one actually depends on the user's purpose, and that's why calendar applications (and, indeed, paper representations of calendars) have multiple types of views. But at it's most focused, a calendar activity's minimal context is a whole day of activities. If the activities are moved around in the day, they change their meaning.

(Sometimes users want to work on a larger scale, such as a week or month, and thus there are week and month views to calendars, but often a day is enough, and each day can be considered interchangeable or independent.)

Contextuality is important. Without it the user is robbed of important information about what they are viewing or changing. Yet how often is it considered? Indeed, the whole design of UI's like Series 60, UIQ, Palm OS, Windows Mobile, and iPhone seem designed to violate this concept.

Could this be one of the reasons why people are so reluctant to edit information on their mobile devices (even when they have perfectly adequate keyboards, and there are significant benefits to making updates on the run)?