Adaptive Path Blog

Part of the Smart.fm iPhone App Story

Update: The app was just released. Download it from iTunes now.

When last we posted about the Smart.fm iPhone app the team had moved from design into development. In the few months since we have been hard at work bringing our ideas to life. The combined team, working across many time zones and many miles of ocean collaborated almost daily. We tackled issues on the server side. We tackled issues on the device. We tested scenarios and we tweaked the design when implementation revealed new ways to solve problems. During app development I’ve taken note of some themes that arose time and again. Here’s four that stood out.

A great experience is responsive

Software that looks good and works right will fail if it is not fast. With a mobile experience this is especially true. Mobile devices are inherently more resource constrained than PC’s. Users expect to dive into an app on their phone, complete a task and then get out. Seconds count. Heck, milliseconds count. In building the Smart.fm iPhone app the team likely spent more time on performance tuning than anything else. As an Internet connected service, the app is constantly downloading information over the network. We had to find techniques to download just what’s needed in the moment. API tuning improves download times and client-side caching reducing the amount of downloading needed. The final design for data synchronization results in the user seeing some shorts bursts of network activity while browsing around. Taking advantage of this pattern, the team came up with a clever “loading” animation. If we did our job well, the burden of waiting for a download will actually help to make the app feel even more fun!

A great experience is correct

The Smart.fm app is designed to work a lot like the iPod app. A user has numerous goals with many items. They select a goal and begin studying it with the learning game Alexa described earlier. If a user leaves the game, either by returning to browse goals or by quitting the app then their state needs to be saved and resumed at a later time. In addition, the user’s study progress needs to be synced back to the Smart.fm web site so that they can continue learning on a PC. And wait! What if the user studied that same goal, or another one in the mean time… download that progress and figure out the user’s total progress across all goals. And wait! Since goals are “alive” other users might have added new items, so download them too.

What seems like a pretty simple app design on it’s surface reveals quit a bit of complexity during implementation. I think we all know of applications that offer plenty of utility are are unusable due to bugs. It goes without saying that errors in software are not a good experience. During the development of this app we worked diligently to test and remove bugs…. and test and test and test. The hope is that our users get an error-free experience that lets the fun shine though.

A great experience is choreographed

Brandon Schauer always talks about the cupcake. In fact, I find it hard to get him not to talk about it. And to be honest, I love the metaphor; it’s infectious. The concept is this: a cupcake, a birthday cake and a wedding cake are each perfect in their own scale. A cupcake may be smaller than a wedding cake, but it is no less delicious. You take a bite and are completely satisfied. The cake, the icing and the decoration on that cupcake is just right. Perhaps you’d like a second helping, but you don’t wish you were eating a slice of birthday cake. The cupcake is small, but complete.

During the development of this iPhone app the team had to cut some features due to time and resources. In deciding what to remove, and how deeply to cut, we need to ensure that the app was still tasty and satisfying. A Smart.fm app that didn’t allow a user to study would be incomplete for sure. But what about some of the social network aspects of the service? Could those be removed from the first version without it feeling lacking? What about multiple types of quiz games… do we need those too? What’s the cupcake of a Smart.fm iPhone app?

A great experience ships!

I’m happy to say that the iPhone app has been submitted to Apple and is very close to being in your hands. There is always a time at which a developer must decide that their work is refined enough for customers to use. The hope of course is that this time is not dictated such that the application is incomplete or full of bugs. Our team was able to work towards a ship date that allowed both the freedom to “do it right” and “just get it done”. Screenshots of the app are available at http://smart.fm/iphone. Early in November we anticipate seeing a smiling Smart.fm owl sitting in the iTunes app store. Thanks for all of your interest and patience!

On a personal note, I want to say that it has been a joy working with the Smart.fm team. Not only does the service live up to it’s name, but the folks who work behind the scenes are some of the brightest I’ve met

Earlier this year I wrote about the value of prototyping. Along with my thoughts on why and how to create effective design prototypes, I listed some rapid prototyping tools. My hope was to offer non-technical folks in the UX field the inspiration and the means to create something interactive instead of a standard wireframe and visual design comp.

I’ve been overwhelmed by the response to the original post. Sixty of you offered suggestions for additional tools and techniques. In the months following I’ve collected these, and found a few of my own. The list of rapid prototyping tools has been updated and can be found below. The list has grown to 42 items with 18 new or updated tools. Please comment with your own perspective on these tools and send me links for more! I’ll update the list (hopefully more frequently) with your suggestions.

