Adaptive Path Blog

A few days ago, I finally got an Amazon EC2 beta account, spent a little time playing with it and had some initial thoughts about the service.

The Getting Started Guide was reasonably straightforward with the expected gotcha’s and a couple unclear instructions. Took me about an hour to set up a stock virtual machine, get it running, modify it, save my changes to an encrypted copy stored on S3, and relaunch my my customized version. Not bad. Still, the process is complicated enough my mother is never going to do this and anybody who is not familiar with unix command lines is going to be pestering their geek friends for help.

The pricing is such that if you need one machine, it’s cheaper and more reliable to go to ServerBeach, Rackspace or some other dedicated hosting provider. Bandwidth costs are not that high but if you have an application that involves huge amounts of bandwidth, you can beat the pricing by buying in bulk. The RAM provided on the virtual machine doesn’t seem beefy enough for anything involving a heavy database work. And the transitory aspect of the machines (and IP addresses) provide some challenges.

That being said, it seems clear that there could be some great opportunities here for rapidly scaling up and down in a cost effective manner, the challenge being how to architect an application to be able to take advantage of this. Seems like somebody should set up an service that acts as a front end to EC2, transparently proxying requests, providing load balancing and scaling up or down as needed. There’s a need for user friendly tools to create, manage, launch, and save instances. Could be cool for teaching too. Give each student their own linux box w/ root access for the duration of the class or quarter.

Ultimately, whether or not we harness EC2 to solve our current needs, I’m most interested in seeing the new types of applications that evolve. My experience is that it is easier to perceive problems when we have the tools to build solutions. This is a new tool in the toolbox and there is potentially a whole new class of problems that we can solve. I think we’ll see some entirely innovative uses for EC2.

About a year ago, Ryan, Rae, and I did a project for make-your-own-social-application web start-up Ning. It was a great project, designing tools for average users who couldn’t code to better create their own social networks. Lo and behold, we were pleased to see that the new tools have launched! The Ning team did a great job translating, developing, and extending our designs. Others seem to like it too.

As a fan of good information design, I’ve made a point lately of raving about Google Reader’s trends visualization. Despite my enthusiasm for visualizations of personal data from digital life, I admit to some serious data-envy for the exhaustive analog efforts of Nicholas Felton (of NYC design firm Megafone) and his Feltron Annual Report(s).

I’ve been eagerly anticipating the 2006 Feltron report since I first discovered last year’s, and I was not at all disappointed. From the total number of air miles traveled to a geographical listing of every restaurant eaten at in New York City in the past year, the Feltron reports stand as the most gorgeous representation of personal information I’ve ever seen. The extent to which Felton goes to record his own movements along various axes over such a long timeline is incredible, and the quality of execution — especially typographically — is close to perfect.

The quality of Felton’s work has gotten me thinking about improving personal data visualization in the tools we build.

When Adaptive Path founder (and current Googler) Jeff Veen posted recently about the work he and his team had done with Google Reader’s trends, he expressed excitement for “collecting and understanding the ambient information that flows through our digital lives.” Specifically, he referenced an excellent post by Tom Coates, who elaborates on the value of personal data summaries:

… more specifically I don’t want to know this stuff, I want to be able to capture it invisibly so that it can be knitted together and sense made of it and data made discoverable and searchable at some point in the future, when the urge or need takes me.

For me, Tom’s sentiment (and Jeff’s enthusiasm) clarify something I’ve just started to really grapple with: As we create tools that have the ability to record the wakes of users moving through their digital lives, there is a corresponding obligation to create quality visualizations of that data.

Designers should seek to enable everyone to discover meaning in the patterns of the everyday. What is required is something as complete and concise as it is visually parsable — maybe even beautiful. As artifacts go, the Feltron reports are an exemplar that tools like Google Reader Trends should evolve towards, if not in form, than in spirit.

Perhaps the most satisfying thing I read today is that in 6 months Google Calendar has gone from launch to being almost in a horse race with Yahoo Calendar for top spot.

Why should I care? Because Google Calendar’s success is an example of the power of experience strategy. How do I mean that?

Among the presenters at last September’s Future of Web Apps conference was Carl Sjogreen, the product manager for Google Calendar. Carl described the user research that his team did before any design or coding took place (not common practice at Google), and how they informed the vision of what Google Calendar should be. From his deck (PDF):

Here’s a product whose very definition was predicated on empathy for true customer needs. And it’s succeeding brilliantly. (We refer to such a vision as an “experience strategy,” which I’ll talk more about in my next post.)

Don’t forget: Yahoo and MSN’s calendars have been around for *years*. Google Calendar has been around for 8 months. And it’s very much on target to surpass Yahoo!’s standing as number one calendar.

The good folks over at IT Conversations have posted my presentation from this August’s User Experience Week, “Facilitating Collaboration: Web Technologies that Work“. Here’s the relevant portion of the presentation’s abstract:

With an eye towards helping Interaction Designers and Managers choose their collaborative tools effectively, we’ll survey the landscape of what’s available and why it’s important. We’ll take a look at the factors that shape adoption, from uptake strategies to degrees of commonality and centralization. Finally, we’ll look at how some organizations are combating email overload by employing “governance architectures” to structure their use of these tools.

I had a great time giving this talk, and people seemed to really enjoy it. I did my best to keep the focus on what teams need to work together effectively, rather than just do a competitive analysis of the available tools. I’ll post the slides as soon as I can get Wordpress to stop throwing script errors during the upload. The deck is available for download from the IT Conversations page linked above. Listen, follow along, and enjoy.

