Help Your Content Go Anywhere With A Mobile Content Strategy

You’ve put a lot of thought, time and effort into creating great content, and you want users to have a great experience with your content. While you might have created the best content in the world, you don’t get to choose how users access it. That’s why it’s important to make sure your content works beautifully on every platform and device, desktop, mobile or something else entirely.
Before you panic, I’m not advocating that you create individual content strategies for each device or network that your content is published to. That would be crazy, and it wouldn’t necessarily work better for your users.
It’s not because you wouldn’t do a good job — it’s because it would be impossible to plan and keep up with special content strategies for every device that exists now (not to mention ones that haven’t been invented yet).
While there’s no magic bullet to make sure your content is publishable and useful on every device, you can change the way you think about, plan for and create content so that it can go anywhere it needs to go.
Developing a mobile content strategy isn’t just about making content look as good on phones and tablets as it does on the desktop. As Sara Wachter-Boettcher writes in her book, “Content Everywhere“, It’s about creating portable, flexible content structures that go wherever your users are, without sacrificing quality. It’s an intimidating task, but not impossible. We’ll start with an example, then cover some of the things you can do to make your content more flexible and accessible.

First, An Example: How NPR Learned To COPE

National Public Radio’s (NPR) core product has long been high-quality audio journalism. But because audiences don’t solely rely on their radio for news, NPR needed a content strategy that would allow it to reach a larger audience by publishing stories to multiple platforms. It needed a way to expand its radio stories with photos, videos, audio and text and get them to readers, no matter what devices they were using. They also needed to be efficient and cost-effective and make it easy for journalists to publish their stories. So, it developed a content strategy that would ensure that its stories would work well on every device without their having to create new publishing platforms for each type of device or having to duplicate every story for each platform.
The key to the strategy was to create “display-agnostic” content structures that allow journalists to COPE — create once, publish everywhere. In NPR’s new strategy, journalists file their stories once to a CMS. Each story published to the CMS has common elements — titles, categories, tags, captions, etc. — that can be shown or hidden depending on the device and that is distributed via an API. This way, NPR’s designers can change the content’s presentation for each platform without sacrificing quality or requiring the editorial team to publish stories multiple times.
Here’s a small example of how it works. Check out one story about Downton Abbey from NPR’s Monkey See blog. The story was written, edited and then published to NPR’s CMS. But because of NPR’s COPE model and APIs, it displays a little differently on different screen sizes.

Looks good, right? Let’s break it down by the elements in the desktop excerpt:

• categorization (of the Monkey See section)
• headline
• excerpt
• a few links to related tags (to the right)
• image
• image caption (hidden behind that blue button)
• image credits (also hidden behind the blue button)
•  
• You’ll notice it’s pretty much the same, but with a few small differences:
  
• While the category is still there, the related tags aren’t used.
• The image credit is visible right below the image, while the caption is still hidden behind the button.

So, the journalist published the story once, and the same content is presented, but some of its elements are left out or rearranged to accommodate for the smaller screen.
In order to create a content strategy that works for you and that goes wherever your users are, you have to stop thinking about devices. Instead, start working to create content that has structure, even as it takes on different forms.

Content Modeling: A Difficult, Time-Consuming And Incredibly Necessary Process

Before you can build an effective content strategy, mobile or otherwise, you have to know exactly what you’re working with. That’s where content models come in — they’re a way to give your content an organizational structure without defining its form, and they’re very important to your strategy’s success.
Trust me, content modeling is something you want — no, need — to do, not because it’s a fun time necessarily, but because doing it early has the potential to save you a ton of time, money and heartache later. Doing content modeling early, before you get into the design and development process, is much better.
Raise your hand if your design team has ever spent weeks or months on a really lovely design for desktop and mobile, only to show it to the client for review and realize that you haven’t accounted for content types that need images or video or some other crucial element. That’s the worst, right? By spending a little time on content modeling, you’re reducing the risk of that happening, while also making your designers and developers’ lives easier. Content modeling isn’t difficult, but it takes some time and effort.
Let’s say you’re working on a website geared to home cooks. Your team is ready to start working on a new mobile content strategy. Before diving into your strategy, though, you need to get your team together for a content modeling session.
A content modeling session is easy to set up. You’ll just need to get a few key stakeholders together around a whiteboard for an hour or two (though, don’t be surprised if it takes longer). There’s no limit to how many people you should invite to the content modelling session, but don’t let it get too big. Include a few of the people who will be creating the content — they’re the ones who will be dealing with the content the most — as well as anyone charged with setting standards, goals and direction for the brand.
Start by looking at the website’s existing content types. What kinds of stories, blog posts or other content types are being created? List each content type and the elements it includes, like photos, captions, body copy, headlines, etc. Don’t forget to include things like newsletters, podcasts, listings and events — the point here isn’t to do this quickly, but to be thorough. For our cooking website, two of the website’s content types might be recipes and ingredients.
Once you’ve got a list of content types, break them down by element. You’ve established that two of the content types are recipes and ingredients. These two content types are related (recipes consist of ingredients, and ingredients can be tied to specific recipes), but each includes its own unique set of elements.

After you’ve listed each existing content type and its elements, think about what content types you’d like to be able to create in future. For example, do you want to go beyond recipes and ingredients and create sets of seasonal dishes? Or is your business model shifting to include notable chefs or contributors, who will need to be featured. Nothing is off limits — think about your business goals, editorial goals and audience’s needs.

Once You’ve Got Models, Start Building Them Out in the CMS

Once you’ve got your content model in place, start setting up a CMS that will help you COPE.
Every CMS is a little different, but in most cases you won’t need to create an entirely custom CMS to support your new content strategy. In most cases, you can bend your existing CMS to your will by creating page types, post types, custom fields and field sets that make it easier to create and display content. You can tie field sets to page and post types, which will make it easier for your content creators to add all of the necessary information.
For example, you might set up a page type in your CMS for each recipe and include these fields:

• ingredients list (linking each ingredient to its ingredient page);
• cooking time;
• categories (like season or course — think appetizers, desserts, etc.);
• introductory copy about the recipe;
• recipe instructions;
• tags;
• author (which could possibly include fields for the author’s name, a head shot and a short bio).

Once you know which elements make up each content type and have accounted for them in your CMS, you’ll be able to COPE. You’ll have a flexible content structure that allows you to publish each recipe or ingredient once, even though it might be presented differently on each platform. You can then work with your designers and developers to figure out which elements should appear when.

Understand How Your Content Will Be Used

Ultimately, we don’t get to choose when someone decides to use the content we create or which platform they use it on (but, oh, the world would be a much simpler, if less interesting place, if we did). So, why think about use cases? Because our job is to make our content accessible and useful to all users, no matter when or where it’s being used.
Super-smart content strategist Karen McGrane puts it this way:

People use every device in every location, in every context. They use mobile handsets in restaurants and on the sofa. They use tablets with a focused determination in meetings and in a lazy Sunday morning haze in bed. They use laptops with fat pipes of employer-provided connectivity and with a thin trickle of data siphoned through expensive hotel Wi-Fi. They use desktop workstations on the beach—okay, they really only use traditional desktop machines at desks. You’ve got me on that one.

Going back to the recipe website, it has a ton of possible use cases. You may have users who:

• spend time browsing the website for recipes on their desktops and planning their menu before going to the grocery store;
• pick up an interesting ingredient at the store and pull up your website on their phone to learn more about it and to see what recipes it could be used in;
• call on Google Glass to find a recipe on their way to the store;
• prop their tablets up in the kitchen like a cookbook;
• ask an audio interface to read a recipe to them step by step.

