workflow

Every few days there's an interesting article proposing new interfaces at UXmovement. It's like a serialized release of a new Tufte book, not always what you agree with, but invariably both thought-provoking and affirming.

I've broadly agreed with almost everything I've seen there in the past few weeks, including having a few "wow, yeah!" moments. So it's only when I think there's room for discussion that I'm blogging about it, and I hope that it doesn't come across as caviling! A recent post talks about simplifying the "search hotspot" on your websites by moving elements around. I like the ideas behind this simplification, but it would definitely need testing, especially as a lot of influential sites (including Amazon) moved in the other direction years ago.

The major problem I foresee is not so much ambiguity: the ambiguity is eventually resolved by the text on the button. It's more to do with how you optimize an interface for "just-in-time" disambiguation. People in the Western world largely read from left to right (although you could swap "left" and "right" in this blogpost and it wouldn't matter so much), so forcing people to look first at an empty box on the left, wonder what it is, continue right, then see the button, then---"aha! that box I just saw a half-second ago was a search text box!"---look back to the box in order to search... this complicated just-after-time disambiguation slows the user down, and makes them cumulatively uncertain using your site.

"Search" in a right-hand button disambiguates retroactively, whereas you'd ideally want the user to be disabused of any notions before they even get to the box. Accessibility points directly at the issue here, serving as the canary in the coal-mine. The way that the proposed alternatives don't meet accessibility guidelines---no labels for the text box or the dropdown---suggests that the only thing that ever truly disambiguates an input element is, ultimately, a label. And this label typically sits (or is read out by a screen reader) before the box, not after it.

The suggestions on the most recent UXmovement post are also not consistent with guidelines in a previous post about why users fill out forms faster with top-aligned labels. What do I mean by that? Well, in that post, very close label/input combinations in a clear single visual direction are treated as a single step; back-and-forth combinations comprise multiple steps.

Just for fun, let's give two of UXmovement's suggestions their own treatment:

Here we see the behaviour I discuss above. In the first example, the eye travels from the search label/input (which it fills in) to the go button: two steps. In the second, the eye sees the input box; looks right for clarification; looks back to the beginning of the input field to fill it in; moves back to the search button to click it: four steps.

Does that really mean there's a problem here? Does consistency between different parts of a web interface matter? Well, I have to stress that, as with accessibility, inconsistency is not a deal-breaker for a new interface; but you have to be sure that the widely accepted "visual grammar of search" and plain observed user behaviour supports the contextual changes you make to your UX guidelines. The user is key. You want to keep them as happy and as certain as possible: they have to continue to trust their weight to your interface.

Who knows? You might find in usability testing that people are so used to the visual grammar of search---a box in the top-right means "search"---that you could get away with no button at all, and people would figure it out with a low failure rate.

Inconsistency is fine. Inaccessibility---when we're prototyping new user interfaces, and accessibility with slow-moving web standards is often post hoc however hard we try---is OK, but it needs to get sorted before production releases. And clutter is completely excusable, if that clutter makes every next step a no-brainer.

If the user needs clutter, provide clutter; if they don't, don't. Your user interface does not have to be a show home. It just has to work.

Recently my wife and I were trying to work out why she couldn't submit her address details to a website, even though I could. As we watched her behaviour in filling out the form, we encountered error after error: or rather, exceptional circumstance after exceptional circumstance. And it was clear that very few of the circumstances had been considered, that error handling was the absolute bare minimum, that the form was set up to be almost a trial to use. The postcode lookup part of the process was probably the source of the most unhandled exceptions: difficult if not impossible for the power user to flow through; unwieldy for the standard user; of almost no benefit at all to the web newbie.

People still think of their workflows on the web like they're workflows. Over here there's the start; over there is the goal; somewhere in between there might be some intermediate stages, but ultimately you go from over here to more or less over there eventually. It comes as something as a shock to most people that their beautiful webform does not encompass a workflow: the web has holes all over it; the user is a ball bearing and your application is a pinboard:

Above we see a slightly clumsy metaphor for your web application. The end point of your own particular "workflow" isn't even something visually obvious like the shark's head. It's, oh, let's say that small metallic gate in the bottom right with the red doors (luckily for you) open. The best you can hope for is that the user caroms through your website hitting as few pins as they have to and ends up in one of a trillion end points, that they don't close the browser, or reach a form error, or silently lose their submission, or navigate elsewhere in irritation.

In fact, it dawned on my wife first, and then gradually on me, that postcode lookups are not intended to directly benefit the user filling them in. Instead, they're meant to force the user---remember that phrase---to provide a canonical address, and not the address. That is, the user comes to your site with an opinion about where they live and limited good will about your "product", and the postcode lookup is a mechanism for forcing them to discard the former, while the application as a whole is trying hard to get them to keep hold of the former.

Good luck with that.

Richard Rutter figured out the dirty secret behind postcode lookups---that they're not for the user---long before my wife and I. In order to mitigate this natural tension between forcing the user and keeping them happy, he's done a sizeable chunk of work to condense the postcode lookup pattern here. Along with a quite lively and informed conversation in the comments, this post nails much of the core of the pattern that lookup needs. Much of what's frankly miserable about using a postcode lookup is indeed tackled there, but there's an important omissions that I think needs dealing with. Roughly speaking, that is: never force your users to pretend to be someone they're not.

As an example, consider Spotify. Since inheriting a slightly ropey eMac, I've been able to listen to Spotify, and I like it. I think Spotify is a gamechanger in the field of streaming music. I've heard albums on Spotify that I would never have bought. And yet: I would never consider purchasing Spotify Premium. The obvious barrier for me is that I use Linux, and there are no native Linux binaries for the Spotify desktop client.

