On 5-6 September my colleague Stephen and I attended the second CS Forum in London.

“Content strategy” is the latest buzz-phrase gaining traction in our industry, joining usability, information architecture, interaction design, user experience, accessibility and the like. As with the others, there is a great deal of overlap, but it’s a term I think will endure, as it gets to the nub of the biggest unsolved problem in web projects.

Put simply, it’s that content remains the weak link in most projects. Online content sucks much of the time. There’s too much uninteresting content, not enough useful content, and responsibility for creating and improving it is diffuse. Poor content often exposes the most convincing information architecture and wireframes as a fantasy of wishful thinking.

Content strategy brings out the pessimist in me. There are many reasons why it’s such a hard problem:

• Getting good quality content out of organisations that do not see themselves as publishers is like getting blood out of a stone.
• Most content strategy problems are human – political, organisational – on the client side; those you (as external agency/consultant) are least equipped to solve, often going beyond your remit.
• It’s always easier to make content strategy the client’s problem – you don’t want to accept responsibility for something that is so likely to go wrong.
• Well-structured content is a Good Thing, but the better structured your data (both information architecture and content types), the worse problems you face when the structure is no longer fit for purpose, and editors try to get around the structure you’ve imposed.

Conference themes

The following themes occurred repeatedly during the conference:

• We forget to consider the user experience of the content creators (usually in a CMS), in focusing on only the site users
• Fragmented organisational structures, e.g. lack of communication between developers, designers, copywriters and client
• Not knowing the CMS well enough, or choosing a CMS without consulting content creators
• Not learning the lessons of separating content from presentation – content should be produced from a “create once, publish anywhere” approach
• Lorem ipsum is a problem – it’s always better to design from the content out

The following are not so much summaries of all the talks I attended, as the most interesting things I took away from them. Some writeups are therefore much longer than others.

Gerry McGovern – Manage the tasks, not the content

Back in 2003, his books “Content Critical” and “The Web Content Style Guide” had a huge influence on me and helped guide the content strategy on Unilever.com, which I was working on at the time.

He reminded us that people go to website to do specific things on a website; any content that is not related to those essential tasks should be cut. He particularly dislikes marketing content. “Support is the new marketing”, he says, meaning that the “customer service” content should be the main focus of a site, rather than marketing content.

Avoid unhelpful navigational labels like “Articles” or “FAQs”, and link text should be written to make the keywords clear. (All principles familiar from information architecture best practices.)

Finally, Gerry made a plea for measuring content success, with the emphasis on useful metrics. Figures like visitor numbers, time on page, eye-tracking “fixation time” are all relatively useless – why do we assume that more = better? A/B testing yields more credible insights.

Melissa Rach – Content strategy methodology: a DIY project

Melissa talked about methodology – what strategists do – such as

• Create clarity
• Facilitate smart decisions
• Align stakeholders
• Help operationalize change

These steps have both content components and people components. But like many talks, it mainly deals with the what (none surprising), but not the how, which is where the the problems lie in my experience.

Margo Bloomstein – First things first: message matters

This talk recommended establishing a “message architecture” as a first step. Via card-sorting, help the client establish

• Who we are
• Who we’re not
• Who we’d like to be

…and tell the story of those aspirations. The message architecture drives the copywriting, the user experience and design, and becomes the benchmark by which to evaluate success later.

This is valid advice, but not always within my remit, and also not really where the worst problems originate.

Karen McGrane – The way forward: what’s next for content strategy

This gets my vote for the best talk of the conference, as it homes in on all the biggest problem areas. You can watch it on Vimeo

Problems usually don’t lie in technology, but in company structure. She describes her role as “corporate therapy”. Companies suffer from fragmentation:

• fragmented content management
• fragmented organisation structures
• fragmented devices and platforms

Content strategy – part of UX – should function as the bridge between marketing and technology. Content strategy is often about organisational change management.

Karen acknowledged to me in conversation afterwards that solutions to these problems are often out of your grasp and if she could do certain projects over again, she wouldn’t necessarily be able to prevent them.

The CMS – “the enterprise software that UX forgot” – is another major problem area. Why do we care more about the conversion funnel than the CMS workflow? Why do we care about the user experience of site visitors, but not editors? We need to work with the developers implementing the CMS from the beginning. And even before that, CMS procurement should be on the basis of usability – workflow that matches editors’ mental model – rather than feature checklists. A better CMS fosters better content.