What do all of these users have in common? Each one of them deserves to have a great, complete experience with your content.
“But wait!” you might say. “We’ve got a ton of data showing that our users use our website in this particular way on this particular device.” That may be mostly true, but you can’t always be absolutely positive. That’s why the best solution is to make all of your content available and easily accessible across all platforms.
Such accessibility doesn’t mean sacrificing the user experience, though, nor does it mean that the presentation of your content must be identical on phones, desktops and tablets.
Each device has its own considerations for design and user experience that your content can work within. Let’s consider some examples.

• You might choose to highlight specific content elements on different platforms, while placing others behind a menu.
• Or you could opt for a more visual presentation on large screens, using larger images that might not work as well on smaller screens. (For example, you might hide each section of a recipe behind a tappable button on a phone, so that users can quickly see and access the information they need.)
• On desktop displays, you might choose to immediately show more photos of recipes associated with an ingredient to encourage further browsing.

The point is that while your content’s presentation may change, users should be able to access the same amount and quality of content from any platform.

Adapt Your Editorial Process To Your Strategy

Once you’ve done the hard work of modeling your content and thinking about use cases, you should have a pretty good idea of the content you’re working with and where it needs to go.
Before running off and firing up your CMS, you need to consider one more thing: the editorial process. Remember that content strategy is not just about structuring content for the reader, but also about making the process of creating content efficient, thoughtful and sensitive to the content’s mobility.
Your editorial team and its process are crucial to implementing your new content strategy. Your content creators are the ones who will be dealing with the new structure the most, so it’s important to understand their existing processes, any pain points they may have and any changes they’d like to see. Even if you feel pretty good about the editorial process, this is a good time to check in with the content creators to see whether they need anything to make their work easier.
Creating and implementing a flexible content strategy could also mean making some changes to the way your content is published. In a perfect world, it’ll make things easier. When you don’t have to worry about publishing each piece of content to its own platform, you’ll probably be able to streamline the editorial process. Instead of content creators having to create content in more than one place and editors having to edit for each platform, a COPE model allows the editors to edit each piece only once.
During content modeling, you may have added a few new content types or elements to the content’s structure. Don’t forget that these new pieces will need to be brought into your editorial policy. Here are a few things to consider:

• Who is responsible for creating each piece of content? The writer, the editor or someone else?
• Who publishes the content once it has been edited? Does the editor publish it, or do they inform the writer that it’s ready to go?
• Who is responsible for categorizing and tagging content? Will your writers do that or your editors?
• How will the content be created? Will the writers create content directly in the CMS, copy and paste from a document, or submit a document to an editor for publication? Given that many CMS’ allow writers to save unpublished drafts, asking your writers to create their stories in the CMS instead of in a document might not be a bad idea. This will reduce the number of steps each story goes through and will make formatting and editing easier.

Additionally, the new content structure could require changes to your editorial standards. You’ll likely have to put new guidelines in place for any new content elements you have added. This is also a good time to review existing editorial guidelines to make sure they still make sense. Think about things like the following:

• Who will choose the photos that go with posts? Who will write the captions? Do photos have to have captions?
• If you’ve added any new content types (for example, “chefs”), who is responsible for creating those new pieces?
• How many categories and tags should be assigned to each piece of content? Does the writer or editor choose them? Also, who determines when it’s time to add a new post category or tag? (Personally, I recommend that editors set them in order to keep things consistent and to make sure you’re not doubling up on tags. This is especially important in content structures such as in the recipe example, which require posts to be in certain categories in order to be found.)

Before implementing your new device-agnostic content strategy, you may need to revisit your guidelines to account for things that might display differently on small screens. Headline lengths may have to be adjusted so that they don’t completely take over small screens. Also, you might have to change the guidelines on image sizes to make sure that a photo attached to a story looks just as good on large monitors as it does on tablets.
Finally, even if you feel pretty good about the editorial process, this is a good time to check in with the editorial team to see whether they need anything or whether you could implement new processes as part of your strategy to make content creation easier. To dig deeper, I highly recommend reading Sara Wachter-Boettcher’s book, “Content Everywhere“.

Final Thoughts

Remember that any new strategy is partly a learning process. And content is messy — it’s human and it’s vital, and ensuring that its creation, distribution and use go smoothly requires a lot of time, effort and coordination. As long as you’re working to make sure that every user has a great experience with your content, you’re fighting the good fight.
Use content models to understand each type of content you’re publishing and the elements it includes. Then, use post types, page types and custom fields to account for each element in your CMS. Study your users to learn how they interact with your content. Try to address their most common needs while making sure the content works well across all platforms. Adapt the process of creating content to your new strategy. Train your content creators to use the new content structures you’ve created, and put editorial guidelines and practices in place to ensure that the strategy will be implemented.
By taking the time to create content structures that can go anywhere, as well as considering use cases and tightening up your editorial strategy, you’ll be confident that the content will work, no matter who’s using it or where.
If you’ve got stories about creating mobile or device-agnostic content strategies that you’d like to share, please leave them in the comments.

Involving Clients In Your Mobile Workflow

A lot of mobile-minded talented folks across the globe produce great work, but yet sometimes you still hear many of them complain about their relationships with their clients. They often mention feeling isolated and not truly understanding what the client really needed.
This lack of personal interaction often leads to misunderstanding, as well as less awareness of and appreciation for all your hard work. While involving clients in your mobile workflow can be challenging, really working together will make a big difference. In this article, I’ll share some important things I’ve learned about involving clients in my mobile workflow. Let’s dive into some tips and tricks that I use every day.

Work Out Your Manifesto

Projects don’t happen overnight. It usually takes a few meetings to get to know the client and to discuss collaboration. Your company’s business strategists and account managers invest a lot of time and energy in this process. While they will often seem to distance themselves from your daily work, speaking with them is a real window of opportunity. These “suits” are the first ones to meet potential clients, and they convey your company’s vision, portfolio and creative approach. They can be a great help in nurturing a more involved relationship.
A great way to approach this internal conversation is to work out a manifesto, a summary of your creative vision and beliefs. Get together with your team and discuss your existing workflow and how it could further support what you really stand for as a team. Ask the team lead to help you work it out and make the message tangible. Do this simply by making a presentation to your colleagues. But why stop there? You could design posters, flyers, even stickers for your team so that they can help you spread the word.
We were getting really frustrated with clients asking us to define or optimize their mobile experience, when in fact they just wanted us to make things “prettier.” The slide above helps our client service directors to detect how potential clients really think about design. If we see that they don’t value our vision or approach, then we respectfully decline to work with them. Involvement starts with finding clients who want you to work with them, instead of for them.

Don’t Miss The Kick-Off

A kick-off meeting is the perfect opportunity to raise awareness of and appreciation for your mobile workflow. Learn as much as possible about the client, and find out how they would like you to help their business. Do this simply by asking about their vision, strategy and goals. Also great is to ask what inspires them and to get insight into their competitive research and analysis. From the minute you show true interest in their business, you are changing the way they look at you. By immediately working with them, you become their partner, instead of just someone who designs and codes.
A kick-off meeting is also a great time to double-check that you are on the same page. Sometimes we forget that our creative jargon might confuse clients. Big Spaceship points this out in its inspiring manual (PDF):

“We act like humans, we talk like humans, and we think like humans. And we call out anyone who does the opposite.”

