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

Share this article

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.

Annarita TranficiAnnarita Tranfici
View Author

I have a Bachelor's degree in European languages, cultures, and literature from the University of Naples. I'm passionate about graphics and web design, and for several years I've been working on projects and designs for many companies. I'm a writer for the Audero User Group; my specialties are HTML, CSS, Web Design, and Adobe Photoshop.

Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week