Tomorrow I’ll be leading a workshop at UX Week titled “Making Things”. Yep, you guessed it, we’ll be breaking out laptops and building prototypes! As of right now, there’s still four spots available, so either sign up for the workshop if you are already a UX Week attendee or register for the last two days of the conference (use the promo code blog for 10% off).

Read this spreadsheet in a new, wider tab

Part of the Smart.fm iPhone App Story

Imagine that you want to learn how to read and speak Japanese. You’ve heard about the web-based learning applications offered by smart.fm and check them out. The site is great (and only getting better) but you’d really like to learn Japanese during those in-between moments of day. What if there was a companion smart.fm app for your iPhone?

Well, it’s coming and Adaptive Path is both designing and developing the app. Later this summer you will be able to download an official smart.fm app from the iTunes App Store and learn at your own pace when convenient for you. This project is unique in many ways, not the least of which is our ability to speak very publicly about the work. The team at smart.fm is happy to have us sharing our thinking and our process during the project. We’ll be posting regularly to the blog. You will get to hear about challenges, accomplishments and insights directly from practitioners. When possible we will bring in the smart.fm team as well to give you the client perspective. Adaptive Path is just thrilled to be able to design in the open like this. We are looking forward to hearing from you as well, so please leave comments!

Domo Arigatō (ありがとう), Tokyo

Alexa and I spent the last week in Tokyo Japan, home of smart.fm. We not only kicked off the iPhone app project but also wrapped up a previous engagement, a redesign of the smart.fm web site. Our time spent working face-to-face with the rest of the team proved to be invaluable.

As you would guess, everyone at the company has a strong opinion about the mobile app and what it should accomplish. We needed to channel this enthusiasm towards the goal of a refined set of tasks that users will actually find compelling.

A core team including developers, designers and product managers gathered for a day of workshopping. We facilitated the brainstorming of the mobile context in which this app would live. For example, we all agreed that mobile phones are great social lubricants (hand it to a friend), great for quick check-ins and great for when you have unexpected downtime. All of the ideas generated were clustered and use cases for the smart.fm learning tools were mapped on top of the mobile context.

The next step was the organization of the resulting use cases into a mental model and the listing of application features under each mental space. Features that were both appropriate for use on a mobile and support a mental space were added. Those features that were better served by the site or that just didn’t fit, went into another pile.

By the end of the day we had the following mental spaces, ordered in priority

1. Study: See what I need to do, do it, and see how I’m doing
2. Capture: Create items that you want to learn, or share items with others
3. Discover: Find something new to learn
4. Look up: Use smart.fm as a quick reference tool on-the-go
5. See what’s going on: A dashboard of your activity in the smart.fm universe
6. Respond & react: Answering questions from other users

In addition to the workshop with a select team, we also spent time interviewing many other stakeholders in the company to get their thoughts.

“If [the app] has the ability to share and teach someone who’s right there with you then it’s a different type of social—physically social. How can it fit into people’s real lives?”
Simon Dennett, Creative Director

With this foundation in place, combined with the detective work from Dane back home in our San Francisco office, we’ll begin defining the structure of the iPhone app.

Of course, what trip to Tokyo would be complete without a little bit of play. Our hosts were terrific about showing us their town. We were able to take in some of the best sights and tastes that Tokyo has to offer. Fresh sushi anyone?

Not Our First Time

This project may be unique in our ability to broadcast it real time, but it’s certainly not our first mobile project. Nor is this our first smart.fm project! The iPhone app will actually be our second major project with the smart.fm team. As I mentioned a bit earlier, we recently wrapped up the experience design of their web site, turning it into the collaborative, social and motivational learning app that users are longing for. Adaptive Path’s learnings on the site design are feeding directly into the upcoming iPhone design. Kate, Alexa, Kumi and Brian worked on this project and look forward to sharing more about it on the blog real soon!

About smart.fm & Cerego

Combining cognitive science with the social and collaborative structure of the web, Cerego empowers people to learn faster, remember longer, and manage their knowledge.