In the last two years, I’ve learned that clients find it very hip to focus on responsive design, even if they don’t clearly understand it. Too often, it leads to a discussion on size and dimensions, when the conversation should be conceptual and strategic. Reserve some time in your kick-off meeting to explain what “responsive” means and why you believe in its value. Educate the client and steer the conversation towards what is really needed to make the project better. And if you notice that a certain topic needs more time and attention, host a mini-workshop to talk it through.

Dealing With Isolation

I don’t understand why some account and project managers try to keep their team away from the client as much as possible. Granted, it makes perfect sense that they manage the client, oversee the scope, deadlines and budget, and handle the communication and next steps. But when the work is in progress, keeping the team isolated doesn’t add any value. If this happens to you, explain to the manager that getting direct feedback from the client will help you fine-tune the product better and more quickly — a win-win for everyone.
At Little Miss Robot, we try to hold half of our meetings in our studio. Clients find it inspiring to be in this creative environment — especially because it is where their own product is being developed. In long-term projects, we also ask the client to designate a space at their office for our team to work on the project. When developing Radio+, worked at the client’s headquarters twice a week. Anyone could hop in and out of the space and have informal conversations about the work. Not only did it create a great atmosphere, but we also received the most valuable feedback during these times. Highly recommended!

Seeing Things

A typical project starts by the team exploring or defining what they will create. A lot of teams rely on textual aids, such as functional requirements. While these documents contain a lot of detail, I always end up having to address misinterpretations. The worst part is that these “minor” misunderstandings always pop up during the production stage, resulting in increased time and expenses. Have you noticed on these occasions that the client says they “saw” things a bit differently? This is why I recommend using text documents to scope features and using visual resources to describe them. Mind maps, wireframes, storyboards and paper prototypes are my personal favorites.
I always encourage clients to get involved in generating these visual resources. Having them by your side during a brainstorm or a UX workshop is really helpful. While they wouldn’t consider themselves designers, I’m always challenged and inspired by their thinking and how they see things.

Feeling The Progress

Throughout the mobile development process, you will probably invite the client to several meetings to discuss the status of the project and to demo the product. Make sure you have something tangible to talk about. If a meeting is just about process, time or budget, then let the project manager handle it. Build momentum when meeting in person, and show your work in progress on real devices! Of course, you could print out the design or demo the application on a big screen, but the client should be able to feel the progress in their hands, too. Feeling a product grow in your hands is a much more powerful and engaging experience!
Some great tools exist to share designs across devices. We use AppTaster to share mockups, Dropbox to share designs and TestFlight to distribute apps to clients. If we are building a mobile website, then we just host it on the client’s servers internally, which allows them to view the latest version whenever they want.

Happy Ending

Involving clients in your mobile workflow is the key to better understanding their problems, goals and strategies. You’ll also raise more awareness of and appreciation for your work, thus reducing negative energy and making discussions more positive and constructive. However big or small your team or client, it all starts with a desire to be involved. These take-aways can help you with that:

1. Create a manifesto that explains what your team stands for.
2. Hold a kick-off meeting to ask the client about their vision, strategy and goals.
3. Use both your and their offices to meet.
4. Scope features in text documents, and describe them in visual documents.
5. Take advantage of third-party tools to share your work in progress on real devices.

Last but not least, read on how to wrap up a project and follow up afterwards. This is critical to building and maintaining a long-term relationship. Most importantly, it will lead to future business because the client will already know and value your work.
Please feel free to share your experiences and thoughts in the comments below. I’m already looking forward to reading them.

Key Ingredients To Make Your App Go Viral

A viral app is the highest achievement on iTunes and Google Play. It’s an app that customers eagerly share across the Internet, through social networks, email, chat and word of mouth. It’s like rocket fuel, and it is the best case scenario for an app developer because word of mouth is far more powerful than any paid advertising. Ad clutter is everywhere, and people just ignore it.
No one trusts ads, and they cost too much for developers anyway. But humans have shared stories since we’ve been using rocks as tools. We’re naturally built for viral sharing.

But getting your app to spread faster than celebrity gossip takes a lot more than bolting on some Twitter and Facebook buttons. It requires strategizing a world of social interaction inside your app.

What Is Viral?

Virality is about interacting with people and enticing them to participate. Virality isn’t a marketing strategy that can be executed once you launch. It has to be thought through and built into your app from the beginning.
To succeed, your app must pass these four tests:

1. It must have something valuable to share.
2. It must make it easy for users to share and for friends to join.
3. It must reward users for sharing and offer them incentives to come back.
4. The more people use the app, the more value must be created for them.

First and foremost, your app has to have a gem — something valuable to share. That something could be a photo, a great wine, a turn-based game, an article, a playlist or a five-mile run. It’s your customer’s little pride and joy, and it has to be shareable.
When users share their little gem, they’ll get a warm fuzzy feeling that keeps them checking into the app over and over. The more they check into the app, the more praise and delight they will get from it. And when the app’s audience grows, the value just keeps going up.
To figure out whether your app has any gems, ask yourself these few questions:

• Does my app offer something valuable to share?
• Is it worth being shared?
• How will users be rewarded when they share?
• Why will users want to share?
• Why would they want their friends to share?
• How will my app motivate users to keep sharing over the long term?

Old-School Viral Models

The typical viral flow starts when the user creates something and then shares it, leading friends to discover the gem and download the app so that they can get in on the action:

The typical viral flow strategy of apps.
With this approach, the most obvious way to offer social interaction in your app is to add buttons so that users can share their creations (or actions) on Twitter, Facebook, email and SMS. For example, the Faces app enables users to design silly faces of friends that can be shared on Facebook, Twitter and email.

Social interaction in the Faces app has a typical viral flow, because it only lets users share images.
Unfortunately, this approach misses a lot of opportunities, because only some of the users will share, and only a small percentage of their friends will actually see what they’ve shared, let alone click on the link and download the app themselves.
To go truly viral, you need to engage your audience. Every time they use your app should build on the previous experience, so that they get more value out of your app. And as the audience grows, that value should just go up.
Think of Facebook, Twitter and Pinterest. No one sees the true value of these apps the first time they use them. But the more you put into Twitter, the more you get out of it.

Five Principles Of A Viral Strategy

You don’t have to dig too deep into viral principles before you come across something called the viral coefficient. In The Lean Startup, Eric Ries defines it as “how many new customers will use the product as a consequence of each new customer who signs up.” He claims that a viral coefficient greater than 1 will lead to exponential growth, and a viral coefficient less than 1 will lead to hardly any growth at all. I won’t get into the details, but the math looks like this:

viral coefficient = (average number of users invited by each active user who invites someone) × (proportion of invited users who actually join or become active) × (proportion of active users who invite others)

One important element missing from this formula is the time it takes for a customer to try the app and share it with their friends. The key is to get your users to invite their friends in the shortest amount of time possible. How do you do that?
The quick and dirty method is to just tap into their address book and spam their friends. But then you’d be abusing your customers rather than caring for them, and it will backfire in the end. Instead, try the five principles outlined below. (Most of the examples shown are iOS apps, but the principles apply to all platforms.)

Principle 1: Make It Effortless

The best apps appear so effortless that the design fades into the background, making the task at hand surprisingly easy. This is “flow,” and it has nothing to do with processes or charts. It’s about being completely absorbed in doing something you love and not being distracted by confusing or burdensome steps. The user loses a sense of time and self and becomes completely immersed. It’s why you can’t stop playing Minecraft and why your friend just spent three hours on Pinterest.
To create flow in your app, you’ll need to remove all obstacles and doubts that users might have about using your app and sharing it with friends. Let’s go through a few examples of how your app can do that.
Offer one-click sign-in via Facebook or Twitter, rather than with a dedicated user name and password. This not only gets users registered quickly, but lets you tap into important data to grow the network.

