Everyone is talking about mobile. Some e-commerce websites are venturing into it. Mobile commerce (also known as "m-commerce") has immense potential, exhibiting a 86% growth rate and hitting $25 billion in 2012 (set to reach $86 billion by 2016, according to eMarketer).

It’s also a whole new platform, with new interaction methods and usage contexts that introduce a host of limitations and pitfalls to watch out for when designing and running an m-commerce website. With few best practices yet established, m-commerce is, to a large degree, unchartered territory when it comes to actual implementation.

This is why we decided to invest the better part of a year at Baymard Institute to conduct A LARGE-SCALE USABILITY STUDY FOCUSING SPECIFICALLY ON M-COMMERCE (following the “think aloud” protocol). We set out to explore the entire mobile shopping experience, including users’ conceptual understanding of m-commerce websites and how users interact with form fields, category navigation, search, product pages, the checkout process, etc.

The 18 m-commerce websites that we tested were: 1-800-Flowers, Amazon, Avis, Best Buy, Buy.com, Coastal.com, Enterprise.com, Fandango, Foot Locker, FTD, GAP, H&M, Macy’s, REI, Southwest Airlines, Toys “R” Us, United Airlines, Walmart.

Despite testing the mobile websites of some of the largest e-commerce players in the world, our subjects ENCOUNTERED 1,000+ USABILITY-RELATED ISSUES DURING THE TESTING SESSIONS. These usability issues have been analyzed and distilled into 147 design recommendations in a report titled “M-Commerce Usability.” In this article, we’ll share 10 recommendations from that report with you.

While following some of the guidelines would improve the usability of desktop websites, too, there is a major difference in the severity of breaking them. Whereas these guidelines are largely “nice improvements” on desktop, they are among the “vital basics” to get right on an m-commerce website. Thus, most of these usability guidelines are not exclusive to mobile, but they are much more critical to get right in the m-commerce context.

1. MAKE THE HOME PAGE EASILY SCANNABLE ISSUE: _When users are not able to get an overview of the entire website by quickly scanning the home page, they will feel less confident with the website and often end up choosing the wrong path for their task._

70% of the test subjects scrolled up and down the entire page when first landing on a home page or a category list, in what most described as “getting an overview of my options.” These subjects WANTED TO SEE THEIR OPTIONS before deciding which to choose. Even when they knew how they wanted to find a given product, some subjects still chose to get an overview of the home page, presumably to get a better feel for the website on which they were going to shop. In some instances, when a subject found the category they were looking for, they continued to look through one or two other categories to get a better sense of the other options on the website.

_Most subjects scanned the whole home page to get an overview of their options and to better understand what they could do on a particular website. Here, one subject continued to explore the home page options, even after having found his desired navigation path of “category” → “men.”_

Therefore, making the home page easily scannable is important because this will be the first point of contact for a very large portion of your mobile visitors. This initial impression will have a significant impact on the types of products they expect your website to carry and, just as importantly, not carry. While “easily scannable” might sound a bit vague, three instances of “what not to do” became clear during testing.

Having Too Many Visual Elements Avoid the confusing eye path that results from placing multiple highly graphical elements that demand attention high up on the home page. This was the case on Macy’s, where approximately 60% of the first viewable part of the home page is plastered with highly graphical content, with at least eight different elements calling for attention:

_Multiple subjects were overwhelmed by Macy’s home page because it was very difficult to scan. As one subject expressed it, “I’m desperately trying to get an overview here. There’s so much crap being shoved at my face.” The right-hand image shows typical eye fixations._

This is not to say you cannot have graphics -- but limit their size if they are above the fold on the home page, and design them to have a clear eye path.

Not Showing The First Layer Of Categories Another mistake is unnecessarily hiding the category navigation. Some websites have a single “browse categories” option, which takes the user to a new page with the first layer of category choices. If you have a website where the user cannot browse with any method other than category and search (i.e. not by “brand” or “store” directly from the home page) and the number of main category options is of a somewhat manageable size, then this is an oversimplification. Instead, show the first level of category options directly on the home page so that users can start scanning the list immediately upon landing on the home page.

_On the left: On Coastal.com, all the category options are displayed directly on the home page, which not only allows direct access, but gives users an accurate idea of the types of products they can expect to find on the website. For stores with multiple ways of browsing the catalog (e.g. by both “category” and “brand”), displaying the category options directly on the home page might not be feasible. On the right: For stores with a very high number of first-layer categories (typically mass merchants), a curated list with the most popular options might prove to be a better option, because displaying all categories would impede scannability._

Moreover, DO NOT PRESENT THE CATEGORIES IN A DROP-DOWN DIALOG. Multiple subjects explicitly stated that they had to scroll through the entire list to choose the category in which they expected to find a particular product. The problem with a drop-down quickly became clear, then: because it takes up only 50% of the available screen, getting an overview of the available categories became needlessly difficult (see Best Buy below).

Because the gesture area is also only half the size, the subjects also had a much harder time accurately controlling the scrolling speed. Lastly, the drop-down interface element was confused with a filter selection by some subjects and not recognized as the main website category navigation.

_Do not follow the example of Best Buy, which does not have a category option in the main body of its home page content. Instead, a “three bars” icon takes the place of a category option in the page’s header. This not only requires all users to understand the meaning of the three bars icon, but also makes it impossible to get an overview of the store by scanning the home page. And, of course, using a drop-down to actually select a category is not ideal either._

Perfect Fold Alignment Finally, do not design your website to have perfect alignment or white space exactly at the fold. This happens on GAP’s website, where it is easy to doubt whether the home page contains more than a search field and a few graphics (i.e. no category navigation), because these home page elements align precisely with the viewport fold (on an iPhone at least).

_One subject, a bit surprised, asked, “This is it? This is the entire page?” believing this was GAP’s entire home page. When elements are spaced with pixel-perfection alignment around the viewport fold, users are more likely to misinterpret the top part as being the entire home page (in this case, missing out on the category navigation below)._

To indicate more content, simply align the elements so that some are only partly viewable within the viewport on the most popular mobile devices.

Therefore, WHEN DESIGNING A SCANNABLE HOME PAGE:

* Put very few (if any) very visually stimulating graphics above the fold on the home page, and make sure the ones that are there have a clear eye path so that the user can quickly get an overview. * Try to ensure that the fold (on the most popular mobile devices) partially cuts off some content, to indicate more options below. * Display navigation options on the home page as a list (not in a drop-down). * If you have only one category navigation type (such as “product type” or “department,” and not also “brand” or “store”), then show the first level of the category hierarchy directly on the home page either in full or, if there are too many options, as a curated and collapsed list of the most popular choices. * Only display highlighted or featured products below the search field and the category navigation options. 2. BE SENSITIVE TO PEOPLE’S FEAR OF LOSING THEIR DATA ISSUE: _Typing on mobile devices is clumsy, so users are constantly worried about losing their inputted data._

“Argh, no! Do I have to start over? Now I’m getting angry. Doesn’t it have my shit already?,” a subject moaned, referring to his previously typed address and credit-card information, which suddenly disappeared. “Now I’m leaving. This isn’t a serious store.”

Data persistence is not something to take lightly. Your users certainly don’t. Of course, the recommendation is simple: always persist the user’s data, which requires investing in solid technology, testing thoroughly, and storing inputted data temporarily on the user’s device (most mobile browsers support localStorage). In practice, of course, this is easier said than done, and numerous websites have failed miserably, to the great frustration of users.

Because users have already suffered through many horrible experiences of lost data, they often exhibit extreme caution around certain types of elements and avoid certain interactions when possible. The following screenshot shows the types of actions and elements that particularly worry users. Either avoid these elements altogether or soothe users’ fear with the smart use of microcopy, icons and animations.

During checkout, the subjects consistently OPENED LINKS IN A NEW WINDOW because they were afraid their data would be lost if they opened links in the current window.

Subjects were almost always disturbed by UNEXPECTED PAGE RELOADING (i.e. any page reloading that is not a direct consequence of clicking a link or button). In the image above, a subject selected a “Residence type,” which reloaded the page, causing the subject to immediately scroll up and down to ensure that none of their data was lost. We observed this type of unease with page reloading among subjects time and again throughout testing.

Many subjects were SCARED BY SYSTEM DIALOGS and often assumed that they would lose data by clicking “OK,” even though few of them actually read the message. The subject in the test shown above wanted to go backwards in the process to pick another ticket but was met with this dialog, which he cancelled -- assuming that he would have to re-enter everything if he wanted to select another ticket.

A good number of the subjects believed that LEAVING THE CHECKOUT PROCESS would destroy their data and so refused to go back and check for other products. The subject in the test above contemplated going back to find another bouquet of flowers, but decided against it because he did not want to re-enter all of his data. This happened despite many of the test websites actually remembering the users’ details, even if the users left the checkout process midway -- the keyword, of course, being “many” websites, rather than “all.” Given this inconsistency, users have no way to know beforehand, so their only safe choice is to just assume the worst on all websites.

During checkout, the “BACK” BUTTON was generally perceived by the subjects to be dangerous, and subjects used it during checkout only when they felt they were out of all other options. In many cases, this perception was justified: numerous websites did indeed fail to persist the user’s data when they used the “back” button. However, equally important is that PROCESS STEP LINKS and other “back” links and buttons that were part of the website’s UI were generally considered by the subjects to be “safe.”

Therefore, including either process steps or “back” links in the checkout is crucial so that users do not feel they have to gamble by using the browser’s “back” button and can instead use your website’s dedicated UI element(s) for the purpose. In the test shown above, the subject hunted up and down to find a link or button that would take him back to the previous step, but was unable to find one. Finally, he tried the browser’s “back” button.

These were the most significant insights relating to users’ fear of lost input. In general, the subjects were vastly more pessimistic about websites on which they had once lost data. For example, clicking the keyboard’s “next” button cleared one subject’s input on a website, which made her consistently avoid that button throughout the rest of the checkout. As she said, “Here, I don’t dare click ‘Next’ anymore because I don’t want to start over again.” Not only that, the subject also became overly cautious when interacting with any fields on the website, fearing that even the slightest hiccup would destroy her data.

A single bad experience set low expectations for the rest of the website. So, HOW DO WE AVOID BAD EXPERIENCES in cases where we are unable to persist the user’s data due to technical limitations? In these instances, clearly warn the user that they are about to do something destructive.

_As the subject left the incomplete checkout, the website warned her that her data would be lost. “This is very good,” the subject remarked, “because if I did something wrong by accident, I would be extremely annoyed if they deleted everything. So, it’s good that they warn me like this if the data would otherwise be lost.”_

Persisting data is always the ideal, of course, but WARNING THE USER AND GIVING THEM THE OPTION TO BACK OUT before destroying their data is a good secondary solution, and it sure beats simply destroying the user’s data without warning; moreover, it gives the user a chance to cancel the destructive action. This type of fallback solution could be especially useful for less common navigation paths, where persistent data is too time-consuming to implement, considering how few users it affects.

This could also entail something like persisting the user’s cart or checkout data when switching between the full website and mobile website. In these instances, it is acceptable to simply warn the user that they will lose their data if they proceed, and then give them the option to proceed (and lose their data) or stay (and keep their data).

Data persistence is clearly a complex matter, especially when one considers the user’s expectations towards data persistence. We observed subjects creating accounts merely to ensure persistence, and witnessed data lost due to accidental clicks, and we watched with as much surprise as the subject when an entire form was remembered perfectly by autofill, turning potentially horrible data loss into a small moment of joy. Data persistence is tricky, but getting it right is crucial.

3. ADD A PRIMARY BUTTON AT THE BOTTOM OF PRODUCT PAGES ISSUE: _Users are likely to misinterpret cart buttons in the page’s footer if there is no “Add to Cart” button at the bottom of every product page._

A wide range of the tested websites had multiple identical primary call-to-action (CTA) buttons on product pages (i.e. two “Add to Cart” buttons), one at either the top or middle of the product page and a second one at the bottom.

_On Best Buy, one subject read this product’s entire specification sheet and was in the mindset of “Yes, this is the product I want to purchase.” He saw the website’s shopping-cart icon at the bottom of the page (second image above) and clicked it, believing it was an “Add to Cart” button. Logically, he assumed the product would be added to his cart and so continued browsing for more products, only to notice much later in the shopping session that the website had “deleted” his cart’s contents (the TV was never added in the first place)._

_The subject here on Amazon thought the shopping-cart icon was the button for adding the displayed product to her cart._

It turned out that on the websites with only one CTA button on a product page, subjects often ran into severe problems even with adding a product to their cart -- which, in some cases, ultimately led to abandonments. Cart icons in the page’s header or footer were often mistaken for an “Add to Cart” button.

Both Best Buy and Amazon failed to make the primary buttons immediately obvious and generally available, which led subjects to start interpreting various icons on the page, including the cart icon, as shown in the two examples above. Subjects often scrolled to the bottom of a product’s page when looking for the “Add to Cart” button (a behavior confirmed in another study).

_This subject started looking for the “Add to cart” button by scrolling to the bottom of the page, then scrolling back to the top of the page, thinking she might have missed it, and finally scrolling down again patiently, until finding the “Add to bag” button in the middle of the page._

To accommodate this behavior and reduce misinterpretation of any cart icons, add a second “Add to Cart” button to the bottom of all of your product pages. A second button there will also support a more natural interaction flow, as the user first reads the product description, then the specification sheet, then the reviews and so on, and then, at the end of the page, decides whether to buy or not. Only if the product page is extremely short (one to two mobile viewports tall) would a single button suffice.

4. BE VERY CAREFUL WITH ANIMATED CAROUSELS ISSUE: _Users fail to discover vital features that appear only in a carousel, and they have a hard time interacting with carousels themselves._