As for the developing content for a fragmented landscape of devices and platforms, Karen compared the approaches of Condé Nast and NPR. Condé Nast’s strategy, by creating iPad apps for their magazines like Wired, is unsustainable. Ethan Marcotte: “Fragmenting content across ‘device-optimised’ experiences is a losing proposition” . By contrast, NPR pursued a “Create Once, Publish Anywhere” approach, by building an API that enables their content to be deployed in a multitude of contexts. This is why we need flexible, structured content, and why Ethan Resnick claimed “Metadata is the new art direction”.

These are all familiar principles to information architects, but as Karen said, Mobile is a great wedge to bring the argument up again.

Lisa Welchman – On All the Different “Web Governances” in the Universe

Governance refers to a policy and standards. Some key points:

• A policy that no-one knows exists, or reads, doesn’t exist
• Policy that you don’t have the authority to implement doesn’t make sense
• Don’t be a barrier to organisational change that needs to take place (I suspect this is aimed more at insiders than consultants)

Lisa then introduced the recently-formed Web Governance Journal.

Eric Reiss – Content strategists: the men and women of a new renaissance

Eric summed up the big problem I have with content strategy: “Strategy is easy. The rest is tactics.” We often know what needs to be done, but making it happen is where the problems lie.

Erin Kissane – Making sense of the (new) new content landscape

Erin invoked the old IA favourite, Christopher Alexander, who in his treatises on architecture described enduring patterns such as balance, interconnection and stability, and fundamental user needs that products are useful, accessible, findable, searchable, portable and usable in many ways.

We need to preserve the life of our strategic decisions to enhance the life of our visitors.

Des Traynor – The language of software: the role of content strategy in software development

Des talked about websites (or web applications) with strong social elements or user-generated content. In such cases, there may not be much content to begin with, but what we do control, is

• The user interface
• The blank slate (what users start with)
• The content definition

Thus “you get the content you deserve”.

1. User interface: “Language influences behaviour”. Consider the ramifications of labeling decisions like “tweet” (not share, update, set, publish, post…) or “like” (not love, or appreciate…) E.g you can “+1” something where “like” isn’t appropriate. The Zune’s coolest feature, instant sharing via wifi, was arguably killed at birth by the term “squirt”.
2. Blank slate: Consider the different quality of user-generated content on YouTube, Yahoo Answers, Quora, Get Satisfaction. By subtle elements in how they let you compose, the results can be idiotic or serious, disrespectful or civil. Google Wave undermined itself with unconvincing sample/seed content.
3. Content definition: Compare the quality of TripAdvisor reviews with those on the Apple app store (where ratings don’t differentiate between e.g. technical problems or product suitability.)

Des showed an example of a “microcopy framework” for an application. This is a spreadsheet containing all messages in the application, and their aims and expected tone of voice.

Content is “always an opportunity to delight your user”. +1

Richard Ingram – How did we all get here?

Richard revealed the results of several surveys on professionals who consider themselves content strategists, in the form of gratuitous infographics which you can view here.

His blog’s title is a veiled entreatment to abandon Lorem Ipsum.

Martin Belam (guardian.co.uk) @currybet – Content strategy for people who think they already have one

As expected, another stand-out talk, but probably one of the least applicable to me. Journalistic organisations tend not to have the CS problems I find most intractable (they actually have qualified writers and editors), although they have different problems relating to the business model – extracting the greatest value from content – and publishing across a ever-fragmenting landscape.

The Guardian is also an ideal organisation in many respects – doing their development in-house with good collaboration between editors (a fascinating story of “domain driven design” in itself), IAs and developers, and using a custom-built CMS that dispenses with a lot of complex workflow in favour of trust. Having a controlled taxonomy of keywords with a single manager is also something that on most projects I can but dream of.

In keeping with one of the main themes of the conference, Martin stressed the benefits of an API approach to deal with platform fragmentation – create once, publish anywhere.

I liked Martin’s advice to teach using a “portfolio of errors” – showing the mistakes others have made before, rather than criticising your colleagues’ efforts.

Martin ended with a healthy reminder for all “content strategists” not to forget their Information Architecture, and the decade-plus of prior art. (The vast majority of the conference would have sat comfortably under an IA banner.)

Sophie Dennis @sophiedennis – How web designers can stop worrying and learn to love content strategy

I enjoyed Sophie’s talk, which grappled with the all-too-familiar problem their own agency website, which no-one likes but never gets fixed. 

Sophie pointed out that “lorem ipsum” dummy text is specifically intended not to be read, hence it results in designs that are simply not reader-friendly, where the text is the least important component of the design.

When we start designing with real content, we become better designers. However, this is usually not realistic. The pressure to design first typically comes from clients – “I’ll know what to write when I see it”.

