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 24, 2008

Accessible, and Mobile

So I've talked a lot here about accessibility, and that work is still ongoing. But, today is a day for talking about something new and different.

Received Mobile Web Design by Cameron Moll in the post yesterday, and have begun working my way through it. As I've mentioned here in the past few weeks, part of the refactoring of Gophermail towards current "semantic" standards is to make it simpler to target towards various media, including mobile. This path is currently being worn by some of the best, from Apple to Google to a hundred smaller outfits. Our goal is to take some inspiration from the things they've done, while incorporating some of our own ideas and targeting the University environment in specific ways that outside folks simply never can.

But! While that thinking is going on, the first step is simply to have something usable and readable, and to that end I'll conclude this little bit of musing (more details later, I promise!) with this screenshot of Gophermail 2.0 running on an iPod Touch. Apologies for the quality, there's no easy way to do a screenshot so this was taken with the built-in camera on my iMac. Click for full-size.

April 18, 2008

Searching for (W3C) validation...

A week from today, we'll be meeting to finalize usability scenarios and go over the prototype. Five days after that evaluation sessions begin.

As we're in the home stretch now, I'm trying to finalize any feature adds that involve changes to interface elements, and beginning to move on to clean-up. Just like a good woodworker, I do my best to keep my area clean as I work. But I'll be the first to admit that during the iterative prototyping process, sometimes the sawdust accumulates around my feet a little. Today began the process of standardizing the CSS class usage across different areas of the app, fleshing out error handling to do more than writing a message to the console, things of that nature. And, of course, running all pages through the W3C validators.

Inherent in this is confirming that accessibility elements such as labels, fieldsets, and tab order have been employed in applicable areas. Heading elements, which can be used for quickly navigating a page with a high density of information (such as our message list screen), are a particularly interesting aspect when it comes to a web application as opposed to a web page. While most textual pages have some sort of outline structure, explicit or implicit, this isn't necessarily true in an application. Apps can lean in the direction of, oh, call it a widget model. There are widgets on the screen, which you try to group logically in relation to each other, but don't necessarily lend themselves to a hierarchical or list structure.

I've talked to a number of people about this issue and it sounds like I'm not the only one who wonders about this. So: for the moment I'm doing the best I can by having a "heading" (not necessarily always visible to non-screen-reader users, when visual clues render it redundant) for each major segment of the page.

For example, in the following screen shot:

  1. H1, not visible, at the top of the page which reads: "Message list for homework".
  2. H2, not visible, at the start of the main toolbar which reads: "Main toolbar".
  3. H2, not visible (likely will become visible), for the search box: "Search messages in homework".
  4. H2 on "My Folders".
  5. H2 on "homework with 8 messages". For an interface that does not use styles, this heading appears at the start of its toolbar, before the Copy/Delete widgets.
  6. H2, not visible, on the bottom toolbar which reads: "Occasional actions". That title will likely change, but it is appropriate!

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.