Skip navigation
Help

mobile web

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

First time accepted submitter faffod writes "Coming from a background of console development, where memory management is a daily concern, I found it interesting that there was any doubt that memory management on a constrained system, like a mobile device, would be a concern. Drew Crawford took the time to document his thoughts, and though there is room for some bikesheding, overall it is spot on. Plus it taught me what bikeshedding means."

0
Your rating: None
Original author: 
Wilson Page

  

When the mockups for the new Financial Times application hit our desks in mid-2012, we knew we had a real challenge on our hands. Many of us on the team (including me) swore that parts of interface would not be possible in HTML5. Given the product team’s passion for the new UI, we rolled up our sleeves and gave it our best shot.

We were tasked with implementing a far more challenging product, without compromising the reliable, performant experience that made the first app so successful.

promo-500-compr

We didn’t just want to build a product that fulfilled its current requirements; we wanted to build a foundation that we could innovate on in the future. This meant building with a maintenance-first mentality, writing clean, well-commented code and, at the same time, ensuring that our code could accommodate the demands of an ever-changing feature set.

In this article, I’ll discuss some of the changes we made in the latest release and the decision-making behind them. I hope you will come away with some ideas and learn from our solutions as well as our mistakes.

Supported Devices

The first Financial Times Web app ran on iPad and iPhone in the browser, and it shipped in a native (PhoneGap-esque) application wrapper for Android and Windows 8 Metro devices. The latest Web app is currently being served to iPad devices only; but as support is built in and tested, it will be rolled out to all existing supported platforms. HTML5 gives developers the advantage of occupying almost any mobile platform. With 2013 promising the launch of several new Web application marketplaces (eg. Chrome Web Store and Mozilla Marketplace), we are excited by the possibilities that lie ahead for the mobile Web.

Fixed-Height Layouts

The first shock that came from the new mockups was that they were all fixed height. By “fixed height,” I mean that, unlike a conventional website, the height of the page is restricted to the height of the device’s viewport. If there is more content than there is screen space, overflow must be dealt with at a component level, as opposed to the page level. We wanted to use JavaScript only as a last resort, so the first tool that sprang to mind was flexbox. Flexbox gives developers the ability to declare flexible elements that can fill the available horizontal or vertical space, something that has been very tricky to do with CSS. Chris Coyier has a great introduction to flexbox.

Using Flexbox in Production

Flexbox has been around since 2009 and has great support on all the popular smartphones and tablets. We jumped at the chance to use flexbox when we found out how easily it could solve some of our complex layouts, and we started throwing it at every layout problem we faced. As the app began to grow, we found performance was getting worse and worse.

We spent a good few hours in Chrome Developers Tools’ timeline and found the culprit: Shock, horror! — it was our new best friend, flexbox. The timeline showed that some layouts were taking close to 100 milliseconds; reworking our layouts without flexbox reduced this to 10 milliseconds! This may not seem like a lot, but when swiping between sections, 90 milliseconds of unresponsiveness is very noticeable.

Back to the Old School

We had no other choice but to tear out flexbox wherever we could. We used 100% height, floats, negative margins, border-box sizing and padding to achieve the same layouts with much greater performance (albeit with more complex CSS). Flexbox is still used in some parts of the app. We found that its impact on performance was less expensive when used for small UI components.

layout-time-with-flexbox-500_comp
Page layout time with flexbox

layout-time-without-flexbox-500_comp
Page layout time without flexbox

Truncation

The content of a fixed-height layout will rarely fit its container; eventually it has to overflow. Traditionally in print, designers have used ellipses (three dots) to solve this problem; however, on the Web, this isn’t the simplest technique to implement.

Ellipsis

You might be familiar with the text-overflow: ellipsis declaration in CSS. It works great, has awesome browser support, but has one shortfall: it can’t be used for text that spans multiple lines. We needed a solution that would insert an ellipsis at the point where the paragraph overflows its container. JavaScript had to step in.

ellipsis-500_mini
Ellipsis truncation is used throughout.

After an in-depth research and exploration of several different approaches, we created our FTEllipsis library. In essence, it measures the available height of the container, then measures the height of each child element. When it finds the child element that overflows the container, it caps its height to a sensible number of lines. For WebKit-based browsers, we use the little-known -webkit-line-clamp property to truncate an element’s text by a set number of lines. For non-WebKit browsers, the library allows the developer to style the overflowing container however they wish using regular CSS.

Modularization

Having tackled some of the low-level visual challenges, we needed to step back and decide on the best way to manage our application’s views. We wanted to be able to reuse small parts of our views in different contexts and find a way to architect rock-solid styling that wouldn’t leak between components.

One of the best decisions we made in implementing the new application was to modularize the views. This started when we were first looking over the designs. We scribbled over printouts, breaking the page down into chunks (or modules). Our plan was to identify all of the possible layouts and modules, and define each view (or page) as a combination of modules sitting inside the slots of a single layout.

Each module needed to be named, but we found it very hard to describe a module, especially when some modules could have multiple appearances depending on screen size or context. As a result, we abandoned semantic naming and decided to name each component after a type of fruit — no more time wasted thinking up sensible, unambiguous names!

An example of a module’s markup:


<div class="apple">
  <h2 class="apple_headline">{{headline}}</h2>
  <h3 class="apple_sub-head">{{subhead}}</h3>
  <div class="apple_body">{{body}}</div>
</div>

An example of a module’s styling:


.apple {}

.apple_headline {
  font-size: 40px;
}

.apple_sub-head {
  font-size: 20px;
}

.apple_body {
  font-size: 14px;
  column-count: 2;
  color: #333;
}

Notice how each class is prefixed with the module’s name. This ensures that the styling for one component will never affect another; every module’s styling is encapsulated. Also, notice how we use just one class in our CSS selectors; this makes our component transportable. Ridding selectors of any ancestral context means that modules may be dropped anywhere in our application and will look the same. This is all imperative if we want to be able to reuse components throughout the application (and even across applications).

What If a Module Needs Interactions?

Each module (or fruit) has its own markup and style, which we wrote in such a way that it can be reused. But what if we need a module to respond to interactions or events? We need a way to bring the component to life, but still ensure that it is unbound from context so that it can be reused in different places. This is a little trickier that just writing smart markup and styling. To solve this problem, we wrote FruitMachine.

Reusable Components

FruitMachine is a lightweight library that assembles our layout’s components and enables us to declare interactions on a per-module basis. It was inspired by the simplicity of Backbone views, but with a little more structure to keep “boilerplate” code to a minimum. FruitMachine gives our team a consistent way to work with views, while at the same time remaining relatively unopinionated so that it can be used in almost any view.

The Component Mentality

Thinking about your application as a collection of standalone components changes the way you approach problems. Components need to be dumb; they can’t know anything of their context or of the consequences of any interactions that may occur within them. They can have a public API and should emit events when they are interacted with. An application-specific controller assembles each layout and is the brain behind everything. Its job is to create, control and listen to each component in the view.

For example, to show a popover when a component named “button” is clicked, we would not hardcode this logic into the button component. Instead “button” would emit a buttonclicked event on itself every time its button is clicked; the view controller would listen for this event and then show the popover. By working like this, we can create a large collection of components that can be reused in many different contexts. A view component may not have any application-specific dependencies if it is to be used across projects.

Working like this has simplified our architecture considerably. Breaking down our views into components and decoupling them from our application focuses our decision-making and moves us away from baking complex, heavily dependent modules into our application.

The Future of FruitMachine

FruitMachine was our solution to achieve fully transportable view components. It enables us to quickly define and assemble views with minimal effort. We are currently using FruitMachine only on the client, but server-side (NodeJS) usage has been considered throughout development. In the coming months, we hope to move towards producing server-side-rendered websites that progressively enhance into a rich app experience.

You can find out more about FruitMachine and check out some more examples in the public GitHub repository.

Retina Support

The Financial Times’ first Web app was released before the age of “Retina” screens. We retrofitted some high-resolution solutions, but never went the whole hog. For our designers, 100% Retina support was a must-have in the new application. We developers were sick of maintaining multiple sizes and resolutions of each tiny image within the UI, so a single vector-based solution seemed like the best approach. We ended up choosing icon fonts to replace our old PNGs, and because they are implemented just like any other custom font, they are really well supported. SVG graphics were considered, but after finding a lack of support in Android 2.3 and below, this option was ruled out. Plus, there is something nice about having all of your icons bundled up in a single file, whilst not sacrificing the individuality of each graphic (like sprites).

Our first move was to replace the Financial Times’ logo image with a single glyph in our own custom icon font. A font glyph may be any color and size, and it always looks super-sharp and is usually lighter in weight than the original image. Once we had proved it could work, we began replacing every UI image and icon with an icon font alternative. Now, the only pixel-based image in our CSS is the full-color logo on the splash screen. We used the powerful but rather archaic-looking FontForge to achieve this.

Once past the installation phase, you can open any font file in FontForge and individually change the vector shape of any character. We imported SVG vector shapes (created in Adobe Illustrator) into suitable character slots of our font and exported as WOFF and TTF font types. A combination of WOFF and TTF file formats are required to support iOS, Android and Windows devices, although we hope to rely only on WOFFs once Android gains support (plus, WOFFs are around 25% smaller in file size than TTFs).

icon-font-500-compr
The Financial Times’ icon font in Font Forge

Images

Article images are crucial for user engagement. Our images are delivered as double-resolution JPEGs so that they look sharp on Retina screens. Our image service (running ImageMagick) outputs JPEGs at the lowest possible quality level without causing noticeable degradation (we use 35 for Retina devices and 70 for non-Retina). Scaling down retina size images in the browser enables us to reduce JPEG quality to a lower level than would otherwise be possible without compression artifacts becoming noticeable. This article explains this technique in more detail.

It’s worth noting that this technique does require the browser to work a little harder. In old browsers, the work of scaling down many large images could have a noticeable impact on performance, but we haven’t encountered any serious problems.

Native-Like Scrolling

Like almost any application, we require full-page and subcomponent scrolling in order to manage all of the content we want to show our users. On desktop, we can make use of the well-established overflow CSS property. When dealing with the mobile Web, this isn’t so straightforward. We require a single solution that provides a “momentum” scrolling experience across all of the devices we support.

overflow: scroll

The overflow: scroll declaration is becoming usable on the mobile Web. Android and iOS now support it, but only since Android 3.0 and iOS 5. IOS 5 came with the exciting new -webkit-overflow-scrolling: touch property, which allows for native momentum-like scrolling in the browser. Both of these options have their limitations.

Standard overflow: scroll and overflow: auto don’t display scroll bars as users might expect, and they don’t have the momentum touch-scrolling feel that users have become accustomed to from their native apps. The -webkit-overflow-scrolling: touch declaration does add momentum scrolling and scroll bars, but it doesn’t allow developers to style the scroll bars in any way, and has limited support (iOS 5+ and Chrome on Android).

A Consistent Experience

