Skip to end of metadata
Go to start of metadata

This is a bit speculative, and undoubtedly my own thoughts on the issue. Still really fuzzy.

What Are we Building for Engage Mobile?

One of our primary goals for Engage is to deliver a rich and useful experience for museum visitors using a variety of mobile devices.

  • Focus primarily, for the first year, on delivering a pure Web-based experience. Just a Web site.
  • Experiment with some features that may require native phone APIs: 1) 2D barcodes + camera or 2) audio recording
  • Longer term, deliver a hybrid experience if needed, combining Web-based UIs with a native, downloadable app

Scenarios for Deploying Engage

1. Plain old Web application: available through the mobile device's built-in Web browser, along with its usual chrome
2. "Home Screen Bookmark:" (currently only on iPhone) User can manually create an icon on their home screen, providing a "chromeless" browser experience
3. Downloadable hybrid app: a native app that uses an embedded browser view for rendering its primary UI, while taking advantage of native APIs such as the camera, audio, and more.

Thoughts on Supporting Multiple Devices

iPhone and the Others

The iPhone's user interface conventions are extremely well-established and supported by their Human Interface Guidelines. With this, users tend to bring a fairly firm mental model of how the user interface should work. They expect to use certain gestures, they expect consistent layout and navigation, and so on. Failure to conform to this mental model, at least in the case of downloaded apps, will inevitably cause frustration and disappointment.

The other platforms, particularly Android and Symbian, provide little in the way of established conventions and consistency of interaction across applications. Put another way, there is no solid user mental model about how an app should work with. This is acutely the case with Symbian, where even portions of the OS behave differently than others. Symbian and Android users expect diversity and inconsistency. I still don't have a good sense of Blackberry as a platform, or the expectations its users bring to it.

Another thing to point out is the fairly small number of apps running on the non-iPhone platforms at this point. Undoubtedly, app development is picking up speed on all platforms, but iPhone has the largest base. As a result, many apps are being ported from iPhone to the other platforms, bringing with them the idioms and conventions of the iPhone. I suspect that most Android or Symbian users don't find this particularly disconcerting.

On the other hand, the Web brings with it a very different set of expectations, even on the iPhone.

The Web as Platform

Examples of Webbish Mobile Web Apps

Try these on your mobile device or in Safari:

The Technical Context

  • Cost of implementing different idioms for different platforms: styles of navigation, themes, etc.
  • Cost of reimplementing native controls in HTML/CSS/JavaScript
  • No labels