Animated carousels caused interaction problems for half of the test’s subjects. The carousels simply changed too quickly for some subjects to both read and select an option.

_A subject was about to click the “Mega Sale” slide (left image), but the carousel animated to the next slide at the very same moment, forcing the subject to wait for that slide to reappear._

In multiple instances, a subject found a carousel slide interesting and attempted to tap it. However, the carousel changed to the next slide at the very same moment, causing the wrong slide to load. Sometimes the subjects noted this, but sometimes they did not and LEFT THE LANDING PAGE IMMEDIATELY because they did not find it relevant to what they were looking for.

Interestingly, the “Prev” and “Next” buttons in the Toys “R” Us carousel were not used by a single subject during testing, despite these issues:

_The carousel changed the very second this subject tapped it, registering a click for “Bike Blast” instead of the “Mega Sale” she wanted. The subject never noticed and assumed that “Bike Blast” was the sale._

Both of these interaction issues were also encountered (and still exist) in the early versions of carousels on full websites, but as carousels have become increasingly popular on e-commerce home pages over the last several of years, they have evolved, so most now stop animating when the user hovers over an option with the mouse.

And most also have an indicator that enables the user to see how many slides a carousel has and, just as importantly, to jump to a particular slide (such as back to the one that piqued their interest but changed too quickly). These interaction issues cannot be easily solved on mobile because there is no hover state and much less screen real estate.

_On Toys “R” Us’ home page, the subjects pored over the menus to find a “Gift Guide” wizard but could not find one (image on left). It turns out there is a wizard but is accessible only via a particular slide in the rotating carousel at the top of the page._

Perhaps an even more critical usability issue is that MOST TEST SUBJECTS SIMPLY IGNORED THE CAROUSEL after quickly glancing at the first slide. Some waited and looked at two to three slides before focusing elsewhere. This proved critical on some websites, such as Toys “R” Us’, because the majority of subjects were desperately looking in the traditional navigation for certain features (such as the “Gift Finder”) that were accessible only via the carousel. Some subjects spoke at length about how the website really should have some sort of “gift guide,” ultimately abandoning the website because they could not find one.

Users ignore animated carousels for multiple reasons. First, a carousel’s content might look like advertising, depending on how it is styled, greatly increasing the chance of banner blindness (a subgroup of subjects tended to focus much more closely on text-based navigation than on graphics-based navigation). Secondly, when using a large laptop or desktop monitor to browse a full website, the user is able to check out other options on the home page while still glancing at the carousel slides as they change.

On mobile devices, however, the screen is so small that a carousel would take up a significant portion of the viewport, making it practically impossible to scan any navigation or category options while monitoring the carousel slides (one of them will always be partly or completely out of sight). Therefore, if users are to see all options in a carousel on a mobile device, they will have to watch the carousel for its full duration (like a video clip).

Regardless of the cause(s), what is really important is that the vast majority of subjects ignored the animated carousels completely and, on the home page, focused instead on the category navigation and search features. For this reason, be very cautious about relying on carousels for important content, and never have it as the only path to a particular feature.

5. BE CAREFUL OF SHOWING PRODUCT INFORMATION OR IMAGES ON SEPARATE SUBPAGES ISSUE: _Users have incredible difficulty understanding the scope of product subpages._

On a mobile device, understanding the scope of the current page is vastly more difficult for users, due to the very small display. Mobile pages often lack the subtle yet vital page-scope cues that are present on full-size pages, such as a full set of breadcrumbs, an overview of the current page, and full URL paths viewable throughout the browsing session.

This lack of scope on mobile makes having any kind of substeps or subpages that refer to a main page very risky, because the user would have to fully understand the scope of the current page in order to appreciate the difference between the subpage and main page.

_When users want to see larger versions of images of an Amazon product (left), they are taken to a subpage (middle). Our test subjects clearly noticed that they were still within a product’s particular scope (because of the large product image), but they did not understand where the rest of the product page went (right)._

This became immediately apparent when testing websites that offer a “larger view” option of their images, taking users to a separate product subpage, as seen on Amazon above. Because of the apparent LACK OF ACCESS TO VITAL CONTENT, such as “Product Description,” “Product Specs” and “User Reviews” (which are available only on the main product page), the subjects who did not notice this change in scope assumed that such content simply did not exist for the given product and continued looking for other products with such information, discarding perfectly matching ones.

_Amazon also uses subpages to show full specification lists, causing the exact same issue, except that this time subjects were unable to locate something as vital as the “Add to Cart” button._

On a mobile device, and especially on subpages, understanding the current scope is simply much more difficult. Instead, display your “larger views,” image galleries, detailed specification sheets and the like (i.e. all relevant content) directly on the product’s main page. You could also use progressive disclosure by collapsing each content section by default, to avoid overly long pages; but then be sure to have clear trigger indicators. A strategy such as this minimizes the need to display additional information and images on subpages and the resulting scope issues.

Especially with image galleries, you also have the option of an overlay, as shown above on Foot Locker. With an overlay, the user can still see the product page beneath and have a simple way to get back to it.

6. BE THOUGHTFUL IN THE DESIGN AND SEQUENCE OF YOUR THREE ACCOUNT-SELECTION OPTIONS ISSUE: _Users had difficulty figuring out how to initiate “Guest Checkout” and understanding field relationships, selection options and buttons in the account-selection steps._

On mobile, the user’s selection of a checkout type -- “create an account,” “sign into account” or “guest checkout” -- will be a separate step (unlike on full websites, where it could be integrated into the first step). More than half of the test subjects (60%) had serious trouble identifying, seeing and selecting the guest-checkout option at the account selection step during checkout.

Multiple times, the misunderstandings led subjects to believe that registration was required, despite it being optional, and carried all of the downsides of forced account registration (including abandonments). Therefore, the design of your account-selection screen for mobile is just as important as having a guest-checkout option at all.

Several different design schemes led to these serious misunderstandings, as the following screenshots illustrate.

On Macy’s, subjects saw the account-selection step (above left) after selecting the cart. Some clicked “Express Checkout,” believing they would have a fast checkout (as a guest), only to get form-field validation errors for the two fields because “Express Checkout” requires a Macy’s account (above center). Some only discovered the “Checkout as a Guest” option further down the page (right), after getting this validation error, while others never noticed the guest-checkout option and registered for an account, believing it was required.

On multiple websites (Amazon, Toys “R” Us, REI, GAP, Best Buy), subjects started to interact with the fields, such as by providing their email address (above). On REI, every single subject interacted with the email field before looking for, or figuring out that there was, a guest-checkout option.

In most cases, the subjects spotted the error before submitting the form (typically upon reaching the password field and deducing that they were on an account sign-in or creation form). In such cases, not even detailed analysis of your Web statistics and error logs would reveal these issues because no validation error ever occurs.

On Buy.com, things are even worse. The vast majority of subjects simply could not figure out the relationship between the four checkout methods (sign-in, create account, guest checkout and PayPal checkout), the two form fields, the three radio buttons and the two primary buttons. All tapped the “Checkout as a Guest” option after spending some time trying to understand the page.

Then, the naming of the “Sign in Using Our Secure Server” button utterly confused subjects because they were trying to check out as a guest (and, therefore, actively opted not to sign into anything). This particular naming has been used by Amazon for years and has even been highlighted as a best practice to indicate a secure checkout, so how could it lead to such major misinterpretation?

The reason is that IT INDICATES THE USER WILL SIGN IN, which makes sense only if they have an account or will create one, but not if they are checking out as a guest. (Amazon does not offer a guest-checkout option, so the wording makes sense in that context.) Given the button’s name, one subject assumed that the only other prominent button on the page, “Checkout with PayPal,” must be the one to pick to initiate the “Checkout as a guest” selection.

Others finally clicked the oddly named button -- but nothing seemed to happen. It turns out that inline text reading “Required” appeared next to the “Enter your eMail Address” label (seen above), but no one noticed it initially. The subjects typically waited for a little while just in case the website did not load, and then clicked again, at which point most realized that they needed to fill in more data. By this point, some, especially those who did not notice the validation error, concluded that they were not allowed to check out as a guest and proceeded to create an account instead.

One explained his experience thusly, “Normally I would think ‘guest checkout’ would let me through without having to create an account. But here I have to fill in my mail, so I have no idea what that option is for, then. To be on the safe side, I’ll then pick the ‘No, I’m a new customer,’ because if I’m forced to create an account, I might as well just do it properly anyways.”

Making the account-selection process clear is as important as offering a guest checkout option. Following two main design principles will help to prevent these serious problems:

* ALWAYS PLACE THE GUEST-CHECKOUT OPTION AT THE TOP, with its own button to proceed, so that the user does not need to fill in an email field in this step. (If needed, you can look up whether the user has an account in the next step, when you ask for their email address, to ensure that they have not selected the guest checkout just because it is the first option in the list.) * COLLAPSE ALL OF THE FIELDS AND DESCRIPTIONS FOR ALL THREE OPTIONS -- “guest checkout,” “sign in” and “create an account” -- bringing each option down to a single line, making it possible to get an overview in the viewport without having to scroll or expand. Dynamically expand them when tapped, revealing the fields and descriptions. This will also make clear which fields are related (and required) for each option. Below, we have created a simple mockup to illustrate how account selection can be clarified by combining these two principles:

_All three account-selection options are displayed in collapsed state (with guest checkout at the top), so that the user can instantly see all available options. The options can either expand inline (image on right) or redirect to the next step in the checkout process. Progressive disclosure also makes the relationship between an option and its fields much clearer._

7. DISABLE AUTOCORRECTION WHEN THE DICTIONARY IS WEAK ISSUE: _Poor autocorrection is frustrating when users notice it, and can be detrimental when they do not._

Autocorrection usually works poorly for abbreviations, street names, email addresses and similar words that are not in the dictionary. This caused significant problems throughout testing and resulted in a great deal of erroneous data being submitted as subjects completed their purchases.

_When this subject typed in his street name, “westheimer,” the phone incorrectly autocorrected this to “weathermen” (left). However, the subject did not notice this, submitted the form and received a validation error (right)._

One of the major issues of autocorrection was that the subjects often failed to notice the correction (because they were often focused on what they were typing, instead of what they had typed). This is fine if the “correction” is correct, but it can be detrimental if it is wrong. For example, in multiple instances, a valid address was autocorrected to an invalid one and submitted because the subject failed to notice it.

On websites without address validators, this resulted in wrong addresses being submitted, unless the subject was particularly attentive on the order review page. After all, the user’s address will often be replaced with something that looks very similar, although incorrect. In addition to the “weathermen” example, official address abbreviations, such as “Rd,” were autocorrected, to “Ed.”

That being said, AUTOCORRECTION DID PROVE VERY HELPFUL WHEN IT WORKED. So, don’t disable it in all fields. Use it discreetly, and disable it on fields for which autocorrection dictionaries are weak. This typically includes names of various sorts (street, city, user) and other identifiers (such as email address).

You can disable autocorrection by adding an autocorrect attribute to the input tag and setting it to off, like so:

8. MAKE FIELDS LONG ENOUGH TO FULLY DISPLAY COMMON DATA (AND PUT LABELS ABOVE FIELDS) ISSUE: _Users cannot easily spot errors, let alone correct them, when the field is too short to display the entire inputted data._

Due to the small size of mobile screens, form fields often get so short that users cannot self-validate before submitting their data, and users have a very difficult time correcting any validation errors because they cannot see the inputted data in its entirety.

_“I can’t see what I’ve typed. Argh. Then I’ll delete everything and retype it.” On REI, a validation error for an email field that was too short to be displayed in its entirety made it impossible for the subject to see what the actual error was. In trying to pan the inputted text, the subject accidentally enabled both the iOS text-selection tool and the text-replacement tool._

Form fields that are too short presented problems for many subjects who tried to confirm the validity of their data before submitting it. They often made complaints such as, “I can’t see if the emails are the same when the email field isn’t long enough.” Some examples are seen below.

_On the left: Amazon’s email field is too short, despite the abundance of white space. In the middle: United’s credit-card field shows only 15 characters, even though most card numbers are 16 digits. On the right: Macy’s email fields are too short for users to verify whether the two addresses they’ve inputted match._

Given how easy it is to make a typing mistake on a mobile device, FIELDS THAT ARE NOT LONG ENOUGH to allow users to validate their data before submission are very harmful to the typing experience. Even worse, they make correcting any validation errors unnecessarily difficult.

Note that in the case of Amazon and the earlier example from REI, the white space is sufficient to make the field much longer, while the other two examples have no additional space to make the fields longer because the labels are all left-aligned. For this very reason, labels should be placed above form fields to allow full use of the space and to display all of the user’s data (at a decent font size). Displaying labels to the left of the fields would be acceptable only when the device is in landscape mode (as explained in detail in “Mobile Form Usability: Place Labels Above the Field”).

An adequate width for email and address lines is the full screen. Then, adjust the font size of the fields to allow for the full display of reasonably long data, such as first.lastname@my-company.com. (The character-length distribution of our own newsletter list shows that 96% of email addresses are 30 characters or fewer.)

9. ENABLE USERS TO VERIFY THE INPUTTED DAY AND DATE ISSUE: _Using text fields for dates requires unnecessary mental processing of the user and can cause serious selection errors._

During testing, websites that had only a simple text field or drop-down dialog for date selection presented problems for 80% of the subjects.

_This subject was among the 80% who were unsure which date “this Friday” was. So, she decided to count the days on her hand, wanting to make sure she picked the right one._

This happened with both Southwest (which uses drop-downs for the month and day) and United (which shows a text field for writing MM/DD/YYYY). On both of these websites, the following scenarios occurred:

* A handful of subjects had to count the days on their hand (as explained above). * Half of the subjects went off-site and opened the phone’s native calendar app to double-check the date for their weekend trip (to confirm “this Friday”). In the instance seen above, this calendar verification goes completely awry because the subject checked the day of June 15th, instead of July 15th, and ended up purchasing a flight ticket for his “weekend” trip that left on a Sunday and returned on a Tuesday.

* Lastly, a few struggled with typing and using the text-selection tool to enter the correct date on a website that uses a text field for date selection.

By contrast, on the three test websites that provided a graphical interface for inputting dates in the form of a calendar view (namely, Enterprise, Avis and 1-800-Flowers, seen above), not a single one of these issues arose, and the subjects generally liked being able to verify the day and date they were selecting. This could potentially save customers from incorrectly counting or “verifying” the wrong weekday (as mentioned earlier) and thus booking the wrong date.

While this is an annoyance on desktop as well (since the user would be no better equipped to spot the errors there), the severity and impact on the user’s experience is much greater in mobile when it comes to correcting the erroneous data, because PANNING AND EDITING TRUNCATED DATA ON A THREE- OR FOUR-INCH TOUCHSCREEN IS MUCH MORE CUMBERSOME THAN USING A MOUSE OR KEYBOARD ARROWS ON A DESKTOP. Furthermore, ordering tickets on the wrong day is much less likely on the desktop because the booking form and a separate calendar application can be displayed next to each other -- whereas on mobile, only one can be viewed at a time.

Therefore, always provide an interface that enables users to verify the day of their selected date. One option is to display a calendar interface in which the user explicitly selects the date they want. That would simplify the actual selection interface and, more importantly, gives users a chance to verify the day. If you already use a drop-down for date inputs and do not want to replace it, you could instead append the day after each date option (for example, “March 15 - Monday”); although that would require the month to be included in each drop-down day value or, in case a separate drop-down is used to select the month, you would need to dynamically update the day names depending on the currently selected month.

10. MAKE THE HIT AREA FOR EACH LIST ITEM DISTINCT ISSUE: _With some lists, users simply have no idea where to tap in order to select an item._

Can the entire “element” be tapped? Or only the product title? And what about the thumbnail? During testing, multiple issues arose as subjects were unsure of where to tap in order to select an item in a list. This was by far the worst on websites where list items were above the recommended half-screen height. In fact, one subject got completely stuck and was unable to complete her purchase.

The problem was by no means limited to websites with list items that were too tall; it was just worse on those websites. The issue also extended to websites whose list items were normal in size but whose hit areas were unclear, which severely limited the subjects and even resulted in abandonments.

_It simply was not clear to subjects what can and cannot be clicked on this page. Note the very inconsistent link styles. Orange is sometimes used for the header, other times for a list item. Separators are sometimes used to set off list items, other times to set off elements of text. Some text is one shade of blue, which sometimes indicates a link, while other links are styled in a darker blue and underlined. Confused yet? The subjects were, too._

_Note how the subject was trying to click the “Lowest Fare” label, believing this was the button to choose the displayed flight. Besides the primary button being unclear, the list item is also very long. Combined, these two design choices are a surefire way to leave some users in doubt on how to even proceed._

_On the left: This subject did not know what to click in order to proceed on United’s website. Presumably, this was caused by the single result. With no options to compare and choose between, it was not clear to the subject what to select. On the right: Many subjects did not pick up on the ticket icon and its meaning on Fandango’s website. Instead, they assumed that the movie was playing only in theaters where a “Buy” button was shown (which was not the case)._

The images above show only some of the many instances where it was unclear to subjects what elements are clickable, what the differences are between the different hit areas and, most importantly, where to click in order to select an item in a list. The websites with the far fewest problems with hit areas embraced multiple of the following recommendations:

* Make the entire element area clickable. In particular, the thumbnail, product header and price should be clickable and should lead to the product page. * Style the title as a link (using your primary style for text links). * Indicate the virtual space with an arrow or similar visual cue, showing that the entire list item will move the user to the next step in the process. * Consider separate “Buy Now” or select buttons for very long list items -- i.e. when a list item could be easily mistaken as pieces of information, rather than a collective entity to be clicked. * Avoid multiple hit areas within the same visual element -- in particular, links or buttons within a list item that lead to different pages. DESIGNING M-COMMERCE WEBSITES Aside from their practical use, these 10 recommendations have hopefully given you a glimpse of just how complex designing an m-commerce website really can be. It’s not simply a matter scaling and adding media queries; it’s an entirely new platform, and the balancing act is particularly difficult to get right due to the complex tasks involved, such as product finding and product comparison and multi-step processes such as checking out. In many ways, DESIGNING AND OPTIMIZING AN M-COMMERCE WEBSITE IS MUCH MORE DIFFICULT and often requires more “intelligent” website features than a traditional desktop e-commerce website. It comes as no surprise that IBM reports average m-commerce conversion rates that are roughly half of its desktop e-commerce conversion rates.

In general, the more complex a mobile website’s features, the more likely the experience should be significantly different from the desktop experience. The greater the difference between the two, the stronger the argument for having a standalone mobile website. Of course, maintaining two versions of the same website comes with many issues, especially with maintenance (of content, code and design). A RESPONSIVE DESIGN IS A BETTER SOLUTION IN SOME CASES, but it depends very much on the size and complexity of the website, as well as on your organization’s strengths and weaknesses. It’s a nuanced issue, with many gray areas and with good arguments both for and against having a standalone mobile website.

If you can achieve this by designing for mobile first, then a responsive design could be truly great -- not just in its maintainability, but also its user experience. Be clear, however, that if your existing website is complex, merely scaling it down to different devices won’t be enough to offer a great mobile experience. And if messing with the full website’s existing structure and content isn’t an option, then you might be forced to create a standalone mobile website in order to provide a decent experience -- although maintaining content and code on the two separate platforms in parallel could turn out to be both expensive and messy.

Thus, getting an m-commerce website right tends to be very resource-demanding, as you account for all of the nuances. But the opportunities are great. This is a new world, and it will take time before best practices stabilize. Spending time and money on a mediocre m-commerce website is wasteful. Yes, making the website great will require significant investment, but the potential payoff is high, too. M-COMMERCE IS A WINDOW OF OPPORTUNITY; it enables you to distinguish yourself from competitors and to position yourself well to grab a share of this market, which is expected to reach $86 billion by 2016.

NOTE: Find out more about m-commerce usability guidelines in the (paid) report “M-Commerce Usability.”

_(al) (il)_

------------------------- © Christian Holst for Smashing Magazine, 2013.

Good typography has always been a defining aspect of effective Web design, and this holds true especially for websites in which the emphasis is on presenting a large amount of content -- specifically, articles, news and stories. Whether for a magazine or international newspaper, the designer of any website that distributes a lot of content has always had to consider typographic details as seriously and thoroughly as a print designer would.

In 2009, we conducted a survey of then current typographic practices. Since then, responsive design techniques have clearly gained momentum and established their place in the landscape of CSS layout. With the advent of mobile, new modes of browsing websites and reading text have emerged.

Online publications have had to reevaluate how their content is presented on mobile devices. Web typography is as rich, versatile and accessible as ever before. Yet new opportunities introduce new complexity; and with new implementation challenges, we are all spurred to reconsider our practices.

Now, three years later, WE’VE REVIEWED THE ORIGINAL STUDY AND EXPLORED HOW WEB TYPOGRAPHY HAS CHANGED over these years. We spent countless hours between February and April of this year collecting new data and exploring common developments and trends in Web typography.

How Did We Conduct The Study? We have compiled relevant data from over 50 well-respected websites to address these questions. For this study, we selected a wide variety of international newspapers, magazines and blogs, all of whose typographic choices should have been carefully and thoroughly weighed. We chose publications and organizations that have a very large readership (such as The Boston Globe and The Financial Times) as well as specialized magazines with smaller yet often more demanding readerships (such as A List Apart and UX Booth).

These websites focus primarily on text-based content rather than on generic environments such as Instapaper and Readability. As such, they need to be highly legible in order to ensure that users continue visiting and reading on their websites. Because READABILITY OF CONTENT is (or rather should be) the main design goal of these publications, the techniques they follow could be considered good practices. However, the results presented in this study should be taken with a grain of salt.

Issues We Were Interested In The questions asked in our first study nearly four year ago remain relevant but need to be complemented by questions about the challenges of mobile devices. How widely has responsive design been adopted by publications, if at all? Has there been any change in the typographic choices of big and small publications? How many weights of a large font family should we deliver to mobile devices? How large should the font size of body copy be? How should the font size change on a responsive website? Optimizing readability could require changing the font’s style, size and spacing according to the viewport’s width _and_ height.

The second article in this series will address the growing diversity of eBook readers and mobile apps whose purpose is to give users a pleasant, improved or enhanced reading experience -- from desktop readers down to smartphone readers. We were curious about the specifics of design and typographic choices that make reading articles in these applications more pleasing than reading on the original websites.

NOTE: For the sake of continuity, we have stayed close to the format of the original study from 2009. This article is meant to update the data, and hopefully detect new trends and reach new conclusions.

TYPOGRAPHY IN ONLINE PUBLICATIONS After carefully analyzing the style sheets in the publications in this study, we compiled a comprehensive spreadsheet of typographic points and collected the relevant data. You can view a spreadsheet of the raw data, which contains more data than was pertinent to this article.

Not limiting ourselves to the questions in the original study, we will broach issues that have arisen since then as a result of responsive design techniques, and we’ll examine whether such techniques are being applied at all. This led us to the following questions:

* How popular are serif and sans-serif typefaces in body copy and headlines? * Which fonts are used most frequently? * What is the average font size (on narrow, mid-sized and large screens)? * What is the average ratio of the font sizes of headlines to the font sizes of body copy? * What is the average line height of body copy? * What is the average ratio of line height to font size in body copy? * What is the average ratio of line height to line length in body copy? * What is the average amount of space between paragraphs? * What is the average ratio of paragraph spacing to line height in body copy? * How are links styled? * How many characters per line are common in body copy? * How often are links underlined? * How often are font fallbacks used? * How often are responsive design techniques implemented? * Which ratios of display sizes are discernible? * How do websites deal with the performance of Web fonts? To answer these questions, we collected more than 40 data points, all of which can be found in the aforementioned spreadsheet. We can extract several rules of thumb from this data. We wouldn’t recommend acting on the data from this study blindly; the statistical data, however, will no doubt yield useful insights.

POPULAR SERIF AND SANS-SERIF FONTS “Which typeface to use?” Obviously, this is one of the most important questions a designer has to answer when considering Web typography. The typeface will set the tone for the entire website, and a poor choice could send the wrong message or thwart the intended atmosphere. The argument for either serif or sans-serif hasn’t been won yet. Interestingly, looking back to the results of the 2009 study, sans-serif typefaces seemed to be more popular in body copy and headlines. The last four years have seen a tiny shift away from that.

_Serif and sans-serif are almost equally popular in headlines._

The motivations of designers likely haven’t changed much. Serif fonts apparently stand out in headlines, but arguments have been made for serifs’ ability to guide the reader and for its readable structure in body copy as well. Still, CONTRASTING A SERIF BODY WITH A SANS-SERIF HEADLINE or vice versa can improve the overall visual appeal and readability of a website.

The data suggests that serifs have gained in popularity in recent years, leading almost to a reversal in common usage in the last four years, at least where body copy is concerned.

_Serifs have strongly gained in popularity in body copy._

* Half of the websites analyzed use serifs in their headlines, the other half sans-serifs. The two most popular typefaces are Georgia -- used on such websites as The Guardian and the Financial Times -- and Arial -- found on Zeit.de and the BBC’s website. * Only 37% use a sans-serif typeface for body copy. * The most popular serif typefaces for headlines are Georgia (14%) and Chaparral Pro (6%). * The most popular serif typefaces for body copy are Georgia (20%) and Chaparral Pro (4%). * The most popular sans-serif typefaces for headlines are Arial (10%) and Freight Sans Pro (4%). * The most popular sans-serif typefaces for body copy are Arial (14%) and Helvetica (6%). * However, 66% of headline typefaces and 39% of body copy typefaces are found in only one instance. So, in summary we can state that nearly two thirds of the websites analyzed use serifs for body copy, and Georgia and Arial are still the most common primary typefaces. However, OUR MOST SURPRISING FIND IS THAT A MAJORITY OF WEBSITES USE NON-STANDARD FONTS AS THEIR PRIMARY TYPEFACE -- 39% of body copy and 66% of headlines. This development is truly interesting, because it shows that typography has become an important element in establishing brand identity and character. These numbers indicate growing typographic diversity on the Web -- which we should probably expect anyway.

_A majority of websites use non-standard fonts as their primary typeface._

The growth of “bulletproof” font-delivery services such as Typekit and Fontdeck likely explains the increasing variety of primary typefaces. Fallback typefaces are predominantly standard core Web fonts. TIMES, TIMES NEW ROMAN, GEORGIA, HELVETICA AND ARIAL are most often used in CSS font stacks. Mobile platform fonts such as Droid Sans, Palatino and Cambria are almost never used.

Ironically, a consequence of the resurgence in serif typefaces is that Times and Times New Roman, which had almost been written off as too old-fashioned in the last study, have made kind of a comeback as the two most popular fallbacks. Roughly 11% of headline and body copy fallbacks have Times, and another 11% have Times New Roman.

There is much literature on typography in Web design, most of which discusses the applications of serif or sans-serif typefaces. Increasingly, the argument for better readability combined with artistic value supports a judicious use of both styles. Douglas Bonneville discusses the benefits and best practices of combining serifs and sans-serifs, and Simon Pascal Klein discusses the intricacies of font families and makes further typographic considerations in his article “Achieving Good Legibility and Readability on the Web.”