Fragmented support and an inconsistent feel forced us to turn to JavaScript. Our first implementation used the TouchScroll library. This solution met our needs, but as our list of supported devices grew and as more complex scrolling interactions were required, working with it became trickier. TouchScroll lacks IE 10 support, and its API interface is difficult to work with. We also tried Scrollability and Zynga Scroller, neither of which have the features, performance or cross-browser capability we were looking for. Out of this problem, FTScroller was developed: a high-performance, momentum-scrolling library with support for iOS, Android, Playbook and IE 10.

FTScroller

FTScroller’s scrolling implementation is similar to TouchScroll’s, with a flexible API much like Zynga Scroller. We added some enhancements, such as CSS bezier curves for bouncing, requestAnimationFrame for smoother frame rates, and support for IE 10. The advantage of writing our own solution is that we could develop a product that exactly meets our requirements. When you know the code base inside out, fixing bugs and adding features is a lot simpler.

FTScroller is dead simple to use. Just pass in the element that will wrap the overflowing content, and FTScroller will implement horizontal or vertical scrolling as and when needed. Many other options may be declared in an object as the second argument, for more custom requirements. We use FTScroller throughout the Financial Times’ Web app for a consistent cross-platform scrolling experience.

A simple example:


var container = document.getElementById('scrollcontainer');
var scroller = new FTScroller(container);

The Gallery

The part of our application that holds and animates the page views is known as the “gallery.” It consists of three divisions: left, center and right. The page that is currently in view is located in the center pane. The previous page is positioned off screen in the left-hand pane, and the next page is positioned off screen in the right-hand pane. When the user swipes to the next page, we use CSS transitions to animate the three panes to the left, revealing the hidden right pane. When the transition has finished, the right pane becomes the center pane, and the far-left pane skips over to become the right pane. By using only three page containers, we keep the DOM light, while still creating the illusion of infinite pages.

Web
Infinite scrolling made possible with a three-pane gallery

Making It All Work Offline

Not many Web apps currently offer an offline experience, and there’s a good reason for that: implementing it is a bloody pain! The application cache (AppCache) at first glance appears to be the answer to all offline problems, but dig a little deeper and stuff gets nasty. Talks by Andrew Betts and Jake Archibald explain really well the problems you will encounter. Unfortunately, AppCache is currently the only way to achieve offline support, so we have to work around its many deficiencies.

Our approach to offline is to store as little in the AppCache as possible. We use it for fonts, the favicon and one or two UI images — things that we know will rarely or never need updating. Our JavaScript, CSS and templates live in LocalStorage. This approach gives us complete control over serving and updating the most crucial parts of our application. When the application starts, the bare minimum required to get the app up and running is sent down the wire, embedded in a single HTML page; we call this the preload.

We show a splash screen, and behind the scenes we make a request for the application’s full resources. This request returns a big JSON object containing our JavaScript, CSS and Mustache templates. We eval the JavaScript and inject the CSS into the DOM, and then the application launches. This “bootstrap” JSON is then stored in LocalStorage, ready to be used when the app is next started up.

On subsequent startups, we always use the JSON from LocalStorage and then check for resource updates in the background. If an update is found, we download the latest JSON object and replace the existing one in LocalStorage. Then, the next time the app starts, it launches with the new assets. If the app is launched offline, the startup process is the same, except that we cannot make the request for resource updates.

Images

Managing offline images is currently not as easy as it should be. Our image requests are run through a custom image loader and cached in the local database (IndexedDB or WebSQL) so that the images can be loaded when a network connection is not present. We never load images in the conventional way, otherwise they would break when users are offline.

Our image-loading process:

  1. The loader scans the page for image placeholders declared by a particular class.
  2. It takes the src attribute of each image placeholder found and requests the source from our JavaScript image-loader library.
  3. The local database is checked for each image. Failing that, a single HTTP request is made listing all missing images.
  4. A JSON array of Base64-encoded images is returned from the HTTP response and stored separately in the local database.
  5. A callback is fired for each image request, passing the Base64 string as an argument.
  6. An <img> element is created, and its src attribute is set to the Base64 data-URI string.
  7. The image is faded in.

I should also mention that we compress our Base64-encoded image strings in order to fit as many images in the database as possible. My colleague Andrew Betts goes into detail on how this can be achieved.

In some cases, we use this cool trick to handle images that fail to load:


<img src="image.jpg" onerror="this.style.display='none';" />

Ever-Evolving Applications

In order to stay competitive, a digital product needs to evolve, and as developers, we need to be prepared for this. When the request for a redesign landed at the Financial Times, we already had a fast, popular, feature-rich application, but it wasn’t built for change. At the time, we were able to implement small changes to features, but implementing anything big became a slow process and often introduced a lot of unrelated regressions.

Our application was drastically reworked to make the new requirements possible, and this took a lot of time. Having made this investment, we hope the new application not only meets (and even exceeds) the standard of the first product, but gives us a platform on which we can develop faster and more flexibly in the future.

(al)

© Wilson Page for Smashing Magazine, 2013.

0
Your rating: None
Original author: 
GoogleDevelopers


The Modern Workflow for Developing the Mobile Web - Google I/O 2013

Matt Gaunt Building for today's mobile web, getting 60fps across all target devices, while still delivering a fantastic user experience is a huge challenge. ...
From:
GoogleDevelopers
Views:
3483

54
ratings
Time:
30:33
More in
Science & Technology

0
Your rating: None
Original author: 
(author unknown)

I know you’ve been asked this plenty of times already, but: no new vendor prefixes, right? Right?

Nope, none! They’re great in theory but turns out they fail in practice, so we’re joining Mozilla and the W3C CSS WG and moving away them. There’s a few parts to this.

Firstly, we won’t be migrating the existing -webkit- prefixed properties to a -chrome- or -blink- prefix, that’d just make extra work for everyone. Secondly, we inherited some existing properties that are prefixed. Some, like -webkit-transform, are standards track and we work with the CSS WG to move ahead those standards while we fix any remaining issues in our implementation and we’ll unprefix them when they’re ready. Others, like -webkit-box-reflect are not standards track and we’ll bring them to standards bodies or responsibly deprecate these on a case-by-case basis. Lastly, we’re not introducing any new CSS properties behind a prefix.

Pinky swear?

Totes. New stuff will be available to experiment with behind a flag you can turn on in about:flags called “Experimental Web Platform Features”. When the feature is ready, it’ll graduate to Canary, and then follow its ~12 week path down through Dev Channel, Beta to all users at Stable.

The Blink prefix policy is documented and, in fact, WebKit just nailed down their prefix policy going forward. If you’re really into prefix drama (and who isn’t!) Chris Wilson and I discussed this a lot more on the Web Ahead podcast [37:20].

How long before we can try Blink out in Chrome?

Blink’s been in Chrome Canary as of the day we announced it. The codebase was 99.9% the same when Blink launched, so no need to rush out and check everything. All your sites should be pretty much the same.

Chrome 27 has the Blink engine, and that’s available on the beta channel for
Win, Mac, Linux, ChromeOS and Android. (See the full beta/stable/dev/canary
view
).

While the internals are apt to be fairly different, will there be any radical changes to the rendering side of things in the near future?

Nothing too alarming, layout and CSS stuff is all staying the same. Grid layout is still in development, though, and our Windows text rendering has been getting a new backend that we can hook up soon, greatly boosting the quality of webfont rendering there.

We’re also interested in better taking advantage of multiple cores on machines, so the more we can move painting, layout (aka reflow), and style recalculation to a separate thread, but the faster everyone’s sites will render. We’re already doing multi-threaded painting on ChromeOS and Android, and looking into doing it on Mac & Windows. If you’re interested in these experimental efforts or watching new feature proposals, take a look at the blink-dev mailing list. A recent proposed experiment is called Oilpan, where we’ll look into the advantages of moving the implementation of Chrome’s DOM into JavaScript.

Will features added to Blink be contributed back to the WebKit project? Short term; long term?

Since Blink launched there’s been a few patches that have been landed in both Blink and WebKit, though this is expected to decline in the long-term, as the code bases will diverge.

When are we likely to start seeing Blink-powered versions of Chrome on Android? Is it even possible on iOS, or is iOS Chrome still stuck with a Safari webview due to Apple’s policies?

Blink is now in the Chrome Beta for Android. Chrome for iOS, due to platform limitations, is based on the WebKit-based WebView that’s provided by iOS.

Part of this move seems to be giving Google the freedom to remove old or disused features that have been collecting dust in WebKit for ages. There must be a few things high on that list—what are some of those things, and how can we be certain their removal won’t lead to the occasional broken website?

A few old ’n crusty things that we’re looking at removing: the isindex attribute, RangeException, and XMLHttpRequestException. Old things that have little use in the wild and just haven’t gotten a spring cleaning from the web platform for ages.

Now, we don’t want to break the web, and that’s something that web browser engineers have always been kept very aware of. We carefully gauge real-world usage of things like CSS and DOM features before deprecating anything. At Google we have a copy of the web that we run queries against, so we have a pretty OK idea of what CSS and JavaScript out there is using.

Blink also has over 32,000 tests in its test suite, and manual confirmation that over 100 sites work great before every release ships. And we’re working closely with the W3C and Adobe to share tests and testing infrastructure across browsers, with the goals of reducing maintenance burden, improving interoperability, and increasing test coverage. Eventually we’d like all new features to ship with shared conformance tests, ensuring interoperability even as we add cutting-edge stuff.

Still, any deprecation has to be done responsibly. There’s now a draft Blink process for deprecating features which includes:

  • Anonymous metrics to understand how much any specific feature is used “in the wild”
  • ”Intent to deprecate” emails that hit blink-dev months before anything is
    removed
  • Warnings that you’ll find in your DevTools console if you’re using anything
    deprecated
  • Mentions on the Chromium blog like this Chrome 27
    wrap-up
    .

Did part of the decision to branch away from WebKit involve resistance to adding a Dart VM? WebKit’s goals explicitly mention JavaScript, and Apple representatives have been fairly vocal about not seeing a need.

Nope, not at all. The decision was made by the core web platform engineers. Introducing a new VM to a browser introduces considerable maintenance cost (we saw this with V8 and JavaScriptCore both in WebKit) and right now Dart isn’t yet ready to be considered for an integration with Blink. (more on that in a sec). Blink’s got strong principles around compatibility risk and this guides a lot of the decisions around our commitments to potential features as they are proposed. You can hear a more complete answer here from Darin Fisher, one of the Chrome web platform leads.

Have any non-WebKit browsers recently expressed an interest in Dart? A
scripting language that only stands to work in one browser sounds a little
VBScript-y.

Not yet, but since Dart compiles to JavaScript and runs across the modern web, it’s not gated by other browsers integrating the VM. But it’s still early days, Dart has not yet reached a stable 1.0 milestone and that there are still technical challenges with the Dart VM around performance and memory management. Still, It’s important to point out that Dart is an open source project, with a bunch of external contributors and committers.