Based on years of applied research, Cerego has built adaptive, web-based applications that accelerate knowledge acquisition. Cerego’s patented core learning engine is driven by algorithms that generate optimal learning schedules for discrete chunks of declarative learning content, called “items”. This intelligent scheduling is achieved by gathering metadata on individual user performance and modeling memory decay patterns at the granular level of every item.

Cerego’s smart.fm platform represents the first phase of a platform that combines personalized learning applications and content creation tools in a collaborative, social environment – a place where anyone can study, create, re-mix, share, and manage learning content of any kind, from foreign languages to medical terminology, from photographs to paintings, from people to sound.

At Adaptive Path we often talk about collaboration. It’s in our DNA. We turn down work with prospects that don’t want to collaborate with us and cherish opportunities to work closely with clients that do. The Changemakers’ team and project was the quintessential collaboration between client and consultancy, resulting in a powerful redesign meeting the needs of both the client and user. What’s even more amazing is the three parties involved in the project are spread across North America:

• Adaptive Path lead the UX design out of our San Francisco office
• Enomaly lead the development of the site from their Toronto office
• The bulk of Changemakers staff is based in Washington, DC
• Key members of the client team are in the Vancouver, BC area

How does a large team spread across three time zones and two countries successfully collaborate? The short answer is that clear and honest communication is key and online tools can help. We started the project off with some face time. Sharing a meal and a beer with team members offers you a chance to get to know them on a personal level. It’s important to know what people on the other end of an email are like so that you can properly “read between the lines” and understand where they are coming from. Unique to this project was the assignment of nicknames (I’m “Woody.”). A couple of times mid-stream we had additional in-person meetings to ensure that the personal connection is renewed.

During the five month project we held weekly status calls. When needed, we’d add a second or third conference call for deliverable review. These regular check-ins offered the entire team a chance to both review progress and to just talk to each other. Team members took breaks to get married and have babies and we shared all of this on the conference calls.

Like on many of our projects, Skype and Basecamp were our critical tools. Basecamp served at a common location for collecting our thoughts and sharing documents. All digital communication flowed through Basecamp maintaining a record of decisions. Skype was used for the occasional video call with the far flung team. More importantly however, we used Skype to interview users around the globe. The Changemakers community has members in most every country and it was crucial for us to hear international perspectives. Skype allowed us to interview users in Africa, India, Australia, Macedonia, and Ohio all from the comfort of San Francisco.

A new digital tool we added to our arsenal for this project was ConceptShare. ConceptShare allows you to upload a concept and allow others to sketch and annotate all over it. That’s the basic premise for the app. We used ConceptShare to review sketched, wireframes and final visual comps. During a conference call, the entire team would login to the tool from their remote location and add comments real-time. ConceptShare brought a whole new level of collaboration and will be used on future projects.

Sometimes, the problem you set out to solve is not the problem that needs solving.

The Changemakers site is focused heavily around competitions. A challenge is posed on the site, users submit entries, those entries are commented and revised and ultimately judged.

When we first spoke with the Changemakers team, their primary need was to design a better experience for their users. This robust and diverse community of social entrepreneurs was the principal focus of our work but we soon surfaced a secondary and equally important need: help the internal staff manage these competitions.

At the outset of our engagement with Changemakers, we were told that the initial setup of a specific competition was burdensome. Gathering assets and loading data into the site was difficult and often required system administrators to step in and use their HTML/CSS expertise.

Before tackling the administrative interface, we interviewed competition managers. Our discussions quickly identified competing administrative priorities: loading a competition, tracking metrics, managing the shortlisting process. After our interviews, we ranked the identified priorities and, to the surprise of the team, we realized that the shortlisting process (taking a large number of competition entries and refining it down to the top few; this is done numerous times over the life of a competition) was more in need of a designed solution.

On the fly, this nimble team adjusted to focus on a tool for shortlisting, metrics, and loading a competition. The numbers clearly showed that while the loading of a competition took a staff member one day, the shortlisting process took more than five days over the course of a 10-week competition. A well-design loading interface might shave a few hours off that day of work, but a shortlisting interface would shave off days. The ROI was clear: reduce the competition managers’ burden significantly with a better shortlisting process and interface.

The result of our work designing an interface to manage to site raised questions within Changemakers about their internal process. The internal team took a good look at where they focus time, attention, and resources.

Newsletter readers: jump straight down to the list of tools.

