SitePoint » Mobile Web Discussion

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 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.

Understanding Responsive Web Design: Responsive Imagery

Annarita Tranfici — Wed, 27 Feb 2013 17:34:32 +0000

In this fifth part of our Understanding Responsive Web Design series, I’ll show you one of the typical problems that a web designer faces when building a responsive website: the management of the images. As you’ve seen so far, the challenges that a mobile designer faces are numerous, and it’s not so strange or unusual to think that one of the biggest is serving multiple image formats to multiple screen sizes. There are currently three strategies that a developer can choose when it comes to responsive imagery: he can choose between: “fighting” the browser, “resigning” himself, or relying on the server. Let’s try to understand the advantages and downsides of each option.

Fighting the Browser

Most front-end developers choose to apply the first strategy and fight the browser. What does “fighting the browser” stand for? It means doing your best to give the “right” image (that is, the image that has the correct size for the device used to view the website) to the browser so that it can be loaded before the browser had downloaded the “wrong” one (that is, the “default” or the desktop version of the image). This is an increasingly difficult task, as modern browsers and ever-quickening bandwidth means that users try to download images as quickly as possible.

Resigning

Sometimes the simplest and most comfortable strategy is the only viable option: admit defeat. Generally, this approach involves loading the default image onto small screens, and secondly, if necessary, loading a larger image for screens with larger dimensions. While this method is easy and straightforward, it’s not recommended, because in the second case, two requests are sent to the browser when only one is necessary.

Relying on the Server

The third strategy involves the use of the server, a server-side programming language and some basic forms of detection to determine which image to load. All of the logic is executed before the browser is able to see and interpret the HTML code. Unfortunately, this strategy has its own flaws: the act of maintaining an ever-growing list of mobile devices and screen sizes would become very complicated and require constant upkeep.

To help you understand better what this technique does and how it can be used, let’s consider an example. In the following example, I’ll show you a few lines of PHP, but don’t worry, you don’t have to me a PHP expert to create responsive images, and you’ll understand the example even if you haven’t worked with PHP before. Let’s assume that you’re creating a page dynamically and that you’re injecting an tag using the following line of code:

echo '';

As you might already know, mobile connections aren’t nearly as fast as their desktop counterparts. So, to speed up the rendering of your page for mobile devices, you’d like to inject a lightweight version of the image if the user is using… perhaps an iPhone. What you can do server-side is check the user-agent that made the request and—if the device was an iPhone—inject the smaller image. The next snippet demonstrates this technique:

if (strpos($_SERVER['HTTP_USER_AGENT'], 'iPhone') === false) {
  // Not an iPhone
  echo ';
}
else {
  // An iPhone
  echo ';
}

As you can see, the method is very easy to implement, however this approach isn’t very reliable because the user-agent information itself isn’t 100% reliable. If the method fails, you could have some glaring problems with your imagery.

Is One Method Better Than The Others?

Obviously, each approach has its own unique advantages and limitations, and it’s unlikely that one single method will be the ideal choice for all of your mobile projects. However, there are some additional techniques and resources that a developer may use to create responsive images.

Sencha.io Src

The first option is very fast and simple. It is a service developed by James Pearce that returns the image you choose to load resized to fit your exact needs. Its name is Sencha.io Src, and all you have to do is put the Sencha.io Src URL location of your image as the image’s source.

The service uses the user agent string of the requesting device to determine the desired image size and resize the image accordingly. By default, the image is scaled to 100% of the width of the screen. Sencha.io Src has a high level of customization; it’s possible to set a specific width or any other parameter. For example, if you want to set the image width to 250 pixels, you have simply to add the size into the URL as follows:

The service also caches the request, so the image will not be reloaded each time the page is loaded.

Adaptive Images

A similar solution is proposed by Matt Wilcox. It involves determining the size of the screen first, and then creating (and caching) a scaled version of the correct image dimensions. This is an ideal technique to make the images of an existing website responsive. After downloading the code (which you can find at adaptive-images.com), to make this solution operational and running properly, you need to follow three simple steps:

Add two files, .htaccess and adaptive-images.php, to the root folder;
Create a cache folder and allow write permission;
Add the following line of Javascript code at the beginning of your document:

Thanks to this one line of code, the screen resolution is captured and stored in a browser cookie. It’s possible to configure multiple options in the file adaptive-images.php, but the primary purpose of the file is setting the variables for the resolutions ($resolutions).

$resolutions = array (800, 480, 320);

These resolutions are the “breakpoints” of images based on the screen resolution (a width to be measured in pixels). In this case, This tool will serve out a small, mobile-friendly image for devices with a pixel width of 320 or smaller. If the display exceeds 320 pixels, the new reference value is 480, which is the next numerical value in the array above.

Once created, the images will be stored in the cache folder (where you can change the filename), so that you will no longer need to generate them.

In addition to what I showed, I want to highlight that the key point of the discussion on adaptive images concerns their size. This is certainly an important factor, but we often forget that it is not the only one. For example, resizing an image for smaller displays often reduces the impact and the recognition of the image. In these cases, it may be necessary to modify the image. Even a simple cropping of the edges or of the superfluous elements can help the image retain it’s impact and significance at a smaller size.

Conclusion

In this article I described three ways to work with with images from a responsive design point of view. The first is fighting the browser—that is, doing your best to give to the browser the “right” image to download. The second is choosing services like Sencha.io which use the user agent string of the device from which the request is sent to understand screen size and resize the image accordingly. The last involves to adaptive images—in this case, the developer only needs to determine the size of the screen and the image will scale to accommodate.

In conclusion, between the three approaches discussed above, the one of the adaptive images is probably the best solution as it requires no dependency to another site or link. In the next articles in the series, we’ll examine other methods that a developer can use to manage all the images of a responsive website.

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

5 Essential Elements of a Successful Business App

Kyle Sanders — Mon, 25 Feb 2013 18:10:57 +0000

The ever-growing population of smartphone owners has led more and more companies to develop mobile business apps to cater to customers and generate leads. What used to be an optional “nice to have” mobile component is now becoming an essential part of any business, regardless of industry. But, to build a great mobile presence for your business, you need a lot more than just the realization that you need an app or the decision to build it. Many poorly-conceived small business mobile apps end up as nothing more than an expensive novelty.

If you don’t take time to develop a fully-functional, properly-planned app that offers real value to users, all of your efforts will go wasted. We’ve learned some important lessons through creating countless mobile apps for small businesses; here are the five essential elements that play pivotal roles in the building of successful business apps.

A Professional Developer

The first thing your mobile app needs is a professional developer. It’s tempting to view mobile development as a commodity—it’s not. Seeking the lowest price for your development (and ending up with the lowest quality) can result in major headaches, glaring software glitches, and brand damage. You should never try to cut corners and costs by hiring someone with little experience in mobile application development. Professional, seasoned developers know the ins and outs of mobile operating systems, version control, optimization, best practices, and the latest web technologies. With a veteran (or veterans) working on your project, you’ll be assured a mobile app that’s a strong benefit to your business instead of a frustrating hindrance.

An Adequate Budget

You can’t start the development process without an adequate development budget; having a half-built app and no funding to finish is arguably worse than having never started. You’d be amazed at just how complicated it can be for a developer to breathe life into what initially seemed like a simple design. The process often involves a designer, a project manager, and input from executives, marketers, and salesman. You have consider all of the moving parts of your design and how much it will cost to incorporate all of the multifaceted needs of each stakeholder. If your budget is not enough to cover these development costs, you might not be able to make your app as functional as you wanted it to be, and both customers and stakeholders could end up disappointed.