In response, Sophie proposed an agile approach, where neither comes first. For their own agency site redesign, she turned off CSS on the existing site and, working with the HTML rather than wireframes, started rewriting – this made it easy for everyone to focus on the content. Then, it became easy to start adding style and “grow the brand out from there”.

Sophie is also a fan of spreadsheets instead of tree-diagram sitemaps, as they are much better at communicating scope. Sitemaps can give a misleading mental model of the amount of content on a site. Spreadsheets are also more accessible and collaborative.

Kate Kenyon @kate_kenyon – Content strategy and CMSs

Valuable reminders never to ignore the CMS. As the content strategist, you need to own it, and understand the publishing process. Find out where it fits in the technical ecosystem. Ideally, the CMS should be procured from the user requirements of the editors.

Good reminders for me. For a long time I intentionally ignored the CMS, believing that it was my duty to focus on the user experience and not be “captured” by the tech constituent.

Cleve Gibbons @cleveg – Strategist and executioner

We’re used to doing “customer journeys”, Cleve said, but we hardly ever do “author journeys”. Optimise the author journey, focus on making authors proficient and productive.

More exhortations to bring technologists to the table when content management is discussed. Developers shouldn’t just “take the ticket and implement” something; they should ask “Why?” more often – what’s the aim of the requirement?

(I agree, from painful experience – many well-intentioned features I designed turned out, after implementation, to result in such editor overhead in the CMS that the features went unused.)

Lisa Moore @writebyteuk – Agile and Content Strategy

Lisa espoused Agile principles such as “putting deliverables on a diet” – keeping documentation to a minimum (I agree), developing early, and testing often.

The team structure she described had separate content strategists and copywriters – she recommends that these people should be involved in all meetings with IAs and developers. However, in most of my projects these don’t exist as separate roles.

Lisa also recommended using real content as far as possible in wireframes – besides benefiting design, another advantage is that it’s likely to be included in user tests.

Noz Urbina @nozurbina – B2B content strategy

Noz made a compelling case for replacing the traditional marketing content with customer service content – i.e. the stuff you usually got after the sale is then driving the sale (echoing Gerry McGovern from earlier.)

B2B (as opposed to B2C) compels you to focus on customer retention rather than acquisition.

Noz saw our role as “consultant within the enterprise” – that if everyone just stuck to the org chart, eventually it’ll be the customer who suffers.

A few weeks ago I watched a live web conference in which the open source Plone content management system was put through its paces by a blind person using a screen reader (JAWS). Two important issues stuck with me, since they affect most websites, are quite serious, but do not seem to be very widely known.

Popups are usually inaccessible

(Ticket 12123) Popups (by which I mean dynamic overlays rather than popup browser windows) are usually inaccessible. For example, in Plone the login button invoked a login form inside an overlay. Popups are also commonly used for modal dialogs. It is common practice to put popup DIVs at the end of the HTML body, but this means screen reader users are usually not aware of their appearance, nor have any way to get to their contents. (Especially if they do not contain forms; forms in popups are still accessible via JAWS “forms mode”.)

There are two alternative solutions:

• The trigger element should have an anchor link to the popup contents.
• The popup should be inserted in the markup immediately after the trigger element.

Both have some associated problems, but I prefer the first solution and will try to implement it in future.

Form field help should be part of the label

(Ticket 7212) In the commonly-used “forms mode” in JAWS, the screen reader reads only labels, legends, input fields, select fields and textarea fields, but no other elements in the form, such as paragraphs, DIVs, etc. That means any help text (usually positioned below or alongside the field) is ignored. This also applies to validation error messages.

The recommendation is to include the help text inside the LABEL element, and use CSS positioning to put it in the right place in the layout. (I can see how this can cause problems where the text should appear above or below fields.)

Update: Here’s an example (see also the ARIA enhancements, not quite reliable cross-platform according to the associated Alistapart article)

Update 19/10/2011: This article recommends the use of aria-describedby for both help text and validation message. It advocates telling users of non-ARIA supporting screen readers to upgrade (but claims that JAWS has supported it since version 10 in 2008)

It was good to see a content management system take accessibility so seriously. Here are some more tickets.

Thoroughly enjoyed UX Lisbon, organised by ideas e imagens. I don’t think I’ve ever been at a conference where I didn’t regret a single session.

These notes are not necessarily complete summaries of the sessions; they focus on the aspects I found most noteworthy.

1. Prototyping with HTML5 – Todd Zaki Warfel

@zakiwarfel | Slides

Probably the workshop in which I learned least, as Zaki Warfel effectively described exactly the way I currently prototype, and for the same reasons. But was good to have this reinforced.

