Cognitive Friction

In my last post, I threw the rattle out of the pram over my disappointing experience trying to buy an iPhone 3G on the day it was launched. As of today – almost a week later – I am still stuck with my crappy Sony Ericsson T630. Last Friday the O2 store said that they would call me when stock came in, perhaps by Tuesday. Well that was two days ago, so I made a few polite inquiries today. Here’s what I heard:

• A guy in Car Phone Warehouse told my friend that they expected a nationwide delivery of new stock in two weeks time, consisting of just 700 phones, which is exactly what they received at the 11th July launch.
• O2 and CPW are pissed off at Apple for oversupplying the States and starving the rest of us for stock. I don’t know, though, it’s unsurprising that Apple would look after the US first and let the rest of the world suffer any initial stock shortage.
• I called the O2 store where I placed my pre-order, and they expect some stock today or tomorrow. How many phones and what spec. they will receive they wouldn’t say. Those will go to whoever’s next on the preorder list.

So I may get lucky and get a call this evening or tomorrow, if my number comes up. After that, I’m on holiday and out of the country for most of the next two weeks, so I’ll have no choice but to wait until early August.

In the interim, I’ve been downloading some apps from the app store to my iPod Touch and having fun trying to sync OmniFocus across my Macs and the iPod. More about that experience in a later post.

Updates

Friday 8^th August: I got my iPhone! Read my first impressions.

Wednesday 6^th August: So I called into the O2 Store today and inquired about my iPhone. The staff told me that the waiting list had been cleared and that I should already have gotten a call to collect my phone. I had received no call. They checked the store room and found no phone waiting for pickup – I had somehow been overlooked. The staff took my details again and have promised to call as soon as they can source a phone for me. Bummer, but at least it’s getting fixed. I knew taking a holiday was a bad idea.

Friday 18^th July: I see that stock did arrive into the O2 retail stores yesterday and was used to clear pre-orders not yet filled. An O2 forum administrator posted this to the iPhone stock thread:

Some stock was made available yesterday for customers who had pre-ordered but not received a iPhone. Some more will be on the way soon.

So my number didn’t come up yet. I bet they try and call me next week when I’m on holiday, Sod’s Law says this will be so.

Science fiction author William Gibson said The future is already here - it is just unevenly distributed. The same could be said of Apple’s long awaited iPhone 3G, which launched last Friday. Although I had pre-ordered a phone at the start of the month, I came away empty handed.

iPhone 3G - still waiting

I turned up at O2’s Henry Street retail store at 8.00 am on the day of the launch. They normally open 9.30, but the O2 website publicized a 9.00 am opening. By 9.00, there was a line of about 20 people, including me and my colleague Ciarán but the store didn’t open until 9.35. The manager unlocked the door and stood there to advise people with no pre-order that they would not be getting phones today. I had heard on the grapevine earlier that morning that this store had exactly 11 models in stock, a report that proved spot on. Those levels of stock were typical in Irish stores: 10 phones here, 14 there. Pathetic.

At the counter, the assistant showed me her pre-order spreadsheet. It had 11 names at the top highlighted green – those getting a phone that morning – and about 20 names below that highlighted red. I was about halfway down the red list. No phone for me. I changed my pre-order to a 16 GB model and was told I might get my phone Tuesday, maybe, they’d give me a call. Folks with no pre-orders were told they’d have to wait two weeks, maybe more.

I was disappointed, naturally, I’d been waiting two weeks since I prudently pre-ordered my phone to pick it up on launch day, and took time off work to stand in line. Worse, folks who didn’t pre-order at all, but went to stand in line early at Car Phone Warehouse, were lucky enough to get their phone that day.

It’s not the end of the world, I know, but I feel Apple handled this launch really badly. The predictable but unmanaged server load, the resulting activation debacle, the poor levels of stock, all add up to a really bad user experience. In fact, I’d say Apple’s handling of this launch sucked, and to prove it I ran a poll over on the forums at the maccast.

9 out of...er...9 said the iPhone 3G launch sucked

As you can see above, most people (55% as of 14^th July) also reckon this launch sucked while a further 33% were less than happy. So what’s the fall out for Apple here? Probably nothing. Personally, I can’t wait to get my phone and will probably forget how much I griped about the launch as soon as I pick it up. Watch this space.

I was buying the excellent ScreenFlow application from Vara Software yesterday and that old chestnut, the mandatory post code field, came up again. For some reason, whoever coded their purchase forms decided it would be a good idea to ensure that:

• You must enter a post code, even if you don’t have one.
• It must not be one character long
• It must not be too many characters long

What’s too many? I would guess that it’s the maximum length of a British post code or American ZIP code, or some such arbitrary length. Filling this in was a pain – here’s how it played out.