Original Content That Will Keep Your Customers Coming Back

You are not going to have thousands of customers lining up to download your app—even if it’s free—unless you have something truly valuable to offer. Many businesses expect a lot of exposure from their app without a real investment into the app’s content. Others make a substantial commitment of content upfront, but then consider the app a completed project instead of an ongoing project. Neither is a good long-term strategy for maintaining and leveraging a mobile app to benefit your business. You’ll want a steady stream of special offers, updates, or other reasons to revisit your business app.

A good litmus test of your app’s appeal is to simply play the role of the prospective user. Ask yourself why you’d notice the app, why you’d want or need it, and what would cause you to keep it on your mobile device’s small screen and limited storage. If you struggle with the answers, you may want to remedy the problem with original, valuable, regular content updates.

Careful Branding to Grab Your User’s Attention

You will need to find ways to grab your user’s attention the first time they load your business application. Clever loading screens and new user tutorials are a great way to do this, but you need to make sure you do not go overboard with your introduction efforts. Mobile users are inherently busy multitaskers; you never want to keep them from their purpose without good reason. You are not dealing with a captive audience; Users can leave your app or turn off their phone at a moment’s notice. You’ve already won the competition for their attention and gotten your app installed on their device; offer them some carefully-designed welcome messaging that’s just as easy to use as it is to bypass.

Loading Indicators that Keep Your Users in the Loop

There is nothing more frustrating than trying to navigate through an application just to be directed to a blank, unresponsive screen. One of the first thing your users will think if you do not have loading indicators is that the application is frozen or malfunctioning. Loading indicators and animations let your users know that the app is fully-functional, working, and waiting on your phone’s network or hardware to respond. A process indicator might be even more useful, because it tells the user how much of the process has been completed and the specific steps involved. This may sound like a small, inconsequential addition to an app, but in the minds of many users, it’s the difference between a buggy, crash-prone app and a snappy, responsive, user-friendly one.

Conclusion

“We need a mobile app” is just the beginning of your planning process. You need to take time to think about what you want your users to accomplish and how you design to suit their needs. Do not cut corners during your design, development, funding, or testing—your shortcuts will likely be noticed in a very public way. But, if you test your app thoroughly, design it thoughtfully, and keep the essentials in mind, it will be a valuable asset worthy of your time, investment, and brand.

Do you have any essentials to add to the list? Have you worked on mobile projects that lack thorough planning? Do you have any hard-earned development lessons to share?

What to Expect From jQuery Mobile 1.3.0

Aurelio De Rosa — Fri, 25 Jan 2013 18:38:22 +0000

I wrote an article titled What’s New in jQuery Mobile 1.2.0? that showed the new features and the changes made by the jQuery Mobile team in version 1.2.0 of their popular mobile development framework. Several days ago, the team announced the beta version of the 1.3.0 release. Lucky for us, it focuses on responsive web design, specifically two different responsive table modes, panels, and dual-handle range sliders. In this article, I’ll show you an overview of some of these new features.

Tables

In the 1.3.0 version of jQuery Mobile, there are two important additions: reflow table and column toggle table mode. Let’s have a closer look at both.

Reflow Table Mode

Let’s suppose that you have a table with many columns, and that you’re looking to display that data sensibly on a small screen. With basic responsive design techniques, you’d reduce the font and cause the data table to be difficult due to the very small font size. With this mode, the table is instead divided into chunks where each row becomes a new table and the columns are turned into rows. So, the new small tables will have as many rows as the previous column count, and it will display just two columns: one for the data labels (which were the old column headers), and one for the values.

To apply the reflow mode, all you need to do is to add the data-role="table" attribute to the

tag, since the data-mode="reflow" attribute is the default behavior. To see the reflow mode in action, take a look at this example on the jQuery Mobile website.

Column Toggle Table Mode

This mode has a different approach compared to reflow table mode. In fact, this time you have the chance to hide one or more columns based on your needs, thanks to a button injected at the top of the table. Of course, this is not the entire solution, because if all the columns are shown, you’ll have the same limited width problem discussed before. To solve this issue, you can program a set of columns to hide themselves if a certain width threshold is reached. This is accomplished by using CSS media queries that manage columns based on the priority level. You can specify the columns that can be hidden or shown applying a data-priority attribute, having values from 1 (highest) to 6 (lowest), to the table’s header (

). If you don’t specify a priority, the column is persistent so it’s not available for hiding. This means that it’ll be visible at all the widths and won’t be available in the column chooser menu. Apart from specifying the columns’ priority attributes, you have to add the data-role="table" and the data-mode="columntoggle" attributes to the

 tag.
To see the column toggle table mode in action, take a look at this example on the jQuery Mobile framework website.
Panels
If you’ve ever seen the Google+ app on Android, you may have noticed the nice panel that is shown once you click on the Google icon at the top-left of the screen. From this release onward, you can easily implement a panel like that for your website or application (using Cordova, as you might have learned in Build a Location-Based Mobile App With HTML5 and Javascript). This new widget gives you a lot of options: you can position it on the left (the default) or the right of your page, and you also have up to three ways to show it. The default method is “reveal,” but you also have the “push” and the “overlay” animations at your disposal. The panel can be closed by swiping, tapping onto the page, or hitting the Esc key on the keyboard. To create a panel you simply add the data-role="panel" attribute to the container (usually a 
) that you want to transform into a panel.
Typically, your code will look like the following:

  
    Your title
  
  
    Open the panel: Panel
  
  
    Copyright Aurelio De Rosa
  
  
      The content of the panel
  

A demo of the panel widget can be seen looking at this page.
Range Slider
The new range slider is a very nice feature in JQM version 1.3.0. It allows you to create a slider that has two handles that you can move to fit the range for a given property. It’s very useful. For example, if you have a reservations’ website and you want to enable your users to select the price range to filter the results of a search, they can specify this exact range using the range slider. To have this widget, you just apply the data-role="rangeslider" attribute to the container, usually a 
, consisting of two  elements.
An example of code that create a range slider is the following.

  Slider 1:
  
  Slider 2:
  

In case you want to see a live demo, look at this page.
Auto-Complete Listview
The listviews have been enhanced with a shiny new feature: auto-complete. The basic version uses local data. To have the auto-complete function, you simply add the data-filter-reveal="true" attribute to your list. It will hide the list items when the search field is empty, and while the user writes, the matching elements are shown. However, the jQuery Mobile team warns against the use of this feature on large sets of data. Besides, if you want to use a remote source, you can use the listviewbeforefilter event to dynamically populate the listview as the user types.
To have an idea of how this feature works, watch the demo illustrated in this page.
Some Minor Changes
Dialog Close Button Option
From now on, if the dialog has a header, jQuery Mobile will automatically add a “close” button at the left side of the header. If you want to place it in a more Windows-style position (on the right), you can add the data-close-btn="right" to the dialog container. In case you don’t want the close button at all, you can add the data-close-btn="none" attribute.
Popup Dismissible Option
Until the version 1.2.0, if you showed a popup, it could be hidden by clicking or tapping outside of the popup. If you didn’t like this behavior, you can now stop it by adding a data-dismissible="false" attribute to the popup container. It should be obvious that, in this case, you must provide an alternative method to dismiss the popup, or it’ll stay there and create major frustrations for your users.
New Icons
The jQuery Mobile team has added two new icons. They created an “edit” icon, represented by a pencil, that you can set by adding data-icon="edit", and a “three bar” icon, that you can set by adding data-icon="bars", which can be used with the new panel widget.
Clear Button Option
In this version of the framework, you can add the “clear” button (which is typically used for  elements) to any input type, even types like text and number. To achieve this goal, you have to add the data-clear-btn="true" attribute to the element. You can also change the display text of the “clear” button using the data-clear-btn-text="my new text" attribute.
Conclusion
I’ve shown some of the new features created by the jQuery Mobile team that you’ll see in the next release of the framework. Probably the most interesting new features are the panel widgets and the tables’ responsive mode, which will let you create better mobile interfaces and user experiences. However, keep in mind that these are not the only enhancements made, and you can study them in depth by reading the release update posted in the official website.
  


