This is the next excerpt from the book “Build Mobile Websites and Apps for Smart Devices” by Earle Castledine, Myles Eftos and Max Wheeler. BuildMobile is exclusively publishing a complete chapter from the book, the chapter on Mobile Web Apps, and this is the third section on “Quick Wins”.
3. Quick Wins
As we move though the book, we’re going to meet some relatively complex code for recreating native effects and behaviors. Thanks to some (fairly) standard hooks and APIs, however, there are a few tricks we can employ to add a bit of pizzazz to our apps without having to do much work at all.
3.1. Nifty Links
For security reasons, mobile web applications are sandboxed away from many built-in features of the mobile device; for example, unlike native apps, they’re not able to retrieve a list of a user’s contacts, or take a photo with the device’s camera (yet). However, they do have the ability to open a few core applications and fill them with data just by using some carefully constructed hyperlinks.
The simplest of these is the well-known mailto: URI scheme. On the desktop, these will launch your default mail application – and a smartphone does the same:
<a href="mailto:email@example.com?subject=Complaint"> Send complaint </a>
This will bring up the device’s email app, with the subject line filled out with the variable we passed in, as Figure 4.3, “mailto: links will bring up the phone’s email app” shows.
3.1.2. Phone Numbers
We can also assist in dialing a phone number using the tel: URI scheme. This will bring up (but not dial, of course) a phone number:
<a href="tel:1-408-555-5555"> Call in a sighting! </a>
In fact, for the iPhone, there’s no need to even wrap the number in a hyperlink. Mobile Safari includes a feature that automatically detects phone numbers in a page and turns them into links for you. “Excellent,” you may think – until the first time it tries to turn your product IDs into “dialable” phone numbers! Similarly, there’s a feature that turns address-like text into map links. But like any automagic feature, it’s not always what you want. If that’s the case, you can include tags in the head of your page to disable these features:
Again supported by the iPhone but not Android is the sms: URI scheme, which also takes a phone number, but opens up the text message application. At this point you might be worried about the limited support – fortunately, it’s not a big problem if a device fails to recognize a URI scheme, as nothing will break; the link will simply do nothing.
Turning now to maps, the situation is a little less ideal. If you want to open a map and zoom to a given location, there’s no widely implemented, standards-defined way to do it. A common method is to simply construct a URL that points to http://maps.google.com/ with a properly formatted latitude and longitude. Both iOS and Android will open this using the built-in mapping application rather than following the link in the browser:
<a href="http://maps.google.com.au/maps?q=sitepoint">Visit us!</a>
A more standards-friendly version is the geo: URI, which accepts a variety of values that will be interpreted as map data by the device’s mapping application. You can pass a latitude and longitude:
<a href="geo:-33.87034,151.2037">Visit us!</a>
Or a street address or business name and location:
<a href="geo:0,0?q=123+Fake+St">Visit me!</a>
This is certainly nifty, but it’s currently only supported on Android.
3.2. Form Field Attributes
With our links all polished up, let’s turn to forms. HTML5 drags the basic form into the future with a quiver of shiny new input types and form attributes, which are well-supported on the current crop of mobile devices.
The HTML5 placeholder attribute of an input field will populate the field with a user prompt, which disappears when the user focuses on it. This is commonly used to avoid the need for a field label, or to offer additional help text to the user:
<fieldset> <label for="name"> <span>Who</span> <input type="text" name="name" placeholder="Star's name"/> </label> <label for="tags"> <span>Tags</span> <input type="text" name="tags" placeholder="Tag your sighting"/> </label> </fieldset>
The iPhone’s keyboard tries to help out users by capitalizing the first letter in a form field. Most of the time, this is what you want – but not always; for example, in the tags field in our sample form. The iPhone will also attempt to correct words it fails to recognize, which can become a problem for our celebrity name field. These features can be disabled via the autocorrect and autocapitalize attributes:
<fieldset> <label for="name"> <span>Star</span> <input type="text" autocorrect="off" placeholder="Star's name"/> </label> <label> <span>Tags</span> <input type="text" autocapitalize="off" placeholder="Tag your sighting"/> </label> </fieldset>
Note that these attributes are nonstandard, in that they’re not in the HTML specification – at least for now.
Turn off the Automagic
If the majority of your form’s fields require these attributes, you can also add them to the
tag itself, to apply them by default to all fields in that form. You can then override this setting on any given field as required.
Another HTML5 feature that’s useful for mobile sites is the addition of a number of new input types. Beyond the traditional type=“text”, HTML5 provides email, number, url, date, and even color inputs. These will all display as simple text fields on most browsers, but the iPhone cleverly provides appropriate keyboards for the data in question – for example, including shortcut keys for @ and . (period) when you use type=“email”. For type=“number”, it will provide a number pad instead of a traditional keyboard, as shown in Figure 4.4, “A numeric keypad appears when focusing a number input on the iPhone”. The BlackBerry browser even provides date and color pickers for date and color input types.
Here’s an example of these input types in action:
<label> <span>Tags</span> <input type="text" autocapitalize="off" placeholder="Relevant tags"> </label> <label> <span>Number of celebs</span> <input type="number" placeholder="Number of celebs"> </label> <label> <span>Tags</span> <input type="email" placeholder="Your email address"> </label>
Support for all these features is inconsistent, so you’ll need to test your target devices. The good news is that even when support is lacking, the app won’t appear broken. Unsupported input types will simply behave as regular text fields, and users will be none the wiser.
Because the iPhone was the first to market, many of the iOS proprietary tricks have wide support on other devices; yet, not everyone wants to implement a competitor’s features! Thankfully, support for the HTML5 standard is growing, and that should trickle down to all the big mobile players soon.
Build Mobile Book
You can purchase the book “Build Mobile Websites and Apps for Smart Devices” from Sitepoint. Read the whole of Chapter 4. Mobile Web Apps, exclusively here at BuildMobile, for free, in the following sections.