Build a Responsive, Mobile-Friendly Website from Scratch: Getting Mobile

This entry is part 6 of 6 in the series Build a Responsive, Mobile-Friendly Website From Scratch

Build a Responsive, Mobile-Friendly Website From Scratch

In the fifth part of the series we’ve seen the rules we have to apply to render our website responsive and to assure a good layout on tablets. In this last part, we’ll conclude it with the code for mobile and some final considerations and advice.

mobile image

Before showing you the CSS code with the rules inherent to the mobile version, we have to add a little piece of HTML code to create the mobile version of our menu. As you can see from the screenshot, the menu of the mobile version is a drop-down list (<select> element).

We’ll see shortly why, and how to let the website display a different menu style according to the device used but, as a first step, let’s include these few lines after the nav tag, used to create our menu-list.

<select id="menu-select">
  <option selected="selected" value="">Go to...</option>
  <option value="/">Homepage</option>
  <option value="/news">News</option>
  <option value="/graphics">Graphics</option>
  <option value="/mobile">Mobile</option>    
  <option value="/web-design">Web Design</option>
</select>

Well, obviously the HTML code above, if used alone does not cause any changes. This is why we’ll also need to add few lines of javascript code. Here they are:

$("#menu-select").change(function(){
   window.location.href = $(this).children("option:selected").val();
});

The code structure is very simple to understand. We’re listening for the change event on the element having id menu-select and attaching it an anonymous function to run as soon as the event is fired. Once done, we’ll use the value of the option element to change the URL of the address bar and redirect the user to the selected page.

With this little function (in conditions that we’ll deepen shortly) we’ll have the possibility to visit the other pages of our website without any problems, whether we’re using a PC or a tablet/smartphone.

This little introduction done, let’s have a look at the CSS media queries applied on all those devices whose max width doesn’t exceed 480 pixels. The first thing you’ll notice is that fonts and images have changed. For smaller screens, the first rule to remember is that everything has to be: clear, fast and understandable.

So, too heavy images or customized fonts would make the loading of the pages too slow and this would affect the success of the website and, consequently, the achievement of your goals.

Here is the code for this part:

@media screen and (max-width: 480px)
{
   body
   {
      font-family: Calibri,Arial,Helvetica,sans-serif;
   }

   #banner
   {
      background-image: url("../images/mobile-banner.png");
   }

   .menu
   {
      display: none;
   }

   #wrapper
   {
      width: inherit;
   }

   a.menu-item-link
   {
      font-family: Calibri,Arial,Helvetica,sans-serif;
   }

   #menu-select
   {
      display: block;
      margin: 0.5em auto;
      width: 90%;
      font-size: 1em;
   }

   #newsletter-box
   {
      display: none;
   }

   #mobile-newsletter-box
   {
      display: block;
   }

   #mobile-newsletter-box *
   {
      width: 90%;
      margin: 0em auto 0.5em auto;
   }

   #mobile-newsletter-box > form > *
   {
      display: block;
   }

   input#mobile-newsletter-email
   {
      font-size: 1em;
   }

   #mobile-newsletter-box p
   {
      padding: 0;
      text-align: center;
   }

   #mobile-newsletter-box a
   {
      font-size: 1.2em;
      font-weight: bold;
      color: #FFFFFF;
   }

   .long-box,
   .small-box,
   #banner
   {
      box-shadow: none;
   }

   #team-logo-bar
   {
      text-decoration: none;
      width: 100%;
      display: inline-block;
      text-align: center;
   }

}

Before concentrating on the most important parts of the code, let’s turn back to the topic of the menu style, which deserves a primary consideration. You see that we showed the drop-down menu while hided the menu-list, which was visible on the pc desktop and tablet versions. We’ve applied to the class menu the rule display: none;.

With another rule, which is display: block;, we applied to the element with id menu-select, we’ve afterwards let a drop-down menu (more clear and readable for a mobile version) appear.

Having said that, we must consider a problem that a good Web Designer should keep in mind: what if JavaScript is disabled? If the user has JavaScript enabled, he won’t have any kinds of problems in making use of this new menu; if JavaScript is disabled, the change event will fired but the handler not. Therefore, if JavaScript is disabled, the users can’t go in pages different than the current. A big issue!

The possible solutions for this problem are several but, since the discussion goes beyond the scope of the article, I’ll give you only a cue to reflect, leaving the depth study of the issue to an upcoming article. A potential solution could be to use of a JavaScript function attached to the “resize” event that makes the change discussed before and is also responsible to manage of hiding the menu-list and showing the drop-down menu.

Acting so, if JavaScript is disabled and the user is on a mobile device, the drop-down menu won’t be visible but he’ll find, instead, the previously mentioned menu list which is still usable, because it’s composed of regular links. In this way the user can have access to additional content through the link provided by the menu. The discussion is interesting and deserves attention, but as said before, it’ll be the subject of a future article.

Now that we’ve discussed the issue of the menu, it’s time to focus on other topics such as: fonts and images, box disposition and shadows. Let’s move on fonts, firstly. There are two things to consider: its size and style, which has to be appropriate to the device. As can be easily guessed, the font size should be proportional to the medium used: larger for pc-desktop and smaller for tablets and smartphones.

Moreover, remember that, especially for contents and pure text, you should stick with the most common and “standard” fonts because this will ensure that everyone visiting your site can see it the way you intend it to be seen and with a greater ease of reading.

As you can see, I’ve set one the most common fonts, Calibri. Why this choice? The answer is simple: custom fonts imply an additional request and the file usually isn’t very small. You’ll agree that for mobile, a cute font isn’t as important as readability because screens are smaller. Moreover, you should keep in mind that connection are slower too and performances are very important. Therefore, less kb will be downloaded, better the experience of the user browsing our pages will be.

