Corvus Consulting

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 .

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.

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

thmbnl Homepage Wireframe, Take 1

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.

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:

1. Download or Create the thmbnl-integrated code
2. Initialize (run for the first time), and be prompted to authorize access
3. Sign into thmbnl and grant access
4. Enjoy

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

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.