Let me take a moment to provide my own perspective on Dart. :) Now, as you know, I’m a JavaScript guy, so early on, I took a side and and considered Dart an enemy. JavaScript should win; Dart is bad! But then I came to realize the Dart guys aren’t just setting out to improve the authoring and scalability of web application development. They also really want the web to win.  Now I’ve recently spoke about how The Mobile Web Is In Trouble, and clarified that my priorities are seeing it provide a fantastic user experience to everyone. For me, seeing the mobile web be successful trumps language wars and certainly quibbling over syntax. So I’m happy to see developers embrace the authoring advantages of Coffeescript, the smart subset of JavaScript strict mode, the legendary Emscripten & asm.js combo, the compiler feedback of TypeScript and the performance ambitions of Dart. It’s worth trying out technologies that can leapfrog the current expectations of the user experience that we can deliver. Our web is worth it.

Will Opera be using the Chromium version of Blink wholesale, as far as you know? Are we likely to see some divergence between Opera and Chrome?

As I understand it, Opera Mobile, Opera Desktop, and Opera Mini will all be based on Chromium. This means that they’ll not only share the exact version of Blink that Chrome uses, but also the same graphics stack, JavaScript engine, and networking stack. Already, Opera has contributed some great things to Blink and we’re excited about what’s next.

Why the name “Blink,” anyway?

Haha. Well… it’s a two parter. First, Blink evokes a certain feeling of speed and simplicity—two core principles of Chrome. Then, Chrome has a little tradition of slightly ironic names. Chrome itself is all about minimizing the browser chrome, and the Chromebook Pixel is all about not seeing any pixels at all. So naturally, it fits that Blink will never support the infamous <blink> tag. ;)

<3z

0
Your rating: None
Original author: 
Peter Bright

Aurich Lawson (with apologies to Bill Watterson)

Google announced today that it is forking the WebKit rendering engine on which its Chrome browser is based. The company is naming its new engine "Blink."

The WebKit project was started by Apple in 2001, itself a fork of a rendering engine called KHTML. The project includes a core rendering engine for handling HTML and CSS (WebCore), a JavaScript engine (JavaScriptCore), and a high-level API for embedding it into browsers (WebKit).

Though known widely as "WebKit," Google Chrome has used only WebCore since its launch in late 2008. Apple's Safari originally used the WebKit wrapper and now uses its successor, WebKit2. Many other browsers use varying amounts of the WebKit project, including the Symbian S60 browser, the BlackBerry browser, the webOS browser, and the Android browser.

Read 10 remaining paragraphs | Comments

0
Your rating: None

Imagine you’re at an intersection waiting for your turn to walk across the street. You push the button to call the walk signal, and you take out your phone. You want to accomplish one thing: maybe check your e-mail, add an item to your to-do list, or check Twitter. You have a limited amount of time to accomplish that one thing.

That amount of time is how long users have to finish what they want to do on your site. And it matters.

Adding half a second to a search results page can decrease traffic and ad revenues by 20 percent, according to a Google study. The same article reports Amazon found that every additional 100 milliseconds of load time decreased sales by 1 percent. Users expect pages to load in two seconds—and after three seconds, up to 40 percent will simply leave.

Can you keep up? If you’re designing sites with rich content, lots of dynamic elements, larger JavaScript files, and complex graphics—like so many of us are—the answer might be “no.”

It’s time we make performance optimization a fundamental part of how we design, build, and test every single site we create—for every single device.

Designing for performance

Website performance starts with design. Weigh a design choice’s impact on page speed against its impact on your site’s conversion rate. Do you really need eight different shades of blue? What value does this 1,000px-wide background image add? Will replacing a sprite with an icon font actually add more page weight and slow rendering, or will it be faster than the original image?

Not every design decision will favor performance. I’ve found that a button style that slightly slows page speed can still increase conversions, and it’s worth the small web performance sacrifice.

But sometimes, performance will win. I once had a landing page redesign that added a significant amount of images to a page, and I wasn’t sure whether the performance hit would have a negative impact on conversions, so I rolled the redesign out to a small subset of users in an A/B test to see what the impact would be. The new design took twice as long to load, and I immediately saw a high exit rate and lower conversion rate, so we kept the original lightweight design. Being wrong is okay—it’s what gives you a benchmark.

In another experiment, the dyn.com homepage featured a thumbnail image section with 26 images that rotated in and out of 10 slots.


dyn.com homepage.

My teammate at the time put all 26 images into a sprite, which:

  • Increased the total homepage size by 60K with the increased CSS, JavaScript, and image size needed to recreate this effect with the sprite
  • Decreased the number of requests by 21 percent
  • Cut the total homepage load time by a whopping 35 percent

This proves that it’s worth experimenting: We weren’t sure whether or not this would be a page speed success, but we felt it was worth it to learn from the experiment.

Coding for performance

Clean your HTML, and everything else will follow.

Start by renaming non-semantic elements in your HTML. This is probably the toughest, but once you start thinking about theming in terms of semantics like “nav” or “article” and less with design or grid names, you’ll make significant headway. Often we get to elements with non-semantic names by way of needing more weight in CSS selectors, and instead of cleaning our CSS and adding specificity the right way, we add unnecessary IDs and elements to our HTML.

Then, clean up your CSS. Remove inefficient selectors first. In a study I performed for writegoodcode.com, I found that adding inefficient selectors to a CSS file actually increased page load time by 5.5 percent. More efficient CSS selectors will actually be easier to redesign and customize the styles of in the future since they are easier to read in your stylesheet and have semantic meaning. Repurposable, editable code often goes hand-in-hand with good performance. In that case study, I saved 39 percent of the CSS file size by cleaning my CSS files.

Next, focus on curing your HTML of div-itis. Typically the cleaner your markup ends up, the smaller your CSS will be, and the easier redesigning and editing will be in the future. It saves you not just page load time, but development time too.

Last, focus on creating repurposable code, which saves time and results in smaller CSS and HTML files. Less HTML and CSS will be significantly easier to maintain and redesign later, and the smaller page sizes will have a positive impact on page speed.

Optimizing requests

Requests are when your browser has to go fetch something like a file or a DNS record. The cleaner your markup, the fewer requests the browser has to make—and the less time users will spend waiting for their browser to make those round trips.

In addition to clean markup, minimize JavaScript requests by only loading it when absolutely necessary. Don’t call a file on every page if you don’t need it on every page. Don’t load a JavaScript file on a responsive design that is only needed for larger screens; for example, replace social scripts with simple links instead. You can also load JavaScript asynchronously so that the JavaScript won’t block any content from rendering.

Though a responsive design typically means more CSS and images (larger page weight), you can still get faster load times from larger page sizes if you cut requests.

Optimizing images

Save as many image requests as you can, too. First, focus on creating sprites. In my writegoodcode.com study, I found that a sprite for the icons in the example cut page load time by 16.6 percent. I like to start cleaning up images by creating one sprite for repeating backgrounds. You may need to create one for vertical repeats and one for horizontal repeats.

Next, create one transparent sprite for no-repeat backgrounds. This will include things like your logo and icons. As you get more advanced, you can also use tools like Grunticon, which takes SVG icon and background images and figures out how best to serve them based on the user’s browser’s capabilities.

After you regenerate your images, run them through an optimizer like ImageOptim. Similarly, retina-sized images can still be made smaller with extensive compression that isn’t noticeable in the end result.

Now see which images you can replace with CSS3 gradients. This will not only make a dent in page load time, but it will also make it infinitely easier to edit the site later, as developers won’t have to find original image files to edit, regenerate, or re-optimize in the future.

Last, look at using Base64 encode, which allows you to embed an image into your CSS file instead of calling it using a separate URL. It ends up looking like this:

#nav li:after { content:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA
UAAAAFCAYAAACNbyblAAAAI0lEQVQIW2P4//8/w8yZM//DMIjPAGPAMIiPWx
CIMQQxzAQAoFpF7lGFr24AAAAASUVORK5CYII=);
}

The random letters and numbers add up to a small circle that’s used in many places within dyn.com. Embedding the image allows you to save an image request each time you want to use it in your design. Embedding images using this method will make your CSS file larger, so it’s worth testing the page load time before and after to ensure you’re making improvements.

Measuring performance

Now for the fun part: determining whether your efforts are paying off.

Both Google’s PageSpeed and Yahoo!’s YSlow offer suggestions on how you can improve page load time, including identifying which elements block page rendering and the size of your page’s different components like CSS or HTML.

I also recommend the YSlow extension 3PO, which checks your site for integration with popular third-party scripts like Twitter, Facebook, and Google+. The plugin can give you recommendations on how to further optimize the social scripts on your page to improve page load time.

WebPageTest.org has been my go-to benchmarking tool ever since I first started making improvements based on PageSpeed and YSlow’s suggestions. It gives very detailed information about requests, file size, and timing, and it offers multiple locations and browsers to test in.

Benchmarking can help you troubleshoot as you design. Measuring performance and analyzing the results will help you make both your large- and small-screen designs faster. You can also test and benchmark techniques like conditional loading of images as you get more comfortable developing for performance.

The impact of web performance

Web performance affects your users—and that means its everyone’s job to understand it, measure it, and improve it. All of these techniques will lead to better page load time, which creates a significant improvement to your site’s user experience.

Happier users mean better conversion rates, whether you’re measuring in revenue, signups, returning visits, or downloads. With a fast page load time, people can use your site and accomplish what they want in a short amount of time—even if it’s just while they’re waiting for a walk signal.

0
Your rating: None

  

Many of us care deeply about developing our craft. But staying up to date can be a true challenge, because the quantity of fresh information we’re regularly exposed to can be a lot to take in. 2012 has been no exception, with a wealth of evolution and refinement going on in the front end.

Great strides have been made in how we approach workflow, use abstractions, appreciate code quality and tackle the measurement and betterment of performance. If you’ve been busy and haven’t had time to catch up on the latest developments in these areas, don’t worry.

With the holiday season upon us and a little more time on our hands, I thought it would be useful to share a carefully curated list of the most relevant front-end talks I’ve found helpful this year. You certainly don’t have to read through them all, but the advice shared in them will equip you with the knowledge needed to go into the new year as a better front-end engineer.

Screenshot
Image credit: Jacob Bøtter

Baseline

Have a Strategy for Staying Up to Date

How to Stay Up to Date on Web Stuff, Chris Coyier

Part of continually developing your craft is staying up to date. Doing this is important for all professionals, and in this talk you’ll learn strategies for staying updated even when the ideas that surround the technologies we use are constantly evolving.

Screenshot

Make Sure Your Baseline for Development Is Current

A New Baseline for Front-End Developers, Rebecca Murphey

There was a time when editing files, testing them locally and simply FTP’ing them was the common workflow for a front-end developer. We would measure our abilities based on how well we could harass IE 6 into rendering pages correctly, and we generally lacked strong skills in HTML, CSS and JavaScript.

This has greatly changed over the past few years, with improvements in workflow and tooling. Front-end development is now taken more seriously, and this talk sheds light on the new baseline process for developing on the front end.

Screenshot

Understand How Browsers Work Behind the Scenes

So, You Want to Be a Front-End Engineer, David Mosher (Video)

Some would say that the browser is the most volatile development platform the world has ever known. If you’re a client-side developer, understanding how browser internals work can help you both make better decisions and appreciate the justifications behind many development best practices. In one of the best talks this year, David Mosher takes you through how browsers parse and render your pages.