People keep telling me that Spotify runs really well on the Windows emulator WINE. I'm sure it does. But that misses a more fundamental point: if something wants me to enter into a relationship with it, commercial or otherwise, I should not have to pretend to be a demographic I'm not in order that the relationship can be properly fulfilling. I'm not a Windows user, and it's an affront to a paying customer to expect them to make out that they're a type of user that they're not if they want to buy your stuff. More consisely: I don't take offence at the interface requirements; I take offence at what they imply about the respect for my needs as a user.

With that in mind, consider the first decision block in Richard's workflow:

does the user know their postcode?

As this is the first pin the user's pinball hits, then this is the one that alters their final resting place the most. This is the critical pin. And what does it tell me, a user who knows his postcode but also knows his address, and doesn't want to bother with lookup? It tells me that I have to pretend to not know my postcode if I want to be in a situation where I don't have to put it in. I have to play games with the application, and mask my true intentions. No, the postcode lookup system must allow for users who simply do not want to fill out their postcode. Postcode lookups should therefore begin with a simple choice of two buttons by a traditional form label. The buttons should not make any assumption about the user's reasons for choosing either route:

Address:  [LOOK UP POSTCODE]
               [JUST LET ME TYPE MY ADDRESS]

When you press the first button, both buttons should still remain on the page: the user might decide they wanted to press the second one after all. In fact, as we're probably using AJAX here, the minimum necessary modification to the form is just to add a postcode box (and to move and maybe change that button) like this:

Address:  [ postcode ]   [LOOK IT UP]
               [JUST LET ME TYPE MY ADDRESS]

You should still present the user with the ability to change their address. The "speed bump" of having to press the button is what works in your favour, is what gets you access to canonical data; anything more than a bump will run the risk of walloping the user right off your pinboard.

If at any stage the user clicks on the second button, the webform should then change to this view:

Address:  [ Address, either as a set of textfields or as a textarea ]
               [ postcode ]   [LOOK IT UP INSTEAD]

For simplicity, I'm almost tempted to drop lookup button altogether at this point: the user has made their choice, after all. But you should never make it difficult for users to go back in a workflow, especially when (almost certainly) the browser back button will have been disabled by these shenanigans.

In comment 10 on his blogpost, Richard agrees with the idea of one big textarea for the address: possibly even including the postcode in that textarea! Again, the simplicity is appealing. You could do all sorts with this to make the user's experience easier: regex matching behind the scenes would retrieve the postcode; the address could even be automatically split into lines rather than setting real estate aside for the user to split them up themselves. It sounds great, but it's not an established pattern, and I think a lot of users---especially power users---would mistrust it. Better to go with Address 1, Address 2 etc. even though from a data perspective they're a horror, slightly improved---but, again, made more complex for the user---by labelling the last address line as "town". But this last detail is up to you. Do some A/B testing. See how it goes.

Richard's workflow, with the addition of the basic prototypes above, permits us to move towards as usable a system as postcode lookup will ever be. Usability means the least number of pins on your pinboard, and exactly the right pins, the ones that nudge and tilt the user just enough. And so we end up with a system that still satisfies your original remit---to nudge the user towards using your shiny, expensive, time-consuming, postcode lookup service, with all its concomitant costs in development and maintenance---while catering for the users who simply do not want to, who will never want to, and who will actively object to your site giving them short shrift if they try not to use it.

I'll make a prediction here, that the users who try not to submit a postcode will tend to be the users you want: the digital natives, the users in flow, the people who will buy ten things from a polished user interface without even stopping to think about it. When they reach that very first pin on the board, they briefly want to be your application's friends on the web. Your application should consider itself honoured. The least it could do in return is be polite.

I've never been completely happy with this spindly and slightly confusing diagram from the Django Book, ever since it appeared the first edition. Once I'd digested it, I almost immediately started redrafting it as an exercise in explaining it to others, for a possible seminar for wannabe Djangolians at Torchbox.

Time went by, as it was wont to do, and I still had a slightly incomplete diagram of the Django internal architecture on my desktop. The Django Book had since been reorganized, empires had risen and fallen, we had probably passed peak oil, and I still hadn't any use for that fecking diagram.

In an attempt to just get rid of it I've polished it up and posted it here: a three-page PDF of Django's architecture. It's got callout boxes and different colours and everything. Feast your eyes on it; move rapidly between pages, as in a flick-book; complain about the fact that it's not much of an improvement on the original. Just don't leave it on my desktop, please.

Drupal has a built-in form abstraction system called Form API (or FAPI), which like the Atom protocol consists of two complementary halves. The first is an abstraction of forms to structured data, and is dealt with very well by both online documentation and the excellent Pro Drupal Development. The second is a workflow for turning this data into forms, validating form submissions, and processing valid submissions onto output streams such as the database, the browser or emails to the user.

This second half is quite complex and, like much of Drupal, has various points at which the user can hook into the process: whether by use of the hook_* functions that modules use to talk to each other and the core, or by defining #callback array elements within the FAPI structured data. However, documentation is pretty sparse: PDD is rather quiet on complex workflows, although it does have a lot of slightly higher-level, prose information.

Someone had already taken steps to rectify this: drupal.org user KarenS sent round a detailed flowchart of FAPI’s functional internals which detailed the function-by-function process of FAPI. Seeing a definite niche for a Tufte amateur such as myself, I muscled in and helped her out with a cleaner version of the diagram. I’m dead chuffed to say that this was good enough to go live: take a gander at the Form Workflow Illustration.

I hope to make similar diagrams for core Drupal (in less depth) and PHPTemplate at some point, actually all my own work: watch this space.