How to decide between a responsive website or a native mobile app

Many business owners and entrepreneurs struggle with whether they shoulddesign a responsive website that works across devices or focus exclusively on building a native mobile app.

It’s a difficult choice to make since both options present advantages and disadvantages that must be taken into consideration when moving forward.

As of last year, apps from retail businesses took up to 27 percent of consumer’s time, which sheds lights on how critical a mobile app can be to reaching your customers where they are active online. At the same time, 67 percent of consumers say they are more likely to purchase from a mobile-friendly websitethan they are from a website not optimized for devices other than desktop.

It’s a tough call to make when deciding between responsive design or an app, but in the end, it depends on the goals of your business.

If your company can afford it, it’s highly recommended that you build both a responsive site and a native mobile app in order to help your business work towards capturing the attention of your entire mobile audience. The native mobile app will provide a mobile centric experience for your existing and most loyal customers, while your responsive website can help provide an optimized experience to new and old visitors browsing your website or discovering it for the very first time.

For example, popular ecommerce brand Nasty Gal has a responsive website and a mobile app to help provide the best experience for its shoppers however they wish to shop the brand’s products.

Most companies can’t afford to do both, which is why it’s important to understand the advantages of both options when addressing your company’s mobile priorities.

Responsive design isn’t a cure-all

Responsive Web design is certainly the most affordable option for your business as compared to the development of a mobile app. Take into consideration the initial costs of redesigning your website to be mobile friendly, then the cost of occasional upkeep and upgrades.

If visibility in the search engines is an increasingly important part of your strategy to grow your business, then a responsive website is critical in helping grow traffic to your website. A mobile app lives in a closed environment and cannot be indexed by the search engines, which requires driving traffic to this app through alternate methods.

BBC Responsive Design How to decide between a responsive website or a native mobile app

Depending on your designer and the size of your website, a responsive Web design often takes far less time to create then does a mobile app since there’s no app store approval or extensive guidelines to follow as compared to what GooglePlay, the Apple app store and the Windows Phone app store require for launching an app.

If the goal of your destination online is to be universally accessible from any device, then responsive design is the solution. A mobile app is designed for a unique experience; exclusive to the operating system it lives on, which means it isn’t a one size fits all fix.

However, don’t think of responsive design as the easy way out when it comes to optimizing your website across mobile devices. Although a responsive website optimizes your experience, it doesn’t incorporate all the smart phone features like the camera or GPS that a native mobile app can.

A mobile app will provide users with unique functionality and speed that can’t be achieve with a responsive website, but can be experienced on the operating system you choose to design your app on.

It’s better than not having a mobile-friendly version of your website, but it’s not the finally solution for your customer’s experience with your business on mobile. Again, the choice between responsive and a mobile app depends on what your goals are for mobile.

Consult analytics to inform your native mobile app

A mobile app offers a compelling, unique and mobile specific experience for your customers, which is one of the main reasons why your company should consider designing an app over worrying about making your existing website mobile-friendly.

First and foremost, if you have existing data to analyze than it is important to use your analytics tools like Google Analytics or Omniture to see what mobile devices are used the most to visit your website in the past few months. This can help inform what operating system you decide to design your app on.

Google Analytics Referral Traffic How to decide between a responsive website or a native mobile app

Whether you decide to go with iOS, Android, Windows Phone or another less popular operating system, it’s essential to match the features of the operating system with the type of app you’re looking to create whether it’s an ecommerce store, a content focused website etc.

Besides being able to utilize more of the features incorporated in a mobile device into the experience, a mobile app often has access to more data from a user and therefore, can provide a more personalized experience.

This personalization through data could play out in the types of push notifications an app sends you, product recommendations, suggested content to view or other specific user-driven actions. When a user makes a profile on an app, it makes gathering data about a person and their online habits much easier for a business and much quicker and smoother for the user continually using this app to shop, find events to attend, listen to music and perform other tasks.

As of now, a native mobile app offers the best user experience for a person on a mobile device since there are still limitations to how HTML 5 can be parsed on mobile.

As the complexity of the responsive website increases, the more likely the user experience will begin to suffer. A native mobile app offers the best user experience to your audience, taking advantage of the phone’s functions and the expectations of customers using these devices.

Lastly, in-app purchasing drives 76 percent of all app marketplace revenues to date since once it is setup, it’s particularly easy for users to make a purchase with pre-entered credit card information.

This is best suited if your app will offer micro-purchases, which our low price point products or services within the app, like buying virtual goods, membership to the premium version of the app or access to additional content.


When responsive design will make sense for your application

A few months ago, I found myself in a Twitter debate over whether or not responsive design can work for web apps.

While it was a fun debate, trying to answer the question of whether or not responsive design makes sense for your app is futile. Let me explain.

We don’t have a common understanding of what responsive means.

I wrote about my struggles with figuring out what is “responsive” recently. People think they know what others mean when they say something is responsive, but our definitions often differ.

The best responsive designs use much more than responsive design. When that is the case, it is easy to find faults with any given responsive implementation that can be used to say, “Well, that’s not really a responsive design.”

What happens when you use responsive web design, but add to it things that seem to be at odds responsive design? Is it possible to add something that make it no longer responsive? If so, where is the line?

What is a web app?

If responsiveness has a murky definition, “web app” is considerably worse. Jeremy Keith has long argued that “like obscenity and brunch, web apps can be described but not defined“.

Chris Coyier recently polled his readers about whether or not it was useful to distinguish between “web apps” and “web sites”.

While people agree that the distinction is important, there was little consensus on what the distinction was. Chris summarized his findings thusly:

I was kind of hoping we could get somewhere close to a solid distinction between these two classifications, but I don’t think it’s going to happen. There is very little agreement and heaps of opinion.

So any time we’re discussing web apps, we’re going to have trouble agreeing on what we’re talking about. Discussing responsive web apps is just asking for trouble.

A case study in different perspectives

Here is a timeline of articles and discussions that illustrates my point perfectly:

June 17, 2013 — Responsive design Web apps – good or bad?

On a content only site it [responsive design] probably is very wise to start small and scale up. But in a highly interactive functional UI the UX will be damaged by the time you scale up. Or vice versa. Take a demanding environment such as online betting or a tipping platform. The users needs are potentially very different between device environments.

July 4, 2013 — Why Responsive Web Design is a Must for Gambling Sites

I personally have no doubts that responsive web design will become an official standard for all good web pages and web content design to comply in the future, sonow is the right time for you to start using it on your gambling and sports betting sites.

June 13, 2013 — Case Study: Betting on a fully responsive web application

 is one of the top sports betting providers and their services include popular sports from all over the world…At Kambi 
we went all-in on this bet and decided to build a web application that scales across the board. The value was clear, unified development process and consistent user experience on all platforms…Fully responsive web applications is not just a pipe dream anymore*. With the right mindset, tools and processes it all becomes possible.

July 9, 2013 — I point to Kambi as an example of responsive design being used for a web app. Nick Finck replies:

To summarize:

  1. Gambling apps are too complex to use responsive design.
  2. All gambling apps should be responsive.
  3. A case study of how a popular gambling app was built to be responsive.
  4. The gambling app in the case study is too light-weight.

Therein lies the problem. Even when we have a specific niche app/site (e.g., gambling), we can’t agree on the definitions. We have a case study of how a gambling app was made responsive, but we derive different conclusions about how applicable the case study is.

And I’m fine with that. I don’t mind ambiguity. People don’t have to agree.

I just think it points out how futile it is to try to convince others that responsive design for web apps makes sense.

My thoughts on responsive design for apps

For my own part, I believe responsive design for apps is a no-brainer. We’re building apps for clients that use responsive design. I’ve seen large, complex apps for Fortune 500 companies that are in development. I’ve seen what other agencies are working on.

This stuff is coming. And perhaps when enough of these projects launch, we’ll move on from the debate about whether or not responsive design works for apps like we’ve moved on from similar questions about responsive design for ecommerce. (We have moved onhaven’t we?)

But even if I wasn’t fortunate enough to get a behind the scenes look at upcoming responsive app projects, I would still argue that responsive design for apps is inevitable:

Once you start accepting the reality that the lines inside form factors are as blurry as the lines between them, then responsiveness becomes a necessity.

I’m not saying there isn’t usefulness in device detection or looking for ways to enhance the experience for specific form factors and inputs. This isn’t a declaration that everything must be built to be with a single html document across all user agents.

What I am saying is that even in scenarios where you’re fine-tuning your app code and UI as much as possible for a form factor, that the differences in screen size and the various forms of input within a form factor alone will be enough to require you to design in a responsive fashion.

Sure you can build a complex web app without responsive design that only targets tablets, but that app would be limited. There is too much variation in the screen sizes of tablets for a design that isn’t responsive to work on more than a handful of devices.

I’m much more interested in skating to where the puck is going to be, no matter how difficult, than to fixate on what is easiest to do now.

We’re focused on helping our customers make their apps work across devices. And that means taking on many complex challenges. Making apps responsive is just one of them.

So how will you know when responsive design makes sense for your app?

When you decide it does and put in the hard work to make it so. The rest of the discussion is just noise.


Using Content To Define User Experience

In her presentation at Breaking Development in Nashville TN, Steph Hay talked about the importance of narrative in digital experiences. Here’s my notes from her talk on Using Content To Define User Experience.

  • The Sesame Street TV show was based on actual research of how kids learned and continually measured to make sure it was reaching their educational goals. They approached content development by isolating chunks of programming, testing it, and continually refining.
  • The big paradigm shift was learning first then writing second.
  • Content and technology that guides people over time forms a narrative that allows people to act.
  • Use cases in software design tend to be very flow-focused and high level. Requirements docs just focus on the what. Content is the missing piece in everything we’re doing.
  • When content really works, we can get from point A to B more quickly and easily.
  • Use content to explicitly set expectations then meet them regardless of device.
  • Design is only part of the narrative, the other half is the real human people that experience what we are designing.
  • The “you” orientation of content focuses on the user, not on the company. It positions the customer as the other half of the narrative.
  • Features by themselves won’t protect your narrative, you also need relevance.
  • There are two kinds of narratives online: setting expectations (through marketing), and functional requirements (through experience).
  • Write content first. This is the paradigm shift.
  • Many organizations are afraid to write content first because they are used to writing it last. But this results in missing pieces and incomplete experiences.
  • State your goal: what are you trying to accomplish, what are your users trying to accomplish.
  • You can use tools like Google Keyword builder and Google Analytics to find the language people are using to find you. What terms make sense for them? Use these terms to create a conversation.
  • The content is the structure. This is why it makes sense to start there.


Relying Too Much on Screen Size

As people continue to go online using an ever increasing diversity of devices, responsive Web design has helped teams build amazing sites and apps that adapt their designs to smartphones, desktops, and everything in between. But many of these solutions are relying too much on a single factor to make important design decisions: screen size.

What’s Wrong With Screen Size?

It’s not that adapting an interface to different screen sizes is a bad thing. Quite the opposite. It’s so important that key metrics like conversion and engagement usuallyincrease substantially when Web sites adjust themselves to fit comfortably within available screen space. For proof, just look at how mobile conversion rates increase significantly more in responsive redesigns than PC conversions do.

So if adapting to different screen sizes can have that kind of positive impact for a business, what’s the risk? As the kinds of devices people use to get online continue to diversify, relying on screen size alone paints an increasingly incomplete picture of how a Web experience could/should adapt to meet people’s needs. Screen size can also lead to bad decision-making when used as a proxy for determining:

  • If a browser is running on a mobile device or not
  • If Network connections are good (fast) or bad (slow)
  • If a device supports touch, call-making, or other capabilities

None of these can actually be accurately inferred from screen size alone but they are comfortable assumptions that make managing device diversity substantially easier. The harsh truth however, is that output (screen size and resolution) is only one third of the equation -at best. Equally important to determining how to adapt an interface are input capabilities and user posture, which sadly screen size doesn’t tell us anything about.

Let me illustrate with a few specific examples.

Screen Size Limits

On tablets, PCS, and TVs, Microsoft’s Windows 8 platform allows any app, including the Web browser, to be “snapped” to the side of a screen thereby letting people interact with it while using another application in the primary view. As an example, the Windows 8 calendar application can be snapped alongside the weather app when making your daily plans.

Windows 8 Snap Mode

Notice though, that the default view of the calendar application on Windows Phone 8 is quite different than the snapped view of the same app on a tablet, PC, or TV. They are both using the same amount of screen width (in relative pixels), but the mobile interface starts with a daily agenda instead of a small month view by default. The controls are also adjusted to the mobile form factor as you can see in the image below.

Windows Phone Weather App