500px offers one-click sign-in via Facebook or Twitter.

Rockmelt offers one-click sign-in via Facebook, Twitter or Google.

Snapguide offers one-click sign-in via Facebook or Twitter.
Display profile pictures of friends during authentication to increase their audience as well as yours.

Foursquare displays profile pictures of the user’s friends during authentication.

Vine displays profile pictures of the user’s friends during authentication.
Motivate users on the first screen to get started by clearly showing how they can grow their network and start sharing.

The first screen of Foursquare offers a clear path for users to get started.

The first screen of Hipvite (now defunct) encourages users to get started.

The first screen of Toast encourages users to get started.
Prioritize what is on the screen, and show top actions right in view. Users need to know what they can do.

SoundCloud puts the top action right in front of you.

Wrappit has top actions right in view.

Snapguide has top actions right on hand.
Enable users to easily post to multiple social platforms with just one tap. Always make sharing part of the creation process, and let users post to multiple websites at once. One big advantage of the Android framework over iOS is that it allows apps to share anything with virtually any other app (as long as that other app can receive the “share” intent). This opens up all sorts of interesting viral potential.

Krop Circle lets users post to Instagram, Twitter and Facebook all at once.

Glmps lets users post to several websites with just one tap.

Rexly lets users post to Twitter or Facebook or send by email, all in one action.

Principle 2: Reward Often

If you want to encourage a certain behavior, reward it. This basic psychological tactic has been used on us since we were toddlers, and it will motivate your customers to share your app with friends. Give them a gift for each friend they get to use your app.
Best of all, when someone gives a gift, the recipient naturally has the urge to give one in return.
Inviting friends and connecting with others should be a part of their daily usage. Daniel Tenner, founder of Swombat, suggests that the number of users who each of your active users invites will determine your success. Therefore, inviting friends should be a core process in your app, rather than an afterthought. Experiment with ways to encourage customers to invite friends at different points in the app.

POP’s prototyping app rewards users for signing up early and telling friends.
Reward the friend, too. Rewarding customers for their referrals can make them feel guilty that they are making money off of their friends. The best way around that problem is to also reward the friends who receive their invitations. Voila! Now your customers feel like they’re doing their friends a favor. Everyone wins.
Rewards could be:

• extra storage,
• free themes,
• a character,
• a free upgrade,
• discounts,
• sample sizes.

To create a sense of urgency in the invitation, offer a limited-time promotion. This can get people out of their holding pattern by giving them an incentive to take action before the offer expires. It costs you nothing and could be just the push your customers need to convince their friends to download the app.
Sneak in secret rewards and surprise people, then watch as the app goes viral. Clear unlocks hidden themes when you follow some of the app’s developers on Twitter or if you complete a task at 2:00 am (I discovered that one the hard way). These hidden gifts create a storm on Twitter each time a new one is found, giving the app all sorts of wonderful free publicity.

Clear rewards users with free themes based on other apps installed on their device and based on when they use them.

Each time a new theme is discovered, a Twitter storm happens, making the Clear app more viral.
Some apps even pay people to use them. Not that you’ll need to go to such length, but apps like Shopkick, GymPact and Viggle let users earn real cash and rewards by using them.
With Shopkick, users earn rewards, or “kicks,” simply by walking into participating stores and checking in via the app. They can earn more kicks by scanning items and purchasing them. As a reward, users get a first look at new items in the store, and they can use their kicks to unlock gift cards and products.

Users earn points on Shopkick by going into certain stores. (Image: Hongkiat)
GymPact entices users — non-exercisers, in fact — to go to the gym, work out and earn cash. Users start by making a pact with their friends, promising to work out at the gym a certain number of days, and they set the stakes of how much they’ll pay if they skip a day. Those who go to the gym claim cash from those who don’t!

GymPact rewards people for going to the gym. (Image: Hongkiat)
Viggle is for TV junkies. It practically pays users just to watch the tube. Users earn points by checking into any TV show on the air. Users just tap the “Check-in” button, and their device listens to the TV, earning them points. More points are earned by answering trivia questions. The more points accumulated, the bigger the prizes, which vary from Starbucks gift cards to MacBook Airs.

Viggle rewards users for watching TV.

Principle 3: Give Users Control

Because virality and privacy are polar opposites, transparency is a must. Be up front about what your app is sharing, and give users full control over whether to share. If users don’t trust the app or suddenly see content appear on social networks that they don’t want to be shared, they’ll stop using your app or, worse, leave negative reviews on iTunes.
Be transparent about what is being shared. The social fitness app Teemo tells users what will be shared before they even log into the app. Sonar (iTunes link) reminds users that it won’t post to their accounts unless explicitly told to.

This nice little message in Teemo gives users confidence in the app.

Sonar reminds users of what will be shared.
Always allow users to control what is shared. This can easily be done by including a settings screen with toggles for controlling the sharing options, like in Pinterest’s app.

The settings screen in Pinterest lets users turn off publishing to their Facebook timeline.

Principle 4: Keep Pulling Them Back In

The more people use your app, the longer you’ll stick around. The longer you stick around, the more that customers and onlookers will say good things about you, spreading word of mouth and increasing your profits. So, think about people downloading your app as a springboard to achieving more, rather than as the finish line.
Send users useful notifications that motivate them to return. Don’t wait for them to start using your app. Keep sending them useful messages, as well as showing them tips to encourage them to use your app. This should be a part of your core features.
Also, keep sending friendly reminders and rewards to invite more friends, but be careful not to send out notifications that are worthless and annoying. That’s called spamming. Give users control over what notifications they receive and how they receive them, as We Heart Pics does.

The settings screen in We Heart Pics lets users turn off any notifications.
Create challenges in which users can partake. When Diamond Dash introduced weekly tournaments, users went ballistic. When a player beats a friend’s score, the victory is posted to the winner’s Facebook timeline. When they reach a new level, win a medal or unlock a feature, Diamond Dash announces it to their entire Facebook network. This dynamic has created a friendly competition, pulling users back to the game a stunning 18.5 million times in just one month.
Let users create exclusive groups and invite others to participate, as in the case of a team of supporters in a weight loss or training app.
Promote users with exceptional content or activities. Target power users who have the most connections — these are the mavens who will create the best content. Reward them with freebies and promote them to be managers so that they can set up special groups, create high-end invitations and keep the conversations going. And set them as an example by suggesting that others follow them.

Viddy suggests following the most popular users, helping those users grow their audience.
Let users promote each other. This will help you discover trendsetters. These people might not have the largest following, but they are using your app in new and exciting ways.

Principle 5: Be Useful to a Lone Person

Your app should be of benefit to users, even without the social aspect. This isn’t a requirement, but it does make your chances of going viral much higher. It gives people a chance to kick the tires first. Most people won’t invite others to join the app unless they already know it’s good. To find that out, they have to road test it a few times first.
Your app must have something meaningful for the user to do right away, without inviting friends. When your user base increases, the value of the app’s main function increases as well.

Conclusion

You can’t make your app viral as an afterthought, like pixie dust that magically gives you a ton of users. It has to be designed into the app’s core functionality and features.
You can do these things to improve your app’s chances of going viral:

• Offer something meaningful to share.
• Be transparent about what your app is sharing and whom it is contacting.
• Connecting with friends and inviting new users should be at the core of your app.
• Reward both your users and their invited friends for signing up.
• Keep pulling users back with meaningful notifications, competitions, rewards and promotions.
• Be useful even to the lone user. This is the start of your viral circle.

