phone usability design notes (part 1)

I am starting a company, BuildCap. BuildCap’s target market includes groups like the Transportation and Land Use Coalition.

TALC staff, like others, in the non-profit space do field work away from computers, but they still need to interact with the BuildCap software. So this leads to a mandatory phone browser support requirement. As a result, I am doing preliminary research on being able to support phone browsers.

I am using a Samsung A900M phone, which is actually a fairly nice phone, but one that only cost me $40+tax and a 2-year contract with Sprint just before Christmas 2006.

Some notable stats:

  • Java
  • QVGA – The main screen measures 1.78” x 1.53” and sports 262K colors over 240 x 320 pixels
  • 1.3 megapixel camera
  • connects as a USB device to Win XP
  • 47mb memory
  • EVDO data network (fast)

Some of the info about the web browser on this phone:

  • Browser supplier: Teleca
  • Browser Name: Obigo (AU System)
  • Browser version: AU-MIC/2.0 MMP/2.0
  • Markup Languages Supported: WML, XHTML, HTML, Basic/MP
  • Cookies supported: Yes
  • Maximum URL length: 512 characters
  • Transfer protocols supported: HTTP, HTTPS
  • ECMA Script: Yes
  • Multi-part MIME: Yes
  • CSS Background Images: Yes

This phone is a reasonably high-end phone but still arguably affordable. If this phone doesn’t support something then, it is unlikely that any other phone equivalent or lower in price would either. As a result, this is a good first phone to demo with.

So what did I find so far?

Gothas so far:

Using link <a> with the href attribute containing javascript

This doesn’t work at all in the browser. It complains that it needs a handler for this type and dies. This is probably the quickest way to break a site from the perspective of the phone. Tapestry’s LinkSubmit is guilty of this behavior. Since proper css can make a regular submit button look like a link, a proper <input type="submit"> is probably best. For BuildCap, I am going to set up a checkstyle rule that flags uses of LinkSubmit as an error.

Requiring the user to press “enter” key.

This is the second quickest way to break the site. There is no way that a phone browser user can generate the enter key! So if an action needs to be performed, an submit or link must be available.

Redirects

The browser asks for confirmation on every redirect. So multiple redirects are painful, especially redirects that result from security checks. I would suggest designing code to chain code so that all the things that can trigger a redirect vote for a redirect that is only actually executed by a single piece of code.

Dojo seems to have some issues

Still working on this, but dojo seems to not work well on the browser, even though the browser allegedly supports Ecmascript. For example date/timepickers are not working at all. They are not creating their input fields, yet the browser claims there are no “scriptng” (sic) errors. More research is needed.

Color selection limited

Considering how many colors the phone itself can support, this surprised me. The browser looks like it only supports these colors for text:

  • black,
  • blue,
  • green,
  • cyan,
  • red,
  • magenta,
  • brown,
  • light gray,
  • dark gray,
  • light blue,
  • light green,
  • light cyan,
  • light red,
  • light magenta,
  • yellow,
  • and white.

That’s all for now. More to come!

update According to this from Alex of dojo, Obingo’s browser “will be poorly supported”, because(?) “No way to easily get emulator”. Again more research is needed.

This entry was posted in tapestry, technical. Bookmark the permalink.

2 Responses to phone usability design notes (part 1)

Leave a Reply

Your email address will not be published. Required fields are marked *