Create a Mobile Application Mockup with Codiqa
Annarita Tranfici — Thu, 20 Dec 2012 21:13:52 +0000
Before writing the actual code of web applications, every web designer or developer should create mockups or sketches of their work. On the web, there are several tools that you as a designer can use to envision and adjust your digital projects before you even start coding. Two of the most famous ones are Codiqa and Balsamiq. In this article, I’ll outline the features of Codiqa and I’ll explain you how to take advantage of its potential for saving time and developing better applications.
Planning a Project
When you start planning a new website or mobile application, the ideal first step is to define a detailed initial plan of work. Before starting to write the code, even a hand-drawn sketch of your plans could save you from making many future mistakes, and it could also lend additional clarity and depth to your ideas. It doesn’t matter if you’re planning a personal project or if you’re working on a professional basis. Although the content has obvious importance, the success of the project requires a solid development process in which you maintain a clear idea of the goals that you want to fulfill.
  
If your goal is to satisfy customer needs, you’ll have to analyze their anticipated requirements and draw up a design specification that contains sketches of the layouts, definition of the audience, and technical requirements. You’ll use this specification as guide in the next stages of the project. Each layout of a web app interface starts with a mockup, which is usually nothing more than a simple sketch of the desired outcome. This can be easily modified according to the feedback of the customer and the contributions of the design team, if you have one.
When the design becomes more stable, the mockup can evolve into a refined state and it often is named a “wireframe.” A wireframe shows a more complete version of a page layout, with the inclusion of navigation elements, search features, advertisement spaces, and other features. But, before starting a discussion about what a wireframe is and what it isn’t, let’s have a look at how to build a simple, clear mockup for your next app.
What’s Codiqa?
Codiqa is a simple interface-building tool for jQuery Mobile. It’s incredibly intuitive to use, and it’s composed of 100% HTML5 components. After prototyping your idea, you’ll obtain perfect usable code. In fact, there is no need to code again later. The strength of this application lies in its drag-and-drop interface, which allows for easy and fast mobile prototype building. You can access your project anywhere from the cloud, and moreover, the share function lets you share it with team members or other developers for live testing and feedback. The only “flaw” Codiqa has is that it is not a completely free tool. In fact, after a 30 days trial, if you want to continue using this tool, you’ll have to subscribe a plan. There are four plans from which you can choose: Personal, Starter, Pro, and Team, all of which are are described in detail on the Codiqa website.
How Codiqa Works
Now that you know more about Codiqa, it’s time to delve deep with its features. Please note that the 30 days free trial version restricts you to opening and working on only one project, and you can’t share your work with other users.
The first task is to define the size of the device for which you want to create a mockup. You can choose between iPhone (3,4,4S,5) , iPad (1/2/3), tablets 600 x 1024 pixel dimensions, and phones that range from 240 x 320 pixels to 800 x 1280. As a next step, let’s work on the style of the main page, called “Home” by default (you can change the title as you prefer). You can choose a theme between the five available, upload a background-image (also selecting the repetition on X and Y axes), and program your content padding in pixels or percentages.
Let’s see what else we can add to our new homepage. If you click on the element called “Components” next to “Pages” on the left side of the page, you’ll find that you can add numerous elements, many of which are common and quite useful. At this point, let’s think about the elements that we might want to add: a header, a footer, a menu-list, a text box for some content, a little image, and some links. With Codiqa’s simple, intuitive drag-and-drop system, you can easily add everything you desire with a few clicks. After adding the elements we wanted, our mockup now looks something like this:
Now we start to customize all the components one by one using the menu on the right of the device screen. The header and footer can be chosen among the five available, and you can decide if you want these elements to be fixed or not. Clicking in the space where the titles are, you can easily change its text and size.
In the “Select Menu” box, which appears when you click on the corresponding space, you can set the name, the title you want to be shown, the theme, the size (choosing between the “normal” and “mini” options), and the items that will be offered within your menu. To add a new item on the menu, you have simply to click on “New Option,” the green button at the bottom of the box. You’ll find a typical text editor where you’ll be able to specify the characteristics and content of the paragraph.
Regarding images we’ve added an example image below the content box. Its size can be specified in pixels or percentages. Finally, in the link menu, you can build hyperlinks and specify all of the usual attributes for linking. For functionality, you can choose between fade, pop, flip, turn, flow, slide fade, slide, slide up, and slide down. Remember that at any time you can rotate your device to verify that your design choices work well in landscape mode.
At this point, let’s create another page to learn a little more about other components that are at our disposal. Below, I’ve created a page called “Contact us” where in addition to the element header, menu, and footer, I’ve added a heading, a search input, a form, and a submit button. Look below for clarity.
For this contact form, you’ll have to indicate a URL, choose between a “GET” or a “POST” method, and decide if the submission will be done with AJAX or not. The submission button can be modified by size, title, inline disposition, and in this case you can also choose an icon. There are other few elements that don’t fit perfectly into my mockup example, but they are certainly worthy of mention:
Map: like the images, its width and height can be specified in pixels. You can also determine the zoom level;
List View: you can create a list defining both the theme of the divider and the items, the link transition, the path of the links, and the titles of the buttons;
Radio Button: a radio button is an element that allows the user to choose only one of a predefined set of mutually exclusive options;
Toggle Switch: it displays checked/unchecked states as a button with a “light” indicator and by default accompanied with the text “On” or “Off”. You can choose theme, name, size, and eventually the text you want to be displayed instead of “On” and “Off”.
Conclusion
This article shows how simple and intuitive is to create a mockup for a website or web application using the tools provided by Codiqa. This kind of careful upfront planning can save you countless development hours down the road, and it’s especially helpful to show a visual, interactive mockup of your idea to your partners in a collaborative environment.
Are you disciplined about creating mockups of your applications, or do you get right into coding without wasting any time? Do you find mockups to be useful in collaborative settings? Do they help you envision the details of your project?
  


10 Years of Mobile Industry History in 10 Minutes
Dirk Reagle — Fri, 30 Nov 2012 18:03:40 +0000
Any investor will tell you that past performance is not a guarantee of future results, but as investors of time, money, and energy in mobile enterprises, it’s important to maintain a bird’s-eye, macro-level view of the industry. The market for mobile software and devices has been steadily growing at a nearly geometric pace, and it shows no signs of slowing.
Since the mid 2000′s, the industry—especially in terms of software, apps, and web interactivity—design has absolutely boomed and gone through immense advancements in every way imaginable way. This is because during the last decade (and even more so during the last five years), mobile phones have gone from being simple phones to being fully-functional pocket-sized computers, with a mobile equivalent for almost every single feature of a full-blown desktop or laptop computer.
This general trend has naturally led to the development of an enormous industry that can basically be divided into two interrelated parts: mobile app development and mobile-friendly design. Mobile development has grown alongside thousands and eventually millions of increasingly-sophisticated mobile applications developed for ever-growing smartphone marketplaces. Modern mobile applications take advantage of built-in hardware abilities in astoundingly clever ways and perform robust web-based and organizational functions.
  
