Tags: pattern



On the side

My role at Clearleft is something along the lines of being a technical director. I’m not entirely sure what that means, but it seems to be a way of being involved in front-end development, without necessarily writing much actual code. That’s probably for the best. My colleagues Mark, Graham, and Charlotte are far more efficient at doing that. In return, I do my best to support them and make sure that they’ve got whatever they need (in terms of resources, time, and space) to get on with their work.

I’m continuously impressed not only by the quality of their output on client projects, but also by their output on the side.

Mark is working a project called Fractal. It’s a tool for creating component libraries, something he has written about before. The next steps involve getting the code to version 1.0 and completing the documentation. Then you’ll be hearing a lot more about this. The tricky thing right now is fitting it in around client work. It’s going to be very exciting though—everyone who has been beta-testing Fractal has had very kind words to say. It’s quite an impressive piece of work, especially considering that it’s the work of one person.

Graham is continuing on his crazily-ambitious project to recreate the classic NES game Legend Of Zelda using web technology. His documentation of his process is practically a book:

  1. Introduction,
  2. The Game Loop,
  3. Drawing to the Screen,
  4. Handling User Input,
  5. Scaling the Canvas,
  6. Animation — Part 1,
  7. Levels & Collision — part 1, and most recently
  8. Levels — part 2.

It’s simultaneously a project that involves the past—retro gaming—and the future—playing with the latest additions to JavaScript in modern browsers (something that feeds directly back into client work).

Charlotte has been speaking up a storm. She spoke at the Up Front conference in Manchester about component libraries:

The process of building a pattern library or any kind of modular design system requires a different approach to delivering a set of finished pages. Even when the final deliverable is a pattern library, we often still have to design pages for approval. When everyone is so used to working with pages, it can be difficult to adopt a new way of thinking—particularly for those who are not designers and developers.

This talk will look at how we can help everyone in the team adopt pattern thinking. This includes anyone with a decision to make—not just designers and developers. Everyone in the team can start building a shared vocabulary and attempt to make the challenge of naming things a little easier.

Then she spoke at Dot York about her learning process:

As a web developer, I’m learning all the time. I need to know how to make my code work, but more importantly, I want to understand why my code works. I’ve learnt most of what I know from people sharing what they know and I love that I can now do the same. In my talk I want to share my highlights and frustrations of continuous learning, my experiences of working with a mentor and fitting it into my first year at Clearleft.

She’ll also be speaking at Beyond Tellerrand in Berlin later this year. Oh, and she’s also now a co-organiser of the brilliant Codebar events that happen every Tuesday here in Brighton.

Altogether that’s an impressive amount of output from Clearleft’s developers. And all of that doesn’t include the client work that Mark, Graham, and Charlotte are doing. They inspire me!

100 words 039

Charlotte and I came up with a fun exercise today to help a client’s dev team to think of patterns at the granular level—something that had been proving difficult to get across.

We print out page designs, hand them some scissors, and get them to cut up the pages into their smallest components. Mix them all up so you can’t even tell which components came from which pages.

Then—after grouping duplicate patterns together—everyone takes a component and codes it up in HTML and CSS. As soon as you’re finished with one pattern, grab another.

Rinse and repeat.

Code refactoring for America

Here at Clearleft, we’ve been doing some extra work with Code for America following on from our initial deliverables. This makes me happy for a number of reasons:

  1. They’re a great client—really easy-going and fun to work with.
  2. We’ve got Anna back in the office and it’s always nice to have her around.
  3. We get to revisit the styleguide we provided, and test our assumptions.

That last one is important. When we provide a pattern library to a client, we hope that they’ve got everything they need. If we’ve done our job right, then they’ll be able to combine patterns in ways we haven’t foreseen to create entirely new page types.

For the most part, that’s been the case with Code for America. They have a solid set of patterns that are serving them well. But what’s been fascinating is to hear about what it’s like for the people using those patterns…

There’s been a welcome trend in recent years towards extremely robust, maintainable CSS. SMACSS, BEM, OOCSS and other methodologies might differ in their details, but their fundamental approach is pretty similar. The idea is that you apply a very specific class to every element you want to style:

<div class="thingy">
    <ul class="thingy-bit">
        <li class="thingy-bit-item"></li>
        <li class="thingy-bit-item"></li>
    <img class="thingy-wotsit" src="" alt="" />

That allows you to keep your CSS selectors very short, but very specific:

.thingy {}
.thingy-bit {}
.thingy-bit-item {}
.thingy-wotsit {}

There’s little or no nesting, and you only ever use class selectors. That keeps your CSS nice and clear, and you avoid specificity hell. The catch is that your HTML is necessarily more verbose: you need to explicitly add a class to whatever you want to style.

For most projects—particularly product work (think Twitter, Facebook, etc.)—that’s a completely acceptable trade-off. It’s usually the same developers editing the CSS and the HTML so there’s no problem moving complexity out of CSS and into the markup templates. Even if other people will be entering the actual content into the system, they’ll probably be doing that mediated through a Content Management System, rather than editing HTML directly.

So nine times out of ten, making the HTML more verbose is absolutely the right choice in order to make the CSS more manageable and maintainable. That’s the way we initially built the pattern library for Code for America.

Well, it turns out that the people using the markup patterns aren’t necessarily the same people who would be dealing with the CSS. Also, there isn’t necessarily a CMS involved. Instead, people (volunteers, employees, anyone really) create new pages by copying and pasting the patterns we’ve provided and then editing them.

By optimising on the CSS side of things, we’ve offloaded a lot of complexity onto their shoulders. While it’s fair enough to expect them to understand basic HTML, it’s hardly fair to expect them to learn a whole new vocabulary of thingy and thingy-wotsit class names just to get things to look they way they expect.