Screenshot

Know What the Web Platform Now Has to Offer

The Web Can Do That!?, Eric Bidelman (Video)

The Web is constantly evolving, and keeping up with what’s new on the platform can be hard. HTML5’s new capabilities enable us to build an entirely new suite of applications with features that were simply impossible to achieve before (at least, not without the use of plugins) but are now a reality.

In this talk, my teammate Eric guides you through the bleeding edge of HTML5, focusing on solving many real-world problems. You’ll learn about media streaming, device input, modern CSS design, media capture, file I/O and more.

Screenshot

Workflow

For Web App Developers

Tooling for the Modern Web App Developer, Addy Osmani

Whether you’re using JavaScript or CoffeeScript, LESS or Sass, building an awesome Web application these days usually requires a plethora of boilerplates, frameworks and tools and a lot of glue to get them to work together. In short, you need a kick-ass utility belt.

In this talk, you’ll get an overview of the current tooling eco-system for the front-end and learn about a new tool that tries to bring together all of the pieces of this eco-system for you, called Yeoman.

Screenshot

An extended version of this talk is also available.

For Web Designers

A Modern Web Designer’s Workflow, Chris Coyier (Video)

A lot is expected from today’s Web designers. If this role defines what you do, then it’s now not just about visual design, but increasingly about building interactions. Designs need to work across different devices of varying shapes, sizes and connections, and they also need to be accessible.

As a designer, you often need to communicate and share code across teams and be familiar with many different technologies. In this talk, Chris Coyier discusses many of the amazing tools that can help things along, discussing what does what and giving a high-level view of a modern workflow.

Screenshot

For Mobile Web Developers

Mobile Web Developers Toolbelt, Pete Le Page (Video)

Building for the mobile Web requires a different mindset to the one we use when developing for desktop, and a different set of tools. Thankfully, a number of great options are available. From remote debugging to emulation, mobile browsers are offering more and more tools to make our lives easier.

In this talk, Pete Le Page takes you through a couple of tools that you can use today to make cross-platform mobile Web development easier, and then he peers into the crystal ball to see what tools the future may bring.

Screenshot

For Debugging

Secrets of the Chrome DevTools, Patrick Dubroy (Video)

Google Chrome Developer Tools provide powerful ways to understand, debug and profile Web applications. Most developers are familiar with Chrome’s basic inspection and debugging tools, but some of its most valuable features, like the Timeline and memory analysis tools, are less known.

In his demo-based walkthrough, Patrick Dubroy provides an overview of Chrome Developer Tools and an in-depth demonstration of some lesser-known features.

Screenshot

The Future

CSS

The CSS of Tomorrow, Peter Gasston

In this talk, Peter looks briefly at the state of CSS3: what you can do right now, and what you’ll be able to do in the very near future. He then looks into the long-term future, to a time when CSS3 will make possible page layouts far richer and more dynamic than we’d thought possible, and when CSS3 has taken on aspects of programming languages. This is effectively what CSS developers will be learning years from now.

Screenshot

JavaScript

The Future of JavaScript, Dave Herman

The Web platform is growing, and JavaScript is growing along with it. EcmaScript 6, the next edition of the JavaScript standard, is gearing up to be a huge step forward for Web programming. In this talk, Dave Herman discusses the exciting new features being worked on for EcmaScript 6 and how they can be used.

Screenshot

Web Applications

Web Components and the Future of Web App Development, Eric Bidelman

Web components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit together?

This talk prepares you for the future of the Web platform by discussing the fundamentals of Web components and how we can use them today with frameworks such as AngularJS.

Screenshot

CSS

State of the Art

All the New CSS Hawtness, Darcy Clarke

This talk dives into some of the latest CSS implementations and specifications floating around. You’ll learn what’s here and what’s around the corner, and you’ll gain insight into why these new features will change our development workflow.

Darcy Clarke touches on modules such as paged-media, multi-columns, flex-box, filters, regions, box-sizing, masking and 3D.

Screenshot

Modularity

Your CSS Is a Mess, Jonathan Snook

We all think that CSS is easy. Take some selectors, add some properties, maybe a dash of media queries, and — presto! — you have a beautiful website. And yet, as the project changes and the team grows, we see the frustration build, with increasingly complex selectors and overuse of !important.

In this talk, Jonathan looks at common problems and solutions that will make your CSS (and your projects) easier to manage and easier to scale.

Screenshot

Pre-Processors

CSS Pre-Processors, Bermon Painter

If you haven’t jumped on the pre-processor train this year, you’re missing out. In this helpful overview of (current) popular pre-processors, Bermon Painter takes you through Stylus, LESS and Sass, with features subdivided into easy-to-learn sections of beginner, intermediate and advanced. I’ve been using mixins quite heavily this year, and I simply wouldn’t have been able to if it weren’t for projects like Sass.

Screenshot

Documentation

A Better Future With KSS, Kyle Neath

Writing maintainable CSS within a team is one of those problems that a lot of people think can be solved by writing CSS in a particular style. But in Kyle’s experience, that never works out.

In this talk, he introduces you to his latest creation, KSS. It’s a documentation and style guide format. He’ll show you why he built KSS and how it’s been helping him at GitHub to refactor its four-and-a-half year old CSS, and he’ll give you a glimpse into the future of KSS.

Screenshot

JavaScript

The Importance of Code Style

Maintainable JavaScript, Nicholas Zakas

Some say that good code is its own documentation, and the fact is that the more readable our code is, the easier it is to maintain.

Writing JavaScript for fun and writing it professionally are two different things, and in this talk by Zakas, you’ll learn practices to make JavaScript maintainable over the long run, to reduce errors and to make your code easily adaptable to future changes. It’s highly recommended reading.

Screenshot

A Modern Large-Scale App Stack

SoundCloud’s Stack, Nick Fisher

I’ve talked a lot about large-scale development in the past. It’s a non-trivial problem that’s difficult to get right, and so it’s exciting when someone working on such challenges shares their experience.

In this talk, Nick Fisher of SoundCloud discusses the company’s story of developing large-scale applications with JavaScript, not only at runtime, but also its steps to make development and deployment easier. In particular, he looks at RequireJS and Backbone, talking about how SoundCloud has used and abused each to suit its needs, sometimes in uncommon ways.

Screenshot

Rethinking Application Structure

Re-Imagining the Browser With AngularJS, Igor Minar

What if you could a write modern Web app with dramatically fewer lines of code and improve its readability and expressiveness at the same time? In case you’re wondering: no, there’s no new language to learn, just familiar old HTML and JavaScript. As a matter of fact, there are concepts for you to unlearn.

AngularJS is a client-side JavaScript Web development framework whose authors believe they’ve done something special. Instead of asking what kind of functions they could provide to make writing apps smoother, they asked, “What if the browser worked differently in a way that eliminates code and gives structure to apps?”

In this talk, you’ll get a tour of how to get the power of tomorrow’s Web platform in today’s Web applications.

Screenshot

Internationalization and i18n

Entschuldigen you, parlez vouz JavaScript, Sebastian Golasch (Video)

While JavaScript applications grow in size and complexity, there are still some white spots on the big map of Web applications: internationalization and globalization! If you´re still thinking that switching strings in and out is the way to go, you are definitely headed in the wrong direction.

In this talk, Sebastian takes you through how to spot real-world internationalization problems and how to solve them in the most elegant way.

Screenshot

I couldn’t cover internationalization without mentioning Alex Sexton, who has also spoken a great deal on this topic. His JSConf talk on client-side internationalization is available in video form if you’re interested in checking it out.

Patterns and Principles

The Plight of Pinocchio, Brandon Keepers

JavaScript is no longer a toy language, and many of our Web applications can’t function without it. Brandon states that if we are going to use JavaScript to do real things, then we need to treat it like a real language, adopting the same practices that we use with real languages. I completely agree with him.

This framework-agnostic talk takes a serious look at how we develop JavaScript applications in the real world. Despite their prototypical nature, good object-oriented programming principles are still relevant. The design patterns that we’ve grown to know and love work just as well in JavaScript as they do in any other language.

Screenshot

When to Lazy Load Scripts

How Late Is Later?, Massimiliano Marcon

Reducing the loading time of a Web application is a well-known challenge. Developers need to make sure that the browser downloads only the code that is strictly necessary to bootstrap the application, and leave the rest for later. This is what we commonly call “lazy loading.”

But when is “later”? When is the right time to lazy load? This talk shows how JavaScript code — functions and objects — can be delivered to the browser on demand, thus reducing the perceived loading time of a Web application.

Screenshot

Mobile

Building Touch-Based Interfaces

Creating Responsive HTML5 Touch Interfaces, Stephen Woods (Video | Audio)

Flickr front-end engineer Stephen Woods shares some hard-learned lessons about building responsive touch-based interfaces using HTML5 and CSS. Because our users are demanding better instant feedback from touch-based UIs, understanding how to approach this problem and avoid the pitfalls will be critical for many application developers in the future.

Screenshot

The Challenge With Scrolling

Embracing Touch: Cross-Platform Scrolling, Mark Dalgleish (Video)

Scrolling effects are a popular way to add personality to the simple act of moving down the page. Unfortunately, these effects don’t work natively on mobile devices, where the touch interaction would make these techniques more effective. In this talk, Mark looks at some ways to implement these effects within the limitations of mobile browsers.

Screenshot

Native, HTML5 and Hybrid Apps

Native, HTML5 and Hybrid Mobile Development, Eran Zinman

One of the toughest decisions every mobile developer faces is choosing a development strategy: “Should I develop a native, HTML5 or hybrid mobile app?” Over the past two years, Eran has led Conduit’s mobile client development efforts, experimenting with cross-platform development in various flavors: from complete HTML5 solutions (using PhoneGap and other technologies) to hybrid solutions to semi-hybrid solutions to fully native solutions.

In this talk, Eran shares some real-life experiences in cross-platform development, describing changes that Conduit has implemented along the way, and sharing what some of the “big players” (such as Facebook, LinkedIn and Twitter) are doing in their mobile app development.

Screenshot

Performance, Distribution and Facebook on HTML5

On the Future of Mobile Web Apps, Simon Cross

Simon looks at Facebook’s experience with and investment in the mobile Web, the issues affecting mobile Web developers and what Facebook and the industry are doing to push the mobile Web forward. Mark Zuckerberg’s comments on HTML5 were undoubtedly one of the most discussed topics in mobile this year, and I personally found these slides a good summary of Facebook’s current take on what works and what still requires improvement.

Screenshot

Tools for Mobile Debugging

Mobile Debugging, Remy Sharp

Debugging Web apps on mobile devices can be a genuine pain. Luckily, a number of tools are available today to ease the process. From remote debuggers to cross-device consoles, this talk summarizes the current state of debugging for mobile, going into more depth on debugging than Pete’s talk from earlier in the post.

Screenshot

Responsive Design Techniques

Responsive Web Design: Clever Tips and Techniques, Vitaly Friedman