With all prototypes, including wireframes, set expectations with the client. Choose the level of visual and functional fidelity the project requires. I tend to choose HTML prototypes when I require a high level of functional fidelity, when I don’t know whether an interface works until I can use it.

HTML prototypes have many advantages:

• closest to final delivery environment
• browsers & text editors are ubiquitous – fewer things that can go wrong
• my favourite: producing production-quality HTML for the prototype can shave 30-40% off production time. (This divided attendees as some considered it too high a hurdle. But aligns with my belief that well-structured semantic HTML is akin to IA and the IA is best placed to write it)

HTML + JavaScript is also more capable than any GUI prototyping tool like Axure. But remember, it is still more constrained than a sketch or a wireframe. When you are sketching you can invent things; you’re not constrained by the familiar toolset.

Zaki Warfel stressed the advantages of HTML5, but I came away still unconvinced of any real benefits for prototypes. Only new HTML5 form attributes (date, email, tel, url, placeholder, etc) are a no-brainer if you want to improve usability in iPhones.

In the tricky choice between HTML5‘s <section> and <article> elements, he suggested thinking of using <article> for things that you can imagine going into an RSS feed. But just “choose one road and don’t look back”. (I also find this very confusing, and agree with Jeremy Keith that article and section should be merged into a single element.)

To make HTML5 compatible with older browsers, Zaki Warfel recommended html5shiv instead of modernizr, to keep your HTML cleaner.

CSS3 he didn’t have to sell to me. I already know it saves major time not doing sliding doors or image-based corners, shadows or gradients. But note you have to go back later to fix for IE (or convince the client to accept visual compromises in IE, as Zaki Warfel, echoing Zeldman, advised.)

CSS3 selectors are also a huge time saver in prototyping, but (in my opinion) they will usually require extensive refactoring for IE later.

Zaki Warfel recommended using include files for repeated elements in your HTML, using PHP (already installed in OS X). At first I thought this was unnecessary, but then remembered that in later stages of prototyping I tend to do a lot of difficult find/replace operations across files. So I definitely want to try this in future.

Finally, Zaki Warfel demonstrated the magic of jQuery. I’ve only recently started learning it, and I think every interaction designer should. I use it for all show/hide, open/close, expand/contract, highlight, popup, etc. behaviours in HTML prototypes, and it is a pleasure being able to do this as easily as CSS.

2. Skeuomorphs: The Good, The Bad, and the Silly – Andrew Watterson

@andrewwatterson | Also summarised on Johnny Holland

Skeuomorphs refer to physical metaphors to ease transition to new technologies (mostly touch interfaces in this talk). Explicitly recommended in Apple’s HIG. Criticised by Adam Greenfield “patronizing crutches” and (implicitly) by Jakob Nielsen “Users don’t know where they can click.”

Skeuomorphs can be good:

• They deemphasise technology in favour of utility (cf. Apple’s ads which suggest familiar usage contexts for new technology, vs. Android’s science-fiction approach.)
• They can reassure and please, bridge gaps, ease transition. He paraphrases Don Norman’s adage that users have 2 needs, (1) to get something done, and (2) to smile.

But skeuomorphs can cause lots of problems (interestingly, most of the worst culprits are Apple apps)

• They can mislead with inappropriate metaphors (Apple Calendar and Contacts on iPad have scrollable areas, concealed by the fact that they look like paper; Contacts has a “Groups” icon that looks like a bookmark but is actually a button; the Apple Sound Recorder shows a realistic microphone that conceals the location of the device’s actual microphone)
• They can cause you to skip opportunities to innovate, preventing you from improving on existing tech (e.g. Apple’s Compass app, which has no more utility than a mechanical one, compared with AR Compass which uses augmented reality to give a far more useful view.)

Watterson didn’t even talk about Apple’s egregious Game Center, which boasts the worst skeuomorphic interface I’ve ever seen.

3. Serendipity: Beyond Recommendation – Pedro Fernandes

@betasolo

In Fernandes’ talk, serendipity refers to fortunate discoveries while looking for something unrelated.

The essence of his argument was that existing recommendation engines frequently resemble echo chambers, limited by their algorithms or the metadata they depend on. If item A always recommends items B and C, and items B and C recommend A/C and A/B respectively, then you’ll never discover items D or Z.

In e-commerce this can undermine “long tail” sales, but in social networking it can result in “cultural tribalism”, online spaces that just reinforce your preferred world view.

Fernandes showed two apps that try to inject more serendipity into the user journey: mowid.com for browsing films, and Serendipicity, a mobile app for tourists. Mowid relies heavily on tag-based browsing, drawn from a rich vocabulary of tags, and Serendipicity lets you explore places primarily via photos (inherently more open to interpretation) taken in the vicinity by other users.

