Everything First

Everything First

FFW Blog - illustration
default avatar
Thought byMatt Korostoff
Senior Solutions Architect
February 26, 2014

“Mobile first” is perhaps the hottest buzzword in web development today. The merits have been debated time and again, and already developers are applying mobile first principles in the wild with stellar results. Nevertheless, we as an industry are still struggling to articulate just what “mobile first” means. Does a mobile first approach simply mean generating mockups in that order? Or does it mean writing the HTML/CSS in that order? Does it require quality assurance testing in that order? Perhaps it means none of these things—perhaps it simply means always giving mobile users first consideration at all phases of the project regardless of the actual chronology. In practice, the meaning seems to lie somewhere in the middle—a project might identify itself as “mobile first” while still designing, coding, or testing in some other order.

If there is serious interest in moving towards a mobile first approach industry wide, I think it's important that we take some time define our goals. Here I want to argue that, whatever “mobile first” means, it doesn't (or shouldn't) mean coding a mobile experience prior to the desktop experience. When it comes time to implement a design in HTML/CSS, “mobile first” versus “desktop first” is a false choice, and instead a holistic approach is necessary. It makes no more sense to code a website mobile first than it does to build a house “inside first.” Desktop, mobile, and tablet views are all “facets of the same experience” as Ethan Marcotte put it in the article that started it all—they are mutually dependent and influence each other. Trying to build one without considering the rest is an exercise in futility.

Take, for example, the following style guides:

 
Desktop

Heading 2

Tablet

Heading 2

Mobile

HEADING 2

 

If we were going to code the mobile stylesheet first as our “global” stylesheet, we would probably arrive at something like this:

/*global*/
@media only screen {
   h2 {
      font-size: 130%;
      font-family: Arial,sans-serif;
      color: skyblue;
      text-transform: uppercase;
      text-decoration: underline;
   }
}

/* tablet */
@media only screen and (min-width: 768px) and (max-width: 1024px) {
   h2 {
      font-size: 200%;
      color: black;
      text-transform: none;
      text-decoration: none;
   }
}

/* desktop */
@media only screen and (min-width: 1025px) {
   h2 {
      font-size: 300%;
      color: black;
      text-transform: none;
      text-decoration: none;
   }
}

Does anyone else think this is a strange approach? In this scenario, we must override three properties at the desktop and tablet size (color, text-transform, and text-decoration) to return them to their default, user-agent stylesheet configuration. That is to say, we wrote nine lines of code to achieve results that a “desktop first” approach would have achieved in three. It would be objectively shorter and, in my view, simpler to make the “global” styles those that are used the most not those that happen to affect one arbitrary resolution. In this case that would mean:

/*global*/
@media only screen {
   h2 {
      font-family: Georgia,serif;
   }

/*mobile*/
@media only screen and (max-width: 767px) {
   h2 {
      /* this breakpoint is an outlier, so it gets special treatment */
      font-family: Arial,sans-serif;
      color: skyblue;
      font-size: 130%;
      text-transform: uppercase;
      text-decoration: underline;
   }
}

/* tablet */
@media only screen and (min-width: 768px) and (max-width: 1024px) {
   h2 {
      font-size: 200%;
   }
}

/* desktop */
@media only screen and (min-width: 1025px) {
   h2 {
      font-size: 300%;
   }
}

The same effect can be observed in HTML. Consider the following mobile design:

Mobile Design with HTML

 

Ok, simple enough. Lets set up our HTML like this:

   <nav>
   <div id="logo"></div>
   <a href="#">Toggle Menu</a>
   <ul class="menu">
      <li class="menu-item"><a href="/page-1">Menu Item 1</a></li>
      <li class="menu-item"><a href="/page-2">Menu Item 2</a></li>
      <li class="menu-item"><a href="/page-3">Menu Item 3</a></li>
      <li class="menu-item"><a href="/page-4">Menu Item 4</a></li>
      <li class="menu-item"><a href="/page-5">Menu Item 5</a></li>
   </ul>
   </nav>
   <div id="page-width">
      <h2>Recent News</h2>
      <article><img src="image1.jpg" alt="image1">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</article>
      <article><img src="image2.jpg" alt="image2">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</article>
      <article><img src="image3.jpg" alt="image3">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</article>
      <article><img src="image4.jpg" alt="image4">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</article>
      <article><img src="image5.jpg" alt="image5">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</article>
   </div>

Now lets take a look at the tablet design:

Tablet Design with HTML

Hmm, well, some of that HTML doesn't quite work anymore. Of course we'll have to serve larger images than originally planned. And we'll need a wrapper around the text inside each <article> element to pull off the transparent overlay effect. The large “featured” story shouldn't give us any trouble, because we can target it as a “first-child” pseudo-element. So lets make an adjustment:

   <nav>
   <div id="logo"></div>
   <a href="#">Toggle Menu</a>
   <ul class="menu">
      <li class="menu-item"><a href="/page-1">Menu Item 1</a></li>
      <li class="menu-item"><a href="/page-2">Menu Item 2</a></li>
      <li class="menu-item"><a href="/page-3">Menu Item 3</a></li>
      <li class="menu-item"><a href="/page-4">Menu Item 4</a></li>
      <li class="menu-item"><a href="/page-5">Menu Item 5</a></li>
   </ul>
   </nav>
   <div id="page-width">
      <h2>Recent News</h2>
      <article><img src="image1.jpg" alt="image1">
         <div class="body-copy">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</div>
      </article>
      <article><img src="image2.jpg" alt="image2">
         <div class="body-copy">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</div>
      </article>
      <article><img src="image3.jpg" alt="image3">
         <div class="body-copy">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</div>
      </article>
      <article><img src="image4.jpg" alt="image4">
         <div class="body-copy">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</div>
      </article>
      <article><img src="image5.jpg" alt="image5">
         <div class="body-copy">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</div>
      </article>
   </div>

All told, very little has changed. Now let's take a look at the desktop design:

Desktop Design with HTML

Ok, quite a bit has changed here. We'll definitely need a unique class on each article to achieve the varied sizing. The fact that the menu extends to the edge of the page is going to be a problem, because it will prevent us from wrapping the menu and the logo together. There are a lot of ways to achieve this effect, but here we'll use “outer” and “inner” divs, with the inner divs set to a fixed width:

   <nav>
   <div class="logo-outer">
      <div class="logo-inner">
         <div id="logo"></div>
      </div>
   </div>
   <a href="#">Toggle Menu</a>
   <div class="menu-outer">
         <div class="menu-inner">
         <ul class="menu">
            <li class="menu-item"><a href="/page-1">Menu Item 1</a></li>
            <li class="menu-item"><a href="/page-2">Menu Item 2</a></li>
            <li class="menu-item"><a href="/page-3">Menu Item 3</a></li>
            <li class="menu-item"><a href="/page-4">Menu Item 4</a></li>
            <li class="menu-item"><a href="/page-5">Menu Item 5</a></li>
         </ul>
      </div>
   </div>
   </nav>
   <div id="page-width">
      <h2>Recent News</h2>
      <article class="article-1"><img src="image1.jpg" alt="image1">
         <div class="body-copy">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</div>
      </article>
      <article class="article-2"><img src="image2.jpg" alt="image2">
         <div class="body-copy">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</div>
      </article>
      <article class="article-3"><img src="image3.jpg" alt="image3">
         <div class="body-copy">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</div>
      </article>
      <article class="article-4"><img src="image4.jpg" alt="image4">
         <div class="body-copy">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</div>
      </article>
      <article class="article-5"><img src="image5.jpg" alt="image5">
         <div class="body-copy">Lorem Ipsum dolor sit amet consecutir ati mat bilenue ampitus callais jun.</div>
      </article>
   </div>

This HTML, in all likelihood, will serve well for all breakpoints. Now consider: which of these designs would have been proper to code first? It's unlikely that looking at any one of these designs would have resulted in HTML that serves all of them. Instead, the developer must consider all breakpoints simultaneously and find a solution that works for all. Particularly when producing a CMS driven site, the cost of recoding the site again and again as we've done here is very high.

The two basic assumptions that motivate mobile-first coding are that 1) desktop capabilities generally exceed mobile device capabilities and 2) a mobile site will be simpler and therefore easier to progressively enhance up to the desktop size. Both assumptions are false. Mobile devices have long exceeded desktop devices in CSS3 support, if for no other reason than the Android/iOS monoculture. iOS was supporting flexbox in v3.2 circa 2010; the same didn't come to Internet Explorer for two more years when IE10 arrived, and still few IE users have upgraded to this version. Not to mention the unique features accessible almost exclusively on mobile devices, such as shake gestures, GPS, voice recording, and multitouch. Mobile devices don't do “less” than desktop devices—they just do things differently. The notion that mobile sites are simpler is sort of hard to rate, because there's so much diversity in site design. In some cases it might be easy to add bells and whistles at larger resolutions, but often the simplest thing to do is use “display: none” to hide elements that are too finely detailed for small screens.

In many ways, “mobile first” is an understandable reaction to years of desktop domination. But we must be careful not to pull too far in the other direction—an optimal solution will provide a high quality experience for all users equally, regardless of device. In short, we don't need to put desktop or mobile first; we need to do everything first.

Topics:
Best Practices
Learning Series

Read next:

Blog
Acquia Engage NOLA Teaser

Join us at Acquia Engage in New Orleans

Blog
Teaser of "Learn to Make Your Site Accessible" blog

Learn to Make Your Site Accessible in a New Training from FFW

Blog
Teaser of Drupal for Customized eCommerce Solutions blog

Using Drupal for Customized eCommerce Solutions

Blog
Teaser image of Acquia Engage Awards blog

FFW Clients Named as Finalists in Acquia Engage Awards