Unlike the Snuggie Blanket, there is no one-size-fits-all viral strategy; some apps simply won’t benefit from viral tactics. While adding viral features to your app might increase its virality, to really make your app spread, you’ll need to start with a clever idea and a good design. Combined with a fantastic viral strategy, these will surely make your app go Gangnam style.

Choosing A Responsive Image Solution

If you code websites, it’s a good bet that at least one of your clients has asked about or requested a mobile-friendly website. If you go the responsive design route (whereby your website is flexible enough to adjust visually from mobile to desktop widths), then you’ll need a strategy to make images flexible, too — a responsive image solution.
The basics are fairly simple to learn, but once you’ve mastered them, you’ll find that scaling images is only the beginning — you might also have performance and art direction conundrums to solve. You’ll be faced with a wide field of responsive image solutions to choose from, each with its own strengths and weaknesses — and none of them is perfect! This article leads you through the basics, and then arms you with the information you’ll need to pick the best responsive image solution for your situation.

The Basics

Styling foreground images to adjust to the width of their container is very easy. In your style sheet, perhaps in your normalize or reset style sheet, you’d add the following code:

img {
    max-width: 100%;
}

In most cases, that tiny style rule will do the trick! Once it’s in place, if the container around the image becomes narrower than the width of the image, then the image will scale down to match the width of its container. Setting the max-width to 100% also ensures that the image does not scale larger than its actual size, which would significantly reduce the image’s quality. If you’re still stuck providing support for IE 6 or 7, you’ll want to add a width: 100% style rule targeted only to those browsers, because they don’t understand max-width.
High-resolution “Retina” images can make this basic implementation a bit tricky. Let’s say you want your 150 × 150-pixel logo to display at double the usual pixel density, and the image is small enough that having two separate versions wouldn’t be a problem. So, you create a 300 × 300-pixel version of the logo and plug it in — and now it’s huge! Your first inclination is probably to try something like this in CSS:

img.sitelogo {
    max-width: 150px;
}

Unfortunately, this doesn’t work as expected — the logo image will now refuse to scale nicely with the other images on the page.
To limit the maximum width of an adaptive image, you’d have to limit the maximum width of the image’s container, rather than of the image itself! Let’s say you’ve wrapped your logo image in a module with a class of branding. Here is the style that will do the trick:

.branding {
    max-width: 150px;
}

So, now we have scalable responsive images in our website’s fluid layout. Mission accomplished. Time to go find out what this strange “outdoors” place has to offer to a sun-starved developer, right?
Not so fast! We still have two main challenges to overcome.

The Performance Problem

With the responsive image solution outlined above, all devices are fed the same images. Small icons and logos might not be too bad, but the problem compounds quickly as the images get larger and heftier. Retina images exacerbate the problem — you don’t want to send a big Retina image to a device that isn’t capable of displaying its full detail!
Think about it. Should we really be sending a 990 × 300-pixel 100 KB image meant for desktop viewers to a mobile phone? Sure, the mobile visitor might be on their local coffee shop’s Wi-Fi connection — however, they might be on the road trying to get crucial information from your website, with one shaky bar of wireless service. Every mobile user who gives up when your page takes too long to load is a potential customer lost!
Many mobile websites that are just as big or bigger than their desktop counterparts can be found in the wild today. Guy Podjarny ran some tests a year apart, and there hasn’t been much improvement: in 2011, 86% of websites were the same size or larger, and in 2012 that number went down to 72%, but the overall sizes of websites increased. Dave Rupert also captured the problem beautifully in his article “Mo’ Pixels Mo’ Problems.”

Complicating It Further: Browser Preloading

When I first began wrestling with performance issues on responsive websites, my initial thought was to put all of the image variations on the page, and set up some CSS classes with media queries that would hide big images and show small images at small widths, and vice versa at desktop widths. It seemed logical: shouldn’t the browser only download the visible images?
The problem is that browsers are too quick for us! In order to provide the fastest loading time possible, browsers preload all of the images that they can identify in the source code before any CSS or JavaScript is processed. So, this approach would actually penalize mobile visitors more, by forcing them to download all of an image’s variants!
Because of this preloading, most solutions require either a back-end solution (to preempt the preloading) or special markup and JavaScript.

Bandwidth Detection

The last piece of the performance puzzle is network speed. We know that we want to feed only the large images to devices that are on a speedy network, but how do we determine that? A few techniques are out there to estimate network speed, but they aren’t foolproof yet.
The W3C has been working on a Network Information API, which could be very helpful in future, but currently it’s supported by only a handful of devices (and not the big ones, unfortunately). It is currently implemented in a few responsive image solutions, but I don’t expect it to be widely adopted until it’s more widely supported. Network measurements are difficult and as Yoav Weiss states in his Smashing Magazine’s article, reliable “bandwidth media queries” don’t seem to be something that can be accurately implemented in the near future.
Foresight.js by Adam Bradley uses JavaScript to test how long the browser takes to download a 50K image, then stores that information and uses it to make bandwidth decisions. It does have a few small drawbacks: it does add a 50K image download to your page, and it can block download of other images on your page until the test image download is complete. Many of the responsive image solutions that currently implement bandwidth detection use a variation or adaptation of Foresight.js.

The “Art Direction” Problem

Let’s say you’ve got a beautiful wide image on your home page. It shows a wide bucolic expanse of fields and forest, blue sky and fluffy clouds above, and a happy family having a picnic on the grass.
Now scale it down to 300 pixels wide, mobile-style. At this scale, our vacationing family looks more like the ants at the picnic!

Detail is lost when this large image is scaled down. (Image: Mark McQuitty)
Herein lies what we call the “art direction” problem. Some images just don’t scale well; fine detail is lost, and dramatic impact is reduced. In the case of our hero image, it would be much nicer visually if the mobile version of the photo was zoomed in, cropped and focused on our happy family. To solve this problem, we need a responsive image solution that enables you either to specify different versions of the image for different situations or to adjust the image on the fly.

Sometimes a different crop or zoom of the image is desirable for narrow widths. (Images: Mark McQuitty)

Choosing Your Solution

Luckily, the web development and design community has no shortage of creative, smart people who have been working to solve these problems. Of course, the flip side of that coin is that it’s easy to get overwhelmed by the sheer number of responsive image solutions out there. How do you decide which is best for you?
Choosing between them can be an extremely complicated matter, because so many factors come into play. No current solution is perfect for every situation; each was designed to solve a particular set of problems. To decide, you’ll need to weigh each solution against your project’s particular needs. Chris Coyier has done a great job of summarizing the deciding factors (including a spreadsheet to track them all, although some newer solutions aren’t mentioned).
Here are some factors to consider:

• Do you need to solve the art direction problem (i.e. different image ratios, crops and sizes for different widths)?
• Do you have a huge website or a CMS on which going back to add special markup to every image is not feasible?
• Are all images present upon the page loading, or are some images loaded dynamically via JavaScript?
• Do you want to test for the user’s bandwidth to determine whether their connection is fast enough to handle high-resolution images?
• Does the solution require a platform that is unavailable to you (such as jQuery or PHP)?
• Is a third-party solution acceptable, or do you need to keep the solution hosted in-house?

With this in mind, let’s look at some responsive image solutions that have been out there for a while and that are widely used within the developer community.
Please note: The list of solutions below is by no means comprehensive. They are the ones either that I’ve found most useful personally or that have proven track records for reliability. Have a favorite solution of your own that’s not here? Let us know in the comments!

