I’ve established a web design agency called Together London, based in Soho, London.
From the site:
Our approach to web design is user-centred, collaborative and strategically focused—resulting in a website that achieves the aims of your organisation, is easy to maintain, and offers a pleasurable user experience.
Read more on the Together website.
In the autumn of 2006 I spent a month travelling in Vietnam. Riding a taxi into town from the airport in Ho Chi Minh City, I noticed several fancy billboards, featuring soft-focus photography and slick English slogans, advertising the brands of large foreign corporations. They seemed out of place, like an Armani suit in a student common room — and I realised that the airport road was the only place in the country where I’d seen this type of fluffy marketing. Elsewhere, where I’d seen billboards at all, they looked less polished, they marketed specific products, and they used the local language, Vietnamese.
So why were these masterpieces of advertising guff reserved for the airport road? The answer was obvious. I’d assumed that the billboards were aimed at the companies’ customers — the people who bought their products — but they weren’t. Their audience was the people who pay the advertising agencies’ bills: company executives, and ultimately the CEO. These people aren’t likely to see much of a country — they’ll fly in, take a car to their hotel, and perhaps attend a conference, or tour the company’s facilities. Amid all the rush of a whistle-stop tour, they might assume that the whole country is plastered with billboards just like the ones on the airport road — and that therefore, the great international branding strategy is working exactly to plan.
The billboards in HCMC were an example of flattery masquerading as marketing — a corporation paying an advertising agency to make executives feel good about themselves. This isn’t necessarily a terrible thing — many corporations can afford it, and a few fluffy posters and magazine ads don’t do any harm. But on the web, designing to flatter the CEO leads to disaster.
I use the term “ego marketing” to describe inward-focused, self-congratulatory marketing that takes an organisation-centred viewpoint rather than a user-centred one. With the exception of sites that aren’t supposed to be communicative, like vanity sites, ego marketing doesn’t work on the web.
The client will ultimately judge the success of a website project by user feedback and results, not personal aesthetics or preferences. Ego marketing annoys users and weakens the site’s message, so any use of it will tend to work to your disadvantage, negatively impacting the client’s judgement of success. What’s more, the client will expect you to have thought this way from the start, even if he or she didn’t, because you’re the web professional. Don’t design for the CEO — he won’t thank you for it.
During the web design process, it’s tempting to give in to clients’ personal aesthetic tastes, naive preferences, and ignorant prejudices, instead of challenging them to think from their audience’s point of view. For example, a client might ask for a colour scheme that he personally likes, an information architecture that fits his internal view of the company, or a crowded, cluttered layout because he “doesn’t like vertical scrolling”.
Paul Boag proposes some useful methods to deal with these unhelpful requests in “10 Ways To Get Design Approval” — particularly relevant are “define the role of the client and designer” and “control the feedback”.
Design agencies get their income from clients, and so tend to be over-sensitive about doing exactly what the client asks for. Whether or not your boss is looking over your shoulder, muttering, “she pays the bills!”, there’s often pressure to do whatever the client seems to be asking for — even if it’s a stupid idea, and you know it isn’t what she actually needs. To make it worse, clients and co-workers are often accustomed to less user-centred fields, and so genuinely expect websites to be designed for the client.
Visualising how abstract concepts will work in real, living websites is notoriously difficult, especially for those unfamiliar with web design — which makes unworkable or inappropriate requests common. Processes like wireframing and prototyping help to mitigate this problem, but they don’t remove it.
Technically, the client pays the bills. But figuratively, the users pay — because if you don’t design with users in mind, they’ll be turned off, and eventually you’ll lose the client.
Although it might not seem like it at the beginning, the CEO will judge the success of the website on feedback and results. If users like the site, and it achieves its aims, he’ll be happy — but if they hate it, and the site fails, he won’t feel any better for knowing that he got his way earlier on. In fact, he’ll expect you to have advised him well from the start — even if that meant you had to challenge some of his assumptions and preferences. Nobody likes to be told that something’s their fault when it’s too late to fix it — and as web professionals, it’s our job to advocate the user’s point of view throughout the design process.
Suppose the CEO requests one of the all-time classics of ego marketing, the splash page, and you go ahead and implement one (with a really big logo). You know what will happen — users will be annoyed, because instead of helping them find what they’re looking for, the site is wasting their time by pushing empty marketing guff into their faces. Perhaps that’s an extreme example, but the same principle is true of all ego-marketing — users are unconvinced, and so feel annoyed — weakening your message.
In this article I’ve argued that if you give in to unreasonable client demands upfront, by designing for the CEO, you’ll pay for it later. Even if pandering to requests for ego marketing pleases the client in the short term, once the site is live she’ll judge it on feedback and results, and then you’ll be blamed for failing to advise her properly. Even though clients pay our bills, user-centred design is complicated — we’re paid to help clients communicate with their audience, not to make them feel good about themselves.
If you manage to steer the client away from designing for the CEO, by advocating the user’s interests and resisting ego marketing, you’ll get a big payoff when the site launches and the client starts to get positive feedback from users. Ultimately, your clients will love you for thinking of their users first — which will make you more successful in the long term. And if they’re still not happy, you could always design them some big fluffy posters…
Right now everybody’s talking about Facebook, “the social utility that connects you with the people around you”. Thousands of people register on the site every day, and the mainstream press drones endlessly about whether it’ll get bigger than MySpace, and then presumably take over the world. And even though I haven’t signed up yet, I know from looking over people’s shoulders that an incredible number of my friends and acquaintances are active Facebook users. Perhaps I should just give in, and sign up.
But is Facebook really the ultimate social networking site, the last one you’ll ever need to add all your friends to? Of course not: in a year’s time, some other site will be the trendy hangout that you can’t afford to miss out on. But the good news is that this constant migration from network to network isn’t going to carry on for ever — because we now have interoperable, open standards that will make the idea that all your friends need to be on the same social network seem quaint. The combination of microformats and OpenID will allow open websites to compete with the key selling points of walled gardens like Facebook — privacy and network effects — and as a result, kill their business model.
As Jason Kottke says, Facebook is the new AOL — a walled garden, which you can’t access from the open internet unless you’re a signed-up, logged-in Facebook user. Signing up to yet another website, and then approving all your friends for the 14th time is clearly a pain, so why do so many people do it? Because walled gardens offer two key features that open websites don’t: privacy and network effects.
When you add content to your Facebook profile, you can make sure that only your friends can see it. So the fact that you’re feeling grumpy today isn’t broadcast to the whole world, just to your network — and the photos from the party last night can only be seen by people you trust. This kind of privacy feature isn’t unique to Facebook, of course: you can achieve the same effect using Flickr or Twitter, for example — sites which aren’t usually thought of as walled gardens. But I argue that whenever privacy features are used on these sites, they behave like walled gardens — because in order to restrict access to a network of friends, all of your friends need a profile on that site. You effectively lock out any of your real-life friends that haven’t signed up for that website: a walled garden approach.
The success of social networks like Facebook is clearly helped by network effects — the fact that if lots of your friends are already active users, joining looks much more attractive than if you’re the first to join. This applies equally to adding comments to other people’s photos on Flickr and writing on a friend’s “wall” on Facebook.
The business model of these walled gardens goes something like this:
At the moment, this model works — just look at Facebook and MySpace. But notice that during the second step, the site isn’t getting users to sign up primarily because they like the service, but because their friends are already on the network. Walled gardens exploit their users’ personal relationships to grow their proprietary systems — and on the internet, that’s never sustainable.
So what’s the open alternative to this walled garden approach? Microformats for relationships and OpenID for identity.
Microformats are “a set of simple, open data formats built upon existing and widely adopted standards” — often referred to as the lowercase semantic web. Jeremy Keith outlines how the existing hCard and XFN microformats could be used to create portable social networks, so that each new website you join could automatically fetch a list of friends from a URL you provide. This wouldn’t have to be hosted on a blog or personal site — a profile page on a site like Flickr could automatically provide this information, just by using microformats in the markup. But what about privacy?
OpenID is an open, decentralised identity system. The central idea is that if a person can prove that they own a URL, that’s enough to identify them. Simon Willison describes how OpenId could be used to create decentralised social networks, “with profiles tied together across multiple sites and relationships easily portable between services” — that is, you can restrict access to your group of friends even if they’re not members of your social networking website of choice.
If a social networking site combined these approaches, you could instruct it to restrict access to a group of friends that:
This is the killer combination for Facebook’s business model.
Why am I so sure this will happen? Well, it might not work exactly the way I’ve outlined, but some kind of interoperable, open standard will eventually replace proprietary, closed social networks, because open systems always beat closed ones on the internet. This doesn’t necessarily mean that the sites I’m calling walled gardens are doomed though — they just need to open up, and rethink their business model.
Once you remove the exploitation of personal relationships I’ve described above, exponential growth of users is much more difficult to achieve. Now, new users won’t sign up just because their friends’ content is in your system — because they can access it anyway using an open identity system. To get them to sign up, you’ll have to convince them that your service is better than all the others — which means you have to offer the best user experience, not the largest network.
Selling advertising to a captive audience also becomes more difficult, because your audience isn’t really captive any more. If your users’ friends use RSS to access content, for example, they won’t see your site at all — and anyway your users are free to migrate to another site whenever they want to, because they now own their data in an open format. Perhaps this will result in more targeted, niche advertising — or even a service charge (gasp!), paid in return for a well designed, pleasurable experience. Either way, the Facebook model will fail — which means that sometime soon, we won’t have to join a new social network every six months. I’m looking forward to it.
My first article for A List Apart, for people who make websites, was published today. It’s called ‘You Are Not a Robot’.
We often sell web standards by explaining that using them improves accessibility. We might talk about reaching as wide an audience as possible, or about laws requiring accessible websites.
However, accessibility is only part of the story. An equally important benefit of following standards is the discipline they require.
The concept of discipline that I want to introduce in this article is closely related to professionalism and self-respect.
Having discipline as a web professional requires the self-respect to admit that what we do is valuable in itself — not just as a plugin to a more legitimate activity. Once we have self-respect, we can begin to bring order to the way we work: discipline. Using web standards is a powerful way to achieve that.
In the junk markup era, it was effectively impossible to follow web standards if you wanted visual or behavioural consistency across browsers. We had to use code forking and nested table layouts, which led to rushed websites with messy, unmaintainable code. Only a handful of pages validated.
This led to the belief that anyone could create websites after a few hours of hacking, and a corresponding lack of self-respect among web professionals. We felt powerless to influence the web, and as a result we lacked discipline in our work.
Part of the difficulty in having discipline comes from the tendency for clients, management and colleagues to assume that our role is a minor subset of some other activity, like graphic design or software engineering. Jesse James Garrett refuted this assumption in his Elements of User Experience, in which he argued that the essence of web design is managing the tension between web as software interface and web as hypertext space. One example of the dot-com era tendency to write off web design as a subset of graphic design is demonstrated by Adaptive Path‘s decision to use the term ‘user experience’ instead of ‘design’, to avoid an association with visual stylists, who had no grasp of what we would call web design.
When faced with the lack of discipline I’ve described, many web developers have turned to computer science and software engineering as a source of discipline. They see methodologies like Object Oriented Design and Model View Controller as solutions, and use frameworks based on these methodologies to bring discipline to their work.
An analysis of the benefits of these methodologies is outside the scope of this article; clearly, many programmers find them useful. However, I argue that they can shift the focus of thought away from the essence of web design, because they assume that our main task is programming — that web design is a subset of software design. Again, this is an error: although we may do some programming, we are not primarily programmers.
So, how can web standards give us discipline? Using semantic and valid markup, styling using CSS, progressively enhancing with widely-supported JavaScript and using clean URLs introduces a lot of discipline. And it’s not easy to do.
Writing valid markup is not intrinsically difficult, but correctly applying semantics to documents is not straightforward for most people. To demonstrate this, how many people do you know who are able to use Microsoft Word’s outline styles feature semantically, instead of just using presentational styles like bold and italic? Creating content management systems that allow non-technical people to write semantic markup is even harder.
The basics of CSS are straightforward; for example, it’s easy to demonstrate how to change the colour of headings in a document. However, successfully pulling off floated or positioned layouts, flexible width columns or bulletproof designs that work with zoomed text is much harder, especially when you have to support a range of browsers.
JavaScript is also more complicated than it looks. It’s straightforward to trigger an alert box when a form element is left empty, but unobtrusively adding interactivity that gracefully degrades when JavaScript is disabled requires a lot more thought.
The concept of using clean URLs sounds easy, even obvious. Implementing them well, however, requires a lot of thought — there are implications for information architecture, navigation, content management and database design.
I argue that simply by following web standards in the way I’ve outlined, you go a long way towards introducing discipline in your work. You’ve separated content from presentation, written your documents semantically, used style sheets for design, progressively enhanced behaviour for modern browsers, and used URLs to make your content easily accessible. You’re more likely to produce maintainable, reusable code, and to be able to transfer what you’ve learnt to other projects.
Molly Holzschlag wrote last year about a new professionalism in web designers and developers. She talks specifically about the need to keep our skills up to date, and to be willing to learn. I argue that an equally important element of the new professionalism is gaining the self-respect to realise that what we do is not a subset of some existing field, that it is not easy — and therefore, that it has substantial value.
It isn’t a coincidence that the new professionalism arrived at the same time as the mainstream adoption of web standards; and we should use our new self-respect to argue that following web standards is a discipline in itself.
When you build an accessible website, do you aim for code that follows standards, or for a site that is actually usable by people with disabilities?
The obvious answer is ‘both’. The reason we follow web standards is largely to make our sites accessible to as many people as possible, and specifically to people with disabilities.
This is great in theory, but as we’re used to on the web, the practical reality is more complicated.
Remember ‘To Hell With Bad Browsers’? The Web Standards Project (WaSP) was founded at a time when there was no such thing as a standards-compliant browser. Table-based layouts were used to achieve visual consistency and code forking was required to get consistent behaviour.
The browser upgrade compaign was about using CSS layouts at a time when web designers were afraid of them, because many users still had old browsers. By separating content from presentation in 2001, WaSP wasn’t writing for the web as it was — it was writing for the web that it wanted.
What has this got to do with accessibility? I argue that the state of adaptive technology today can be compared to the state of the 4.0 web browsers. I’ll attempt to demonstrate this with two examples: image replacement and Ajax.
The current stalemate in font distrubution on the web led to innovative but non-ideal methods of embedding typography, like image replacement. The concept of image replacement is simple; use semantic markup for headings, but use CSS to hide the browser-generated text and show an image of fine typography instead. In this way devices which don’t undersand CSS, for example search engines, can still access the content, while CSS-aware graphical browsers get proper typography.
The theory was that screen readers would behave like search engines, by reading out the headings as if the image replacement had never happened. The CSS rules that hid the text were delivered in a “screen” media type stylesheet and so should not have affected the “aural” rendering of the page. It turned out that this assumption was wrong: Joe Clark demonstrated that most screen readers never read the hidden text, because they first rendered the document using a visual browser such as Internet Explorer, and then read out the resulting document tree.
Clark argued that this behaviour is justified because current screen readers are “multimodal” devices, while Dave Shea disagreed. Clark’s approach is well-intentioned, but I argue that it is the equivalent of an anti-standards viewpoint during the browser wars.
The Ajax approach to building websites involves updating parts of a web page without refreshing the entire page. It is relatively straightforward to implement this approach on modern browsers while delivering a comparable, but less interactive, experience for older browsers or those who disable JavaScript. Screen reader support, however, is harder to predict since there is no standard way to ‘notify’ a screen reader that part of a page has changed. A recent study by James Edwards concluded that Ajax techniques cannot currently be considered accessible, while testing of the Basecamp web service concluded that it was usable but had some limitations. Both studies involved testing by screen reader users.
What is an accessibility-conscious web developer supposed to conclude? Presumably either that new approaches like Ajax are not accessible and are to be avoided, or that massive screen-reader testing is necessary to justify their use. I argue that both of these conclusions are misguided, and that if the majority of web developers accept them, they will have a negative impact on the future state of adaptive technology.
The central question here is: how much time are we prepared to spend testing one particular user-agent’s behaviour? There are lots of variables: different screen readers, different software versions, complex user preferences and a range of proficiency among users. The current market-leading screen reader (JAWS) is an expensive piece of proprietary software, with no web developer help except for a demonstration version that requires frequent system reboots. And we’re only talking about one group of disabled users.
Zeldman related that the motivation for founding WaSP wasn’t altruism but anger: ‘angry laziness’ as he put it. I think we need some more of that.
If we work around all the non-standard behaviour we can find, simply for the sake of people who are using broken technology, we’re not really helping them in the long run. Adaptive technology vendors aren’t going to start following standards unless we can demonstrate that their current implementations are not good enough; and the only way that’s going to happen is if they see modern standards-compliant code that doesn’t work. This is closely related to the recent WaSP debate about how to embed Flash: should user experience always come before web standards?
Both Apple and Sun are working on accessible operating systems that could ultimately remove the need for separate screen reading software. I don’t know how well these technologies follow web standards at the moment, but perhaps developing websites as if adaptive technology followed web standards might inspire vendors to make it a reality?
Although the kind of testing that Clark, Edwards and others have done is clearly valuable, it’s not going to be practical for every medium-sized website. To some extent the non-testing approach is already implicity advocated; consider the unobtrusive scripting / ‘Hijax’ approach that holds that if it works with JavaScript off, it’s accessible. Since screen reader users may have JavaScript turned on, this claim is more of an aspiration than a reality, and rightly so; perhaps we need to make that explicit.
The recent launch of WaSP‘s Assistive Technology Initiative is a positive step, but it needs to be accompanied by pressure. A good way to exert this pressure would be to continue the use of innovative techniques like image replacement and Ajax, making sure that we follow standards, but not insisting on 100% interoperability with assistive technology, if we can show that a lack of standards-compliance is the cause. The WCAG 2 debacle demonstrates that vendors don’t always act in the interests of the web and its users. If we want to stand up for accessibility, we need to show that we can still sting.