_The Great Discontent combines both the Stratum and Meta Serif Web Pro fonts to generate a dynamic yet respectable feel._

Compared to the previous study’s results, Verdana and Lucida Grande are the big losers. Verdana is used only twice as a primary font, and neither is used more than once as a fallback font. CHAPARRAL PRO AND HELVETICA HAVE RISEN IN PROMINENCE. The increasing diversity and individuality in design is due to both the increased use of font foundries and the wider range of Web fonts.

One discovery of the previous study, that “alternative” fonts are more common among headline typefaces, is still proving accurate. No doubt, the general belief that experimentation is best applied to small details still stands. The look and feel of a page can be adjusted just enough by changes to the font family of headings, rather than by drastic changes to body copy. However, the overall USE OF ALTERNATIVE FONTS FOR BODY COPY HAS INCREASED dramatically, creating a much richer and more diverse typographic landscape on the Web.

LIGHT OR DARK BACKGROUND? The previous study concluded that a large majority of websites favored dark on light color schemes. Not much has changed, although the websites surveyed this time are more varied in their light background tones.

_An Event Apart demonstrates the readability of a subdued color scheme._

Several websites have a less aggressive contrast of an off-white or even beige background with dark-gray text. The off-white is often chosen to lower contrast. The designers in this case have clearly opted for a comfortable, lengthy reading experience.

Black text on a white background is a common pattern for body copy. The contrast is easy on the eyes and is, at least among these websites, the status quo.

AVERAGE FONT SIZE FOR HEADLINES Generally, the font size of headlines is chosen according to the typeface of the body copy. Still, it’s interesting to see what common ranges designers prefer for body copy and headlines. In this study, the headlines for large display sizes average at roughly 38 pixels. Of course, we made sure that the text always displayed at the actual size, without any zoom.

_The most popular sizes range from 20 to 32 pixels._

You can easily notice the increase in font size since the last study. Not only did the average increase by more than 10 pixels (!), but the range of headline sizes starts further up, at 20 pixels, and tops out at an impressive 212 pixels in the case of The Great Discontent. This publication is an exception, with its magazine-like headlines and smaller font sizes for headings.

_We're going further up. The Great Discontent shows an impressive 212 pixels font size._

AVERAGE FONT SIZE FOR BODY COPY With readability as the determining criterion, the average pixel size of body copy has increased in four years as well. Back then, most of the websites were between 12 and 14 pixels in font size. Now, 14 PIXELS IS AS POPULAR AS 16 PIXELS; each is used on 13 websites.

_14 pixels is also The Verge's font size. While some websites offset the first paragraph of an article with a larger font size, many, like The Verge, follow a uniform size._

RATIO OF HEADLINE TO BODY FONT SIZE We’ve updated OUR RULE OF THUMB based on the current average ratio between headline and body font size. Don’t follow this rule blindly; rather, just keep it in mind as you make decisions in your projects.

Headline ÷ Body Copy = 2.5 According to our study, on average, the ratio between the headline and the body copy is around 2.5. The traditional scale (6, 7, 8, 9, 10, 11, 12, 14, 16, 18, 21, 24, 36, 48, 60, 72) and the Fibonacci sequence (16, 24, 40, 64, 104) are still relevant, of course, and represent a more naturalistic approach. The GOLDEN RATIO (1.618) might also yield an organic effect, too.

OPTIMAL LINE HEIGHT FOR BODY COPY Leading (or line-height in CSS) will always depend on your font size and measure (or line length). But in general, the longer the measure, the longer the leading should be. Therefore, presenting a chart of the most popular leading values in pixel units wouldn’t make sense here. More appropriate for you would be to use a relative unit, such as an em or percentage value, that determines the ratio between leading and measure and between leading and font size.

This latest study reveals the following:

* LINE HEIGHT (PIXELS) ÷ BODY COPY FONT SIZE (PIXELS) = 1.46 Classic typography books recommend 1.5, a value backed up by this and our last study. Very few websites use anything less than that. The number of websites that go above 1.48 decreases as you get further from this value. * LINE LENGTH (PIXELS) ÷ LINE HEIGHT (PIXELS) = 24.9 The average line length (570 pixels, excluding margins and padding) has grown comparatively less than font size and line height have since 2009 (the latter averaging 22.9 pixels). The average line lengthened by approximatively 5% (from 538,64 pixels in 2009), while the average line height has increased from 12 pixels in 2009 to 13 pixels in 2013. * SPACE BETWEEN PARAGRAPHS (PIXELS) ÷ LINE HEIGHT (PIXELS) = 1.39 In the first study, it turned out that paragraph spacing (i.e. the space between the last line of one paragraph and the first line of the next) rarely equaled the leading (which would be the main characteristic of a perfect vertical rhythm). According to our results, paragraph spacing is around 1.39 × the paragraph leading. Paragraphs are more clearly delineated with this increased ratio, thus increasing readability. Multiplying the value of your body’s font size by 1.46 would give you the optimal line height, which you could then adapt to your font style. Multiplying this new value by 24.9 should give you the optimal line length. Note that the layout would also need gutters, margins and padding to let the body copy breathe.

CHARACTERS PER LINE As explained by Robert Bringhurst, the classic rules of Web typography dictate that the optimal number of characters per line is 55 to 75. Our data shows that at their actual size (i.e. with no zoom and at the default font size), most websites average 83.9 CHARACTERS PER LINE at a widescreen resolution (in our case, a browser width of 1100 pixels).

While this average fluctuates quite significantly when the browser is at various other widths -- between 83 and 86 characters per line at display widths of 700, 950 and 1600 pixels -- only in smaller views of 500 pixels this average comes close to the classic rule. At that width, the average lies around 77 characters per line.

This is most likely the result of an attempt among designers to balance the font size with the amount of text displayed on narrow screens. With more characters displayed per line, the font size would have to become small, making the reading experience a bit more difficult on the eyes.

The highest number is, of course, much higher, but in general most designers stay in the range of 75 to 90 characters. In the most extreme cases, SB Nation has 55 characters per line, and Polygon averages 118 for the introductory paragraph. A more exact average could be derived by averaging several lines. But such an in-depth analysis probably would not vary greatly from the average that we calculated here. Still, the discrepancy between the number of characters at different widths is peculiar.

_Polygon displays more characters per line in the introductory paragraph than in the rest of the article. However, the font size of that paragraph is larger as well._

WEB TYPOGRAPHY AND RESPONSIVE DESIGN A burning issue we wanted to explore was the impact of of responsive design in Web typography today. The results were surprising: 22 OUT OF 52 (I.E. 42%) OF THE WEBSITES WE ANALYZED SHOW (MINOR OR MAJOR) CHANGES when the browser size changes. Considering that responsive design has been around for two years, that number is quite impressive. We calculated the number of characters per line, the body font size and the headline font size at five browser widths (and experimented with the height as well): 500, 700, 950, 1100 and 1600 pixels. The font sizes for those three metrics do not differ greatly across the screen sizes -- except at the 500-pixel view.

Unexpected, though, were the VISUAL CHANGES that occurred as we resized the browser. Changes in layout, image scaling, content and font size were evident to varying degrees on 22 websites. The changes are as minimal as images being scaled down to suit the display width. In some cases, however, the websites display other minor and expected changes. At the 500-pixel view, for example, the menu is often replaced by an icon; design components are moved from a multi-column layout to a single column; and both images and fonts are scaled.

NO SIGN OF RESPONSIVE DESIGN WAS EVIDENT ON 30 WEBSITES, including major publications such as The Financial Times and The Economist. At least some, if not all, of these websites seem to opt for a separate mobile website or application. The Financial Times immediately invites mobile visitors to use its FT app. At the moment, large online publications seem to prefer to invest in an app than in responsive design. If this trend continues, then the question becomes, how much will users be annoyed by being prompted to download an app for every single publication they’re interested in.

Despite this, we were happy to find that the layouts of the large majority of websites DO NOT BREAK when being zoomed in.

Some Numbers On The Implementation Of Responsive Design 42% of websites implement responsive design changes, including for layout, image scale, content and font size.

At a display width of 500 pixels:

* Average line height: 28 pixels * Average font size of body: 15 pixels * Average number of characters per line: 77 At a display width of 700 pixels:

* Average font size of headlines: 36 pixels * Average font size of body: 15.6 pixels * Average number of characters per line: 82.7 At a display width of 950 pixels:

* Average font size of headlines: 37.9 pixels * Average font size of body: 16.1 pixels * Average number of characters per line: 84.8 At a display width of 1600 pixels:

* Average font size of headlines: 40.7 pixels * Average font size of body: 16.2 pixels * Average number of characters per line: 86.8 These averages might be somewhat skewed because of the mixture of responsive and non-responsive websites. But they show how little the body font size and characters per line change over varying widths. The only exception is the 500-pixel width, which have a lower number of characters per line.

PERFORMANCE CONSIDERATIONS While EMBEDDED FONTS are slowly becoming a de facto standard in Web design, they also introduce overhead in performance because, well, they have to be loaded. Chris Coyier recently discussed the idea of loading Web fonts only on large screens to avoid the performance hit. You could also load Web fonts into AppCache or LocalStorage first and show them on subsequent page loads.