With the rising advancement of high-speed, large-bandwidth mobile networks like 3G, WiFi, and 4G, consumers can access the web on their smartphones as quickly and reliably as they can via a normal computer. At the same time, the growing access has prompted an explosion in the number of mobile-friendly or purely mobile websites; this in turn has increased demand for mobile design enormously, and that’s where developers like you come in.
Today, the mobile phone market is outstripping ownership and use of landline phones in virtually every country on Earth, the steady conversion of more and more of these phones into smarter, more multimedia-friendly devices that work off WiFi, 3G, or 4G networks suggests that the future of mobile development and design will only grow stronger.
Let’s go over some of the major ingredients that led to the rise of modern mobile design.
The First Cellular Networks
Starting from simple wireless analog-based (1G) portable phones, it wasn’t until the late 1990′s that cell phones turned into more sophisticated devices as the technology inside them started to spawn an ever larger number of features (features that nonetheless seem basic by today’s standards). These first phones gave basic calling abilities to users and their convenient portable capacities are what established them as widely-used communications devices.
2G/GSM Networks and the Rise of Mobile Media
It wasn’t until the mid to late 1990′s that a new communications network, known as GSM—or 2G, as it was less often called—began to develop in which more mobile services could be offered. At this point, the first pre-smartphone devices began to appear, and the fact that data transmission over these next-generation devices was digital instead of analog allowed them to carry many of the more basic smartphone features that we use as the basis for modern app development. Capabilities such as text messaging, downloadable content, and extremely basic web access gave consumers the ability to send emails, view a small selection of online multimedia, and download simple digital applications such as ringtones and music files.
The growth of the GSM, or 2G networks, is what really expanded mobile phone use so broadly that mobile devices eventually eclipsed landline communication tools. Despite the 2G networks explosive popularity amongst users of all income levels worldwide, these machines were still pretty basic compared to today’s mobile devices.
3G Arrives
It wasn’t until the early 2000′s, with the development and service offering of the first 3G wireless digital networks that true smartphones arrived. In 2002 and 2003, network operators began to offer widespread 3G access based on more powerful wireless transmission technology that depended on efficient packet switching data transmission found in computer-based web connections instead of the 2G networks circuit switching mechanism.
With the arrival and rise of 3G, the modern era of wireless mobile smartphones as pocket-sized computers truly began, especially after 2005, when High-Speed Downlink Packet Access (HSDPA) was implemented into 3G and expanded its data carrying ability even more. The resulting explosion in online media accessibility created a tandem explosion in online media creation. At the same time, in order to take full advantage of all these web-based data options that phone networks now offered, mobile applications started appearing for smart phones—at first in small quantities but later at a rapid development pace. Also, the devices themselves had to be redesigned so that they could better display digital media and other interactive systems, taking full advantage of the growing apps market.
4G Replacing 3G
Currently, even 3G itself is being slowly replaced by the much more powerful, purely packet-switching-based, data optimized 4G network. With this new technology, ten-fold increases over 3G in data transmission ability are coming into the picture, making access to digital media even more robust and further bolstering the demand for media-rich mobile applications.
Bye Bye Buttons
This is where the touchscreen phone with its large visual screen interface comes into the picture. Today, this is the replacement to the antiquated button control and small display screen based phones of several years ago.
The end result of this mix is the rapid replacement of old phones for new touchscreen devices and the deliberate obsolescence of older networks in favor of 3G and its even more powerful successor, 4G. In many countries, anything older than 3G is no longer even available and almost all new phones being sold feature a predominantly buttonless touchscreen design.
As of the most recent figures, there were over 1.6 billion 3G/4G mobile subscribers worldwide (up from only 297 million in 2007)
Mobile Operating Systems and App Marketplaces
Finally, we come to the growth of mobile device operating systems. Since modern smartphones are more like computers than cell phones in a classical sense, they naturally needed a fully-functional OS of their own. Because of this, several companies such as Research in Motion, Apple, Google, and Microsoft all came out with their own competing mobile operating systems that gave a full-scale interface to digital media access and software applications compatibility
Thanks to all these features, the mobile apps development landscape has exploded like few other industries ever have in history. Since 2010-2011, app marketplaces have grown for mobile operating system developers such as Apple with its iOS platform, Google’s Android OS, and Microsoft’s Windows Phone.
As of 2012, the Apple mobile apps market alone houses over 600,000 smartphone apps and has had over 30 billion downloads to date. Similarly, the Android OS market gives access to hundreds of thousands of additional applications and sees some 3 million downloads per day from its online platform.
These applications are developed by both major mobile market players and, even more overwhelmingly, hundreds of smaller third-party companies and teams that sell them through the major apps markets for a majority percentage of revenues per app. This mutually-beneficial sales relationship ensures an extremely robust mobile app market that constantly sees new innovation flooding in.
Mobile Website Design
Finally, the last major branch of the mobile development landscape—with the enormous growth similar to that of mobile device development—is mobile website design. The ever-faster Internet connectivity of modern devices virtually guaranteed their use for web browsing. As of early 2012, some 61% of American users were regularly accessing the internet through their smartphones or tablets, and of those, at least 30 to 40% are almost exclusively mobile Internet users who rarely if ever bother browsing from a desktop or laptop.
Naturally, this creates an immense demand for web design that’s compatible with the much smaller and simpler screens of mobile phones and tablet devices, and this search for mobile web compatibility in online domain pages has been the latest trend in web design.
Thanks to this trend, most major site owners today have both a regular site for their URLs and a mobile-friendly version that is either automatically accessible as a special domain with its own mobile designated prefix or as a downloadable app that functions as a website. In general, these mobile versions of pages are visually stripped down versions of the full-scale original website that maintain core functionality.
Do you remember the “old days” of flip phones and low bandwidth? Did you develop or utilize primitive phone apps from years ago? What do you predict will be next for the mobile industry?
  


Build Lists and Popups in Minutes Using jQuery Mobile
Aurelio De Rosa — Tue, 27 Nov 2012 21:05:35 +0000
In my last article, I explained what’s new in jQuery Mobile 1.2.0, the latest release of the popular mobile development framework. The article describes the new devices compatibility, the popup widget, the collapsible lists, and several deprecated methods. Today, I’ll show you a complete and functional example which will be powered by the new features and widgets found within jQuery Mobile’s latest evolution.
 
Working With jQuery Mobile’s New Tools
The first feature discussed was the expanded device compatibility. Unfortunately, all that I can do to show off jQuery Mobile’s increased compatibility coverage is suggest that you to try the following example on one of those newly-supported devices (like those powered by Tizen) and see how jQuery Mobile 1.2.0 enhances the page. The next section referred the new popup widget, and how you can create a basic popup of your own. jQuery Mobile allows you to put any content that you want inside a container that floats above the current page. The popup widget has three events that are possible to catch and manage:
  