While I agree about the central issue, I was a bit skeptical about both apps.

Designing for Touch – Josh Clark

@globalmoxie

Definitely one of the conference highlights (all the way from the Johnny Cash opening music). Clark proved himself a consummate educator, fitting in so much detailed, actionable information and examples that the fact it was a presentation rather than a workshop didn’t matter.

When designing for mobile devices, forget pixels: think of it as designing a physical device. It’s more like industrial design.

Many design rules follow directly from physical limitations. On small touchscreen devices, follow the rule of controls at bottom, content at top – so that content is not obscured by “meat sticks”. For the same reason, two rows of buttons at the bottom is also not ideal, something which Android is unfortunately stuck with.

Bottom-left is the top spot – for right-handed users at least, which is what you should optimise for. But consider offering a setting for the 10-15% of users who are left-handed.

Because it’s difficult to fix buttons at the bottom of the screen using JavaScript, he suggested a design pattern for web apps where the main menu is always presented at the bottom of the content, but with a “menu” anchor link at the top of the page.

For the iPad / tablets, rules are different. There are many ways to use them, and many use contexts, with no clear preference for portrait or landscape. It is therefore harder to predict hand positioning. Top-of-screen controls are better, to avoid controls at the bottom sinking into your belly

The Instapaper app, with its controls in the top two corners, was praised, and The Daily, where using the page scrubber at the top obscures the thumbnail images just below it, was criticised.

What is the optimal size for a button? The answer turns out to be 44 pixels high (29 wide). This happens to be (no coincidence) the height of the iPhone menu bars, buttons, and keys on the virtual keyboard.

But what is a pixel? Due to differing pixel densities, we should stop thinking of device pixels, and think rather of a physical measure on screen. This is called

• iOS: points
• CSS: pixel (which is device-independent)
• Android: density-independent pixel (dp)

So if you continue to use the px unit in CSS, it automatically does the right thing. However, you need to start producing both a normal and high-density version of all images, e.g. image.png and image@2x.png
This is easy enough to apply using the IMG element, but for CSS background images you have to specify the higher-density image thus

@media -webkit-min-device-pixel-ratio:2 {
		.class { background-image: image@2x.png;
		         background-size: 50%;
		}
	}

It’s not just about size, though, but also spacing: the closer together, the bigger buttons need to be. A useful tip is to invisibly increase the hit area for small elements (Remember the Milk does this for checkboxes.)

You can also use animation to draw attention to or explain buttons or other elements that might otherwise be missed or misunderstood. For example, slide in a menu that can be swiped, or pop up the primary action button (Gowalla does this.)

Single-screen interfaces (utility apps) strengthen the illusion that it is a physical device. They should pass the “glance test” – right information hierarchy at arms’ length. Two examples: Tea Round and Umbrella Today. Strip out everything not needed when rushed and distracted. Clarity trumps Density (of features).

But mobile devices are not always used when rushed and distracted! People don’t want “dumbed down”. People want uncomplicated. Full-featured, just lighter interface. (Story of initial Facebook app which was billed as a companion app, which users rejected because they expected to be able to do everything they could do on the website.) Some mobile apps need to do more than the desktop versions.

Don’t fear extra taps! Web has made us squeamish about number of clicks. Latency not an issue in a native/cached app. Tap quality* trumps tap quantity (*unconfusing)

Similarly, don’t fear scrolling. E.g. USA Today used an accordion interface to avoid a long list of headlines scrolling, but not all users understood it. For long lists of content, scrolling is still better.

Changing orientation: think of it not just as a change in layout, but also a change in mindset. Landscape mode can also be seen as “focused mode”. But beware of depending on it, as it is hard to discover. (Personally, I believe orientation in iOS is flawed, invoked overwhelmingly by accident. I think Ben Summers has the right idea for how it should work.)

Affordances: gestures are the keyboard shortcuts of touch interfaces, they can be hard for users to discover. Shortcuts need backup plans – never rely on all users discovering them.

When you see your app being used, look for unsuccessful gesture attempts and repetitive interactions, and pave the cowpaths. (Have Apple never seen users try to swipe the Calendar app to change day?)

Multi-touch (on phones, not iPad) and the shake gesture generally considered bad.

Don’t get carried away with an impressive, glitzy interface. Showcase the content, not the form. Don’t underestimate the power of the humdrum and familiar – see NY Times and Flipboard apps. Similarly, skeuomorphs, while still window-dressing, can enhance a design; familiarity and intimacy invite touch. But if you’re aping a physical object, choose the right metaphor.