Moreover, you could use Google’s WebFont Loader to ensure that the content is displayed in fallback fonts even before the Web fonts have loaded, and then switch to the Web fonts once they have completely loaded (this is what we're implementing in this very moment).

Our study shows that Web fonts are indeed a heavy bottleneck in performance, with 5.7 FONT FILES BEING LOADED ON AVERAGE, totalling an average of 133.5 KB of extra bandwidth. In cases such as a page being loaded on a slow mobile connection, the user would initially see no text other than the underlining of links (apparently due to the use of the border-bottom property). Only once the fonts have loaded would the text be visible -- and even then, elements would appear one by one (headings, then subheadings, then body copy). We can avoid this suboptimal experience by properly adjusting the CSS font stack, as Richard Rutter explains in his talk “Responsive Web Fonts” (slidedeck).

OTHER FINDINGS * 45% of websites underline the links in body copy. The others do so only on hover or not at all. * 71% of websites highlight links with color. The rest do not or only on hover. * 99% of websites left-align text. * No website uses hyphenation. * 84% of websites use the same fonts in the print and standard style sheets. * The loading weight of home pages averages around 1.346 MB. Article pages are marginally less, at around 1.146 MB. * The websites average 119 HTTP requests! CONCLUSION This study has revealed a set of common practices in Web typography. These results should NOT BE INTERPRETED AS LAW. They should not be interpreted as “best” practices; rather, just as rough guidelines that we encountered in current Web design.

For example, the performance hit introduced by Web fonts and the (huge) number of HTTP requests should be reduced as far as it's possible, while the content-out approach in responsive design would dictate how the font size would need to adjust depending on the settings in which it's used. These findings are no doubt JUST A SNAPSHOT OF CURRENT TRENDS and may very well be outdated in a year’s time.

* Serif fonts are more popular than sans-serifs for both headlines and body copy. There is, however, a trend to mix sans-serifs and serifs to contrasting effect. * The most common fonts for headlines are Georgia, Arial and Chaparral Pro. But the majority of websites are individualized and use less common fonts. * The most common fonts for body copy are Georgia, Arial and Helvetica. But, again, the majority of websites are individualized and use less common fonts. * The most popular font size for headlines is between 29 and 32 pixels. * The most popular font size for body copy is between 14 and 16 pixels. * headline font size ÷ body copy font size = 2.4 * line height (pixels) ÷ body copy font size (pixels) = 1.47 * line length (pixels) ÷ line height (pixels) = 24.8 * space between paragraphs (pixels) ÷ line height (pixels) = 1.43 * The optimal number of characters per line is between 55 and 75, but 75 to 90 is more popular. * Body text is left-aligned. Hyphenation is not used at line endings. And links are underlined and/or highlighted with bold or color, sometimes only on hover. * Mobile devices are mostly adapted to via responsive design, although some publications opt for a dedicated app. The decision of whether to modify any typographic element always lies with the designer. Most of the results shown in these websites are likely the outcome of much trial and error. When designing a new website, you might want to stay close to these parameters, but with adjustments to suit your layout. Feel free to review the study’s spreadsheet for the raw data.

As we mentioned at the beginning, the second article in this series will deal with the INTRICACIES OF EBOOK READERS AND MOBILE APPS. We don’t necessarily expect very different results. However, apps do offer more interactivity to the user. It will be interesting to see how much developers take advantage of the range of possibilities in mobile apps. Because there is not yet an inordinate number of readers on the market, we’ll accumulate data on as many readers as possible.

MORE STUDIES ON SMASHING MAGAZINE? Interested in more studies? Let us know what you’re interested in, and we’ll see what we can do!

What kind of studies would you like to see on Smashing Magazine? _(al)_

------------------------- © Jan Constantin for Smashing Magazine, 2013.

Now powering over 17% of the Web, WordPress is increasingly becoming the content management system (CMS) of choice for the average user. But what about websites built with an outdated CMS or without a CMS at all? Does moving to WordPress mean starting over and losing all the time, energy and money put into the current website? Nope!

Migrating a website (including the design) over to WordPress is actually easier than you might think. In this guide, we’ll outline the migration process and work through the steps with a sample project. We’ll also cover some of the challenges you might encounter and review the solutions.

ABOUT THIS GUIDE Before we get to work, let’s establish some context. First, this guide was written primarily with BEGINNERS in mind and will be most helpful for BASIC websites. Some of you will likely encounter advanced aspects of WordPress migration, but they are beyond the scope of this guide. If you’re tackling an advanced migration and get stuck, feel free to share your difficulty in the comments below.

Objectives The objective of this guide is to help you with the following:

* Plan an effective migration to WordPress. * Walk through the technical steps involved in migrating. * Get ideas and resources to solve common migration challenges. Assumptions I assume you have basic familiarity with WordPress. Previous development experience with WordPress would be helpful, but not necessary. I also assume you have an existing website and design that you want to migrate to WordPress.

Basic Steps Here are the basic steps that I recommend you follow for a typical WordPress migration:

* EVALUATE WEBSITE. Work carefully through the pages on your existing website, identifying all of the types of content (standard pages, photo galleries, resource pages, etc.) and noting any areas that need special attention. * SET UP ENVIRONMENT. Set up WordPress and get ready to import. * IMPORT CONTENT. Bring over and organize your content, whether via an importing tool, manual entry (for a small amount, when no tool is available) or a custom importing process. * MIGRATE DESIGN. Incorporate your existing design into a custom WordPress theme. * REVIEW WEBSITE, GO LIVE. Carefully review the import, making adjustments where needed, set up any URL redirects, and then go live. With this outline in mind, let’s work through each step in detail.

START WITH A PLAN The key to a successful migration is to carefully evaluate your current website. You need to figure out how to import and structure the content in WordPress before carrying over the design.

While the principles are the same across migration projects, THE DETAILS OFTEN VARY. So, below are two lists of questions to ask as you work out a plan.

Imported Content * How much content needs to be imported (number of pages, number of images, etc.)? * Is the volume low enough to be imported manually, or do you need a tool? * If you need a tool, does one already exist? * Can the content be categorized into the standard “posts” and “pages,” or does it call for custom post types? * Does extra content need to be stored for certain pages (custom fields, taxonomies, etc.)? * Will the URL structure change? If so, will the old URLs need to be redirected? Existing Functionality * Does the website integrate any third-party services (data collection, reservations, etc.)? * Do any forms need to be migrated (contact forms, application forms, etc.)? * Is access to any content restricted (such as members-only content)? * Does the website sell products (digital or physical)? * Do any administrative tools need to be carried over (such as custom CMS functionality)? A Working Example My brother, Joshua Wold, has volunteered a website to serve as an example; it’s for a side project of his in which he sells posters and postcards of a Vegan Food Pyramid. He built the website in plain HTML, with some basic PHP includes for the header and footer. Below is a screencast of me evaluating the website to give you a sense of how the process will work. Enjoy!

SET UP WORDPRESS Before importing the content, we need to get WordPress ready to go. If you’re just experimenting or if you prefer offline development, start with a local installation of WordPress. Otherwise, the next step is to install WordPress with your current hosting provider; or you could use the migration process as a great opportunity to move to a new host.

Once WordPress is up and running, you’re ready for action!

For our example, we’ve installed WordPress with the same host, setting it up in a /wp directory for the duration of the migration process.

Settings And Plugins With WordPress installed, we’ll make a few minor adjustments:

* UPDATE PERMALINKS. Go to Settings → Permalinks to make changes. In most cases, I’ll switch to “postname”-style permalinks. * UPDATE USERS. I create an admin-level account for myself and any admin or editor accounts that are needed for clients and collaborators. I also remove the default “admin” user name if it exists (a basic but wise step for WordPress security). Depending on the needs of the project, we might have to preinstall plugins. Here are the major categories of plugins:

* FORM MANAGEMENT Migrating a form “as is” is usually a mess; simply recreating it using a forms plugin is usually easier. My current favorite is Gravity Forms ($39+ per license). Other options are Formidable (with free and pro versions) and Contact Form 7 (entirely free). * SEO MANAGEMENT Search engine optimization (SEO) is a touchy subject. My philosophy is to build content for people, not for search engines. That being said, there is a common-sense approach to SEO that is solidly supported by the WordPress plugin ecosystem. And if your old website includes custom meta descriptions, giving them a new home during the importing process is important. I recommend WordPress SEO (free). * MULTIPLE LANGUAGES If your old website supports multiple languages, WordPress has you covered. My plugin of choice is WPML ($79 per license, free for non-profits). Another option is qTranslate (free). * SECURITY WordPress security is a topic near and dear to me. The increasing popularity of WordPress has made it a target for security attacks. WordPress itself is rarely the problem; a poorly secured hosting environment or an outdated or poorly developed plugin usually is. I use managed WordPress hosting for the majority of my projects, which offers a good foundation for solid WordPress security. Options include WPEngine, ZippyKid, Pagely and Synthesis. In addition to managed hosting (and especially if you opt for a non-managed host), consider installing a security plugin, such as Better WP Security (free) or Wordfence (also free). Last but not least, review the “Hardening WordPress” guide in the Codex. * BACKUPS If you opt for managed hosting, backups are usually included (make sure, though). If you’re managing backups yourself or you want an extra layer of data protection, great options are available, including VaultPress ($15+ a month), CodeGuard ($5+ a month), BackupBuddy ($75+ per license) and BackWPup (free). IMPORT CONTENT With WordPress up and running, it’s time to bring over all of your content.

If your old website has a CMS, an importing tool might be available. Start by viewing the list of content-importing scripts in the Codex. If there’s a match, great! Follow the instructions and get to work. If all goes well, you’ll have migrated the content over without any trouble.

If your old CMS is not in the list or you don’t have a CMS at all and you’ve got fewer than 100 pages, then manual migration is probably the way to go. Copy and paste the contents, noting the old URLs as you go (tracking the migration in a spreadsheet is a good idea).

If you’ve got a custom CMS or a database of records without an importing tool and a high volume of content, then you might want to BRING IN A SPECIALIST TO MOVE THE CONTENT over before continuing. The higher the volume of content, the higher the chance of human error and the more important automating it becomes.

For our project, I’ve migrated the content manually and replaced the existing navigation with a WordPress menu. You can watch the process in this next screencast:

BRING OVER THE DESIGN With our content in WordPress, it’s time to bring over the design. Incidentally, if you’re considering a new design, then now is a great time to look at the many excellent WordPress themes out there, both in the official repository and in third-party marketplaces such as ThemeForest and Creative Market. For our purpose, I’ll assume that you’re happy with your design.

Evaluating A Design Evaluate the source code of a prospective design as best you can before tackling the migration. If the code is table-based or more complex than you’re comfortable with, then migrating the design might not be worth the effort. While anything is possible (I’ve migrated some complex table-based designs in my time), NOT EVERYTHING IS PRACTICAL.

Working With Source Code In my experience, the easiest way to migrate is to work directly with the source code in the browser. While having access to the original hosting environment can be helpful (especially when working with a lot of images and downloadable files), the ways that websites are built vary so widely that you’ll often have to reverse-engineer the original architecture in order to derive anything useful.

Going directly to the source code in your browser of choice will save a lot of time and, barring any important “behind the scenes” functionality, give you everything you need. Google Chrome is currently my browser of choice, and I’ve pulled our source-code samples directly from the browser. (In Chrome, go to Menu → Tools → View Source, or just right-click to bring up the contextual menu.)

CREATE A CUSTOM THEME If you’re new to them, learn about using themes in the Codex. For the migration process, you can either build a new WordPress theme from the ground up or modify an existing theme to meet your needs. I recommend the latter.

Most of my migration projects have started with the latest version of WordPress’ default theme (currently Twenty Twelve). Recently, I stripped down the default theme to create my own migration starter theme, which I’ll use in our example and which you’re welcome to use yourself. (Feel free to suggest improvements!) Let’s get to work.

Download a copy (ZIP) of the migration starter theme or follow along in your own theme of choice as we work through the relevant theme files.

1. STYLE SHEET Our first step is to bring over the styles from the old website. In most cases, this is as simple as searching the source code for references to .css and then copying and pasting the contents from those style sheet(s) into our own style.css. Let’s get to it.

* Open up style.css. * Replace the details of the theme (“Name,” “URI,” “Description,” etc.) with your own. * Paste in the styles from the old website. A Note About Images As you migrate the style sheet(s), search for and update any references to images. In general, I like to keep all images in an /images/ folder within the theme’s directory. More often than not, changing the locations of images referenced in the original CSS is necessary, and I make sure to update all references in the style sheet and templates accordingly.

2. HEADER The next step is to create the header for our new theme. Our objective here is to merge the structure of the current code base with WordPress’ templates. Here’s what we’re going to do:

* Replicate the HTML structure of the old website. * Replace the static menu with a WordPress-powered menu. * Use WordPress’ title tag and leave the wp_head hook in place. * Merge any other relevant tags from the old header. Let’s get into the code!

Original HTML

Vegan Food Pyramid

• Products
• Wallpaper
• About
• Contact

Merged Header (header.php) >

Vegan Food Pyramid

primary, container => false, menu_class => menu ) ); ?>

Explanation One of the challenges of migration is deciding whether to improve code as you go along. Our project has a few areas that could be improved, but Joshua and I agreed to leave them as is. Most of you will be tackling the migration of a design that hasn’t been coded to current best practices (although, in fairness to the original coder, they may have been best practices at the time).

IF TIME AND OPPORTUNITY ALLOW, I ENCOURAGE YOU TO IMPROVE ON THE CODE. Otherwise, take comfort in the fact that, with the website now on WordPress, improvements will be a whole lot easier down the road.

Let’s work through the changes we’ve made!

* DOCTYPE Make sure to carry over the same doctype. In this case, the original HTML already has an HTML5 doctype (a relatively rare occurrence on old websites). Using a modern doctype in a code base written for an older specification (such as XHTML or HTML4) could break the layout (especially in old browsers). * META TAGS I usually bring over the majority of meta tags as is, replacing them in WordPress. The exception in our case is the reference to the style sheet, which is being inserted automatically via wp_enqueue_style in the functions.php file. * SCRIPTS Scripts can be tricky. If a script belongs on every page (such as a tracking script or font script), then putting it directly in the header (or footer) file is fine. If it needs to appear only on certain pages, then a conditional tag will do the trick. As a best practice, register all scripts and add them to the header (or footer) via wp_enqueue_script. If you’re up for the challenge, I recommend doing it this way. (Check out a tutorial on enqueuing TypeKit the right way.) * WP_HEAD Leave at the bottom of the tag in the merged header file. WordPress uses wp_head, among other things, to enqueue scripts and style sheets that are referenced in the theme (usually in functions.php) and in plugins that you’ve installed. Without wp_head in place, most front-end plugins won’t work. * BODY_CLASS Notice our use of the tag. WordPress uses this to provide a series of helpful classes to the tag depending on the page being viewed. In our example, the classes weren’t being used. Yours might have unique IDs or classes on each page, in which case you can create a custom function using conditional tags to add the appropriate classes to the corresponding pages. Have a look at the Codex for some examples. * WORDPRESS MENUS Switching to a WordPress-powered menu is one of the more complex tasks in most basic migrations. It will be fairly straightforward for us. We have a menu with simple markup that uses an active class (generated via PHP) to indicate which page the visitor is viewing. The wp_nav_menu function is highly flexible and offers built-in functionality to handle the current state of an element in the menu. I’ve updated the references in the style sheet to the active class and changed them to use the equivalent generated by wp_nav_menu, which is current-menu-item. Watch the screencast on importing content to see how I’ve set up the menu for our example. And that’s a wrap! Let’s move on to the next piece.

3. FOOTER The footer is usually the most uneventful template in the migration process. As with the header, our objective is to merge the relevant parts of the original source code. Let’s get to it!

Original HTML

(c) 2013 VeganFoodPyramid.com

Merged Footer (footer.php)

(c) VeganFoodPyramid.com

Explanation Some footers are hard to migrate (such as ones with complex menus and widgets), but most are simple. In this case, we’ve merged the HTML with our footer template, making sure to preserve our reference to the wp_footer hook. We’ve also changed the date reference to use PHP, ensuring that it updates with each year.

4. HOME PAGE One of the challenges of a migration is that there are so many different ways to get the job done. The home page is a good illustration of this because it tends to be the most different from the rest of the website. Adopting the simplest method is usually best. I’ve opted to put all of the home page’s content directly in the template. Changes will be rare and can easily be made by editing the template.

Let’s look at the code, excluding the header and footer, which we’ve already covered.

Original HTML

Poster

A 30×20-inch poster illustrating over 125 vegan food items as an alternative to the traditional food pyramid. This poster will catch people’s attention and serve as a suggestion for food ideas.

$30 each

Includes free shipping worldwide

Buy

Postcards

Beautiful 4×6 postcards that can be mailed and shared with friends and family. Hand them out at events. Post them on walls. Share the vegan love!

$50 for 50

Includes free shipping worldwide

Buy

Merged Home Page (/page-templates/front-page.php)

Poster

A 30×20-inch poster illustrating over 125 vegan food items as an alternative to the traditional food pyramid. This poster will catch people’s attention and serve as a suggestion for food ideas.

$30 each

Includes free shipping worldwide

Buy

Postcards

Beautiful 4×6 postcards that can be mailed and shared with friends and family. Hand them out at events. Post them on walls. Share the vegan love!

$50 for 50

Includes free shipping worldwide

Buy

Explanation The front-page.php template begins and ends with a reference to the header and footer that we’ve just prepared. In between, we’ll merge the rest of the HTML, and we’ll use the get_stylesheet_directory_uri function, which will dynamically generate references to the images folder in our new theme.

5. STANDARD PAGE TEMPLATE With the header and footer done, the standard templates are usually quite easy. For brevity’s sake, we’ll go directly to the merged templates.

Merged Template (page.php)

Content Template (content-page.php)

>

Explanation There are several items to point out here:

* THE LOOP If you’re new to WordPress or programming in general, this piece of code in the #content container might look intimidating. The “loop” is code used by WordPress to display a post’s content. You can learn more about the loop in the Codex. Meanwhile, just make sure that it’s in there, or else the content you save in WordPress won’t show up. * GET_TEMPLATE_PART Our page template here employs the handy get_template_part function, which is a great way to keep content organized, especially in complex projects. Our website is simple enough not to warrant it, but I left it in just to show you. * POST_CLASS I also added a reference to