popupbeforeposition: It’s fired after the popup completed preparations for opening but before is actually opened
popupafteropen: fired after the popup is completely opened
popupafterclose: fired after the popup is completely closed
The final code will have two links that open a popup. The first link, having the ID helloPopup, shows a basic popup that has simple text, while the second doesn’t call the popup directly. The former will show an alert when each of those are triggered to better understand their execution order and the time when they’re fired. This will be done using the following code.
$("#helloPopup").on(
   "popupbeforeposition popupafteropen popupafterclose",
   function(event) {
      alert(event.type);
   }
);
The latter will programmatically open the popup which contains an image centered on the current window, as you can see below.
$("#imagePopupLink").click(function() {
   $("#imagePopup").popup("open", {positionTo: "window"});
});
jQuery Mobile List Management
The next set of improvements implemented by the jQuery team were about the lists. The first two were Listview Autodividers and Collapsible Lists, which will be merged in the example page created below. Autodividers enhance the list readability by adding alphabetical list dividers, while collapsible lists are designed to make the most of the limited screen space on mobile devices. The relevant code is shown below.

  Collapsible List with Listview Autodividers
  
    The following list is inside a collapsible element and it
    uses also the new data-autodividers attribute.
  
  
    Aurelio De Rosa
    BuildMobile.com
    JSPro.com
    PHPMaster.com
    SitePoint.com
  
The third major enhancement to jQuery Mobile 1.2.0 was the introduction of Read-only Lists. This addition is more of an aesthetic change than a functional one, so you’ve got to see the code in action to understand the difference.
And finally, the new version of jQuery Mobile brought about page loading deprecated methods and properties. In the following code, I’ve included a function that catches the mobileinit event to set the global configuration of the loading widget using the new $.mobile.loader.prototype properties.
$(document).on("mobileinit", function() {
   $.mobile.loader.prototype.options.text = "Please wait...";
   $.mobile.loader.prototype.options.textVisible = true;
   $.mobile.loader.prototype.options.theme = "e";
});
In addition, I’ll attach a function to the pageshow event that will show the widget and then hide it after 1.5 seconds using the new $.mobile.loading() method.
$(document).on("pageshow", function() {
   $.mobile.loading("show");
   setTimeout(function() { $.mobile.loading("hide"); }, 1500);
});
Lastly, I’ll create a button that, once clicked, shows the same loading widget, but this time it’ll use a local configuration. A local configuration allows you to overwrite the global configuration when you call this method to create a specific style. Just like the previous loading widget, after 1.5 seconds it will be hidden.
$("#loadingLink").click(function() {
   $.mobile.loading("show", {
      theme: "b",
      text: "Different message...",
      textVisible: true
   });
   setTimeout(function() { $.mobile.loading("hide"); }, 1500);
});
Putting it All Together
As promised, below is a jQuery code sample that encompasses all of the aforementioned new techniques afforded by the 1.2.0 version. The following example will make use of and expand the above snippets to show you the discussed features.


  
    
    Working with jQuery Mobile 1.2.0
    
    
    
    
    
  
  
    
      
        What's new JQM 1.2.0
      
      
        
          This page will show you some of the new features, widgets and
          method of jQuery Mobile 1.2.0 explained in the article
          "What's New in jQuery Mobile 1.2.0?".
        
        
          
            Popups
            Basic Popup
            Image Popup
          
          
            Collapsible List with Listview Autodividers
            
              The following list is inside a collapsible element and it
              uses also the new data-autodividers attribute.
            
            
              Aurelio De Rosa
              BuildMobile.com
              JSPro.com
              PHPMaster.com
              SitePoint.com
            
          
          
            Read-only Lists
            Articles published
            
              Aurelio De Rosa3
              John Doe2
              Jason Parker5
            
          
          
            Loading
            Keep loading...
          
        
      
      
        
          Popup
        
        
          Hello! I'm a brand new popup widget.
          Close
        
      
      
        Close
        
          
        
      
      
        Aurelio De Rosa
      
    
  
Conclusion
Now, you should be able to master the recent changes implemented by the jQuery team in the new release of jQuery Mobile. These can serve your mobile apps and websites well, and hopefully propel your next mobile project to new heights.
  


What’s New in jQuery Mobile 1.2.0?
Aurelio De Rosa — Mon, 12 Nov 2012 22:50:38 +0000
A highly anticipated new version of jQuery Mobile was recently released. Let’s have a look at what’s been added and changed in this 1.2.0 version. Throughout the code samples, you’ll learn also how to handle these new features and harness them to improve your mobile apps.
 
 jQuery Mobile is a lightweight, useful, and easy-to-learn mobile framework defined by a unified user interface system that works across all popular mobile device platforms. I must admit that as soon as I started to study and use it, I fell in love. I’ll focus on the new features of the latest version, but in case you don’t know what jQuery Mobile is or if you need a starting point, I advise you to read Hello jQuery Mobile and Building a Staff Directory on jQuery Mobile.
Keep in mind that the newest version also solves a lot of bugs from the previous one. If you need a complete list of the changes, refer to the official change log for 1.2.0. Please note that I’ll use the term “virtual page” to emphasize the difference between a jQuery Mobile page and a physical page — a file like index.html or page.php.
  
Compatibilities
The first thing to highlight is that jQuery Mobile 1.2.0 increased device compatibility. Actually, most of these operating systems or browsers already worked with the version 1.1, but jQuery Mobile now has an unrivaled “‘A’ grade” compatibility. “A” grade means full, enhanced experience with Ajax-based animated page transitions. If you need more information about what those grades are, you can read Mobile Graded Browser Support.
 The complete list of fully compatible mobile operating systems includes: iOS 6, Android 4.1, Tizen, Firefox for Android, and Kindle Fire HD. Now, you’re probably puzzled by Tizen. It’s an open-source operating system created by the Linux Foundation. To be more accurate, I’ll to cite their “About” page:
Tizen is an open source, standards-based software platform supported by leading mobile operators, device manufacturers, and silicon suppliers for multiple device categories, including smartphones, tablets, netbooks, in-vehicle infotainment devices, smart TVs, and more. Tizen offers an innovative operating system, applications, and a user experience that consumers can take from device to device.
As you may know, jQuery Mobile relies on the jQuery library. The new version of jQuery Mobile added the support for the latest jQuery version, the 1.8 branch and — on the other end of software modernization — the jQuery team dropped the support for the 1.6 branch. However, if you still use that old version, your code should work as before, but be aware that if bugs are found that affect just this older 1.6 version, they won’t be fixed.
Popups
Popups are one of the new features introduced in the latest version of jQuery Mobile. They allow you to put any content like menus, widgets, or images inside a container that floats above the current page. It’s very easy to create one. In fact, all you have to do is to follow the structure of a classic jQuery Mobile virtual page and replace the data-role="page" with data-role="popup". To call a popup widget, just like a dialog, you have to place a link pointing to the ID of the popup and add data-rel="popup". The following is an example of how to call a popup.
Basic Popup
And this is how it resembles a basic popup.

  
    Popup
  
  
    Hello! I'm a brand new popup widget.
    Close
  
Like almost every other feature, the popup widget has a lot of useful options like theme to set the color scheme for the popup contents, corners to determine if the popup has rounded corners, and probably the most interesting, positionTo, which allows you to determine where to render the popup. The possible values are:
origin, the default, which means centered based on the element that called the popup; 
window, centered in the current window;
a jQuery selector, centered among the given element.
One of the main differences between popups and dialogs is that while a dialog must be an external page and a physical file, a popup is placed in the same file and within the same virtual page that will call it.
I must admit that this dialog constraint made me waste a lot of time when I started with jQuery Mobile. In fact, at that time I wasn’t using the popup widget, and I felt that having a physical file was a waste of disk space. Citing the documentation:
Any page can be presented as a modal dialog by adding the data-rel=”dialog” attribute to the page anchor link.
Although the documentation examples always show a link to a physical file, they don’t specify that it must be a physical file. However, thanks to the new popup widget, you’ll never have to build additional external files or run in this issue again.
Lists
In this new jQuery Mobile version, lists are rendered, altered, and manipulated much more easily. Let’s take a closer look.
Listview Autodividers
The jQuery Mobile team has introduced a new list attribute that will absolutely thrill you. The attribute is data-autodividers, and it greatly improves the readability of your lists by adding alphabetical list dividers. The great news is that this attribute can work together with the data-filter to further improve your apps. So, if you employ both techniques on your list and a user types a string into the input box to filter data, the dividers will change accordingly. Of course, they still remain independent from each other. To start using this new attribute, your list view should resemble to the following.

  Audero.it
  Aurelio De Rosa
  BuildMobile.com
