Corvus Consulting

Have you ever wondered if the web is the first medium where businesses could make something deeply valued by customers but struggle with how to actually make money from their innovation?

Radio and television must have faced the same problem, and born lacking a way to meter and charge individual use, broadcasters turned to predominantly ad-based subsidies for free content traded with consumers for their attention. If content producers for radio and TV had been able to control distribution like newspapers did (by nature of selling a physical medium) from the start, I suspect we’d live in a very different media universe. For starters, maybe we wouldn’t have to wonder about ironically-combined cable channel bundles.

Like TV and Radio, the web delivers content people value, and has tried to ape the ad-supported model with dubious results, the most dubious being the rapid consolidation into a monoculture ad economy where one player outweighs them all. The ad-supported model doesn’t seem to scale enough to float really successful web content or services. While the web can deliver on the alternative, metering and collecting payment for content and services, the culture has been saturated by TV and radio to expect the content for free. Now that’s a conundrum.

But you know what, none of that matters, because OMG Twitter changed its homepage. The change is more than aesthetics, and I think it shows how they intend to escape the conundrum of high value and the revenue vacuum.

Read more »

Among the many rumors of products that Google would one day ship, a home-spun operating system has been among the more persistent and esoteric. What would such an OS look like? How would they ever get it into OEM hardware? Would it be sold or ad-supported? As with Android, the answer is not so much the arrival of what’s expected (g-phone, anyone?) as a reveal that re-frames the original questions.

Read more »

Tech bloggers, reporters, pundits and armchair quarterbacks worked overtime this past weekend with news of Microsoft’s withdrawal of their bid for Yahoo!. It’s anathema to blog rhetoric to say, but I have no opinion on who was right or wrong, won or lost, or who’s stunned and who’s sly.

As Monday closed, the commentary had shifted to Jerry Yang’s role in the collapsed bid and his future. As with the bigger picture, I have no opinion on Jerry’s actions. What has struck me as worth commenting is the blog post under his own name that appeared Sunday night.

More precisely, it’s what follows the blog post. Comments. Quite a few comments, at that: 125 as I write. While some comments offer encouragement and ideas, many are personal and none too flattering. Old school PR would have hit the kill switch on most, if not all of those comments, in a heartbeat.

Now, jump back in time to December with me, and recall if you will, Facebook’s Beacon fiasco. After a month or so spent stonewalling calls for some kind of dialog with members, founder Mark Zuckerberg wrote a mea culpa on the company blog, also announcing a change in the sharing model for Beacon. As a blog, there is a form for posting comments. With hot-button (and legitimate) issues like privacy, data ownership and proper disclosure in play, one can imagine that the comments would be on fire.

Not so much. In fact, there are precisely zero comments posted. There’s a form for submitting, but those comments aren’t seen by others. Old school PR rules here, because we can’t be expected to believe that exactly zero Facebook members had nothing to say here, yet that’s the line being held there. Months later (which would be now), there’s barely an ember of the firestorm over Beacon to be found. The ads that do appear look like clutter, and the focus as a business development technology seems to have shifted, I am guessing, to background aggregation of members’ purchasing activity across participating sites.

However history remembers the business savvy of these two personalities, there’s a kind of respect that I have for Jerry’s blog post showing comments in all their often-ugly glory. As much as I find Facebook innovative and interesting, I can’t find that same respect for their willingness to hook up anything and anyone within its walls, as long as it’s not the opinions of its members with its own statements on controversial policies.

But, I’m an idealist about these sorts of things, and believe that conversation with customers should happen in the open. I’m interested in hearing other takes on these polarized approaches to member feedback and conversations about problematic issues in an online community. What example is the right model? Yahoo!, Facebook, or something in between?

I’ve been playing with single-site browsers for the last couple months, specifically using Fluid, created by Tod Ditchendorf.

For the uninitiated, single-site browsers (SSBs) give a website its own window and dock icon (or place in the task bar for Windows), apart from the main browser. I made a quick (3.5 min) screencast to show how SSBs are created and how they present themselves in the desktop environment.

Read more »

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 Ancients talk of a time before memory, before 1990, where, here on the west coast of Canada, coffee culture did not exist. The world then was a flat wasteland of instant coffee, reconstituted from crystals, sitting for hours on a sad Tim Hortons’ hot-plate. Like cave-folk, only with less to live for, we stumbled about knowing nothing of espresso, machiato or latte. The only reason to drink that grim brew was to bitterly pinch oneself for a moment out of a mumbling, lurching existence.

Things are different now.

Today, serving coffee means having an industrial espresso machine, knowing and boasting the bean supplier, and not daring to let an espresso shot live outside the cup for more than a minute. What changed?