Responsive Web design challenges designers to apply a new mindset to their design processes and to the techniques they use in design and coding. This talk (by Smashing Magazine’s own Vitaly Friedman) provides an overview of various practical techniques, tips and tricks that you might want to be aware of when working on a new responsive design project.

Screenshot

Web Apps

Offline Web Apps

Offline Rules, Andrew Betts (Video)

In the last couple of years, a deluge of new offline storage technologies have appeared. In this talk, Andrew looks at why they are all excellent and rubbish at the same time and why you need to use all of them, and he walks through techniques to consider when building a Web application that can load and function with no network connectivity.

But making use of client-side storage is necessary not only in order to make an app that works offline, but it can also hugely improve the experience of your website when the user actually does have connectivity.

Screenshot

State of the Art

Building Web Apps of the Future: Tomorrow, Today and Yesterday, Paul Kinlan (Audio)

The browser is an amazing runtime that can already deliver amazing apps. Paul dives into the technologies that will help you deliver Web apps that will blow your users’ socks off now and in the future.

Screenshot

Client-Side Storage

Storage in the Browser, Andrew Betts

Installed native applications can use all the space they want, but in the browser we’re much more limited. This talk explores how to make the best use of the storage technologies available to Web apps, comparing the virtues of different packaging and encoding techniques, and covering simple forms of in-browser compression that can yield surprising results.

As more apps are developed to surf over network turbulence, and to work even when completely disconnected from the network, local storage becomes ever more important.

Screenshot

Application Cache

Application Cache: Douchebag, Jake Archibald (Video)

The Application Cache is one of the cool bits of HTML5. It allows websites to work without a network connection, and it brings us much closer to native app-like behavior. However, from roundup articles and talks about HTML5, you might be left with the impression that it’s a magic bullet. Unfortunately, it isn’t; the Application Cache is, as Jake famously puts it, a douchebag.

In this talk, he looks at how to use the features of Application Cache without the horrible side effects, comparing techniques that you’d use for both a simple client-side app and a large content-driven website. He explores the many gotchas left out of most articles about Application Cache and discusses how to build your website to survive them.

Screenshot

Performance

CSS

High-Performance CSS, Paul Irish

Paul dives into the tools available in and outside of the browser to assess the performance of your CSS. Find out what’s slow (is box-shadow causing paints to be 70 milliseconds longer?) and how to fix it. Learn about about:tracing, CSS profiling and speed tracer, and get a better understanding of the browser’s internals in the process.

Screenshot

There’s also Jon Rohan’s talk about some problems related to CSS performance that were solved at GitHub. Recommended reading.

GitHub’s CSS Performance, Jon Rohan

Screenshot

Avoiding Jank

Jank-Free: In Pursuit of Smooth Web Apps, Tom Wiltzius

Building beautiful experiences on the mobile Web takes more than a good designer and fancy CSS: performance is critical for a Web app to feel fluid. Smooth animation that never drops a frame can give your app a native feel. But when animations stutter, effects lag or pages scroll slowly, we call that “jank.” This talk is about identifying jank and getting rid of it.

Screenshot

Web

Building Faster Websites, Ilya Grigorik

In this comprehensive crash course, Ilya Grigorik shares some really juicy tips on how to make the Web faster, including Google’s findings on what slows down people’s Web experience and how Chrome and other services have improved it. If you’re an engineer looking to improve the performance of your websites or apps, this talk comes highly recommended.

Screenshot

JavaScript

Breaking the JavaScript Speed Limit With V8, Daniel Clifford

Are you interested in making JavaScript run blazingly fast? If so, this talk looks at V8 under the hood to help you identify how to optimize your JavaScript. Daniel shows you how to leverage V8’s sampling profiler to eliminate performance bottlenecks and optimize JavaScript programs. He also exposes how V8 uses hidden classes and runtime-type feedback to generate efficient JIT code. A very interesting talk for performance junkies.

Screenshot

Note: Some of the optimizations mentioned in this talk are specific to V8 and may not apply to other JavaScript engines. I wrote about how to write memory-efficient JavaScript on Smashing Magazine recently, in case you’re interested in exploring the topic further.

Testing

Understanding Code Smells

Why Our Code Smells, Brandon Keepers (Video)

Odors exist for a reason, and they are usually trying to tell us something. If our code smells, it might be trying to tell us what is wrong.

Does a test case require an abundance of setting up? Maybe the code being tested is doing too much, or it is not isolated enough for the test? Does an object have an abundance of instance variables? Maybe it should be split into multiple objects? Is a view brittle? Maybe it is too tightly coupled to a model, or maybe the logic needs to be abstracted into an object that can be tested?

In this talk, Brandon walks through code from projects that he works on every day, looking for smells that indicate problems, understanding why the smells are there, what the smells are trying to tell us, and how to refactor them.

Screenshot

Current State of the Art

JavaScript Testing: The Holy Grail, Adam Hawkins (Video)

Adam talks about this Holy Grail for JavaScript developers: getting a test suite up and running fast and having multiple browsers execute the tests. Getting the Holy Grail is difficult, though, even though several tools have been created in the past in attempts to solve this problem.

Barriers to entries are everywhere. How easy is it to get going testing small parts of JavaScript functionality? What happens as your become bigger and more complex? What about headless testing? Does this process scale up to CI? Can you even do this stuff locally?

A myriad of testing tools and solutions are available, and Adam shows what’s out there and what we as a community need to do next to get the Holy Grail, to ensure a better Web experience for everyone.

Screenshot

Tip: One tool for testing that I’m loving at the moment is Testling-CI, which runs browser tests on every push.

Improving the Testability of Your Code

Writing Testable JavaScript, Rebecca Murphey (Audio)

It’s one thing to write the code that you need to write to get something working; quite another to write the code that you need to write to prove that it works — and to prove that it will continue to work as you refactor and add new features.

In her talk, Rebecca looks at what it means to write testable JavaScript code.

Screenshot

Conclusion

Time spent thinking about (and developing) your craft is time well spent. The more honed your skills are, the more opportunity you will have to become an efficient engineer.

While this list doesn’t cover every excellent talk presented this year, it hopefully offers some direction for you to accentuate your skills. Do consider reading through a few of them. Focused reading in this way will add to your value as a craftsperson and hopefully improve your daily development workflow.

With that, do enjoy the holiday season and have a fantastic new year.

(al)

© Addy Osmani for Smashing Magazine, 2012.

0
Your rating: None

  

Most apps fail. This cruel reality has led many disillusioned developers to conclude, often subconsciously, that succeeding on the App Store is like striking it rich in the gold rush: you just need to get lucky.

The App Success Formula.

The idea of luck is a dangerous sedative to ease the pain of failure. Pain is a good thing. It shows something is wrong. If my app fails, I want to know why. Instead of blaming forces beyond our control, why not look at what folks like tap tap tap and Tapbots are doing to succeed again and again and again.

While applying this formula flawlessly is nearly impossible, working towards it will dramatically increase your chances of success. These concepts are based on the iOS platform, but many of the principles apply to other platforms as well.

Idea

Any successful app rests on the foundation of a solid idea, because the idea determines the ultimate potential of the execution. Avoid the temptation of jumping straight into execution after having an epiphany in the shower. A little bit of research up front can save you a lot of pain down the road.

Find a Vacuum

Vacuum

Phill Ryu (@phillryu) has an impressively consistent track record of top apps: Clear, The Heist and Classics, to name a few. His secret for validating ideas is pretty simple: find a vacuum. The App Store houses a plethora of quality, user experience and innovation vacuums. Vacuums are cool because they inherently want to be filled. A few examples:

Clear, Tweetbot and iTranslate Voice.
Clear, Tweetbot and iTranslate Voice.

Clear: among thousands of to-do apps, Clear filled a user interface (UI) innovation vacuum. Entering a crowded category seems counter-intuitive, but the biggest categories provide the biggest opportunities if you can innovate within them.

Tweetbot: Twitter bought Tweetie and dumbed it down to appeal to the masses. Tweetbot filled the Twitter power user vacuum.

iTranslate Voice: The release of Siri intrigued the world, instantly generating a vacuum for apps like iTranslate Voice that behaved like Siri but offered different functionality. Every new technology introduces a new vacuum along with it.

For sure, the low-hanging fruit is gone, but there are still tons of vacuums out there, particularly in the design department. Find a vacuum that you are passionate about and fill it.

Show Me the Money

Most apps don’t make money. If revenue is important to you, it is worth exploring what kind of apps make money and what kind of apps don’t. Building on Marco Arment’s theory of two app stores, I postulate that three categories of apps make money, and one category doesn’t.

Apps can be divided into categories by profit per user and number of downloads.
Apps can be divided into categories by profit per user and number of downloads. Large view.

Hit Apps:

  • High volume, low price;
  • Appeal to almost everybody, targeting impulse purchasers who browse the top charts and featured lists;
  • Huge launches based on intense marketing campaigns;
  • Require tens of thousands, if not hundreds of thousands of downloads to generate significant profit.

Examples: Clear ($3) and iTranslate ($1).

Premium Niche Apps:

  • Low volume, high price;
  • Target a serious niche;
  • Users find the app through thorough research and are willing to pay big bucks to improve their lives;
  • A large profit per user makes traditional customer acquisition methods (i.e. pay-per-click ads) viable and scalable.

Examples: OmniFocus ($10) and Proloquo2Go ($190).

Premium Hit Apps:

  • High volume and high profit per user;
  • The only viable space for funded startups that need to turn a big profit;
  • Rare but rewarding.

Examples: TomTom GPS ($50), Pandora (monthly $3.99 subscription) and freemium games that make a huge average profit per user through addictive add-ons and credits.

Most Apps Fail:

  • Low volume and low profit per user;
  • Even if such an app garners some attention, the limited appeal and low price limit significant success.

Developers read inspiring stories of app millionaires, look at the astounding number of devices being sold every day and develop grossly optimistic back-of-the-napkin download projections for their relatively niche apps. They conclude that if they could only capture a fraction of a percent of the market, they could sell their app at $0.99 and make a fortune.

It just doesn’t work that way. The brutal reality kicks in when the first day of sales generates six downloads, mostly from friends and family. The app idea might have scratched their itch, but it was just too niche to be a hit.

Your app idea probably falls into this category. Don’t ignore this.

Building an app that makes money is hard. David Barnard, the brilliant mind behind App Cubby, suggests that the future of sustainable revenues may lie in true freemium, scaling the cost with the value derived. Generate lots of downloads and creatively find ways to let users who find more value pay more for it. These kinds of creative monetization ideas are relatively untested for non-game apps, but that’s what makes this industry so exciting.

Make a Statement

No, I mean, literally, write something down. Whittle your idea down to its core and create one sentence that defines your app and its target market. Apple does this for their internal apps and you should do it too.

For example:

“Grades shows college students what score they need to aim for on their next exam.”

If you cannot explain the basic value of your idea in one sentence, it’s too complex. Mobile apps need to focus on doing one task extremely well, because your target market must instantly desire your app after seeing one screenshot.

After defining the app’s core, check every feature idea against this core and remove the cruft.