Here’s a markup pattern that makes more sense for the people actually dealing with the HTML:

<div class="thingy">
    <img src="" alt="" />

Much clearer. But now the CSS looks like this:

.thingy {}
.thingy ul {}
.thingy li {}
.thingy img {}

Actually it’s probably going to look more complicated than that: more nesting, more element selectors, more “defensive” rules trying to anticipate the kind of markup that might be used in a particular pattern.

It feels really strange for Anna and myself to work with these kind of patterns. All of our experience screams “Don’t do that! Why would you that?” …but in this case, it’s the right thing to do for the people building the actual website.

So please don’t interpret this as me saying “Hey, everyone, this is how you should write your CSS.” I’m not saying this is better or worse than adding lots of classes to your HTML. If anything, this illustrates that there is no one right way to do this.

It’s worth remembering why we’re aiming for maintainability in what we write. It’s not for any technical reason. It’s for people. If those people find it better to deal with simplified CSS with more complex HTML, than the complexity should be in the HTML. But if the priority for those people is to have simple HTML, then more complex CSS may be an acceptable price to pay.

In other words, it depends.

Pattern sharing

Mike has written about the Code for America alpha website that we collaborated on:

We chose to work with ClearLeft because they develop a pattern portfolio (a pattern/style library) which would allow us to scale our work to our Brigades. This unique approach has aligned perfectly with our work style and decentralized organizational structure.

Thankfully, I think the approach of delivering a pattern portfolio (instead of just pages) isn’t so unique these days. Mind you, it still seems to be more common with in-house teams than agencies. The Mailchimp pattern library is a classic example.

But agencies like Paravel are—like Clearleft—delivering systems, not pages. Dave wrote about providing responsive deliverables:

Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs.

I think that’s a good way of looking at it: a Bootstrap for every project.

Here’s the front-end style guide for Code for America.

Usually these front-end deliverables will be password-protected on the Clearleft extranet for the client’s eyes only, but Code for America are all about openness, so they’re more than willing to let us share it with the world. That makes me very happy. I remember encouraging the guys at Starbucks to publish their front-end style guide and I’ve written about this spirit of sharing before:

These style guides and pattern libraries aren’t being published in an attempt to provide ready-made solutions—every project should have its own distinct pattern library. Instead, these pattern libraries are being published in a spirit of openness and sharing …a way of saying “Hey, this is what worked for us in these particular circumstances.”

If you’re poking around the Code for America style guide, you’ll notice that it borrows some ideas from the pattern primer idea I published a while back. But in this iteration, the markup is available via a toggle—a nice variation. There’s also a patchwork page that provides a nice glance-able uninterrupted view of the same patterns.

Every project is a learning experience and each front-end style guide gives us ideas about how to do the next one better. In fact, Mark is busy working on better internal tools for creating these kinds of deliverables—something we’ll definitely be sharing. In the meantime, I’ll be encouraging other clients to be as open as Code for America have been in allowing us to share these deliverables.

For more on the usefulness of front-end style guides, be sure to read Paul’s article on style guides for the web, Anna’s classic 24 Ways article, and of course, Anna’s pocket guide from Five Simple Steps.

Coding for America

Back when I was wandering around America in August, I mentioned that I met up with Mike Migurski in San Francisco:

I played truant from UX Week this morning to meet up with Mike for a coffee and a chat at Cafe Vega. We were turfed out when the bearded, baseball-capped, Draplinesque barista announced he had to shut the doors because he needed to “run out for some milk.” So we went around the corner to the Code For America office.

It wasn’t just a social visit. Mike wanted to chat about the possibility of working with Clearleft. The Code for America site was being overhauled. The new site needed to communicate directly with volunteers, rather than simply being a description of what Code for America does. But the site also needed to be able to change and adapt as the organisation’s activities expanded. So what they needed was not a set of page designs; they needed a system of modular components that could be assembled in a variety of ways.

This was music to my ears. This sort of systems-thinking is exactly the kind of work that Clearleft likes to get its teeth into. I showed Mike some of the previous work we had done in creating pattern libraries, and it became pretty clear that this was just what they were looking for.

When I got back to Brighton, Clearleft assembled as small squad to work on the project. Jon would handle the visual design, with the branding work of Dojo4 as a guide. For the front-end coding, we brought in some outside help. Seeing as the main deliverable for this project was going to be a front-end style guide, who better to put that together than the person who literally wrote the book on front-end style guides: Anna.

I’ll go into more detail about the technical side of things on the Clearleft blog (and we’ll publish the pattern library), but for now, let me just say that the project was a lot of fun, mostly because the people we were working with at Code for America—Mike, Dana, and Cyd—were so ridiculously nice and easy-going.

Anna and Jon would start the day by playing the unofficial project theme song and then get down to working side-by-side. By the end of the day here in Brighton, everyone was just getting started in San Francisco. So the daily “stand up” conference call took place at 5:30pm our time; 9:30am their time. The meetings rarely lasted longer than 10 or 15 minutes, but the constant communication throughout the project was invaluable. And the time difference actually worked out quite nicely: we’d tell them what we had been working on during our day, and if we needed anything from them; then they could put that together during their day so it was magically waiting for us by the next morning.

It’ll be a while yet before the new site rolls out, but in the meantime they’ve put together an alpha site—with a suitably “under construction” vibe—so that anyone can help out with the code and content by making contributions to the github repo.

Defining the damn thang

Chris recently documented the results from his survey which asked:

Is it useful to distinguish between “web apps” and “web sites”?

His conclusion:

There is just nothing but questions, exemptions, and gray area.

This is something I wrote about a while back:

Like obscenity and brunch, web apps can be described but not defined.