Tried And True Responsive Image Solutions

Picturefill

The Web is truly worldwide, and we have to confront the fact that not everyone has access to fiberoptic connections and 4G networks. Scott Jehl encountered this digital divide first-hand while travelling and working his way through Southeast Asia, and he is a strong advocate of mobile-first and responsive websites that don’t put an undue burden on mobile users. His Picturefill script is a polyfill for the proposed <picture> element — JavaScript code that mimics the picture API, enabling us to use it on our websites today. The future is now, baby!

Picturefill does not require jQuery, but obviously it does require the picturefill.js script to be included somewhere in the page. Picturefill also requires some special markup, with divs to represent the image variations, differentiated by data-media attributes that act just like media queries in CSS. You may also optionally put an image in conditional comments for browsers that don’t support media queries (I’m looking at you, IE 8), and a fallback in a <noscript> tag for browsers that don’t have JavaScript enabled (I’m looking at you, BlackBerry).
Here’s an example of a typical Picturefill setup:

<span data-picture data-alt="Descriptive alt tag">
    <span data-src="images/myimage_sm.jpg"></span>
    <span data-src="images/myimage_lg.jpg" data-media="(min-width: 600px)"></span>

    <!--[if (lt IE 10) & (!IEMobile)]>
    <span data-src="images/myimage_sm.jpg"></span>
    <![endif]-->

    <!-- Fallback content for non-JS browsers. -->
    <noscript>
        <img src="images/myimage_sm.jpg" alt="Descriptive alt tag" />
    </noscript>
</span>

That’s all you need to display adaptive images at page-loading time using Picturefill. Drop in the script, configure the markup, and everything just works. You can also call Picturefill programmatically if you need to add images to the page on the fly.
Picturefill requires a lot of custom markup, so it might not be the best choice for those who cannot alter their website’s source code for any reason. It also doesn’t do any bandwidth detection. If bandwidth detection is important to your project, then have a look at this next solution.

HiSRC

HiSRC, by Marc Grabanski and Christopher Schmitt, is a jQuery plugin that enables you to create low-, medium- and high-resolution versions of an image, and the script will show the appropriate one based on Retina-readiness and network speed.

To set it up, first make sure that jQuery and the HiSRC script is included somewhere on the page.
In your HTML code, first add a regular image tag to the page, and set the source to be the low-resolution (or smallest) version of the image. Add a class to the image or its wrapper (like .hisrc) to specify which images HiSRC should process. Then, add some special markup to your image tag: data-1x and data-2x attributes, pointing to the medium- and high-resolution versions, respectively. For example:

<img src="http://placekitten.com/200/100" data-1x="http://placekitten.com/400/200" data-2x="http://placekitten.com/800/400" class="hisrc" />

Then, after the DOM has loaded, just call the function on the image class that you’re using, like so:

$(document).ready(function(){
  $(".hisrc").hisrc();
});

In practice, the browser will first load the image source — i.e. the mobile version of the image. Then, the script checks to see whether the visitor is using mobile bandwidth (such as 3G). If so, it leaves the mobile-first image in place. If the connection is speedy and the browser supports a Retina image, then the @2x version is delivered. If the connection is speedy but Retina is not supported, then the @1x version is delivered.
You might have noticed that the low-resolution image always loads, even if the script later decides that the user’s device is a good candidate for high resolution. Even though this is technically a double-download, it only penalizes those on speedy connections. I’m willing to accept that compromise!
HiSRC can handle images that are added to the page dynamically. It also allows for multiple images, so you can specify different crops and sizes to beat the art-direction problem.
As for weaknesses, HiSRC does require jQuery, so it won’t be useful unless you’re using that library. It also requires custom markup in the HTML, so it might not be the best choice if you have a huge website with a lot of legacy images or a CMS in which the output of the image tag can’t be altered. If that’s your situation, read on!

Adaptive Images

Unlike the previous two scripts, Adaptive Images, by Matt Wilcox, is mostly a server-side solution. It requires a tiny bit of JavaScript, but the real work is done via the Apache 2 Web server, PHP 5.x and the GD library.
To install it on your Web server, you’ll need to alter or add an .htaccess file, upload some PHP files to your website’s root directory, add some JavaScript to your pages (which will add a cookie to record the user’s screen resolution), and configure some breakpoint variables in the PHP files to match your website’s media queries.

The installation instructions are quite verbose — a bit too lengthy for the scope of this article. For more information, visit the official website and click the “Details” link at the top.
The best feature of Adaptive Images is that it requires no custom markup on any of your images. Once you’ve installed and configured it correctly, you’re all set! The PHP script will intercept any request for an image and will resize it on the fly as needed to your specified breakpoint sizes and serve it on your pages automatically.
The PHP has a lot of configurable options, such as image quality, breakpoints, caching, and even a sharpening filter to apply to the generated scaled images.
It has a few limitations:

• Because it requires the combination of Apache and PHP, Adaptive Images might not match up with your website’s platform or be available on your Web host’s server.
• It relies on the Web server’s ability to intercept any requests for images (via the .htaccess file). So, if your images are hosted elsewhere, such as on a content delivery network, then it won’t work.
• It doesn’t detect bandwidth.
• It’s not meant to solve the art direction problem, because it only rescales the original images. It can’t crop or create different aspect ratios from the original image.

You may have noticed that all of the solutions thus far require JavaScript, and often some detailed configuration. If you’re looking for one that doesn’t require JavaScript and that is fairly simple to implement, then have a look at this next one.

Sencha.io Src

Previously known as TinySrc, Sencha.io Src is a third-party solution that acts as a proxy for images, so you don’t need to configure anything on your server. Just point your image at Sencha’s servers (with or without some options specified), and Sencha will process it and send back a resized version as needed.

Let’s say you have a big image:

<img src="http://www.your-domain.com/path/to/image.jpg" alt="My large image" />

At its simplest, you’d just prefix the src attribute with http://src.sencha.io/, like so:

<img src="http://src.sencha.io/http://www.your-domain.com/path/to/image.jpg" alt="My large image" />

By default, Sencha.io will resize your image to fit the width of the device’s screen, using the user-agent string for detection. Phones might be sent a 320-pixel-wide image, tablets a 768-pixel-wide image, etc.
You can also configure the Sencha.io prefix string to return particular measurements, orientations, percentage sizes or any number of complex calculations.
Sencha.io is a free service for individual users and can be a very convenient adaptive image solution. However, you’re adding a third-party dependency, with the possibility of downtime and problems beyond your control. Weigh these risks carefully.

Responsive Image Solutions To Watch

The solutions outlined till now are usable today, but they’re not the only fish in the sea. Some newer solutions show a lot of promise, and I’m keeping a sharp eye on them to see how they evolve with current Web technology. Below are two in particular that you might want to watch.

Capturing/Mobify.js 2.0

Capturing is a new feature of the in-development Mobify.js 2.0, which proposes to give you access to (or to “capture”) the HTML source markup before it is parsed or rendered by the browser. Accessing the source code at this stage enables you to swap an image’s src attribute before the browser downloads it. You can even craft a fallback to one of the other solutions, such as Picturefill, in case something fails.

Since this technique directly circumvents native browser preloading, it is a bit controversial in web performance circles. If misused, it could actually create performance problems on a site instead of alleviating them!
The other thing holding me back from running to this solution with open arms is its cross-browser support. Capturing won’t work in any version of IE lower than 10, so IE 8 and 9 users will be left out in the cold. I’ll keep watching, though — down the road a ways, when IE 8 and 9 finally fade into the sunset, this solution might be more viable!
If you’re interested in finding out more about Capturing, the Mozilla team goes into more detail in its blog post, “Capturing: Improving Performance of the Adaptive Web.”