We can debate about why these differences exist and if they should or not but the bottom line is there’s more than screen size being taken into account in these application designs.

This simple example illustrates the challenge for Web designers. On Windows Phone devices, Internet Explorer uses 320 pixels for its device-width (the width it renders content at). On Windows 8 tablets, PCs, and TVs, snap mode uses the same 320 pixel device-width to lay out Web pages docked alongside other apps.

So with a responsive Web design, people get the same interface on a smartphone that they get in snap mode on a TV screen due to the same device-width (320 pixels). You can see this illustrated in the image below.

Polar on XBox One And Smartphone

But should the interface be the same? A TV is usually viewed from about 10 feet away, while the average smartphone viewing distance is about 12 inches. This has an obvious impact on legibility for things like font and image sizes but it also affects other design elements like contrast. So a user’s posture (in this case viewing distance) should be taken into account when designing for different devices.

The input capabilities of a TV (D-pad) can differ wildly from a those of a mobile device (touch) or in some cases be the same (voice). Designing a simple list interface for d-pads requires a different approach than a creating a similar listing for use with touch gestures. So available input types should also be considered in a multi-device design.

When you take user posture and input capabilities into account when designing, an interface can change in big or small ways. For instance, contrast the design below for Windows 8 snap mode on a TV compared to a mobile version of the same feature.

Polar Adapted to TV and Smartphone

While the screen size (320 pixel device-width) has stayed consistent, the interface has not. Larger fonts, a simplified list view, inverted colors, and a lot more have changed in order to support a different user posture (10 ft away vs. 12 inches), and different input types (d-pad vs. touch). As you can see, screen size doesn’t give us a complete picture of what we need to know to design an appropriate interface.

Before you dismiss this as an isolated use case on Windows 8 devices, note that Android smartphones and tablets also offer the ability to interact with multiple applications side by side and Android-powered TVs won’t be far behind. In fact, we’ve already got Android eyepieces like Google Glass that pose similar challenges.

Google Glass allows you to view applications and Web pages using a display that projects information just above your line of sight. The official specs describe the Glass display as a “25 inch HD screen viewed from 8 feet away.” So right up front, viewing distance matters.

Google Glass Screen Specs

Like most mobile Web browsers, Glass uses a dynamic viewport to resize Web pages for its screen. On Glass the default viewport size is set to 960 pixels and pages are scaled down accordingly. So if someone is viewing the Yahoo! Finance site, it displays like this in the Glass browser (below). Essentially, it is shrunk down to fit.


Yahoo! Finance on Google Glass

The Web browser on Glass also allows pages built responsively to adapt to a more suitable device-width. In this case, 640 pixels. So a Web page designed to work across a wide range of screen sizes would render differently on Glass. Given that 600 pixels is a common device-width for 7 inch tablets, the page you’d see on Glass would look more like the following -adapted for a smaller viewport size.

Yahoo! Mobile on Google Glass

In addition to the Web browser, Google Glass also includes a number of “glassware” applications built with the same Web technologies used to create Web pages. One of these apps provides access to stock price changes -very similar to what you see displayed prominently on the Yahoo! Finance site. However, the presentation of this information is very different. As you can see in the image below it’s been designed as if you are viewing a 25” screen from 8 feet away. This design is much more suited to a wall-sized display than a small tablet screen.

Google Glassware for Finance

This Glassware interface is also designed to make scrolling through information using the touchpad on the side of Google Glass (which comfortably supports sweeping left/right and up/down gestures) fast and easy.

So again user posture and input capabilities inform how to design for a specific device. Screen size alone doesn’t tell us enough.

Supporting Everything

In order for an interface to adapt appropriately to different output, input, and user posture, we need to know what combination of the three we’re are dealing with at any given time. On the Web that’s been notoriously difficult. We can’t tell TVs from smartphones or what devices support touch without relying on some level of user agent detection, which is often looked at dubiously.

Because of this, Web developers and designers have smartly decided to simply embrace all forms of input: touch, mouse, and keyboard for starters. While this approach certainly acknowledges the uncertainty of the Web, I wonder how sustainable it is when voice, 3D gestures, biometrics, device motion, and more are factored in. Can we really support all available input types in a single Web interface?

A similar approach to user posture is increasingly common. That is, an interface can simply ask people if they want a lean-back 10 foot experience, a data dense 2 foot experience, or something more suited for small portable screens. This makes user posture something that is declared by people rather than inferred by device. Once again, this kind of “support everything” thinking embraces the diversity of the Web whole-heartedly. However it puts the burden on each and every user to understand different modes, when they are appropriate, and change things accordingly. (Personally I feel we should be able to provide an optimal experience without requiring people to work for it.)

Ultimately trying to cover all input types and all user postures in a single interface is a daunting challenge. It’s hard enough to cover all the screen sizes and resolutions out there. Couple that with the fact that an interface that tries to be all things to all devices might ultimately not do a good job for any situation. So while I embrace supporting the diversity of the Web as much as possible, I worry there’s a limit to the practicality of this approach long-term as the amount of possible inputs, outputs, and user postures continues to grow.

Don’t Assume Too Much

These examples are intended to convey one important point: don’t assume screen adaptation is a complete answer for multi-device Web design. Responsive Web design has given us a powerful toolset for managing a critical part of the multi-device world. But assuming too much based on screen size can ultimately paint you into a corner.

It’s not that adapting to screen size doesn’t matter, as I pointed out numerous times, it really does. But if you put too much stock in screen size or don’t consider other factors, you may end up with incomplete or frankly inappropriate solutions. How people interact with the Web across screens continues to evolve rapidly and our multi-device design methods need to be robust enough to evolve alongside.

Web Performance 2.0

In March 2012, Guy Podjarny ran a test comparing the performance of hundreds of shiny new responsive websites across four different screen resolutions. The results were very dissapointing. (1)

Two years into the rise of Responsive Web Design, after every imaginable sort of designer and developer had jumped into the train, it took a test to almost rock the theory to its foundations.

Guy proved that almost every known responsive site was overweight.

We’ve made the internet in our image… ObeseJason Grigsby

But, most importantly, every mobile user was receiving the same kilobyte overload as a desktop user.

The community had different reactions to the fact. Some claimed Responsive design wasn’t the ultimate solution, perhaps not mature enough for the challenges web designers face today.

Thankfully, the Web community can always count on a number of people who will grab the bull by the horns and turn the situation around. Modern Web gurus likeBrad FrostLuke Wroblewski or Christian Heilmann saw opportunity where others shouted crisis and managed to turn the problem to the community’s advantage.

If your website is 15MB, it’s not HTML5, it’s stupidChristian Heilmann

Web performance has traditionally been built around (no offence) developer-exclusive jargon.

Terms like GZIPing, uglifying, minifying, DNS Lookup, file-concatenation… This obscure words push designers out of the ecuation.

Smart people in the community, though, have since realized that the problem has a deeper root. It really doesn’t matter if you optimize or compress an ultra-high-res image, if your plan is to hide it from a mobile user and still make him download it.

Good performance is good designBrad Frost (2)

To achieve truly lightweight sites, performance shouldn’t only be a concern. It should be treated as a design feature.

To them, performance is like any other issue. Sites that overcome it are the ones who acknowledged it from the start. And the ones that overlook it are the ones that suffer it in the end.

Performance is about respect. Respect your users and they will come back.Brad Frost

The Why

It’s not only that you want users to have a good experience. If that was the case you could easily swap performance for a more important concern in your agenda.

Page Abandonment

Research shows 57% of users will leave your site if it takes more than 3 seconds to load. (3)

Google, page speed & SEO

Back from the spring of 2010, Google takes speed as a ranking factor. (4)

The impact is not major for average-speed sites, but if the page falls behind a certain threshold, it will be punished by the company’s search algorythm.

This proves speed not only is a concern when talking about User Experience. Be aware of loading speed if your site is to be ranked well among the competition.

Bandwidth considerations

Back in the day, people used to talk about the very abstract concept of ‘Mobile Context’. Google´s famous theory breaks mobile users down to three types (5):

Repetitive Now

People that use their phone to stay up to date with ongoing, repetitive changes (sports scores, Facebook feeds or stock market)

Bored Now

Users that put their phone out while waiting for something to happen.

Urgent Now

Pretty self explanatory

Sounds assumable, right?

Well, the truth is there is no truth about this. There is no 'mobile context'. People will use their phone not only when they are walking in the street, travelling by train or relaxing in their home. They do everything at the same time!

Phones follow people everywhere, so people use them anywhere.

Mobile context is important, but first we need to figure out what the heck it is.Tim Kadlec

Luke Wroblewski shows some really interesting stats: (6)

Where are people using mobile devices?

  • 84% at home
  • 80% during miscellaneous downtime throughout the day
  • 76% waiting in lines of waiting for appointments
  • 69% while shopping
  • 64% at work
  • 62% while watching TV (alt. study claims 84%)
  • 47% during commute in to work

As new situations emerge, as new markets and different habits rise, mobile context will change. We can safely assume that the concept of mobile context will always be on the move, until people stop using mobile phones.

This leads us to keep an eye on bandwidth. There is only one scenario where you can serve users an obese website and get away with it: serve it to their macbook pros, while they are at home in UK or the USA with a full bandwidth.

But the rest of possible situations, which are a great many, have to be covered aswell. These include the seemingly endless stream of devices poured every day into the market, which people use to visit websites.

You don’t get to decide which devices access your site, your users doKaren McGrane

They include the countries which didn’t have that many smartphones a few years ago, but are ruthlessly getting ahead.

If your stuff, if your content, if your information, if your products, if your services are not available on mobile, they don’t exist for these peopleKaren McGrane

But more importantly, they include all the places people will be at when using your site. So you have to watch all bandwidths. It’s not only inhabitants of poor areas of the world clearly don’t have the same data-speed coming their way. People will try to access a site at work, with a 100mb/s connection; at home, with 2 to 30mb/s and also with 3G, and also with 4G, and also with a data plan, etc., etc.

To put it bluntly, Responsive design is not anymore about screen sizes but about different scenarios, so the solutions must be flexible, adaptable and thought out top to bottom.

And How?

Well, glad you asked.

We said before not to look at performance as a bunch of automated tasks run server side that help with an already doomed site. There are ways to undertake this concerns and turn them into a competitive advantage.

What to avoid

Guy Podjarny cites three main reasons for the number of bloated responsive websites we see out there: (1)

Download and Hide

Assets are still downloaded, but hidden.

Download and Shrink

High-res desktop-level images are downloaded, and shrinked to fit the users screen

Excess DOM

There is no way to avoid browsers parsing and processing all areas of the DOM, including the hidden ones

A preemptive approach

There’s a great deal of information out there about why websites keep failing to surpass expectations in performance. But what most people come to say is something like ‘Be responsible from the start’. All techniques I’m going to cover have been around for a while. To me the interesting part comes in how they mix and intertwine, covering each other’s flaws and combining their strenghts. It is now, deep in the mobile explosion that they show how powerful they are.

Progressive Enhancement…

…is all about providing a web experience reduced to the essential and take it from there.

A couple of years ago this theory was taken mostly from a browser point of view. With emerging technologies like HTML5, CSS3, jQuery and so on, the web makers had kind of forgotten about their users. Quite a big percentage of them were getting an incomplete form of their site, relying a bit too much on this shiny new tech.

Now that Webkit engines and Firefox and others have taken over much of the market share, the problem is the enormous quantity of devices with browsers that don’t have the capabilities of the brand new iPhone or Samsung. Again, Progressive Enhancement is the only approach which takes care of these forgotten players first and leave the shine for the ones that can take it.

Mobile First Development

Back in 2009, Luke Wroblewski proposed designing mobile first for three reasons: (7)

  • Mobile is exploding
  • Mobile forces you to focus (allowing you to get rid of the clutter that stems from having too much screen real estate)
  • Mobile extends your capabilities (with technology like GPS, geolocation, multi-touch gestures, accelerometer, cameras…)

Since then, Web design has been rapidly shifting to this approach. Along the way not only designers, also many developers, have pointed out that building mobile first gives you an edge over desktop development, very related to Luke W’s second point. Progressive Enhancement and Mobile First Development have suffered a fusion of sorts. Devs start building for mobile and progressively enhance from there, taking larger screen space as an enhancement over a mobile core foundation.

Jordan Moore makes a good summary of the reasons(8). He argues that, since 'we can't safely bet on connection speed''The 'responsible Web designer' would build for the lowest point of entry - a mobile-first approach, assuming for the slowest connection speed and building up from there to larger breakpoints for faster connections'. In the future, we will be able to rely on solid bandwidth detection, but for now it is a good idea to take it as a concern and try not to take any steps in the wrong direction.

To sum up:

Code the site for the lowest resolution and possibilities that you care about. Make true use of Progressive Enhancement from the start. Build extra functionality, enhanced visuals and interaction when it can be used.

RESS: REsponsive Web design + Server Side components

To many people, Responsive design had kind of an essential short-coming. It relied mainly in screen width detection.

As more and more types of devices emerge, hybrid devices like touch screen laptops and so on, feature detection has become essential for Responsive design. Libraries that provide it, mainly Modernizr, have bloomed and are now used on most projects. They help devs valuate whether the client’s browser supports certain functionality and provide it accordingly. But many times it’s tricky to rely on browsers, because ‘they’ will say they support features when, really, ‘they’ do whatever they want. Support for new features is usually partial.

RESS was born to provide a solution. Like Mobile First, the term was coined by Luke Wroblewski in 2011 (9). It relies on detecting the user’s device type, evaluating it and providing an experience taylored for it. To do this, there are heavy tools out there, like WURFLDeviceAtlas or lighter ones like Browser Gem, that read the user agent string and start from there.

Evaluating the device type has other advantages. It allows devs to serve different templates depending on the user’s device. Say you are building a ver large site, and you want your mobile navigation to be a simplified one, that doesn´t take half as much space as the desktop one. You could either play with content, showing and hiding stuff, moving divs around with JavaScript, or you could have different templates for mobile and desktop screens and have the server decide which one to serve.

This gives Responsive design an edge over Mdot sites. Mdot’s only advantage until RESS came along was providing an experience specific for mobile devices.

The BBC (very smart people, with millions of readers across the globe and a big responsibility toward their users) talk about how RESS and Progressive Enhancement could work as one and only. They call their approach Cut the Mustard! (10). It consists of creating a core experience that will work on every device you can imagine. After that, they evaluate the device on the server and they decide whether or not it ‘Cuts the mustard’. If it does, a progressively enhanced experience is handed out. But again, if it doesn’t, the user can still access the core content.

Conditional Loading

Mobile users want to see our menu hours and delivery number. Desktop users definitely want this 1mb png of someone smiling at saladMat ‘Wilto’ Marquis

Let’s take a couple of points of view into account:

  • Mobile users want THE content, as much as desktop users.

If your content is accessible from a URL, it will be accessed by mobile devices.Brad Frost

  • Mobile forces you to focus. There are some constraints designers have to embrace to serve the same content, like bandwidth and lesser screen size.

Also refered to as ‘Agressive Enhancement’, this development technique allows designers to focus on the core content and progressively enhance it for bigger screens. It provides basic access to certain content that can later be injected on the page when space becomes available.

It might be more accurate to think of conditional loading as a content-first approach. You don’t have the luxury of sidebars or multiple columns to fill up with content that’s just nice to have rather than essentialJeremy Keith

Use excellent tools like MatchMedia, that mimics CSS behaviour evaluating screen size in JavaScript.

Lazy Loading

Image and user heavy sites that need to be optimized for mobile, like Facebook, Twitter or Pinterest, make use of Lazy Loading to provide a better experience. When you first load the page, a number of posts is loaded. When you scroll down, the designer assumes it is because you want to browse through even more content, so it is injected in the page via Ajax. This makes the page load much faster by avoiding DOM excess.

Setting a performance budget

Tim Kadlec argues that setting a maximum page weight and being always aware of it is the ultimate way to keep page load down (11). ‘Set your goals and stick to them’. Steve Souders mentions three options to choose from, if you fall over your budget:

  • Optimize an existing feature or asset
  • Remove an existing feature or asset
  • Don’t add a new feature of asset.

To me this sounds a bit radical, but it makes a point of closely following the overall performance of a site over time and with each new feature.

Let’s get Technical!

There are certain methods to achieve speed, that work in a more technical and less conceptual level.

Image Techniques

Images constitute around 60% of websites. If you are serving mobile users with unknown bandwidth connections desktop-sized images, you are basically dooming your site to poor performance

The trick to overcome this is to serve different versions of images, depending on screen size or type. You would serve a small image to a mobile phone and a high-res one to a desktop. You would serve a double-sized image to a Hi-DPI device.

Responsive Images

Designers and developers all over the world have been fighting to get responsive images into the HTML specification. Mat ‘Wilto’ Marquis is one of the most outspoken. The battle is not yet won, but there are a number of solutions that rely on JavaScript to achieve a desired result. Scott Jehl, also from the Filament Group, wrote a plugin that mimics the markup proposed by the community and works like a charm: PictureFill

Compressive Images

Daan Jobsis, a dutch designer, found a very strange phenomenon when compressing images with Photoshop (12). He proved the following: Take an image, double its size (200%), compress it to 25% or less its original quality, resize it back in the browser(100%). The image will not only be lighter in size but already optimized for HiDPI screens, since its pixel density is already doubled.

The only observed problem is that the browser might have a hard time painting a double-sized image back to its original size (if it has to do it a hundred times, like in image-heavy sites), so a little bit of testing is required to see if this is the optimal solution.

Vectors VS Bitmaps

SVG images are the way to go at the time. They are completely scalable, so they will perform better in any screen. Providing fallback is very easy through Modernizr.

Icon Fonts

Technically they are vector based images, only served as a font. As Chris Coyier puts it, ‘Icon Fonts are Awesome because’:

  • You can easily resize
  • You can easily change the color
  • You can easily shadow their shape
  • They will work in IE6, unlike transparent PNGs
  • You can do everything you can do with images
  • You can do anything you would do with typography

HiDPI images

Dave Bushell wrote recently a very interesting article with some thinking on HiDPI images (12). He argues that, even if today we have the possibility of serving iPhones, iPads and other modern devices with images that will fulfill their screen capabilities, it is still too soon to assume a site is not going to get crippled by doing it.

Does a fast connection and high pixel density mean users even want higher quality? Not likely on mobile data plans.Dave Bushell

The point is to do it but do it sensibly, considering the case before jumping into 4x images.

What’s next

Google recently developed a new image format, WebP. It provides lossless and lossy compression for Web images, resulting in files 3x smaller, compared with PNG.

There are simple, lightweight JavaScript libraries that convert to and from WebP available today. Considering the impact of Google’s latest tools, it’s probably a good idea to start experimenting today in order to handle an image-heavy site .

Asset Loading

Load assets carefully and in order. Controlling this aspect provides a big advantage, by allowing the page to render the basic content and enhance it afterwards.

CSS, Images

Controlled loading through media queries, conditional or lazy loading and responsive / compressive image techniques


Make use of HTML5 functionality, like async or defer. There are also loading helpers like RequireJS that can handle loading and dependencies.

Advertising, Social Widgets or any third party assets

Just inject after load.

Old-school Performance Techniques

They have been around for a while, but are still as relevant today.

Reduce the number of HTTP Requests

To achieve this devs have to think resource by resource, but here are a number of guidelines:

  • Concatenate all CSS files or make use of CSS Preprocessors to compile them into one file.
  • Unify all JS Plugins under the same file and always load them in the footer, unless they really need to block the rendering of the page (if you load Typekit fonts in the footer, you will get the famous FOUT or ‘Flash of Unstyled Text’).
  • If you must use PNG images, use sprites. They unify all images in one and make use of CSS to cut the pieces. There are a number of online solutions to do this.
  • Make use of the data URI scheme where possible, that allows you to include images as inline data, getting rid of some more HTTP requests.

Reduce the number of Bytes

Uglify, minify every Script or CSS file you call from the page. Set your server up to allow GZIP compression and expansion and GZIP every asset.

In Summary

The importance of Web performance has been slightly overlooked since the birth of Responsive design.

Designers and developers have been focusing on how to solve the Responsive puzzle and, along their way, a new multi-bandwidth, multi-device, multi-location Web is starting to come into focus.

To be prepared for tomorrow’s problems, we have to include performance as an essential consideration, as the Desktop-centered Web is disappearing before our eyes. The mobile user is hastier and readier and won’t jump through hoops to get the content, and since more and more sites spring every day, being fast will mean being ahead.


1. Performance Implications of Responsive DesignGuy Podjarny

2. Performance as DesignBrad Frost

3. Website abandonment happens after 3 seconds

4. How Page Load Speed Impacts SEO And User ExperienceSpencer Yao

5. Organizing MobileLuke Wroblewski

6. When & Where Are People Using Mobile Devices?Luke Wroblewski

7. Mobile FirstLuke Wroblewski

8. Responsible Considerations For Responsive Web DesignJordan Moore

9. RESS: Responsive Design + Server Side ComponentsLuke Wroblewski

10. Cutting the mustardBBC´s Responsive News

11. Setting a Performance BudgetTim Kadlec

12. Retina Revolutie Follow UpDaan Jobsis

13. The Raster Image ParadoxDave Bushell

Follow the discussion 


Five Responsive Web Design Pitfalls To Avoid

There are number of nasty traps to avoid when making your site responsive. Brad Frost of R/GA reveals five of the biggest ones and how to sidestep them

Creating great responsive experiences requires a hell of a lot more than media queries. If you think creating squishy layouts is all this responsive thing is about, you’re missing the point. The fact is we need to deliver a solid user experience to a growing number of web-enabled devices, and creating entirely separate device experiences simply isn’t scalable in the long run. Creating adaptive experiences is a smarter way forward, but that doesn’t mean this approach isn’t without its challenges.

Here are some of the pitfalls you want to avoid as you travel down the responsive road:

1. Hiding content

Because responsive sites share a single code base, they have a better chance of achieving content parity, which is great. However, that doesn’t mean that it’s all gumdrops and butterflies. There are still many responsive sites that hide or remove content for smaller screens in order to deal with screen real estate constraints.

Follow this simple guide: don’t penalise users for the device they happen to be browsing with. People are coming to our sites and services with expectations, and it’s our job to make sure they’re able to achieve their goals. Mobile users will do everything desktop users will do, but it must be presented in a usable way. So do all that you can to make sure as many people as possible can access your content and functionality.

It’s also worth noting that content that gets hidden with CSS still gets downloaded, which is terrible for performance and brings us to our next pitfall to avoid…

2. Bloating it up!

OK, so you’re not gutting content for small screens and you’ve made an effort to deliver a full experience regardless of context. All’s well with the world, right? Well no, because now you have a bunch of stuff to load and that takes time. 74% of mobile users will leave after 5 seconds (PDF) of waiting for a page to load, and the unfortunate reality is that only 3% of small screen versions of responsive sites are significantly lighter than their large screen counterparts. That means users bear the burden of a potentially massive download.

normal page on Barack Obama’s responsive site weighs over 4MB. Four. Megabytes. This is unacceptable by any standard, but especially falls apart when you consider users who may be on EDGE, 3G or poor WiFi connection.

Obama Mobitest Performance Results

For a site whose goal it is to reach out to the general population (all with different mobile races, mobile creeds, mobile colours and mobile religions), this causes serious accessibility issues:

Sure, part of this is RIM’s doing, but these are real constraints that we need to be aware of

Sure, part of this is RIM’s doing, but these are real constraints that we need to be aware of

One of the biggest challenges of creating responsive web designs is the balancing act of delivering a full experience while still maintaining a snappy user experience across the board. Cut away the cruft, follow performance best practices, don’t assume a strong connection by default, and look for ways to exploit great techniques like conditional loading to keep initial page sizes down.

3. Ignoring contextual conventions

A phone is not a tablet is not a laptop is not a desktop is not a TV.

Each device provides its own unique form factor, interface conventions, constraints and opportunities. We need to be considerate of all these variables in order to create experiences that feel natural to the user. Now I’m not recommending recreating every platform’s native UI in the browser, but we do need to be mindful of how people hold their devices, what icons they’re used to seeing, and so on and so forth. A good responsive experience reaches outside of the sandbox that is the browser and is sympathetic to the user and the device context.

Responsive web design by definition is not mobile design, so it’s up to us to introduce contextually-considerate elements to our designs. That means handling responsive navigation in a way that makes sense to visitors across contexts. That means designing for touch. That means avoiding forcing mobile users to sift through ridiculously long amounts of disparate content just to find what they’re looking for.

Let’s account for the many differences across these devices, understand that some compromise is inevitable, but put forth a solid effort to be more considerate of context.

4. Serving a one-size-fits-all experience

Mobile is much more than just various small screens, and these emerging contexts unlock entirely new use cases, patterns and possibilities. We shouldn’t sell ourselves short by only creating responsive layouts. For example, we sometimes forget that mobile phones can get user location,initiate phone calls, and much more. Hopefully soon browsers on all these gadgets will have access to even more device APIs, further pushing the boundaries of what’s possible on the web.