One thing: Starbucks.

Serious coffee drinkers may wave Starbucks aside, but deep down they know that they owe the flourishing of their love to the green mermaid. Starbucks cracked the secret of bringing coffee as way of life, with all of culture’s refinements and diversity, to places where it didn’t exist. They bridged the gap between specialist and general consumer. They raised the bar everywhere they went, changing perceptions and democratizing the elite language, tastes and enjoyment previously isolated to eccentric cafes.

Like any large business there are bound to be practices and effects that aren’t so great, but what I want to focus on is how Starbucks took the tastes of an elite group into the mainstream, and in doing so changed the minimum expectation and demands of the mass market. Leaving coffee, let’s look at the state of Web 2.0.

Hey, Spaceman, How’s the Weather Up in Space?

Chances are that if you’re reading this blog, you know that user-generated content can be more surprising, compelling and often trustworthy than ‘the news’. You wield feeds to give yourself a god’s-eye awareness of change across a custom chain of islands producing news, images, opinions, and funny cats. You know how to find your friends on any website and how to make new ones purely on the basis of shared interest. You know how to weave your awareness and presence through a network of devices, and how to make the threads vibrate to communicate your most casual and profound thoughts. And you know that the world without the connectedness seems dark and stale.

Web 2.0 is our coffee, and we’re the oddballs who sip from tiny cups in out of the way cafes while everyone else thinks that Folgers and Maxwell House are the real deal. We might get small thrills from knowing we’re on the cutting edge, but we also know that it would be more fun if more people understood how much they were missing. And deep down, we know we’re failing to bring the most exciting fruits of Web 2.0 to the world at large.

Try explaining a folksonomy or a wiki to an average web user. It’s hard. How about social bookmarking, or lifestreams? It’s usually hard to get the concepts across, and our enthusiasm for this or that innovative startup comes across as almost alien. With our interest in the web, it’s easy for us to pick up new ideas and words and run with them. For the rest of the web world, it’s not so easy, and we do a terrible job at communicating the value of what we’re doing. To really cross over into the mainstream, Web 2.0 needs its Starbucks.

Blue is the New Green

This weekend I got to meet and work with Scott Kveton up here in Vancouver. While waiting for the rest of our group at breakfast, Scott told me that the night before, he overheard a pair of 30-something women talking outside a pub, and these words especially caught his ear:

“You’re not on Facebook? Oh my god you have to get on Facebook, you just have to.”

What Scott heard was akin to a Starbucks opening on a new street. Only it’s not called Starbucks and it doesn’t serve coffee.

But when that friend goes home, possibly drunk, and gets herself into Facebook, she’ll learn in a short time much of what we’ve been building and enjoying on the web’s edge for the past few years. She won’t be socially networking, she’ll be finding friends and checking out people. She won’t be posting user-generated content, she’ll be making jokes, whispering to friends and talking in a group of people. She won’t raise an impressed eyebrow at some AJAX-fu, but she will be pleased for a second that her message appeared in a thread without reloading a page. She’s not joining an elite crowd of aficionados, she’s joining a party in progress, where it’s easy and safe to move from room to room.

In talking about this, Kris Krug noted that Facebook excels at taking only the most useful and central feature patterns from Web 2.0 websites and making them flow well into the central app. I think he’s dead right, and that’s how Facebook blue will become the Starbucks green for Web 2.0 concepts.

There are things that weird me out about Facebook. There’s a strong streak of Disney-like sanitization running through it, and any hub that links so many personal details together in a persistent space makes me wary. But there’s also no denying the power of a smooth user experience and especially of making contact with people you haven’t spoken with in a while. It’s not the most advanced, it’s not the best, but it just works and works well.

Like Starbucks, there are lots of Facebook members who have discovered a whole new world through one well-crafted and infinitely repeatable experience, and after a while they’ll move on to something more specialized and refined. But most will stick with Facebook for their daily fix of the social web, barely remembering the time before time, when the gossamer-thin channels of email and instant messaging and websites that weren’t about us were the whole online world. But no matter where they end up after Facebook, they’ll expect certain things and a certain quality of experience that didn’t exist for them before.

Like Starbucks, Facebook won’t steamroll every plucky startup and well-loved, if small, service. Niches will still have their place, and in their innovations have a better chance of being understood and adopted with the post-Facebook web user, much like the ex-Starbucks customer has been schooled enough to seek out and embrace niche providers that suit a more refined taste. Makers of the new and cool will soon have more people than ever who get what they’re doing and want a piece of it.

The tide is rising, and all boats are floating higher with it.

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.