ReSRC.it

ReSRC.it is another third-party solution (recently out of beta) that delivers responsive images from the cloud. It seems to be very similar in implementation to Sencha.io Src, but adds image filters and bandwidth detection and doesn’t rely on user-agent detection or cookies.

To get started, you first need to sign up for a trial account at ReSrc.it.
Second, you’ll need to insert their Javascript file on your page (this is the simple JS code; they offer an asynchronous embed method as well to improve performance):

<script src="//use.resrc.it"></script>

Then, suppose you have an image like this:

<img src="http://path/to/image.jpg" alt="My large image" />

You would prefix the image source’s URL with a path to ReSRC.it’s servers, and add a CSS class of “resrc” to the image. They currently have two servers, one for paid accounts and one for trial accounts — we’ll use the trial one for our example:

<img src="http://trial.resrc.it/http://www.your-domain.com/path/to/image.jpg" alt="My large image" class="resrc" />

ReSRC.it allows you to add parameters to the requested URL to perform operations on the image, such as rotating, cropping and flipping. This allows for quite a bit of flexibility and potentially addresses the art-direction problem. The parameters are processed in order from left to right and can be strung together.
Here’s an example of an image that’s being flipped horizontally, resized to 300-pixels wide, with the resulting image optimized to an 80%-quality JPEG:

<img src="http://trial.resrc.it/r=h/s=w300/o=80/http://www.your-site.co/image.jpg" alt="My large image" class="resrc" />

ReSRC.it is recently out of beta, so if anyone using the service has tips or advice (pro or con), we’d love to hear more about it in the comments.

Test, Test, Test!

After you’ve chosen and implemented a responsive image solution, testing the performance of your website is absolutely necessary to making sure that the solution is working well. Below are a few useful online testing tools to help you.

YSlow

Created by Yahoo, YSlow is a client-side tool that analyzes your website against 23 testable rules that Yahoo has determined can adversely affect Web page performance. YSlow awards your website a grade for each rule, explaining each one and suggesting how to improve your website’s performance. YSlow is available for Firefox, Chrome, Safari and Opera (as well as by a few other means, such as the command line).

WebPageTest

The online tool WebPageTest is an open-source project maintained by Google. You enter your website’s URL, perform a speed test from a chosen location, and specify which browser to use. Advanced settings allow you to perform multi-step transactions, pick a network speed (cable, DSL, FiOS, etc.), disable JavaScript, block ads and make other requests, and more. The results come in the form of tables, charts, screenshots, a performance review and a lot of great data to dig into!
The Yottaa blog has an article detailing how they used WebPageTest to test out their website both with and without responsive image loading — check it out!

Conclusion

If you read this blog regularly, you’re probably already on board with creating the best possible website experience for your audience. So, the next time you craft a beautiful, usable experience for mobile visitors, try out one of these responsive image solutions and take your website the extra mile. Your mobile visitors will thank you!

Delve Deeper

• Jeremy Keith took some wonderful notes on Scott Jehl’s presentation “Responsive and Responsible” at An Event Apart in Atlanta.
• Feeling confused and frustrated? It’s OK; we’re all figuring out this responsive design thing together! Josh Long exhorts us all to band together and share our experiences in “I Have No Idea What I’m Doing With Responsive Web Design.”
• Want to take it further? Get involved! Join forces with the folks in the Responsive Images Community Group. You can also follow them on Twitter.

Establishing An Open Device Lab

Managing a personal device lab can be quite hard with an ever expanding number of devices. It’s not only expensive, but also bad for our environment. Think of a situation where every Web developer would purchase a large pile of gadgets and keep adding new ones as they are launched — this wouldn’t make much sense. Thankfully, there are better ways to handle the problem.
During the spring of 2012, Jeremy Keith wrote on his website that anybody is welcome to visit their device lab at Clearleft’s office in Brighton, UK and use their devices. What they didn’t expect, though, was that in response many local developers offered to add their own devices to the collection as well. Two weeks later Jeremy Keith and Remy Sharp also presented this idea at the Mobilism conference in Amsterdam and the people attending loved it. A few months after Mobilism, similar labs started popping up in places like Amsterdam, Berlin, London and Malmö.
Following this example, we decided to bring our own devices to the Kisko Labs office and do the same thing in Helsinki. We now have an open device lab where anyone can come, start using the devices and contribute by lending their old devices. Three weeks after establishing this we already have three new devices from the local community: a Nokia N900 running Maemo, a Nokia Lumia 800 running Windows Mobile and an HTC Desire HD running Android. I have also been in contact with the device manufacturers and so far at least Nokia, Palm and Sony have promised to help us out with the lab.

Helsinki Open Device Lab, devicelab.fi.
I encourage everyone to do the same thing in the city they live in as well. This article will cover most of the things needed to be considered when doing that. It will also work as a guide and give practical tips — things like location, how to get devices, what devices to get and what software to use. At the end of the article is also a list of all the current open device labs around the world.

Location

This is probably the hardest part as it should be relatively open, easily accessible, but also a safe location to prevent burglars. I wouldn’t be too worried though as that’s a risk you need to take with any office space that’s filled with desktop computers and other gadgets. Just make sure that the space has proper locks and an alarm system in place.

Mozilla’s workspace in London. Image by @mozillaeu.
Finding a location was never a problem for us as we had a space at the office which wasn’t used that often, but I understand that it might be hard to find one unless you already work in a location like that. However, I imagine that the best places to start asking are local Web community meet-ups, conferences and Twitter. Find out about local co-working spaces too, as those could be the best candidates to host these kind of projects. I also asked Shaun Dunne (who established the London Device Lab) if he had any advice on how to find a space, and this is what he answered:

“I was in the Reasons to be Appy conference during April when Christian Heilmann mentioned Mozilla’s new London office and how it had a co-op space with free WiFi for anyone to use. I spoke to him after his talk and mentioned what I was trying to do and he said that he thought Mozilla would be more than happy to host it. He said I should speak to @cyberdees who runs things in the office. We exchanged a few emails and I went there a couple of times and it was born from there.”

Devices

You don’t need a huge collection of devices to establish a lab — it can initially be small and grow once other developers start contributing their devices. Some device manufacturers are also willing to help the community by providing test devices for initiatives like this, so you should definitely contact them too.
There are basically four main areas that need to be covered in the lab. These are: feature phones, smartphones with low level support, smartphones and tablets. Later on you might also want to consider adding a Smart TV and other more exotic devices like game consoles. Additionally, the lab should also efficiently cover various screen sizes between 240 x 320 and 1280 x 800 pixels, as well as some high-DPI variants.

PhoneGap’s Device Wall. Photo © 2012 Adobe Systems Inc.
David Blooman from BBC recently shared the process that they use while testing on mobile devices, and the minimum set of devices to get the job done. This list is a slightly modified version of their minimum test device stack. For now it is a good starting point for anyone who is thinking about setting up an open device lab:

• iOS 5 — iPhone 4
• iOS 6 — iPad 3 Retina
• Android 2.2 — HTC desire
• Android 2.3 — Huawei U8650
• Android 2.3 — Kindle Fire (Silk browser)
• Android 3.X — Motorola Xoom
• Android 4.X — Samsung Galaxy Tab 2
• Blackberry OS 5 — Curve 8900
• Blackberry OS 6 — Bold 9700
• Windows Phone 7.5 — Lumia 800
• Symbian S40 — Nokia 2700
• Symbian S60 — Nokia N95
• Symbian Belle — Nokia 500