(with the corresponding post_class function) to make further customization of the design easier. 5. FULL-WIDTH TEMPLATE (FULL-WIDTH.PHP) Although not illustrated in the screencast, the design includes a full-width template for use on the “Wallpaper” page, while the standard page template is changed to a narrow width.

Let’s have a look.

Merged Template (templates/full-width.php)

Explanation With the template created, all that remains is to assign it to a page. From the “Edit Page” interface, find the “Page Attributes” box (usually right below the “Publish” box) and select “Full-Width Template” from the “Templates” dropdown menu.

6. EXTRAS Now let’s tackle some of the “extras” that sometimes come up as challenges during a WordPress migration.

* BREADCRUMBS Breadcrumbs are relatively common on websites. The easiest way to reproduce them is with a plugin. My current favorite is Breadcrumb NavXT (free). WordPress SEO also offers built-in breadcrumbs. * WIDGETS If the design you’re migrating has a sidebar, you could either reproduce it as is (the migration theme has a sample sidebar in place) or integrate WordPress widgets to allow for a dynamically managed sidebar. The folks at Automattic have prepared a handy guide to widgetizing themes. Start there. * RESTRICTED CONTENT In case some content needs to be restricted, WordPress offers basic password protection by default. If you want more control, use a plugin. For basic role management and content permissions, I recommend Members (free). For more advanced control (especially if payment is involved), consider Membership (which has basic and premium versions), s2Member (also free and premium) and WP-Members (free). * CUSTOM POST TYPES Some migrations, especially ones with a lot of different types of content, call for “custom post types.” You can learn about custom post types in the Codex. To set them up, I recommend using a plugin. Two good choices are Custom Post Type UI and Types (both free). REVIEW WEBSITE Now that we’ve wrapped up work on the theme, it’s time for a review. Work carefully through the pages on the migrated website. For a large website, focus on the different templates. As you review, here are some things to watch out for:

* BROKEN LINKS Make sure all links work as they should. If you have only a few pages, you can check manually. For an automated check, use Integrity (free, for Mac) or Xenu’s Link Sleuth (free, for Windows). * BROKEN STYLES Occasionally, for one reason or another, a design element of your website might have broken during the migration. Carefully compare the old HTML to the new to make sure you haven’t missed any important code and that the corresponding style sheet rules have been carried over. If all else fails, a quick rebuild of the design element on the new website might be in order. * BROKEN FUNCTIONALITY Test any functionality that you’ve migrated over, such as “Buy now” buttons, contact forms, newsletter opt-ins, “members-only” content, embedded maps, media players, etc. * TEMPORARY LINKS Depending on how you’ve carried out the migration, temporary links to a subfolder or testing domain might appear in your content or theme. You’ll want to update these before going live. Use the Search and Replace plugin (free) to check for and update links in your content. Setting Up Redirects If your link structure has changed (and it usually will, even if only slightly), make sure that visitors are redirected from the old pages to the new. For small amounts of content, one of the easiest ways to set up redirects is by adding them to the .htaccess file.

Open the .htaccess file in the WordPress directory. If you don’t see it, set your FTP client to show hidden files. Now, create redirect rules for each of the old pages. Be sure to put these rules _after_ WordPress’ block of rules.

Here are the rewrite rules for our links:

Redirect 301 /wallpaper.php http://veganfoodpyramid.com/wallpaper/ Redirect 301 /about.php http://veganfoodpyramid.com/about/ Redirect 301 /contact.php http://veganfoodpyramid.com/contact/ Redirect 301 /contactthanks.php http://veganfoodpyramid.com/contact/thanks/ If editing your .htaccess file is not an option or if you’re dealing with a lot of redirects, then have a look at Redirection (free).

ADVANCED TIP: If the volume of redirects is very high (which is likely with a large-scale migration and a custom importing process), then consider building a function that hooks into template_redirect, compares a generated list of cases, and then uses the wp_redirect function to redirect any matches.

GOING LIVE Going live with a website usually involves one of two tasks:

* Relocate WordPress from the development folder to the root directory. * Point the domain name from the old server to the new WordPress server.

Relocating WordPress If you set up WordPress in a subfolder (as we did), then going live involves a few simple steps. Follow the guide to using a pre-existing subdirectory installation.

Once you’ve made the change, check immediately for any broken links that you may have missed in the final review.

Pointing To A New Server If you set up WordPress on a new server, then you probably used a temporary domain. Accordingly, remove references to the temporary domain before pointing the domain to the new server.

Also, if you’re planning to update the name servers for your domain, then first resolve any dependencies in the current DNS records (such as hosted email and third-party services). I usually go live with a domain by updating the A records, leaving the name servers in place.

CONCLUSION And there you have it! A SUCCESSFUL WORDPRESS MIGRATION IS ALL ABOUT THE DETAILS, and while this guide is by no means comprehensive, you now have a good outline of the process and a sense of some of the challenges you’ll encounter, along with ideas for solving them. If you run into challenges along the way, share them in the comments below. Now get migrating!

_(al)_

------------------------- © Jonathan Wold for Smashing Magazine, 2013.

Now and again, I hit the swimming pool. It’s a good way to exercise, but also to relax after a long day in front of my PC. I can do quite a few laps in my front crawl, but only because I don’t use my legs much. I kick steadily to ensure that my legs stay lifted and don’t slow me down. I DON’T USE MY LEGS MUCH FOR FORWARD PROPULSION. An instructor once explained to me that legs can definitely help with propulsion in the front crawl, but only at the cost of much higher energy consumption.

He also explained that champions use their legs a lot. Their hearts are powerful, and they can happily sacrifice the extra effort for the small yet significant gain in speed. People with modest competitive ambitions are typically better off with moderate leg usage.

Does this relate to mobile Web development, responsive Web design and server-side device detection?

The analogy is a stretch, but YES, IT DOES. As the inventor of WURFL, I used to live in a world where mobile devices were so limited in capabilities that there was no way a commercial website and its corresponding mobile website could be supported through a unique set of HTML pages without the support of some server-side logic. Strategies to detect and tweak content for mobile devices varied from simple detection scripts to the adoption of full-fledged device description repositories (DDR) such as WURFL.

Today, things have, to a large extent, changed. Many still have a feature phone, but the majority of users who care about accessing the Internet from their mobile devices will have a smartphone. A 2013 smartphone means the following: a fast connection, a great WebKit-based browser, a 320-pixel wide (or wider) touchscreen and a great operating system that allows for the installation of apps.

This evolution has turned the mobile Internet into A SWIMMING POOL AVAILABLE TO EVERY WEBMASTER. Programming strategies such as progressive enhancement (PE) and responsive Web design (RWD) enable everyone to make their full websites usable enough on smartphones from a single set of HTML pages -- i.e. with no need for server-side device detection. This is awesome. Webmasters can now make their websites more mobile-friendly without introducing a significant amount of extra complexity. Yet, just like in my initial analogy, the saving is only achieved at the cost of sacrificing certain aspects of the mobile UX that “champions” would not be OK with sacrificing.

In a previous article by Ronan Cremin and me, “Server-Side Device Detection: History, Benefits and How-To,” we explored the different aspects of client-side approaches versus server-side approaches, and we concluded that server-side strategies still offer a lot to mobile Web developers. I won’t repeat it here; rather, I will go one step further and explain how the two worlds can happily coexist for everyone’s benefit.

CLIENT-SIDE VS. SERVER-SIDE: A FALSE DICHOTOMY Most IT people are familiar with the saying, “When all you have is a hammer, every problem looks like a nail.” This is perfectly applicable to mobile development, where, in my experience, developers with a JavaScript and CSS background tend to favor client-side solutions to the problem of device diversity, while developers with traditional system development skills find server-side approaches more natural.

Unsurprisingly, there are pros and cons to both approaches, and, more importantly, the two approaches are not mutually exclusive and can be made to work together. After all, for any organization that offers a website, the ultimate purpose is to create the GREATEST USER EXPERIENCE POSSIBLE for its users within the constraints of the project’s timeline and budget.

BEST OF BOTH WORLDS When it comes to building a strategy for a website that is friendly to mobile users, there is a whole range of possibilities. At one extreme, a designer might adopt a purely responsive website because they cannot afford to maintain a server-side detection component (or simply because they do not find enough value in the extra complexity). At the other extreme are large companies whose websites (and mobile websites) address particular quirks of popular devices. This approach requires an investment and dedicated team so large that typically only major Internet companies (think Facebook, Yahoo and Google) would go for it.

Most other companies will find THE OPTIMUM POINT SOMEWHERE BETWEEN THE TWO EXTREMES by segmenting the world of connected users in ways that make the most sense in their markets. Such segmentation will need to rely on some form of server-side detection.

One way to put it is that one should adopt a “best of both worlds” hybrid approach. In this article, I will show an example of this.

Every software project is one-off. The Web is no exception. Nor is mobile Web development, where the super-rapid progress of mobile devices is constantly turning best practices into moving targets. For this article, I figured that nothing could make the point better than a real example with real code.

MY EXAMPLE IS A CROSS-BROWSER AND CROSS-DEVICE SLIDESHOW. I will show how server-side and client-side detection can be made to work together to deliver a great UX on a variety of clients.

SEGMENTATION (GOOD OL’ DIVIDE AND CONQUER) The slideshow will be made available to the following classes of HTTP clients:

* non-smartphones (or feature phones), * smartphones, * tablets and desktops. I have always called these “segments,” and I have referred to the splitting up into segments as “segmentation.” The key point is that each segment will be provided with a fundamentally different UI structure. Such segmentation will be supported through server-side detection.

Within each segment, there will still be space for further optimization of the UX. Such optimizations will happen with RWD and device detection. Notably, this approach will be used to obtain pictures in different sizes and to address the bandwidth problem, particularly for mobile devices.

Let’s start by sketching the different UIs for the different classes of HTTP clients (i.e. segments).

Non-Smartphones Non-smartphones are commonly referred to as feature phones in the industry. There is no standard definition of what a smartphone is, but a device that possesses the following features would likely be called a smartphone by most:

* touchscreen; * a screen that is 240-pixels wide or wider; * Android 2.2, iOS, Windows Phone 7.5 or higher, RIM OS 7 or higher, Symbian Belle or higher, Nokia N9 WebKit-based browser; * not a tablet. This is a totally arbitrary definition, but good enough for the purpose of this article.

Devices that do not support one or more of the above features will be considered feature phones.

Because no assumption can be made for non-smartphones, we will assume a small screen, no touchscreen and limited bandwidth (which entails the need to minimize the number of HTTP requests required to download all of the content).

Please note that the lack of a touchscreen might require users to click the “down” button multiple times to get to the icon they wish to select.

The following wireframe nicely illustrates what we are getting at:

_Feature phones (i.e. non-smartphones) have relatively small screens (typically narrower than 240 pixels). The presence of a touchscreen should not be assumed for devices in this segment._

Smartphones Smartphones have a large screen, and users don’t have to click their way through icons to get to the one they want. They simply touch it. Because of this, a UI such as the following is better suited to them:

_Smartphones have large screens (240 pixels or wider). The presence of a touchscreen and of basic media queries for changes in orientation may be safely assumed._

Tablets And Desktops In the case of tablet and desktop browsers, we can safely assume that a large screen is available. In this case, consolidating the two views (i.e. the navigation and the actual picture) into a single screen makes sense:

_A screen 700 pixels wide (or wider) may be assumed._

Of course, I created a single segment for tablets and desktops for illustrative purposes, but a real project might segment differently, based on the business model of the organization and the traffic it sees from different classes of devices.

Before delving into the code to implement this, I should discuss a few aspects of mobile development.

IMPORTANT NOTE ABOUT MOBILE BANDWIDTH: SPEED ISN’T EVERYTHING US carriers (i.e. network operators) boast in their advertising about their increasingly faster 4G networks and the blazing download speeds that their customers can get. My experience (and the experience of others) is that those figures are sometimes truthful under good network conditions, as in the case of a large single download or of video streaming. In practice, things are a bit more complicated. The overhead of establishing an HTTP connection in mobile is high.

Many browsers and devices open only one or two concurrent connections with the server (partly because of what the HTTP specification says, and partly because of hardware limitations). Keep-alives cannot be assumed to always work as one would expect in mobile, because of strategies that the devices follow to save battery power.

The problem is at the lower levels and is rooted in the fact that mobile networks and TCP/IP were not built to play well together to begin with.

Techniques such as “domain sharding” (i.e. fooling the browser into believing it’s talking to different servers) help to increase the number of concurrent connections. However, if you want to increase the download speed (both real and perceived) of a website, limiting the overall number of HTTP connections is your best bet.

MAY YOUR DAYS BE MERRY AND YOUR URLS UNIQUE People share links on Twitter, Facebook, Google+ and a lot of other services these days. This is good, but it has also exposed a shortcoming with a popular approach to managing the mobile channel -- i.e. creating a separate mobile website (with separate URLs to the mobile view of the content). In short, a user will share http://m.coolsite.com on Twitter, and users on desktops and tablets will be offered a sucky UI. Having http://www.coolsite.com serve both the Web and mobile experience would effectively solve the problem.

As my last article explains, THERE ARE WAYS TO HAVE A SINGLE URL “MULTI-SERVE” CONTENT FOR DIFFERENT MEDIA. Of course, this requires a bit more design and work from the service architect as compared to purely client-side approaches.

In the case of PE and RWD, the “uniqueness” of the URL comes free of charge. In the case of server-side detection, a strategy to multi-serve content from a unique URL needs to be designed into the system. We will see one way to achieve this in the code discussed further down.