Prototypes as a design deliverable are on the rise, and for good reason. I am strong believer that prototyping helps us to design better experiences. We are working in a world of rich, dynamic interfaces, both on the web and on our devices. The experiences we design are interactive, responsive, and have emotion. Prototypes allow us to articulate the feeling and function of a design in a way that a wireframe does not. But how do you select the best prototyping tool for the job?

Making Effective Prototypes

In order to evaluate a prototyping tool or technique, we first need to define what makes an effective prototype. The best prototypes are ones that slipstream right into our design process. We want the ability to quickly take sketches from a whiteboard to something interactive.

Effective prototypes are fast. We want to use techniques that allow for rapid iteration. A prototype should not just be bolted onto the end of a design process. Incorporating the creation of a prototype into your daily design work allows new ideas to emerge and validates concepts quickly.

Effective prototypes are disposable. Just like with any design deliverable, we are creating an artifact intended to express an idea to someone else (stakeholder, developer, user, etc). Once that design idea has been communicated, the prototype deliverable can be discarded. We don’t have to feel the burden of creating a masterpiece that will live on, and we certainly don’t have to work in production-level code.

Effective prototypes are focused. We want to select the interactions of our design that really need to be prototyped. Look for the parts of your design that have of complexity. Look for interaction patterns repeated throughout the user’s experience. Look for the interactions that bring revenue to your product. A prototype that demonstrates these interactions will be the best use of your time and energy. At our upcoming workshop, Good Design Faster we are teaching techniques to evaluate sketched concepts for the inclusion in a digital prototype. Use the promo code NEWS for 10% off.

Selecting the Tool

With the baseline set that a prototyping tool must enable us to create effective prototypes (above), we look at our particular organization to see what will fit.

First, let’s take a look at or team make up. Does someone on staff have the ability code? Is a Design Technologist a member of our UX group? Do we have a strong relationship with the engineering department that can help create prototypes? What about contract developers who can help out? Identifying our tech capabilities will point us towards coding a prototype by hand or using drawing-based prototyping software.

How large is our team? Are we a UX  team of one, expected to research, sketch and prototype on our own? Are we members of a small, tight team that can nimbly iterate through a design prototype in less than one day? Are we part of a large organization that needs to navigate the murky waters of corporate politics and different perspectives with our prototype? Often, the larger the team, the more detail (read: spec) a prototype will require.

Where is the audience for our prototype located? Are they in the same office, glancing over our shoulders? Are they remote? Are they in a country who’s time zone is an entire day away? Answering this question will determine our ability to talk through a prototype versus having it be 100% self-explanatory.

Is our UX team in-house or are we members a consulting firm? If in-house, are we integrated deeply with the engineering team or are we a completely separate department? A UX group that’s “outside” often has to justify their design concepts a little more.

What is our budget for a prototyping tool? Like most software, the range of offerings covers the range from free to expensive. The best solutions tend to fall within the cheap to mid-priced range. The super-expensive solutions (both in time and money) are often just not worth it.

How flexible does our prototyping tool need to be? Are we targeting just one platform, such as the web? Are we designing for lots of platforms like mobile, kiosk, television, consumer electronics and the web? Many prototyping tools are created with a single output type (usually web) in mind, so we’ll either need to select one that we can tweak to our liking or opt for techniques of creating our own prototypes in code.

Prototyping Tools

With the above criteria in mind, I started a list of prototyping tools. I encourage you to comment with your own suggested tools and techniques. My hope is that together we can generate a comprehensive selection criteria and menu of prototyping options. I will revise this list based on the feedback of this community.

Last weekend I lounged comfortably on the couch and sat through 3+ hours of The Fellowship of the Ring. The classic tale by J.R.R. Tolkien describes the desires of man through the artifact of an all-powerful One Ring. Time and again characters, even some quite noble, are tempted and tested by the ring. They try to steal it, even kill for it in the hopes of gaining power through it’s wearing. The ring, you see, is precious. It’s preciousness, however, is a trick, for the ring is actually only powerful to it’s creator, the evil wizard.

In much the same way, I often hear people tricked into believing that prototypes are precious. This is not an affliction unique to developers; designers fall prey to the same notion. “A prototype must be a starting point from which developers can code”. “We need to invest up front in a prototyping a framework”. “What tool I use to prototype matters as the idea I am trying express.” These are all statements justifying the precious nature of a prototype in the eyes of some. Can you hear Gollum crying out in the darkness for his prototype?