The results of Chris’s poll are telling. The majority of people believe there is a difference between sites and apps …but nobody can agree on what it is. The comments make for interesting reading too. The more people chime in an attempt to define exactly what a “web app” is, the more it proves the point that the the term “web app” isn’t a useful word (in the sense that useful words should have an agreed-upon meaning).

Tyler Sticka makes a good point:

By this definition, web apps are just a subset of websites.

I like that. It avoids the false dichotomy that a product is either a site or an app.

But although it seems that the term “web app” can’t be defined, there are a lot of really smart people who still think it has some value.

I think Cennydd is right. I think the differences exist …but I also think we’re looking for those differences at the wrong scale. Rather than describing an entire product as either a website or an web app, I think it makes much more sense to distinguish between patterns.

Let’s take those two modifiers—behavioural and informational. But let’s apply them at the pattern level.

The “get stuff” sites that Jake describes will have a lot of informational patterns: how best to present a flow of text for reading, for example. Typography, contrast, whitespace; all of those attributes are important for an informational pattern.

The “do stuff” sites will probably have a lot of behavioural patterns: entering information or performing an action. Feedback, animation, speed; these are some of the possible attributes of a behavioural pattern.

But just about every product out there on the web contains a combination of both types of pattern. Like I said:

Is Wikipedia a website up until the point that I start editing an article? Are Twitter and Pinterest websites while I’m browsing through them but then flip into being web apps the moment that I post something?

Now you could make an arbitrary decision that any product with more than 50% informational patterns is a website, and any product with more than 50% behavioural patterns is a web app, but I don’t think that’s very useful.

Take a look at Brad’s collection of responsive patterns. Some of them are clearly informational (tables, images, etc.), while some of them are much more behavioural (carousels, notifications, etc.). But Brad doesn’t divide his collection into two, saying “Here are the patterns for websites” and “Here are the patterns for web apps.” That would be a dumb way to divide up his patterns, and I think it’s an equally dumb way to divide up the whole web.

What I’m getting at here is that, rather than trying to answer the question “what is a web app, anyway?”, I think it’s far more important to answer the other question I posed:


Why do you want to make that distinction? What benefit do you gain by arbitrarily dividing the entire web into two classes?

I think by making the distinction at the pattern level, that question starts to become a bit easier to answer. One possible answer is to do with the different skills involved.

For example, I know plenty of designers who are really, really good at informational patterns—they can lay out content in a beautiful, clear way. But they are less skilled when it comes to thinking through all the permutations involved in behavioural patterns—the “arrow of time” that’s part of so much interaction design. And vice-versa: a skilled interaction designer isn’t necessarily the best at old-skill knowledge of type, margins, and hierarchy. But both skillsets will be required on an almost every project on the web.

So I do believe there is value in distinguishing between behaviour and information …but I don’t believe there is value in trying to shoehorn entire products into just one of those categories. Making the distinction at the pattern level, though? That I can get behind.


Incidentally, some of the respondents to Chris’s poll shared my feeling that the term “web app” was often used from a marketing perspective to make something sound more important and superior:

Perhaps it’s simply fashion. Perhaps “website” just sounds old-fashioned, and “web app” lends your product a more up-to-date, zingy feeling on par with the native apps available from the carefully-curated walled gardens of app stores.

Approaching things from the patterns perspective, I wonder if those same feelings of inferiority and superiority are driving the recent crop of behavioural patterns for informational content: parallaxy, snowfally, animation patterns are being applied on top of traditional informational patterns like hierarchy, measure, and art direction. I’m not sure that the juxtaposition is working that well. Taking the single interaction involved in long-form informational patterns (that interaction would be scrolling) and then using it as a trigger for all kinds of behavioural patterns feels …uncanny.

Off-canvas horizontal lists

There was a repeated rallying cry at the Responsive Day Out. It was the call for more sharing—more sharing of data, more sharing of case studies, more sharing of success stories, but also more sharing of failures.

In that spirit, I thought I’d share a pattern I’ve been working on. It didn’t work, but I’m not going to let that stop me putting it out there.

Here’s what I wanted to do…

Let’s say you’ve got a list of items; modular chunks of markup like an image and a caption, for example. By default these will display linearly on a small screen: a vertical list. I quite like the way that the Flickr iPhone app takes those lists and makes them horizontal—they go off-canvas (to the right), with a little bit of the next item peaking out to give some affordance. It’s like an off-canvas carousel.

I’d quite like to use that interaction in responsive designs. But I don’t want to do it by throwing a lot of JavaScript at the problem. So I thought I’d attempt to achieve it with a little bit of CSS.

So, let’s say I’ve got a list of six items like this:

<div class="items">
    <ul class="item-list">
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
    </ul><!-- /.item-list -->
</div><!-- /.items -->

Please pay no mind to the qualities of the class names: this is just a quick proof of concept.

Here’s how that looks. At larger screen sizes, I display the list items in groups of two or three, side by side. At smaller sizes, the items simply linearise vertically.

Okay, now within a small-screen media query I’m going to constrain the width of the container:

.items {
    width: 100%;

I’m going to make the list within that element stretch off-canvas for six screens wide (this depends on me knowing that there will be exactly six items in the list):

.items .item-list {
    width: 600%;

Now I’ll make each item one sixth of that size, which should be one screen’s worth. Actually, I’m going to make it a bit less than exactly one sixth (which would be 16.6666%) so that a bit of the next item peaks out:

.item-list .item {
    width: 15%;

My hope was that to make this crawlable/swipable, all I had to do was apply overflow: scroll to the containing element:

.items {
    width: 100%;
    overflow: scroll;

All of that is wrapped up in a small-viewport media query:

@media all and (max-width: 30em) {
    .items {
        width: 100%;
        overflow: scroll;
    .items .item-list {
        width: 600%;
    .items .item {
        width: 15%;

It actually works …in some browsers. Alas, support for overflow: scroll doesn’t extend back as far as Android 2, still a very popular flavour of that operating system. That’s quite a showstopper.

There is a polyfill called Overthrow from those mad geniuses at Filament Group. But, as I said, I’d rather not throw more code at the problem. While I can imagine shovelling a polyfill at a desktop browser, I have a lot of qualms about trying to “support” an older mobile browser by giving it a chunk of JavaScript to chew on.

What I really need is a way to detect support for overflow: scroll. Alas, looking at the code for Overthrow, that isn’t so easy. Modernizr cannot help me here. We are in the realm of the undetectables.

My pattern is, alas, a failure.

Or, at least, it’s a failure for now. The @supports rule in CSS is tailor-made for this kind of situation. Basically, I don’t want any those small-screen rules to apply unless the browser supports overflow: scroll. Here’s how I will be able to do that:

@media all and (max-width: 30em) {
  @supports (overflow: scroll) {
    .items {
        width: 100%;
        overflow: scroll;
    .items .item-list {
        width: 600%;
    .items .item {
        width: 15%;

This is really, really useful. It means that I can start implementing this pattern now even though very few browsers currently understand @supports. That’s okay. Browsers that don’t understand it will simply ignore the whole block of CSS, leaving the list items to display vertically. But as @support gets more …um, support …then the pattern will kick in for those more capable browsers.

I can see myself adding this pre-emptive pattern for a few different use cases:

Feel free to poke at the example code. Perhaps you can find a way to succeed where I have failed.

Twitter permissions

Twitter has come in for a lot of (justifiable) criticism for changes to its API that make it somewhat developer-hostile. But it has to be said that developers don’t always behave responsibly when they’re using the API.

The classic example of this is the granting of permissions. James summed it up nicely: it’s just plain rude to ask for write-access to my Twitter account before I’ve even started to use your service. I could understand it if the service needed to post to my timeline, but most of the time these services claim that they want me to sign up via Twitter so that I can find my friends who are also using the service — that doesn’t require write access. Quite often, these requests to authenticate are accompanied by reassurances like “we’ll never tweet without your permission” …in which case, why ask for write-access in the first place?

To be fair, it used to be a lot harder to separate out read and write permissions for Twitter authentication. But now it’s actually not that bad, although it’s still not as granular as it could be.

One of the services that used to require write-access to my Twitter account was Lanyrd. I gave it permission, but only because I knew the people behind the service (a decision-making process that doesn’t scale very well). I always felt uneasy that Lanyrd had write-access to my timeline. Eventually I decided that I couldn’t in good conscience allow the lovely Lanyrd people to be an exception just because I knew where they lived. Fortunately, they concurred with my unease. They changed their log-in system so that it only requires read-access. If and when they need write-access, that’s the point at which they ask for it:

We now ask for read-only permission the first time you sign in, and only ask to upgrade to write access later on when you do something that needs it; for example following someone on Twitter from the our attendee directory.

Far too many services ask for write-access up front, without providing a justification. When asked for an explanation, I’m sure most of them would say “well, that’s how everyone else does it”, and they would, alas, be correct.

What’s worse is that users grant write-access so freely. I was somewhat shocked by the amount of tech-savvy friends who unwittingly spammed my timeline with automated tweets from a service called Twitter Counter. Their reactions ranged from sheepish to embarrassed to angry.

I urge you to go through your Twitter settings and prune any services that currently have write-access that don’t actually need it. You may be surprised by the sheer volume of apps that can post to Twitter on your behalf. Do you trust them all? Are you certain that they won’t be bought up by a different, less trustworthy company?

If a service asks me to sign up but insists on having write-access to my Twitter account, it feels like being asked out on a date while insisting I sign a pre-nuptial agreement. Not only is somewhat premature, it shows a certain lack of respect.

Not every service behaves so ungallantly. Done Not Done, 1001 Beers, and Mapalong all use Twitter for log-in, but none of them require write-access up-front.

Branch and Medium are typical examples of bad actors in this regard. The core functionality of these sites has nothing to do with posting to Twitter, but both sites want write-access so that they can potentially post to Twitter on my behalf later on. I know that I won’t ever want either service to do that. I can either trust them, or not use the service at all. Signing up without granting write-access to my Twitter account isn’t an option.

I sent some feedback to Branch and part of their response was to say the problem was with the way Twitter lumps permissions together. That used to be true, but Lanyrd’s exemplary use of Twitter for log-in makes that argument somewhat hollow.

In the case of Branch, Medium, and many other services, Twitter authentication is the only way to sign up and start using the service. Using a username and password isn’t an option. On the face of it, requiring Twitter for authentication doesn’t sound all that different to requiring an email address for authentication. But demanding write-access to Twitter is the equivalent of demanding the ability to send emails from your email address.

The way that so many services unnecessarily ask for write-access to Twitter—and the way that so many users unquestioningly grant it—reminds me of the password anti-pattern all over again. Because this rude behaviour is so prevalent, it has now become the norm. If we want this situation to change, we need to demand more respect.

The next time that a service demands unwarranted write-access to your Twitter account, refuse to grant it. Then tell the people behind that service why you’re refusing to sign up.

And please take a moment to go through the services you’ve already authorised.

The email notification anti-pattern: a response

Quite quickly after I wrote my email to Findings about their email notification anti-pattern, I got a response back from Lauren Leto:

Give it to us. I applaud you shouting at us from a rooftop. I also hate defaulting to all notifications and agree that it was a douchebag startup move but can assure it was one made accidentally - a horrible oversight that the entire team feels bad about and will work to amend for you and the rest of our users.

We try to be a site for the common user - nothing like Facebook taking cheap shots wherever they can. I hope we haven’t forever turned you off from our site. Relaunches are hard and mistakes were made but nothing like this will happen again.

Apart from the use of the passive voice (“mistakes were made” rather than “we made mistakes”), that’s a pretty damn good response. She didn’t try to defend or justify the behaviour. That’s good.

She also asked if there was anything they could do to make it up to me. I asked if I could publish their response here. “Yeah, feel free to post”, she said.

I think it’s important that situations like this get documented. It could be especially useful for new start-ups who might be thinking about indulging in a bit of “growth hacking” (spit!) under the impression that this kind of behaviour is acceptable just because other start-ups—like Findings—implemented the email notification anti-pattern.

As Lauren said:

I think every startup manages to mess up one of these at some point in their life, either willingly or unwillingly. A clear listing of all offenses could be useful to everyone.

That’s where Harry’s Dark Patterns wiki comes in:

The purpose of this pattern library is to “name and shame” Dark Patterns and the companies that use them.

  • For consumers, forewarned is fore-armed.
  • For brand-owners, the bad-press associated with being named as an offender should discourage usage.
  • For designers, this site provides ammunition to refuse unethical requests by our clients / bosses. (e.g. “I won’t implement opt-out defaults for the insurance upsells because that practice is considered unethical and it will get you unwanted bad press.”)

The email notification anti-pattern isn’t yet listed on the wiki. I’ll see if I can get Harry to add it.

The email notification anti-pattern

Dear Findings,

I see you have introduced some new email notifications. I have also noticed (via my newly-overstuffed inbox) that by default, these new email notifications are checked.


Sorry. Sorry. I lost my temper for a moment there. And the question is rhetorical because I think I know exactly what you were thinking …“traction”, “retention”, “engagement”, yadda yadda.

I realise that many other sites also do this. That does not make it right. In fact, given the sites that already do this include such pillars of empathy as Facebook, I would say that this kind of behaviour probably has a one-to-one correlation with the douchebaggery of the site in question.

You’re better than this.

Stop. Think. Spare a thought for those of us who don’t suddenly—from one day to the next—want our inboxes spammed by emails we never opted into.

Didn’t anybody stop to think about just how intrusive this would be?

Also, doesn’t this flood of new emails directly contradict this section of your privacy policy?:

As part of the Services, you may occasionally receive email and other communications from us, such as communications relating to your Account. Communications relating to your Account will only be sent for purposes important to the Services, such as password recovery.

Contrary to appearances, I don’t want to be completely negative, so I’ve got a constructive suggestion.

How about this:

If you’re about to introduce new email notifications, and all my existing notification settings are set to “off”, perhaps you could set the new notifications to “off” as well?

Sound good?

All the best,


Sharing pattern libraries

I’ve been huffduffing talks from this year’s South by Southwest, revisiting some of the ones I saw and catching up with some of the ones I missed.

There are some really design and development resources in there that I didn’t get to see in person:

One talk I did get to see was Andy’s CSS for Grown Ups: Maturing Best Practices.

CSS for Grown Ups: Maturing Best Practices on Huffduffer

It was excellent.

You can have a look through the slides.

He talks about different approaches to creating maintainable CSS for large-scale projects. He touches on naming conventions for classes, something that Nicolas Gallagher wrote about recently. And while he makes reference to SASS and Compass, Andy makes the compelling point that’s what more interesting than powerful tools is the arrival of powerful approaches like SMACSS and OOCSS.

Over and over again, Andy makes the point that we must think in terms of creating design systems, not simply styling individual pages—something that Paul has also spoken about. One of the most powerful tools for making that change in thinking is in the creation of style guides for the web and Paul has even created blog dedicated to the BBC’s style guide.

Andy referenced the BBC GEL style guide in his talk but pointed out that because it’s published as a PDF rather than markup, it isn’t as powerful as it could be—there’s inevitably a loss of signal when the patterns are translated into HTML and CSS. Someone from the BBC was in the audience, and in the Q and A portion, acknowledged that that was a really good point.

After the talk I got chatting with Lincoln Mongillo who worked on the recent responsive redesign of Starbucks.com. He mentioned that they created a markup and CSS style guide for the project. “You know what would be really cool?” I said. “If you published it!”

Here it is. It’s a comprehensive library of markup patterns; exactly the kind of resource that Anna wrote about in 24 Ways.

In my experience, creating a pattern library for any project is immensely valuable, whether you’re working in a team of two or a team of two hundred. I’ve found they work well as the next step after Style Tiles: a way of translating the visual vocabulary of a site into markup and CSS without getting bogged down in the specifics of page structure or layout (very handy for a Content First approach). The modularity of a pattern library enforces a healthy .

I’m really pleased to see more and more pattern libraries being made public. That’s one of the reasons why I shared my pattern primer and Dan shared his Pears theme for Wordpress:

Breaking interfaces down into patterns has been immensely helpful in learning and re-evaluating the best possible code to implement them.

But Pears isn’t about how I code these patterns—it’s a tool for creating your own.

I love that. These style guides and pattern libraries aren’t being published in an attempt to provide ready-made solutions—every project should have its own distinct pattern library. Instead, these pattern libraries are being published in a spirit of openness and sharing …a way of saying “Hey, this is what worked for us in these particular circumstances.”

For that, I am very grateful.

Pattern primer

I’m on a workshopping roll. Fresh from running my Responsive Enhancement workshop in Belfast, I’m now heading to Düsseldorf for Beyond Tellerand where I’ll be running the workshop on Sunday (and if you can’t make it, don’t forget that you can book the workshop for your own workplace too).

As part of the process of building a responsive site from the content out rather than the canvas in, I talk about beginning with the individual components divorced from any layout context. Or, as Mark puts it, “start with the bits.”

That’s the way I’ve been starting most of my projects lately: beginning with the atomic units of content and styling them first before even thinking about layout. This ensures that those styles are extremely robust—because they don’t depend on any particular context, they can be safely dropped into any part of a page.

I’ve been calling this initial collection of markup snippets a pattern primer. To help create the pattern primer, I’ve written a little bit of PHP to automatically generate a page of patterns from a folder of HTML snippets.

In my workshop I keep promising to put that script on Github. I finally got around to doing that and you can find it at github.com/adactio/Pattern-Primer.

Take a look at an example pattern primer to get an idea of what a handy deliverable this can be if you’re handing off to other developers. It also acts like a page of unit tests for CSS—whenever you’ve been messing around in the stylesheet you can refresh the page to quickly check to see if anything looks screwed up.

Grab the code; improve upon it; share your changes.

Pattern praise

Two months ago, I called Twitter out on their insistence that developers use OAuth when authorising with Twitter while they themselves continued to use the password anti-pattern when they wanted to peek into third-party address books.

I’m happy to report that Twitter have since fixed this. If you go to the Find Friends portion of the “Who To Follow” section, you’ll now be greeted with links that lead to correct authentication with LinkedIn, Gmail, Yahoo and Hotmail.

Thanks, Twitteroonies!

Meanwhile, Flickr recently launched their own “Who to Follow” functionality. There is nary a password request in sight: they’ve implemented correct authentication right out of the gate for Yahoo, Gmail, Hotmail and Facebook.

Thanks, Flickroonies!

See? I’m not always bitching’n’moaning.

OAuthypocrisy and the Passwordpocalypse

The OAuthcalypse is upon us. Since August 31st, all third-party Twitter services must use OAuth to authenticate. This is a good thing; a very good thing. Before that date, services were allowed to use the password anti-pattern to log you in.

Twitter has put its foot down and declared that the password anti-pattern will no longer be tolerated. Hurrah!

What a shame then, that Twitter is being utterly hypocritical. On their Find Friends page, they encourage you to:

Scan your email address book or contacts to discover which of your friends are already using Twitter.

They do this using the password anti-pattern. You are asked for your Gmail password even though the Google Contacts API would allow Twitter to connect to Gmail using proper authentication …exactly what Twitter is insisting third-parties use when they want to access Twitter’s data.

Twitter asks for your Yahoo Mail password even though the Yahoo Contacts API would allow them access to your address book using OAuth.

Twitter asks for AOL passwords (now there’s an audience that we shouldn’t be teaching to give their passwords away) but even AOL has an API with proper authentication.

Twitter does connect to LinkedIn correctly. That’s one out of four.

There are two solutions to this state of affairs. Either Twitter decides to do the right thing and switch over to using APIs and authentication for Gmail, Yahoo and AOL …or else Gmail, Yahoo and AOL follow Twitter’s example and disallow the password anti-pattern for scraping address books.

Twitter should not be encouraging Gmail users, Yahoo users and AOL users to divulge their passwords but at the same time, Gmail, Yahoo and AOL should be taking steps to ensure that such profligate behaviour is not rewarded.

Twitter has done the right thing with third-party services wishing to access its data. Now let’s see if the third-party services currently being abused by Twitter will follow this example.

Update: There are some very encouraging responses from Twitter. Ryan Sarver says:

all good points and I think there are already plans to fix it

And Josh Elman concurs:

yes - great points and something we hope to migrate very soon

Antipatterns for sale

Twply is a straightforward little Twitter app that sends @replies to email. It uses the password anti-pattern. Oh, but don’t worry. It states quite clearly on the site that Your password is safe with us. No worries!

Twply is up for sale …sold. That means all those passwords are available to the highest bidder ($1200 in this case).

Sleep tight, Twply users. May you wake to a better day.

Anti-pattern recognition

A new site called My Name Is E launched for beta testing today. Eager geeks rushed to sign up for the contact aggregation service. The second step of the process involved handing over your Twitter username and password. This request was dutifully obeyed by the eager geeks.


This is a classic example of the password anti-pattern. And this time it bit the willing victims on the ass. My Name Is E used the credentials to log in to Twitter as that person and post a spammy message from their account.

This is identity theft. It’s not as extreme as having your credit card used or having somebody get in to your email account but it’s still an unrequested violation of personal details. I’m very interested in hearing how the willing victims felt when they saw the message appear on Twitter with their own name and their own avatar next to it. I imagine adjectives like “outraged” and “shocked” would describe the initial reaction but I wonder if “embarrassed” would be far behind.

The “auto-tweeting feature[sic]” was removed within hours in response to the overwhelming negative reaction, as demonstrated on Get Satisfaction. What’s ironic, in the Alanis Morissette definition of the word, is that the Get Satisfaction page features a “share” tab that includes a link to “Twitter this.” Click it. Go on.

Needless to say, I disapprove of what My Name Is E did. But I don’t lay the blame entirely at their feet. Frankly, I’m really disappointed that so many people who really ought to know better were so quick to hand over their Twitter password to any site other than Twitter.

I blame Facebook.

I don’t mean that facetiously. I really do blame Facebook. I also blame Digg. And LinkedIn. And Plaxo. And Twitter.

All of those sites—and many others—actively, sometimes aggressively, use the password anti-pattern. Together they have created a pervasive atmosphere in which it is now completely acceptable for even seasoned geeks to throw their passwords ‘round like car keys at a dodgy ’70s party.

I’ve been banging on about the password anti-password for what feels like ages now. I keep saying that it’s teaching users how to be phished. After a particularly dispiriting discussion of OAuth on the iPhone, Simon went one further and put it in the past tense.

I fear that Simon may be right. But I’m not going to give up hope just yet. Now that Google, Yahoo and Hotmail all have OAuth-style contacts APIs, I think the tide could still be turned.

Mind you, Twitter’s continuing lack of an OAuth-based API is nothing short of shameful, as acknowledged by Blaine in his comment here:

OAuth came out of my worry that if the Twitter API became popular, we’d be spreading passwords all around the web. OAuth took longer to finish than it took for the Twitter API to become popular, and as a result many Twitter users’ passwords are scattered pretty carelessly around the web. This is a terrible situation, and one we as responsible web developers should work to prevent.

So while Twitter positively encourages the password anti-pattern (by example and by design), the situation is very different now for Google, Yahoo and Microsoft. Access to those web-based email services are used as justification for the majority of instances of the password anti-pattern. Now that they all offer alternatives, the only reason for abusers (like Digg and LinkedIn) not to switch from the password anti-pattern to using the official APIs is development time and priority.

Those are valid reasons for not immediately making the switch so I understand that not everybody scrambled to implement, say, the Google Contacts API in the week it came out. But it was released in March. It is now September. Surely that’s long enough for even a low priority task to get implemented?

I realise that I sound very negative in my finger-pointing here so I’d like to give credit where credit is due. Back in March, I listed a chart of web sites who were using the password anti-pattern but who I hoped would switch over. Shame on me for not including Flickr in the list because they were the first to follow Dopplr’s lead and scrap the anti-pattern in favour of a seamless import feature. Shame on me also for putting Last.fm at the bottom of the list. As part of their recent redesign, they too scrapped the anti-pattern. Good for them!

At the top of my list of sites I expected to ditch the anti-pattern was Pownce. Alas, they’re still not all the way there (Yahoo import is working correctly, GMail and AOL isn’t). But after some petulant grandstanding on my part, I have been assured that they are working on it.

I know I should care more about the big abusers like LinkedIn and Facebook than the little guys like Slideshare and Pownce. But it’s precisely because I love Pownce so, so much that it upsets me to see them get such an important thing so wrong when they get everything else so, so right.

Y’see, I’ve been thinking of putting my money where my mouth is. I should really plant a flag in the sand and set a date in the not-too-distant future (like maybe early next year) beyond which I will simply refuse to use any site that implements the password anti-pattern …and delete any existing accounts.

Now, I wouldn’t mind doing this for LinkedIn, Digg or Facebook (I’ve already done it for Plaxo). I wouldn’t miss those sites. I don’t have any strong attachment to those sites. But I have a very strong attachment to Pownce and I would miss it very, very much if I were to delete my account there.

I’d also have to delete my Twitter account, which would probably feel like losing a limb. It’s not that I feel a strong emotional attachment to Twitter—using Twitter often feels like being in an abusive relationship with a Fail Whale—but it’s so pervasive that it would be like swearing off using email, or chat, or the telephone.

Besides, what difference would this grandstanding of mine do? I’m just one measly account. But if other people were to join me …well, perhaps that might affect the speed and priority of abandoning the password anti-pattern.

I could set up a Wiki, or something similar; somewhere where others could add their voice to the call to remove the password anti-pattern. It needn’t be wholly negative either: it could double up as a place for listing useful resources for developers who want to implement OAuth-style APIs.

So I have a few questions for you:

  1. Is this a good idea or am I tripping?
  2. Would you abandon sites that refuse to ditch the password anti-pattern?
  3. Do you know of any good, easy to implement Wiki software?

Making contact

Today Yahoo announced the release of their Address Book API — previously only available internally and to selected partners. It follows on from Google’s Contacts Data API and I hope that this is one more nail in the coffin of the password anti-pattern.

Chris has expressed disappointment with the proprietary nature of the response formats and Dave also wishes there were more consistent APIs. It’s a fair point but the situation is still immeasurably better than logging in and scraping the individual address book services.

The sites that have so far abandoned the anti-pattern in favour of best practices are:

Meanwhile a whole bunch of otherwise-great services are still encouraging people to get phished:

The clock is ticking. There really isn’t any excuse any more for asking for my Yahoo Mail or GMail username and password.

No fooling

There are two problems with April fool’s day on the Web.

Firstly, there’s the curiously timeless nature of online publishing. Google has a habit of preserving everything we write in amber so that long after a joke has been published in the context of April 1st, it resurfaces in search results where it may the taken at face value.

Secondly, it becomes very difficult to separate “real” stories from the japes. Remember a few years back when Google launched their GMail service? Remember what day they launched it on? I recall quite a few people who refused to believe the veracity of the announcement.

With that in mind, here are some tidbits that are most definitely pranks:

  • GMail adds time-travel support using an e-flux capacitor to resolve issues of causality.
  • John Resig releases Class Query for developers who are sick and tired of brevity and simplicity. This one is only funny if you a total code nerd but if you are a total code nerd, it’s very funny indeed.
  • The Web Standards Project follow up their bookmark campaign with hyper-localised social tagging.
  • Moo announce the MightyCard.
  • The latest World of Warcraft character is the bard with damage effects like “epic solo” and “shoegazer”.
  • The BBC show flying penguins.
  • And finally, every single featured video on YouTube is a winner today.

These bits of news, on the other hand, are for real:

  • Joe launches Captioning Sucks in an attempt to bring sanity and standards to the worlds of film and television. Any garishness you may experience is intentional.
  • The good people over at Flickr have resurrected Game Neverending—the game that many years ago served as the genesis for Flickr itself (that’s why you’ll still the .gne extension to this day). The message announcing the resurrection is, of course, very much a joke.

There was one other announcement from Flickr but they managed to get it out right before the dreaded day of foolishness. The site now has a flawless import feature that has completely scrapped the password anti-pattern. Instead they’re using authentication APIs from GMail, Hotmail and Yahoo Mail (that last one is actually a bit of a cheat as Yahoo do not offer any export API for external services).

Needless to say, I’m over the moon about this (although Lachlan is less pleased). First Dopplr, now Flickr. And I’m ashamed to say that I didn’t even put Flickr in the running in the race to do the right thing. Consider me suitably chastised.

Anti-pattern begone

Last week Google announced something called the Contacts Data API. This makes me a very happy camper indeed.

I’ve made no secret of my loathing for the password anti-pattern. Asking for a GMail username and password on a third-party website is just plain wrong. I’ve said it before and I’ll say it again: it teaches users how to be phished. I spoke about this at the Social Graph Foo Camp, naming and shaming implementors of the anti-pattern:

Brave representatives from Facebook, Plaxo, Twitter, LinkedIn, Dopplr and Pownce showed up to be named and shamed (though most of the shame was reserved for Google in not providing an API for contacts).

To be honest, the impression I got from Google was that I shouldn’t hold my breath but now that they’ve stepped up to the plate and provided an API, there’s really no excuse for websites to ask users to enter their GMail username and password. The API uses AuthSub now but Kevin announced at SXSW that it will support OAuth at some unspecified future date.

Within 24 hours of the Contact Data API’s release, Dopplr had already removed the username/password form and implemented the handshake authentication instead. Bravo, Matt!

So who’s going to be next? Place your bets now. Here are my nominations for the next contenders:

  1. Pownce
  2. LinkedIn
  3. Digg
  4. Twitter
  5. Last.fm

C’mon Leah, don’t let me down.

I’m starting to see a pattern. Whenever I bitch and moan about something, it seems to get fixed:

I think I might be suffering from some sort of reverse paranoia. The whole world seems to be out to help me.

Update: Well, shame on me for not including Flickr in the list of contestants. They’ve implemented a superb import feature that never once asks for a third-party password. Bravo, Flickrites!

The password anti-pattern

Design patterns are useful. They enable us as developers to encapsulate recurring interactions and refine them. From simple pagination right up to Ajax requests, patterns allow us to codify common conventions.

Inevitably, conventions can lead to a mentality. Clients start to request Web 2.0 standards. I have no idea what that means but it usually involves tagging, “friends” and gratuitous use of JavaScript. This kind of copycat development isn’t so bad if you’re ripping off a site like Flickr—the more sites like Flickr, the better. The problems start when web apps start replicating bad design patterns as if they were viruses. I want to call attention to the most egregious of these anti-patterns.

Allowing users to import contact lists from other services is a useful feature. But the means have to justify the ends. Empowering the user to import data through an authentication layer like OAuth is the correct way to export data. On the other hand, asking users to input their email address and password from a third-party site like GMail or Yahoo Mail is completely unacceptable. Here’s why:

It teaches people how to be .

This issue was raised by Tantek at Fundamentos Web. Rigo Wenningprivacy activity lead at the W3C—was quick to back Tantek’s position. While we can’t protect people from themselves, we have a duty not to deceive them into thinking that throwing passwords around like confetti is acceptable behaviour.

Oh, don’t worry… the terms of service for Google accounts puts the responsibility in the hands of the user:

  • Your passwords and account security
    • 6.1 You agree and understand that you are responsible for maintaining the confidentiality of passwords associated with any account you use to access the Services.
    • 6.2 Accordingly, you agree that you will be solely responsible to Google for all activities that occur under your account.

…but this isn’t a question of legalities.

I was somewhat surprised, even shocked, to see 37 Signals highlight this anti-pattern on Facebook as a smart way to connect members of the site. Simon was quick to point out the problem:

The Facebook thing isn’t a smart way of connecting members, it’s a horrible precedent that teaches users to be phished. Unfortunately that kind of feature is so prevalent now that you’d be foolish to launch a new social network without it, but from an ethical point of view it’s distinctly unpleasant.

He’s right. The issue for us as developers is a moral question. Do we blindly follow the dictates of clients looking to “add value” to their applications even when we know that the long-term effect is corrosive? I don’t think we should. We can collectively make a choice not to erode the long-term stability of our users’ data. Sure, the particular site you’re working on might not have any nefarious plans and the next site might claim to be secure, but over time we’re creating a climate conducive to cultivating honeypots.

Morality (or ethics) is not something that’s usually discussed alongside Web development. But Jeff Veen pointed me towards this great quote from Jamais Cascio’s talk at the Singularity Summity that illustrates the underlying truth:

To put it bluntly, software, like all technologies, is inherently political. Even the most disruptive technologies, the innovations and ideas that can utterly transform society, carry with them the legacies of past decisions, the culture and history of the societies that spawned them. Code inevitably reflects the choices, biases and desires of its creators.

So here’s what I’m going to do: even if it costs me a contract in the short-term, I will refuse to implement any kind of interface that involves asking the user for a password from a third-party site. I urge you to do the same. And if you feel equally strongly about this, make your thoughts known: blog about it, talk about it… you might even want to make your position clear in your terms and conditions. As the Naked Yak blog so eloquently puts it:

With the endless possibilities of the social web it is easy to fall into the trap of going for broke, applying everything in life to a particular application or piece of software that seems to enhance it. From now, I will always ask the question “Will this have a positive effect on my world?” rather than “What could I pull into this new tool?”

Update: For all the people saying yeah, but no, but yeah, but we need access to users’ data, please read the post again and this time, pay attention to the part about OAuth. See also:

I don’t know how much clearer I can make this: the end result of exporting data is desirable; teaching users to hand over their passwords to any site that asks for them is not. There is no excuse for asking for a third-party password on your website. You’re doing it wrong. That authentication must happen on the third-party site.