Before starting, please note that this post is quite long. A table of contents is after the jump for moving to specific areas of interest.
When talking about what I do with people who don’t know or care much about things like information architecture and interaction design, I use the metaphor of being the bridge between a vision and all the things that need to happen to make it a reality. Without, I like to add, losing the spirit and values that drive the idea.
Now, I have the opportunity to show what that means in detail with a new service I’ve been quietly working on for Larry Halff over the last few months: the just-launched thmbnl.com.
What-dot-com?
Background
Requirements and Roadmap
The Sitemap
The Master Flow
The Wireframes
The Homepage
OpenID-Only
The Account Page
Authorization Details Page
Innovating on OAuth
Rounding Out the thmbnl Experience
The End of the Beginning
What-dot-com?
Another website with a wacky name. It’s true. But if you’re involved with web application development, it’s a good one to know about. The 20-second story is that another application submits a URL, and thmbnl serves a small picture of the page contents for use by the requesting application. Through an API, thmbnl provides access to a thumbnail-making engine, and the site is the gateway for people to gain and manage their access. That idea is likely quite abstract for those not into the nuts and bolts of web apps, so a quick illustration might help:
A conceptual overview of thmbnl
Making all this happen presented some challenges in product strategy and interaction design, which are the meat of this post. As a bonus, the demo is already happening: thmbnl.com has been quietly serving thumbnails for Ma.gnolia for the past month, with only two sharp-eyed members spotting any .
And, on this page only (for now), a proof-of-concept alpha javascript from Adam Roth, thmbnl’s developer, shows a tiny thumbnail beside off-site links. Clicking the tiny image gives a larger preview, both from thmbnl’s standard offering, showing the destination clearly. Try it out with this link to the
Darren’s classy blog.
Think of all the accidental clicks to sites and associated drama; if only thmbnl had been here earlier, we could have helped.
Background
We’d originally spec’d thmbnl to replace a third-party service providing thumbnails for millions of bookmarks on Ma.gnolia. Early into the project, Larry realized that thmbnl would face the same issue as many web applications: its maximum capacity would be rarely utilized in normal day-to-day operation. To make use of the excess thumbnail-juice, he decided to add a public-facing side as a utility service, and broke ground with the name and domain thmbnl. Some people drop one vowel to stand out – we dropped them all.
We established key requirements and contracted graphic designer Cindy Li to create a look and help us nail down a brand. Cindy played a pivotal role in making thmbnl, and will also be writing about the process she followed for this project. Where the walkthroughs intersect, we’ll link between the two posts to show how the deliverables connect.
Before diving in further, I have to say thanks to Larry for giving us the go-ahead to openly share how we work, including some of the design documents that went into the project. It’s a great opportunity to talk about work that I’m excited about, and a chance to share some of the innovations we made in thmbnl.
Requirements and Roadmap
- Make something to solve our immediate needs: accurate images, flexible presentation, enough capacity to keep up with Ma.gnolia
- Don’t try and solve every thumbnail scenario out there with plugins for every platform, etc. instead, enable others to fulfill their specific needs
- Communicate the focus and do-it-yourself nature of the service to set the right expectations.
- Be fun and friendly. This sounds easy, but becomes critical when deciding how to handle out-of-capacity scenarios that would affect user’s public web pages.
- Build for the state-of-the-art web
- Provide good customer support with minimal extra overhead
From those requirements, we made a few key decisions about how to proceed:
- A Ruby on Rails app that snapshots every URL submitted in 5 sizes of image for current and future uses, and doesn’t cheat with just the top page of the site.
- An API+code library offering. To put it differently, we don’t have code products that solve thumbnail problems; we enable custom solutions to be written and managed by web developers. We also started out with 5 service levels and eventually pulled back to 3 for launch.
- A minimal public-facing website. Having a site that does everything it needs to in few pages was key to thmbnl’s brand as a compact utility.
- Use informal but friendly language and graphic design in the site.
- OpenID for user authentication, OAuth for application authentication, and the aforementioned API.
- Use Satisfaction to answer questions for everyone, a wiki for sharing documentation and public code projects, and email for priority support for premium customers
With the roadmap in place, my involvement turned to information architecture and interaction design.
The Sitemap
The first sitemap draft went to extremes to minimize the number of pages, including an audacious attempt to combine the canonical About, Support and Terms of Service on one page. After finding, by mapping features to pages and thinking about how much is too much to try and do on any given page, we found we could capture the entire service in about 7 pages, with 3 of them carrying most of the load. The only substantial change in moving to a final draft was to relax the compression of the service info sections, and break them out into their own pages as people would expect to find them. Even when striving to be compact, there’s still a need for some leg-room. So the sitemap we ended up with had changed very little from its first draft (the numbers refer to wireframes of the specific pages, which you can see in the sections below:
The thmbnl Sitemap
The Master Flow
To help get a handle on the scope of interaction, I like to try and fit the entire lifecyle of a person’s involvement with the project into a very high level flowchart. While flowcharts seem a bit folksy and mine look very old-fashioned, I find nothing gets my own head organized better, and that their simplicity makes them addressable by non-technical teammates as much as the developers.
The main events in the lifecycle of a thmbnl account
What’s somewhat unusual about thmbnl is that all the interactions that take place in the website are not the main reason for its use. To put it differently, everything that happens on thmbnl.com is to support a customer’s use of the site’s core functionality, which is makin’ thumbnails. The value is realized when a customer’s websites and applications properly show thumbnails along with other content, not in the thmbnl.com site itself. Once we had a shared understanding of the scope and flow of things from the flowchart and sitemap, I had enough to start into the details.
The Wireframes
Knowing the pages we needed to build, I dove into making the wireframes. The way that I work with wireframes is to treat them as a detailed expression of the information architecture and most of the interaction. They show the things that need to be on the page, their identities and behaviour. Used in this way, they wireframes become the blueprints for the software that guide not only the programming but also the graphic design. Although I created wireframes for every page on the site (usually there are a few pages that can be left to common sense and convention), I’ll be focussing on those 3 pages that carry the key interactions in thmbnl:
- The Homepage
- The Account Page
- The Authorization Details Page
The Homepage
A few years back, I read a manifesto for efficient website design. It made a bold claim: the homepage is your Website’s least important page. This actually makes a lot of sense: the reality of web surfing often brings us to new destinations through the side-door: a product page, a forum posting, but rarely the homepage. While I haven’t thought about that statement for a while, it’s embedded itself deeply enough into my thinking that, like all rules, it can be sidestepped under certain conditions, and I think that thmbnl fits those conditions.
Given that thmbnl isn’t a content site, a visitor is unlikely to land anywhere but the homepage, and if they happen to stray they’ll be at the homepage within a click or two of their first visit. Combined with the need to reflect thmbnl’s compact nature, I set out to get everything a visitor needs to know if they want to explore more, or move along knowing it’s not for them. My first take was, admittedly, not very original:
thmbnl Homepage Wireframe, Take 1
Chris Messina, who’d been helping us with advice and insight along the way, suggested a different approach that came closer to the mark:
thmbnl Homepage Wireframe, Take 2
This design didn’t try to force our offering into a 3-act homepage, but it did got me into a sticky point: I’d need more space than I had to explain why thmbnl is a great idea, meaning one or more extra pages of overt marketing content, and as such working against that goal of a compact site. In this case the save was a technical one: use AJAX to create a region of the homepage that could paginate through all our reasons to use thmbnl. The result is the current homepage:
The thmbnl Homepage at Launch
This design gives the flexibility of changing marketing material without adding any new pages. The space for talking about what the service can do for customers offers more than enough room to play and experiment with different ideas over time, including embedded demonstrations. But most importantly, the homepage communicates the service, right up to plans and pricing. A light touch of AJAX allowed us to describe the service without crowding or trying to entice visitors into more navigation and pageloads. The result is a rich, but tightly focussed homepage, where you can do the two things that make sense there: learn about thmbnl, and sign in.
OpenID-Only
The decision to only use OpenID might seem strange when opening your doors and hoping for customers. Wouldn’t we get more registrations by also providing a traditional user-name+password? It’s likely that we would, but just as likely that many of those other people wouldn’t be the ones we want to reach. OpenID is a growing change in the web, and as such the people most likely to be using it are the ones best positioned to take advantage of what thmbnl offers. It’s also a chance to advance OpenID just that much more, showing by example where we see things going.
The most concrete benefit of the OpenID-only strategy in its impact on feature design is that it’s allowed us to support webmaster and enterprise teams who need to work from the same thmbnl account without adding weight to the account management features. Although we don’t have the permissions gradient that corporate software often provides, we have a simple, one-field interface for attaching OpenIDs to an account. OpenIDs for those people who leave the team or no longer need access are removed from the same place. Under a traditional user name+password approach, we would have had at least one or two more pages to manage multiple users on the same account.
Obviously, our choice to exclusively use OpenID won’t please everyone with an interest in what we’re doing, but narrowing the door lets us focus more on the people we built thmbnl for. On top of the other benefits, this practical reality really made the decision for us.
The Account Page
As a utility, the account page is the center of thmbnl’s interaction for signed-in users; everything starts and leads back to this page, throughout the lifecycle of the account. The activity that takes place on the Account page is really about access:
- who can access this thmbnl account? (answered by the list of OpenIDs)
- what software can access this thmbnl account? (answered by the list of Authorizations)
- how much can this thmbnl account be used? (answered by the Service Plan)
Accounts are structured to strike the right balance between separation and consolidation of management tools, with web developers specifically in mind. Many web masters have mutliple clients, and we wanted thmbnl to make it easy to give all those clients thumbnails while keeping client usage organized and easy to manage. With OAuth authorization control of each installation that uses the thmbnl account, we give web masters (and their staff) the ability to turn on and off access per-installation, per client, all from that one account. Again, a diagram illustrates the arrangement of actors and equipment:
A conceptual overview of thmbnl accounts
The first time someone signs into thmbnl, we capture some essentials needed to create the account: a company or person’s name, an email address and permission to communicate using that address, if we need to. We use a small form to capture that info, and speed our new friend along as quickly as possible:
Welcoming a new user
Once signed in, the Account page becomes the main destination for a thmbnl visitor. Discussion and analysis had shown three key tasks: managing the account itself, managing the service plan, and managing applications authorized to use thmbnl through the account. The design for this page ended up with four sections:
- Account Basics
- OpenID
- Service Plan
- Authorizations
Wireframe for the Account page.
We broke out OpenID into its own section to draw attention to multple OpenID association, which is a relatively new concept. This move also simplified the area where customers manage their basic account information, as a bonus. I was concerned that the mix of information types made this design a bit dangerous, but that’s where Cindy came through again with graphical touches that supported and strengthened the information architecture:
The Account page, with the designer’s touch.
The shaded areas help differentiate zones on the Account page and keep related elements visually grouped. The eye can jump from one zone to the next, and find each stop conceptually organized.
We’ll skip the Service Plan features, as they’re straightforward and not very different from what’s seen in other web services: choose a plan, add billing information, and go on with your day. One noteworthy event: while integrating with the Cybersource payment gateway using the ActiveMerchant Ruby library to process payments, we found that subscription billings weren’t well-supported. The code that Adam wrote to address that unfortunate discovery will be released under an open-source license for use by others in the next few weeks.
Authorizations, or installations of code accessing the thmbnl account, are shown in a dashboard-style view. In the conceptual diagram, each place where you see a client’s website (or web application) is separately authorized, and can be tracked and billed for accordingly. As we happen to be at the bottom of the Account page now, we can segue to the details of a single Authorization, and exactly what Authorizations are.
The Authorization Details Page
For the web geek in you, this is where things get interesting. It’s also where things get more technical, so if you’re not so inclined, feel free to [SKIP AHEAD] to the concluding section. Every time a request is made to thmbnl, it must be though an account. This requirement allows us to track usage for billing and prevents the unauthorized use of someone else’s account capacity. The security aspect is an important one for thmbnl, so we give quite a lot of information and control over exactly how the account can be used by a given application.
The Authorization Details Page Wireframe
As with the Account page, the Authorization Detail brings a fair amount of information and several activities together onto a single page. In this case I have to admit a bit of luck, in that the tasks involved with managing an authorization were limited to single-field entries and toggles. It wasn’t hard to get them all together, and once again Cindy’s highlight treatment helped us visually organize and call out the most important thing to know at a glance: namely, is this thing on?
The finished Authorization Details Page
Innovating on OAuth
As mentioned above, thmbnl is full-on-OAuth, so our assumption was that for each installation of an application or plugin that needs access to the account, the process would be:
- Download or Create the thmbnl-integrated code
- Initialize (run for the first time), and be prompted to authorize access
- Sign into thmbnl and grant access
- Enjoy
While chatting in
Pibb about
downloading and plugins one afternoon, Larry had a flash of inspiration about authorizing code libraries and plugins that we supply: because they’re obtained from inside an account, we could automate the authorization step and dynamically add the . This is required for the code libraries, but for samples and any future downloads that we provide, it’s an option that improves the OAuth user experience.
Rounding Out the thmbnl Experience
So far we’ve covered the brand formation, the information architecture, and the nuts and bolts: accounts, authorizations, code libraries. There are some other, smaller touches that we spent time working out, particularly where we could make the experience more humane and positive.
We put a lot of work into ensuring that the experience with the site is as frictionless as possible, without being spartan and cold. As a utility service, our decisions will affect the public presentation of other people’s websites, and as such we made sure to be sensitive to that
The most crucial test of the ‘friendly and fun’ requirement is in finding a way to respond to scenarios where someone exceeds their capacity. It’s important to understand that exceeding capacity is a good thing in the world of thumbnails because it points to higher traffic for the customer. Getting onto the front page of Metafilter or Digg or another mass audience is often a cause for celebration, but also likely to push the expected need for thumbnails over the top. How we interact with those moments will define a lot of how customers feel about their experience with thmbnl.
For people using the free service plan, we don’t have much choice: we have to stop serving thumbnails when they go over the limit. Once again, I turned to Cindy to help out, and we talked about the need to come up with a generic replacement image that would not blame or embarrass the customer. We played with a few ideas, and Cindy hit on the great concept of a fish outgrowing its bowl. We tried a few different ways to word it and came up with this:
The thmbnl Over-Capacity Image
This theme was extended to the need to provide a generic image for cases where we didn’t have a thumbnail to serve, which can happen sometimes. for mostly technical reasons:
The thmbnl Image Unavailable Image. Kind of meta-ironic.
For customers on a paid service plan, the stakes for maintaining presentation are higher and we couldn’t just turn off access. The natural way out of that is to apply additional charges for the extra thumbnails. But we still wanted to make a positive connection between the customer’s successes and their experience with thmbnl. We came up with Overflow Protection, optionally added at a nominal price to a monthly service plan. Should the account go over its capacity, it’s at half the price that we’d charge for overflows. Getting a break on unexpected costs is the most substantial way we could find to share in our customer’s happiness, rather than dampen it with the necessary increase in cost.
The End of the Beginning
And that’s the (long-ish) story of how we brought thmbnl.com to life. It’s a day before our planned launch as I’m writing, and we’ve been putting on the finishing touches, like the favicon and removing sample data. While thmbnl has already passed initial tests by flawlessly serving Ma.gnolia’s needs, the real tests of our ingenuity are about to happen as we open the doors.
Thanks for reading, if you made it this far. I’m happy to answer questions about thmbnl’s design and creation process, but if you have specific inquiries of the business itself, those should go through thmbnl.com/help.
iPhone & iPod Touch UI Elements 