To see in action a full example, please refer to the its demo page on the jQuery Mobile website.
Collapsible Lists
From this release onward, you’ll have collapsible lists at your disposal. Lists within lists are displayed when the parent list is tapped. Being lists, you can use all of the attributes that you already know such as data-inset, data-filter, and the previous-explained data-autodividers. You’ll now be able to show a single collapsible element or create an accordion. In case you aren’t familiar with accordions, they are sets of collapsible elements that you can create by wrapping several collapsed elements with a tag having attribute data-role="collapsible-set".
Read-only Lists
In jQuery Mobile, lists are very easy to read due to the readability enhancement made by the framework. Although they’re mainly used to list links, lists are also used to display read-only list items. In this 1.2.0 version, an aesthetic style modification now renders read-only list items using a flat background color to give the user a visual understanding that they aren’t clickable. You can see an example of this change by looking at the read-only list demo.
Deprecated Methods and Properties of the Page Loading Widget
In this version, several methods and properties of the page loading widget have been deprecated. In jQuery Mobile, you used to configure it using $.mobile properties like loadingMessage, loadingMessageTextVisible, and loadingMessageTheme. Now, they should be set using properties text, textVisible, and theme of the $.mobile.loader.prototype.options object respectively. So, the following configuration:
$.mobile.loadingMessage = "Please wait...";
$.mobile.loadingMessageTextVisible = true;
$.mobile.loadingMessageTheme = "e";
should be changed in this way:
$.mobile.loader.prototype.options.text = "Please wait...";
$.mobile.loader.prototype.options.textVisible = true;
$.mobile.loader.prototype.options.theme = "e";
Other changes have been implemented within the methods to show or hide the page loading widget. In fact, before the 1.2.0 version, developers used the $.mobile.showPageLoadingMsg() and the $.mobile.hidePageLoadingMsg() methods. They are now deprecated, so you should use $.mobile.loading("show") and $.mobile.loading("hide") instead if at all possible. Please note that using this new method, you also gain the option to overwrite the global configuration in favor of one specified passing a configuration object when you call those methods. An example of a call to show the widget using a local configuration is below.
// Show the widget using theme swatch "e",
// a custom message and setting the text visible
$.mobile.loading(
   "show",
  {
    theme: "e",
    text: "foo",
    textVisible: true
  }
);
Conclusion
Throughout this article, you’ve seen the new version’s features created by the jQuery Mobile team, including popups, minor list style improvements, and several deprecated methods and properties. Thanks to the expanded device compatibilities, you can spread even more your own applications among a greater array of operating systems and markets.
  


Building Apps That Build Apps: An Interview With The Co-founder of TheAppBuilder
Zsombor Markus — Thu, 08 Nov 2012 18:23:14 +0000
Those of you who dream of a successful startup better pay attention to TheAppBuilder. It’s one of those stories where a couple of savvy developers discover a market gap and come up with a well-executed and successful solution.
It’s been about 6 months since I had a chat with TheAppBuilder team. I have been following JamPot’s updates ever since, and I must say they’ve been working so hard that the product is now completely transformed. While the core of their business still lies in providing a super easy workflow to create multi-platform mobile apps, they have implemented some serious changes and new features.
This time, I interviewed Michael Barr, co-founder of JamPot. We discussed their latest updates and future plans.

 
 
The obvious question: how did the whole thing start?
  
It started just about two years ago. It was just me and another technologist. We had both been working in various sections of the IT community. I was mainly involved in building content management web solutions. We had both been asked to start thinking about mobile solutions for a number of clients. We got together and said: there must be a better way to build mobile apps fast.
We were predominantly focused on iOS apps at the time. I pretty much enjoyed building stuff in Objective-C, but not everyone has those technical skills. So, from there we solidified the idea, secured the funding, and found few like-minded guys. Long story short: we brought TheAppBuilder to where it is today. And that is far beyond what we expected.
Tell me about your story with the CMS you originally worked on. TheAppBuilder could be looked at as a type of CMS. How do they relate?
It was at a small company in Northern-Ireland called WebBelief. It’s focused on delivering content managed web solutions based on the .NET platform. This business model was successful in the days when you could charge a reasonable amount for a content-managed website. However everybody knows that it was gonna be a short-lived time in the web. Many of the solutions move away from being developer tools to cater directly to the end user.
This is exactly the idea we have behind TheAppBuilder. We didn’t want to build another developer tool after we’d seen what happened when professional software such as FrontPage or Dreamweaver and CMS options like WordPress did to the industry. We wanted to allow anyone to create an app, same way that WordPress works with websites. We want to cater to the small business owner who just wants a presence on mobile marketplaces. He/she might not have coding skills, but they really shouldn’t need any to use TheAppBuilder. Those who want to take things further and have some HTML5 skills can use some really fancy techniques. We’ve even seen people building and embedding games using HTML5 canvas.

 
Are you planning to implement some kind of e-commerce solution to help app owners boost their business through the app?
We have a pretty extensive roadmap with some exciting ideas. Payments is one of those things we are currently looking at. People are constantly asking us how they might enable purchases within the app. We are looking at some of the big players in the payments and e-commerce field to see how could we implement their technology. There are some other interesting third-party solutions that we also would like to enable in our apps.
Let’s move on to the updates. The last time I spoke to you guys, the product had just gone public. How has the product been evolving in the past 6 months? 
When I look back and see how many things have happened it’s almost scary!
In the early days, in order to deliver the apps across all major platforms, we had to use a few specific tools. One of these was the Adobe Air platform, which really helped us to deal with both Android and iOS. Although Air was a good introduction to the world of cross-platform development, the apps produced were not of sufficient quality for us to use, and our customers were not happy with the user experience that the cross-compiled solution provided.
We have since moved on to completely native clients: Objective-C for iOS, Java for Android, and C# for Windows Phone. We have also launched our new Windows 8 client, and we are the first app building company to support native Windows 8 apps. (Check out the Steve Ballmer app in the Windows 8 store.) This is especially interesting, because Microsoft are focusing a lot on the transition between PC’s, tablets, and mobile phones and providing a consistent UI and environment for the user, regardless of what device they choose to consume their content.
For a while, we kept Adobe Air for the desktop editor, but then we realized it could be far better if we moved everything to a fully web-based interface. That’s probably the biggest change. The whole app creation workflow is completely web-based from start to finish, and it’s accessible even from tablets.
We also added a whole new templating mechanism. To achieve this, we really had to look into how people use our app builder. If you start creating an app, the first thing you will find in TheAppBuilder Wizard is a selection of templates. If you are about to create an app for a restaurant, you can pick the Restaurant/Bar template, which is geared up with the relevant tabs and functionalities. Of course, you can customize all of these just a few steps later. We are planning to allow our users to submit their self-designed premium templates, which others can purchase. This will be a great way to allow our community to feed in and even return a bit of their time investment as well.
One of the most exciting new addition is Maps. It’s an easy way to set the geolocation of your business or any of your upcoming events. This can also be displayed in an augmented reality view on compatible devices. Up until now, it has been only using Google Maps’ API, however with the launch of iOS6, it’s set to work with Apple’s map back-end too.
We added a few other new sections as well. Gallery provides an easy solution to upload and manage your photos. Lists are extremely useful if you want to upload a selection of products. We also made a separate section for events. Apart from Twitter and Facebook, we also have YouTube gallery, which provides easy access to your videos. Of course, if you need any additional functionality you can always add an HTML5 tab and apply your own custom code.
We also introduced private apps. We saw a need for enterprise apps that aren’t designed for the public. These provide a way to distribute news and updates for a selected group of users, and we are working with some large enterprise clients who are looking to disseminate internal information to their employees via custom mobile apps.
One of our most recent updates includes nesting. This allows users to place any type of module within a standard list view, which opens up a world of possibilities to create very powerful apps. For example, a single content section can contain many sub-galleries, a news feed can be broken down into different sub-sections, users could even create product catalogs with categories and sub-categories.
Do you see any potential in NFC (Near Field Communication) at the moment?
Absolutely, we could probably do great things with it, but we need to wait until manufacturers catch up on the hardware side first. Then the technology can become mainstream and it will be worth dealing with it.
Do you still keep up with the look and UX of the different platforms or do you plan to go your own way?
We remain completely native, and we have embraced the features and behavior of the various operating systems even more closely. Our Android apps are now in line with JellyBean’s native UI, and the iOS apps bring you the distinct iPhone that is familiar to iOS users.
If you build an app, you also get an iPad beta version of it. This is a slightly different accommodation that’s tailor-made to this faster and larger device. The main point is that the app owners really just need to take care of the content and we do the hard work of releasing the apps on as many major platforms as possible.
Are there any other ways you are planning the community to get involved?
In the next few months we are planning to open up a developer API. That will allow people to discover the app structure via web services, which will allow developers to build native clients for devices that we don’t currently support.
Now you offer the HTML5 version of the applications for free. Do see growing interest in web solutions opposed to native?
We are starting to see a huge uptick in the web solutions and maybe a bit of a slow down on the native side. This is partially due to the strict approval processes of the app stores. Apple, Google, and Microsoft really wants to control what goes public, and this can sometimes make gaining approval difficult. Not necessarily because of the content itself, but the structure and behavior of the apps.
If you put together an HTML5 web app, you have the freedom to do almost anything you want. This free, easy solution allows regular people to create apps for purposes like birthday parties, or perhaps for non-profit organizations to stay in touch with their community in a really cost-efficient way. Some high-end applications may require access to hardware that only native code can allow, but HTML5 is quickly closing the gap to native code.
At the moment we have over 50,000 apps submitted and we see more every day. We’ve been really lucky to have such momentum without putting any particular effort into advertising.
Have you created any apps with TheAppBuilder? Do you feel that HTML5 capabilities are coming progressively closer to that of native code, or do you think that truly robust apps will always need Objective-C, Java, or C# to meet their needs?
 
  