But try to avoid buttons altogether. Buttons are a hack. Look at how a toddler uses an iPhone/iPad – they try to interact directly with the content. Wherever possible, make the content the interface. (Example: see how Twitter for iPad eliminated the Back button.)

Clark signed off on an optimistic note, and an encouragement to experiment: new platforms don’t appear very often. This is the coolest job in the world.

One of my favourite talks at UX London 2010 was Stephen Anderson’s Seductive Interactions – using basic psychological principles to bridge the gap between business goals and users’ behavioural goals. Usability alone, he argues, often merely decreases friction. Using psychology can also increase users’ motivation.

At UXLx, the recent UX conference in Lisbon, I attended Anderson’s workshop on the same topic. By luck, our exercises focused on improving one of my great bugbears, time tracking. And not just any time tracker: Harvest, which we use at Isotoma.

Don’t get me wrong: Harvest is by a long stretch the best time tracker I’ve used. But nevertheless, it remains an activity I hate and avoid, and routinely fill in my time weeks late.

Applying typical utilitarian thinking would result in improvements like –

• Increasing the font sizes in Day view
• Week view should highlight active rows and columns, and keep column headers and footers visible when scrolling

– helpful, but unlikely to change my attitude or behaviour.

In the workshop we used Anderson’s “Mental Notes”, each of which describe a psychological principle designers can take advantage of, and used them to generate ideas to improve Harvest. Here are the relevant notes, and what we came up with:

Trigger / Recognition Over Recall / Feedback Loops

The application should listen and learn from your actions. Just like a good online supermarket will make it easy to re-order the things you frequently buy, Harvest should always automatically show the jobs you worked on previously.

It should also trigger you to take action. At the end of each day, it should pop up a form: “Did you work on these jobs today?” containing only the jobs you had put time on the day before.

A frequent problem is that a job might not exist in the system yet, because a project manager hasn’t created it, or hasn’t added you to it.

Firstly, in the Day and Week views, you should see all the jobs you’ve been added to, not only the ones you’ve chosen to show. (The dropdown menu to add jobs is a terrible interface.)

Secondly, you should be able to create “placeholder” jobs and assign times to them, which you can later reconcile with an actual job. Placeholder times will be used in your own totals, but not in project managers’ reports.

Status / Achievements / Competition / Appropriate Challenges

Anderson showed the example of Target’s supermarket checkout interface, which uses a game-like system to encourage cashiers to work more quickly (photo).

Similar principles can be used to encourage workers to fill their timesheets in sooner. Harvest should track how long, on average, it takes you to fill in your timesheet (same day, 1 day late, 7 days late, etc.) This should be shown to you as a chart over time, so you can see your average and your trend.

Then it should also show you the same timeliness charts for your colleagues, and where you rank (without names, as no-one would appreciate the feeling of being singled out.) This will act as a subtle but powerful spur to improve your timeliness. The company can also offer rewards for the most timely, or the greatest improvement.

Set Completion

Highlight it when a day totals up to 7.5h or more (or whatever your daily goal is). Completed days should stand out clearly on the Week view and reports. And how about a “Well done!” whenever you complete a day?

Another example: 750 Words encourages writers to stick to a writing schedule by writing only 750 words a day, checking off a box when they’ve done so. (See screenshot here.)

Delighters / Surprise / Humor Effect / Visual Imagery / Self Expression

In a different UXLx talk, Andrew Watterson paraphrased usability pope Don Norman’s adage that users have 2 basic needs: (1) to get something done, and (2) to smile. Adding a touch of humour to an application can go a long way towards making it more pleasurable to use and memorable.

This is why our own Forkd.com uses tomatoes instead of asterisks on forms, amongst many other touches, and I’ve lost count of the number of people who have commented on that.