First, I can see the field is mandatory, so, I try entering a hyphen, figuring that it’s the least effort and if anything actually gets posted to me, that’ll look the least silly on the printed address.

Error! you have foolishly attempted to enter one character, this is verboten!

OK. Time to send these people a message. But wait. That is verboten also.

By this stage I am trying to model the mentality of the coder of this form:

Hmmm. What boundary conditions can I imagine that would enable me to validate the text in this mandatory field? Well, I know there should be more than one character, because I can’t conceive of a post code system that uses just one character. And if I set an upper limit to the number of characters in the field, say the length of my local postcode, I’m done. Excellent! What a diligent programmer I am.

Do you know the worst thing? After all this careful validation, he accepts two hyphens.

So, effort was expended in ensuring that only nonsense that falls within rigidly defined parameters is acceptable. AAARRRGGGH! Maybe I just get riled up too easily. But these little details are so easy to get right, there’s just no reason to get them wrong.

I spent a great deal of time in Omnigraffle this year and last writing Form and Behavior specifications for websites and web applications. These documents contain a lot of text and a lot of diagrams – site maps, wire frames, widgets and so on. I used to use Omnigraffle to produce the diagrams, then export them for use in MS Word or PowerPoint. As I got to know Omnigraffle better, I started using it to create the whole specification, using the presentation functionality to present the spec and outputting to PDF for printed copies. But it’s not perfect, and I have a short wish list for things I’d like to see in the next version that’d make my life easier.

1. Better text handling: Omnigraffle isn’t a text editor, but I’d really appreciate some improvements in how it handles text. Lists that work would be a good start. Lists don’t add new formatted lines as you write, probably because the application has no sense of styles attached to blocks of text. Lists are hard to find too. I was using Omnigraffle for over a year before I found the control for adding bulleted lists on the ruler. Not a good location for it. A better system for handling paragraph and heading styles would also be welcome, especially if it facilitated generating a table of contents.
2. Components: I find myself drawing the same toolbar, footer, widget or whatever again and again throughout a set of wireframes. Now the smart thing to do is to draw one example and then reuse it by pasting it into a layer on other wireframes. The problem is that when one link on a toolbar changes, you need to go through the whole document to effect the change everywhere. On some projects, that eats up a lot of time. I’d like to be able to designate certain groups as components, so that a change in one instance is automatically applied to all instances. That would make life a lot easier.
3. Richer actions: I wish Omnigraffle had a richer palette of actions. Currently, actions are essentially varieties of hyperlink, jumping you around between documents, canvases or URLs. It’d be great if Omnigraffle had actions that changed the properties of shapes, text and groups. This would enable me to simulate roll-overs and other application behaviours in clickable prototypes. Imagine if this were integrated with Applescript, so that we could script for simple behaviours in prototypes too. Sweet.
4. Better variables: The variables in Omnigraffle are a good start, but there aren’t enough and they aren’t flexible enough. There may be a way to change the format of the date variable, but I haven’t been able to figure it out. A really good set of variables would release the true potential of master pages – for me the model for master page and variable functionality is Adobe FrameMaker. I recall turning out some fantastic templates in that application that automated lots of the little fiddly bits on a page. I’d love that sort of power in Omnigraffle.

There you go, I told you the list was short. I’d be interested to know if anyone else has anything to add to this list. Finally, I know that Omnigraffle 5 is well on the road to release and I haven’t looked at the feature set yet. Now that I have written my wish list, I may go over and take a peek. Fingers crossed that I’ll be pleasantly surprised.

Update

Just had a look over at the feature list on Omnigraffle 5 beta, and we have a few hits:

• “There is a new action in the Action Inspector to show, hide, or toggle visibility of any given number of layers.” This will enable simple animations simulating state changes without using multiple canvases. Not all that I had wished for but a very welcome addition and a good start.
• “Instead of using Master Canvases, OmniGraffle Professional 5 now has Shared Layers instead … Changes made to any shared layer dynamically propagate to all instances of the shared layer.” This looks like components, I’ll download the beta just to check this out. Woohoo!

Not on my wish list, but most welcome given that many of my colleagues are still stuck on WinDoze:

• “OmniGraffle Professional 5 now has a built in parser to convert the binary Visio file format (VSD) to XML for import. Visio stencils (VSS) and Visio templates (VST) are supported.”

We had a bit of a heated debate in work this week, which followed my suggestion that we should consider using a HTML/CSS Framework to create prototypes instead of creating so many wireframe drawings. Now, there’s a whole case for and against this approach, but I don’t intend to go into all aspects of it here or any of the specific differences among my colleagues. Instead, I want to focus on the most contentious issue in the debate, which is how technically adept a user experience designer should be. This will also bring me back to the issues that started me blogging again, as set out in my Agenda Addendum post.

