SitePoint » Mobile Web Development

Build a Responsive, Mobile-Friendly Website From Scratch: CSS stylesheet

Annarita Tranfici — Tue, 07 May 2013 07:10:27 +0000

In the last article of this series, I’ve shown how to start building a website from scratch with a particular focus on the HTML code and its main elements.

Now it’s time to introduce the first CSS rules in order to have a general idea of the graphic style that the homepage of our website will display, especially for the pc-desktop version.

First of all, before having a look on the rules we have to apply in order to create a particular design for our homepage, let’s see how it will appear in our browser window (my default browser is Chrome but, with the application of some specific rules, you’ll be able to obtain the same result for all modern web-browsers).

The homepage of our totally customizable website should look more or less as following:

As you can see, I have imagined a very big banner to allow the designer to express all his creativity and chosen colors that combine in a clear and positive way (I really love them!). Having said that, let’s dive deep into the code.

As for the HTML section, in this case we’ll proceed step-by-step from the upper part of our layout to the bottom part. The code for the very first part (which includes the elements of banner, newsletter bar and menu) will be shown piece after piece with a very short comment, as for the other items of the page.

The first one is the banner element, with this code for styling:

#banner
{
   width: 100%;
   margin-top: 0.2em;
}

These first rules simple enough to understand. To space the banner from the top of the browser window we’re applying a margin of 0.2em and to let our banner-image cover all the width of our browser’s window, we’ve set the corresponding rule with a percentage of 100.

Let’s go on with the rules for styling our newsletter-box. In this case we have to pay attention for the rules to put on the id and the ones to consider for the class since I have decided, for personal clarity, to not choose different names for elements that substantially indicate the same part. So, for the class we set a background color (which will be the color of the box and a margin-top of 0.2 em–you’ll find out why it’s better to use these kind of measurements for a responsive website in this article, which will give you a short overview on the most common units used in Web Design) to slightly space the newsletter-box from the banner above.

The id “newsletter-box”, that is the space where we’ll find the input field and the submit button, has three simple rules, to define the spacing with the box that contains the above-mentioned elements. As you can see, there’s an id (“mobile-newsletter-box”) that seems to be inappropriate to the version we’re analysing. Actually, it’s not so: since there’ll be a change of view when passing from a pc-desktop version to a tablet version or a mobile-phone one, we have to “suggest” to our stylesheet how to perform and display the page elements.

In this case, as you’ll see in the next article when we’ll discuss about the rules to set thinking responsively, the disposition of all the elements characterizing the newsletter bar will totally change. What we have to do now is avoid having the mobile-display shown in the pc-desktop version. To achieve this result, we simply set to the rule “display” the none parameter.

A nice effect I’d like to talk about is the transition I have applied to the white box where the user inserts his e-mail to receive news. Setting to the element a transition, the resulting effect is an enlargement of the box; the other thing I’ve done is to indicate the time that this has to last. This is a CSS3 rule that creates a simple and light movement with a very pleasant output.

The last rule to discuss is the width applied when the newsletter box is clicked: setting this to 17em, the box will appear larger than usual.

.newsletter-box
{
   background-color: #c32526;
   margin-top: 0.2em;
}
#newsletter-box
{
   margin-top: 0.5em;
   height: 1.8em;
   padding: 0.3em;
}
#mobile-newsletter-box
{
   display: none;
}
#newsletter-email
{
   width: 12em;
   -webkit-transition: all 1s;
   -moz-transition: width 1s;
   -o-transition: width 1s;
   -ms-transition: width 1s;
   transition: width 1s;
}
#newsletter-email:focus
{
   width: 17em;
}

Let’s go on now analyzing our navigation bar. To delete the default bullet points of our menu list, we set the parameter to none, while to center it we recourse to the well-known rule “text-align: center”. Then we change the padding and the margin rules to the size that seems to be appropriate for our purpose. To let the elements of the list appear one after another horizontally, we change the display from the default setting “block” to “inline” and also, in this case, specify the margin parameters.

Now, it’s time to have a look at the rules applied to the link elements: as font, I’ve chosen “Bebas Neue” (you can download it here). I’ve set a font-size of 1.3 em, removed the underlining with the rule “text-decoration: none” and set the color I preferred. This color changes when the cursor moves on the menu items and, moreover, when the user clicks on the link of the page he desires to visit, there’s a 3D effect, and you can obtain it setting the rule “position: relative” on the menu links and the parameters top and left on the active state of the same element. In this way, you’ll have a slight movement that will give you the impression of a clickable 3D button.

ul.menu-list
{
   list-style-type: none;
   padding: 0;
   margin: 1em 0em;
   text-align: center;
}
li.menu-item
{
   display: inline;
   margin: 0em 1.5em;
}
a.menu-item-link
{
   font-family: "Bebas Neue",Calibri,Arial,Helvetica,sans-serif;
   font-size: 1.3em;
   text-decoration: none;
   color: #c31f05;
position: relative;
}
a.menu-item-link:hover
{
   color: #000000;
}
a.menu-item-link:active
{
   top: 0.1em;
   left: 0.1em;
}
#menu-select
{
   display: none;
}

Now, move on to the general part, that is on the rules applied to elements such as heading, paragraphs, images, boxes appearance and so on. Here is the code with the specifications of the rules for the layout I have thought out, planned and realized.

body
{
   max-width: 1024px;
   margin: 0 auto;
   font-family: "Cwmagic",Calibri,Arial,Helvetica,sans-serif;
   background-color: #E3E3E3;
   font-size: 1.2em;
   line-height: 1.5em;
}
img
{
   border: 0em;
}
h1,
h2,
h3
{
   text-align: center;
}
.float-left
{
   float: left;
}
.float-right
{
   float: right;
}
.clear-both
{
   clear: both;
}
.shadow
{
   -webkit-box-shadow: 0.4em 0.4em 0.2em #5C5B5B;
   -moz-box-shadow: 0.4em 0.4em 0.2em #5C5B5B;
   -o-box-shadow: 0.4em 0.4em 0.2em #5C5B5B;
   -ms-box-shadow: 0.4em 0.4em 0.2em #5C5B5B;
   box-shadow: 0.4em 0.4em 0.2em #5C5B5B;
   margin-right: 0.4em !important;
}
.long-box,
.small-box
{
   background-color: #cdcdcd;
   padding: 0em 0.3em;
   margin: 0em;
   margin-bottom: 1em;
}
.small-box
{
   width: 47%;
}
p
{
   margin-top: 0;
   margin-bottom: 0.5em;
}

I won’t explain the rules one by one as for the first part, especially because they are almost all the same. The only thing to which I’d like you’d pay attention is the classes float left, float right and clear both; in fact, I’ve preferred to create a class which “identifies” these rules and applies them to the elements in the HTML code rather than repeating the elements. Another element worthy of note is the CSS3 rule “shadow“.

This property allows designers to easily implement multiple drop shadows (outer or inner) on box elements, specifying values for color, size, blur and offset.
It can accept a comma-separated list of shadows, each defined by 2-4 length values (specifying in order the horizontal offset, vertical offset, optional blur distance and optional spread distance of the shadow), an optional color value and an optional ‘inset‘ keyword (to create an inner shadow, rather than the default outer shadow).
Browser support is growing of late with Mozilla (Firefox), Webkit (Safari/Chrome/Konqueror), Opera and the IE9 Platform Preview all offering a decent implementation of the specification.

Let’s conclude this article with the rules applied to elements present in the footer, that is the footer itself and the bar containing the icons for the linking to the most important social networks’ profile.

#main-footer
{
   background-color: #c32526;
   text-align: center;
}
.social-bar a
{
   text-decoration: none;
   margin-right: 3em;
}

Finally, let’s see how to manage fonts in the CSS stylesheet, bearing in mind that Internet Explorer requires a different format for the fonts, that is “eot”. Here is the code.

/*
 ***********************************
     FONT FOR INTERNET EXPLORER
 ***********************************
*/
@font-face
{
   font-family: "Bebas Neue";
   src: url(../css/bebasneue.eot);
}
@font-face
{
   font-family: "Palatino Linotype";
   src: url(../css/pala.eot);
}
/*
 ***********************************
       FONT FOR OTHER BROWSERS
 ***********************************
*/
@font-face
{
   font-family: "Bebas Neue";
   src:
      local("Bebas Neue"),
      local("Bebas Neue"),
      url("../css/bebasneue.ttf");
}
@font-face
{
   font-family: "Palatino Linotype";
   src:
      local("Palatino Linotype"),
      local("Palatino Linotype"),
      url("../css/pala.ttf");
}

Conclusion

In this article we’ve seen the basic rules to create a simple layout for a website. After concentrating on the pc-desktop version, in the next part we’ll see which are the rules to apply to make this layout responsive.

Build a Responsive, Mobile-Friendly Website From Scratch: Semantic HTML

Annarita Tranfici — Tue, 16 Apr 2013 17:37:35 +0000

In the last article, as promised, we’ve begun doing some practical work with the planning and creation of a mockup. Now, we’ve focused on how to build a personal project wireframe thinking responsively and—consequently—how a responsive design can adapt to three target layouts: Default (PC desktop), Portrait Tablet, and Smartphone.

We’ve seen how to arrange the elements of a typical website in the three main devices’ categories by creating a template that represents the common content elements. In this third part of this series, I’ll concentrate on writing the HTML code and work on the structure of the homepage, while in the very next, I’ll be setting the first CSS styling rules to build the initial design of our project.

First Step: HTML code

Let’s begin building the structure of our website through the use of HTML code. To avoid confusion and miss some steps, we’ll proceed by dividing the layout into three parts, just like we did during the mockup design phase. We’ll pause from time to time on parts of the code that are inherent only to that single part. The first part we’ll face with will of course be the header, that is the part that in our mockup consists of the following elements: banner, newsletter-box, and main menu bar. Now, what we have to do as our first task is declare the type document that for HTML5 is indicated in the following way:

Next, we must add the section that is necessary to help the web browser to interpret the content in the following body section. This section contains specific tags, CSS stylesheets, and other elements that remain hidden and are not displayed in the browser. These elements are generally called meta information (basically “information about information”) because their function is to describe what kind of information is on the page.

The first meta-tag which needs a specification is “meta charset”; it defines what character coding is used in the page. In our case, we set it to UTF-8, which is a variable width Unicode format compatible with ASCII or plain text for the basic alphanumeric characters. By using the “upper half” of the 8-bit ASCII set and extension codes, it can handle over a million unique characters.

It’s a requirement that any web page defines the formatting of the page within it’s header info so that all the browsers know exactly how to read and interpret the content. Otherwise, they’ll show the characters using their “best guess,” which isn’t always accurate. The guess could be wrong, and this will lead to showing the wrong characters to the users.

The next item we have to pay attention to is the viewport property. Setting a viewport tells the browser how content should fit on the device’s screen and informs the browser that the site is optimized for mobile. For example…

…tells the browser to set the viewport to the width of the device with an initial scale of 1. After this, we insert into the title tag the name we’ve chosen for our website. Finally, we have to link our HTML page to the CSS stylesheets that we’ll use to define the style of our homepage; the HTML “link” element specifies relationships between the current document and other documents. With this line of code…

…we link the document to the common stylesheet (that is, the document which contains all the common CSS rules that will be shared by the three versions of the project), while this one…

…recalls to the file where there are the specifications of the particular rules that will be applied only to that particular device indicated. Please note that since we’re using HTML5, you don’t actually need to specify type="text/css".

Close the head tag and move on to the body section. At this point, we have to create two separate divs: one for the banner, and one for the newsletter box.

In the first, in addition to the id, it’s a good practice for accessibility to use a WAI-ARIA role; generally roles describe widgets and structure. Structural roles are added to markup as attributes of elements, which makes it perfect for our purposes.

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a technical specification published by the World Wide Web Consortium that specifies how to increase the accessibility of web pages. It allows web pages (or portions of pages) to declare themselves as applications rather than as static documents by adding role, property, and state information to dynamic web applications in order to make controls and content updates accessible to users with disabilities. That’s why all these kinds of specifications are so important.

Let’s continue our project by building a newsletter opt-In form. first of all, add a form with