Some ideas that cropped up here were for the application to offer occasional comments and quips, e.g. advising users to mind their posture, or go for a walk now and then, or pep talk suggesting how hard-working they are. Ex-colleague Jonathan Baker-Bates designed a custom-built time tracker that allowed employees to add their own quips, which rapidly became an impromptu means of humourous communication and teasing within the company (like the #isotoma IRC channel’s notorious topics, I imagine.)

Another ex-colleague, Karl Sabino and I came up with the idea of adding “themes” to the time entry interface. Instead of the current businesslike grey-and-orange, you could fill in your times on something resembling a ticking bomb, or a Superbowl scoreboard, or an Indian restaurant menu. To our surprise, it turned out that Dominos Pizza already had this idea on their patented Pizza Tracker:

Many customers found this amusing enough to post videos of it on YouTube.

So there you have it: a fresh approach to a design problem that yielded many results I doubt I’d have come up with otherwise. When I tweeted about the workshop, Harvest immediately responded with interest. I hope you like the results! (And my employers will thank you if you can somehow improve my terrible timesheet habits.)

I’d like to acknowledge the input of Karl Sabino and Jonathan Baker-Bates in several of the ideas above.

Wow, my last post became obsolete fast. Good to know that the talented designers at Twitter have indeed been working on a root-and-branch revamp of Twitter.com all this time. Sorry if I cast aspersions that you weren’t! Let’s see how they fared against my wishlist:

1. How is “Profile” a suitable label for your Twitter stream?
Well, you still have to click Profile to see your tweets. But they’re clearly titled “Timeline” now, and this is not the only way to get to it.
The tab is also highlighted when selected.
Score: 7/10

2. Why is there not a decent Profile page?
We still don’t have detailed Profile pages, with more than 140 characters and 1 link, and room for more personal information, account statistics and analysis. Curious to know the rationale for this.
Score: 0/10

3. Why on earth is there only a Tweet box at the top of the Home page?
and
4. As soon as you scroll down, you lose the Tweet box.
These problems have been fixed 100%. Not only is the box above both Home and Profile, but there at any point you can invoke a floating, repositionable tweet box from the button in the header.
Score: 10/10, 10/10

5. Inconsistency in the right-hand navigation between the Home page and the Profile page.
Well, the right-hand navigation has been completely changed. These links are now tabs on the Home and Profile pages respectively, and differ between these two pages. At least some thought appears to have gone into which tabs are shown. Would have to see if I find them intuitive. I may still end up wondering how to get to @Mentions while on the Profile page, or where to find things I’ve retweeted. Messages are in a more appropriate location, well separated, in the header.
Score: will have to see.

6. The Home right-hand navigation area is also polluted by, essentially, promotions
They have now been clearly separated from your content, and no longer pushing some of it down. Still occupies a lot of prime real estate, though.
Score: 8/10

7. The right-hand navigation could generally be used a lot better.
OK, still can’t browse my hashtags. And don’t have totals for @Mentions or Retweets, but that’s not really important. The search box is now in a sensible place, in the header. And they’ve done plenty of other useful things with the right-hand column.
Score: 8/10

8. Only when you’re on the Home page (twitter.com) can you easily see who you’re signed in as
Fixed. This is now in a sensible place, top right.
Score: 10/10

9. Twitter.com does a terrible job of showing you recent activity.
Still terrible. Still no alert for an @Mention. Not even a new DM is highlighted in any way.
Score: 0/10

10. Inability to Search inside your own Twitter stream, or inside someone else’s.
No change here, by the looks of it.
Score: 0/10

11. When you look at your, or someone else’s Profile, Twitter could display much, much more useful information.
Besides room for more personal information, I was hoping for statistics and analysis, such as tweet frequency and tweet type ratios, frequently-used hashtags, time on Twitter, etc. No change here either.
Score: 0/10

12. The “More” page-down experience is atrocious.
OK, AJAX (sort of) to the rescue. The new “infinite scroll” is very impressive and (in my tests) super-fast. However, it still does not allow me to easily make big leaps into the past, the way paging links would’ve. When you navigate away, and click Back, you’re also not (instantly) back to where you were, although it tries to do so and catches up after a few seconds.
Score: 6/10

13. The display of user lists is bad, both in the mini form (avatars in the right-hand column) and the full page listings.
This is also improved by the AJAX infinite scroll, and the layout is improved, but still no sorting, or searching for a name within a list of contacts. Also, the experience of mousing over mini-avatars to see names hasn’t been improved.
Score: 3/10

14. Automatically hyperlink a Tweet ID.
Unsurprisingly, no. (I’d be curious to know whether this is feasible, incidentally.)
Score: 0/10

So, in total, of my 14 criticisms, 7 were completely or mostly corrected, and 6 only imperfectly or not at all. One still needs further testing.

My analysis above looks only at the points I raised in my previous post, and does not take into account the smart new layout and many new features, some of them quite wonderful. I especially like the photos, videos and conversations in the new right-hand pane. (Although the pane often seems to be filled up with not-really-relevant stuff just because there’s room.) I want to experience the beta a bit longer to get a feel for everything that’s new.

Since I’m always complaining about Twitter.com, it’s just fair for me to list what I think is wrong with it and how it should be improved. Please note: I’m only criticising the Twitter.com website, not the service itself or any other Twitter client.

1. How is “Profile” a suitable label for your Twitter stream? Can you imagine someone talking about their “profile” on Twitter, when they mean their updates? Making it even more confusing, this menu item is not even highlighted after it’s selected.

2. For that matter, why is there not a decent Profile page? (In the normal social networking sense of the word.) Tweets are restricted to 140 characters for a good reason; there is no reason to have only a 140 character bio and a single link.

3. Why on earth is there only a Tweet box at the top of the Home page? At the very least, there should be one on the Profile page. Really, you should be able to tweet from any page on Twitter.com.

4. As soon as you scroll down, you lose the Tweet box. So if an update lower down on the page spurred you to write, or if you click Reply, bad luck: you have to lose it from sight in order to write.

5. Look at the inconsistency in the right-hand navigation between the Home page and the Profile page. Home has @replies, DMs, Favorites and Retweets (itself a disaster). Profile has Tweets and Favorites only. Is there any reason for them to be different on your own Profile? (On someone else’s Profile it will be Tweets and Favorites only, of course.) I’ve often been confused at the disappearance of, say, @replies, only to realise it’s because I’m on the Profile, rather than the Home page.

6. The Home right-hand navigation area is also polluted by, essentially, promotions, such as “Who to follow” and “Trending”. They are not visually distinguished from real navigation.

7. The right-hand navigation could generally be a lot better. Why not have the hashtags you’ve used, since they’re effectively a way of categorising your tweets? Why not display the total numbers of @replies, Favorites and Retweets (as for DMs)? The Search box is in a silly place, and being directly below your navigation links, implies it’s searching your tweets, not all tweets.

8. Only when you’re on the Home page (twitter.com) can you easily see who you’re signed in as (badge at top right). On the Profile page, only the “That’s you!” under the photo at the top tells you. On other pages, nothing tells you. In a household with multiple Twitter accounts, this is rather frustrating.

9. Twitter.com does a terrible job of showing you recent activity. When you log in to Twitter, you expect bright highlights alerting you of new @replies, if one of your tweets was favorited or retweeted, or if you have new DMs. When done right, this really boosts addictiveness: Facebook and Flickr are just two examples.

10. The inability to Search inside your own Twitter stream, or inside someone else’s, is simply crippling. I assume that this is a technical limitation due to Twitter’s scale, but it should be a top priority. If Google had bought Twitter, I imagine this would’ve been the first thing they’d fix.

11. When you look at someone else’s Profile, Twitter could display much, much more useful information. (Having a real Profile page would help.) Basically, the sort of information that 3rd-party services like MrTweet offers: their tweet frequency, how long they’ve been on Twitter, the nature of their Twitter usage (ratio of posts with links, ratio of posts that are @replies, recurrent hashtags, etc.)

On your own Profile, you’d want to see statistics. Number of views of your stream, number of favourites and retweets, ideally graphed over time (like Flickr does it).

12. The “More” page-down experience is atrocious. It’s slow, you can’t skip by more than a page at a time, so if you want to go back a few days it takes forever. And if you navigate away, and click Back, the entire stream is gone again. Presumably this is another technical limitation.

Ideally, I want actual paging links like on Flickr or Vimeo. (Only for a single person’s stream, not the firehose.)

13. The display of user lists is bad, both in the mini form (avatars in the right-hand column) and the full page listings.

On the mini version, relying on tooltips or the browser status bar to read a person’s name is very user-unfriendly. You want to scrub your mouse over the avatars and easily read the names as you do so.

On the full-page versions, where is the paging? Like the Twitter stream, there’s only a “Next” link. How are you expected to navigate through more than a 100 people? They are in no discernable order, and there’s no ability to order them by username, first or last name, or search within the list (like Facebook).

14. An obvious, if geeky, enhancement: automatically hyperlink a Tweet ID. Currently if you want to link to another tweet, you have to use an URL shortener. (A tweet ID is 9 characters shorter than a bit.ly link.)

And here are just some shortcomings that were fixed scandalously late:

• Native URL shortening
• The Follow button used to be a gear for ages
• Emails alerting you to new followers contained no useful info (the follower’s bio was just added a few weeks ago)

I understand Twitter is focusing on growth, and many shortcomings are unavoidable results of its scale (such as Search and proper paging), but they cannot afford to lose sight of the user experience. But mostly I can’t understand how the remarkably talented UX folks they’ve been hiring — people like Kevin Cheng and Doug Bowman — can allow these problems to persist for so long. (While simultaneously rolling out unimpressive features like the infernal hovercards and “Who to follow”.)

Perhaps Twitter’s attitude is to focus on the API, and leave the user experience to third-party services and Twitter clients. That would be a pity: it’s a jungle out there if you’re looking for decent Twitter services. For every decent 3rd-party service or client there’s a plethora of ones that are ramshackle, spammy or downright malware. I also find this explanation implausible, given their investment in UX design talent.