Design

Apple’s culture revolves around design excellence. It’s no coincidence the apps Apple showcases are always well designed. Design is the most critical component in building a successful app.

Don’t Make Me Think

Like websites, apps are incredibly disposable. If an app doesn’t make sense immediately, users feel little pain in deleting it. The title of Steve Krug’s popular book encapsulates our task as usability designers: don’t make me think. Like a well-designed doorknob, the interface itself implicitly explains its own use and value.

A few points to that end:

Kill the Baby
Every cool feature idea inevitably adds complexity to the app. Strip the app, the screens and even the elements within each screen to their essence. Good design is more about saying no to good ideas than it is about generating them.

The to-do list app on the left let cool features get in the way of the core experience.<br /><br />
Clear (right) questioned everything and only the essence survived.
The to-do list app on the left let cool features get in the way of the core experience.
Clear (right) questioned everything and only the essence survived.

Consider UI Conventions
Users have certain expectations about how the UI on their devices should behave based on the conventions they see in the operating system and the primary apps they use every day. Pay attention to the UI guidelines (iOS Human Interface Guidelines, Android User Interface Guidelines) and be sure to understand a convention before ignoring it.

In an attempt to look unique, the grade input interface on the left neglects basic navigation conventions. A similar screen from my app, Grades, applies a unique skin to familiar iOS interface conventions.
In an attempt to look unique, the grade input interface on the left neglects basic navigation conventions. A similar screen from my app, Grades, applies a unique skin to familiar iOS interface conventions.

Think Like a Human
Users have models in their head about the way the world works. Don’t design according to your database or programming limitations, but according to how the user thinks about things.

RedLaser’s scanning interface initially required users to take a picture of the barcode they were interested in (left). The app went viral when they changed the interface to match how a real barcode scanner works. Hover, beep, you're done (right).
RedLaser’s scanning interface initially required users to take a picture of the barcode they were interested in (left). The app went viral when they changed the interface to match how a real barcode scanner works. Hover, beep, you’re done (right).

Don’t Make Me Work
Users are lazy. They don’t want to read instructions and they hate typing. The best apps figure out the absolute minimum the user needs to do for the app to function.

TripIt is great but the opening screen offers little motivation for users to sign up. If an app works without an account, let users explore the app and sign up later; otherwise provide an appealing walkthrough to entice users to sign up like TuneWiki.
TripIt (left) is great but the opening screen offers little motivation for users to sign up. If an app works without an account, let users explore the app and sign up later; otherwise provide an appealing walkthrough to entice users to sign up like TuneWiki (right).

Do Usability Testing
Don’t let eye scanning and focus groups intimidate you. Do whatever you can! Most basic usability problems surface by simply getting the interface in front of some potential users. Ask a few questions (“what do you think this app does? How might you do X task?”), and watch them. Do it early and often throughout the entire design and development process.

Get Emotional

The sliding pane opening animation in Weightbot, the humorous copy in Everyday, the satisfying ascending charms when you check off items in Clear; though offering little utility, these tiny details elicit a powerful emotional response. These apps exhibit a personality. You either love them or you hate them, but you definitely don’t forget them and you are much more likely to share them.

Usable isn’t good enough any more. The best apps go the extra thousand miles to pay attention to the details that make an app enjoyable. Simon Schmid wrote a thorough treatment on emotional design, but here are some basic points relating to apps.

Visuals Matter
Beautiful apps sell better, are more enjoyable to use and feel more valuable than bland apps. Though beauty can be found in rich gradients, textures and shadows, strive for the subtler attributes of elegance, readability and tasteful layout. Use skeuomorphism (UI that mimics physical objects) only where it enriches the experience and doesn’t distract from it. If you’re unfamiliar with basic graphic design principles, The Non-Designer’s Design Book by Robin Williams is a great place to start.

Paper for iPad by Fifty Three.
Paper for iPad by Fifty Three.

Experiment With Sound
Sound in a UI is a delicate, powerful and largely unexplored tool. Experiment to see if sounds can improve your app.

Tapbots’ apps beep, click and buzz just like you would expect from robotic controls.
Tapbots’ apps beep, click and buzz just like you would expect from robotic controls.

Touch Is Magic
Apple’s engineers don’t stop working until their products feel right. It’s why the first iPhone’s bouncy scrolling “scrolls like butter.” If an object doesn’t respond immediately to the touch, it reminds you that you are using a computer and not actually directly manipulating the object.

All pictures and objects in Our Choice can be directly manipulated with your fingers.
All pictures and objects in Our Choice can be directly manipulated with your fingers.

Gestures can provide a powerful connection between the interface and the user but can also be frustratingly undiscoverable if not implemented correctly. Experiment with new interactions and don’t stop working until every interaction, transition and metaphor makes sense and feels right.

Spice Up Your Words
Users generally dislike instructional copy, error messages and notifications. Why not make their day by writing quirky, witty or maybe even humorous copy! Users will appreciate the unexpected pleasure.

In my latest app, Languages, a witty error message not only softened the blow of a download error, but made people want to tweet about the experience.
In my latest app, Languages, a witty error message not only softened the blow of a download error, but made people want to tweet about the experience.

Animate With Class
Whether it’s elements moving on the screen or transitions between screens, animation can express personality and give users a sense of continuity and polish as they navigate the app.

Users opening Weightbot for the first time enjoy watching the bot unlocking itself.
Users opening Weightbot for the first time enjoy watching the bot unlocking itself.

Don’t Neglect Your Icon
The icon is most people’s first impression of your app. It also occupies a space on users’ precious home screen. The best icons are simple but memorable; they stand out without being garish. The icon should look beautiful at large sizes, yet iconic enough to be recognized within an app folder on the home screen.

Clear’s icon stands out using a bright color scheme and one simple shape. The icon on the right has too many conflicting colors and shapes to be recognizable or attractive.
Clear’s icon (left) stands out using a bright color scheme and one simple shape. The icon on the right has too many conflicting colors and shapes to be recognizable or attractive.

Programming

Your technical choices influence the experience of the app, and thus, its success on the App Store.

Go Native

The “build once, deploy everywhere” method is a terrific recipe for mediocre apps.

To start, the method itself is a myth. Different operating systems have different UI conventions and patterns. With the exception of games where a custom interface is desired, one interface that deploys to all platforms results in a foreign experience on each platform.

Facebook tried HTML5 for years. When they recently switched to native code, they were able to improve performance by 200% and increase their average user rating from two stars to four stars.
Facebook tried HTML5 for years. When they recently switched to native code, they were able to improve performance by 200% and increase their average user rating from two stars to four stars.

At very best, we can build once and optimize everywhere. Apps like Zipcar have successfully used this approach. Unfortunately, Zipcar is an exception to the rule of suboptimal apps built using this approach. There are a few reasons for this.

  • Build once, optimize everywhere encourages a bottom-up design approach where the programming heavily constrains the design of the app. It stifles design innovation by tempting you to cut corners in order to satisfy the lowest common denominator.
  • Technologies like PhoneGap essentially turn your app into a browser window that runs JavaScript code. Avoid these. JavaScript apps tend to feel slow, choppy, unnatural and error-ridden because JavaScript just isn’t ready to match native experiences.
  • Tools like Appcelerator compile native code. These perform much better but still lack the flexibility and robustness of pure native code. Since you do not have direct access to the code that is running on the phone, errors can be more difficult to locate and squash. They can also make it difficult to implement new technologies right away, giving you a disadvantage against competitors who can tie into new technologies from the day they are announced.
  • The bottom line: choose your technology based on the design, not your design based on your technology. Design your apps for the various platforms first. Then see if something like Appcelerator is capable of executing those designs without compromise.

For an in-depth view of cross-platform trade-offs, read Aral Balkan’s comprehensive treatment on the subject.

Code Quality Matters

While perfectly-formed, well-documented code does not directly affect the user, it certainly affects your ability to push out timely, robust updates, something that can be critical to continued success.

In addition, laggy, bug-ridden code definitely affects the user. The user doesn’t care if there is a good reason why the app crashed or deleted their data — it’s still the brand’s fault. I have seen cases where this alone has stolen the thunder out of the launch of otherwise promising apps.

Hourly rates can be deceiving. In the time it takes a poor coder to build one component sloppily, a quality coder can build three components robustly. If you decide you don’t like the poor coder, a new coder will most likely have to start from scratch because the legacy code only makes sense to its author. On the other hand, quality code can be reused and built upon easily.

Marketing

If you have a marketing department, good for you, but grassroots marketing by a developer or a designer can often be even more effective. Believe me, when I started, my name didn’t mean anything to anybody that mattered. Now my work has been featured by Apple, Mashable, TechCrunch, The Huffington Post, Fox News and dozens more. All this without spending a dime on marketing, aside from a few website costs.

Start Early

Many developers think of marketing as something to do after an app launches. Nothing could be further from the truth.

A huge launch is critical, especially for inexpensive apps. If your launch does not propel your app into the top charts, the app will most likely fade into oblivion almost instantly amidst the thousands of apps launching every week. An app that is not on a top chart is nearly invisible to most consumers.

After the launch, a review here and there doesn’t help much to propel your app up the charts. It’s just the way the App Store rankings work. Ranking algorithms constantly change but they are roughly based on sales in a window of time, say four days, weighted towards the latest day. This means that marketing you do today will not affect your ranking a week from now, making fragmented press all but worthless. Only concentrated marketing blasts work. The launch constitutes your number one chance to show your app to the world in a concentrated way.

With this in view, App Savvy author Ken Yarmosh characterizes the marketing of apps as a crescendo. Marketing an app should start at the very beginning and continually develop as it consummates in a huge launch blast.

Make Friends

Connections are everything. They power your marketing machine. No connections means no warm doors, and, with thousands of apps vying for press attention every week, a warm door is gold.

I have created Twitter lists of Apple employees, members of the press and remarkable iOS developers to help me find opportunities to connect. Feel free to use them!
I have created Twitter lists of Apple employees, members of the press and remarkable iOS developers to help me find opportunities to connect. Feel free to use them!

Connect With Apple Employees, Tech Writers and Influential Designers and Developers in the Community
Realize that actual human beings run companies like Apple, TechCrunch and tap tap tap. A lot of these people are really cool and love to meet and promote people with great products and ideas. Make a list of people to connect with and actively seek opportunities to do so.

Go Where They Are

  • Twitter is a good place to start — nearly every influencer in the tech industry tweets.
  • Commenting on influential blogs or emailing the author can be a great way to initiate contact.
  • Face-to-face connections are the most powerful, so be sure to hit up the Apple Worldwide Developers Conference (WWDC) and other conferences that the Apple community tends to congregate at. Local meetups are also a great place to meet people.

Be Cool, Don’t Spam
Just because you get the opportunity to talk to someone doesn’t mean they are instantly interested in your pitch. Build a meaningful connection first. Then they’ll be asking you what cool things you’re up to. When you do show off some work, do it in the way of seeking advice and feedback rather than pitching. It comes off better and often elicits great feedback.

