They start mind reading, is what they do.

“Mobile users want…” is how they start, and then they make sweeping generalizations about what all mobile users want because of the real-world situations phones are used in: patrons just want directions and hours (as Harvard Libraries used to believe), mobile-friendly databases, a map of the stacks, and contact information. They don’t say how they know this, because they’re just guessing. And behind that guess is an assumption about mobile users and context.

Context

Context is the real-world situation you are in while using the website. The most popular belief about mobile context is that mobile users are distracted, on-the-go, browsing with one eye and one hand.

The problem is that this isn’t how people use their phones.

We can start with your own mobile use. If you are a smartphone owner, you probably use your phone to browse the web at times when you are not “on-the-go,” or distracted, or on a crummy connection. I do almost all of my web browsing on my iPhone, laying on my couch, sitting on campus eating lunch, or sitting in bed. At these times I’m focused, I’m stationary, and I’m on a fast connection. And I don’t know about you, but I was more than a little frustrated last year when I went to the Harvard Library site and was offered only directions and hours¹.

But I’m not a typical user (more on that later), and we know that the plural of anecdote is not data. So let’s take a look at the research on mobile contexts².

As early as 2010, surveys of Smartphone owners showed that the typical image of smartphone use was flawed. According to the 2010 Compete Quarterly Smartphone Intelligence Report:

• 84% used their smartphone at home
• 80% use it at for random downtimes
• 76% while waiting in lines
• 64% at work

These contexts are not what we would expect based on our typical view of the harried smartphone user. In 2011, Google conducted a study that showed that 39% of smartphone users admitted to using them in the bathroom (which means that 61% of smartphone users are liars).

What’s more, the Google study showed that 77% of smartphone users use them for searching—more than any other activity except for general web browsing. And there is no reason to think people won’t search the library if giving an opportunity. In fact, many don’t have a choice.

When libraries talk about the digital divide, they often talk about users with no access to the Web except for the public stations at the library. But a new kind of digital divide has sprung up. In 2011, studies by On Device Research and the Pew Internet and American Life Project show that between 20 and 25% of smartphone owners in developed countries only go online using their phones. In addition, according to a recent Pew report, 46% of American adults owned a smartphone as of February 2012. As Josh Clark points out, “that’s north of 11% of adults in the US, or about 25 million people, who only see the web on small screens”. The numbers are much higher in developing countries³.

Intent

“But people don’t want to search the library on their phones!”

This is the response I’m usually given when I bring out the data on context. But now we’re not talking about context. Context is the situation you find yourself in out in the world. What our disagreers are now talking about is intent, or what the user wants or needs to do with their phone. And that’s a different beast⁴.

There was a time when no one thought phones would be good for shopping, but just look at the revenue coming through mobile apps and you’ll see that this isn’t true. In 2011, Paypal had over $4 billion worth of mobile payments, and eBay topped $5 billion in sales through mobile. And that isn’t 5 billion $1 sales, either. eBay confirms that 3-4 Ferraris are sold each month on their mobile app.

Now, in the library we can’t intuit what users want or need to do. But we can turn to our friend user research to get a good idea of that they want to do.

Analytics

Your users are already trying to do the things they want, even though your site might not be helping them along. Get a heat-map generating analytics tool like Reinvigorate to see where people are trying to click. (This is how we eliminated most of the link farm on our home page. When I have more political capital to spend, we’ll kill the rest.) Look closely at your search logs and site analytics to look for patterns. We found a large number of searches for databases in our Summon search logs, which told me that users are taking us at our word when we say they can search for “Everything.” We’re redesigning our search landing page to take advantage of this existing user behavior.

User Interviews

Ask your users, because they are not like you.

Every design project is an exercise in exorcising subjectivity from a team of people with very strong opinions.
Erika Hall, Mule Design

Our users don’t want most of the things we think they want. Even if you’re an old hand at user-centered design, they will surprise you. (I never saw using the search box to find a database coming.) Interview a variety of different users, and ask smart questions. Use the answers you get to build composite personas of different types of users. Whenever you are stumped about how to get past a design problem, go to your persona. That will help guide you to user-centered thinking.

If you need to get started with user research, check out Observing the User Experience by Mike Kuniavsky.

Usability Testing

It’s like a broken record with me, isn’t it? Test your website so you can see how people use it. Test it with a variety of devices. Don’t get fancy, just do it. I’ve already said a lot about this.