What’s New in PhoneGap 2.2?
Aurelio De Rosa — Tue, 06 Nov 2012 03:56:25 +0000
The day after Halloween, we all received a great gift from Adobe — the release of the latest version of Cordova, better known as PhoneGap. The new 2.2.0 version introduced several interesting supplementary features and enhancements. This article will show you a brief overview on these new changes to PhoneGap.
As you may already know, PhoneGap is an open source framework that allows you to build cross-platform mobile apps using consolidated web technologies like HTML, CSS, and JavaScript. The speed with which the Nitobi team and now the Adobe team now releases new PhoneGap versions is impressive, and every release has consistently been a solid a step forward. Here’s what’s the latest version, 2.2.0, has to offer.
The most significant change, in my opinion, is the support for the brand-new Microsoft Windows 8 operating system. Starting with this release, you’ll be able to develop your PhoneGap applications for Windows 8. To develop these apps, you’ll have to develop in Windows 8. And, just like the Windows Phone 7 equivalents, you’ll have to use Visual Studio as your IDE. The official online documentation has a getting started guide that will help you to set up the environment that you need to develop your mobile apps using PhoneGap.
The Cordova team has also announced that in the next releases they’ll also add the support for Windows Phone 8, not to be confused with the Windows 8 desktop operating system. They’ve also announce massive performance increases both on Android and iOS. The team announced that the PhoneGap 2.2.0 JavaScript bridge will improve your apps execution by a factor of 15-25 compared to the older versions.
Additionally, the Globalization plugin has been integrated into the PhoneGap core. This plugin allows you to get information about user’s locale and timezone using methods like getPreferredLanguage(), getLocaleName() and getCurrencyPattern(). In addition, it has methods to perform operations on these topics like stringToDate() and numberToString(). These improved methods can make for highly personalized app experiences that measure up very well against native apps.
Currently the supported platforms are Android, BlackBerry WebWorks (OS 5.0+), and iOS. But, as always, in the next releases the support will be extended to other operating systems. In case you need more details you can read the specific section of the official documentation.
A couple of changes have been introduced for the FileTransfer API. Citing the official documentation, FileTransfer is an object that allows you to upload files to a server or download files from a server. The PhoneGap curators have also added the support for the onprogress event to meticulously track of the progress of a transfer operation and add the possibility to abort a transfer operation. This API is one of those that are already available for Windows 8 too. As well as the Globalization API, the Splashscreen API has been added to the official documentation, so now you can find a specific page within the PhoneGap documentation. This new API allows developers to show or hide the application’s splash screen. Currently, the support is only for Android and iOS.
Several changes have been made to the process in which mobile developers create an Android plugin that allows extension of PhoneGap’s basic functionality. Now, it must have at least one Java class that extends the CordovaPlugin class, which replaced the old Plugin class. Like in previous versions, a plugin must override one of the execute methods, but now PhoneGap developers have a new execute() method that allows them to pass a large amounts of data to the native side. It also has a new onReset() method, called when top level navigation changes. You can read more details on this matter looking at the official documentation page.
Conclusion
PhoneGap is an extremely robust mobile development tool, and it is curated constantly and carefully. In addition to the explained new features, a lot of bugs have been fixed and many minor enhancements have been added. If you want a detailed list, you can read the official changelog, or the two platform-specific posts published; one post on Android and the second post on iOS. Maybe you’ll find that they fixed exactly the feature you needed to make PhoneGap your development framework of choice.
  


