Mobile Gui

From MvcIsNotImplementable:

Abstract design, usability: For better or worse, largely settled; the last burst of innovation was with the W3 explosion. Anyone designing a GUI or website must now bear in mind user's expectations based on experience of other apps. Mobile phones seem to have settled as a subset of GUIs.

• I've done mobile GUIs, but I'm not quite sure what you mean. The limited screen real estate makes it a real challenge, but it's not like we just settle for that as lowest common denominator and do the same thing on desktop screens. Please elaborate, maybe on MobileGui?

Ok, but I was saying I'm not sure what you mean, so of course I'm even less sure which aspect of Mobile GUIs you'd like to see elaborated. Please explain what you mean by "settled as a subset of GUIs", and tell me what you'd like elaborated.

(My experience was implementing a major portal on mobile phones (using WML), after I'd worked on the desktop part of that portal; the adaptation was fairly easy implementation-wise but quite difficult design-wise, since so little of the desktop experience could be simply ported straight across.)

My impression of MobileGui as a subset of DesktopGui? was based on a quick look at JavaTwoMe?. To say that something is a subset is not intended to be derogatory: defining a suitable subset of anything is a challenge, as is using it.

• Yes, that's how I took it.

I suppose the key question is, are there any patterns (formal or informal) used in a MobileGui that have no counterparts in DesktopGui?? I can see there might be, to deal for instance with lack of real-estate.

It would be great to have a couple of frinstances from a practitioner (hint, hint). - DavidWright (June 2004)

Ooops, over a year late replying, sorry.

There certainly are informal patterns, and I think some of them could be back-adapted profitably to DesktopGui?s.

Our group supported multiple kinds of mobile devices, but I'm going to focus exclusively on cell phones here, for specificity.

In 2005, things are somewhat easier in some respects, given that embedded Java and moderately high resolution (320x200?) and moderately high color (8 bit/16 bit?) have become far more common, but I won't address that, and some of the other limitations remain.

Many of the company's InformationArchitects?, and almost all of the graphic designers, detested the constraints, and either refused to work on MobileGuis, or did a remarkably poor job on them - and this was reflected in all companies, and is a large part of why MobileGuis from all companies have tended to suck so badly in general.

Our group, however, found it an interesting challenge rather than a detestable punishment, and as a result we came up with the friendliest MobileGui portal on the web; years later, most of this stuff is still being done badly, suggesting that there is indeed a need for people to grok the necessary patterns (although we didn't use PatternLanguage at the time).

Constraints (it's been a while, so figures are approximate, nor have I stayed current on this year's latest and greatest):

• physically small screen (2 inches square or so), small number of pixels (down to 100x100? Still no more than 320x200 even today, I think), small number of rows/columns of text (something like 10 or 12 rows of text each of perhaps 25 columns on the display, with the scrollable virtual display also small, perhaps double those dimensions)
• had to work with black/white only screens (1 bit/pixel), ideally should support 2 bit greyscale and 4 to 16 bit color
• extremely sparse navigational controls: scroll window up/down/right/left, go back, select current highlighted option (menu), select current button with assignable label, and not much else (and not always even all of the above - quirky vendor-dependent issues)
• extremely painful alphabetic user data entry (average user will refuse to enter more than maybe 1-3 letters at any time for any reason, and result will be error prone), adequate numeric user data entry (e.g. requesting a zipcode for location-based movie search tended to be acceptable in terms of the mechanics)
• Low bandwidth and bad latency: Quite slow downloads and turnaround in response to user input, measured in seconds at best

The basic model (and this was explicit, not just a pattern) was a deck of cards, where each card represented a single scrollable virtual display screen, such as a 20-item menu, of which 10 lines at a time were visible. There was a limit of perhaps 10 cards per deck.

The entire deck is downloaded all at once. Each card can contain links to other cards, in which case the latency for switching to the next card to display is very fast, because that next card was pre-downloaded as part of the deck. Links can be made to other decks, but those are slow, since it requires downloading the new deck, replacing the current deck.

That model immediately implies some pretty basic stuff: applications need to be carved up into natural units represented by a single deck; if two screens need to be flipped between quickly, e.g. between a menu and several target screens from that menu, where the user may go forward and back several times, they'd better be part of the same deck.

This in turn means anticipating what the user will want next, rather than simply being purely reactive.

Example: say the user is sitting in an airport waiting for a flight, bored, drags out their phone (this was in fact a common scenario), goes to our portal, and sees a menu with selections like News, Sports, Movies, etc and selects News:

Dots (...) represent currently visible screen, which scrolls over the virtual screen, dashes (---) represent limits on virtual screen; text beyond the latter limit is simply truncated and cannot be seen at all, period.

  +....................................--------------+
  .           Current News            .              |
  . 1 Is Sheehan a Spark or a Flicker?.              |
  . 2 Computer worm still has legs    .              |
  . 3 US ekes past T&T                .              |
  . 4 Young Catholics want Pope to uph.old Church sex| stand
  . 5 ...                             .              |
  +...................................+--------------+

Keep in mind that we don't choose the headlines and stories, they're provided by a content provider in an XML feed to us, and processed by software, not humans, for display on the phone.

This sometimes leads to comical results. The above was taken from today's Google news headlines, and the truncation limits can lead to things like the user seeing:

   Young Catholics want Pope to uph

...so they're curious, so they scroll to the right and see:

     lics want Pope to uphold Church sex

Hmm. Surprising! Let's see what the story says. :-) So the user drills down from there and gets:

    Reuters India - 46 minutes ago
    By Tom Heneghan, Religion Editor. COLO
    GNE, Germany (Reuters) - They're full
    of life, brimming with raging hormones
    and Catholic. [MORE]

Well, this is still ambiguous, so they drill down again and finally see enough of the story to disambiguate:

    So what do young people at the World
    Youth Day want to hear from their 78-
    year-old Pope about sex?
    The hundreds of thousands gathered in
    this Rhineland city all know that Pope
    Benedict staunchly upholds the Church's

    ban on pre-marital sex, contraception,
    gay marriage and other aspects of what
    he rejects as a modern "anything goes"
    morality. [NEXT PAGE]

There's nothing we can do about ambiguities like this, we can only recognize that they occur and will affect the user's experience in some odd ways.

Anyway, the user experience is worse if each user selection requires a download, so what worked better was to download both the menu of headlines, plus a first paragraph of each story, into one deck, that way they can read at least that first paragraph with no delay.

This is especially important since the headlines are so often fairly meaningless teasers. With the pope story they had to drill all the way down to see what was up, but at least part of the time, the first paragraph is enough, e.g. above "Is Sheehan a Spark or a Flicker?" Who? What?

A glance at the first paragraph (which shows up instantly, since it's in the same deck) shows "Is Cindy Sheehan the spark igniting an antiwar movement that threatens the Bush presidency? Or is she just an over-hyped flicker that will be extinguished with the next turn of the news cycle? [MORE]" - which may be enough explanation such that the user decides not to read the rest of the story, and instead (instantly) returns to the News menu to try a different story.

So the pattern there is to anticipate that the user will not get enough info from headlines to know whether they want to wait for the download of the story, so we put a bit of the top of the story into the same deck as the menu, so that they can do a little back and forth navigation without waiting for a slow download.

Thus although mobile device physical characteristics are largely a simple subset of the desktop screen characteristics, it's not so simple for the GUI design; some aspects are just different, not subsets.

To be continued....

-- DougMerritt