One thing that came up in a recent test involved the “ratings” LibGuides offers to users on link lists. A few of the students that tested the site thought the ratings were generated by librarians, and wondered why sources with 3 or fewer ratings were even listed. When told that the ratings were generated by fellow students, they were shocked. The thought of their peers vetting research sources for them was disconcerting.

Never would have seen that coming, either. Several of our librarians removed ratings from their LibGuides because of this.

Understanding user needs is an iterative process. Don’t interview half a dozen students and then use the same personas for the next decade. Do new interviews every year. Do monthly usability tests. Test and iterate, don’t redesign. You’ll keep up better. The smartphone market is just 6-7 years old, and it’s already changed the way people use the Web. Your users will thank you for it by continuing to use the library website.

1. Ok, so this was in 2010 when the mobile site launched. I know I should let it go. After all, they have some limited searching capabilities now on the mobile site. But like most smartphone users, I don’t soon forget a bad experience. ↩
2. I first learned about much of the data presented here through Luke Wroblewski’s excellent series “Data Monday”. You should probably also read his book, Mobile First, since it is the smartest thing written about mobile web design I’ve found. ↩
3. Check out On Device Research’s fascinating report on the “Mobile-only” generation in China. After all, there will be more mobile-connected devices than people on earth by the end of the this year. (Eek!) ↩
4. The distinction between context and intent was made by Josh Clark in his super smart response to Jacob Nielsen’s arguments for separate mobile sites. ↩

We have a lot of tools we use for internal use, but we can’t use Active Directory to log in due to IT restrictions: Libstats, instruction statistics, our home-grown Library Labs CMS, our Sustainability Challenge game, and a new tool called CookieWatch that helps promote a culture of food sharing and notifies you when a coworker has brought in a snack. The problem is that all of these tools require different logins. This is annoying and silly.

So, I decided to do something about it.

A solution presents itself

IT has let us connect several of our services to Active Directory: Illiad (ILL), Ares (Course Reserves), Millennium (OPAC), and EZProxy. Of these, EZProxy isn’t tied to a single service, but rather authenticates users against Active Directory (or technically, LDAP), and then forwards them along to a specified service².

I remembered an article I read a while back about how to turn EZProxy into a single sign-on system. Written in 2009 by Brice Stacey, it was more of a proof-of-concept article than a documentation of working code, but the snippets he provided were enough to get me started.

Since all of our internal login systems require a session variable for the username, I figured we could use EZProxy to generate the user session variable we could replace our existing login system with EZProxy³.

Configuration

Brice’s plan revolved around EZproxy’s UserObjects, which are configurable blocks of session data that EZProxy can generate for a user session. EZProxy lets you set all kinds of session variables in a UserObject. To use them, though, we have to set them up in the EZProxy configuration. You’ll need to generate a secret key so that EZProxy knows that your login request is legitimate. You’ll also need to know the URL of the application you want EZProxy to authenticate for. On this example, we’ll say it’s http://example.com. We’ll also say that your EZProxy URL is http://ezproxy.mylibrary.edu.

Add these lines to your EZProxy config.txt to activate UserObjects:

Option UserObject
Option UserObjectTestMode
LocalWSKey kjshf9hkauy392jlkncq3FBC3F27F2CD4CBA25B0BE858F2A5C3823FEAB33kjyw9uhakjkjashd39uh
RedirectSafe ezproxy.mylibrary.edu
RedirectSafe example.com

Now we also need to add the URL of your app to EZProxy’s white list, so add another set of lines like this:

T My Awesome Application
U http://example.com
DJ example.com

See OCLC’s EZProxy manual for more on how to set up your config.txt file.

Now we need to tell the LDAP server what goodies we want in our UserObject. For this test, I just want the username, so I’ll add the following line before the /LDAP in users.txt:

Set session:uid = login:user

Now we have EZProxy set up, so we need to handle the session variable once EZProxy passes it to us.

EZProxy UserObjects

EZProxy UserObjects are XML elements that you can manipulate. I used a cURL function Brice wrote to grab the object:

<?php
    $wskey = 'kjshf9hkauy392jlkncq3FBC3F27F2CD4CBA25B0BE858F2A5C3823FEAB33kjyw9uhakjkjashd39uh';
    $url = $_GET['token'] . '&service=getUserObject&wskey=' . $wskey;

    $ch = curl_init();
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); // Won't fail on errors
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

    $o = curl_exec($ch);
    curl_close($ch);