Give and You Shall Receive
Build meaningful connections with people by getting into their mind and thinking about their needs and wants. Maybe an influential person asks a technical question on Twitter that you know the answer to, or writes a post you have thoughts on. Be sure to respond! Do this a few times and they might just notice. Finally, remember that people have egos — be sure to let them know when you appreciate their work.

Post Interesting Stuff
Link to insightful articles and maybe even write your own blog with the things you learn about. People love to read honest journaling and analysis of apps. Websites like iDevBlogADay promote your articles to the community.

Build Buzz

You don’t want your launch to fall flat, so a few weeks before launch, start revving up the hype machine. The idea is to build up a fan base who will be the first to download your app on launch day.

Teaser websites like this one can help build anticipation and collect email addresses.
Teaser websites like this one can help build anticipation and collect email addresses. Large view.

  • Set up Twitter and Facebook accounts for your app. This gives potential fans an easy way to follow and mention your app. Use the account to post sneak peeks, updates on progress and contests. You can even use the account to follow people you think might be interested in the app. They’ll see you’re following them and might even check the app out.
  • Build a teaser website with a form to sign up to your mailing list. Include something to entice people — an attractive Web design, a beautiful screenshot and maybe even a video.
  • Create a video. Nothing builds buzz like a well-done video. The buzz behind the Clear video exemplifies that. It’s also an easy way to show the press what your app is all about.
  • Run a private beta. Your beta testers will be your biggest fans going into launch because they feel invested in the development of the app.

Get Featured

After winning an Apple Design Award, my app was featured in nearly every tech publication I had ever hoped for, but all that press combined generated fewer downloads than when Apple featured it.

So how does one get featured by Apple? Thousands of apps come out every week, and only a select few find a place on the App Store homepage.

Only a small number of apps are featured on the Apple App Store homepage.
Only a small number of apps are featured on the Apple App Store homepage.

First, the app has to be “featureable.” It must interest Apple in some way. Does it have a polished design? Does it show off the Apple platform? Is it something you cannot find on other platforms? Any of these characteristics boost your chances. The good news is that out of the thousands of apps coming out, very few feature the kind of design discussed here, making it relatively easy to stand out.

Second, you need to get Apple’s attention. Making connections within Apple can be invaluable. As a general rule, though, you need to make your own splash before Apple will make you a bigger one. Apple has an editorial team. They find apps to feature. You need to get to the places they are looking. Based on my experiences, they probably look at new apps that are “charting” — moving up the charts. For that, you need to generate a good number of launch-day sales. It takes at least a few hundred sales to chart in most categories. Besides that, think of the places you might go to find new quality apps; they probably visit the same websites.

Pitch the Press

Press reviews help establish credibility, an initial stream of downloads and visibility to influential people or Apple employees. Seek press attention at least a week or two before launch — these people are busy and you want to try to have reviews lined up to publish on launch day.

Getting the press to review your app is an important part of a good marketing strategy.
Getting the press to review your app is an important part of a good marketing strategy.

This is the part where you contact all those really great friends you’ve made within the press and tech community, giving them a sneak peek of your app and asking if they want to hear more.

After exhausting your warm doors, start cold calling. Have a story, keep it short, make it personal and don’t forget to follow up.

Build a Fan Base

The most powerful app company is one with a fan base. Sonico Mobile, a partner on our latest app, Languages, recently released an app called iTranslate Voice. The app became an instant #1 hit with very little promotion from the press or Apple. How? Sonico advertised iTranslate Voice to their 30 million strong iTranslate user base and sent out an email to their massive mailing list.

All of Sonico's apps allow users to easily follow the company on Twitter or subscribe to their mailing list.
All of Sonico’s apps allow users to easily follow the company on Twitter or subscribe to their mailing list.

A fan base takes time to develop. Be sure to make it easy for fans to join your mailing list, like your Facebook page and follow your Twitter account. In addition, consider a mass-market free app as part of a strategy to gain millions of fans. Ad bartering services like Swappit allow you to build up ad impression credits and use them all at once on a big launch.

Conclusion

Success is measured in different ways. The first version of Grades made less than $10,000, but it was a stepping-stone to an Apple Design Award, and dozens of invaluable connections. Now our company is positioned to launch top-selling apps like Languages, which is more than making up for Grades pecuniary issues.

Monetary success is hard, but it gets easier as you go. As you consistently produce quality apps, your brand becomes recognized by the press and Apple, your team gains critical hands-on experience and you develop a fan base. This is definitely a long-term game, but the payoff can be incredible. It’s a great feeling to know that millions of people are enjoying the fruit of your hard work. Learn the lessons, don’t compromise and make a dent in the universe.

(cp)

© Jeremy Olson for Smashing Magazine, 2012.

0
Your rating: None

  

Mobile users and mobile usage are growing. With more users doing more on mobile, the spotlight is on how to improve the individual elements that together create the mobile user experience.

The mobile user experience encompasses the user’s perceptions and feelings before, during and after their interaction with your mobile presence — be it through a browser or an app — using a mobile device that could lie anywhere on the continuum from low-end feature phone to high-definition tablet.

Creating mobile user experiences that delight users forces us to rethink a lot of what we have taken for granted so far with desktop design. It is complicated in part by mobile-specific considerations that go hand in hand with small screens, wide variations in device features, constraints in usage and connectivity, and the hard-to-identify-but-ever-changing mobile context.

Dissecting the mobile user experience into its key components gives us a conceptual framework for building and evaluating good mobile experiences, within the context of a user-centered approach to designing for mobile. These components shape the mobile user experience — including functionality, context, user input, content and marketing, among others.

The elements of mobile user experience

The relevance of these elements will change depending on the type of device (feature phone versus smartphone versus tablet) and the presentation interface (app versus Web). This article briefly describes each of these elements and elaborates on each with selected guidelines.

Functionality

This has to do with tools and features that enable users to complete tasks and achieve their goals.

Guidelines

  • Prioritize and present core features from other channels that have especial relevance in a mobile environment. For an airline, this includes flight statuses and flight check-ins. For cosmetic chain Sephora, it includes supporting in-store shopping via easy access to product reviews on mobile devices.
  • Offer relevant mobile-only functionality (like barcode scanning and image recognition), and enhance functionality using the capabilities of mobile devices where possible to engage and delight users. Old Navy’s app serves up surprise games or savings when users snap the logo in a store.
  • Ensure that fundamental features and content are optimized for mobile. For example, make sure the store locator shows the nearest stores based on the device’s location, and make the phone numbers click-to-call.
  • Include features that are relevant to the business category. For retail websites and apps, this would include product search, order status and shopping cart.
  • Offer key capabilities across all channels. Users who sign in should see their personalized settings, irrespective of the device or channel being used. If certain functionality is not offered on mobile, then direct users to the appropriate channel, as TripIt does to set up a personal network.

    TripIt directs users to the website for setting up a network

Additional Reading

Information Architecture

This has to do with arranging the functionality and content into a logical structure to help users find information and complete tasks. This includes navigation, search and labeling.

Guidelines

  • Present links to the main features and content on the landing page, prioritized according to the user’s needs. Mobile Design Pattern Gallery has examples of primary and secondary navigation patterns for mobile, many of which are vertical instead of horizontal as on desktop websites.
  • Enable mobile users to navigate to the most important content and functionality in as few taps or key presses as possible. Navigation optimized for small screens is usually broad and shallow instead of deep. While three clicks (or taps) is not the magic number, users need to be able to recognize that each tap is helping them complete their task. Every additional level also means more taps, more waiting for a page to load and more bandwidth consumed.
  • Address the navigation needs of both touchscreen and non-touchscreen users. When designing for touch, make sure the tap size of the navigation item is at least 30 pixels wide or tall. Provide keypad shortcuts for feature phones, so that users can enter, say, a number (0 to 9) to quickly access a link:

    Cater to feature phone users, as CNN does with access keys, not as Delta does by making the first action to be nine key presses downs
    Cater to feature phone users, as CNN does with access keys (left), not as Delta does by making the first action to be nine key presses downs (middle and right).

  • Provide navigational cues to let users know where they are, how to get back and how to jump back to the start. Mobile breadcrumbs are often implemented by replacing the “Back” button with a label showing users the section or category that they came from. For mobile websites, use standard conventions, such as a home icon that links back to the start screen, especially when navigation is not repeated on every screen.
  • Use concise, clear, consistent and descriptive labels for navigation items and links. While always a good practice, it becomes even more important on tiny mobile devices.

Additional Reading

Content

Otherwise known as “the stuff on your website” (as Lou Rosenfeld and Peter Morville refer to it in Information Architecture for the World Wide Web), content is the various types of material in different formats, such as text, images and video, that provide information to the user.

Guidelines

  • Present an appropriate and balanced mix of content to users (product information, social content, instructional and support content, marketing content).
  • Use multimedia when it supports the user’s tasks in a mobile context, adds value to the content or supports the goals of the website. Most of the time, multimedia content is best provided when the user is looking for distraction or entertainment (such as news or funny clips) or when it has instructional value (for example, how to use an app or new feature).
  • Always give the user control over multimedia content by not auto-starting video or sound, by allowing the user to skip or stop multimedia content and by being mindful of the bandwidth it takes up.
  • Ensure that content is mobile appropriate. Just as we had chunking guidelines when going from print to Web, copy should be written for shorter attention spans on mobile devices. Optimize images and media for the device; this means scaling down for smaller devices and making sure images are sharp enough for the new iPad.
  • Ensure that primary content is presented in a format supported on the target device. Even now, websites such as Volkswagen’s ask iOS users to download Flash.

    VW asks iPad users to download an unsupported Flash plugin

Additional Reading

Design

This has to do with the visual presentation and interactive experience of mobile, including graphic design, branding and layout.

Guidelines

  • Remember the sayings “Mobilize, don’t miniaturize” (popularized by Barbara Ballard) and “Don’t shrink, rethink” (of Nokia). Both make the point that mobile design should not just rehash the desktop design.
  • Design for glanceability and quick scanning. Glanceability refers to how quickly and easily the visual design conveys information.
  • Maintain visual consistency with other touchpoints and experiences (mobile, app, Web, print and real world) through the use of color, typography and personality. Identifying Amazon in the stack below is easy even though the brand name is not visible.

    Amazon's visual design is easily recognizable

  • Guide users from the initial and most prominent element of the design to other elements to help them complete their tasks. This is known as visual flow. A good design brings together visual elements as well as information architecture, content and functionality to convey the brand’s identity and guide the user.
  • Consider both portrait and landscape orientations in the design process. Devices increasingly support multiple orientations and automatically adjust to match their physical orientation. Maintain the user’s location on the page when they change orientation. Indicate additional or different functionality in the new orientation if applicable, as shown by ING:

    The ING app informs users about additional features in the landscape mode

Additional Reading

User Input

This has to do with the effort required to enter data, which should be minimized on mobile devices and not require the use of both hands.

