Cognitive Friction

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.

The excellent Luke Wroblewski is currently writing a book called Web Form Design Best Practices for Rosenfeld Media. I’m really looking forward to reading it, and so I was interested to see Luke’s blog post on Zip codes and locations. Having read it, I hope that Luke remembers in his book that not everyone lives in the States, and that many people have no postcode of any sort at all.

This is a bugbear of mine, because I live in Ireland, in County Dublin, just outside the only city in the state that has any sort of post code system. In urban Dublin, the city is divided up into areas labelled D1, D2, D3 and so on. All of the even numbers are on the south side, all of the odd ones on the north side. In Northern Ireland, still part of the UK, the excellent British post code system is in place, which assigns a seven-letter code to groups of no more than 25 street addresses. Everywhere else on the island, though, there is no postcode system at all. Indeed, in rural areas, addresses look positively inadequate, like this:

If you look for Cornaglea on Google maps, you’ll just see a road running through a big blank area of map. It’s farmland. There may be 3 or 4 houses scattered around the area. How do you find such an address if you are driving? How do you deliver mail there if you are a delivery driver? Well, you either know your way there, or you don’t. If you don’t, you ask directions. Now, let’s get back to web forms, and eCommerce in particular.

It drives me nuts when forms require either a ZIP code or a postal code and call me out with an error message if I don’t provide one. I don’t have one to provide! Worse, some forms even try to ‘validate’ whatever I type as a workaround (usually a hyphen) and inform me that my postcode is in error because it must contain only alphanumeric characters. Says who? Don’t these people know the Internet is available all over the planet? I shop online a lot, and have for years, and I still email the owners of forms with this irritating characteristic every time I come across it. It’s so easy to fix this, especially when your form knows which country I am in.

All of this is to say nothing of French or Italian street addresses, where the door number may come at the end of the first address line, not the start. And let’s not even venture into Asia at all. But Luke, please tell me you have a section in your book on international addresses, calling attention to the wide world of sports outside of the USA. Please tell me it is so. Because people will read your book, they will learn, and in some small number of cases, they’ll take the trouble to do this address thing well. And who knows how far best practice may spread from there, as those who couldn’t care less simply copy forms from some other site.

The real joy of owning a Mac is having access to some of the best-designed software on the planet. I’m thinking principally of the products of small software vendors, such as The Omni Group, or even the work of micro-ISVs. These developers bring real passion to their work, turning out elegant designs that can be sheer bliss to use. Yesterday, I found another of these Mac software gems in the shape of Scrivener, which I can best describe as an IDE for writers.

What is Scrivener?

Scrivener is the product of one man, Keith Blount, a teacher, writer and Mac software developer. Keith, if you are reading this, thank you; Scrivener is just what I was looking for. What’s so good about it? Well, I have always wanted an application that does a number of things for me when I’m researching or writing, Scrivener is the first application that I have found that offers all of these things in a form I feel I can work with. Here's my wish list:

• A writing environment that allows me to focus on just the words when I am trying to write.
• An outliner, that enables me to sketch in the parts of a text, move them around at will, and get a useful overview of the whole thing.
• A way to collect and organise research materials, annotations and references from all kinds of sources in all kinds of formats, and associate them closely with the document.
• A way to create a document as separate chapters, sections or whatever, assembling them all into a complete document when I need to. Back in my tech writing days, Adobe FrameMaker gave me this capability and I miss it when writing long documents.

These are the main things, although I’ve seen many more features in various applications over the years that are also on my wish list. I’ve tried to find these features in other applications, in fact I have a collection of partly satisfactory solutions in my Applications folder.

My long search for the right writing environment

I have been looking for something like Scrivener for a long time. As a result, I have a collection of Mac software that at one time or other served as my mainstay for fact collecting, note making and writing. For example:

• OmniOutliner Professional: Great for taking notes and outlining text, but I find I use it for little else, despite its great potential. I'm not sure why.
• DEVONThink: which promised to be my paperless office, but never won my heart.
• NoteBook: I use this a lot as a project notebook and scrap book, but I don’t like it so well for writing, especially writing long documents.

This is to say nothing of the many other applications that I have coveted, but managed to resist buying so far, such as Yojimbo or Curio.

How Scrivener meets my needs