On a desktop, the use of a cute font doesn’t affect its efficiency because usually it implies a fast connection, while on mobile devices the changes to a normal one should always be applied to achieve best performances. However, even in this case the custom font specified in the rules is downloaded. But…why? Is really necessary? The answer is that the font download could easily be avoided.

A more correct option could be, in fact, the removal of the custom font rules from the common stylesheet and the creation of a new breakpoint. Doing that, once the site is displayed on a mobile device, the rules applied to that specific device are overwritten while the custom font (previously visible in tablet and desktop versions) is simply not downloaded, and this leads to a greater speed of loading of content and style.

In fact, if the device is larger than the sizes indicated in the range, it means that the person is using at least a tablet, so the font can be shown in all its beauty and particularity; otherwise this passage is deleted because it would be neither useful nor efficient.

So, let’s write another media query (where we’ll set a range of values):

@media only screen and (min-width : 481px)
{
   a.menu-item-link
   {
      font-family: Bebas Neue, Calibri,Arial,Helvetica,sans-serif;
   }
}

There’s another thing like the font that can be moved in the range we’ve previously created and that is banner; indeed, the same consideration can be done for the banner image.

We are optimizing for mobiles and so far we did not care because we were talking about the tablet, but now it’s appropriate even touch this topic. We are making a speech to improve performances, so why download two images when we’ll always view one of them at time? Even in this case, the lines of code referring to banner should be moved from the common stylesheet and put in the range, in this way:

@media only screen and (min-width : 481px)
{
   #banner
   {
      background-image: url("../images/banner.png");
   }
}

Last thing, for boxes’ shadow we’ll do the same consideration done for transactions; on a small screen, are shadows fundamental? In fact it is an effect whose particularity is evident on the pc-desktop and would not have the same efficacy on other devices.

Conclusions

This series about how to build a responsive, mobile-friendly website from scratch has ended. I hope you’ve enjoyed it!
If there is any advice that I can give to you, is to continue to “practice with this stuff”, not only in the practical realization of the website, but also in the design phase which has a fundamental importance because it’s extremely important that everything is planned in detail; only in this case you’ll avoid waste of time and exhausting corrections, and you’ll perfectly understand how to organize your content and improve your final result.

Build a Responsive, Mobile-Friendly Website From Scratch

<< Build a Responsive, Mobile-Friendly Website from Scratch: Responsive Rules

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Keith Austin

    As a web developer who has trained in a college we are taught to build sites to be cross browser, cross platform and now with responsive sites cross device friendly. While most smartphones are of similar size, and most Tablets are similar size, why is it that your design rules “focus” on Apple products? Too many people focus only on Apple but it is not the only product around. We do nor focus only on Firefox, or Chrome, or Safari, or IE or Opera as browsers, we do not focus only on Windows or Apple OSs so why do you focus purely on Apple iPads, and Apple iPhones?

    • Robert Weidner

      Keith, I believe she addresses that in the introduction by saying the following:

      “Someone might argue that not all smartphones and tablets are iPhones or iPads, and they’d be unquestionably correct. But, in this case the screen size of the Apple device is used more as a reference point for a greater category of devices. Moreover, creating a breakpoint for each and every device would be totally absurd.

      A good practice could be defining a set of main breakpoints possibly combined with some secondary breakpoints in order to fit the document to specific devices. You could also think about creating a custom breakpoint; this is very straightforward but requires a familiarity with media queries, so I suggest practicing initially with basic media queries and common breakpoints.”

      You are correct that there are plenty of devices out there that aren’t Apple. But Apple does have a significant market-share, and for a tutorial, it seems to be her choice to go with common Apple screen sizes for breakpoints. She leaves it up to us to write our code for the sizes we feel should be supported. They’re just examples.

      Best regards

  • Boe Var

    Have you tried Phonegap? There are tutorials on mobile web development like Sencha. I have not tried but Annarita’s tutorial will help get you started if you think you can apply using Phonegap as well.

  • Rutherford

    Hello Anna….thanks alot for a great series on responsiveWD i was just wondering if one can download the source file? especially the image files use for the tutorial.

    Thanks

  • http://www.tiecoon.com Jesse Necktie

    We’ve used a few variants of mobile solutions, and they are difficult to integrate and make function properly. I mean, go to any huge company’s mobile site and notice…it never gives you the functionality you want, and they have budgets in the millions! Orbitz, Hotels, Walmart, grocery stores…find yourself frequently hitting that “Full Site” button? So do we, and that’s why we have had better luch leaving our full site up for all users. ;)

  • http://websemantics.co.cuk mike

    A very good series of articles for mobile-friendly development.
    Will mobile-first be the next?
    If so I can’t wait…

    Mike Foskett

  • Peter Galiba

    If your dropdown only works with JavaScript, why don’t you create it with JavaScript? Maybe use an UL/LI/A instead, and transform it to SELECT/OPTION. It should be like 5 lines of code with jQuery. And also getting a SELECT element’s value is easy as .val(), you don’t have to go through the OPTIONs.

  • James Smith

    Hi

    Apologies if I missed something really obvious, but any chance of attaching a zip file with the files/images and everything? I want to use this as a basis for my new site but would be handy to not have to make dummy images and such. Cheers

    James

  • James Smith

    Don’t you need to set a height on the div#banner in order to see the background image?

  • James Smith

    also this css doesn’t do anything

    #banner > img
    {
    width: 100%;
    }

    this and my last comment leads me to suspect you changed the HTML at the last minute so the banner image was a background image and not using an image element?? can you fix?