Corvus Consulting

Over at the Ma.gnolia blog, I’ve written on the task of re-making the global navigation menus for Ma.gnolia 2. Global navigation is one of those interfaces elements that you don’t typically notice until it fails to get you where you need to go. When it does fail, it fails with a thud. And from that, we want to make sure that major changes are thought through and don’t leave people hanging.

I found that re-working navigation for an application as large as Ma.gnolia wasn’t quite as hard as starting from scratch, but it did present some real challenges. If I have one big take-away, it would be that global navigation can’t be refactored before most of the interaction it frames has been worked out. Kind of like arriving at a destination, then plotting out how you got there, instead of the other way around.

Back in February, I posted that I’d be moving on from full-time involvement with Ma.gnolia. A minimal amount of involvement was expected to help Larry on side-projects and minor contributions to Ma.gnolia’s ongoing operation. But that situation ended up being surprisingly fleeting.

At SxSW in March, we started talking about Ma.gnolia’s long-term future. As it was, the service required ongoing balancing of a small team keeping up with a very large database and engaged member base, the sometimes-turbulent nature of web app operations, and the overarching need to better capitalize on business potential without losing a fun place to do R&D on new web techs.

The plan: make the core Ma.gnolia application an open-source product and run a service providing hosted accounts with value-adding and customization services as revenue channels. More than just opening the doors to what’s already there, Ma.gnolia 2 will be a ground-up rewrite and re-take on the way the service works, structured specifically to make numerous community and feature configurations possible. Moreover, it throws our support fully into the open-source tradition that’s made important parts of Ma.gnolia possible.

To share the plan, Larry took to the stage at Gnomedex 8 with Tara Hunt. There they talked about Ma.gnolia’s history with open technologies, and announced that we’re going to take that trend all the way. As I’m a touch behind on my writing, I can point to some headlines that you might have seen a few weeks ago in the social web media (or is that social media web?)…

• Profy takes a look at the business strategy and how they interact with key aspects of the architecture.
• John Eckman at the open parenthesis blog gives a solid and detailed overview of the announcement, and pulls some good stuff out of the charter documents.
• The Mashable scoop you may have already seen.
• And Marshall’s ReadWriteWeb article that was read widely.

And so we come to my belated follow-up announcement, which is that I’ll be working extensively in Ma.gnolia 2 to re-design features and to make a space for the open product to live. It’s the first project that I’ve worked on with open-source as such a central focus, so I’ll be looking for advice along the way. I’ll also be writing about pieces of M2 and the overall project in more detail between now and December. It’s an amazing project to round out 2008, and I’m truly excited for the chance to build on what we’ve learned in round one.

This is really just an update, but it seemed worthwhile to bring to its own shiny new post. Since SlideShare makes it too easy not to do consistently, I’ve put slides from a presentation at BarCamp Vancouver 07 into their viewer.

The big takeaway remains the same going on a year later: treat twitter as its own thing (not just a second RSS feed, as Hillary puts it when talking about Zappos use of Twitter); and, treat people’s attention with care. The only thing I’ve added is a note that Twitter has, for me anyway, has been as much or less about status and more like a group instant message tool, and as such has proven an essential part of Ma.gnolia’s and my own communication toolset.

Update: I came across a page today that presents the most pristine example of .

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.

The second of two posts on Twitter, where I’ll share how we’re using Twitter to enhance communication with the Ma.gnolia member community.

In the last post’s apologia petite (pardon my faux French) for substantial meaning in Twitter posts, I held that despite being tiny, Twitter posts can carry very significant meaning when read in the context of an established social relationship. That notion immediately suggests that micro-blogging is best done between friends and family who know each other well. It turns out though, that this isn’t strictly the case.

At Ma.gnolia, we’ve put Twitter to good use as a means of keeping in touch and staying relevant to a core group of our membership. Not all our members are using Twitter, obviously, but those who use Ma.gnolia every day are heavy web users, and as such are much more likely to be able to tame and enjoy Twitter with ease. So our expectation is not to reach all our members with Twitter, but just those who are very regularly connected.