We should all we can to make the entire experience respond to what the device is capable of. Addressing constraints first gives us a solid foundation to stand on, then we can utilise progressive enhancement and feature detection to take the experience to the next level.

5. Relying on device dimensions

320px. 480px. 768px. 1024px. The fold. Oh God, the fold.

The fact of the matter is that we don’t control what our visitors’ browser sizes are, nor what dimensions manufacturers decide to make their devices. Believe me, they’re trying every size in the book.

Devices of all shapes and sizes

Why you should never rely on device dimensions

In addition, page height has always been even more of a moving target because of bookmarks bar, browser chrome and the Ask Jeeves toolbar. But now in the mobile web world, a web experience is often not seen through the lens of the browser at all. We visit links through Facebook, Twitter and other apps, each of which has its own custom chrome for containing web views. Of course hierarchy of content still matters and you want to get to the guts of the page as soon as possible, but you can’t get all worked up over the available pixel height, learn to let go.

In his article Fanfare for the Common Breakpoint, Jeremy Keith eloquently states that “it’s not about what happens at the breakpoints, it’s about what happens between the breakpoints.” That means our designs should hold together irrespective of any particular dimension.

Let the design itself sort out where breakpoints should occur. I absolutely lovethis advice from Stephen Hay:

“Start with the small screen first, then expand until it looks like shit. Time to insert a breakpoint!

By letting the content itself determine the breakpoints of our responsive designs, we’re preparing our designs to look great in not just today’s landscape, but tomorrow’s as well.

Do the evolution

We’re at the tip of the iceberg as far as creating adaptive experiences go. While these pitfalls (and many more not covered in this article) exist, they are no reason to shy away from creating adaptive experiences. With more connected devices of all shapes and sizes come onto the scene every day, we as web creators have an opportunity to be there when they arrive. While it’s admittedly a bit daunting, we should accept the challenge and embrace the opportunity to reach people wherever they may be.


Why We Need Responsive Images

The topic of responsive images has been one of the most hotly debated topics amongst web developers for what feels like forever. I think Jason Grigsby was perhaps the first to publicly point out that simply setting a percentage width on images was not enough, you needed to resize these images as well. He showed that if you served appropriately sized images on the original responsive demo site, you could shave 78% off the weight of those images (about 162kB) on small screens.

The discussion has evolved since then with debates over what sort of solution we need (server-side, client-side), new markup (srcset vs picture) and even, in some cases, wondering whether we really needed to worry about it at all.

It’s a messy issue for sure. The current solutions for responsive images do come with some complexity and overhead. If you’re using a client-side solution and don’t want to make more than one request per image, then you end up breaking the preloader. As Steve Souders explained rather well, this can have a very negative impact on the time it takes for those images to actually start appearing to your visitors.

No doubt there are trade-offs. Complexity of solutions, preloader versus file size—these each have to be considered when making the determination of what solution to use. Eventually we’ll have a native solution which will take care of the preloader issue, but browsers sure seem to be dragging their feet on that.

In the meantime, I was curious just how much page weight could be saved with a responsive image solution in place. I know that on the projects I’ve worked on, the savings has often been huge, but I wanted to see how consistent my experience is with the web as a whole.

Experiment time!

Yoav Weiss created a bash script called Sizer-Soze that, with the help of ImageMagick and PhantomJS, determines just how much you could save in file size by serving optimized and resized images. The script is built for one url at a time, so I modified it slightly to let me loop through a list of 471 URLs (the same list used by Guy Podjarny for his analysis of responsive performance). My bash scripting skills are minimal (read: nearly non-existent), but thankfully Yoav is far more skilled there than I and was happy to help out and make the whole thing run much more efficiently.

The script looped through the 471 urls, spitting out the results into a CSV. Each site was tested at widths of 360px, 760px and 1260px. Numbers were collected for total original image size, size of images if they weren’t resized but were optimized, and size of images if they were both optimized and resized to match the size they actually displayed at (so if a 1200px image was displayed at 280px wide, the script resized the image to 280px and compared the two file sizes).

If Sizer-Soze came across an image set to “display:none” it would re-check the dimensions every 500 milliseconds (for a maximum wait of 25 seconds) to see if things had changed. This was done to account for image-based carousels where images may have been hidden initially but then later revealed. If the image became visible during that time, then the dimensions were used to process the file savings normally. If the image was never displayed, the entire weight of the image was counted as wasted.

Even with that tweak, there are few caveats about Sizer-Soze:

  • It does not make a distinction between 3rd party images and images served by the site itself. So some of the weight can be attributed to things like ads.
  • It does not analyze background images. That’s fine because that’s not what we want here anyway, but its worth noting that potentially even more bytes could be saved.
  • It won’t be able to pickup some clever lazy-loading techniques, so again, its possible that some sites would actually be able to save even more than the reported numbers.
  • It doesn’t include data-uri images in the totals as the file name exceeds the length limit for the script.

After looping through, the list shortened to 402 different responsive sites. Some of the original 471 moved to new URLs or apparently went AWOL so Sizer-Soze couldn’t follow along. Others had no images in the source code—either as a result of some sort of lazy-loading mechanism or by design. Still, 402 sites is a pretty good base to look at.

Results: Total Savings

On to the results! First up, the totals.

Viewport SizeSum of Original SizesSum of Optimized SavingsSum of Resized Savings360237.66MB12.86MB171.62MB760244.39MB13.30MB129.34MB1260250.08MB13.70MB104.31MB

It’s not too surprising to see that the original size (what’s being served now) is pretty consistent from screen size to screen size. Guy’s research, and many others, have already demonstrated this pretty well.

What is staggering is just how massive the savings could be if these sites served appropriately sized images. At 360px wide, these 402 sites combine to serve 171.62MB of unnecessary weight to their visitors . That’s a whopping 72.2% of image weight that could be ditched by using a responsive image technique.

It’s not just small screens that would benefit. For 760px and 1260px sized screens, 52.9% and 41.7% of image weight is unnecessary.

Results: Average Savings

Let’s look at the savings in terms of per-site averages.

Viewport SizeAvg. Original SizeAvg. Optimized SavingsAvg. Resized Savings360603.89kB32.68kB436.08kB760622.53kB33.88kB329.47kB1260635.43kB34.81kB265.06kB

Looking at it from the perspective of an individual site, the numbers feel even more impactful. For each screen size, sites on average would shed about 5% of the weight of their images (from 32-34kb) by simply doing some lossless optimization. Considering that this could be automated easily into a build process, or manually done with tools like ImageOptim with little effort—that’s an easy 5% improvement.

Unsurprisingly, the gains are much more significant if those images get resized to an appropriate size as well. At 360px, the average site would drop 436.08kb. Consider that for a second. One optimization (resizing images) dropping that large of a chunk of weight. That takes image weight for a page from 603.89kB to a mere 167.81kB. That’s a huge difference that shouldn’t be dismissed.

While the improvements are slightly smaller for larger screen sizes (as you would expect), using some sort of responsive image technique would still save 320kB for sites displayed at 760px and 265kB for sites displayed at 1260px.


We spend a lot of time talking about responsive images online—debating the approaches, trying out new solutions. Sometimes it can be a little discouraging that we still haven’t gotten it ironed out (I know I feel that way frequently).

But the web needs us to be diligent. It needs us to not settle for seemingly simple solutions that sacrifice performance. It is extremely rare where one optimization lets us knock off such a significant amount of page weight, but here we are staring one such technique right in the face.

72% less image weight.

That’s why we need a responsive image solution.


Mobile first: Luke Wroblewski interview

The Mobile First philosophy has radically changed how professionals approach Web design and become the way companies as diverse as Facebook and IBM build their products.

The Mobile First approach is to start designing for mobile devices — which typically have less screen size and less capabilities than desktops — and progressively enhance the product; so that desktops get an enhanced site experience rather than mobiles getting a pared down one.

We grabbed the opportunity to interview Luke Wroblewski, who first defined the Mobile First concept back in 2009, about how he used the principle to create Polar at his latest startup, Input Factory Inc. where he is co-founder and CEO.

How did you get started building apps and what kept you fascinated?

The first mobile apps I worked on were during my time at Yahoo! I joined the Yahoo! Search team back in 2005 and a bit later was heading up a small “tiger team” focused on ideas for products that were 3 to 5 years out. At that time I was fascinated with where the web was going and in particular with mobile.

We started out building some experiences for newer Nokia devices, as Nokia was the big player back then. Soon after though, Apple announced the app store for iOS and we jumped into iOS applications as well. At the time we were experimenting with services that connected mobile apps to networked TVs and more traditional computers like laptops and desktops. It was a really great opportunity to explore what was coming and we came up with a bunch of concepts that I’m still passionate about today.

I think that’s what keeps me interested in this space. You can see the future: more connected devices of every shape and size; interactions between those devices; more real time access to useful information, services, and people –it’s all coming. But these things don’t just appear out of thin air. They take years of effort, trial and error to make real. So I keep at it because I keep seeing a more and more exciting future ahead.

When developing a product, how do you identify a gap in such a saturated market?

I don’t. If a market is saturated I think that’s a great sign it’s interesting on a number of levels. For me, its much more important to focus on problems I can understand and actually do something about. When you have deep experience in an area, you can often see a future other people can’t.

For instance, I’ve dug really deep into web form and mobile design. I even wrote two popular books on these topics. So I feel like I’ve increased my ability to see problems in these areas. And when I look across the Internet I see lots of people eager to share their opinions and get the opinions of others. But the solutions out there are just really bad.

You’ve got surveys that basically consist of multiple pages of form elements: checkboxes, radio buttons, text fields, and so on. Because they’re so painful to complete, companies are paying people to take these surveys and even then the participation rates are really low. I look at this and think: we can do better.

It doesn’t really matter if there are a lot of companies out there with apps for making surveys or soliciting feedback. If you see a problem and think you can do a better job solving it, that’s the on-ramp. That may sound overly confident but I think you need confidence to get out there and start doing your own thing. You have to believe in it or no one else will.

Why is the Mobile First approach a better way to do things?

Well the reasons have been stacking up over the years. But when I outlined the idea originally I pointed to three main reasons: growth, focus, and innovation.

Growth is pretty obvious these days. More than 2 million modern mobile devices enter the world each day. Compare that to the 371,000 children born per day and you can quickly see how these numbers add up. All these devices connected to networks is a huge opportunity and many companies are now feeling it in their stats as mobile begins to take over other kinds of devices in usage.

Focus comes from the natural constraints of mobile. These devices need to be portable, so their screens are small, they connect to networks anywhere and everywhere with varying success, and they get used in very diverse environments often full of distractions. These constraints push you toward more focused, simplified solutions. You can only fit so much on the screen, people often have to wait for it, and they’re unlikely to give you their full attention. So make it easy to understand and use and focus on the important things first. Mobile is a great forcing function for simplicity.

But mobile isn’t just about constraining yourself; quite the opposite. There are lots of things that make mobile experiences more powerful and engaging. Not least of which is the fact that mobile devices can be used all the time and just abut anywhere. That not only creates new uses but also means people can be connected throughout the entire day.

If that weren’t enough, due to the capabilities of mobile devices, we have new ways of creating experiences. Thanks to local detection technology, we know where people are down to 10 meters. Thanks to integrated cameras and microphones we can take in visual and audio input, process it, change it, and share it. Thanks to motion sensors we can tell where a device is in three-dimensional space, and the list goes on.

It’s easy to dismiss these capabilities as technology for technology’s sake. Instead think of them as new techniques or paints on your design palette. With them, you can paint a totally unique user experience that allows you to innovate and move beyond existing solutions that came about before these technologies were available to us.

How do you know your design is hitting the mark, especially when aiming for speed and simplicity?

Well, you can test for both. In fact, that’s exactly what we did for our app, Polar. We designed Polar for mobile first and foremost so speed and simplicity were, of course, top of my mind. Earlier I mentioned that we thought we could make collecting and sharing opinions fast, easy, and fun, almost the exact opposite of what most survey tools are like online today.

Polar is our first attempt to do that. The most important interactions in Polar are collecting and sharing opinions and, as a result, we spent a lot of time trying to get those interactions right. To make sure they were fast and easy, we used one-handed, timed tests. Our goal was to allow anyone to vote on 10 polls or create a new poll in under 60 seconds.

If you design for the extremes, the middle usually works itself out. To quote Dan Formosa at Smart Design: When they designed garden shears, they tested them with people who had arthritis. If this “extreme” case could use the garden shears, then anyone could. That’s the same approach we take with timed, one-thumb use. If you can make it work for that extreme it will work for everyone.

Is there anything you can do from a design perspective to make sure that people who download the app actually use it?