?>

Note that the secret key you added to config.txt should be the same as the key in $wskey.

The userObject will be stored as $o. If you’re only grabbing the user name here, your UserObject will look like this⁴:

<?xml version="1.0" encoding="UTF-8"?>
<userObjectResponse>
    <serviceStatus>OK</serviceStatus>
    <userDocument>
        <lastAuthenticated>2012-04-23T16:24:04Z</lastAuthenticated>
        <uid>USERNAME</uid>
        </userDocument>
</userObjectResponse>

To get the username, we just need to parse the XML and specify what we want:

<?php
    $data = new SimpleXMLElement($o);
    $user = (string)$data->userDocument[0]->uid;
?>

Putting it all together

Now we want to start a session, save the username as a session variable, and redirect back to the application. Simple:

<?php
    session_start(); // Open a new session
        $_SESSION['username'] = $user; // Save the session variable
    session_write_close(); // Make sure the username is written before we redirect

    $new_url = $_GET['newurl']; // URL of the app to authenticate

    header('Location: ' . $new_url);
?>

Because we are building these tools for internal use, we don’t need to write anything to handle new users who haven’t registered. We have a small users table in our database that helps us link users to several of the existing applications we’ve built, and the existing routine for grabbing user data comes from session variables and cookies. So we needed minimal tweaking to our existing apps to move logins to EZProxy.

Building the URL

EZProxy works by passing URLs to the login script in a GET request, so that after authentication you are directed to the service you logged into. Using EZProxy to log in to your own system is no different, but we need to include a few extra parameters, including a URL to build the UserObject, the URL for our script that will parse the userObject (EZLogin.php), and finally the URL of the app or site we’re logging into. Our new URL will look like this:

https://login.ezproxy.mycollege.edu/login?url=https://login.ezproxy.mycollege.edu/userObject?service=getToken&returnURL=http://PATH/TO/EZlogin.php&newurl=http://PATH/TO/APPLICATION

Going to this link will first take me to EZProxy, and after logging in I’m directed to their UserObjects scripts, then to my EZlogin.php script, and finally to my application, with a session variable set for the user’s username.

Now we’ve managed to use EZProxy to log into a system we built, which means our users don’t have to remember 13 different passwords to do their jobs. It also means we have a lot less code to worry about, since EZProxy does the heavy lifting for us. Next up, getting EZProxy to play nice with Illiad, Ares, and Millennium⁵.

You can grab the whole EZlogin.php file at Github, if you like.

1. Penn State highlights this problem by sending their “My Library Account” link to a modal window asking the user to choose which system they want to log into. This solution seems forced to me, and puts the burden on the user. In addition, I think by presenting the systems in this way, the library is only highlighting the lack of integration the systems have. ↩
2. For anyone outside the library, EZProxy is how we authenticate our users before sending them on to databases, journals, and other subscription services we provide. ↩
3. I am not a security expert, but I did try my hand at exploiting this system by bypassing EZProxy and setting the session variable. All of my attempts failed, leading me to believe that it was reasonably secure. If you spot a huge security hole in this plan, please let me know: @mreidsma or reidsmam@gvsu.edu. ↩
4. You can see a more beefed up version of the UserObject on the OCLC wiki. ↩
5. Campus is planning to upgrade to Banner 9 within the year, which requires CAS, so maybe this whole project will be moot if they implement it outside of the Banner environment. ↩

There is only one problem with the fold metaphor in web design: it doesn’t exist.

There is no page

When designers first started working on the web, they brought their metaphors from working with print to the screen. Thus, we’ve thought about web pages as “pages” for the past 15 years, imbuing them with many of the properties of their paper analogues, most notably a fixed size. We’ve designed first for screens that were 640 pixels wide, and then 800 pixels wide, then 1024 pixels. Then we embraced grids and settled on 960 pixels. The whole time we imagined our users seeing our page on a screen the size of our canvas. We started paying attention to heights, so that the most important content made it into the top 480, 600, or 768 pixels. Thus, the fold.

And then came the iPhone.

What’s the screen size again?

Suddenly, we realized that our users might see our websites on different screen sizes. But because we had this fixed canvas mentality, we simply added a second screen width, 320 pixels, to our fixed “desktop” width.

