May 12, 2008

The usability of a garbage can

It's been a while. The last couple of weeks have been a mix of usability lab, and me being sick. Usability, as always, was exhausting but very productive. Scripted activities in a lab are only part of the interface picture. There are a lot of things that environment isn't, but one thing it is: a great way to shine a light on any basic stumbling blocks that the designers/developers have become immune to during the process.

We had surprisingly few of these; the worst one involved prompting users to try to go into "mobile"/small display mode. It was lumped in with "styles" in the preferences, which nobody expected (and not many found). It's been shifted to more a appropriate heading, and more importantly, a "fast switcher" is now available on the masthead. This has the advantage of being a common element across much of the web. Hopefully we'll catch most cases automatically with a little intelligence on style sheets and a tiny bit of a javascript probe. Google seems to rely exclusively on this--or a user knowing their mobile url--as neither nor gmail seem to have a link or preference anywhere to jump to their mobile versions. I'm not sure if they don't subscribe to the mobile web design community's wariness of detection (as accuracy is always suspect), or they just think they're that much smarter than anyone else... interesting question!

Aside from that issue, the other thorny one was the idea of deleting messages. IMAP has a two-step deletion model; you mark a message deleted, and then you "expunge" to permanently remove all deleted messages from a mailbox. It's a model of both safety and efficiency. You aren't moving a message around to delete it, so you're saving on IO, possibly network bandwidth depending on the environment, and lessening the risk of message corruption.

The downside, as we've heard numerous times in both the usability labs and from users throughout the years, is that most people flat out don't like it. They obviously like not having messages permanently disappear as soon as you hit "Delete". They don't like the message sitting there, with its big red "X" and strikethrough and whatever other "hey, I am deleted! I'm different!" indicator might be used. This isn't surprising. From POP3 clients twenty years ago to the defaults of Yahoo! Mail and Thunderbird today, deleted messages go to a "Trash" can. People are used to it, people want it.

The problem is, that isn't what IMAP is designed for. So, we're left thinking about ways to accomplish this. Thunderbird, Apple Mail, and Outlook all take a common approach. By default, deleted messages are copied to a Trash folder. They are also left in place marked for deletion, in proper IMAP style. The client hides these marked-for-deletion originals from the user's view.

What happens when the Trash is emptied?

All the copied messages in the Trash folder are permanently removed, while the originals are left there for all eternity, or until the user executes some sort of "Compact folder..." command. Which, obviously, nobody ever does unless they specifically know they should, because the client is hiding the messages that the "Compact" will remove. How can you expect someone to be a responsible user of a shared resource when they don't know that their software is leaving a trash heap under their feet?

This approach, however, does have advantages in that it satisfies the user desire for a Trash folder, and it leaves deleted messages alone in the original mailbox until directed otherwise. While the latter is problematic for the reasons noted above, it's a good thing in that it's non-disruptive if a person uses more than just that client to access their mail. Imagine you've been using Gophermail, marking messages for deletion but you aren't ready to get rid of them permanently yet; then you use Thunderbird at your desk, and it unilaterally does an expunge for you after you delete one message there. You'd go back to Gophermail the next day to find all the messages you left there gone, and then you'd end up with an expensive paperweight after giving your laptop a Kruschev-style shoe-banging.

So, there is a method to their madness.

But it has a huge cost in wasted storage.

What's a person to do! We're discussing this in an ongoing fashion. In the end, it seems that this approach may be the best idea if coupled with a clear, well-communicated policy like most e-mail providers (from Google and Yahoo to other universities) of removing any deleted messages after thirty days. This is one that is going to take a lot of talking out, but it seems a reasonable compromise.

April 17, 2008

Learning, and interface

I spent Monday at MinneWebCon, which was a great experience; big thanks to the organizers Kristofer Layon and Peter Fleck, et al. It was a credit to the University to have that quality of a program here.

Moving on to this week's Gophermail progress: work on finalizing some style issues is ongoing. Myself and the alpha test audience have been evaluating some small things that make big differences, such as typeface. Trying to settle on a sans-serif face that is readable without strain in both standard and bold. I'm a bit surprised, honestly, at the challenge this has posed. At least to my increasingly Mr Magoo-like eyes, most of the standard sans-serif fonts seem very thick and compacted in bold. I think we've got it now; if it poses any problems during usability we'll hear about it.

Also continuing work on using bandwidth-freeing javascript insets, rather than full page loads, for a number of input interfaces that don't really need a full page. This would apply to things such as adding a person to your Contacts or changing miscellaneous settings, as opposed to composing a message. For an idea of where we're going with this (click for larger version):

April 11, 2008

Web interfaces

AJAX, Web 2.0. We've been through the hype, the outrageously context-inappropriate deployments, more hype, the dismissals, more hype, and the backlash. Now we seem to be getting on to the part where people are using these techniques to add a layer of responsiveness that makes web applications less frustrating than they once were, while keeping in mind fallbacks for accessibility, mobile, and the like.

So, what can these things do for Gophermail?

Two of the major goals for the 2.0 release are addressing accessibility concerns and the mobile environment. The first step in this process took place over the first few months of this year. The late-90s markup style of Prayer was largely gutted. Tables for layout, especially, were mercilessly stripped. What was left was a semantically-meaningful skeleton to be enhanced with a presentation layer (CSS) and an enhanced interaction layer (Javascript).

First, I'll stress this: all functionality is available to a browser that ignores images, styles, and Javascript. In fact, one goal of this process was to make such an environment more useful than it previously was. For example: There are now proper headings to make navigation with a screen reader easier, and fewer redundancies in page content (the 1.x series has no fewer than three identical lists of folders on the message list page for various controls, for example).

That said: the abstraction of the presentation layer has enabled mobile/small-screen and large-font versions, among other things, that hinge only on style sheets. This will enable, going forward, rapid development and modification of environments for a wide array of devices.

On the interaction side, there is a small Javascript library being introduced that attaches asynchronous handlers to a number of actions. For example: deleting a message from the message list screen no longer causes a page reload. Neither does checking mail, or navigating through your folder hierarchy in the new folder view. Not only does this enhance responsiveness and hence usability, but it greatly cuts down on network use.

This is critical going forward as e-mail on mobile devices moves from being a toy--or something people put up with because they had to--to something that is truly usable, and in demand. The more we get devices with readable screens and low-key, usable interfaces, the more true this will become, and with this shift in the "platform" we're on our way to being able to address these needs in an agile, flexible manner.

I'm curious if people have ideas on ways that web-based e-mail interaction, whether in a desktop browser, a mobile device, or anywhere else, could be improved. Most development seems to focus on emulating the classic desktop e-mail clients, and it's fairly obvious that this isn't the most productive approach.