flow|state

Why not allow the user to rename an open file?

It's odd that virtually all document editors still prevent the user from changing the name of the file they're working on. This is a shame, because it's a common user task.

A user may start writing a new document, save it under one name, and then as the document evolves come to realize that another name would be more appropriate. There's usually no good way to do this inside the application, so they struggle through workarounds like saving the file under a new name and then digging around in the file system to delete the file with the old name. The operating system usually doesn't offer much help either:

The main reason most applications don't support this is because most platforms don't make it easy—and the main reason platforms don't make this easy is because most applications don't think they need to support the feature. Alan Cooper vented about this problem in About Face, and it's still a widespread problem today.

There are a few applications enlightened enough to let you rename an open file. Microsoft Visual Studio, for example, handles this without complaint. Interestingly, Microsoft Word used to support this—but only in the Macintosh version years ago, before its user interface was realigned for consistency with the Windows version.

It's almost impossible to get problems like this fixed in an application, let alone the operating system. Unless customers complain about this, no one wants to tackle the problem—and by now most people have grown too used to working around the problem.

Google Local for Mobile: bellwether Java cell phone applet

The new Google Local for Mobile is a compelling little demonstration of what a Java cell phone applet can do. It's carefully tuned to the constraints of cell phone hardware, uses the network well, and makes good use of the graphic display and local caching.

Google Local for Mobile

The installation process was much easier than I’d expected. Google’s site does a good job helping you figure out whether your phone will actually run their applet, which is nice and presumably reduces customer disappointment. The site directs you to a web page to open on your phone, and offers to SMS you the URL to save you the trouble of typing it in. The resulting web page sniffs your browser to determine which download you need, so you only have to make a few clicks to download and install the applet.

In my case, I had to put up with some very clunky Java applet management UI produced by the local cell phone OS (controlled by my phone manufacturer, not Google). For example, the phone asked me to confirm that I wanted to install a “MIDlet”, whatever the heck that is. I expect most cell phone manufacturers outsource the utility UI like this to the cheapest bidder, with predictably poor results.

The Google Local applet itself is simple but quite polished for a phone app. It feels a lot like Google Maps. The keyboard UI for zooming in and out took some getting used to. You can read a complete description in the Google Local tour. The UI suffers from the fact that the key to zoom in (the OK button, or the center of the directional pad) is otherwise unrelated to the key you press to zoom out (a mappable button that labeled here as "Zoom -"). This is a reasonable trade-off given the small keyset available on a phone, but nonetheless the lack of conceptual connection between the buttons makes it hard to learn their relationship. It's also confusing to see the zoom out command clearly labeled, when what every user will need to do first is zoom in. The applet does offer a quick tip on how to zoom.

The zoom UI also has the unusual behavior that setting the zoom level doesn't take effect immediately—you can zoom in or out multiple levels, then wait a second for the new zoom level to kick in. Again, this is a reasonable trade-off given the bandwidth on a phone, but again this is confusing for the new user. Now that I know how zooming works, I think it’s elegant, but I expect a significant number of users will be completely confused and give up on the applet after a few minutes of failing to successfully zoom around.

Other small points: I was disappointed that Google’s address lookup couldn’t find my house. I was also disappointed that Google Local couldn’t show me my approximate location on the map based on info from the cell towers. Finally, at one point when I switched away from Google Local and then launched it again, Google Local lost track of the previous map view. It reset the map back to a high-level country view, forcing me to laboriously re-zoom down to my local area.

The weakest part of the whole experience in my opinion is that it’s hard to get back into to the Google Local applet once you've left it. This isn't really Google's fault. On my phone (and probably most other phones), Java applets don't get their own top-level entry point in the main menu, nor is there an option to create such an entry point. I have to navigate to a special Java area first, then launch the Google Local app from there. For me, the entire navigation sequence in six clicks long, and requires two clicks that are essentially random (i.e., the UI element doesn't suggest that clicking it will lead you closer to a mapping application). The top-level Java area eventually did show up as a shortcut on a top-level MRU (Most Recently Used) list, which cut out a few clicks, but that shortcut will age off the MRU list if I don’t keep using it.

I’ll bet that a big chunk of people who download Google Local won’t be able to find the applet after the first time they run it, so this single issue of finding the app’s entry point could be a critical weakness. Convincing cell phone OS designers to make it easier to launch Java applets is a chicken-and-egg problem: OS designers won't do this until there are more interesting applets like Google Local for Mobile, and app ISVs won't create a significant body of interesting cell phone applets unless they can be sure users can quickly and easily run them.

Nevertheless, my overall reaction to this applet is quite positive. Google Local for Mobile may become a bellwether entry in the mobile app space, in much the same way Google Maps broke ground for highly interactive AJAX apps. This is the first non-game Java app I’ve seen that’s worth downloading. If you have a Java-capable phone, it's worth checking out.

Letting a user specify a preference using an example

I recently came across an elegant demonstration for getting the user to specify a preference by offering examples to choose from. This technique is often done with visual settings (e.g., letting a user select a template for a document by clicking on sample template thumbnails), but in this case, the technique was applied in letting a user specify a simple textual setting for a date format.

I've been looking at some web sites that help manage To Do lists, including tadalists.com, rememberthemilk.com, and mypimp.com. (Where do they get these names? The latter could adopt the slogan, "We think having a borderline offensive name is so funny it's worth giving up market share!") All these sites strive to be as interactive as possible, and to some extent they each struggle with the absence of conventions for entering data on highly interactive web pages. This has produced some interesting and creative UI experiments, some of which succeed.

One bit of creativity (albeit in a non-interactive area) shows up in the account setup page for rememberthemilk.com:

It's the last line that caught my attention. The label for the radio buttons doesn't even say what you're picking (preferred date format), but it's obvious what you're supposed to do: pick the sample that shows the date the way you like it. What's particularly interesting is that this trick capitalizes on a person's ability to recognize patterns at a subconscious level. I live in a country where the month comes before the date, so the first option ("14/02/05") looks like a jumble of numbers to me, while the second option ("02/14/05") leaps off the page as a valid date. Presumably people who live in date-first countries have the opposite reaction.

It may turn out that this trick only works in narrowly constrained circumstances; perhaps it would stop working, for example, if they needed to support a broader range of date formats. Nevertheless, it's impressive that rememberthemilk is able to ask for something as mundane as a date format in a manner consistent with the site's overall casual visual and textual tone.