Sure. Let them actually use it. In all seriousness, so many apps start off the process by wanting to tell you all about themselves and having you tell them all about you. Fill in this form, give us your phone number, take this intro tour, and so on. All this instead of just letting you get in and start using the app you’re spending all your time memorizing which gestures the app has and connecting to Facebook.

No actually, you’re skipping past all that trying to actually use the app. So my approach is just get to the good stuff. Let me say, however, that I know this approach is controversial. There are a number of examples out there that show forcing registration up front increases your sign-up numbers. Which means you increased the number of people who filled out a form. But they’ve never used your service. They might not even know what it is, so how valuable are these users?

I’m biased toward people who’ve seen and used the app, then decided to sign-up as a result. That means they liked what they saw enough to take the next step. The total number of sign-ups may be lower but the number of qualified users may end up being higher. At least that’s our approach!

Have you heard horror stories of people screwing up their signup process in their products?

The best one I saw recently was published by Greg Nudleman. It was an app for finding nearby restrooms made by Charmin. The intro process was so labor intensive that Greg very appropriately titled his write up: Let Them Pee!

You’ve use the term “gradual engagement” a lot in the past when you talk about sign up process, can you elaborate on what that is?

Sure. Gradual engagement is an alternative to the sign-up form issue I just described. Through gradual engagement, we can communicate what apps do and why people should care by allowing them to actually interact with them in gradual ways.

For example, Polar is all about sharing and collecting opinions. So we allow anyone opening the app for the first time to vote on the polls they see. 88% of people who download the app do just that. We hold on to all their votes locally so if they ever take the next step on the “walkway” (when you want to leave a comment or create a poll of your own), all your votes carry over to your account. This is what I mean by gradually getting people to understand and use your service. It’s about creating a clear and welcome “pathway” vs. putting up walls.

There has been much debate recently over whether improved device capabilities will render mobile-first obsolete, where do you stand on this?

I certainly hope all our devices keep getting better and that we develop new ways of interacting with information and with each other. So I’m not building a moat around mobile or anything. That said, the idea of having a connected device with you anywhere and everything is really powerful.

For proof, just look at Flurry’s recent analysis of user sessions and activity across all phone and tablet sizes. The clear winner for both was the “medium” sized (3.5”-5”) phone. I think this is a testament to the value of a portable computer that you can turn to at any moment for answers, conversations, and frankly just about anything. That kind of mobility and its importance does not show any signs of letting up in the near future. So I’m still really bullish on mobile.

We’d like to thank Luke for taking the time to answer these questions.

Do you take a Mobile First approach? What stops you from using an app or mobile site? Let us know in the comments.

Featured image/thumbnail, mobile internet image via Shutterstock.


Mobile: Never Use Native Drop-Downs for Navigation

Many responsive mobile sites are using native drop-downs (as in: a select tag) for main navigation and many plugins have beendeveloped for this specific purpose, yet our usability research shows that this is a poor strategy. On the tested m-commerce sites that used native drop-downs for navigation, the test subjects showed decreased control and overview of the menu items.

During testing, nearly all subjects scrolled up and down category lists before selecting an option, many explicitly stating that they wanted to see all the categories before selecting one – even if they felt they had spotted a good match early in the list, the subjects still scrolled the remaining items just to make sure they knew what their other options were (before then scrolling back and selecting the good match). The subjects exhibited the same behavior on homepages where they often scrolled up and down to get an idea of what their options were, even if they saw what they were looking for right away.

This strong tendency towards scanning all options before selecting one is at the core of why native drop-downs are a poor choice for navigation. When open, a native drop-down only utilize ~50% of the screen, which made it needlessly difficult for the subjects to get an overview of their options.

selectNav.js is a plugin that turns custom navigation items into a native drop-down.

With only half of the screen used to display the available options, users will have a difficult time scanning and comparing the available options. To make matters worse, the drop-down often starts out at the top with only 3 options visible to the user (left image), and even when scrolled to align optimally, no more than 5 options can be seen at once (right image).

Another issue with the navigation options only taking up 50% of the screen is that the scroll area for those options is similarly small. The smaller scroll area resulted in less accurate scrolling as there was so little room to “drag” the content that many subjects flicked to scroll instead (which of course is a much more inaccurate way of scrolling).

Finally, we also observed a few instances where subjectsmistook the navigation for filtering options. This was especially true of category and search result pages where subjects were on the lookout for filtering options and then simply jumped to the conclusion that the drop-down was such a feature.

Solution: Custom UI Drop-Downs

It’s very important to underscore that drop-down navigation isn’t bad at all, it’s native drop-downs (as in: a select tag) which are unsuitable for navigation due to the way they have been implemented in the major smartphone operating systems (such as iOS and Android).

The Boston Globe expands the navigation items inline, which makes it easier for the user to compare and scroll them.

While the navigation at The Boston Globe is very similar to how the native drop-down works in terms of interaction (you first click “Sections” and then a set of simple items are revealed) it is significantly better because the options aren’t limited to a dialog but can take up the entire screen if necessary. In the above all 10 items are shown at once; quite the improvement in terms of overview, scannability and “scroll control” when compared to the meager 5 items that can be shown in a native drop-down dialog. (The navigation items on Boston Globe are, however, on the short end, being only ~5,3mm tall.)

CSS-Tricks is a great example of how custom drop-downs allows you to tailor the design of the options to your site.

Another benefit of implementing custom drop-down UIs for navigation is that you have complete control over the design of the options. This means you can optimize the design and layout of the shown options (which you can’t with a native drop-down).CSS-Tricks, shown above, is a great example of this where, when expanded, the menu items are displayed in two columns and each has a descriptive icon next to it. It can also be more subtle, like the earlier Boston Globe example where arrows have been added to indicate virtual space.

During testing the subjects had no issues using these types of custom UI navigation as long as they followed basic design conventions, had adequate hitarea sizes (device manufacturers recommend a minimum of ~7×7mm), and the trigger elementwas designed as a link / button (so that the subjects knew it was clickable).

It should be noted that native drop-downs are not poor for all purposes – they can work well in forms where keeping page context can be as important as the options themselves. However, native drop-downs should not be used for main navigation as they simply afford too little overview of the available options and are needlessly difficult for users to scroll accurately.


Responsive Web Design Summit talk, 'Measuring Web Performance'

On Tuesday, April 16, 2013, I was lucky enough to give the opening talk on the web performance day of RWD Summit presented by Environments for Humans. This is the short description for the talk:

Today, a web page can be delivered to desktop computers, televisions, or handheld devices like tablets or phones. While a technique like responsive design helps ensure that our web sites look good across that spectrum of devices we may forget that we need to make sure that our web sites also perform well across that same spectrum. More and more of our users are shifting their Internet usage to these more varied platforms and connection speeds with some moving entirely to mobile Internet.

In this session we’ll look at the tools that can help you understand, measure and improve the web performance of your web sites and applications. The talk will also discuss how new server-side techniques might help us optimize our front-end performance. Finally, since the best way to test is to have devices in your hand, we’ll discuss some tips for getting your hands on them cheaply.

This presentation builds upon Dave’s “Optimization for Mobile” chapter in Smashing Magazine’s ”The Mobile Book.”

Article: Source

Designing a responsive, Retina-friendly site

It’s hard to believe I have been blogging for more than 7 years. Michael Wozniak, my hallmate during my freshman year at Georgia Tech, had gotten me into Gentoo Linux the year prior and told me he was playing with WordPress 1.2. Compared to the MediaWiki site I was running at the time that piqued my curiosity and I began blogging on WordPress on my G4 Mac Mini that summer. I immediately fell in love with it and began learning CSS and PHP to tweak the theme1.

Eventually I found my thing – writing technical guides, product reviews and tech editorials. I still remember the feeling when I noticed one of my articles got picked up by Lifehacker. Then digg. Then 5 other sites. 20,000 uniques in 4 hours. I wrote a follow up to that article. Same thing. And another follow up. I received enough traffic that month in 2005 to kill the hard drive in my dorm-hosted Mac.

Unfortunately, I haven’t blogged as much in recent past; my waking hours spent worrying about startup issues than crafting new content. Things I would have blogged about in the past are now published as tweets.

When the time arises, I thoroughly enjoy writing long-form articles and with that in mind I wanted to design a better experience for consuming them.

Note: This article got rather long (15,000 words), so I split it up into a few posts. This one is about design. Developing a responsive, Retina-friendly site (Part 1) covers responsive development while the third part will cover responsive images.


My last redesign in 2010 was not built with mobile in mind. It was more of a lets-get-this-new-Jekyll-thing-working project than a planned website overhaul. Visiting on an iPhone meant the typical double-tap-to-zoom fiasco.

Having seen my traffic breakdown go from 3% iPhone and 2% iPad in 2011 to7% iPhone and 4% iPad in 2012 I knew it was time to focus on the mobile experience throw mobile visitors a proverbial bone. iPad visitors in particular spent more time on site than desktop or iPhone visitors. Approximately 132,000 people read this site on a mobile device in 2012. Damn.

Responsive devicesThe new responsive & retina-friendly

These numbers are only going to grow. It helps that proliferation of LTE networks and devices means the fastest Internet connection people have will likely be on their smartphone, not their home connection. That’s crazy.

Picture Perfect

Many of my posts and reviews are filled with my own photos. My blog actually got me into photography. I first purchased a DSLR to take better pictures for articles and product reviews. In the last 3 years I have fallen in love photography. But most of my shots were getting published on Instagram. It made me feel a bit bad that I don’t often share many of my photos on my blog.

Paul Stamatiou Instagram

Some of my Instagrams

I was in that exact mindset when I was flying back from New York after hanging out with the Rap Genius guys. They don’t have an office, instead they have a few baller (to use their vernacular) penthouses in Brooklyn. I took this panorama on their deck with my iPhone which I then post-processed with Snapseed.

Rapgenius HQ Brooklyn, New York

Click see my new photo page

I liked this photo so much that I was vexed I couldn’t share it with my Instagram followers. I began pondering about a clean way of sharing it on my blog.

The Retina Revolution

If I was going to touch my site, it would need to be Retina friendly. I’ll be referring to Retina as the device agnostic term HiDPI from here on out. What does that mean? Every icon, background or image used should look crisp on HiDPI displays. The most pressing area for that is on mobile devices as there aren’t yet that many HiDPI desktops and laptops out. As much as people love the Retina MacBook Pros, that’s not even a single percentage of anyone’s web traffic yet.

Don’t expect to have a HiDPI 27-inch display just yet. The first 4K (3,840 x 2,160) big displays are shipping and they are expensive.. around $5,500. But in 2-3 years? That’ll be another story entirely; HiDPI displays will be standard on most high-end desktops2.

If responsive web design was the fad of the web design/development community for the last few years, the next one is going to be HiDPI support. With HTTP 2.0 (with SPDY forming the starting point) slated to drop in 20143it will be perfect timing to combat the larger filesizes needed for HiDPI image assets. As I’ll discuss in the second part of this post, there are some development challenges associated with this.


Photoshopping desk

Late night Photoshopping & trance. Very similar to The Coding Zone.

I wanted to completely rethink my site, not just a add new coat of candy paint. I planned to rewrite copy on all static pages, reorganize content as necessary and generally simplify things. This would also give me a good excuse to start using more semantic HTML5 tags.

My design process was a little different from how I mentioned it in my ridiculously popular Crash Course: Design for Startups. I usually start with some inspiration-wrangling, a few ideas about direction and lots of sketching before any Photoshop or code. I couldn’t exactly whip out a big sketch pad in lovely last-minute seat 37b so I worked in Photoshop for most of my 6 hour flight back to SF (until they started playing How I Met Your Mother).

If you need to use something like Readability or Safari Reader to read my articles, I’ve failed as a designer.

I began thinking single column. The content should be the star of the show. No sidebars or extraneous post metadata that gets in the way of reading. If you need to use something like Readability or Safari Reader to read my articles, I’ve failed as a designer. And lets not forget the impetus behind this rethinking; I wanted to be able topublish large photos – within posts that extend beyond the narrow copy and also on individual photo pages.Bandwidth and latency be damned, I want to show dozens of 1000px+ wide photos at a time.

Planning Mobile First RWD

The premise behind Mobile First Responsive Web Design4 is that you should trim your site to only the essentials, establish the priority or question the necessity of all elements and focus on mobile before adding complexity for larger/desktop versions of the site. This is going to sound ridicu-cheesy, but this is a way of thinking and it applies to every aspect of your site planning. Even down to writing mobile first CSS to keep things lightweight and simple and conditionally load extra stylesheets and content for larger devices (that are also likely to have faster connections) as necessary.

Categorizing your site into pieces and setting priority before even pondering aesthetics stems from Dan Brown’s page description diagrams back in the early 2000s.