The problem is that there never was a fixed canvas to begin with.

Users have always visited our sites with different resolution screens. This is how we settled on our design widths, after all. Once enough folks came to our sites with an 800 x 600 resolution screen, we switched our layout. We knew that a handful of users had screens smaller than our designs, and that a handful had larger screens. But we chose to focus on the majority of screens that visited us, and design for those.

But once again, we were assuming that our users visited our sites in browser windows that filled the width of the screen. We were designing for screen sizes, now browser windows. Essentially, we ignored the fluid nature of the web in favor of a rigid, familiar metaphor that gave us the illusion of control.

Screen size variety expands

Well, after the iPhone came the iPad (768 pixels x 1024 pixels), Android phones (varied sizes), the Kindle, the Nook, the Kindle Fire, the iPhone 4’s retina screen, and now the iPad 3 with its crazy high-resolution retina display. Next month will bring another slew of devices with different screen sizes and resolutions. We’ll have to add a dozen, or two dozen screen sizes to our list of “fixed” canvases to design for if we still with the page metaphor.

I think it’s time we drop it. There is a better way.

You Can’t Control the Viewport

For years we’ve pretended that screen size equals browser window size, and it took the proliferation of mobile devices to make us realize our mistake. With the advent of Mobile Safari on the iPhone, Apple popularized a term for the browser window width: the viewport. Now we can stop pretending we’re designing for screens and accept the fact that we’re dealing with viewports. Only our old metaphors aren’t going to help us anymore. Because we can’t control the viewport.

So what do we do?

The Fluid Web

Last year at An Event Apart Boston, Jeremy Keith said something that’s really stuck with me: “the web has always been fluid, we just chose to ignore its fluidity.” We believed deeply in our print metaphor, and although we’re starting to see the limitations of the metaphor, the web itself hasn’t fundamentally changed.

In fact, if I were to choose the my greatest professional influence, I might waffle between Jeffery Zeldman’s seminal Deigning with Web Standards or Ethan Marcotte’s terrific Responsive Web Design article, but in the end I think I’d say John Allsopp’s 2000 article “The Dao of Web Design” has done more than anything else to shape me as a web professional. Allsopp turns the prevalent thinking of the day (and today) on its head:

Perhaps the inability to “control” a page is a limitation, a bug of the web. … Let’s look at this through the other end of the microscope. The fact we can control a paper page is really a limitation of that medium. … The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility.

The current best practice in making pages that are, in Allsopp’s words, “adaptable” is Responsive Web Design. Ethan Marcotte coined the phrase to describe this technique of designing adaptive pages with three technologies: fluid grids, flexible images, and CSS3 media queries. Designing sites to be responsive (like this one) can save organizations a lot of overhead and maintenance, since you’re not maintaining content for two different sites (a mobile site and a “desktop” site), and you’re also not losing the battle to do device detection to direct users on different devices to the appropriate site¹. It’s all one site, and it works on any device².

The Fold is a Content Problem, Not a Design Problem

In general, we worry about the fold because we want to make sure that the most important information is seen by all of our users. This is a huge issue for libraries, especially those that build link farms on their homepages. We have a lot of resources, and we want to make sure everyone knows about them. But our users see a pileup of list items on a website and they run for the clean, simple embrace of Google. You see, we have a content problem in libraries. We try to show too much of it.

I redesigned our library website last August. A few months before I went live, I started talking about cutting about 70% of our content. Everyone freaked out. “We need those pages!” they said. “They get used a lot!” they insisted (despite analytics evidence to the contrary). “I teach using those!” I stopped mentioning cutting content.

But I still cut over 70% of the content on our website. And so far, no one has noticed³.

The pages still live on the server, where I monitor their use (almost none). I removed all of the links to them from our website. I was going to wait until it had been a full year to tell everyone that I killed their precious content, but I figure an academic year is plenty. Next week I’ll delete them from the server forever and no one, especially users, will care one bit.

The point? You most certainly have too much content⁴. And if you find yourself shuffling links around so that your important ones can live “above the fold,” you need to think more about your content than your design. I’ll write more about that soon,

For now, here are some rules for dealing with content below the fold:

1. Get rid of it.
2. Go to rule 1.

Your users will thank you for it⁵.