When I stumbled across Scrivener yesterday, therefore, I was intrigued but a little skeptical. It promised much, but I wasn’t sure what it would be like to use. So I downloaded the demo and gave it a go. Scrivener made immediate sense to me as I worked through the included tutorial. Within an hour of installing the thirty-day demo, I had purchased a license. Here’s how the key features tick all of the boxes in my wish list:

• Scrivener’s full-screen mode is not unique, but is very nicely implemented. When all you want to do is write, this strips away all distractions.
• Not only does Scrivener include a useful outliner, it also provides a view of your document as index cards pinned to a virtual cork board. I have read of people outlining documents with index cards, I’m not sure how much I will use this, but it is a very interesting approach.
• Scrivener organises your project in a virtual binder, which includes the various documents in your draft as well as a research folder. This enables you to store almost any research document, image or web clipping as part of the project. Add to this an annotation feature and a way to link to referenced documents in your draft and you have a very well integrated writing environment.
• Your draft folder contains as many text documents as you require for your draft, one per chapter, section, scene or whatever division you use. These can be combined and viewed dynamically while editing, and when it comes time to output a draft, you have fine control over what’s included and what format is produced.

There are many more excellent features in Scrivener, but best of all the whole thing comes wrapped in a very well designed user experience. Keith Blount created Scrivener principally because he wanted to use it himself, and the consequent attention to detail shines through.

Scrivener isn’t meant to replace all of your other writing tools. For instance, you wouldn’t use it to create a blog post or knock out a couple of pages of text. But when writing long documents, were project management, research and writing all come into play, Scrivener seems ideal.

Don’t take my word for it

If you write on the Mac, you owe it to yourself to check out Scrivener. There is an excellent overview of the features of Scrivener on Keith's website, Literature & Latte. Even better, Keith has created a very good screencast demonstration of Scrivener, which provides a clear impression of the application in use. As I said, there's a thirty-day demo of Scrivener available for download too, so you can give it a whirl, gratis. Best of all, if you decide to buy, Scrivener is only thirty forty dollars. At that price, what’s not to like?

This morning, I am bunking off work for a few hours to come and see Joel Spolsky’s talk on the Irish leg of his Fogbugz world tour. I’m looking forward to hearing a little more about the FogBugz product, although to be honest, I’m much more interested in hearing him talk about software process management and some of the other topics he covers on his blog and in his books. I considered live blogging the event, but it’s much more likely I’ll just post an update later on.

Update

So I enjoyed the FogBugz event, but not as much as I thought, and not in the way I thought I might. Here’s the story.

Joel started his demo of FogBugz 6.0 and did a great job of showing off the software. He seems like a nice guy, a good speaker with a good sense of humour. I have to admit that I didn’t know a lot about FogBugz, I last looked at it quite a few versions ago when I recall that it was not available as a service and available only on the Windows/IIS platform. It has come on leaps and bounds, and I have to say I was mightily impressed. Stand out features:

• The Wiki, for creating specifications in Fogbugz, with a very nicely done WYSIWYG editing bar.
• Evidence Based Scheduling, which enables you to calculate the probable ship date for individual developers based on past estimates. You have to see this work to see the benefits.
• The ability to take and post a screenshot with a bug report in a few clicks. Simple, but a real timesaving feature.

The best feature for me was, of course, the UI, which had some really nice features and fantastic attention to detail, for example:

• If you type Next Monday in a date field, it will resolve to a properly formatted calendar date.
• Switching to use the shortcut keys will overlay the appropriate keystroke on all of the buttons and links.
• Context awareness, exactly the right options are available to users depending on their task. The developers of this software clearly use it themselves.

So what was not to like? Well I was a little disappointed that the questions from the floor didn’t draw out Joel’s opinions on Software development and the industry in general. We did get a few fascinating anecdotes, such as why the MS Project development team don’t think it wise to use MS Project to plan and manage the development of the product; or why there are few true dependencies in a software development project, even though project management tools encourage users to create lots of them in Gantt Charts.

I could have asked a few questions myself, I suppose, but I felt a lot of pressure in the room to stay focused on questions about what FogBugz could or could not do. Maybe I was wrong, but that’s how it felt. There was a chance to talk to Joel and his business partner Michael after the demo, but I had to run off to a meeting with a client. Anyway, it was good to see Joel speak and to see what a great job Fog Creek has done with FogBugz, even if I didn’t get as much of Joel’s insight into the business of software as I would have liked.

Technorati Tags: Dublin, FogBugz, Joel Spolsky