CONTENT = CONTENT + PRESENTATION? A LITTLE (BUT IMPORTANT) ASIDE Ethan Marcotte, arguably the inventor of RWD, correctly identifies the URL issue in his book _Responsive Web Design_:

"I do think fragmenting our content across different “device-optimized” experiences is a losing proposition, or at least an unsustainable one."

This sentence has been quoted endlessly, and it seems hard to disagree with. Yet, it contains an ambiguity that makes it very debatable, to say the least. WHAT ETHAN CALLS “CONTENT” HAS HISTORICALLY BEEN REFERRED TO AS “PRESENTATION” BY MOST. In fact, I could easily argue that separation of content and presentation is the foundation of a plethora of Web programming frameworks, such as model-view-controller (MVC), but also Windows DNA in the late ’90s.

While I am aware that designers will argue that THE DIFFERENCE BETWEEN CONTENT AND PRESENTATION IS BLURRY (advertising is the best example of this), such a differentiation has been very helpful to Web programmers in multiple ways over the past 15 years. In general, professionals are much better off preserving this separation, rather than blurring the difference between the two.

Software architects should obviously _not_ fragment the content managed by their system. At the same time, they should be ready to multi-serve the presentation of the same data to users of different media and different devices in the name of an optimal UX. I would go so far as to argue that PE and RWD are also about providing multiple presentations of the same content, inasmuch as the clever use of grids and media queries allows developers to confine the “multi-serving framework” to a single page.

End of the aside.

GETTING BACK TO URL UNIQUENESS, it is obvious that, in the case of server-side detection, a URL strategy must be designed with extra use of resources. Of course, webmasters have managed similar issues all their careers. Internationalizing a website presents the same challenges: one could have content served in multiple languages from the same URL (or even JSP or PHP page) or simply provide sibling websites, one for each supported language. Support for the potential lack of JavaScript presents a similar issue, as does the fact that an international content provider may wish to offer different (i.e. more relevant) content to visitors from different geographic regions, even where the language is the same. Supporting this means extra effort and cost. Typically, after the cost versus benefit equation is solved, some companies will go for the benefit in spite of the cost.

After so many words, let us see how the following code implements everything we’ve illustrated above.

THE CODE Everything that has been discussed so far is illustrated in practice with a self-contained example that I built (along with my friend Steve Kamerman, COO at ScientiaMobile) to reinforce the points in this article. Be aware that, for the sake of clarity, the example hardwires many of the resources that would normally be isolated in separate databases or configuration elements.

Here is a list of the main components in the code:

* a DDR; * an MVC framework; * a controller with the segmentation logic; * a server-side image-resizing framework; * the views -- feature phone, smartphone and tablet/desktop, in our case. Let’s discuss each of them.

Device Description Repository A DDR is a software framework that enables an application to associate an HTTP request with the properties of the client (Web browser, mobile device, Internet-enabled wristwatch, etc.). In our example, I will be using ScientiaMobile’s DDR, WURFL Cloud, because it’s the easiest to install on all platforms and also comes with a free offering for those who want to play around with it.

Of course, any other DDR could be used in place of WURFL Cloud, including AGPL-licensed WURFL or other open-source frameworks based on user-agent string analysis through regular expressions.

For the purpose of this article, here is the core bit of code that explains how to use the DDR (in the index.php file):

: require_once dirname(__FILE__)./lib/WurflCloudClient/Client/Client.php; : // Disable caching for testing $cache_enabled = false; $wurfl_config = new WurflCloud_Client_Config(); $wurfl_config->api_key = XXXXX:YYYYYYYYYYYYYYYYYYYYYYYYYYY; : if ($cache_enabled) { $wurfl = new WurflCloud_Client_Client($wurfl_config); } else { $wurfl = new WurflCloud_Client_Client($wurfl_config, new WurflCloud_Cache_Null()); header("Cache-Control: no-cache, must-revalidate"); header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); } $wurfl->detectDevice(); NOTE: The cache is disabled because this is handy for testing purposes. But you’ll want to enable it on a production website, or else every HTTP request from your users will be a request to the cloud.

Once this code has run, you will be able to look up device capabilities on your server, without any need to interact with the client through JavaScript or the like, as simply as this:

$wurfl->getDeviceCapability(is_tablet) All of the magic of looking up the HTTP request and recovering a profile for the device is happening under the hood.

Model-View-Controller Framework MVC is a popular programming pattern among Java developers that over the years has made inroads among programmers of other languages (including PHP). In short, the MVC framework analyzes an incoming HTTP request and “dispatches” the actual handling to a different PHP page that has been deemed to be more apt for the job. In our case, the framework will route the HTTP request to the PHP page that would implement the best UI for that “segment.”

For the record, the MVC framework we’re using in our example is homemade, but Steve explains that it was inspired by a micro-framework named Silex.

The framework itself is implemented in the lib/SimpleApp.php file:

require_once dirname(__FILE__)./lib/SimpleApp.php; : $app = new SimpleApp(); Once the MVC framework is included, dispatching an HTTP request to the right view (see below) is as simple as this:

$app->render(image/smartphone.php, $view_data); The interesting part is that the URL will not be affected by this. Users will only see the index.php page that responded to the request. This effectively solves the problem of URL uniqueness that we discussed above.

Controller The controller (the “C” in MVC) is in charge of segmentation (i.e. deciding the view to which a certain HTTP client should be directed based on its profile). Here is the core of the controller (in index.php):

if ($wurfl->getDeviceCapability(is_smartphone)) { $app->render(index/smartphone.php, $view_data); } else if ($wurfl->getDeviceCapability(is_mobile) && !$wurfl->getDeviceCapability(is_tablet)) { $app->render(index/featurephone.php, $view_data); } else { $app->render(index/desktop.php, $view_data); } In light of what we have explained, this part should be rather self-explanatory: smartphone.php handles smartphones, featurephone.php handles feature phones, and everything else (including tablets) is handled by desktop.php. There are actually two sets of views, one that manages the discovery page (i.e. the thumbnails with pictures) and one that represents the single picture.

The is_smartphone capability is a so-called “virtual capability” -- i.e. a computed property that relies on other capabilities and that represents ScientiaMobile’s understanding of what a smartphone is. A lot of people find this handy. Of course, nothing prevents a WURFL user from choosing the capabilities and rolling a particular segmentation that make the most sense for their business model.

Image Resizing (RESS) RESS stands for “REsponsive images and Server-Side components,” making it the most screwed-up abbreviation I have ever seen in my life. Because it is now common, though, I will use it, too. The premise of RESS is fairly reasonable: RWD is cool, but SENDING 500 KB PICTURES TO A MOBILE DEVICE IS NOT A GOOD IDEA for a variety of reasons. This is why even the most inveterate RWD promoters will concede that resizing pictures on the server in order to speed up downloading and rendering on mobile devices is still a good idea. Of course, CSS and JavaScript files are also resources that you’ll want to make as light as possible. These also fall under the RESS umbrella.

Users of WURFL Cloud also have access to a service called Image Resizer. In short, Image Resizer enables you to create a URL that piggybacks the following bits onto itself:

* the URL of the original picture, * a combination of parameters that specify how the picture should be resized and manipulated. Requesting the URL will result in a picture with the desired features being obtained. For the record, other services of this kind are around, such as Sencha.io Src and the up-and-coming WhateverWeb, which promises to go beyond simple image resizing. Call me a romantic, but I prefer that we eat our own dog food for this example.

A photographer also graciously gave me some pictures of Chicago for this article, which I’ve hosted at http://cto.scientiamobile.com/chicago/ (i.e. in a place where Image Resizer can pick them up):

Let’s see how Image Resizer is used in practice (see views/index/smartphone.php):

// Compute the size of the image thumbnails $thumb_width = 95; $thumb_height = 95; $rszr_tumbnail = "http://rszr1.wurflcloud.com/234341/w_$thumb_width/ h_$thumb_height/m_cropbox/"; :