tags. The opening tag should include the form name, a method which can be either “query” or “post,” and the destination or “action” where the form should send the input (I put a # to indicate that it is not fixed).

Now, add a text field with a label to collect the email address and assign an ID and a class for the following changes of style you might apply to your form. Finally, add a submit button to the form. The information put into the form fields will be sent to the receiving page for processing when the visitor clicks the submit button. Insert the word “Submit” for the input type, name and value fields to create a submit button, and close the form and div tags.

So, at this point, you should have the following code:



   
      
      
      Website name
      
      
  
   
      
         
         
            
               Newsletter:

Let’s proceed with the central part of our layout, namely the one used for different types of content.

First and foremost, let’s create a classic menu, composed of five options that will be the main categories of the whole website: Homepage, News, Graphics, Mobile, and Web Design. In this case, the element most suitable for our purpose is the nav element, which is a semantic element used for declaring a navigational section of a website (that is, a section of a page that links to other pages or to parts within the page).

Within the nav tag, let’s add an unordered list (to which we’ll assign a class called “menu-item”). For the content section, let’s create a main div whose ID is “content”, a wrapper div, and put an article within it. The article element is a specialized kind of section; it has a more specific semantic meaning as an independent, self-contained part of the page. In our sample, it’ll be used to contain the description of the purpose of our website.

As for the wrapper div, it will contain three more elements: a div which contains all the information about the author (and a photo,if you want), an aside in which the author can add his screencasts, and another aside intended for his latest tweets. Two points on the aside element: it is used for tangentially-related content. However, in the interpretation of this new element there lies some confusion as to how it should be used; remember that just because some content appears to the left or right of the main content isn’t enough reason to use the aside element. The better way to decide whether you should use an aside or not involves asking yourself if the content within the aside can be removed without reducing the meaning of the main content or if the main content is truly dependent on the aside. Pullquotes, glossaries, or even related links are some examples of tangentially related content that are appropriate for an aside.

The code for this second part is the following:

      
         
            
               Homepage
            
            
               News
            
            
               Graphics
            
            
               Mobile
            
            
               Web Design
            
         
      
      
         
            Title
            
               Your content here
            
         
         
            
               
                  Information about the author 

               
            
	    
               
 
 

            
            
               
                  
                  Follow me on Twitter! 

                  We're in (number of follower)

The last remaining part is the section called footer, which generally contains information about its sections, the author, links to related documents, copyright data, and so on. In some cases, you can also find links to profiles or personal pages of ubiquitous social networks such as Facebook, Twitter, Google+, and LinkedIn. So, we place the principal information in a paragraph inserted in the new HTML5 tag

and the links directed to the social profiles mentioned above in a div whose main class is named “social-bar”.

Here is the code of this last part:

      
         
            Author's name. All rights reserved. Copyright © 2012 - 2013.

Conclusion

In this article, we’ve seen how to start building a website from scratch with a particular focus on the HTML code and its main elements. In the next article, I’ll introduce the first CSS rules in order to have a general idea of the graphic style that the homepage of our website will display. Once we pass this step, we’ll concentrate on the aspects and the procedures to be followed to convert our static homepage into a responsive homepage that will be viewed correctly on numerous different devices.

Build a Responsive, Mobile-Friendly Website From Scratch: Design a Mockup

Annarita Tranfici — Tue, 09 Apr 2013 19:52:22 +0000

In the first article of this brand new series, I have introduced the main objectives of the series and given a short but complete introduction on the critical components of media queries and responsive breakpoints. Now, it’s time to begin doing some practical work. As I have mentioned before, I’ll start with the planning and creation of a mockup for each of the three main device types on which our responsive website will be designed, tested, and displayed: PC desktops, tablets, and mobile phones.

3…2…1… Let’s Start!

Before continuing, I want to give you a little advice: remember that the more mockups you do, the more arduous and confusing your job will become. Responsive mockups are not the same as static mockups; you don’t really know where your content will be placed, because it depends on the screen size.

Obviously, as we’ve seen in the previous series, designing mockups for every screen size is nearly impossible, because there are potentially hundreds of screens, layouts, and orientations that you have to accommodate. This is why I suggest that you select your target screens/layouts and build the project mockups only for your top three main devices’ categories.

For obvious reasons, I won’t show you how to design and build the entire website, but I’ll focus on the homepage, although I’m sure that once you have understood the logic and basis of responsive web design, you’ll be able to proceed with building the entire portal and everything will fall into place. I should reiterate that creating mockups doesn’t usually require that you lay out every single view to perfection, and that they are effective as soon as they’re enough of an abstraction of the final product (website or app) that they give you sufficient information to begin building.

I have chosen to build my project mockup using Balsamiq Mockups. As I have explained in detail in the linked article, Balsamiq Mockups is a tool that helps developers to create wireframes and communicate with clients and coworkers with visual representations of their design plans. Balsamiq is offline desktop software, and you can work with it using the operating system of your choice, since it runs on Mac, Windows, and Linux.

Let’s start planning the mockup of our website working on the PC desktop version.

First and foremost, let me introduce the kind of website we’re going to desogm and all of the elements that we’ll find within it. In fact, when building a web app or website, it’s a good practice to identify your content ahead of time and designate respective content areas within the website template. For our purposes, we’ll build a website with main content topics like graphics, web design and mobile development, a place where the design-addicted can read articles about their favourite fields, discuss, learn new techniques, and stay informed.

Let’s see how can we proceed using the elements of Balsamiq Mockups and focus on one target layout first. We have to work on the placement of blocks on the layouts, and as a first step, I place the browser window shape to represent the profile of any browser page and set its size using slight adjustments with the mouse.

As for the style of the main page, the first thing to determine is which elements we want to show on our brand new homepage. Generally, we might find a header, a newsletter bar, a menu-list, some sidebars (based on the extra-content you want to enter), a text box for the most important information, an image, or some links, for example.

Thanks to its simple, intuitive drag-and-drop system, we can easily add everything we want with a few clicks. For the first components of our page, we have to open the category called “Big.” Here, we’ll find the following elements elements: title/headline, the text area, and the image box. So, drag and drop each of these into your mockup. Then, open the category “Common” to find rectangles, text areas, text input boxes, image and icons’ indicators, and link pointers. Let’s place the two sidebars to the left of the author information box (where it could be nice adding a photo) under the main content box, which occupies the full window width.

At this point, our design concept should look something like this:

Once you’ve dragged and dropped the elements, you’ll see that each element has extensive editing options. When you click on the title/headline or within the text box, you’ll see a typical text editor, where you’ll be able to specify the characteristics or content. You can modify texts selecting size, text alignment, format, and color. You can also set the background color, set the border color, add a scrollbar, and play with opacity and focus.

For images, we can show or hide a border, crop the image, and hyperlink the chosen image to lead to a new URL or screen. Since this is a mockup project intended mainly to keep in mind all the page elements and their arrangement, is not necessary in my opinion to make ultra-precise stylistic changes. What is important is to have a sort of “skeleton,” or a point of departure to fix attention on what is necessary to build into the structure with the help of the HTML code and the CSS3 styling rules.

Once we’re done with this first passage, let’s continue planning our tablet version.

As you can see in the image above, all the elements used in this second mockup are the same; the only thing that has changed is their arrangement. In the top part of the page, almost everything has the same style: the banner and the newsletter bar occupy all the window width on the PC desktop as well as the tablet version.

What has changed is the alignment of the menu-list items. In order to make the reading of menu items clear and easy even on a screen with a reduced size, I have planned to increase the space between all the present items. Additionally, the bottom part of the mockup introduces some slight changes: the sidebars that were placed on the left side of the author box have been moved under this and positioned next to each other in order to give them a larger width. Look below for clarity.

As our last step in the mockup process, let’s tackle the smartphone version. I have placed the iPhone shape (as said before, it’s the only one available to represent the profile of all modern smartphones) and duplicated it twice to allow you to view what the user would see by scrolling through the site from the top to the bottom.

As you can see, for the top part of the portal, the arrangement of the newsletter elements has changed, andthe menu-item list is also different compared to the PC desktop and tablet mockups. The input box and the submit button are presented vertically in order to make the process of writing and sending data faster and simpler. As for the menu, the best solution to adopt in this case (since the menu is composed of only five items) is to create a drop-down menu that the user can easily touch to load the page he desires to visit.

All the other components of the page are set to their max width to make the content intuitive and accessible. Even if at this stage you cannot see it, for the text view, you can think about a simple trick to make your users satisfied. Remember that, if your content is too long, they would have to scroll down the page many times to reach the end, and this could easily cause disorientation and boredom. So you could solve this “too much content” problem by placing a “Read more” link that takes the user directly to the information he demands and makes the homepage more streamlined, easier to load, and pleasant to visit, even on a narrow smartphone screen.

Conclusion

In this article, we’ve seen how to build a project mockup thinking responsively and—consequently—how a responsive design can adapt to three target layouts: Default (PC desktop), Portrait Tablet, and Smartphone. We’ve seen how to arrange the elements of a typical website in the three main devices’ categories by creating a template that represents the common content elements. In the third part of this series, we’ll start to write the HTML code and work on the structure of the homepage and set the first CSS styling rules to build an initial design.

Build a Responsive, Mobile-Friendly Website From Scratch: Introduction

Annarita Tranfici — Mon, 25 Mar 2013 14:51:30 +0000

In the last series (“Understanding Responsive Web Design“), I defined the basic features of this new and important responsive approach to mobile-friendly, device-agnostic design. Now, let’s set the stage for a more concrete work.

We’ve seen that there are many aspects to take into consideration throughout the responsive design process: screen size, operating platform, user behavior, and so on. We have explored the various measurement options for fonts in a website, and we’ve covered the best way to approach typography in terms of responsive web design. We’ve explored the characteristics of four different layout types and their respective fields of implementation. We’ve covered some common problems that a web designer may encounter when managing responsive images (and pointed out potential solutions). Finally, we’ve explored the problem of cross-browser compatibility and proposed different ways to achieve it.

Now it’s time to demonstrate some real-world technical applications of the responsive web design and build a real responsive website.

Objectives

Let’s start with defining the objectives of this new series, and highlight what you’ll learn. Thanks to this tutorial…

You’ll learn how to create a responsive design mockup, taking into account the main features of a website, the users’ needs, and the way to effectively combine responsive graphics and web design. The mockup of the website won’t be unique to one platform, and it’ll provide an example of the possible structure of a portal from several standpoints—imagining the view on three different devices: smartphones, tablets, and desktop PCs.
You’ll learn how to take full advantage of modern web technologies, namely HTML5 and CSS3, applying them step-by-step to each component of your web content.
You’ll see how to implement some rules related to responsive web design, by applying what we have analyzed conceptually in prior articles.

Media Queries

One of the foundations or responsive design is media queries, which ultimately make the site accessible and usable by the largest number of users, including those who do not use recent versions of popular browsers such as Internet Explorer, Mozilla Firefox, and Chrome.

Let’s start by getting our hands dirty with media queries; they represent one the most important tools that a web designer has to make their website responsive and mobile-friendly.

Media queries are composed of two main parts:

@ media screen — The first part of a media query is the type of support. You might recognize this syntax from writing your own CSS styles, especially if you used this method before when designing printing options for your website.
(min-width: 500px) — The second part is the query itself. It includes the function to be evaluated (in this case, the minimum width of the browser window) and the corresponding value to test that the rule has been applied (in this case, a value of 500px).

Thinking about responsive web design, there is a tendency to focus exclusively on the width property, but there quite a few other attributes to consider when designing for a variety of screen sizes. There are many more valid properties associated with media queries. They are:

width / height — With these properties, you can set the width and height of the display area including any scroll bar. You can use the prefixes min and max.
device-width/height — These properties set the width and the height of the rendering surface, that is, the width and height of the entire screen of the device and not simply of the display area of the document. Even in this case, you can still use the min and max prefixes.
orientation — it sets a vertical or horizontal orientation. By specifying particular rules in the CSS stylesheet, you will be able to define how the various elements of a web page will be displayed on the device, in this case, depending on the orientation of the device we use. We can then specify the type of orientation; landscape and portrait that allow us to change the layout of your design according to the current orientation of the browser.
aspect-ratio — This is a property that sets the ratio between the width and height of the display of a document. Even in this case, you can still use the min and max prefixes.
device-aspect-ratio — This attribute monitors the ratio between the width and height of the device. Prefixes min and max are allowed.
color — This applies certain CSS styles for all color devices. Prefixes min and max are allowed, but very few black and white devices (besides inexpensive Kindles) remain as popular browsing options
color-index — This describes the number of colors in the palette supported by a device. It can have min and max prefixes.
monochrome — This property indicates the number of bits per pixel of a monochrome device (grayscale).
resolution — Resolution sets the resolution (i.e. the density of pixels) of the output device. The values of the resolution can be expressed in DPI (dots per inch) or in DPCM (dots per centimeter).
scan — a valid property for television screens that indicates the type of scan, interlaced or progressive. The values can be precisely progressive or interlaced.
grid — Grid indicates whether the device is a bitmap type or a “grid” equivalent.

Breakpoints

After this short overview of the main (and often underutilized) properties of media queries, let’s proceed by pointing out what are the best responsive breakpoints and how to determine them for a given project.

Breakpoints in terms of responsive web design are browser widths that have a media query declaration to change the layout once the browser is within a declared width range. More specifically, a breakpoint is a point on a line that starts from 0, where there is a change (via CSS) within the layout of the page. Breakpoints are defined with numeric values and units of measurement based on the media queries entered into your CSS stylesheets.

In general, every responsive website has a minimum of two breakpoints — one for tablets and one for mobile devices. Each breakpoint corresponds to a media query. In the media query below, I wrote CSS that only takes effect when the minimum width of the browser window (min-width) is equal to a specific value (that can be 320px, 480px, 768px, etc..).

Here is an example of one of these standard breakpoints:

@media only screen and (min-width : 320px) {
/* Styles */
}

But, how many breakpoints does a web designer need to create? This depends on the characteristics of the website, on its layout, and on the techniques that you decided to implement in order to turn your design plans into something truly interactive and responsive In essence, we could answer the previous question in this way: You need a breakpoint for every device that you deliberately choose to support.

Breakpoints According to the Devices

Today, the prevailing practice tends to set breakpoints based on the size of the screen (or browser window) of the following popular device types:

Smartphone (with portrait or landscape orientation)
Tablet (with portrait or landscape orientation as well)
Netbook
Desktop PC monitor with high or very high resolution

Translating this scheme into pixels, you can see how for smartphone and tablet categories, the “standard” sizes adopted mainly correspond to the screen dimensions of the iPhone and iPad:

320px — iPhone in portrait orientation
480px — iPhone in landscape orientation
768px — iPad in portrait orientation
1024px — iPad in landscape orientation (as well as netbooks, since these devices typically have a horizontal resolution of 1024px).

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.

It’s extremely important to test your dynamic layouts, including the breakpoints themselves, and the CSS that executes under certain screen size conditions. If you do not have both of those aspects of your responsive design in good order, you’ll end up with glaring layout and functionality problems that make your website less responsive than if you hadn’t attempted any mobile-friendly accommodations. Test your designs thoroughly!

Conclusion

I have introduced the main objectives of the series, and above all, I have given a short but complete introduction on the critical components of media queries and responsive breakpoints. In the next article, I’ll start with the planning and the creation of a mockup for each of the three main device types on which our website will be designed, tested, and displayed.

Want to learn more about Responsive Web Design? Check out SitePoint’s new book, Jump Start Responsive Web Design!

Understanding Responsive Web Design: Cross-browser Compatibility

Annarita Tranfici — Wed, 13 Mar 2013 13:06:22 +0000

In the last article, I described three ways to work with with images from a responsive design standpoint, discussing the best solution to adopt while serving properly-sized imagery to a variety of screen sizes. In today’s article, I’ll focus on imagery management from another point of view, that is cross-browser compatibility.

During the creation of a website — especially if your aim to make its structure responsive — one of the most important and frequent problems that a web designer has to face involves cross-browser compatibility, that is, compatibility across different browsers.

What does “compatibility” stands for? The designer of a website must ensure that their design works properly and that its appearance is error-free and functional on any platform used to view it. It ‘s definitely one of the most complicated and frustrating aspects you must consider when designing a new project, but it’s essential that the you do not leave anything to chance and keep cross-browser compatibility in mind throughout the design process.

Many of the new CSS capabilities introduced in the new CSS3 version are still not widely supported by all major browsers. In fact, some are not recognized and therefore ignored completely, which can pose major problems if your design relied on unsupported CSS. It’s not just a variety of browser types either; different versions of the same browser can support (or fail to support) various design techniques, which complicates cross-browser compatibility even further.

Let’s get back to image management, which probably is the weak point of the RWD approach, especially for browser compatibility issues. Photos and media need to be flexible and adapt to different devices, and at the same time, it’s crucial that they don’t slow down page loading in the process. Therefore, there is still no definitive, ideal solution to problems such as different screen sizes, restricted bandwidth (in cases of mobile browsing), performance on high-resolution (“retina”) displays, and so on.

It is clear that using a single image (the largest possible version) for all devices is not an advisable solution. Think about the time a poor smartphone-2G user would take to load your design. After your ultra-slow image loads, those high-resolution images will probably display at about one quarter of their original size.

The largest problem is that media queries do not work with older browsers. Consequently, a responsive web page with many CSS3 rules applied can be seen correctly only by those who have recently-updated browsers with strong CSS3 support. Fortunately, there are three JavaScript solutions that can help us serve responsive websites to older browsers lacking CSS3 support: Respond.js, Modernizr, and adaptive.960.js. Let’s have a look together.

Respond.js

The first solution is also the simplest one — I’m talking about a script called respond.js, which enables the older browser versions to understand and execute CSS3 media queries. Here’s all it takes to get started.

This script is called on the page (as shown above) and adds support to media queries, min-width, max-width, and all media types (e.g. screen) for older browsers. This script can help your CSS3 instructions work properly, even for older browsers.

Respond.js may seem like it’s too easy to be an ideal solution, but for many projects this is an great solution because the code is read from the latest CSS3 PC browser and all browser designed for smartphones. The sole purpose of the script is to make older browsers read the CSS3 instructions within media queries. Nothing more, nothing less.

Modernizr

The second solution is the use of a tool called Modernizr. As explained in the documentation page of its website, “Modernizr is a small JavaScript library that detects the availability of native implementations for next-generation web technologies, i.e. features that stem from the HTML5 and CSS3 specifications.”

Many of these features are already implemented in at least one major browser (most of them in two or more), and what Modernizr does is—very simply—tells you whether the current browser has this feature natively implemented or not. This is an indispensable tool that gives you fine control over the experience through JavaScript-driven feature detection.

After the first phase of detecting features, Modernizr creates a JavaScript object with the results and adds classes to the HTML element for you to target with your CSS. It’s a gorgeous solution, because it makes it easy for you to write conditional JavaScript and CSS to handle each situation, whether a browser supports a feature or not.

Modernizr supports these browsers: IE6+, Firefox 3.5+, Opera 9.6+, Safari 2+, Chrome, Mobile Safari, Android WebKit browser, Opera Mobile, and Firefox Mobile.

You can download the full version of the library and implement it according to your specifications. However, if you only needs to test the compatibility of CSS3 in your browser, you can set the various options offered by the library and create your own compressed code. Paste the code into an external .js file and include it at the tag of your HTML document. The Modernizr team recommend to include the library just after importing CSS.

You should have this code:



 
  Your title
  
 
 Your content

Now you have a JavaScript library that indicates you whether the CSS3 or HTML5 functions you used are supported or not. Let the page run on the browser and look at the code with Chrome developer tools or Firebug.

You should see something like this:


....

adapt.960.js

The third solution that we consider is very different from the previous two, especially because it does not make use of CSS3 and accordingly of media queries. However, the concept is very similar to the CSS3 media queries.

If we use CSS3 in a single file, this library requires us to separate the code into several CSS files, one for each device type. The library parses the resolution of the device and calls the CSS designed for that specific screen resolution.

We can download the script and see immediately how it works. Activate the library on your page with the following line:

Then, copy the following code:

We see the list of CSS files within the “range,” one for each group of resolutions. Each of these files contains CSS properties related only to a specific device, just as the code enclosed within the CSS media queries.

The common CSS—that is the CSS that should apply to all screen sizes—should be included in a different CSS file, which for convenience we can call master.css and retrieve it before the integration of this library, just like normal CSS file:

Conclusion

Which of the three solutions should we adopt? They are all valid, sensible approaches. If you choose to apply the first solution (respond.js), you’ll have to write and manage a single CSS file, unlike adapt.960.js, which requires multiple CSS files. Finally, if you choose to try Modernizr, you’ll take advantage of new CSS3 capabilities in the browsers that can support them and still have easy and reliable means of controlling the situation for the browsers that cannot.

If you believe that, within few years, older browsers will be irrelevant and that mobile browsers will supersede their desktop counterparts, I believe that it is better to work with media queries and extend support for older browsers with JavaScripts plugins that are available.

Remember that there are also web-based services to test a responsive website and simulate resizing of the browser window. Two of these are responsive.is, which is very easy to use, and studiopress.com, which, after entering the web address, makes different views of your website appear side-by-side.

In addition to web-based solutions, there are also applications that can be installed directly on your personal computer. Among them, we find Opera Mobile Emulator, which is available for Mac, Linux, and Windows. After installing and opening the application, you’ll have a list of devices that it can emulate (with the unfortunate exception of Apple devices).

To conclude this article, I’d like to share a very useful online tool to test the compatibility of your live website: crossbrowsertesting.com. You must choose an operating system and a web browser, and that’s all. A series of well-organized screenshots on multiple browsers will allow you to have a complete view of your site, and in this way, it will be easier to understand on which elements you should modify to make your project perfectly compatible with any platform.

Want to learn more about Responsive Web Design? Check out SitePoint’s new book, Jump Start Responsive Web Design!

Build a Contacts Management App Using HTML5, JS, CSS3, and Wakanda Studio

Saad Mousliki — Thu, 07 Mar 2013 18:32:09 +0000

Many years ago, JavaScript developers were considered second-class citizens in the programming world. JavaScript was only used to perform some easy client-side tasks such as alert messages, form validation, and style manipulation. Nobody was convinced to use it for intensive programming applications due to its limitations and several serious security problems.

But, in the past few years with the arrival of HTML5, JQuery, NodeJS, WebRTC, Google API, and others, JavaScript has become a mature language for developing a robust business applications via server-side coding, NoSQL Databases, JSON format, REST for communication and many other worthy methods.

In this article, we will prove how possible (and even easy) it is to develop a mobile web application that retrieves the phone contacts on disconnected mode and retrieves contacts from a remote server in connected mode using HTML5, JavaScript, and CSS3. We’ll package it using PhoneGap to build to a native mobile app that will work online and offline.

Background

Before starting using this guide, you should have some basics on HTML5, JavaScript, and the mobile development world. In this article, I’ll also use the Wakanda DataStore as a NoSQL database that will be remotely added by our native app to get data using REST/HTTP and JSON format, so having some basics on Wakanda could be very helpful.

Using The Code

Application Architecture

The PhoneGap build input for this mobile application is freely available for download. It’s a zip file developed using the Wakanda Studio smartphone part. The bundle contains numerous noteworthy files.

First and most importantly, it contains the index.html file, which is the main page of our application. This page has three views: one for the homepage that contains two buttons to choose between connected or disconnected mode, a view containing a grid that will load data from the remote Wakanda Server, and a third view that contains a richText widget, which will load the list of mobile contacts using the PhoneGap contact API.

The second file worth mentioning is the config.xml file. This XML file provides some necessary settings to the PhoneGap build service. which to package the app and prepare it for mobile devices. Below is the config.xml data.


    GET CONTACTS
        An application that gets contacts from DataStore and also from phone
        Saad Mousliki

(You could take a look to the official PhoneGap documentation to learn more about how to write this file.)
Two additional noteworthy files are splash.png and icon.png. These two files serve as the splash screen and the icon that will be displayed when installing the packaged app on your mobile device.

Next is the walib folder, which contains the WAF (Wakanda Application Framework) API—a set of JavaScript libraries used to manipulate UI, HTTP/REST communication, mapping, etc.

And, of course, the widely-used scripts and styles folders, which contain the JavaScript and CSS files used by the mobile app.

(Note: To learn more about how to create this application using Wakanda Studio and pre-package it to be accepted by PhoneGap, take a look to this guide and this blog.)

The HTML5 Interface

The HTML5 page is generated using the Wakanda Studio GUI Designer with the dragging and dropping of widgets and careful styling using the properties tabs. Below is an example of a Wakanda HTML5 interface in progress; lets go through the surprisingly-easy process of designing the interface for our mobile app.

Step 1

After installing the Wakanda Studio version 3, open the studio by double clicking its icon. Click on the “Create New Solution” button.

Step 2

Give a name to your solution e.g. “CreateHTML5Page.” Check the “Add a blank project to the solution” checkbox and click the “OK” button.

Step 3

Now, click on the “WebFolder” folder and double-click on the index.html file.

Step 4

Go to the right side of the studio; you will find an arrow to choose between platforms: desktop, tablet, or smartphone. Choose the smartphone page.

Step 5

At this step, the page is empty and should be designed using the widget tab on the left and the properties tab on the right. First, we will add a navigation widget to the page by dragging and dropping the desired widget onto the page.

Step 6

After that, we must add some views (navigation options) to the navigation views widget using the properties tab of this widget.

Step 7

Now, we will add a pair of buttons to the first view.

You could modify the button titles and other properties (width, height, color, etc.) using the properties tab on the right side.

Step 8

To specify an event to the button, we should click on the events button on the right side tab and choose the “onClick” event.

Step 9

For example, we could add code that allows switching between views. We will use the navigation view method “goToNextView”, so when we click on this button we will go to the View number 2. Look below for clarity.

button1.click = function button1_click (event)
{
$$("navigationView3").goToNextView();
}

(Note: To learn more on how to create a mobile web app using Wakanda Studio, take a look to this video for a step-by-step description of how to create and test mobile apps on an iPod.)

After creating a page, we should pre-package (prepare it to be packaged by PhoneGap build) it using the step-by-step described in this blog.

Retrieving Contacts Using the PhoneGap Contact API

The following JavaScript code will be executed when the “Get contacts from phone” button is clicked.

var options = new ContactFindOptions(), name, phoneNumber;
options.filter = "";
options.multiple = true;
var fields = ["name", "phoneNumbers"];
function onSuccess(contacts) {
var res = "";
for(var index = 0, len = contacts.length; index < len; index++) { name = contacts[index].name; name = name != null ? name.formatted : ""; phoneNumber = contacts[index].phoneNumbers; phoneNumber = phoneNumber != null && phoneNumber.length > 0 ? phoneNumber[0].value : "";
res += name + "   : " + phoneNumber + "n";
}
$$('textField2').setValue(res);
navView.goToView(3);
}
function onError() {
alert('onError!');
}
navigator.contacts.find(fields, onSuccess, onError, options);

For more details about this code, take a look to the PhoneGap contact API.

Package the App Using PhoneGap Build

This video will show you how to package the web app, starting by uploading the .zip file to getting the .ipa file. For the complete description, we’ll start by downloading the .zip file offered at the beginning of this article and unzipping it.

Take the “Client_Side” folder within the .zip file and zip it to get the desired input file for the PhoneGap build service.

You should have an account on PhoneGap build to upload and build the application, so if you don’t have an account yet, you could create one.

After creating an account, go to the apps page, upload the zip file (Client_Side.zip), and build it! Look below for clarity.

Setting Up Server-Side Elements

For the server-side application, you should take the “Server_Side” folder and run it on Wakanda 3 Server, using a command line or Wakanda Studio. The command line is:

“C:Wakanda Server.exe” ”C:Download the applicationServer_SidegetPhoneContact SolutiongetPhoneContact.waSolution”

After that, you should go to the “Client_Side” folder, and within the “scripts” folder, open the index-smartphone.js and add the IP address of the machine where you have hosted your Wakanda application on the following lines:

WAF.config.baseURL = "http://@IP_of_the_Wakanda_Server:8081";
WAF.core.restConnect.defaultService = 'cors';
WAF.core.restConnect.baseURL = "http://@IP_of_the_Wakanda_Server:8081";
WAF.onAfterInit = function onAfterInit() { // @lock
// @region namespaceDeclaration// @startlock
var documentEvent = {}; // @document
var button2 = {}; // @button
var button1 = {}; // @button

Now, you could access the Wakanda DataStore remotely using the WAF API.

(Note: To build the .ipa for your iPhone, you should provide a provisioning key and the password of your Apple store account.)

Conclusion

This application is a simple demonstration of Wakanda Studio, as well as a much greater testament to the capabilities of HTML5, JavaScript, and CSS3 for the creation of powerful mobile apps. Using the process of development used in this example (from HTML5, JavaScript, and CSS to native app), we could deliver a cross-platform native mobile application in very little time, so by using PhoneGap, a developer with little background in Java or Objective-C can start developing native mobile apps for many mobile platforms simultaneously. Developing this application, testing it, and packaging it using PhoneGap build took be less than a day’s work.

Build a Currency Converter with jQuery Mobile and Cordova: Finishing The App

Aurelio De Rosa — Tue, 05 Mar 2013 16:42:54 +0000

In the previous part of this series, I showed several other functions of the functions.js file, highlighting their key points. In this sixth and final part, I’ll describe the last function left and the Cordova configuration file that we will use to set properties for our project and define several directives for the Adobe PhoneGap Build service.

Initializing the Application

First, within the index.html file, I’ll attach the function, initApplication()—which I’ll describe in a few moments—to the deviceready event, which is fired when Cordova is fully loaded.

$(document).one('deviceready', initApplication);

Once started, the function translates the multi-language written copy described in Build a Currency Converter with jQuery Mobile and Cordova: Translation and Conversion Logic, calling the translateMainPage() function if the user’s preferred spoken language is available. Then, it calls the openLinksInApp() function to manage external links, as described in part 5. These two actions are independent from the rest of the application, even if the device doesn’t satisfy the requirements.

translateMainPage();
openLinksInApp();

After running the two operations mentioned above, “Currency Converter” tests the device against the requirements (discussed in part 4), and if they aren’t satisfied, it disables the “Convert” button and exits the function.

if (checkRequirements() === false)
{
  $('#submit-button').button('disable');
  return;
}

Now that the basic operations have been executed, we can run the other and more heavy (actually, they’re not really that heavy) functions. So, to give the user a feeling that something is happening behind the scenes, one function displays the loader widget. Then, it continues updating the interface, filling the two select boxes with the stored currency values by calling fillCurrenciesSelection(), the function to update the rates, updateExchangeRates(), and the final function that updates the labels by reading the date and time of the last currency exchange rate update, updateLastUpdate().

$.mobile.loading('show');
fillCurrenciesSelection();
updateExchangeRates();
updateLastUpdate();

At this point, all the necessary processes have been called, and we need to attach handlers to some of the pages’ elements and events. The first handler will update the rates as soon as the online event is fired. The latter, as you may guess, fires when a Cordova application detects that it’s connected to the Internet.

$(document).on('online', updateExchangeRates);

The next handler is very important, since it’s the one the execute the money conversion and because it’s attached to the “Convert” button. After it has retrieved the values of the money and the two currencies selected from the interface, it calls the convert() method of the Currency class to made the conversion calculation. Then, it calls the numberToString() to localize the result based on the user preferences and injects the end result into the page. Finally, it updates the app settings with the last currencies chosen by the user.

$('#submit-button').click(function(event) {
  event.preventDefault();
  // Convert the value
  var result = Currency.convert(
    $('#from-value').val(),
    $('#from-type').val(),
    $('#to-type').val()
  );
   // Localize the result
   navigator.globalization.numberToString(
    result,
    function(number)
    {
      $('#result').text(number.value);
    },
    function()
    {
      $('#result').text(result);
    }
  );
  // Update settings
  var settings = Settings.getSettings();
  if ($.isEmptyObject(settings))
    settings = new Settings();
  settings.fromCurrency = $('#from-type').val();
  settings.toCurrency = $('#to-type').val();
  settings.save();
});

Having finished the “Convert” button functionality, we can now move on to the “Reset” button. Its behavior is quite straightforward. If the user clicks it, we set the input field for the money to convert and the conversion result to zero. We also reset the last chosen currencies by changing the selected currency types for both the select boxes to the first currencies listed.

$('#reset-button').click(function(event) {
  event.preventDefault();
  $('#from-value').val(0);
  $('#form-converter select').prop('selectedIndex', 0).selectmenu('refresh');
  $('#result').text(0);
});

The last handler we need to put in place is for the “Update data” button—the one at the top-right of the main screen. The attached function simply tests for an Internet connection, and if it’s found, runs the updateExchangeRates() function. Otherwise it notifies the user that it’s not connected to the Internet.

$('#update-button').click(function(event) {
  event.preventDefault();
  if (navigator.network.connection.type === Connection.NONE)
  {
    console.log('The connection is off. Can't update exchange rates.');
    navigator.notification.alert(
      'Your device has the connections disabled. Can't update exchange rates.',
      function(){},
      'Error'
    );
  }
  else
    updateExchangeRates();
});

Now that all of the pieces are in their place, we can hide the loading widget from the user so that they’ll know that that all background operations are finished.

$.mobile.loading('hide');

As a conclusion of the whole discussion, here is a screenshot of our “Currency Converter” app:

Create the Cordova Configuration

Since we’ll use the Adobe PhoneGap Build service to package our project, in order to set its metadata (the version, the name, the author, and so on), we’ll use a configuration file called config.xml. Explaining the format in detail is outside the scope of this article, but I’ll highlight the main concepts and focus on the important tag. To have an in-depth look of what you can do with this file, you can read the official documentation page.

The cited file follows the W3C widget specification and must reside in the root of the project files, at the same level as the index.html file. The root of the whole document is a tag that has several attributes, but the mains ones are id (the unique identifier of the app) and version (that specifies the version of the app). Inside the tag, you can include several elements:

name (required): Specify the name of the application. It doesn’t have to be unique.
description (required): Specify the description of your work. This will be shown in the app’s marketplace listing.
author (optional): The app’s author. Unfortunately, you can only specify one author, so you can’t have details for multiple authors.
icon (optional): The icon to display on the devices that will install your app. If you do not specify it, the Cordova logo will be used.
feature (optional): Specify the features you want to use. Some operating systems, before installing the app, ask the user to provide permissions for those features. In “Currency Converter”, the only required feature is access to the Internet connection.
preference (optional): A set of preferences you want to apply, such as the Cordova version, to use when packaging the project.
splash (optional): This tag sets the splash screen of the application—the image to show while it’s loading.

The tag is very important because, citing the documentation, it provides your app with access to resources on other domains—in particular, it allows your app to load pages from external domains that can take over your entire webview. Recalling what we discussed in the section “Managing External Links” of the previous part, in order to open the external links in the Cordova WebView, we must add them to the app whitelist. Using the tag, you have several ways to add links. In fact, you can specify each link you want to add individually. Consider the following example:

For each of the above approved domains, you can also include all the subdomains using the subdomains attribute:

Since our app won’t retrieve links from external and unsafe sources, we can shorten the process allowing for any external resource using the * special character like the following example:

Now that I’ve pointed out the key points of the format, you can understand the source of the configuration file of our project. The complete file is below.



   Currency converter
   Currency converter is a simple app that helps you convert from a currency to another. You can update the exchange rates anytime you want so you'll have always an up-to-date conversion.
   Aurelio De Rosa

Conclusion

I have to compliment those of you who completed the whole series. The growing number of hybrid apps released, including the one we just built, prove that you can build amazing games and utilities using web technologies that you’ve already mastered. There are pros and cons in choosing to develop a hybrid app, but this is definitively one additional tool in your development tool belt. My last contribution is giving you the link to the Currency Converter repository. Here you’ll find and download the full and ready-to-work package. For those of you that are too lazy to build the app, I have also created a public page where you can download the installer for every platform supported by the Adobe Build PhoneGap service. As a final note, Currency Converter is released under the CC BY 3.0 (“Creative Commons Attribution 3.0″) license.

I hope you enjoyed the series and have more comfort and confidence with hybrid apps. Thanks for following!

Build a Currency Converter with jQuery Mobile and Cordova: Rate Updates

Aurelio De Rosa — Fri, 01 Mar 2013 01:07:15 +0000

In the previous article in this series, I described the classes and functions needed to perform currency conversions within our app. I also illustrated the Cordova Globalization API and how we can use it to translate the written instructions on the main page of “Currency Converter.” In this next installment, I’ll show you the remaining functions of the functions.js file and a brief overview of the Cordova Connection and InAppBrowser APIs.

Utility Functions

Updating the “Last Update” Label

In the introductory article of this series, I explained that our project will store the downloaded currency rates so that the user can use the application offline. Since the currency exchange rates change every day, it’s important to notify the user of how old his exchange rates are. If he feels that they are too old, he can run an update and download the latest. For this reason, the main page has the following code:

Last update of exchange rates:

The having id="last-update" is where we’ll inject the date of the last update. Th date will be written in the format that best suits the user preferences determined by the Globalization API, which I explained in the previous article. Recalling the third article where we talked about the user settings, you should recall that we update and save the date each time the user request an exchange rates update via the Settings class and its methods.

The function that updates the text of the above tag is updateLastUpdate(), and its markup is the following:

function updateLastUpdate()
{
  if (typeof Settings.getSettings().lastUpdate === 'undefined')
  {
    $('#last-update').text('-');
    return;
  }
  // Show the last time the rates have been updated
  navigator.globalization.dateToString(
    new Date(Settings.getSettings().lastUpdate),
    function (date)
    {
      $('#last-update').text(date.value);
    },
    function ()
    {
      $('#last-update').text('-');
    }
  );
}

Updating the Rates

The method that deals with the actual updating is updateExchangeRates(). At the very beginning of the method, there is a test to verify whether the device is connected to the Internet or not. The test is done using the Cordova Connection API—an object that gives access to the device’s cellular and wifi connection information. It has one property called type that checks the active network connection that is being used and can assume the following values (as constants):

Connection.UNKNOWN
Connection.ETHERNET
Connection.WIFI
Connection.CELL_2G
Connection.CELL_3G
Connection.CELL_4G
Connection.NONE

If the device has an active connection, the function makes a call to the European Central Bank RSS feed to retrieve the rates using the jQuery ajax() method. Once retrieved, the rates are stored using the Currency class, and the lastUpdate data of the user’s settings is updated as well, so the user knows that they’re working with the latest currency exchange rates.

The two select boxes and the “last update” label of the main page are updated using this current data. Then, the two select menus are filled using a function called fillCurrenciesSelection(), which I’ll describe in a few moments. As a final note, if the rate update fails, the user is notified with an alert of this failure shown using the Cordova Notification API.

So, what exactly will happen if the first test fails? Well, if the device does not have an active Internet connection, the app will check if there are any stored rates. If there are no stored currency exchange rates, the user is notified of the issue, and the “Convert” button is disabled, because there aren’t any ways to run any currency conversions.

The code that implements this functionality is listed below:

/**
 * Update the exchange rates using the ECB web service
 */
function updateExchangeRates()
{
  if (navigator.network.connection.type !== Connection.NONE)
  {
    $.mobile.loading(
      'show',
      {
        text: 'Updating rates...',
        textVisible: true
      }
    );
    $.get(
      'http://www.ecb.int/stats/eurofxref/eurofxref-daily.xml',
      null,
      function(data)
      {
        var $currenciesElements = $(data).find('Cube[currency]');
        // The EURO is the default currency, so it isn't in the retrieved data
        var currencies = [new Currency('EUR', '1')];
        var i;
        for(i = 0; i < $currenciesElements.length; i++)
        {
          currencies.push(
            new Currency(
              $($currenciesElements[i]).attr('currency'),
              $($currenciesElements[i]).attr('rate')
            )
          );
        }
        currencies.sort(Currency.compare);
        // Store the data
        for(i = 0; i < currencies.length; i++)
          currencies[i].save();
        // Update settings
        var settings = Settings.getSettings();
        if ($.isEmptyObject(settings))
          settings = new Settings();
        settings.lastUpdate = new Date();
        settings.save();
        fillCurrenciesSelection();
        updateLastUpdate();
        $('#submit-button').button('enable');
      },
      'XML'
    )
    .error(function() {
      console.log('Unable to retrieve exchange rates from the provider.');
      navigator.notification.alert(
        'Unable to retrieve exchange rates from the provider.',
        function(){},
        'Error'
      );
      if (Currency.getCurrencies().length === 0)
        $('#submit-button').button('disable');
    })
    .complete(function() {
      $.mobile.loading('hide');
    });
  }
  // Check if there are data into the local storage
  else if (Currency.getCurrencies().length === 0)
  {
    console.log('The connection is off and there aren't rates previously stored.');
    navigator.notification.alert(
      'Your device has the connection disabled and there aren't rates previously stored.n' +
      'Please turn on your connection.',
      function(){},
      'Error'
    );
    $('#submit-button').button('disable');
  }
}

Filling the Select Boxes

The function to update the select boxes isn’t very hard to grasp. It simply retrieves the stored currencies using the getCurrencies() method of the Currency class and then insert each of them using the jQuery append() method. It’s worth noting that after all the currencies are inserted, this function searches for the last origin and destination currencies saved within the user preferences If these last used currencies are found, they are automatically selected. In this scenario, the listview widget needs to be refreshed, which accomplished using the method selectmenu() and passing the string refresh to it.

The complete source of fillCurrenciesSelection() is listed below:

/**
 * Use the stored currencies to update the selection lists
 */
function fillCurrenciesSelection()
{
  var currencies = Currency.getCurrencies();
  var $fromCurrencyType = $('#from-type');
  var $toCurrencyType = $('#to-type');
  // Empty elements
  $fromCurrencyType.empty();
  $toCurrencyType.empty();
  // Load all the stored currencies
  for(var i = 0; i < currencies.length; i++)
  {
    $fromCurrencyType.append('
' +      currencies[i].abbreviation + '
');
    $toCurrencyType.append('
' +      currencies[i].abbreviation + '
');
  }
  // Update the selected option using the last currencies used
  var settings = Settings.getSettings();
  if (!$.isEmptyObject(settings))
  {
    var currency = $fromCurrencyType.find('[value="' + settings.fromCurrency + '"]');
    if (currency !== null)
      $(currency).attr('selected', 'selected');
    currency = $toCurrencyType.find('[value="' + settings.toCurrency + '"]');
    if (currency !== null)
      $(currency).attr('selected', 'selected');
  }
  $fromCurrencyType.selectmenu('refresh');
  $toCurrencyType.selectmenu('refresh');
}

Managing External Links

As you’ve seen in the interface design of “Currency Converter”, the aurelio.html file have several external links within it. Those links aren’t very useful, but I do need to explain an important concept.

Until a few versions ago, Cordova opened external links in the same Cordova WebView that was running the application. So, once it opened a link, when the user clicked the “back” button, the last project’s page was shown exactly as it was before the user left it. But, in the most recent release of the framework, this behavior was changed; now, the external links are opened by default using the Cordova WebView if the URL is in your app’s whitelist. URLs that aren’t on your whitelist are opened using the InAppBrowser API.

Citing the official documentation, the InAppBrowser is a web-browser that is shown in your app when you use the window.open call. This API has three methods: addEventListener(), removeEventListener(), and close(). The first allows you to listen for three events (loadstart, loadstop, and exit) and allows you to attach a function that runs as soon as those events are fired. The second method, as you might guess, is used to remove a previously-attached listener. Finally, the close() method is used to close the InAppBrowser window.

If the user opens a link that is shown in the InAppBrowser or the system browser and then goes “back” to the application, all the CSS and jQuery Mobile enhancements are lost. This happens because the external link doesn’t the reference the cited files and when the user goes back into the app; the file is loaded as it were requested for the first time, but without passing through the main page. Obviously, this is something you’ll want to avoid, which highlights the importance of the the whitelist within the Cordova configuration file and the next function come in help.

The aim of the openLinksInApp() function is to catch the clicks on all the external links (recognized by using the target="_blank" attribute), preventing the unwanted default behavior and opening them using the window.open() method. As you’ll see in the code shown below, I’ll use the _target parameter so that the links will be opened using the WebView, because I’ll put these URLs in the Cordova whitelist. Using this technique, we’ll avoid the issues described above, and your app will continue to look and function as expected.

/**
 * Open all the links as internals
 */
function openLinksInApp()
{
   $("a[target="_blank"]").on('click', function(event) {
      event.preventDefault();
      window.open($(this).attr('href'), '_target');
   });
}

Conclusion

In this article, I described several other functions of the functions.js file, highlighting the key points of each. I also explained the Cordova Connection and the InAppBrowser API and how they work. As we’ve seen, dealing with external links is extremely important when you’re using jQuery Mobile to build your mobile app interface. In the next and final article in this series, I’ll show you the function that initializes the application, called initApplication(), and the Cordova configuration file that we will use alongside the Adobe PhoneGap Build service to package our “Currency Converter” app.

Build a Currency Converter with jQuery Mobile and Cordova: Translation and Conversion Logic

Aurelio De Rosa — Mon, 18 Feb 2013 17:28:15 +0000

In the previous article of this series, I described the jQuery Mobile custom configuration for our app and highlighted the importance of allowing cross-domain requests to download up-to-the-moment currency exchange rates. I also described a class that will help us translate the app into multiple spoken languages, and I outlined a second class to manage user settings. In this fourth article, I’ll show you the classes that save, load, and complete currency operations, as well as the one that unifies all of the different components of our app.

The Currency Class

When I talked about the Settings class, I described the aim of the _db and _tableName variables. The Currency class has these variables too, and it shares the same purpose. Of course, the value of _tableName is different, as are the “currencies.” Keep in mind that we’re not storing an object—we’re storing an array containing Currency instances. We have to store data beyond the last update or the last currencies used; we also need to save the name of the currency (actually its abbreviation) and the conversion rate itself.

We’re retrieving the rates from the European Central Bank, and they use the Euro as the reference money. So, when you parse the feed, you won’t find the Euro rate itself (a rate of 1.00 is assumed), and the rates you’ll are all relative to the Euro. This leads to a tricky method to make non-Euro currency comparisons, which I’ll explain in detail when I describe the convert() method.

Based on what I stated so far, the beginning of the Currency class is the following:

function Currency(abbreviation, rate)
{
  var _db = window.localStorage;
  var _tableName = 'currencies';
  this.abbreviation = abbreviation;
  this.rate = rate;
}

Just like the Settings class, we’ll have the save() and the load() methods. The latter is identical to the one already discussed, while the former is quietly different because we’re managing an array. Since we don’t want duplicated currencies, we need to check if a given currency is already stored before adding to the array. If the currency is already present, we’ll just update the conversion rate. Otherwise, we’ll push the whole object into the array. To achieve this goal, I’ll create a static method called getIndex(), which returns the index of the currency if it’s found or returns false otherwise. Just like you’ve seen for the Settings class, I’ll write a utility static method to retrieve the array containing Currency instances called getCurrencies().

Now that you’re aware of this tricky situation, I can show you the code of the save() and load() methods.

this.save = function()
{
 var currencyIndex = Currency.getIndex(this.abbreviation);
 var currencies = Currency.getCurrencies();
 if (currencyIndex === false)
   currencies.push(this);
 else
   currencies[currencyIndex] = this;
 _db.setItem(_tableName, JSON.stringify(currencies));
}
this.load = function()
{
 return JSON.parse(_db.getItem(_tableName));
}

And, below is the code for the two static methods:

Currency.getCurrencies = function()
{
  var currencies = new Currency().load();
  return (currencies === null) ? [] : currencies;
}
Currency.getIndex = function(abbreviation)
{
  var currencies = Currency.getCurrencies();
  for(var i = 0; i < currencies.length; i++)
  {
    if (currencies[i].abbreviation.toUpperCase() === abbreviation.toUpperCase())
      return i;
  }
  return false;
}

Now that we’re able to save and load currencies, we need a method to do mathematical currency conversions. Before showing you the code of the methods, I should highlight one thing. As I said, the feed uses the Euro as the reference currency, so you won’t store distinct conversion rates for each and every currency—this would be a waste of memory. What we’ll devise is a method to convert from Euro to other currencies for each desired currency type.

Now, suppose that you want to convert from USD to AUD, what you can do? The solution is that you first convert to Euro and then into the currency you truly need.

To achieve this goal, you need to first divide by the starting rate and then multiply by the goal currency rate. The convert() method requires three parameters: the value to convert, the starting currency, and the goal currency. This method relies on another method, called getRate(), which, using abbreviation (the abbreviation of the currency name), retrieves the appropriate conversion rate. getRate() relies on a method that I haven’t explained yet called getCurrency(). As you might imagine, it’s very similar to getCurrencies(), except that it accepts an abbreviation as a parameter and returns a Currency instance if the search succeed or null return if it failed.

The source code of these three methods is listed below:

Currency.getCurrency = function(abbreviation)
{
  var index = Currency.getIndex(abbreviation);
  return (index === false) ? null : Currency.getCurrencies()[index];
}
Currency.getRate = function(abbreviation)
{
  var currency = Currency.getCurrency(abbreviation);
  return (currency === null) ? 0 : currency.rate;
}
Currency.convert = function(value, from, to)
{
  // Round up to the 2nd decimal
  return Math.round(value / Currency.getRate(from) * Currency.getRate(to) * 100) / 100;
}

The last two methods are those that will be used during the update of the select boxes to select the currencies to sort them alphabetically. Their names are compareTo() and compare(), and their code is the following:

Currency.prototype.compareTo = function(other)
{
  return Currency.compare(this, other);
}
Currency.compare = function(currency, other)
{
  if (other == null)
    return 1;
  else if (currency == null)
    return -1;
  return currency.abbreviation.localeCompare(other.abbreviation);
}

Utility Functions

In this section, I’ll explain the utility functions contained in the functions.js file. Please note that I’ll avoid explaining updateIcons(), because it has already been discussed and provided in a previous series. So, if you want to understand what it does, you can read the section called “Update Icons Based on the Screen Size” from Build a Location-Based Mobile App With HTML5 and Javascript: Part 4.

Testing for Requirements

“Currency Converter” doesn’t have a lot of requirements. In fact, the only mandatory condition we need is the possibility to store data using the Web Storage API. While the ability to connect to the Internet is important, it’s only needed the first time the user runs the application, because he’ll need to download the latest rates from the European Central Bank RSS feed. But, after that, the user can continue to work offline with slightly outdated currency conversion rates. Obviously, without the Internet connection enabled, we won’t be able to update the rates.

To test for requirements, I’ll create a function called checkRequirements(), which will test for Web Storage API support. If the device doesn’t support it, the app notifies the user using the Cordova Notification API and returns false, so the button to update the currency conversions can be disabled. The code of this function is shown below.

function checkRequirements()
{
  if (typeof window.localStorage === 'undefined')
  {
    console.log('The database is not supported.');
    navigator.notification.alert(
      'Your device does not support the database used by this app.',
      function(){},
      'Error'
    );
    return false;
  }
  return true;
}

As you can see I also wrote a console.log() instruction to help you debug the project in case you need to. Remember, using alert() is not a best practice.

Translating Pages

To translate the elements of index.html, I’ll use the Globalization API, introduced in Cordova 2.2.0., which allows you to get information about user’s locale and timezone, thanks specifically to methods like getPreferredLanguage() (which gets the client’s current spoken language) and getLocaleName() (which retrieves the identifier code of the client’s current locale setting e.g. en_US or it_IT).

In addition, this API has methods to perform operations like converting dates and numbers into strings using the proper local format based on the user’s settings. The methods that implement these conversions are dateToString() and numberToString() respectively. Please note that like the other Cordova APIs, these methods are asynchronous, so they use success and failure callback functions.

In our project, we’ll use some of the previously-cited methods, specifically: getLocaleName(), dateToString(), and numberToString(). This API is very important, because it allows you to move the user experience one step forward compared what you could do in previous versions. Please note that currently the supported platforms are Android, BlackBerry WebWorks (OS 5.0+), iOS, and Windows Phone 8.

As you’ll see in the code below, I used the getLocaleName() method to retrieve the language identifier, which I’ll use to get the right language from within the Translation object. Once retrieved, I’ll iterate over the text strings to translate the various instructional elements. Now, you should finally understand why I used the elements’ id as properties’ name. You’ll also note the use of Audero Text Changer to change the elements’ text, which I illustrated in the first part of this series.

/**
 * Translate the main page
 */
function translateMainPage()
{
  navigator.globalization.getLocaleName(
    function(locale)
    {
      var translation = Translation[locale.value.substring(0, 2)];
      if (typeof translation === 'undefined')
        return;
      for(var key in translation)
        $('#' + key).auderoTextChanger(translation[key]);
    },
    function()
    {
      console.log('An error has occurred with the translation');
    }
  );
}

Conclusion

In this fourth article, I described the Currency class and all of its methods. As you learned, it has several utility methods that allow you to write new methods with very few lines of code. I also showed how to test for the minimum app requirements and gave a brief overview of the Globalization API, as well as the specific the methods used in our project. To help us manage the translation of interface elements, I used the Audero Text Changer plugin. In the next part of the series, I’ll show you the remaining functions of the functions.js file to complete the discussion.

Build a Currency Converter with jQuery Mobile and Cordova: JavaScript and User Settings

Aurelio De Rosa — Wed, 13 Feb 2013 16:45:02 +0000

In the second part of the series, I showed you the code of the two HTML pages and the custom CSS file of our “Currency Converter” app. In this article, I’ll show you the jQuery Mobile custom configuration and some of the JavaScript files that implement the business logic. While describing the JavaScript files, I’ll also demonstrate the Cordova APIs in detail.

jQuery Mobile Custom Configuration

jQuery Mobile has a default configuration that is usually good enough for most of the projects with basic requirements. However, you may still need to set up some specific custom rules to fit your app’s requirements. As I said in the first part of the series when I presented the list of the files that make up our app, we have a file called jquery.mobile.config.js, which is exactly where we would specify a configuration. In this section, I’ll show you what options I’ll change.

(Please note that when you create a file like this, you must include it before the library files itself. In fact, when jQuery Mobile starts, it fires an event called mobileinit, which is used to override the default settings.)

You have two different ways to specify the settings, but I’ll use the method that changes the properties of the $.mobile object. I’ll change just some of them, but if you need an overview of all of the jQuery Mobile properties, you can read the jQuery Mobile configuration docs. Our file will change the options concerning the page loader widget, the theme, and those that allow cross-domain requests. The settings to allow cross-domain requests are the most interesting ones and well worth a discussion.

As you learned in the app requirements, “Currency Converter” will make a call to the European Central Bank RSS feed to update the currencies rates, so we need to be able to do HTTP requests to an external source. When you use the Cordova framework in conjunction with jQuery Mobile, to be able to make cross-domain requests, you need to set one property in the config.xml file of for first framework (Cordova) and two properties for the second (jQuery Mobile).

The jQuery Mobile properties to change are $.support.cors and $.mobile.allowCrossDomainPages. The first is a boolean that you need to set to true in order to tell the browser to support cross-domain requests. The project also has links to external pages (in the credits page) so, we must also set the $.mobile.allowCrossDomainPages property to true. In fact, when jQuery Mobile tries to load an external page, the request runs through the $.mobile.loadPage() method, which will only allow cross-domain requests if the cited property is set to true. By default, its value is false, because, according to the documentation, the framework tracks what page is being viewed within the browser’s location hash, so it is possible for a cross-site scripting (XSS) attack to occur if the XSS code in question can manipulate the hash and set it to a cross-domain URL of its choice. This option must be set before the requests are made, and the documentation suggests putting it into the initial configuration. We’ll act accordingly.

Now that you know the meaning of these options, you’re ready to see the full source of jquery.mobile.config.js.

$(document).on(
  'mobileinit',
  function()
  {
    // Page Loader Widget
    $.mobile.loader.prototype.options.text = 'Loading...';
    $.mobile.loader.prototype.options.textVisible = true;
    // Bypass Access-Control-Allow-Origin
    $.support.cors = true;
    $.mobile.allowCrossDomainPages = true;
    // Theme
    $.mobile.page.prototype.options.theme  = 'b';
    $.mobile.page.prototype.options.headerTheme = 'b';
    $.mobile.page.prototype.options.contentTheme = 'b';
    $.mobile.page.prototype.options.footerTheme = 'b';
    $.mobile.page.prototype.options.backBtnTheme = 'b';
  }
);

The Translation Class

Recalling the project’s requirements, you’ll remember that “Currency Converter” is a multi-language app. Since its most important part is index.html, I’ll create translations for that page and ignore translations for aurelio.html. I think that having the credits solely in English is adequate.

To store the strings of the different languages within the translation.js file, I used an object calling the variable Translation. This object has as many properties as the spoken languages that you want support. So, since we’ll translate it into Italian, French, and Spanish, we’ll have three properties whose values are objects containing the strings. To simplify the translation process, these objects have the id of the elements that will be translated as their property names, and the string to change as their values. To understand how Translation is made, it’s enough to see one language, so I’ll show you just the Italian, but you’ll find the others will be supported within the app repository.

var Translation = {
  'it': {
    'app-description': 'Currency Converter è una semplice applicazione che ti aiuta a convertire da una valuta ad un'altra. È anche possibile aggiornare i tassi di cambio ogni volta che si desidera così da avere sempre dei tassi di conversione aggiornati.',
    'convert-title': 'Converti',
    'from-value-label': 'Valore:',
    'from-type-label': 'Da Valuta:',
    'to-type-label': 'A Valuta:',
    'result-title': 'Risultato',
    'copyright-title': 'Creata da Aurelio De Rosa',
    'credits-button': 'Crediti',
    'update-button': 'Aggiorna dati',
    'submit-button': 'Converti',
    'reset-button': 'Azzera dati',
    'last-update-label': 'Ultimo aggiornamento cambi:'
  }
  // other languages here
}

The User Settings

In the introductory article of this series, I stated:

The app will save the last currency used for a conversion, so at the next start of the application, the user will find their last-used currency. In addition, the date and time of the last update will be stored too, so that the user knows how recent (or old) his conversion rates are.

Thus, we need to manage and store these data. To achieve this goal, we’ll use the Cordova Storage API, which is built on the top of the Web Storage API and Cordova. For the devices that have built-in support, it uses the native implementation instead of its own, which is compatible with the W3C specs.

In this section, I’m going to describe the file called settings.js that contains the class called Settings. Let’s take a closer look at this file.

As you already know, this class has three public properties: lastUpdate, fromCurrency, and toCurrency. It also has two private ones: _db and _tableName. The aim of the first three properties should be self-evident so I’ll skip their explanation. _db is a reference to the window.localStorage property that will be used to call the Web Storage API’s method to store and retrieve the data from the browser (or, in the case of our hybrid app, from the device). Keep in mind that this API doesn’t use real tables like a DBMS does. Instead, it has a set of properties whose values are a basic type (like a string or a number) or a JSON-encoded object. Having said that, it should be clear that _tableName isn’t a property having as its value a string containing the name of a real table, but rather the name of the property where we’ll store the JSON-encoded object containing the user settings.

The following code shows what I’ve explained so far.

function Settings(lastUpdate, fromCurrency, toCurrency)
{
  var _db = window.localStorage;
  var _tableName = 'settings';
  this.lastUpdate = lastUpdate;
  this.fromCurrency = fromCurrency;
  this.toCurrency = toCurrency;
}

Now, we need two methods: one to store the data, and one to retrieve them. In another one of my astonishingly-creative moments, I named these methods save() and load() respectively. These methods do nothing but wrap the call the getItem() and setItem() methods, as you can see by looking at their code below.

this.save = function()
{
  _db.setItem(_tableName, JSON.stringify(this));
}
this.load = function()
{
  return JSON.parse(_db.getItem(_tableName));
}

Some of you who have have already used the Web Storage API might wonder why I used setItem() and getItem() instead of using the dot notation. The reason is that Windows Phone 7 doesn’t support the latter, so to ensure the compatibility across all the operating systems, we’ve got to use the former.

This class has another method to discuss that is more of a utility than a must-have method. It’s called getSettings() and it’s a static method. When you use load(), the retrieved object isn’t an instance of the Settings class but of the Object equivalent. Now, suppose that you want to change the current user’s settings based on the ones you stored. In this case, it’s a lot easier to have a Settings instance, so that you can modify the properties and then call the save() method directly. For this reason, I created getSettings(), which calls load() and then converts the result into a Settings instance. The source of this utility is the following:

Settings.getSettings = function()
{
  var settings = new Settings().load();
  return (settings === null) ?
     {} :
     new Settings(
       settings.lastUpdate,
       settings.fromCurrency,
       settings.toCurrency
     );
}

Conclusion

In this third article of the series, I described the custom configuration of “Currency Converter” and the importance of the options to allow cross-domain requests. Additionally, I showed the class used to translate the application and the class used to save the user settings. In the next part of the series, I’ll illustrate the other two remaining JavaScript files: functions.js (which has the functions to retrieve the rates, update the currencies select boxes, and initialize the application), and currency.js, the file that contains the class to store, load, sort, and convert the retrieved currencies.

Responsive Web Design: Custom Grid Layouts

Annarita Tranfici — Tue, 12 Feb 2013 13:00:45 +0000

In the last few parts of the responsive design series, I have introduced the characteristics of fluid layouts and I have described how to use fonts responsively. In this article, I want to introduce grid layouts, a widespread and popular design practice. While grid systems have seen significant use in printed media, interest from web and mobile developers has been a very recent development.

A grid is a two-dimensional structure made up of intersecting vertical and horizontal divisions used to structure content. Grids serve as the framework on which a designer can organize text and images into a rational, easy-to-absorb interface. A well-built and properly-implemented grid system increases scalability and improves the readability of the content on a website or within a mobile application.

The advantages of grid layouts are numerous; a grid structure…

gives order, originality, and harmony to the presentation of content;
allows users to predict where to find the information they need;
makes it easier to add new content without having it looking disjointed or marginalized.

To develop a well-built grid layout, the first step is to create the canvas structure itself. It’s the canvas’ size that determines the grid’s frame: it is divided into the number of columns the designer wants (3,5,9,12) and this is the starting point to work on your interface or layout.

The size of a grid does not have to be defined with fixed parameters. A common and proper practice of design for this type of layout is to let the content define the space occupied by the grid, and not vice versa. In this case, “content” does not refer solely to the text; it also refers to everything that has value within an interface, including images, video, text, ads, links, and more. Rather than trying to hammer a variety of content sizes and types into a predetermined grid, you should design your grid around the size and nature of your content. Within your customized grid structure, the layout is divided with vertical and/or horizontal guidelines that provide a consistent organization of space. Once you define the margins and the spacing for columns, your grid will become a clear, logical, and useful organizational schema for your multifaceted mobile content.

Online Tools

Web design frameworks built upon HTML and CSS had become quite popular before newer, more robust frameworks popularized the use of grid-based layouts. The Internet is full of useful models and frameworks with CSS rules that help designers to create a simple, fast, and efficient grid layout for almost any purpose. Some layouts are flexible, others are quite rigid (after all, they are designed to constrain content). Some of them have between three and five columns maximum, while others have between 12 and 16 columns. I bring up the variety of grid frameworks to emphasize that they’re not all the same, and further, there are grids that are inherently better than others. However, to fully understand the benefits of a grid-based approach, you should consider a unique pattern and purpose for each project you have to develop. You should not be afraid to try a variety; remember, simplicity is often the winning design.

On the web, there are many useful grid resources to help you build a properly-proportioned layout or interface for your projects.

Grid System 960: A tool that lets you create websites using a grid of 960 pixels. This number was chosen because it allows easy division into a variety of columns and rows.
Gridr Buildrrr: A tool that offers precise control over borders, margins, and box contents for custom projects.
Design by Grid: A magazine that publishes articles and tutorials on the creation of grid-based designs.

A Grid Layout Markup

If you’d like to try to develop a grid structure with your own hand-written code instead, determine an interface width and the size of the spacing between the various columns. Remember that in order to obtain a balanced effect, it’s important that the various horizontal spacings are of equal size. As discussed before, study your content first, think about how it should be positioned and arranged, and keep these ideas in practice throughout your grid development process.

Add the main elements of your app or mobile website (header, main content, sidebar, and footer) in a wrapper, like this:


  Header
  Content
  Sidebar
  Footer

At this point, your content and your sidebar will be divided into sections, all of which will be assigned a class named Grid1, Grid2, Grid3, and so on (it depends on the number of grids that you’ve decided to build). Within each grid cell, there can be as many subsections as you would like to include.


  Subsection 1
  Subsection 2
  Subsection 3

As for the CSS, almost everything is based on the proper application of the float CSS property. For the correct positioning of the most prominent area of your grid design (that is, the grid’s main containers, which in turn contain subsections) you employ the so-called “opposite float” technique. For the grids and the horizontal spacings between them, you have to first create several self-contained sections of columns, and secondly, you have to assign each a float and a fixed width. I’ve applied this technique using the following CSS:

div.grid1
{
  float: left;
  width: 290px;
}

Afterward, you’ll apply the same float rule within the sections in multiple columns, giving a specific size to the width and to the right margin (10 pixels in this case) to separate them, like this:

div.grid2 div
{
  float: left;
  width: 250px;
  margin-right: 10px;
}

To add an additional level of modularity, enabling a section to occupy the space of two or more columns, let’s use so-called joint columns: you simply need to assign to an element a class of type ext2, ext3, ext4, or ext5 to have a section that occupies 2, 3, 4, or 5 columns instead of having a unitary width.

Conclusion

This article was intended to point out another possible technique for the design and development of a responsive layout or interface. If there’s one principle to remember about grids, it’s this: Don’t try to cram your content into an ill-fitting grid. If popular solutions don’t suit your needs, design your own grid tailored perfectly for your content. It can be done quickly and easily using a few columns, rows, and CSS declarations.

Want to learn more about Responsive Web Design? Check out SitePoint’s new book, Jump Start Responsive Web Design!

Build a Currency Converter with jQuery Mobile and Cordova: Constructing The Interface

Aurelio De Rosa — Sun, 10 Feb 2013 23:26:37 +0000

In the introductory article of this series, I showed the requirements of the soon-to-be-built “Currency Converter” app and the technologies involved. I also built out a file structure and outlined each component of the app and its purpose. In this article, we’ll delve deeper into the layout and functionality of our app, and I’ll show you the source of both the two HTML pages and the CSS file that govern our app’s interface.

The Homepage

By default, the interface loads the pages differently from the first initial page load using AJAX; That’s why we have to include all the JavaScript and CSS files. As I pointed out in the first article, the app we’re developing is very simple; the entry point is index.html, and it’s also the only page that the user will really interact with. It contains the form the user will use to convert money from one currency to another. The form will have the field to write the monetery amount, the currency to convert from, and the currency to convert into.

I’ll use the new HTML5 tags where possible, and the amount field is ideal to use the new . Apart from the new input type, I’ll take advantage of the min by setting it to zero, because we won’t be converting negative amounts of currency. I’ll also use the attribute pattern and set it with the value range [0-9]* . As a result, when the user puts “focus” on this field (by touching it), the numbers keyboard will be shown instead of the alphabetical one. You can see this specific part of code that creates this streamlined functionality below:

The remaining two fields are implemented using the classic



Now, you’re probably wondering why I added two additional containers. The reason is that since an  field is wrapped with other elements by jQuery Mobile to add aesthetic enhancements (which take up space), so if the buttons take up 50% of the width each, the added width from the styling forces the buttons onto different lines, as you can see in the following screenshot.
Now that you know all the main elements of the page, it’s time to show you the page’s whole code.


  
    
    
    Currency converter
    
    
    
    
    
    
    
    
    
    
    
    
  
  
    
      
        Currency converter
        Update data
      
      
        
          Currency Converter is a simple app that helps you convert from a currency to another. You can
          update the exchange rates every time you want so you'll have always an up-to-date conversion.
        
        Last update rates:
        
        
          Convert
          
            Value:
            
          
          
            From Currency:
            
          
          
            To Currency:
            
          
          Result
          0
          
            
              
            
            
              
            
          
        
      
      
        Created by Aurelio De Rosa
        Credits
      
    
  

In addition to what I’ve already outlined for the header and the footer, I’ve used the new HTML5 
 and  tags instead of generic  tags. Each of those two elements has a link inside: the header’s link will execute the currencies rate update, while the footer’s will simply take the user to the credits page (aurelio.html), which is nothing special but a spam page about…well, me.
Additionally, the link inside the 
, as well as the one inside the , uses the attribute data-iconpos="notext". This tells to jQuery Mobile to hide the link’s text, because on small screens it could require too space. However, as you can see at line 19, I attached a handler, called updateIcons(), to the pagebeforecreate and the orientationchange events. This function will programmatically test the screen’s width, and if a larger enough screen is found, the attribute will be removed and the element’s text will be displayed.
The last thing you should know about this page is the use of a handler, initApplication(), for the deviceready event, which is fired when Cordova is fully loaded. It’s the function that will set up the application, but its functionality will be illustrated in the next parts of this article series.
The Credits Page
Although the page aurelio.html is very simple, there are a couple of facts worth mentioning. The first is the use of two new HTML5 tags: 
, and . Of course, explaining HTML5 is beyond the scope of this series, so I’ll give you a very brief summary. The  element represents a unit of content, optionally with a caption, that is self-contained. The caption described is provided using the element . Regarding the  element, it represents a component of a page that consists of a self-contained composition in a document, page, application, or site. The second fact to highlight is the use of the attribute target="_blank" applied to all the links of the contact listings on the page. It will be used to attach a handler to all those links; the how and the why will be explained in the next article of this series.
The full source of the credits page is below.


  
    
    
    Aurelio De Rosa
  
  
    
      
        Back
        Aurelio De Rosa
      
      
        
          
            
            Aurelio De Rosa
          
          
            
              I'm an Italian web and app developer who have a bachelor degree in Computer Science and more than
              5 years' experience programming for the web using HTML5, CSS3, JavaScript, and PHP. I mainly use the
              LAMP stack and frameworks like jQuery, jQuery Mobile, Cordova (PhoneGap), and Zend Framework.
              My interests also include web security, web accessibility, SEO, and WordPress.
            
            
              Currently I'm self-employed working with the cited technologies, and I'm also a regular contributor to the
              SitePoint network, where I write articles about the topics I usually work with and more. The articles can
              be found on the following websites of the network:
              BuildMobile.com,
              PHPMaster.com,
              JSPro.com and
              SitePoint.com.
            
          
          
            Contacts
            
              
                
                  
                  Visit my website: www.audero.it
                
              
              
                
                  
                  Drop me an email: aurelioderosa@gmail.com
                
              
              
                
                  
                  Drop me an email (alternative address): a.derosa@audero.it
                
              
              
                
                  
                  Follow me on Twitter (@AurelioDeRosa)
                
              
              
                
                  
                  View my profile on LinkedIn
                
              
              
                
                  
                  Visit my repository on BitBucket (AurelioDeRosa)
                
              
            
          
        
      
    
  

Style Tuning
By default, jQuery Mobile will truncate long titles inside the 
 and the , adding an ellipsis at the end of the truncated text. However, this method also applies to other kind of elements like buttons. I don’t like this behavior very much, so in the very short stylesheet, called style.css, which I mentioned in the previous article, I changed it by applying the rule white-space: normal !important;. Apart from that, I just centered my photo in the credits page and applied some styles to the result of the calculation.
The source of the stylesheet is the following:
.ui-header .ui-title,
.ui-footer .ui-title,
.ui-btn-inner *
{
   white-space: normal !important;
}
.photo
{
   text-align: center;
}
#result-title
{
   margin-bottom: 0.2em
}
#result
{
   display: block;
   font-size: 1.5em;
   text-align: center;
}
Conclusion
In this second part of the series, I described the two essential HTML pages and outlined the key points of each. Although the app is very small, the markup is semantic and rich thanks to the use of several new HTML5 tags and attributes. Apart from these elements, the most important feature is probably the jQuery Mobile layout grid system that allows you to create responsive and equally-spaced multi-column layouts. Due to the fact that the business logic isn’t yet complete, the files aren’t very useful at the moment. Additionally, if you try to wrap them using Cordova, as soon as you visit one of the external links in aurelio.html, and then go back using the back button, you’ll see that the credit page will lose the framework’s style enhancements, as well as any custom styles applied. This issue will be discussed in the next articles of the series, where I’ll show you the solution to these problems, and I’ll also describe some of the JavaScript files that power the “Currency Converter” app.
  


Build a Currency Converter with jQuery Mobile and Cordova: Introduction
Aurelio De Rosa — Fri, 08 Feb 2013 00:02:14 +0000
Earlier this year, I ran a series of articles on how to Build a Location-Based Mobile App With HTML5 and Javascript. If you enjoyed that series, you can follow this new series, which will teach you how to build a currency converter with some of the technologies that you may already have in your mobile development arsenal. Like the previous project, this will be a hybrid application built with HTML, CSS, and JavaScript with the support of several frameworks like jQuery, jQuery Mobile, and Cordova (also known as PhoneGap). In a very imaginative moment of inspiration, I gave this app the highly-creative title “Currency Converter.”
 
 For those of you that don’t have a precise understanding of what a hybrid app is, it is built using web technologies, and then wrapped in a platform-specific shell that allows the it to be installed just like a native app. For an in-depth overview on this subject and the differences between native, hybrid, and web apps, take a look at Native, Hybrid or Web Apps?.
  
The goal of this series isn’t to copy the previous one with a different kind of app. While we will cover Web Storage and the Notification API, this series will feature two new Cordova APIs: the Globalization and the InAppBrowser API. The first has been introduced in the release 2.2.0, while the second was included in the last stable version (2.3.0). For more about the 2.2.0 version, read What’s New in PhoneGap 2.2?
In this first and introductory article, I’ll explain the app features, the technologies used, and its structure.
The App Requirements
As I said, this app is very small and easy to understand. We’re developing a currency converter that allows developers to update the conversions rates as needed based on the European Central Bank (ECB) currency RSS feed. One of the most important feature is that, once retrieved, the currency conversion rates are saved using the Web Storage API, so the user can use the application offline. Additionally, as soon as the user launches “Currency Converter,” the app will check for an Internet connection, and if one is unavailable, the app will search for previously-stored rates.
Being based on the ECB feed, I want to emphasize that it’ll support only the currencies provided by the feed and nothing else. To enhance the user experience, the app will save the last currency used for a conversion, so at the next start of the application, the user will find their last-used currency. In addition, the date and time of the last update will be stored too, so that the user knows how recent (or old) his conversion rates are.
By default, the text will be shown in English, but it will be developed to support others languages (which is obviously important when developing an international currency app). If the mobile device uses a language supported by “Currency Converter,” the app will be automatically translated as soon as the app initializes. Apart from English, the final repository will also support Italian, French, and Spanish. I’m sorry but I’m unable to translate into other languages. However, once I’ll publish the repository, you’ll be free to contribute additional translations using other languages.
The Technologies Involved
In the introduction, I described which technologies will be used to create the code, however the following list will give you a more detailed understanding of what we’ll be utilizing:
HTML5: Used to create the markup of the pages.
CSS: Most of the CSS enhancements will be done by jQuery Mobile, so I’ll use just few lines of custom CSS code.
JavaScript: This is the language used to write the business logic, so this is really a must-have skill to understand this series.
jQuery: It’ll be used mainly to select elements and attach event handlers.
jQuery Mobile: This framework is used to automatically enhance the application interface.
Cordova (PhoneGap): Cordova will be used to wrap the files, so you can compile them and install the result just like a native app.
Since version 1.3.0 of jQuery Mobile isn’t yet stable (at the time of writing, however, it’s in “release candidate” status), I’ll use the version 1.2.0. If you need a reminder of the differences between these versions, I described them at length in the articles What’s New in jQuery Mobile 1.2.0? and Build Lists and Popups in Minutes Using jQuery Mobile. The Cordova version used will be version 2.3.0 to use the following new APIs:
Globalization API: It provides an object to obtain information and perform operations specific to the user’s locale and timezone. For example, it provides the getPreferredLanguage() method to get the string identifier for the client’s current language and the numberToString() method that returns a number formatted as a string according to the client’s user preferences. More on this API in the Globalization official doc.
InAppBrowser API: It’s a web-browser that is shown in your app when you use the window.open call. You can find more information on this API by reading the InAppBrowser official doc.
Web Storage API: This provides access to the devices storage options. If you want an in-depth explanation, read An Overview of the Web Storage API.
Just like the previous series, “Currency Converter” will be developed with the assumption that the compilation will be done using the Adobe cloud service, called Adobe PhoneGap Build. It will be the service itself that includes the correct Cordova library for each platform at compiling time. To discover the reasoning behind using this technology, take a look at the discussion provided in the first part of the series. The link to the final, completed source code will be given in the final part of the series and hosted on BitBucket repository.
The Project’s Structure
To start the project, create a folder and rename it “currency-converter”. Now. create three sub-folders within this main folder: css, images, and js. Now download the jQuery (I’ll use version 1.8.3) and jQuery Mobile libraries. Put the jQuery and the JavaScript file of jQuery Mobile inside of the “js” folder, and then place the jQuery Mobile CSS file inside of the “css” folder. Finally, put the jQuery Mobile bundled images into the “images” folder.
In the root of the project folder I’ll create the HTML files, the Adobe PhoneGap Build configuration file, the default splash screen, and the application’s icon. Apart from the files we already put in place, we’ll write the following:
index.html: This is the entry point of “Currency Converter” and the only page that the user will interact with. Being the entry point, I’ll put links to the libraries used inside the  section of the index.html file. It will have the button to update the conversion rates, as well as the button to access the credits page.
aurelio.html: This is the credits page, so nothing special here.
style.css: The file containing the few custom lines of CSS used by the app.
jquery.mobile.config.js: It’ll contain the custom configuration of the jQuery Mobile framework.
currency.js: This file represents a currency object and will have the methods to retrieve, save, and load the currencies using the Web Storage API. In addition, it will have a compare method that will be used for sorting.
functions.js: This will contain the function to initialize the project, translate the index.html page, update the conversion rates, and some other utility functions that I’ll explain further in the next articles in the series.
settings.js: This file will be used to save and load the app settings mentioned before, including the last currencies used and the time of the last currency conversion rate update.
translation.js: This will contain the object having the strings to translate the index.html page.
config.xml: This XML file will have the metadata of the applications and will be used by the Adobe cloud service to store settings like the app version number and the package contents.
Apart from this list, “Currency Converter” will have some additional images stored within the “images” folder, as well as one of the plugins I developed called Audero Text Changer. It’s a very lightweight jQuery Mobile plugin that allows you to easily change the text of elements on your pages without breaking the enhancements made by the framework. So, as you might guess, I’ll use this plugin to translate the application into various spoken languages. If you need more information about this plugin, I wrote about it in Customize Your jQuery Mobile Interface with Specialized Plugins.
Conclusion
In this first part, I illustrated the features and the structure of “Currency Converter.” I also showed you the technologies that will be involved for its implementation. Now that you know what you need to follow the rest of the series, take the time to study the technologies, so that you’ll be ready for the next part of the series, where I’ll dive into the code and describe how to create the HTML pages.
  


Responsive Web Design: Fluid Layouts
Annarita Tranfici — Tue, 29 Jan 2013 01:55:56 +0000
After focusing on general concepts and how to use fonts responsively in the first two articles of the responsive web design series, let’s delve into fluid layouts. In this third part of the series, I’ll demonstrate when fluid layouts are really needed, as well as when you could opt for a different solution that isn’t necessarily responsive. Let’s look at a few specific techniques and applications.
To understand whether or not a flexible layout is the right choice for your project, you have know, understand, and consider the other solutions available. In fact, only by evaluating the strengths and weaknesses of each method will you have the opportunity to validate your layout choice.
There are four different layout types: fixed-width layouts, liquid (or fluid) layouts, elastic layouts, and hybrid layouts. Let’s analyze them one by one.
Fixed-Width Layouts
In fixed-width layouts, the width of the site is bound to a certain number of pixels. Generally, the measure chosen is 960 pixels. This is because with the passing of time, developers have found 960 pixels to be the best size for grid layouts, because the number is easily divisible by 3, 4, 5, 6, 8, 10, 12 and 15.
  
Even today, fixed-width layouts are among the most commonly used in the web, most likely because the rigidity of the layout provides a sense of stability and control. If you know the width of your site across all browsers and devices, you can create graphics with precise, complete control over the result.
However, the fixed-width layouts have some disadvantages. As I have said in the previous articles, designers who want to create a fixed-width website have to keep in mind that every aspect of their work has to be usable and clearly visible to a large number of screens, browsers, and devices. The wide variety of devices on the market at this time, as well as the consequently great variability of screen sizes makes creating one-size-fits-all content quite a challenging task, and arguably a challenge that outweighs the precision and control of fixed-width design.
A common example of fixed-width websites gone wrong involves screens smaller than 960 pixels, which are surprisingly common. The site will not be fully displayed, and you’ll see a very awkward (and unattractive) horizontal scrollbar. The fact that these small screens are usually operated with fingertips instead of cursors only compounds the width woes.
Problems occur also in the opposite situation, when the screen size is greater than 960 pixels. In these cases, the website layout is surrounded by a large amount of white space and, obviously, this would certainly not be the solution that a good web designer aspires to see. Designers and users would rather make the most of the generous width of larger screens.
Liquid Layouts
The first basic difference between the fixed-width type of layout we’ve just analyzed and liquid layouts is the measurements of their size. The fixed-width layouts are measured in pixels, but for liquid or fluid layouts, dimensions are defined in percentages, and as you might expect, this affords greater malleability and fluidity. In other words, by setting a percentage, you won’t have to think about device size or screen width, and consequently, you can find a reasonable solution for each case because your design’s size will adapt to the size of the device used.
Liquid layouts are closely linked to media queries and special styles for optimization. Percentage-based widths alone will likely not be enough to accommodate your design for a large variety of display sizes. We will see later how to get a perfect result from liquid layouts.
Elastic Layouts
Elastic layouts are somewhat similar to liquid layouts. The main difference is once again the unit of measurement for size. The size indicator for elastic layouts is neither in pixels nor percentages; it’s measured in ems.
An em is the equivalent of the size (in pixels) defined in the font-size CSS rule. For example, if we style our text with a font-size of 20 pixels, 1 em would be equal to 20 pixels, 2 ems would correspond to 40, and so on.
This type of layout gives the developer strong typographic control. Since the vast majority of layouts are predominantly populated with text, the precision of type treatments makes elastic layouts a strong contender for many projects. However, even with this type of solution, there is a risk of an unpleasant and unaesthetic horizontal scroll bar in some rare cases.
Hybrid Layouts
Finally, as the term suggests, there are hybrid layouts, which combine the characteristics of two or more of the layouts discussed above. For example, the designer might decide to assign a fixed size (in pixels) to certain elements of the page (a sidebar or a footer) while for the remaining (for example the that contains the main content) choosing a variable width (in percentages or ems).
Obviously, this approach has its own set of limitations and disadvantages—if you assign a sidebar a fixed width of 200 pixels and set a value of 80% for the rest of the content, you might find a horizontal scrollbar on screens smaller than 1000 pixels, since the main column does not have the space necessary to expand itself. In lesser cases, you’ll just have an elements that are unusually large or unusually small for their intended purposes. But you can easily address all of these issues, as we’ll see later.
Conclusion
At this point, you may be wondering what the best solution is for your specific projects, and which of the four types of layouts listed above is best suited for the responsive approach. As you might guess, each layout type has its advantages and disadvantages. It all depends on the needs you want to fulfill and the characteristics of your personal project.
It would be easy to make a knee-jerk, reactionary declaration that one of these layout options is universally superior to the others, but they shouldn’t be considered mutually-exclusive options or competitors. Rather, they should be considered techniques that can be used in conjunction. Many of these techniques aren’t possible without the others. For example, ems are meaningless without a fixed declaration of font-size. Similarly, media queries will be ineffective without inferring precise widths and making accommodations for popular screen sizes.
We’ll get into some real-world applications of all of these techniques in the next article in the series.
Want to learn more about Responsive Web Design? Check out SitePoint’s new book, Jump Start Responsive Web Design!