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.
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.
Requirements and Roadmap
The Master Flow
The Account Page
Authorization Details Page
Innovating on OAuth
Rounding Out the thmbnl Experience
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
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.
- 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 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
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.
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
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.
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.
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
- Service Plan
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.
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
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
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
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.
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.
Jensen Harris, Group Program Manager of the Microsoft Office User Experience Team, published in 2006 a list of the most used features in Microsoft Word 2003, according to data collected from the users who opted for the Customer Experience Improvement Program:
1. Paste (11% of the usage)
2. Save (5.5% of the usage)
These five commands account for 32% of all the command usage in Microsoft Word 2003, as they are used very often.
The post goes on to say that as a development strategy, Google’s office-apps development teams could use those stats to refine the few operations that are used most, rather than trying to cram in more numerous and more complicated features. On the surface, this makes some good sense: follow what people are doing most with your apps, and support them as much as you can. But it misses some of the deeper thinking that can make the difference between an application that does just enough to one that truly evolves.
One thing that relying too much on statistical usage data can get you is a blind spot for parts of the application that are important, despite a low frequency of use. An anonymous commenter points this out with a gentle poke:
This is like saying that most time spent in car involves going and only a little stopping, therefore stopping is not important!
True, that. Sometimes it’s useful to take an idea to an extreme to show its weak spots. The more problematic thing with making plans by stats alone is that they opt for incremental gains in efficiency or raw power without stopping to ask the question: why do people use this feature so much?
Probing the reason for high frequency of use can reveal opportunities to solve underlying problems. That pasting is the #1 feature suggests that data isn’t moving from one document into another, or replicating through the same document, intelligently enough. A user who repeats a Paste command over and over might not be hip to the magic of Find and Replace. That Undo is at #4 suggests that people are making a lot of mistakes or changing their minds. It could be that the natural number of typos pushes Undo to the top five, but it could also be that usability issues are leading to mistakes or unwanted results. Making it faster or easier to Undo a mistake isn’t better than preventing the need to reach for Undo so often.
To appreciate this, consider how Google Docs does solve an underlying problem of trust in the software to get around the need to click Save so often. Again, from the post that kicked this off:
Google Docs auto-saves documents so you don’t need to press the Save button…
Provided that immediate saving doesn’t create other problems, like exposing thoughts before they’re ready to show, this is a perfect example of solving the problem rather than just making it easier to take the action.
Stats can be very useful, but they’re misleading without an analysis that questions the reason for a trend. Spending some time to ask why a feature is needed so much in the first place can reveal the way to a better experience, not through statistical gains in efficiency, but by removing the need for the feature altogether or showing a better way to the same result. After all, the best solution doesn’t make problems easier to solve, it makes them go away altogether.
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.
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.
I spent a few days on the far-west coast of BC this week in a small town called Tofino. In the summer, Tofino’s population goes up to about 20,000, attracting surfers and nature lovers. In the winter, the population is about 1,500. As you can guess, in February, it’s a quiet place to be.
I didn’t check email, turn on my cellphone, or tell anyone the exact place I was staying. I turned off status reporting widgets and read minimal news. I didn’t listen to my iPod once (for real). Late in the week, a surprise snowfall cut off all communication for about a full day, removing land-line phones, television and Internet access for everyone there, like it or not. Local radio is the only kind of radio there, and they lost power as well. Now that’s quiet, and perfect for exploring the beaches, taking in views that defy description and getting lost in the oddities turned up by the tides.
I didn’t fall into some kind of Luddite bliss, but I did notice, by their absence, the demand for our attention that the mere availability of these channels creates. Silencing the flow of incoming information seems to be a staple of the modern vacation, but I think that speaks to a need not being met in our approach to information technologies, and not some inevitable consequence of connectivity. That is, we shouldn’t have to turn off communication channels as a defensive action.
There’s some blue-sky thinking about how the devices we use to access these channels could become aware of our states and bring information to us accordingly, but that’s a post-iPhone world and I’m interested in what we can do now.
When thinking about this I keep coming back to the idea of information richness. The conventional wisdom is that offering depth and interesting pivot points on the information an application delivers is a good thing in itself. We want information, give it to us, relentlessly so. That takes us back to the beaches of the Tofino area for a moment.
On my first morning out I kept coming across Sand Dollar shells. I wanted to collect a few whole ones for some friends back home, but because they are usually partly buried in sand, each one has to be checked to see if it’s whole or broken.
Most are broken. Even after finding a few whole ones, I found that I had to resist an urge to check out each one I came across. It’s the beach-combing equivalent of leaving no stone unturned.
Leaving stones unturned is just something our brains don’t do well, for many good reasons. It’s not that info-richness is a bad thing in itself, either. It’s that it’s often offered without qualification, without meeting a true need other than that of data voyeurism. Always wanting to put lazy theory into a Quaker-like work mode, I’ve been putting together a sanity checklist that will keep the lessons of my week in Tofino in mind.
What is the one essential and concrete purpose that presenting a view of information serves? If the answer is highly subjective or vague, then it must connect directly with the core emotional experiences that the product is designed to create.
How deep does the view of information need to be to serve that purpose?
Applying these questions to previous projects, I see places where we came close to the sweet spot, and many other places where we really filled up at the Information Candy store. In About Face 2.0, a must-read book on interaction design, Alan Cooper identifies cardinal applications, or those that take up all of our attention for extended lengths of time. As the desktop computing experience dissolves into many and mobile devices, cardinality will be taking a back seat. Instead of designing for any one application, we’ll be designing more for an ecology of applications, each of them asking for some degree of attention from people. Being relevant rather than rich in the information that they provide will set applications apart more and more, I believe.
There are many rewarding and appropriate uses of rich information structures, and info-voyeurism certainly has its place. And, we all need to manage the channels that demand our attention, but not by dulling our natural curiosity and learning to ignore the scores of unturned stones presented on any given interface. Making information rich in relevance rather than data will be the key to making applications that fit well with our lives, rather than something we want to escape from every few months.
In the absence of the time to write something substantial this week, I’ve opted for a two-part budget blog post.
The first part is for Mac Mail users. I discovered by accident today that you can change the highlight colour of any mail message or entire thread. Just open the colour palette, select the messages to highlight and pick your colour of choice. Voila, instant colour coding.
What’s interesting about this hidden gem of a feature is that it enables a simple form of a process (categorization) that most software would make more involved. It allows for ad-hoc categorization without any kind of setup, much like tagging systems do. Users can easily formulate and recall coding systems of 7 or so items, typically indicating priority or a workflow step, without having to articulate that system to the software in some kind of category setup. It’s the perfect example of ‘just enough’, and reflective of some deep thinking on the part of Mail’s designers (but not too deep).
The second part of this budget post is to let you know that I’ll be at Web Directions North on behalf of Ma.gnolia, and joined by Larry Halff, Ma.gnolia’s founder. If you see us around be sure to say hi.