The page description diagram, by demonstrating priorities and providing a context for the content and functionality, gives visual designers the information they need to create an effective layout.

It’s a great little exercise when embarking on a redesign. Given that this site only has a few pages and then blog posts, it wasn’t really needed. For the sake of teaching, I’ll elaborate a bit. You generally start with three columns from high to low priority page elements. You list out each element and you can optionally provide a description of it and a simple wireframe of that element.

HighMediumLowArchives/PostsRSS/SubscribeContactPhotos”Bits” (asides) postsSearchAboutComments”Stuff I Use” page@StammyFB/Twitter sharePost metadata, date

Some of this organization was by personal preference and some was metrics-driven. Take the post date for example. I have some articles dating back 7 years and I don’t want to advertise that the content may be outdated5, so I place less importance on that and display the publish date after the post. For the most part my articles are evergreen and more of my content is becoming less product reviews and more editorial.

I’ve also found that time on site increases when users don’t see the post date immediately. The majority of my visitors come from Google SERPs and they’ll leave without reading if the first thing they see is that the content is more than a year or two old. Increasing time on site also tends to decrease bounce rate for these Googlers. After reading the post they are likely to open up a few other articles I link to or just browse around for another pageview. It’s important that I do whatever I can to capture that first time visitor.

If someone won’t share a post because I don’t have a Twitter button in 10 places on the page, then I’m writing pretty crappy content.

An example of priority based on personal preference is my decision to place low importance on Facebook and Twitter sharing functionality. I like to believe that if the content is good enough, people will share it on their own accord. I also didn’t want to load Facebook and Twitter javascript. This gives me a mental test before this content really good enough to publish?

I could simplified things more by merging my "bits" (smaller posts) into the main posts section. Bits had their own RSS feed and index page. It was another navigation element; another forced decision upon visitors to visit another page. Bits now appear styled differently inline with the rest of the posts.

But I messed up. When I first did this page description diagram I prioritizedsearch functionality as high. My first header designs as I’ll show below had a huge search bar next to the main navigation as if it was one of the most important elements on the site. I looked into my Google CSE analytics ‐ search was rarely used; less than 10 queries a day on average. Only 8,500 on-site searches in the last 3 years. I since relegated search to low priority on this diagram.

Where to begin with visual design?

After that basic IA and planning was out of the way, I had a good idea of what to include in the header. I was going to distill it down to the essentials. There would be such little difference between the mobile version and larger responsive versions that I wouldn’t really need to plan the responsive designs. The focus is on the content at all times, not just on mobile, so there’s no need for me to do any content choreography and adjust layouts between responsive designs. No sidebars to hide or move, et cetera.

Some designers start with a blank slate of copy and begin with typography and layout, while others begin with the site header and navigation. I began with the header. I tend to start my designs on an extreme with the intention of toning it down later as necessary. As a tiny example of that, I made the avatar and header text much larger than I was comfortable with. If you only ever design within your comfort zone, you won’t come across unexpected ideas that you may end up loving. That’s how the folks at Lamborghini design 2 too — starting with the most absurd and extreme lines that come to mind.

Lamborghini Aventador LP 700-4I’ve ridden in a Ferrari 458 and thought that was insane. The Aventador hits 60 quicker, in just 2.8s.

I previously had a terse Twitter-like bio on the top of my homepage and decided to further reduce that into a subtitle. As for having my avatar there, I wanted to put a face to the content, much like people have become accustomed to seeing a face next to every tweet.

Below you can see some early versions of the header that I was left with by the time the flight was ready to land. The one on the left was the first stab. It felt like there were too many menu items and the search just didn’t line up. The middle version was my attempt to distill navigation into the most important elements, posts and photos. I wasn’t happy with the visual hierarchy there either and it made search look too important. In the third iteration I began playing with icons to minimize space used by navigation. I was trying to line it up under the avatar, but I had too many menu items and it just looked weird.

PaulStamatiou blog header and navigation iterationsSome early iterations of the blog header and navigation.

Around this point that I dug into my metrics to find out that search wasn’t used much. I initially opted for icon-only navigation with tipsy-style tooltips, but felt it violated Rams’ “as little design as possible” principle, in addition to being cumbersome (having to hover over each icon first to see what they meant).

Some hours of tinkering later I ended up with my current design with only three main navigation elements. In between Photoshop iterations, I would constantly sketch UI on paper to refine my ideas. Just drawing any tangentially-related solution that came to mind helps organize my thoughts.

Design sketching

All I need is a simple sketchbook and a Micron 01 pen to sketch out concepts.

Keeping track of iterations

I’ve made it a habit over the past year to constantly take screenshots of my designs in progress. Either of Photoshop work or in-browser tweaks with Chrome dev tools. Over the course of this blog design I ended up with 67 screenshots. It’s nice to be able to go back and trace your thought process over again. Danny Hertz from Twitter had an interesting idea about how toautomate this with Selenium, but I digress.

I’ve started using LayerVault to help me with this. It’s like GitHub for PSDs and you can visually flip through your PSD revisions.

Paul Stamatiou blog - LayerVaultLayerVault showing a revision. I keep my palette in big blocks on the top of the PSD for easy picking.

The Sandboxed Cover Photo

Going along with my wanton lust for big photos, I also designed a second header to be displayed for particular posts and pages that have a cover photo defined in Jekyll’s YAML front matter. I built it (and incorporated some slick parallax scrolling) but decided not to use it. I’m not quite sold on it yet. Back to the sketch pad.

Cover photo headerExample of a page with a cover photo. Still a work in progress.

I’ve got the blues

At this point, the design was coming together and needed to focus on typography, make a simple footer and some button styles.I created a muted blue shade button style to use throughout the site. after content linksArticle publish date, share UI and related links

As we all know you should never use black so I chose a fairly muted color palette of desaturated blue shades. For one, blue is awesome and two cooler colors recede and since the content is the centerpiece here I want it to stand out. My main copy is a subtle warm gray, as warmer colors come to the foreground.

Not all displays are alike

I wanted to get some feedback on a PSD so I showed it to my friend Anand on my MacBook Air. I quickly realized that I could barely see parts of the design! The colors were way too light. I had been designing the whole time on a 27-inch Apple display and a 24-inch Dell display that made them seem like they had adequate contrast. Not so on any Apple laptop I tested it with.

Enter WCAG 2.0. Yes, another W3C acronym! The Web Content AccessibilityGuidelines cover various aspects of website accessibility, including contrast minimums. There is actually a rating system for contrast! It takes text size, color and background color into account to come up with an AA or AAA level.

No need to worry, Lea Verou came up with a handy tool called contrast ratio. Punch in your color and background color to see if it has adequate contrast. But if you have to ask yourself if there’s enough contrast, there probably isn’t. I still need to darken the color of my footer links, they’re a bit light.

Serifs.. on the web?!?

I decided to go with the lovely serif Adelle for article headings and text. It’s the first time I’ve really used a serif on the web.

Blog design typographyTrying to decide between 6 different Typekit typefaces. Chrome extension: WhatFont

I’ve grown up being told that you shouldn’t use serif typefaces on the web—the serifs themselves6 on certain curvy typefaces don’t lend well to being displayed with a grid of pixels unless the particular font has been properlyhinted (unlikely). Well, my official stance is this all matters less when you’re dealing with HiDPI displays so I’m going for it.

If you want good type on Retina displays, stop discussing hinting et al. Just search for faces that happen to look good. Like the old days.

You can learn more about web typography with this interactive guide or The Elements of Typographic Style Applied to the Web.

Photo Layout Ideation

Up until this point, the homepage mockup in Photoshop just had an article excerpt, a list of recent posts and then a few photos. I thought it would be interesting to show more information about the photos on hover.

Original image metadata hover designFirst idea was to display photo title and camera metadata on hover. (Aston)

Blog homepage v5 iterationAfter I was satiated with hover style, I quickly coded it up ghetto-style directly in Chrome dev tools to see how the interaction felt. I’m glad I made a prototype first because I quickly realized that hovering over each photo and then displaying a full-width overlay was jarring and abrupt to the user.

It could also be inadvertantly triggered while scrolling down the page and it was unexpected. It taking up too much space and you couldn’t see the photo while reading the title. Not to mention how would I make this mobile web friendly? I wanted to have it always display on mobile but that wouldn’t work if it hid the image.

Then I thought about having it only appear on the bottom section of the image on hover.

Design: Image hover metadataSecond iteration for photo hover metadata

That almost worked but then there was the case of longer photo titles wrapping and looking unpleasant. I decided to forget the image hover stuff and instead vertically stack the photo metadata and put it below the image in its own photo layout. Again, I quickly marked it up to see what the experience was like in the browser. It worked, but I had another problem now.

Having the same large site header and navigation took too much attention away from the photo itself.

Photo layouts 3upA few photo layout iterations.

kept removing and de-emphasizing elements until it was clear the focus was on the photo. This brings up a tradeoff with usability though. This breaks the user’s expectation of a consistent and familiar header navigation that they are familiar with on all other pages of this blog. I decided that was an acceptable tradeoff when the user is moving into a photo viewing mode. I added left/right arrows that display on the image on hover, and bind the left/right cursor keys so visitors can browse other photos easily. Since photo pages are not long, there was a simplified footer with all the necessary navigation to get back to the homepage.


It was a bit challenging for me to explain how I approached the design of this blog. It’s one thing to explain the finished product but it’s another to explain all the iterations in between and how you got from one to the next. It’s a lot of fiddling, having a few rules of thumb and constantly questioning yourselfabout those designs.

Subtletly, something I also mentioned in my design crash course, is one of those rules of thumb for me. I very, very often find myself thinking “can I make that lighter?”, “can I remove this line?” and so on.

If there are any visual garnishings, such as a button block sheen or inner white glow on a menu bar background, that don’t serve a functional purpose (like grouping sets of elements together for Gestalt Law of Proximity), it can and likely should be de-emphasized by changing color, reducing opacity or removing it altogether.

I spent a few hours per day over the course of about a week and 19 PSDs coming up with this before doing any real coding aside from prototypes to test certain design decisions. The design of this blog is still a work in progressand I’m sure I’ll be changing things in the near future.

Share this post :) Part 2 coming soon

What’s your design process like? Have you worked on a mobile first or responsive site yet? Let me know in the comments below or shoot me a tweet.

Note: This post is part of a series documenting the design and development of this blog. The next part(s) covering development in great detail will be posted this coming week. Developing a responsive, Retina-friendly site (Part 1) covers responsive development while the third part covers HiDPI and responsive images: Developing a responsive, Retina-friendly site (Part 2).

1Several redesigns later I ended up making and releasing my own theme, 281, that ended up becoming an option on

2I remember paying more than $700 for my first 80GB SSD (and then another for RAID) in late 2008. Now they’re affordable and ubiquitious on any decent computer.

3HTTP/2.0 to be submitted to IESG for consideration as a Proposed Standard in November 2014.

4You can read more about Mobile First in Luke Wroblewski’s excellent book.

5I know this is a controversial issue. Some people despise sites that don’t list publish date adjacent to the title. But as a site owner, it benefits me to put it after the post.

6By my use of “serif” here I don’t mean the typeface but the small lines shooting off the edges of letters.

Article: Source

Responsive Deliverables

In a world of growing front-end complexity, what are we handing off to clients?

During the era of Print Design, companies would approach agencies for a brand identity system. Don Draper would then hire one of two people: either Paul Rand or Saul Bass. Paul Rand’s work with Westinghouse makes a great case study for building a design system.


The identity work started with a simple logo and color scheme and then scaled to business cards, product packaging, vehicles and more. The sum of these components made up the physical brand.

Building webpages is not so different. The old PSD-to-HTML workflow served us well for many years, but isn’t able to stand in the face of all the complexity that responsive web design and the multi-device web have introduced. Internal processes have already begun to change. Likewise, how we craft webpages and what we deliver to our clients must mature.

Modules, not pages

The traditional way to handle complexity in programming is to break large complex things into smaller well-formed “modules”. Focusing on creating healthy front-end modules1 instead of complete pages can help break complex page layouts into reusable solutions. This proved to be true working on the homepage.

Screen capture of homepage broken into color-coded componentsLegendSearchNavigationHeroList of linksHighlight

From the exterior, it may appear to be a single page but the homepage is actually comprised of Lego®-like building blocks designed to be combined together. The look and feel of new components like form controls, navigation, and carousels are informed by the colors and typethat define the brand.

Good components make code reusable. Tyson Matanich, developer at Microsoft, was the main driver and lead enforcer to ensure that all components were reusable at their core, running each component though stress test scenarios. He coached us in how their components might be reused and continually pushed us to “componetize” even further.