It’s worth telling how we got started. During a big upgrade in January, we spent a couple of days getting the kinks worked out, but some of those kinks blocked access to the site from time to time. Since our blog and wiki are integrated pieces of Ma.gnolia, we couldn’t use those channels to keep members informed. And it’s not like we could send out a newsletter for each change, primarily because these momentary changes in status didn’t affect everyone and people would start to wonder if we’d lost it.

So we started using Twitter, making posts whenever there was a change worth reporting. We updated our standard error pages to point people to Twitter as a source of status updates. That got us through the rough parts, but it was a suggestion from factoryjoe that took us to making status updates a daily thing, and to maybe even throw in a cool link of the day.

All in 140 characters?

Messages for the Medium

Twitter demands that you be concise, a brown belt in précis. It also demands that you be somewhat innovative with your words, not just to get in under the character limit but also to keep your communication interesting. Seeing ‘Status OK’ almost every day would be informative, but it gets old quickly. We try to mix it up by finding new phrases to say that all is well, and when it’s not well we have the fun of fitting an artful description into a tight space.

Adding the cool link of the day is the other part of our Status OK posts. We have two advantages here. The first is that Ma.gnolia produces a short link to each bookmark we save. The second is that Twitter takes that short link and makes it even shorter, getting us in under the limit almost every time. Moreover, we make a point of thanking the person who saved the bookmark.

Today’s post was a good example.

Ma.gnolia thinks that spring has sprung, and it feels great. Live large with today’s link http://ma.gnolia.com/zalayo (Thanks fabioassis)

And 3 characters to spare! Rock on. The feedback on how we’re using Twitter has been good and folks say they like a cool link of the day. Hunting a new link down each day is a great exercise for me because it’s one more chance to explore the community and see what people are up to, but with specific purpose – I need a cool link and I need it now! It makes me enjoy the fruits or our own work even more.

Of Course We’re Friends!

Almost as soon as we got the word out that Twitter would be a status update channel for us, people started to add us as friends. Though we hadn’t seen other companies using Twitter do the same, we almost immediately started to reciprocate. We made a point of doing so as soon as we saw the notification that someone had added us, as quickness is in line with the Twitter experience and it shows people that we’re here and engaged, and that they matter to us outside Ma.gnolia as well. Our approach produced an unexpected benefit in that Twitter is a two-way channel, and before long members began posting publicly and directly to us about service interruptions or other issues that needed attention. Without barely trying, we had opened up a lightweight support channel with a super-low barrier to use.

I’ll admit that it’s flattering to watch the numbers of friends grow, but for me that’s the lesser part of the fun. The real thing is in the posts that people share with us, and how it allows us to understand where they’re coming from.

Unexpected Benefits

I’ve already mentioned that Twitter opened up an unexpected way for members to let us know when the service needed some kind of attention.

A greater, though less tangible benefit, came in the insight into what our members are up to. Scrolling through the posts of our friends gives us a Gestalt of what they deal with, what excites and frustrates and amuses, what little successes and failures they face. In short, it enriches how we see our members and understand them as people. No specific features have changed or been planned in response to what we see. Instead, the payoff is that we can think and talk about our members in a more informed way.

What started as a need for a way to keep members posted through a rough update has turned into a vital extension of how we communicate with our members, and how they can talk back to us. All in 140 characters per post. Not too shabby.

This post is the first of two about Twitter and its potential to be an effective and meaningful way of communicating. Today I’ll share some thoughts on objections to the micro-blogging groove, and try to show how Twitter does achieve meaningful communication because of, and not in spite of its format. Tomorrow I’ll talk about how Ma.gnolia is using Twitter to help us keep in touch with our members.

Pretty much anyone who has heard of Twitter has an opinion about it. Not just the casual, evaluative kind where we give a thumbs up/down or numeric rating, but a serious consideration of whether it’s somehow bad for us. The arguments go along one or both of these lines:

Objection 1. Twitter is noisy, and as such adds a high frequency interruption channel to our environment. With so many interruptions, getting focussed and into a productive state becomes more and more elusive, and we end up with something like late-onset ADD. Perfect instance: Kathy Sierra’s pondering if Twitter is the end of attention.