1. Shameless plug: I’m leading a workshop on Responsive Design at ALA Annual (for LITA) this year, Sunday June 24 from 10:30 until noon. You should come. I promise you’ll have fun.  ↩
2. If you marry responsive web design with progressive enhancement and think of layout as an “enhancement” (as Marcotte has been suggesting lately) you’ll find that your site will work on pretty much any device that can render HTML. Even an Apple Newton, for instance.  ↩
3. Ok, one person has mentioned a missing page to me. But he wasn’t one of the freak out folks, and when I told him it was gone because no one usd it, he said “Oh, that makes sense.”  ↩
4. It’s such a cliche that library websites are so cluttered that Aaron Schmidt was surprised when he did a content audit that revealed a pretty modest amount of content on a library website. ↩
5. Some librarians will hate you, but as Tina Fey said, “as occupational hazards go, that’s much better than getting your arm caught in the thresher.” ↩

I do keep a running log at work. I’ve done it for years, and it’s been a great way to look back on a week or month that felt unproductive and see that I really did get some things done (or not, as the case may be). Until recently, I kept the log as a plain text file on Dropbox, and I’d manually record the tasks I’d completed as well as any meetings or conversations I’d had that I might need to remember.

As plain text, the file was easy to work with. I could view and edit it on any computer as well as my phone. It was easy to grep, given that I remembered what I called that weird task I did last year. But as plain text, I couldn’t easily visualize the data as a calendar (which is what it was), and data entry relied on my remembering to type the tasks into the log.

To improve my ability to visualize some of the data, I tried out Felton’s site Daytum, but I was sidetracked often by forgetting to add data manually. I figured there had to be a better way.

Automating

Although we use Basecamp for managing projects on our team, for my day-to-day task management I waffle between paper and Taskpaper. Paper is difficult to automate, but Taskpaper is scriptable, and I was already making heavy use of a few Applescripts to augment Taskpaper’s features. So, I could easily set Taskpaper to log completed tasks to a separate text file, or even grab a ready-made script that would do it for me¹.

But this didn’t solve the problem of tasks completed from Basecamp, or the other things I logged. Nor does it give me a better way of seeing this date-based data. What I needed, I realized, was for all this stuff to be in a calendar.

The Calendar as Archive

A while back, Marco Arment pointed out the problem with skeuomorphic calendar designs—you care very much about the data on today’s date, and a little bit about the data for the next few days. But you don’t really care about anything else, especially days that have passed.

I thought about how valuable those day slots could be if it contained more than a history of the appointments I’ve had. In fact, past calendar days would be invaluable if they tracked things that matter to me (and to the tenure review committee) about what I did that day besides sit through an hour of committee drudgery: Tweets to colleagues at other institutions, Github commits, completed tasks, notes about meetings, foursquare checkins (to show what campus I was at), etc. In short, I wanted an electronic diary, and I wanted it to be automatic.

If this, then that

ifttt.com is a web service that lets you link two separate tasks together: if this happens, then do that. For instance, you can create a task that says if someone tags me in a Facebook photo, then save a copy of that photo to my Dropbox.

One of the recipes that came to mind when I was looking to log my day to my calendar was for archiving all of your Tweets to Google calendar. This was exactly what I was looking for. If I could log Tweets, maybe I could log everything else!

I started with the services that integrate with ifttt.com that I use in my daily work: Twitter, RSS (for Github, my blog articles, Basecamp changes, Instapaper favorites), and Google Reader. For kicks, I added some personal stuff as well: Last.fm favorites, Facebook posts & photos, and Soundcloud favorites².

Now I had meetings, Github commits, articles I post, articles I’ve read and flagged for later use, Tweets to colleagues, location changes, and a handful of personal actions logged to my calendar, automatically, at the moment they happened in real time. But the big missing link was tasks.

In which I cobble together other people’s code

I knew I couldn’t automate tasks written on paper, so I made the choice to move to Taskpaper full-time. I just needed a way to trigger ifttt.com into logging the tasks on my calendar. They offer 2 easy ways to trigger actions: RSS and email. At first I thought about writing an Applescript that would update an RSS feed living in my Dropbox Public folder every time I completed or archived a task³, but I knew exactly how to write an Applescript to send emails. Go with what you know, they say.

My pal John Fink once told me that he does everything possible to avoid writing code. I tend to feel the opposite; I love writing code. But often this distracts me from solving a simple problem. This time I knew I could find most of what I needed in existing Applescripts and I could easily knock together the code for sending the email.