The highlight component, for example, can be re-purposed and “themed” in the news section using a simple CSS class. While they are different visually, they possess the same underlying code structure. All these components are then strung together to create complete page layouts.

Working on isolated components made the iteration process faster as well. Faster and more reusable means that the work our agency performed resulted greater value for their company.

Modern day deliverables

What does a modern day Paul Rand need to do in order to bring a brand identity system to the web? Instead of delivering one PSD per page or worse, one PSD per responsive view, we should be thinking about deliverables as modular pieces of the larger system. Whether they’re based on strategy, components, or layout, they should all be built with extendibility in mind.

  • Components
    • Flexible grid
    • Typography
    • Navigation
    • Accessible form controls
    • Carousels
    • Tabbed navigation
    • Responsive tables
    • Accordions
    • Media lists
    • Dropdowns
    • Pagination
    • Data tables
    • Buttons
    • Icon fonts
  • Strategy
    • Responsive images
    • Responsive typography
    • Accessibility architecture
    • Legacy browser support
    • i18n/l10n tolerance
    • Performance budget
    • Interaction/Animations
    • Responsive advertising
  • Layouts
    • Homepage layout
    • Subpage layout
    • Article index layout
    • Article layout
    • Product index layout
    • Product detail layout
    • Sign up flow
    • Checkout flow

All billable items should be accompanied with demo-able code. If some of these deliverables seem familiar, they should…

Tiny Bootstraps, for Every Client

Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs. These living code samples are self-documenting style guides that extend to accommodate a client’s needs as well as the needs of the ever-evolving multi-device web.


Media Queries are a Hack

Article: Source

The big buzzwords in CSS these days are “modular” and “responsive”—and for good reasons. But we’re still trying to achieve those goals with the wrong tool: Media Queries. What we actually need is a tool that doesn’t exist yet: Element Queries.

This is without a doubt the biggest problem I run into while working on I want to write modular components that I can re-use all over our site, and even across sites—little pieces of CSS, HTML and Javascript that get packaged together once, and don’t need to be tweaked everytime they get used. But CSS as it currently stands won’t let me.

I want write-onceuse-anywhere—that’s what modular code is.

Media queries are not that. They’re write-everywhere. They’re relative to your screen, so every time you write a media query for max-width or min-width, you’re connecting the appearance of your module to the width of the entire canvas—exactly what you were trying to avoid.

Change the number of columns in your layout? Update all of your media queries… Change one of your breakpoint widths? Update all of your media queries…

That’s not maintainable.

Here’s a real-world example…

I was working on testimonials for our new pricing page last week, so the example is fresh in my mind. We went around and collected a bunch of nice things our users have said about us, and stored them in JSON files so we can put them up around the site.

Depending on where we show them, the width and height of their parent element will vary. On the Signup page they’re in a column down the right-hand side of the page:

On the Pricing page we put two testimonials side by side instead:

That’s the same .testimonial module in both places, but their context differs.

Now say I want to make them responsive. After a certain breakpoint where the testimonials gets squeezed too much, I want to shrink the avatar and font-size slightly and hide the company information.

The key here is that I’m not only talking about narrow screens. I’m also talking about narrow columns on large screens.

Doing this today, I have to resort to Media Queries, which immediately breaks my modularity. On the Pricing page, I need a breakpoint at around 34em. But on theSignup page, those same styles need to kick in at around 47em.

Now I’m stuck with the same pieces of code in two different page’s styles (or two unrelated pages styled in the same place). It’s not modular no matter how you slice it. And it gets worse! I want to add more testimonials to our Home page. And Ilyawants to add a “Happy Customers” page full of testimonials as well.

I’m going to end up with an unmanageable mess, when all I really needed was the ability to say, “when a .testimonial element gets too narrow, rearrange things a bit”. I should be able to do that regardless of the browser’s width, so that they’ll look good no matter where I use them.

We’ve been doing it wrong this whole time.

Writing modular code is about making small objects, and making them self-contained. Media queries don’t let you do that. In most cases, you don’t actually care about the width of the entire document (or screen), you care about the width of your element.

If a .testimonial element only has 500px of room on the page, I don’t care if the document is actually 2100px wide, I want the styles to reflect that 500 pixels that I have to work with. My styles shouldn’t be:

@media (max-width: 2100px) {
  .testimonial {
    font-size: 0.8em;

That’s the kind of hack we’ve been using just to get by. That’s not what we actually want to be doing. We want this:

.testimonial (max-width: 27em) {
  font-size: 0.8em;

That’s modular.

Brittle examples are all around you.

One of the reasons I think this need hasn’t been solved yet is because it’s easy tothink that media queries solve all of our problems at first.

One of the textbook media query examples is a super-simple blog. Problem is, a blog post’s width is highly-correlated to the window’s width, so it makes Media Queries seem like a better solution than it is. My testimonials aren’t highly-correlated to the windows width.

But even some of the more intricate examples are better-solved by Element Queries:

This early post about media queries by Chris Coyier is a perfect example of when Element Queries should be used instead. In his example, Chris adds icons to a list of links if he has enough room. But if that email template changes at all, those perfectly-tuned media queries will break. The list of emails should be styled relative to its ownwidth, not the entire email’s.

The same goes for lots of the examples in Brad Frost’s awesome repository of Responsive Patterns. The styles applied to this list and this grid will break if you decide you only want them to take up half of the screen, instead of the full width that media queries assume. When you’re styling this table you don’t really care about the browser’s width, you care about how much space your table has for columns.

Tim Brown’s Molten leading would also be solved by element queries. Instead of needing a truly fluid line-height property, you’d just have several breakpoints for your given element. Each individual element can control it’s own type; the larger the element in ems, the larger your line-height.

I’m not hating on these examples—these guys are awesome and have been influential in me ever understanding media queries in the first place. They’re working with what we’ve got, but we can improve our tools.

So… is this ever going to be possible?

A while back Paul Irish mentioned that “element queries” had been brought up before, but it’s been incredibly hard to find any real discussions about them. Luckily others seem to be coming around to the idea too.

Jonathan Neal recently wrote up his thoughts on what the syntax should look like, and has his own proof of concept. I’m not a big fan of using the media keyword, because it doesn’t make semantic sense once you’re no longer referring to the global canvas, but it’s a good start nonetheless.

I’m sure there are tons of problems to work out to make @element queries possible; I’m not a spec writer or implementor. But I really hope more people start rallying behind Element Queries and they get implemented because they’re really critical to our ability to write truly modular CSS.

Until then we’re stuck with hacky media query or Javascript solutions.

PS. For a little look into the kinds of problems that need to get dealt with, take a look at my testimonial example again. I’m changing the font-size on a font-size-relative breakpoint. Mindfuck.

Responsive Resources

Source: Article

1. Gridset

Developed first as an internal tool that has now grown into a full-fledged product, Gridset lets web designers and developers design, prototype and build custom, responsive grid-based layouts for their projects. It can create any type of grid you require, from regular columnar grids (such as those in CSS frameworks like Bootstrap or, to asymmetrical, compound, fixed, fluid and responsive grids. It even lets you create a library of your own grids, with a variety of presets available.

The beauty of Gridset is how fast it will allow you to build responsive prototypes (without all the calculations), providing all the measurements and tools to integrate with your existing markup. You can tailor specific grids across breakpoints you define, and create PNG files of your entire grid set, so you can view and work on your grids in the design tool of your choice.

Alternatives: FramelessTiny Fluid GridGridpakSimpleGridResponsify,Responsive.gsGolden Grid System and Photoshop Grid for Responsive Design.

2. Bootstrap

Built by two guys at Twitter as a way to provide a clean and uniform solution to the most common, everyday interface tasks they faced as developers, Bootstrap is a “sleek, intuitive, and powerful front-end framework for faster and easier web development.” It uses a 12-column responsive grid system, and features dozens of components, styles and JavaScript plugins, with basic global display, typography and link styles all set.

Using the Customizer, you can really make Bootstrap your own, and customize variables, components, JavaScript plugins and more. Bootstrap can be expanded, with a wealth of resources available, to include themes andinterface-building tools.

Alternatives: SkeletonFoundationBaseInuitCSSLESS Framework,Gridless320 and Up and Gumby.

3. Adaptive Images

Previously, making your website images responsive usually meant using a"hack-around,” such as rewriting the “src” attribute or using the “noscript” tag. But there are now several tools to make this a much simpler task, including Adaptive Images, which uses one htaccess file, one php file and a single line of JavaScript to detect your visitor’s screen size. It then automatically creates, caches and delivers device-appropriate rescaled versions of your embedded HTML images. What’s more, it is entirely non-destructive, and works on existing websites and markups — without the need to edit anything.

Adaptive Images works on the premise that you are already using the highest-resolution images on your site, and also offers a ton of customization options. You can set breakpoints to match your CSS, set the quality of the generated JPGs, set how long browsers should cache the image for and much more.

Alternatives: ReSRC.itjQuery PictureResponsiveImgRetina.js and Retina Images.

4. Responsive Design Testing

Building a responsive website means constantly testing how it displays across mobile and tablet devices. You could resize the browser yourself, or use a browser extension or tools within your IDE; but there is an ultra-simple tool that allows you to see how a page displays on different screen sizes, in a single view. The Responsive Web Design Tool from Matt Kersley works by entering your website’s URL into the address bar to test a specific page. The screen and device options are 240 x 320 (small phone), 320 x 480 (iPhone), 480 x 640 (small tablet), 768 x 1024 (iPad – Portrait) and 1024 x 768 (iPad – Landscape). However, the content width cannot be pixel-perfect, as 15 pixels have to be added to the frame to accommodate the scrollbars.

You can share the results of the test with others by adding any URL to the end of the testing page address (e.g. One major benefit of this tool is that it can be self-hosted(available on GitHub) by downloading and installing it on your own site. You can then navigate through the frames that your website appears in, testing the entire site effortlessly.

Alternatives: Screen QueriesScreenflyResponsivepxResponsinator,Responsive Viewport, and Resize My Browser.

5. FitText

As content scales according to a user’s viewport, the text will naturally wrap as the container is narrowed; but this often causes widows, orphans or your headlines to look rather ugly, and can even break the entire layout. This is where FitText comes in: It’s a fantastic jQuery plugin that makes your finely tuned text inflatable. It auto-updates the font size according to the width of the element wrapping it, so you can achieve scalable headlines and a non-broken layout that can be caused by font-sizing issues. FitText works perfectly withLettering.js or any CSS3 property thrown at it. There are options to fine-tune the text, including the ability to set min-max sizes and the level of scaling. For those that are opposed to “window.resize(),” Chris Coyier created a fork of FitText that limits the number of window-resize events.

As the plugin ignores the font size you specify in the CSS file (body tag), you should set one as a fallback, in case JavaScript is turned off. Equally important is making sure the H1 tag has a display block with a specified width. Please note that FitText is only for headlines, and shouldn’t be used with paragraph text.

Alternatives: BigTextLettering.jsKerning.jsKern.jsType Butter andSlabtext.

6. Respond.js

Media Queries are extensions of CSS3, supported by most modern browsers; they allow you to specify when certain CSS rules should be applied. But one disadvantage of using media queries is that as they are part of the CSS3 specifications; they are not supported in older browsers such as in IE8 and below. With Respond.js, this problem is solved, as the script makes min-width and max-width work in IE6, 7 and 8, and it should also work with other browsers lacking support.

The script itself is incredibly small and lightweight (only 3 KB minified and 1 KB gzipped). It works unobtrusively, and doesn’t rely on any other scripts or frameworks to run. It works by requesting a clean copy of your website’s CSS via AJAX, and then translates any media queries it finds into equivalent JavaScript for browsers that don’t support media queries directly.

Alternatives: ModernizerAdaptCategorizrCSS3 Media Queries andEnquire.js.

7. Responsive Slides

An incredibly lightweight jQuery plugin (only 1 KB minified and gzipped) that creates a responsive slider using list items inside a single container, Responsive Slides works with a wide range of browsers, including IE 6 and up. The plugin is dependent on the images being the same size and jQuery 1.6 and up being used. The plugin uses CSS3 transitions with JavaScript fallback, and allows captions and other non-HTML elements inside the slides. There are settings for transition and timeout durations, with multiple slideshows supported, as well as automatic and manual fade.

While Responsive Slides keeps things simple, there are still a wealth of options and possibilities to customize the plugin, including optional “before” and “after” callbacks, separate pagination controls, a random order setting and the choice of where to append the controls.

Alternatives: Flex SliderSlides.jsPhotoSwipeSupersizedCamera,RefineSlideBlueberry Sequence.js and Galleria.

8. Wirefy

Flat, static wireframes aren’t particularly useful to show a client how responsive your design is, or what functionality is being suggested. Instead, using a rapid prototype approach may be more beneficial. Wirefy is a collection of functional responsive HTML snippets and templates that scale as the browser is resized (working across multiple devices). It builds on tools such as the Frameless grid system and Bootstrap, and uses CSS media queries that adapt to different device resolutions. It allows you to experiment rapidly with responsive wireframes, and lays a foundation for the design (while staying design agnostic), without losing sight of the content’s importance.

Built on a 16-column base grid, it is packed with UI elements and styles such as typography, tables, images, forms, buttons, tab panel, breadcrumb system, paginator, menu, slideshow and much more. When compared to other frameworks, it is stripped down and doesn’t focus on fancy components, but rather focuses on the users, and how they will experience your content on various devices.

Alternatives: FroontInteractive Style TilesResponsive Sketch Sheets,Responsive Wireframe TemplateInterface Sketch TemplatesResponsive Device DiagramsWirifyResponsive Design SheetsResponsive Wireframes,WebstilesResponsive Design Sketchbook and Style Prototypes

9. Responsive Tables

Data tables in responsive design can be problematic: They can be wide and must cater to large, complex amounts of data that need to be kept together to make sense. When the viewport is adjusted, your table can suddenly look very ugly — either being too small to read easily, or zoomed in too far, requiring scrolling. But ZURB offers a simple JavaScript/CSS combination to let tables adapt to small devices and tablets without breaking your responsive layout. It works by taking the first column, which is often the unique key for a table, and “pinning” it to the left of the table, allowing you to scroll the other columns under it. This means the user is able to see the entire table.

It’s a lightweight package containing two key files: responsive-tables.js and responsive-tables.css. To use it on any data table in your markup, you simply need to attach a class of .responsive, and the CSS and JavaScript will do the rest. From there, the tables are modified client-side when the window is smaller than a regular table.

Alternatives: Responsive Data TablesStackable.jsFootableResponsive TablesResponsive TablesResponsive SEO Friendly Data Tables,Responsive Approach for Data Tables and RainbowTables.

10. FlevNav

With responsive design now at the forefront of web design, and the ever-increasing use of mobile and tablet devices, the choice of a navigation strategy is now a wide-reaching decision. It needs to be as carefully planned as your content architecture. FlexNav is a jQuery plugin that takes a device-agnostic approach to complex site navigation. It is a mobile-first concept using media queries and JavaScript to create a menu with drop downs. It features multiple nested sub-menus, with support for em units and tap targets to reveal sub-menus for touchscreens.

It’s simple to set up: Start with an unordered list, add in the appropriate class and data attributes (you can also use em units), add flexnav.css to the head of your document, insert jquery.flexnav.min.js before the closing body tag and initialize FlexNav right before the closing body tag. The default speed can be changed, with the plugin being supported by most modern browsers.

Alternatives: TinyNav.jsNavigation Patterns for Responsive Design,MeanMenuResponsive Solutions for Menu NavigationjPanelMenu,Responsive Design Approach for Navigation and Top Drawer.

Responsive Television

Article: Source

Sometimes, you watch TV on a small screen, sometimes you watch TV on a big screen. Sometimes you’re close to it, other times you’re not. Some TV watchers have 20/20 vision, others don’t.

What if TV adapted to your viewing, the same way that responsive websites adapt to differently-sized devices?

With the confluence of web-enabled televisions, streaming internet video, and a growing cultural appreciation for design, customization of electronics, and accessiblity, this might be a reasonable thing to see in the near future: a television that not only shows you *what* you want to see, but *how* you’d like to see it.

 Adapting to different screen sizes

In many ways, our current televisions do the same thing they’ve always done: show you a full-screen video stream that’s the exact same, regardless of the size or shape of your television.

For movies and sitcoms, this isn’t a big deal: the desired screen is a full-screen single video. For programs that have onscreen chrome, though, this one-size-fits-all approach isn’t great: sports and news channels show scores, tickers, clocks, headlines, and other elements that might warrant the ability to distinguish chrome from video.

Here’s a TV sitcom: all video, no chrome.


Here’s a baseball game and a news program: mostly video, a bit of chrome:


Last, here’s a TV Guide: Just a bit of video in the corner, with most of the interface devoted to the guide:

TV Guide

What would it look like if the interface could change, based on the screen size?

For example, here’s how a responsive television broadcast of a baseball game might appear in three different contexts:

The Kitchen Television:

Kitchen TV

You’re prepping some dinner, and you’ve got the game on in the background. Your kitchen TV is pretty small, and it’s probably far away in a corner somewhere. In this context, the scores show up larger, the sports tickers are gone (they were too small to read, anyway), and as a result, the actual video is a bit smaller. Like a mobile app that focuses on glanceable stats, the kitchen TV focuses on scores and audio.

The Living Room:

Living Room

Same as it is today: moderately-proportioned scores, small sports ticker, and fullscreen video.

The Massive Home Theater: 

Home Theater

This set shows video content that’s a bit more zoomed out (to make the experience more immersive and lifelike), there’s extra content about the player onscreen, and the sports tickers are reduced in proportion to be legible but not obnoxiously large.

Now that we’ve gone and seperated the video from the chrome, why not take it a bit further?


You’ve customized the apps on your smartphone, customized the layout of your cupboards, and customized the bookmarks in your web browser. What if TV could do the same?

  • ESPN viewers could set individual preferences for the sports scores that they see in the screen’s ticker.
  • Let users choose what statistics from the current baseball game they’d like to see.
  • Let users toggle the presence of news tickers, headlines, clocks, etc on a news channel.
  • When your grandpa sits down in front of the TV, it knows his favorite channels and shows them in a large-text, easy-to-read menu.


  • Detect different individuals and their accessiblity needs, and change the interface on-the-fly to accomodate them.
  • Allow users with accessibility concerns (poor eyesight, colorblindness, attention deficit disorder) the ability to set minimum contrasts for this type of chrome.
  • Closed-caption services that don’t suck: beautiful, legible text onscreen to help hard-of-hearing viewers understand.


Take it to the next level, and add the ability for the television to sense where and who you are:

  • When your kid walks into the room while you’re watching a horror film, the TV set pauses so the kid doesn’t see something terrifying.
  • Got kids and want to limit the amount of TV they watch? Easy: the TV knows them and how much they’ve watched, and turns off after awhile. It could also limit what channels they can watch without parental supervision in the room.
  • The TV could pause show when you leave the room to grab a drink.

If there’s one thing the pre- and post-iPhone smartphones showed us, it’s that pre-existing design decisions are difficult to get out of, until you see something much better and rapidly shift to it. If Apple’s got another trick up its sleeve for the television, I’d hope it might include something like this.

It doesn’t seem unlikely, either. With MLB, NBA, NHL, and the Wall Street Journal all providing subscriptions for Apple TV customers, it’s totally feasible that Apple could create these adaptive and customized television experiences. These subscriptions could seperate the content from the chrome, and adapt to your screen. 

Mobile First and Foundation 4

Article: Source

The other day, our friend and advisor Luke Wroblewski stopped by for a chat with Jonathan, Chris and myself. We’re in the midst of working on the finishing touches to Foundation 4, polishing the chrome and making her seaworthy. And Luke’s visit was a pleasant distraction.


Luke turned us on to Mobile First and his work has greatly influenced how we’re approaching Foundation 4, which we talked about during our conversation with him. While we talked, Chris was furiously pounding away on the code — he can pat his head and rub his tummy at the same time.

Some good stuff was said and we didn’t want you to feel left out. Here are a few snippets from our conversation:

Mobile First and Responsive

Luke: Step out to any street corner and people have their face in a smartphone. That trend doesn’t show any signs of letting up. In fact, it’s constantly growing. I think the whole idea of Mobile First is reaching all these audiences anywhere and everywhere. ‘Cause you can pull out your mobile device anywhere and everywhere. All the kinds of things people are doing are all the kinds of things we used to make websites about — buying things, looking up information, taking to their friends, killing some downtime, anything and everything is now mobile.

Mobile First, in a responsive paradigm, for me, forces you to focus on the stuff that matters, front and center. So what you see is people designing things desktop site down. What you end up is that they cram everything and the kitchen sink into the site. They make it huge and bloated in terms of performance, in terms of content, in terms of features. What they end up doing to get down to a mobile view, they stack everything into one long list. It’s huge and it takes forever. It basically creates a crappy mobile experience.

Shifting Paradigms

Jonathan: We’re doing something different with 4 than we did with 3. When we did 3, we said “2 is dead.” With 4, 3 is still there. Because even with our clients, it’s going to be another year of us beating the drum as much as we can to get our clients to sign up doing things Mobile First.

The nice thing about Foundation is we’ve always built Foundation so that it’s probably six months to a year ahead of where we are.

Luke: That’s an interesting philosophy. Sorta building ahead of where your clients are and bring them there over time and learn the lessons.

Jonathan: We have to drag them kicking and screaming. On the way, we get there ourselves.

Luke: I talk with a lot of companies around this sort of stuff. All of them know the terms. They know responsive web design. They know Mobile First. They know that they should be acting on it. But what’s really holding them back is their existing properties and processes. To be clear, what makes people uncomfortable is that it’s a different way of working. It’s different than what we’ve been doing for 20-plus years.

My counter argument to that is that it’s a pretty different web, pretty different world than it was 20 years ago. If you’re expecting things that worked for you 20 years ago work today, I don’t think that’s a viable way to run a business.

The other argument that I hear is that it costs more, takes more time. My response is: OK, so you can keep making a desktop and laptop site and just not have all these new audiences on tablets, on smartphones and all that stuff. If you want more usage on these more devices, more online time, you have to invest a little more. It’s not going to come for free. Nobody just comes hands you a pile of money or customers if you do nothing.

Jonathan: At some point, it’s just going to be the cost of doing business.

Forward the (Mobile First) Foundation

Jonathan: Luke got us turned on to the whole thing. We had lunch … how long ago?

Chris: Back in November … maybe September …

Jonathan: About six months ago, we had lunch with Luke. And Luke was like beating us over the head with “Foundation ought to go Mobile First”. And we talked about it before but that was the first conversation where we got to the end of it and was “like OK that makes some sense.”

Chris: He made us look at Zepto too.

Jonathan: He turned us on to Zepto. So that was a good conversation. I think it was a confluence of — he made a pretty good case for it. Honestly, I think, at last to me, the best case so far. Since we’re doing things mobile first, technically, we have the capability with Foundation to build experiences that don’t suck for like really old phones and feature phones. We’re not going to inherit all the styles we try to cram in there. It will actually be a mobile site.

So we can broaden our appeal by simplifying what we present for devices like that or older browsers like IE6 or 7. You could reasonably say you can build a site for IE6 using Foundation 4, which wasn’t the case with Foundation 3. That was a win.

Luke: To build on that. The promise of tomorrow, for me, is more and more multi-device web. There’s no shortage of devices.

Toward Tomorrow and Beyond

Luke: I think that it’s encouraging to see that more and more people are understanding this opportunity and jumping on it. You guys, potential working with clients, using Foundation — it’s a great vehicle understanding kind of what they’re inevitably going to have to do on the Web. I appreciate that you guys are moving it forward and pushing it past where the clients are right now. In the end, I think it’s going to be good for you and for them. It’s not a negative thing for me. I do agree that change is hard. It’s inevitable to deny that the mobile thing is here. And you’re going to have to deal with it. And eventually deal with it in a good way.

Jonathan: Pretty stoked to where Foundation is going. We wouldn’t have taken the direction we did if you hadn’t badger us for the last year and a half.

Solar Powered Tree Provides Light to Poor Neighborhoods

Article: Source


Designed as part of Moma’s exhibit on experiments in responsive textile architecture, SonUmbra is a bright and energetic tree built to function completely on solar power. By day, the structure serves just like any other natural tree, standing tall and providing shelter from the sun. By night, the light emitting fabric that forms the branches glows with patterns of light. The creator, London-based design firm Loop.pH, states that they strive to “create a new design practice reaching beyond specialist boundaries, mediating between digital & biological media and facilitating participatory design and urban crafts.”

The ultimate goal is for the piece to stand as a light source in towns and villages that cannot afford electricity. However, in the development stages, the artists realized a creative opportunity to construct an interactive piece in which light and motion coexist. The model that stands in Mowbray Park, Sunderland, is designed to react to the activity of people in the surrounding area. As visitors move around the structure, the light emitting patterns react to the sounds and movement and create an awe-inspiring geometric light show. The designers say, “Wandering unaware or actively gravitating towards Sonumbra, each person plays a part and becomes a note in a unique composition of light, sound and space.”