$image) { ?>

:

This will generate markup like the following snippet:

In reality, I’ve cheated a bit. I cut some interesting bits from the code above. In particular, I’ve removed a trick to use a really important technique called the data URI scheme, which enables developers to nest pictures in the HTML itself in the form of ASCII Base64 garbage. As you can imagine, not all devices support the feature (although smartphones usually do). This is where WURFL’s image_inlining capability, along with the ability of the image resizer to provide the picture already in Base64 format, comes in handy. The image_inlining will tell you whether the data URI scheme is supported:

$image_inlining = $wurfl->getDeviceCapability(image_inlining); if ($image_inlining) { $rszr_tumbnail = "http://rszr1.wurflcloud.com/234341/w_$thumb_width/ h_$thumb_height/m_cropbox/in_true/"; } else { $rszr_tumbnail = "http://rszr1.wurflcloud.com/234341/w_$thumb_width/ h_$thumb_height/m_cropbox/"; } :

$image) { ?>

In the case of a device that supports image inlining, the code above will produce the following:

As we discussed earlier, this is particularly crucial because of the importance of minimizing the number of HTTP requests demanded by a mobile device to download a page, an aspect that is simply not worth optimizing in classic Web programming: too much extra work for way too little gain.

Of course, the data URI scheme will greatly increase the perceived download speed on smartphones and non-smartphones alike.

The Views: Feature Phone, Smartphone And Desktop/Tablet The three segments we initially defined map one to one with our three views (feature phone, smartphone and tablet/desktop), according to the MVC paradigm. Each view offers a user experience that is best suited to the respective class of devices and browsers.

It goes without saying that adopters of a DDR still retain control over the UX of a deployed application simply by configuring a device to access a given view (for example, by downgrading a misbehaving smartphone to the feature-phone view).

The feature-phone view is particularly interesting because you’ll want to serve XHTML Mobile Profile (XHTML MP) as a markup to those devices. Developers who approach mobile today might get away with ignoring XHTML MP, but for years XHTML MP has been the standard mobile Web markup. Still today, smartphones will immediately recognize a website created in XHTML MP as being a mobile website, even when no viewport meta tag is available. Be aware that XHTML MP is typically better served with a different MIME type than text/html.

NOTE: Covering XHTML MP is beyond the scope of this article. If you are curious about the world of mobile programming on feature phones, my document “Global Authoring Practices for the Mobile Web” enjoyed some popularity for some time. Most people find it very informative still today.

The following screenshots visualize what the different UIs mean in practice:

_The view on feature phones._

_The view on smartphones._

_The view on tablets and desktop. Above: The page on an iPad._

_Here is the same page on the Xbox 360 (IE 10)._

Of course, this example is just a proof of concept. Nothing prevents a programmer from making the desktop view even more responsive than it already is, or from adopting something like the good PhotoSwipe to provide interactive slideshows on smartphones and tablets (but not on older phones, where they would be unlikely to work). Divide and conquer.

CONCLUSION Purely client-side approaches such as RWD and PE can make Web pages accessible on smartphones. For companies and organizations, this means that supporting mobile devices could be cheaper now than it was a couple of years back. Yet, these savings come at the cost of sacrificing certain aspects of a full-fledged cross-channel Web offering.

Large organizations may still want to adopt server-side device detection in some form to deliver a great UX to everyone who accesses their websites. While RWD and PE strategies can (and should) be adopted by companies, a hybrid client- and server-side approach is the most likely to DELIVER A GREAT SERVICE TO DESKTOP, TABLET AND MOBILE USERS ALIKE.

We’ve discussed an instance of such a hybrid approach by showing how segmentation, server-side resized images and the data URI scheme are key components to a great user experience across devices and browsers.

Have a look at the demo app.

_(al) (ea)_

------------------------- © Luca Passani for Smashing Magazine, 2013.

Storytelling takes many forms. In the past, stories were told orally, with people telling and retelling myths, fables and even histories. As writing technology became more prevalent, we began to record our stories, and we told them in the pages of books. Now, our society is awash in different devices and technologies, and those traditions of spoken stories and printed stories are blurring.

Multi-screen narratives are being told across all kinds of platforms, pages and devices, making for truly immersive experiences. We are watching them, tapping them and learning from them. They immerse us in the storyteller’s world. This article outlines what I believe are the FIVE ESSENTIALS OF TELLING MULTI-SCREEN STORIES.

HOW I FELL IN LOVE WITH INTERACTIVE STORYTELLING First, a little background. My childhood was spent in Nigeria, West Africa. I am a member of the Tiv tribe, a group of about 6 million people clustered in Nigeria’s Benue River Valley. As a child, I heard a lot of Nigerian folktales, about animals, humans and even magic. In Nigerian narrative tradition, stories are often told orally, in front of a gathered audience. During festivals and cultural events, men even dress up in elaborate costumes and perform stories for the crowds. I have vivid memories of these stories and have always been curious about how they could be translated into something digital and interactive.

_The Kwagh Hir, or Thing of Magic, my tribe’s largest cultural festival (Image: Naptu2)_

Those fables are a piece of my cultural inheritance. They always seemed to contain essential truths about humans. Take the story of the Ear and the Mosquito. One day, the Ear steals food from the Mosquito and refuses to pay it back. In anger, the Mosquito visits the Ear every evening, demanding the food to be returned, annoying Ear all night with his buzzing. It’s an old tale, with many versions, but the moral is consistent: don’t steal from your friends.

CREATING MODERN, INTERACTIVE VERSIONS OF THESE STORIES is possible, but HOW EXACTLY DO WE DO THAT? Let’s begin by talking about what I mean by the word “multi-screen.”

A BIT ABOUT CONTEXT AND SCREENS When speaking about multi-screen storytelling, remember that screens have different contexts, not only different capabilities. The same screen on which you carelessly watch videos at home becomes a closely guarded viewport when you’re watching a movie on a crowded train. The context in which people view stories is more important than the device’s specifications. When we tell interactive stories, we need to be aware of this, and embrace it.

I like to focus on the following screens:

* Sensors (Twine, GPS, Arduino, motion detectors, etc.) * Mobiles and tablets (phones, tablets, laptops and everything in between) * Flat-screens (desktops, TVs, etc.) * Public and immersive displays (store kiosks, large stadium screens, projectors, Kinects, etc.) Not all of these need to be used at the same time, because they won’t all be appropriate to the story you are telling. Context is extremely important.

Now, as promised, here are the FIVE ESSENTIALS OF MULTI-SCREEN STORYTELLING.

1. DIVIDE YOUR STORY INTO SEPARATE CONTENT BLOCKS When we create multi-screen narratives, we need to FIND NATURAL BREAKPOINTS in the story, places where the VISUAL OR NARRATIVE CONTENT can easily be separated. This enables us to deliver different segments to different devices, in different contexts.

Kolobok is a Slavic children’s story about the adventures of a round yellow cake. For the Moscow International Festival, a large team of designers and animators from SilaSveta Studio incorporated it into a truly fascinating demonstration of storytelling. Before the show, the team set up a large touchscreen at the children’s height. With their hands, the kids could manipulate parts of the animation by adding movement and color.

_A public display for children to play with_

For the show itself, the full story was projected onto the facade of a large building, allowing the crowd of adults and their children to watch the narrative unfold. Along with sound, it made for another discrete content block, one that closely resembled a 3-D movie.

_The full animated story in front of a large festival crowd_

While the touchscreen and the movie were different views of the same content, they could exist as independent pieces and did not have to appear next to each other. The SilaSveta team found the natural breakpoints in its story and created two separate visual experiences to match them.

Questions To Ask * WHERE ARE THE BREAKPOINTS IN THE STORY? Divide your content so that it makes sense in context. The practice of responsive design gives us numerous guidelines on how to do this. * CAN THOSE CONTENT BLOCKS EXIST INDEPENDENTLY? Sometimes, the answer is no, but it depends on the story. In the Kolobok example above, they can. In other interactive stories, such as Snow Fall from the New York Times, the blocks are chapters in a single story and should be kept together. 2. OFFER PEOPLE MULTIPLE PERSPECTIVES Bear 71 is an award-winning multi-screen experience created by Jeremy Mendes and Leanne Allison. The creators tell the story of a bear living in Banff National Park in Canada. It feels like a cross between a role-playing game and a TV documentary, and as a linear narrative with a non-linear interface, it works beautifully.

_The Bear 71 story is told in a highly abstracted interface._

MULTIPLE VIEWPOINTS ARE ACCESSIBLE. Online, you roam in a stylized landscape, watch crittercam footage from the forest, and otherwise live as bears do — freely. Even though it may look like a game interface, you are not so much “playing” as you are participating in a story. Watching real crittercam footage, you see what the forest silently sees. You also have the option to turn on your webcam (“stealth mode”) to see other users around the world, all watching the same story online.

During shows and installations, the team responsible for Bear 71 set up augmented-reality applications and motion-detection cameras, so that visitors could experience what it’s like to have their pictures taken with one. By playing with the augmented-reality apps and the motion-detection cameras at the installations, USERS GOT A BIT OF THE SAME PHYSICAL EXPERIENCE THAT THE BEARS HAD.

Questions To Ask * DOES THE NARRATIVE CHANGE WHEN VIEWED FROM A DIFFERENT PERSPECTIVE? A variety of perspectives can make a narrative much more fascinating. Bear 71 forces us to see the world first from the bear’s perspective and to sympathize with its loss of habitat, but other viewpoints take a slightly different angle. The voyeurism common in our digital sharing culture takes on a different meaning when used for animal surveillance. * WHAT DATA SETS CAN BE USED IN THE NARRATIVE? Bear 71 cleverly combines crittercam video, GPS data, cell tower data, augmented reality, and topographical data. The photographs of visitors to the installation provide an additional emotional layer of data. The data we bring into our stories helps to define additional viewpoints and characters. 3. REDEFINE A TRADITION As Western culture has moved more deeply into Nigeria, Nigeria’s traditions are weakening. I wanted to take a piece of my culture and put it in the cloud, instead of leaving it locked in the heads of our oral storytellers. That meant redefining how the stories are relayed, how they are saved and, most importantly, what messages they convey to the audience.

In 2011, I started a project named Pixel Fable in which I take those traditional stories and reinterpret them online. In essence, I’m creating an INTERACTIVE ARCHIVE OF NIGERIAN STORIES. As mentioned earlier, the oral histories of Nigerians are rich, but capturing them and translating them into digital stories means they will reach a wider audience. About 25% of my website’s visitors come from the US, while another 25% come from Japan. Canada, France and Germany also send a fair amount of traffic.

Pixel Fable uses responsive websites, iOS apps and augmented-reality animations to reinterpret Nigeria’s oral history.

_An introductory screen from “Cricket and Mud Brick,” a new Pixel Fable story built with the Tapestry app_

I’ve relied on TWO PRIMARY CONTEXTS TO REINTERPRET THE OLD NIGERIAN STORYTELLING TRADITION. The first is people on their tablets and phones, clicking on and reading the stories. The spread of mobile devices makes this inevitable — why not tell African fables in a more accessible context? The second is my attempt to update the moral lessons for our modern age. While the original story of the Ear and the Mosquito may be a funny tale about annoying insects, the lesson can be updated to speak about how mosquitoes spread malaria in Nigeria. There’s room to redefine our old myths for the 21st century.

Questions To Ask * WILL PEOPLE LOVE OR HATE THE REIMAGINED VERSION? Not every fable or myth can (or should) be recreated digitally. However, if people have an emotional reaction to a story that you have designed and pushed out to multiple screens, that is usually a good sign. * IF PEOPLE TALK ABOUT YOUR NARRATIVE, WILL IT BRING ABOUT CHANGE IN SOCIETY? Each Pixel Fable story has a message. Most fables do. Some revolve around love triangles, others around the wisdom of elders, and there’s even one about why you shouldn’t get angry at your friends. They are small messages, but put together, they force us to reconsider how we treat the narrative history of people in Nigeria and West Africa. 4. IMMERSE PEOPLE IN THE NARRATIVE The Walking Dead, the famous comic and now TV show, used a polling Web app (AMC’s Story Sync, if you like marketing-speak) to ask viewers questions and show related content as an episode was being broadcast on TV. While the app was simply timed to each scene, it was an experiment in multi-screen storytelling that invited AUDIENCE PARTICIPATION, not just audience attention. Polling has a gimmicky feel to it, but that probably came about as a result of Hollywood pressure and doesn’t reflect the value of the concept in general.

_Polling and syncing apps extend narratives from the TV to the couch._

The creators also added mobile gaming to the mix, bringing viewers “into” the story in a completely different way, in different contexts.

All of these facets of each story’s arc ENABLED PEOPLE TO IMMERSE THEMSELVES in this apocalyptic narrative. Jason Spero of Google notes the need for a seamless experience as users move between devices. Other people, however, say that a second-screen experience can be extremely distracting, forcing viewers to miss key parts of the TV show. It is the opposite of an immersive experience, they say, and is confusing to use. In my opinion, each content block should work independently to avoid putting users in this position.

Questions To Ask * WILL PEOPLE FORGET WHERE THEY ARE? I’ll be the first to admit that this is not always a good thing. I can’t count the number of times that I’ve almost missed my train stop because my head was buried in my phone. Context, not only device capability, is key. Do you want users to get lost in the story or just engage in a manageable chunk? * DO THE SCREENS YOU HAVE CHOSEN FEEL NATURAL? By this, I’m not referring to pixel density. That is simply impossible to control, and if the story if good, it won’t matter anyway. The screens that people choose will depend a lot on the tasks they want to complete, so make your story feel natural for whatever content block they are interacting with. 5. DESIGN CONTEXTUAL INTERACTIONS Recently, a number of storytelling apps have relied on location to serve additional content, much in the same way that Foursquare or Google Maps do. The Silent History is a dystopian science-fiction story about children who do not speak. The iPad app contains the whole story, but by visiting certain geo-tagged locations, users can access additional content.

For a novel about children all over the US, INVITING READERS TO PHYSICALLY GO TO WHERE THE STORY’S KIDS ARE makes perfect sense. The additional contextual interaction makes the story more layered and thought-provoking, in a way that a simple app would not be.

We use map data every day, to look for restaurants, check the weather, see road conditions and even check for public transit delays. Other CONTEXTUAL INTERACTIONS make sense when creating digital stories: taking photographs, texting, sharing and saving information, even body motion. Use these, along with your UI and UX skill sets, to devise new storytelling methods.

Questions To Ask * DOES THE DEVICE MATTER? With the rise of responsive design workflows, our content should not be device-dependent. Some things, however, such as camera or GPS functionality, may be integral to a part of your story, and so the device would need to be factored in. * SHOULD THE INTERFACE BE DESIGNED AS A SEAMLESS PART OF THE NARRATIVE? As people who work on the Web, we really have a strength here. If we choose to make the interface part of the story, then we can rely on our experience in building websites and content management systems. * WILL YOUR STORY “REMEMBER” ANYTHING? As a child, I folded over the top corner of the page when I had to put a book down. It was a simple way to keep my place. With a narrative split across multiple devices, it might be necessary to design an interaction that flags where you’ve gotten to and then returns you there when you visit again. That all depends on the content, but the question does need to be asked. Everyone hates losing their place on the Internet and having to navigate back, so perhaps we should enable a memory in our stories as well. CONCLUSION We have conceptualized different uses of multiple screens to tell stories. All of us, from every corner of the globe, have intensely rich cultures FILLED WITH STORIES AND FABLES. Using them to create interactive narratives is another way to explore the power of the Web, to wow people and to record our cultural history.

I would love to see what you come up with, or hear about other examples of clever digital storytelling.

_(al) (ea)_

------------------------- © Senongo Akpem for Smashing Magazine, 2013.

The element is a new addition to HTML5 that’s being championed by the W3C’s Responsive Images Community Group (RICG). It is intended to provide a declarative, markup-based solution to enable responsive images without the need of JavaScript libraries or complicated server-side detection.

The element supports a number of different types of fallback content, BUT THE CURRENT IMPLEMENTATION OF THESE FALLBACKS IS PROBLEMATIC. In this article, we’ll explore how the fallbacks work, how they fail and what can be done about it.

THE ELEMENT AND FALLBACK CONTENT Like and , uses elements to provide a set of images that the browser can choose from. The elements may optionally contain type and media attributes to let the browser know the file type and media type of the source, respectively. Given the information in the attributes, the browser should render the first with a supported file type and matching media query. For example:

For situations in which a browser doesn’t know how to deal with (or or ) or cannot render any of the elements, a developer can INCLUDE FALLBACK CONTENT. This fallback content is often either an image or descriptive text; if the fallback content is an , then a further fallback is provided in the alt attribute (or longdesc), as normal.

The element differs from and in that it also allows srcset. The srcset attribute enables a developer to specify different images based on a device’s pixel density. When creating a responsive image using both and srcset, we might expect something like the following:

The idea behind a example like this is that exactly one image should be downloaded, according to the user’s context:

* Users with support and a viewport at least 40 ems wide should get the big image. * Users with support and a viewport narrower than 40 ems should get the med image. * Users without support should get the fallback image. If the browser chooses to display the big or med source, it can choose an image at an appropriate resolution based on the srcset attribute:

* A browser on a low-resolution device (such as an iMac) should show the 1x image. * A browser on a higher-resolution device (such as an iPhone with a Retina display) should show the 2x image. * A browser on a next-generation device with even higher resolution should show the 3x image. THE BENEFIT TO THE USER IS THAT ONLY ONE IMAGE FILE IS DOWNLOADED, regardless of feature support, viewport dimensions or screen density.

The element also has the ability to use non-image fallbacks, which should be great for accessibility: if no image can be displayed or if a user needs a description of an image, then a

or or

or any other element may be included as a fallback. This allows for more robust and content-appropriate fallbacks than a simple alt attribute.

THE FALLBACK PROBLEM Right now, the element is not supported in any shipped browsers. Developers who want to use can use Scott Jehl’s Picturefill polyfill. Also, Yoav Weiss has created a Chromium-based prototype reference implementation that has partial support for . This Chromium build not only shows that browser support for is technically possible, but also enables us to check functionality and behavior against our expectations.

When testing examples like the above in his Chromium build, Yoav spotted a problem: even though is supported, and even though one of the first two elements was being loaded, the fallback was _also_ loaded. TWO IMAGES WERE BEING DOWNLOADED, EVEN THOUGH ONLY ONE WAS BEING USED.

This happens because browsers “look ahead” as HTML is being downloaded and immediately start downloading images. As Yoav explains:

"When the parser encounters an img tag it creates an HTMLImageElement node and adds its attributes to it. When the attributes are added, the node is not aware of its parents, and when an ‘src’ attribute is added, an image download is immediately triggered."

This kind of “look ahead” parsing works great most of the time because the browser can start downloading images even before it has finished downloading all of the HTML. But in cases where an img element is a child of (or or ), the browser wouldn’t (currently) care about the parent element: it would just see an img and start downloading. The problem also occurs if we forget about the parent element and just consider an that has both the src and srcset attributes: the parser would download the src image before choosing and downloading a resource from srcset.

In all of these cases, we would have multiple images being downloaded instead of just the one being displayed. But who cares? Well, your users who are downloading extra content and wasting time and money would care, especially the ones with bandwidth caps and slow connections. And maybe you, too, if you’re paying for the bandwidth you serve.

A POTENTIAL SOLUTION This problem needs both short- and long-term solutions.

In the long term, we need to make sure that browser implementations of (and and ) can overcome this bug. For example, Robin Berjon has suggested that it might be possible to treat the contents of as inert, like the contents of