A prototype is just a means to an end, and that end should be the creation and testing of a design concept. Demanding that your prototype do anything more distracts from your ability to use the tool to it’s full potential as an ideation mechanism. To drive this point home, I have started referring to prototypes as “design prototypes”. The inclusion of this prefix helps to set expectations around how the prototype will be used. The term “design prototype” quickly separates from it’s cousins proof of concept, blueprint and pattern. In another context, a prototype may in fact need to conform to the production code-base of the app for which it’s being developed, but not during UX design ideation.

A design prototype must be disposable. Just like a wireframe, a persona and a visual comp, a design prototype exists for a specific purpose in your design process. Going into prototyping with the understanding that at some point you will shelve it gives you a the freedom to cut corners and do “just enough” to solve a particular problem. Appropriate uses for a design prototype include demos to stakeholders, usability testing, and my favorite: solving tough interaction problems. Often the best way to figure out how a complex interface should work is to select particular elements build them for testing. Using techniques like paper prototyping and digital mock-ups allows the design team to quickly assess if a particular interaction will work. The only way to really be efficient in prototyping during design is to have the freedom to throw it all away; don’t allow the prototype to become precious.

Ask yourself and your team a few tough questions. Are you investing tens or even hundreds of thousands of dollars on prototyping software? Do you have a project ongoing with the specific aim of creating a “rapid prototyping framework”? Are you fighting to get developer time to build your prototype using production code? If you answered yes, then perhaps you need to take a step back and assess how precious you consider your prototypes to be. Are your prototypes beckoning you with promises of power and wealth? Are prototypes your One Ring?

I’ll be speaking more about this topic at MIX09 with a session titled “Design Prototyping: Bringing Wireframes to Life”. Leave a comment if you’ll be attending so we can meet up.

You can also learn hands-on, practical techniques at our upcoming workshop Good Design Faster. Designers will learn techniques to create clickable prototypes without touching code and developers will dive into the scary new world of sketching. Register now with the promo code BLOG for 10% off.

More and more I am hearing UX practitioners talk about making the thing that we design. This often turns to discussions around prototyping and bridging the gap between design and implementation. As a Design Technologist, this is right in my sweet spot. For years my career was focused on the engineering side of projects and I cannot help but have that programmer part of my brain light up when working on design or strategy.

I sometimes get quizzical looks at my title, followed by questions about what qualifications I look for in a Design Technologist. Here’s some thoughts around that question. I think you will do best looking for someone who has a development background. If you find an individual with a history of “making stuff” then they will naturally have the right mindset to build something interactive. Usually this includes:

1. A comfort level with front-end programming (web, desktop, mobile, device)
2. A tool belt filled with techniques for creating interactive apps
3. The ability to quickly pick up new tools
4. A itch to dive into code and “just built it”

You also need to find that special someone who appreciates design and wants to be a member of the UX team. A design technologist uses her skills to solve design problems, not to code the final working application. A lot of developers will balk at this since they feel most productive when users are clicking on something that they actually built. A design tech needs to be satisfied knowing that the UX of the software is better because of their work. A prototype is often her end deliverable.

Also, this person may start to feel isolated since they work day to day with colleagues who don’t code and don’t swap stories about programming logic and MVC frameworks. She’ll instead work with IA’s and IxD’s who talk about design patterns and user research. Your design tech should help to bridge the gap between the UX and development teams. In doing so, she may be able to satisfy her desire to kibitz with other techies. It’s important that technologists stay connected to communities of programmers as lessons learned from that world are often very applicable to UX design problems.

My ideal design technologist job description probably wouldn’t mention specific development apps or programming languages. That’s a moving target and often this person would be asked to “just get the job done”. I would talk more about approach and project experience. If you are working for a company that make mobile devices then perhaps you want someone who’s worked a bit in the consumer electronics space or mobile space. I’m not saying that you’d want a Java-guru with years of experience shipping J2ME apps, but someone who understands the mobile context and is excited about the opportunity to try loading a prototype onto a phone.

Are you a Design Technologist even if your business card says something different? Do you want to learn techniques for translating your designs into prototypes quickly? I’ll be leading a day dedicated to this very topic at our Good Design Faster workshop in April. Register with the promo code BLOG for 10% off.