For nearly a year, I’ve been pleased to tinker with and present multiple times the great set of slides that my co-worker Ryan Freitas created: Beyond Wireframes (418k pdf). It’s a look at three different experiments we’ve tried (and are trying) at Adaptive Path to document applications, especially web applications built in Flash or Ajax. Because this is a pdf version, the low-fi animations don’t work, so I’ll refer you to Brandon’s post about using keynote as a prototyping tool that is shown in the presentation. Thanks, too, to Bill Scott for the Frame-by-Frame example.

In all the talk about YouTube’s boffo $1.65 billion dollar deal, there are two videos that should be recognized for their contributions (and their creators given some $$$): SNL’s Lazy Sunday video (which, although now gone from the site, put YouTube on the map) and Ok Go’s “Here It Goes Again” video, which reminded us why YouTube was so great in the first place.

Yahoo today launched the new version of their homepage for US audiences. What’s significant about it is that for the first time, one of the most-used (the most used?) pages on the web is full-on Ajax-ified. People like my parents, who have never used Google Maps or shopped at The Gap online, much less used hipster sites like Flickr, will now be exposed to what can now be done online.

What’s more, any arguments about Ajax’s suitability for and adoption by a mass audience should soon be settled. Plus, rumblings in IT departments about increased server hits and bandwidth usage may diminish. (”If Yahoo can do it, why can’t we?”)

I’d also personally like to thank Yahoo for putting weather back on the home page. Kudos.

Lately, I’ve been thinking about the ways that web products’ interface / interaction  evidence the business strategy and approach. While wafting in metaphorville, this one emerged: you can look at web products like you do gemstones. To take it further, which bling is your bling?

the diamond: transformation
Distill the business (and the interactions) down to something totally clear, where each facet creates more luster and sparkle, where it’s harder than steel and incredibly valuable. Start with a bunch of coal, and apply pressure intensely until it’s completely different, where it’s not coal any longer…it’s been transformed into something brand new.

Coal comes from situations that erode good user-centered design: too many moving parts, complex data structures, lots of business rules or expectations, too many options, unclear filters, results, form-fields, whatever. Pressure comes from intense competition, need for organizational change, markets that are poised to combine or consolidate, and other internal / external factors.

What Google did for search is a visible diamond. Search was a major (and growing) market with too many options, lots of complexity, lots of market pressure, lots of stuff out there. Google collapsed it all down to one entry field and a whole lotta under-the-covers algorithmic smartness. Now that’s sparkly.

the pearl: evolution
Pearls start with a grain of sand. In real life, the oyster is really just trying to find a way to survive with a stupid piece of sand in its body; but in business life, the sand can be seen as a problem or an opportunity that rallies a team to make something else. Whether it’s an opportunity (here’s a nugget of an idea that could be BIG) or a business snafu (we get 8,000 complaints about this a year) the goal is to apply strategy and design to change the grain of sand into a positive thing.

Pearls are great when the strategy needs to evolve over a measured period of time. The good part is that the bigger they get, the more valuable they are. The more oysters you got working to make the pearl, the more you win.

Wikipedia is a pearl: start with something small (an empty page, a one-sentence entry, an erroneous claim) and let the community nacreate it over time into something that iterates and evolves into something unique and valuable. Tah-dah, pearls of wisdom.

the crystal: organic growth
It grows organically, wildly, sporadically and spontaneously. But through it all, it keeps a crazy kind of symmetry and holism, since the prongs extending in all spatial directions are built from the same pattern as the core. Crystals are great for unknown challenges, communities that give their members more than lip-service power, and cultures that promote organic, opportunistic change. Crystals are products that start small and grow exponentially and unexpectedly.

Flickr is a great crystal. The stuff that makes it all up is pretty much the same: it’s a bunch of photos. But the crazy fractal-like outgrowths jut out in all directions, are constantly in development and build organically on the whole. And baked into the entire approach is the concept of giving power to the users so that the community itself takes charge of creating new spurs and directions. The strategy is crystal clear.

These are just three examples in the jewel box of the web. So now when I think about cornerstones of design, I’m going to consider gemstones, too.

During the dot.com bubble, I worked with a large technology corporation on a product with a meticulously pre-meditated strategy. The strategy made sense on paper and was a nice antidote to all of the, um, exuberant product strategies popular at that time. The product didn’t take off mainly because it was trying to accomplish too much (think iMovie + iPhoto). Additionally, the product’s strategy was static from conception through launch, which was about a year and a half. This experience got me thinking … when is it appropriate to develop a detailed product strategy in advance, and when is it better to let the specific details emerge during the design process?

Enter the Economist’s Best Business Book from 2004: The Modern Firm: organizational design for business and growth by John Roberts (Oxford Press 2004). Roberts explores the question of predetermined vs. emergent strategy in a case study on the 19th century battle between the Hudson Bay Company and the Nor’Wester Company. The HBC succeeded for many years with a very exacting top-down strategy until, during a time of economic turbulence, the NWC was able to out compete them (briefly) based on a broad strategic direction and by relying on employees to make good decisions. Roberts asserts that in times of rapid change, business performance is heightened when strategy follows organization rather than the other way around.

This concept explains why broad strategic objectives and principles are more valuable for many technology-focused companies making products now. Overly specific strategies and detailed implementation plans *can* become an impediment to success. This doesn’t mean that strategy or planning isn’t important; quite the contrary. As Roberts explains it, the more important role of a product leader is to “set a broad strategic intent that informs and shapes dispersed strategic decision making [throughout the company or team]“. While this concept seems somewhat obvious, in the real world, gauging how much strategic detail to set from the start, and how much is allowed to emerge is often an interesting and challenging jugdement call.