Guidelines

  • Limit input to essential fields. Or, as Luke Wroblewski says in his book Mobile First, “When it comes to mobile forms, be brutally efficient and trim, trim, trim.” Limit registration forms to the minimum fields required, and use shorter alternatives where possible, such as a ZIP code instead of city and state. My favorite offender of this guideline is Volkswagen’s form to schedule a test drive; the mobile form has more required fields than the desktop version (the extra fields are highlighted below):

    Volkswagen's mobile form to schedule a test drive is more tedious than the desktop version

  • Display default values wherever possible. This could be the last item selected by the user (such as an airport or train station) or the most frequently selected item (such as today’s date when checking a flight’s status):

    United and NJ Transit use defaults to simplify user input

  • Offer alternate input mechanisms based on the device’s capabilities where possible. Apps take advantage of quite a few input mechanisms built into devices, including motion, camera, gyroscope and voice, but mobile websites are just starting to use some of these features, particularly geolocation.
  • Use the appropriate input mechanism and display the appropriate touch keyboard to save users from having to navigate their keyboard screens to enter data. Keep in mind that inputting data is more tedious on feature phones that have only a numeric keypad. For non-sensitive applications, allow users to stay signed in on their mobile device; and save information such as email address and user name because mobile phones tend to be personal devices, unlike tablets, which tend to be shared between multiple people.

    Use appropriate keyboard; examples from the iOS Developer Library

  • Consider offering auto-completion, spellcheck suggestions and prediction technology to reduce the effort required to input data and to reduce errors — with the ability to revert as needed. Disable features such as CAPTCHA where not appropriate.

Additional Reading

Mobile Context

A mobile device can be used at anytime, anywhere. The mobile context is about the environment and circumstances of usage — anything that affects the interaction between the user and the interface, which is especially important for mobile because the context can change constantly and rapidly. While we often focus on distractions, multitasking, motion, low lighting conditions and poor connectivity, it also includes the other extreme — think using a tablet in a relaxed setting over a fast Wi-Fi connection.

 The Context of Mobile Interaction
The Context of Mobile Interaction,” Nadav Savio

Guidelines

  • Use device features and capabilities to anticipate and support the user’s context of use. The iCookbook app allows users to walk through a recipe using voice commands — a nice feature when your hands are covered in batter!
  • Accommodate for changes in context based on the time of day and when the user is using the app. The Navfree GPS app automatically switches from day to night mode, showing low-glare maps for safer nighttime driving.

    GPS app sensing context

  • Use location to identify where the user is and to display relevant nearby content and offers. A Google search for “movies” on a mobile device brings up movies playing nearby and that day’s showtimes, with links to buy tickets online if available.
  • Leverage information that the user has provided, and respect their preferences and settings. After the first leg of a multi-leg flight, TripIt showed me the flight and gate information for my next flight, as well as how much time I had to kill. United’s app did no such thing, even though it knew much more about me. It could have shown me how to get from my current plane to the connecting flight and highlighted the location of the United Club along the way, where I could comfortably spend my two-hour wait, since it knew I was a member.
  • Default to the user experience most appropriate for the device (i.e. a mobile experience for small screens, and perhaps a desktop-like experience for tablets), but give users the option to have enhanced features. A big discussion on how to present this to the user recently took place, with Jakob Nielsen recommending a separate mobile website and Josh Clark arguing instead for a responsive design; yet others believe that Nielsen and Clark are both wrong.

Additional Reading

Usability

This is the overall measure of how well the information architecture, design, content and other elements work together to enable users to accomplish their goals.

Guidelines

  • Make it clear to the user what can be selected, tapped or swiped (this is known as affordance), especially on touchscreen devices. One of the big findings of Nielsen Norman Group’s usability studies of the iPad was that users didn’t know what was touchable or tappable. Another issue was swipe ambiguity: when the same swipe gesture means different things in different areas of a screen. Ensure that touchability is clear and that items such as links, icons and buttons are visibly tappable.
  • For touchscreen devices, ensure that touch targets are appropriately sized and well spaced to avoid selection errors. Also, place touch targets in the appropriate screen zones; for example, put destructive actions such as those for deletion in the “Reach” zone, as shown by Luke Wroblewski in his book Mobile First:

    Zones showing ease of access for right handed touch-screen use from Mobile First

  • Follow conventions and patterns to reduce the learning curve for users and to make the mobile experience more intuitive. Dedicated apps should follow platform-specific standards and guidelines. A comprehensive collection of links to official UI and UX guidelines is available in the article “UI Guidelines for Mobile and Tablet Web App Design” on Breaking the Mobile Web.
  • Ensure usability in variable conditions, including for daylight glare and changed angle of viewing and orientation, by paying attention to design elements like contrast, color, typography and font size.
  • Do not rely on technology that is not universally supported by your audience’s devices, including Java, JavaScript, cookies, Flash, frames, pop-ups and auto-refreshing. When opening new windows or transitioning from an app to the browser, warn users to avoid overwriting already open tabs.

Additional Reading

Trustworthiness

This relates to the level of confidence, trust and comfort that users feel when using a mobile website or app. According to a 2011 study by Truste and Harris Interactive, privacy and security are the top two concerns among smartphone users:

Privacy and security are the top two concerns among smartphone users

Guidelines

  • Do not collect or use personal information (such as location and contact list) from mobile devices without the explicit permission of the user. The first few months of this year have seen numerous reports of apps secretly copying smartphone address books, with watchdogs up in arms and users retaliating.
  • Make it easy for users to control how their personal information is shared in a mobile app by asking before collecting their location data and by allowing them to opt out of targeted advertising.
  • Clearly state your business practices (including for privacy, security and returns), and present them contextually (such as by displaying links to your privacy and security policies on the registration screen). The policies themselves should be accessible in a secondary section of the mobile user experience (such as the footer or a “More” tab). Reinforce credibility by displaying trusted badges, especially when users need to trust you with their personal or financial information.
  • Present policies appropriately on mobile devices by offering a concise summary and an option to email the entire policy. Privacy and security policies tend to be notoriously long and full of boring legalese that users often blindly click through to continue what they really want to do, so make it easy for users who are interested in the fine print.
  • Don’t break the user’s workflow when displaying legalese. Take them back to where they were before being interrupted, instead of making them start all over.

Additional Reading

Feedback

This has to do with the methods for attracting the user’s attention and displaying important information.

Guidelines

  • Minimize the number of alerts the app displays, and ensure that each alert offers critical information and useful choices. For a smile, look at Chris Crutchfield’s video on notification and alert overload.
  • Keep alerts brief and clear, explaining what caused the alert and what the user can do, along with clearly labeled buttons.
  • Notifications should be brief and informative, not interfere with anything the user is doing, and be easy to act on or dismiss.
  • Provide feedback and confirmation on screen without disrupting the user’s workflow.
  • If your app displays badges and status bar notifications, keep the badges updated and clear them only when the user has attended to the new information. Chase clears the notifications badge for its mobile app the moment the user visits the notification section, even before the user has seen which of their multiple accounts triggered the badge, forcing them to hunt through each account to see what triggered it.

Additional Reading

Help

This relates to the options, products and services that are available to assist the user in using the website or app.

Guidelines

  • Make it easy for users to access help and support options. Users commonly look for help in the footer of a mobile website and in the toolbar or tab bar of an app.
  • Offer multiple ways to get support, including options relevant in a mobile context, such as self-serve FAQs, live support via click-to-call, and near-real-time Direct Message tweets. Two financial service companies that actively offer support via Twitter are American Express and Citibank.
  • Present a quick introduction and short tutorial on using the app when it first launches, with options for the user to skip and view later.
  • When introducing new or unique functionality (such as when check depositing via mobile apps was first introduced), offer contextual help and tips to guide users the first time, and as a refresher for infrequently used functionality.
  • Offer help videos when appropriate, but allow the user to start, pause, stop and control the volume as they wish, and keep in mind the multimedia guidelines mentioned in the “Content” section above.

Additional Reading

Social

This relates to content and features that create a sense of social participation, that enable user interaction and that facilitate sharing on established social networks.

Guidelines

  • Create and maintain a presence on social networks (for example, a Facebook page) and local services (for example, a profile page on services such as Google Places, Bing Business Portal and Yahoo Local). These will be highlighted in search results and on location-based social networking services. In addition to your business’ name, include your physical address, phone number, URL and hours of operation.
  • Incorporate your social presence and activity into your website’s mobile experience by showing your recent activity and offering an easy way to follow or like you on these networks.
  • Integrate social networking features into your website’s mobile experience to make it easy for users to connect with their own social networks. This could be as simple as using APIs to enable social sharing, bookmarking, tagging, liking and commenting.
  • Invite users to generate content featuring your brand, product or service from their mobile device, offering some incentive in return. For example, the burger chain Red Robin could invite the user to share a picture of their child reading a school book at one of its locations to get a free milkshake.
  • Provide mobile offers that can be shared and go viral. American Express currently offers savings and discounts to users who sync their profiles on networks such as Facebook, Twitter and Foursquare to their credit card.
  • Apps that rely on social contributions from users should look at ways to seed content in a way that is useful and, eventually, self-sustaining. For example, the My TSA app has a user-contributed feature that shows the wait times at security checkpoints, but it often shows outdated information, even though airport staff post physical signs of wait times at some airports.

Additional Reading

Marketing

This has to do with the methods by which a user finds a website or app and the factors that encourage repeated usage.

Guidelines

  • Ensure findability by optimizing for mobile search and discovery, such as by keeping URLs short. If you have a separate mobile website, follow URL naming conventions (m.site.com or mobile.site.com). In mobile search results, provide quick access to location-based content (e.g. directions from one’s current location) and device-formatted options (e.g. click to call).

    Mobile optimized formatted information for UPS, but partially missing for Fedex
    Mobile-formatted information is optimized for UPS (left), but partially missing for FedEx (right).

  • “Quick response” (QR) codes should lead to a mobile-optimized landing page, instead of a traditional page that requires zooming or, worse still, to the website’s home page, from where the user has to hunt for information. As a side note, QR codes painted on buildings should be big and clear enough to be recognized and deciphered by mobile devices.
  • Email campaigns should include a link to view the message in a mobile-friendly format, which itself links to the relevant offer page formatted for mobile — unlike CVS/pharmacy, which takes users to its mobile home page.
  • Promote your app in other channels where possible (TV, print and in-store advertising), and offer incentives to download and use the app, usually in the form of discounts and savings. If your app has a price tag, attract users to buy it in an overcrowded market by offering a limited-time promotional price. Another option is to promote the app through the Free App A Day marketplace.
  • Prompt users to rate and review your app or to share it on social networks after they have used it, but give them the option to postpone or stop these prompts. This will not only generate word of mouth, but give you insight into what users like and don’t like about the app. “Taking Control of Your Reviews” by smalltech discusses the strategy of encouraging happy customers to post reviews and unhappy customers to email you feedback.

Additional Reading

Conclusion

Mobile user experience is still a developing field, and opportunities for improvement continue to emerge. We’ve presented an overview of the key elements of the mobile user experience, along with some guidelines to get started in each. Focusing on these individual elements will help us create great overall mobile user experiences for our users.

(al)

© Lyndon Cerejo for Smashing Magazine, 2012.

0
Your rating: None