To hear that Twitter is noisy makes me point to the name and raise an eyebrow. It feels like it’s supposed to be a little noisy, and while that can be part of the fun it also has to be managed. Outpacing email and instant messaging, the phone, children, pets and the person who sits next to you, Twitter can be a serious interruption engine. And like all those other interruptions, learning to keep them from running and ruining you is part of working and playing in the Internet.

Objection 2. Twitter is a river of banal narcissism, in that answering the question that drives Twitter, “What are you doing right now?” produces only familiar, ordinary moments. Waiting for the bus. Eating a sandwich. Is your sandwich that important that the world must know? With 140 characters, what can you possibly say of substance? Perfect instance: Nick Carr calls out Twitterers as a navel-gazing chattering class.

Context is Key

The answer, I think, is quite a lot, and it’s not so much about what gets sent out as it is how it is read. Twitter posts (I really can’t call them ‘tweets’, not yet), aren’t consumed like most regular blog posts and web pages, because we usually read those items in the context of a search for information or in a passive, news-reading mode. Twitter is just sort of happening, and as such most Twitter posts can seem pretty trivial when read without some kind of context.

Since Twitter streams grow and intersect by adding ‘friends’, the most natural context is a personal relationship with an individual or group. Common, but important relationships, like friend to friend, organization members, teammates, and so on. In the context of these relationships, the conversation is already flowing in some way or another, opening up shared values, vocabularies and timelines as informers of each Twitter post.

To demonstrate, let’s make a fictional Twitterer. We’ll call him Adam and say he’s in university. When Adam posts to Twitter:

“Talking to Amanda on the phone”

We can imagine that being read in a few different ways:

Adam’s lab partner: Who’s Amanda?

Adam’s best friend: Awesome! He finally got the nerve to call her up!

Adam’s ex-girlfriend: Her?? I can’t believe it. He’s still rebounding.

Adam’s rugby coach: Whatever

Amanda: doesn’t use Twitter, which is probably a good thing at this point

How Adam’s post is read is determined largely by the relationship he has with the readers. There’s a neat trend in that scenario, where the more involved the shared context, the deeper the understanding, and the stronger the resonance. Indeed, Adam has moved the shared timeline between himself, his ex, and his best friend in under 140 characgters. As a relationship builds, Twitter posts can say more with the same number of characters, and I think that’s how Twitter posts can communicate very well with few words. This isn’t to say they always do.

Same Time, Different Space

Dropping into a bunch of Twitter posts might leave you feeling a bit lost if you don’t have any reason to be looking at them. Something has to tie you to the person making the post for the resonance to happen. The campus gossip scenario shows this in theory, but please try with me this comparison of experiences:

First, check out the public timeline from Twitter. You get the idea right away, but it’s just kind of there.

Next try this view, and let it play for a half-minute or so.

Bada-boom! Context! Every post gets a place on the world map, and you’re seeing it barely a moment after it was sent. With our understanding, or lack of, about places in the world we can establish a context for the person behind the post, and a powerful one at that. What does it do to know that someone who just posted “getting ready to go to the market” lives in Baghdad or in Paris? The difference in locality from our own or from what we are familiar with becomes a binding element in reading a given post and knowing where it comes from.

Place raises notions of environment, culture, language, stereotypes and more, and as such adds richness to each Twitter post. By also answering ‘where are you from’, Twittervision adds something engaging and human to what is otherwise can feel like a bulletin board on Red Bull. Twittervision adds the context of geography, an alternate to the context of interpersonal relationship.

Though overlapping Twitter streams with different types of contextual information are novel and interesting, the context of relationship seems to be the one in which Twitter works best. Returning to the scenario with Adam, we can see that the value starts to go down with the degree of interpersonal involvement. That would seem to relegate the best uses of Twitter to existing friends and family circles, but in fact, with the right circumstances and the right approach, Twitter can be a great tool for strengthening ties in communities that gather online around services or initiatives.

Next Time, on TwitterTalk

In the next post, I’ll show how we’re doing that at Ma.gnolia, and talk about some of the unexpected benefits of doing so.