4 Ways To Avoid Scope Creep And Still Please Your Clients
Nicolas Acuna and Mikka Olsson — Thu, 12 Jul 2012 16:03:09 +0000
Landing a mobile development deal is a tough task and a rewarding accomplishment. But, as anyone who has created an app knows, landing the deal is just the beginning. As the production process begins, designers and developers need to be aware of a very tricky problem called scope creep.
Sometimes, clients feel that — since they have awarded you the deal and money has been exchanged — they have the right to request features and changes that are beyond the original scope of the project. This is rarely done of our malice or bad intentions, but it still puts designers and developers in a difficult position, since we have to figure out how to say “no” without jeopardizing the relationship.
So, how do we avoid scope creep? Here are four tips that have worked for us.
Define the Scope
This tip may seem obvious, but defining the scope in clear, precise written terms is surprisingly difficult. As we begin to sense that the client is leaning towards signing the deal, we often feel the need to rush, skip important details, and complete the agreement as soon as possible. The problem with rushing is that the scope will not be as clear and comprehensive as it needs to be, which in turn can very likely lead to scope creep. Any areas of work that weren’t explicitly defined will be interpreted two different ways by the client and the developer, respectively. The client will see vague, undefined, areas of work as a wide open canvas with lots of possibilities. The developer, however, will probably consider those same areas of work as unmentioned, unspecified, and thus not a part of the agreement.
Because of this all-too-common difference in perception, it’s important to define all of the moving parts of a project with painstaking clarity. You might even want to state explicitly what work isn’t part of the project; this will help define the boundaries very clearly, which will in turn keep scope creep to a minimum.
Set a High Rate for Out-of-Scope Work
Add a simple (but important) line in the contract stating that all out-of-scope work (changes, additions, etc.) will be charged at an “X” hourly rate and will extend the timeline of the project. If your client’s extra requests are reasonable, mention this rate and ask them if they want to be invoiced. This approach gives your client good options options and decision-making control without damaging the relationship or causing you to take on unexpected, unpaid work. If accepted by the client, considering amending the original contract to expand the scope to the newly agreed standard and rate.
Be Courageous and Say “No.” Use the Sandwich Technique
Are you familiar with the sandwich technique? If not, it works like the following:
Start out with a positive statement. It could be appreciation for the client’s care for the project, or the value of the (unplanned) idea/feature that they want to add to the project.
State the negatives in the middle. Be honest, direct, and objective. Talk about how adding another feature is not a good idea, and how they would cost more money, take more time, or they may not even be possible.
Then, close the sandwich with another layer of positivity. This could be a statement like “the project is going well,” “we’re very excited for the project,” “thanks for bring this idea to us,” or “that sounds like a great idea for the next version of this project.”
Turn Scope Creep into the Feature Set for the Next Version of the App
Most scope creep includes tweaks, changes, and additions that have the potential to improve the project, and are thus are easily justified by the client. The important questions to ask are not whether the project should include these additions, but rather what version should include these new additions. Talk to your client about a minimal feature set for Version 1 and make a list of additions for the next versions. To help clients understand, we have explained versioning like this: “We all have ideas that can make the app better but at this point they are educated guesses, let’s wait until we launch the app and users ask for these changes/features. This way, it’s no longer an assumption but a defined need.”
Hopefully these tips can help you protect the integrity of the project, your time, and your profit margins. If you’re honest with your client and constantly talk things through, you can turn the scope creep problem into an opportunity to create a better app.
Have you had any trouble with scope creep? How have you handled surprise additions to your mobile projects?
  


Offline Capabilities: Native Mobile Apps vs. Mobile Web Apps
Lee Whitney — Fri, 04 May 2012 16:00:23 +0000
Many mobile apps could benefit from working without an Internet connection. Here, we take a look at how offline capabilities affect the decision of developing native apps vs. mobile web based apps.
Apps that continue to work while “offline” or “disconnected” have been important since laptops first became common. A classic example is a salesperson that wants to enter data while travelling, and then have that data automatically sync with a server when they get back to the office. Even with Wi-Fi and cellular broadband, there are many scenarios (airplanes, Wi-Fi only devices, remote areas) where people still need to work without a connection.
So, when workers need offline mobile capabilities, do we need to develop a native mobile application on the device, for example with Objective-C for the iPhone, or is a mobile web-based app a viable option?
It turns out, the answer is changing very quickly, because more HTML5 capabilities like local storage and local databases are being added to mobile browsers to support offline capabilities.
Short Answer: Mobile Web Apps are Ready to Go Offline
The short answer is yes, it is now a practical option to develop an entirely web-based mobile app with offline capabilities for many scenarios. Notice that I say many scenarios, not all. At this point in time, it still depends on what offline capabilities are needed. Specifically, the main factors are how much offline data is needed and what indexing capabilities are required.
  
How is an Offline Web App Even Possible?
To understand what offline scenarios are good candidates for a mobile web app, it helps to first understand the key technologies that make it possible.
Mobile web apps can be built with three core capabilities, and all of these are part of the new HTML5 standards:
Browser application caching of pages
Local storage
Local database
Browser application caching allows a manifest to be created listing pages that should be cached and made available offline. Normally, when you visit a URL, a server request is made to return the page. Setting up an application cache manifest tells the browser how it can use pages already downloaded rather than just immediately displaying an error when there is no longer a network connection.
Local Storage is a standard that retains local web app data (even when the browser is shut down) using a key/value system that works similarly to browser cookies. However, it is different from browser cookies in two important ways. First, cookies are resent to the server with every HTTP request, and it would waste a lot of bandwidth to resend all offline data when the server doesn’t need it. Secondly, cookies tend to max out at around 4k of data, while local storage usually gives an application as much as 5 MB of data to work with per domain. 5 MB may not sound like much, but when used carefully, it can go a very long way in terms of offline local storage.
Local Database removes the 5MB limit of local storage and allows data to be indexed so that multiple properties can be queried quickly. This is only an HTML5 proposed standard at present; only Internet Explorer and Firefox have implemented it so far. Safari and Chrome use an older, deprecated system called Web SQL. This means if you need this level of functionality, there is a significant amount of extra work and complexity to support both standards across all major browsers. Hopefully, that won’t always be the case and major browsers will conform to the finalized HTML5 specifications.
So, is a Mobile Web App a Good Solution for Offline Features or Not?
The key here is whether your app needs the higher storage limits (greater than 5MB) and indexing features that come with a Local Database. If Local Database and major browser support are needed, it stacks the deck against a web app because of the extra work and complexity needed to support two very different standards.
However, if you can get by without using a Local Database, and your offline storage needs are below 5MB, then using Local Storage and Browser Application Caching alone will allow for a clean solution that works well across major browsers.
To decide if Local Storage is good enough, consider these constraints for the app:
The total size of data you need to keep offline
The number of data items (records) you need to keep offline
The number of data properties (fields) you need to search within
If you need less than 5MB at a time offline, Local Storage fits the bill. If you have a large number of records but usually only one field to search on, Local Storage is still a good fit. If you have many fields to search on but the total number of records is small, again Local Storage would work nicely.
By answering these questions about your app, you should have a good idea about the practicality of a mobile offline solution.
There is Much More to the Native vs. Web Decision
Here, we’ve focused mainly on issues around offline capabilities for mobile apps. However, keep in mind the more general decision criteria still apply.
For example, if you need to allow a user to take a photo with a built-in camera and upload it to a server, a mobile web app simply is not capable of meeting your needs. Beyond the device capabilities questions, there are also the issues of what skill set you want your company to invest in and what types of apps you tend to develop.
Finally keep in mind that “native vs. web” is a simplification of the choices. Mobile web apps can be built by just adding a viewport tag to an existing site, adaptive rendering (CSS media queries), and dedicated views for mobile devices. Native apps can be built with the vendor toolkit (like Objective-C), or with an abstraction platform (like Titanium), or by bundling HTML with a native library (like Phonegap). The “native vs. web” dilemma shouldn’t be seen as two polar extremes; it is actually a continuum of choices from one end of the spectrum to the other.
Think Offline
It turns out that the variety of mobile apps that can benefit from offline features is quite diverse. If you’re in the process of making a platform decision to build a mobile app, it’s a good idea to think through all of the offline possibilities that have been discussed above as part of the process. You’d be surprised how many mobile projects can benefit from HTML5′s new offline capabilities.
Do you have any experience using HTML5′s caching, local storage, or local databases? Do you use any mobile web apps that employ offline storage?