Remember: You will want to end up with a collection that represents the audience and overall market share in your own location, which might be different from what I have listed here. Stephanie Rieger, who is a co-owner of Yiibu, has written an excellent article explaining Strategies for choosing test devices (so be sure to read that to find out more about the subject). Dave Olsen has also written an article about how to build a device lab, where he explains how and why they decided to get certain devices.

“If I had to start from nothing, I would start with the phone in my pocket. After that, I would take the usual suspects — Android 2.3, iOS5, etc., and make sure to have the more popular phones in place, but not go overboard. One of each to begin with, and then more varieties as time goes on. In a good way, everyone’s device lab should be different, as every market is going to have variations. There is no golden list of devices.”
— David Blooman

How To Contact Device Manufacturers

• You will need to have a space and a website (a single-page website is fine) for the lab before asking for any devices. Otherwise, it may be hard to look convincing.
• Twitter and email seem to be the best way. Look for developer relations accounts like this from Twitter and send emails to their developer related addresses. You can find the addresses from the developer websites, which usually reside in an URL formed like this: developer.manufacturer.com.
• Ask people on Twitter if they know someone who works at one of the companies you are trying to contact. It may be an easier way to begin communicating with the right people.
• When sending emails, explain carefully what the project is about, what you need and why you need it. It’s good to keep it short and get straight to the point.
• Remember that you are sending emails to other human beings, not to some random corporations.
• If you don’t get any answer from them within two weeks try to contact another person from that manufacturer.
• Last but not least: Don’t be afraid to ask for help. I contacted several people about their test devices and where they got them from. Shaun Dunne (from the London Device Lab) was also kind enough to provide his perspective on how to contact the manufacturers:

“I started hitting the developer relations people up on Twitter. BB and Palm got back to me via Twitter and an email conversation went on from there. Nokia had their developer relations person at Mobilism, so I found out his email and sent him an email directly. It’s about being persistent, really, email is hard because it could end up in their spam or they can ignore it.”
“In a public forum like Twitter it’s harder for them not to engage. Don’t just go after the hardware manufacturers either, it’s worth speaking to the Android + WP7/8 people to see what they can do for you. If they want people to develop applications and websites that work on their devices, then it’s in their best interests to get those devices in developers’ hands. The best and easiest way to get the devices in their hands is through a community lab.”

Setting Up The Lab

You don’t need much in the beginning: a table, a few chargers and a Wi-Fi connection is all you need to get things up and running. If you have more than five devices, it may be a good idea to get a USB hub which can provide power to avoid cable clutter and stands where you can put the devices on. A few of the labs have also built their own stands and you can get some ideas from the resources listed below. Jeremy Keith also told me that they have all the devices running through a wall socket that’s on a timer which switches the power off in the evening and nighttime and back on again in the morning. That might be useful for saving some energy and also to keep the batteries healthy.

64 Digital’s device testing station. Photo © 2012 64Digital.
Later on, when there are many more devices in the lab, you may want to start considering getting a better wireless router which can handle all the devices. Andre Jay Meissner told me that Apple’s Airport Extreme can handle up to around 30 devices, but not much more (it claims to support 50!). SIM cards with data plans are also something which you might need once you start adding older devices that exclude Wi-Fi.

• 64 Digital’s Device Testing Station
• PhoneGap’s Device Wall
• Clearleft’s Laboratory Conditions
• Anna Debenham’s Sketches for the Clearleft Lab
• Animoca’s iOS Testing Wall
• Helsinki Open Device Lab’s Desk
• How to Build a Device Lab [Part 1]
• Need: Multi-Device Stand for Mobile Web Development
• Handmade Phone and Tablet Stands by The Iron Mill:
  These are the same stands used by both Clearleft and ourselves. The website doesn’t really say it, but you can order them from anywhere in the world, just send a direct email to the contact address and ask for a delivery price.

Software Tools To Get You Started

• Adobe Shadow:
  Probably one of the best tools for testing at the moment. It allows device pairing, synchronous browsing and remote inspection using Chrome extension on either Mac or Windows. To be able to use Adobe Shadow you will need to download and install the mobile client to all test devices. In addition, you will also need the Google Chrome extension to run Shadow on your laptop.
  
• JS Bin:
  JS Bin is a Web app specifically designed to help JavaScript and CSS folks test snippets of code, within some context, and debug the code collaboratively. You can use JS Bin together with the Adobe Shadow mentioned earlier.
  
• Web Inspector Remote:
  Weinre is a remote inspector tool for WebKit browsers. It has been included in the Adobe Shadow application, but you can also set up your own installation to be able to use it on platforms like WebOS and Blackberry (in addition to the iOS and Android platforms).
  
• xip.io
  xip.io is a domain name that provides wildcard DNS for any IP address. You can use these domains to access virtual hosts on your development Web server from devices on your local network (like iPads, iPhones, and other computers).
  
• Showoff.io, Localtunnel, Proxylocal:
  For sharing your localhost over the Web.
  
• Mobile browsers:
  Remember to install various browsers like Opera Mobile, Opera Mini, Chrome and Firefox to all of your supported test devices.
  

“Be sure to track the OS versions found on your test devices, and think carefully each time you upgrade. Owning four BlackBerry devices with four different versions of the OS is infinitely more valuable than owning four with the same version.”
— “Strategies for choosing test devices” by Stephanie Rieger.

Adobe Shadow running on multiple devices. Photo © 2012 Adobe Systems Inc.

Maintenance

There are some running expenses — rent, Wi-Fi, personal time used — and you may initially need to spend a few hundred bucks to provide chargers, wires and stands for the devices. So it’s worth considering if a small monthly payment would be acceptable. As it also might not be possible to find a space which is completely open like the one in London, it’s possible to have everything available by appointment too. This seems to be quite common practice and it allows you to use the same space for your own workshops as well, if needed.
In the beginning, when you are setting up the lab, I wouldn’t worry about all of this though. It’s possible that the lab will get popular and have lots of visitors and that someone might be using the devices when someone else comes in, but only time will tell. Shaun Dunne also said that they were discussing this very same problem in the beginning and decided finally that the lab should just be open. Jeremy Keith seems to think in a similar manner:

“When I started the device lab in Brighton, I didn’t worry about the paperwork. Instead of worrying about insurance, theft, liability and all those other worst-case scenarios, I decided to just do it and deal with the bad stuff if and when it arises. So far, so good.”

Closing Words

I believe in testing on real devices. Software emulators and simulators can be useful, but in the end they can only do that; simulate the experience (as Paul Robert Lloyd points out). To make testing on real devices possible for everybody, we need open device labs. If your city doesn’t yet have such a lab, I would say go for it, establish one. Don’t worry about the amount of devices you start off with, you’ll be surprised about how much the community is willing to help.
Last but not least: just a few days ago, while writing this, Andre Jay Meissner contacted me about the possibility to set up LabUp!, which would help people around the world in establishing nonprofit Open Device Labs. I think it’s a splendid idea and everyone who can help should join the movement.

Open Device Labs Around The World

This list is by no means complete, but it should include all the labs which were established before this post was published. For the future you should bookmark the up-to-date list of all open device labs which Jay is collecting.

• Brighton, UK
• London, UK
• Frome, UK
• Berlin, DE
• Malmö, SE
• Breda, NL
• Helsinki, FI
• Zurich, CH
• Portland, USA
• Marietta, USA
• Cape Town, ZA