First I visited the Taskpaper Applescript wiki, and looked at Stephano Rauch’s script for archiving done tasks to another file, becuause I liked his code for checking that an Archive project existed. Then I grabbed a routine from the guy who inspired my desire to log everything in a format more appropriate to grouping things by time: Brett Terpstra. He wrote a script that archives his done tasks to Day One every night at 11pm, and I thought I could use his parsing routine for grabbing and reformatting done tasks. All I needed was the script for sending out the email, which was trivial. The final script is below, or you can grab it on Github:

    set archivedTasks to ""

    tell application "TaskPaper"
        tell front document

            -- This next section from Stefano F. Rausch's Archive Entries Applescript
            -- http://www.hogbaysoftware.com/wiki/ArchiveAllOrSelectedDoneEntries

            -- Make sure there is an archive project
            if not (exists project "Archive") then
                make project with properties {name:"Archive"} at end
            end if

            set archive to project named "Archive"

            -- This whole function is from Brett Terpstra's excellent Taskpaper to DayOne script
            -- http://brettterpstra.com/log-taskpaper-archives-to-day-one/

            repeat with _task in search with query "project != Archive and @done"
                if entry type of _task is not project type then
                    -- remove common tags that won't matter after archiving
                    repeat with _tag in {"na", "next", "priority", "waiting"}
                        if exists (tag named _tag of _task) then delete tag named _tag of _task
                    end repeat
                    -- if there's no project tag on the task, 
                    -- add the task's current project as a tag
                    if not (exists (tag named "project" of _task)) then
                        tell _task to make tag with properties {name:"project", value:(name of containing project of _task as rich text)}
                    end if
                    -- append the full text of the entry, including tags, to our log
                    set archivedTasks to archivedTasks & "Tasks: " & (text line of _task)
                    -- archive it
                    move entry id (id of _task) to beginning of entries of project "Archive"

                end if
            end repeat

        end tell
    end tell

    -- Check to see if there were any completed tasks
    if archivedTasks is not "" then
        -- Send mail to ifttt to archive to calendar
        tell application "Mail"
            set theNewMessage to make new outgoing message with properties {subject:"Completed #task", content:archivedTasks, visible:false}
            tell theNewMessage
                make new to recipient at end of to recipients with properties {address:"trigger@ifttt.com"}
                send
            end tell
        end tell
    end if

I then created a task on ifttt.com to look for incoming emails tagged with #task, and then to log those to Google Calendar. The final step was to map the default “Archive Done Tasks” keyboard shortcut, ⌘D, to run my new script. This was most easily done with Quicksilver, which allows you to overwrite hot keys. Now I can continue to use Taskpaper as I always have, but when I archive my completed tasks they’ll automatically be logged to Google Calendar.

Nerdy. And useful. And with the Google Calendar API, potentially more useful when I get my tenure portfolio ready later this year⁴.

1. I loved this feature of todo.txt. ↩
2. Music is a great trigger for me. I can often forget a technical solution for something at work, only to remember it when I hear the song that was playing when I first thought of it. So you could argue these are work related. ↩
3. This is still the best solution, I think, which I’ll write when I get a chance. ↩
4. I’m just going to call it right now: I’ve waste a lot of time later this year trying to make all this data look great, like a Felton Annual Report. You heard it here first. ↩

Of course, we’re not the only ones who have made such a guide, nor are we the only ones sharing ours.

We were originally inspired by Mailchimp’s UI Pattern Library, but many others have cropped up lately, including Twitter Bootstrap and the excellent (and highly detailed) Starbucks’ Style Guide. Ours is a tool that helps us maintain a consistent look, feel, interaction model across all of our sites, including those dragons hosted by vendors². It’s a win for us, because we don’t have to think about presentation and can instead focus on content. And it helps maintain consistency with several people writing code and shipping projects. (Not to mention it makes launching a new project really fast, since 75% of the CSS will be done by including the pattern library.)

Getting Started

If you want to get started with a pattern library, you can download the source of our pattern library or grab Jeremy Keith’s excellent Pattern Primer, a simple php tool for turning code snippets into a pattern library. And as always, share yours so others can learn from what you’ve done.

1. That is if we assume anyone thought about design in the first place. ↩
2. I should mention that while we have the guide, now, we haven’t quite made it through all the old code to get everything on the same page. Ahem. ↩