For most casual web users today, the smallest thing on the Internet is a web page. This is the element that a user can recall via a URL, store in a bookmark or forward to another user. Sure, there’s sub-elements of a page such as the text or an image or an embedded video, but most users are not savvy enough to deal directly with these. More importantly, users typically don’t care to break sub-elements out of the context of their web page since the browser offers no compelling reason to do so.

For Aurora we saw an opportunity to change the browser’s focus from the page to the individual “object”. Giving users the ability to interact directly with the atomic parts of a given web page offered greater personalization of their Internet experience. As we see in all three of the movie segments users can tear off parts of a web page and store them for use later in their browsing. Sometimes those parts are recognized as people objects and sometimes they are discrete data objects. The objects can be combined with other web pages or other objects. For example, refer to the second segment where a calendar event (data object) is pulled from a web page and dropped onto a person that’s resting in the browser frame.

My favorite combining of objects is displayed in the first movie segment where rainfall data is styled to be more usable. The browser automatically recognizes that the data bound to the page is interactive and this data reacts visually when a second presentation object is dragged on top. The intersection of the data provided by the National Weather Service site and the preferred presentation from the user creates an information source that clarifies the rainfall trends for our actor.

At UX Week I was thrilled to see Jeff Veen present a similar idea in his session titled “Designing Our Way through Data“. Amazingly his example even uses rainfall over time as the data source. Here’s the five relevant slides (pdf) from his presentation:

During our brainstorming we envisioned that a marketplace could open supporting the creation of presentation objects. You don’t like the way that Google search results look but you like the underlying data? Well, just purchase Dan’s Fancy Results (only $9.95 for a limited time) and add it your browser. Did you create an amazing mash-up with data from Amazon and Last.FM plus your own visual design? Sell it in the presentation object marketplace!

Like many of the ideas in Aurora, objects are based on the extrapolation of current technologies. The semantic web is already recognizing and defining the atomic elements of a web page. The browser can sniff out these elements (microformats) via plugins like Operator. By default all modern browsers also present the existence of an embedded RSS feed to the user. Our notion is that data and presentation objects in Aurora are some evolution of markup, like XML.

A prototype was released by Mozilla Labs this week that tackles many of the same concepts. Aza Raskin describes the Ubiquity concept as “allowing everyone–not just Web developers–to remix the Web so it fits their needs”. Similar to Aurora’s data objects, this experiment relies on the ability of the browser to see information within a page as discrete elements. The atomic level of the web is reduced to something smaller than the page.

Ubiquity for Firefox from Aza Raskin on Vimeo.

Adaptive Path is a pretty homogeneous company, technologically speaking. We’re a 100% Mac shop. Some of us fire up Parallels to create a Visio document or to play with Expressions, but this is a rarity. As a developer this limits my ability put a page design through it’s paces on disparate platforms and web browsers. Also, we only have a limited need for browser testing. Many of our projects don’t require us to deliver production-level code to a client. It doesn’t make financial sense to spend a lot of time and money setting up a lab and staffing a QA team for browser testing. This is why I love Browsershots.

Browsershots is a automated service that will take screenshots of your site on various browsers. You start a request by feeding the site a URL. That request is distributed amongst a network of volunteer computers each of which is running one or more operating system and browser combination. Sit back and wait for your job to move it’s way through the queue and return your screenshots. I submitted the uxweek.com homepage to 55 browsers and it took about 1 hour to return all of them.

What did I find out? Well, I have a little bit of tweaking if I want IE 5.5 on Windows 2000 to look perfect and something called ELinks on FreeBSD doesn’t like the site at all:

As if the FREE service was great enough on it’s own, the software that powers Browsershots is open source so you can create your own distributed testing environment. Why would you go through the effort? Maybe you have super-secret content that you’d like to keep behind a corporate firewall. Maybe you have the expertise and demand for your own dedicated testing lab. Whatever the rationale, it’s great that the site author was willing to release the source code.

What’s Browsershots NOT good for? Because of the queue nature of the service, it doesn’t work well for real-time trial and error. You would need enormous patience to make a one-line change in your CSS and wait to get a screenshot back only to find that the change didn’t have the effect desired. For the same reason, you won’t want to count on Browsershots for testing pages right after they go live. It just takes to long. Use the service for the occasional testing of your design on an enormous number of platforms when you have the time to wait.

Who’s using Browsershots right now? Take a look at their recent screenshots page.