My agenda

If you missed that post, or just forget what I said, here’re the issues that were exercising me in that post:

• The role of prototyping and design specifications and the wisdom of spending time on these design artifacts as opposed to just diving into the build process.
• The role of design and designers in the development process and the relationship between designers and engineers

To ease back into this subject, I want to introduce a little known but seminal text on this subject by Mitch Kapor, co-founder of Lotus Development Corporation. It was written back in 1990, before the web really took off and before the phrase ‘user experience’ enjoyed wide currency. In fact, it contains the earliest use of the phrase ‘user experience’ that I have ever encountered. It’s called A Software Design Manifesto, and was eventually published in the anthology Bringing Design to Software, Terry Winograd (ed.) Addison-Wesley, 1996.

Kapor’s Manifesto

In this manifesto, Kapor opens by lamenting the poor user experience of the software of the day, which he puts down to a total lack of professional design in the software development process. The remedy he proposed was the creation of a new role in software development teams:

The lack of usability of software and the poor design of programs are the secret shame of the industry. Given a choice, no one would want it to be this way. What is to be done? Computing professionals themselves should take responsibility for creating a positive user experience. Perhaps the most important conceptual move to be taken is to recognize the critical role of design, as a counterpart to programming, in the creation of computer artifacts. And the most important social evolution within the computing professions would be to create a role for the software designer as a champion of the user experience.

Kapor then goes on to make a brief but convincing case for design as part of the software development process. He defines the role of the Software Designer thus:

The software designer should be the person with overall responsibility for the conception and realization of the program.

But more importantly, Kapor outlines the skills and course of education likely to turn out people who could adequately fulfill this role. Let’s see what he recommended.

A software designer’s skill set

Kapor sets out a number of basic tenets for the training of software designers, which can be summarised as follows:

1. Their training should be distinct from that of computer science, software engineering, and computer programming professionals in that their focus must be on usability and users rather than technology and computing theory.
2. They should be trained in part through practice, in a studio environment, where they participate in directed projects to learn their profession.
3. They must master the field of human computer interaction and related social science research methods.
4. They must have a firm technical grounding to make them effective participants in the software development process and so that they will not risk losing the respect of technical colleagues for not understanding fundamental technical concepts.

We have been striving at work to do as good a job as possible to live up to points 1 to 3 in that list, and part of the reason I started discussion of prototyping is in an effort to advance our skills in regard to point 4 on Kapor’s training agenda. User experience design is a very new field, and practitioners have very diverse backgrounds, some with more technical understanding than others. I contend that one of the benefits of doing more prototyping is to increase this technical understanding.

To be an effective participant in the design of a web application without a good understanding of the fundamental principles of the technology is problematic, to say the least. Certainly, the developers who must implement your design will have less respect for both design and designer if they heard you confess that the learning curve of HTML and CSS is too steep. But prototyping is more than just an excuse to gain a good technical grounding, as Kapor also points out.

The importance of prototyping

No one, least of all Kapor, is advocating that the designer be able to write code professionally. That is not the focus of the designer, which should be on defining a good user experience. But in an interactive medium, words and static pictures are only going to take you so far. Kapor points to Architects, who create models of their buildings, because 2D plans are an inadequate medium to understand their designs. Software designers will need a similar tool:

In both architecture and software design it is necessary to provide the professional practitioner with a way to model the final result with far less effort than is required to build the final product. In each case specialized tools and techniques are used. In software design, unfortunately, design tools aren't sufficiently developed to be maximally useful.

The important phrase here is Far less effort, Kapor doesn’t envision a software designer opening a text editor at a blank file and starting to define variables, functions and data structures. He realised that for prototyping to make economic sense, it had to be quick and easy. Here’s how he saw it in 1990:

Hypercard, for instance, allows the ready simulation of the appearance of a program, but is not effective at modeling the behavior of real-world programs. It captures the surface, but not the semantics. For this, object-oriented approaches will do better, especially when there are plug-in libraries, or components, readily available that perform basic back-end functions. These might not have the performance or capacity of back ends embedded in commercial products, but will be more than adequate for prototyping purposes.

Behaviour, that’s the clincher. The effort to model web applications in static drawings can approach or surpass the effort required to create a prototype in code. As Jeffrey Zeldman said Wireframing Ajax is a bitch.

In the last few weeks, looking around for the right sort of tools for rapid prototyping, I came across the excellent work done on speeding up and simplifying the creation of CSS, HTML and Javascript in projects such as the YUI library, or the BlueprintCSS Framework, or the work on the Protoscript Javascript library. These are exactly the sorts of tools Kapor was talking about in 1990. All that’s missing is the will to learn to use them effectively. It’s time for those User Experience Professionals who don’t do markup to up their game, and I include myself in that number.