You are currently browsing the Devices archives.

HTML5 Input Elements on iOS

Saturday, September 7th, 2013

Perhaps some of the most important UX considerations to make are those surrounding the simplicity with which forms can be completed. This is especially important when taking into account the constraints of Mobile devices.

Input Elements and the iOS Keyboard

While implementing a form for a Mobile Web Application, I found myself in need of a way to control some of the default behaviors of the native iOS Keyboard. Specifically, I found it rather inconvenient on the user’s part to require manual closing of the keyboard of any kind, especially after submitting a form. I also found it inconvenient to have to manually turn off auto capitalization on input elements, or having to work around the default auto-correct behavior on input elements.

Fortunately, these issues (as well as others) have solutions which are readily available, both natively and programmatically.

Turning off auto-caps

By default, the iOS Keyboard displays with Caps Lock on for the first charachter on input elements of type text. For certain use-cases, such as entering usernames, this may not be desirable.

Caps Lock can be turned off by simply defining an autocapitalize attribute with a value of off on input elements:

Turning off auto-correct

As with with Caps Lock, in iOS, by default, input elements of type text have auto-correct enabled. For certain use-cases, again, such as entering usernames, this may not be desirable.

Auto-correct can be disabled by simply defining an autocorrect attribute with a value of off on input elements:

Automatically closing the Keyboard

When submitting a form, at times, the iOS Keyboard may not automatically close. This is quite a usability issue as Users should not be required to manually close the Keyboard for use-cases in which they would otherwise not expect the need do so.

A simple solution for this can be implemented by invoking the blur method on document.activeElement, which effectively allows one to programmatically hide the keyboard:

HTML5 Input Attribute Types

In addition to controlling the default behavior of the iOS Keyboard, specific types of Keyboards can be invoked simply by defining a supported HTML5 input element type.

The following examples demonstrate just how easy it is to display a context specific keyboard:

The Email keyboard can be invoked via the email input type:

The URL keyboard can be invoked via the url input type:

The Telephone keyboard can be invoked via the tel input type:

The Numeric keyboard can also be invoked via the pattern attribute, the value of which being either of the following Regular Expressions [0-9]* or \d*:

You can try the above examples here, or view the gist.

Invoking Native Mobile Applications with URI Schemes

Wednesday, July 10th, 2013

In a previous article, I outlined how the native iOS Keyboard and it’s behaviors can be managed with HTML5 input types. In addition to this, iOS, Android and most A-Grade Mobile platforms implement standard URI Schemes (or parts thereof), which allow for easily launching native applications.

URI Schemes

When considering URI Schemes, more commonly (though incorrectly) referred to as protocols, one typically thinks in terms of the more ubiquitous schemes: http, ftp, file, mailto, about, data:uri and so forth. However, as with these and other common URI Schemes, there are additional schemes which allow for various practical applications in the context of Mobile Web Apps; the most common of which being the ability to invoke a platform’s native phone or messaging application, respectively.

URI Schemes and Mobile Devices

In the context of Mobile Web Applications, the tel, and sms URI Schemes are perhaps the most common and applicable; providing a simple means of invoking their corresponding native applications. The following are basic examples which work across all major mobile platforms.

The tel URI Scheme

The tel URI Scheme allows for launching a device’s native Phone application in the context of the phone number specified:

The sms URI Scheme

The sms URI Scheme allows for launching a device’s native Messaging application to send an sms message, or to send an sms message to the phone number specified:

As can be seen in the above examples, hyphens are used in the same manner as one would typically specify a phone number; however, use of visual separators are purely optional – they can be used to aid in readability if desired, but are otherwise ignored when parsing the URI.

As a general best practice, one should take care to ensure both tel and sms URI Schemes are defined in lowercase, so as to ensure portability across platforms. Additionally, it is important to note that the sms scheme is not implemented to completion against it’s formal definition on any platform (see section 2.2 of rfc5724); thus, an sms message body, or sending an sms message to multiple recipients is not supported.

While there is nothing particularly ground breaking about these URI Schemes, or technically complex for that matter, they do prove to be quite useful in the context of Mobile Web Applications. As such, they are certainly worth noting as each can be leveraged to improve the usability of an application.

Windows 8 Web App Start Screen Tiles

Friday, March 1st, 2013

Having had to certify a Web Application for use on the HTC Windows Phone 8X, as well as the Microsoft Surface Tablet, I was interested in providing a Start Screen Tile similar to that of the application’s current iOS Web Clip Icon. Not the least, the new Tile Based UI in Windows 8 presents significant UX improvements over that which has been seen in previous versions of Windows; thus, I felt compelled to take advantage of the new UI from a Web Application context.

Conveniently, adding a Windows 8 Start Screen Tile (Pinned Site) can be accomplished quite easily, and in much the same way as that which is used when specifying a Web Application to run in standalone-mode on iOS. To do so, one need only add additional meta elements with a name attribute of msapplication- followed by a specific Tile property. A standard content attribute can then be used to provide the corresponding attribute value.

For example, a Tile can be defined with a specific color using msapplication-TileColor:

Likewise, a specific Tile image can be provided using msapplication-TileImage:

Note: Tile images should be 144x144px, in .png format (transparent).

This site, for instance, utilizes both of the above:

While creating and defining a Start Screen Tile is simple enough, Microsoft also provides a handy Web based utility which allows for automating the Pinned Site creation process by generating a selected Tile Image in the correct dimensions, and providing the corresponding source at

AT&T Best Practices Guide for App Development

Sunday, January 15th, 2012

When considering the various best practices surrounding the design of Mobile Web Experiences and Architectures, such works as the W3C’s Mobile Web Application Best Practices guide, or the excellent Mobile Web Best Practices site, and of course, the seminal text, Mobile First, are likely to come to mind. The concepts and strategies presented in these works are a staple in the design of many modern Mobile Web Experiences and are without question an invaluable resource. In addition to these and other similarly related works, another new and valuable resource has been made available from a very important player in the Mobile Space indeed – an actual Wireless Carrier, AT&T.

Recently, I was contacted by a representative of the AT&T Developer Program informing me of the research conducted by the AT&T Research Labs and, the subsequent resources made available by AT&T as a result of their findings. Since I was unaware of this work, I was very interesting in learning more and, after reading the introductory statements, I was quite eager to apply AT&T’s recommendations as well; to quote specifically:

We quickly saw that a few, simple design approaches could significantly improve application responsiveness.

Having read through the material in it’s entirety (provided below) I must say I am rather impressed. The information provided has very real and practical implications on the design of Mobile Web Applications. Specifically, I found the clear and concise explanation of the underlying implementation of the Radio Resource Control (RRC) protocol to be particularly relevant and useful. RRC is by far one of the most important design factors to consider in terms of battery life and Application responsiveness and, as the research suggests, this may not have been common knowledge.

By far, the most interesting and notable aspect of the AT&T Research Lab’s work in this area is the fact that all of the information provided is applicable in the context of all Wireless Carriers, not just AT&T. That is, the recommendations given, such as those regarding the RRC State Machine, for example, are all based on carrier-independent standards and protocols implemented by all Wireless Carriers. As such, understanding the implementation specifics and recommendations provided is certain to prove valuable for all users of your Application, regardless of their Carrier.

If you haven’t all ready, I highly recommend reading and applying the principles provided by AT&T’s research to your current and future Mobile Web Application Designs.

AT&T Research Labs: Mobile Application Resources

Build Efficient Apps
Profiling Resource Usage for Mobile Applications: A Cross-layer Approach

Configuring iOS HTTP Monitoring

Friday, December 16th, 2011

When developing Web Applications for the Mobile Web Experience it is often useful to have a clear view into all HTTP requests and responses sent between the client and server. This is quite simple to accomplish when developing Web Applications for the Desktop as, the browser is running locally so any standard HTTP Monitor will suffice. And, while it is a normal part of a typical development workflow to run an application locally the majority of the time, testing on each target device is obviously an essential part of the process as well.

Luckily, with Charles, on iOS this is quite simple to accomplish.


To configure Charles to proxy all requests from an iOS device, simply follow these basic steps:

  1. From your iOS Device, open Settings.
  2. Go to Wi-Fi, select your Network and select the Blue “arrow” icon.
  3. Scroll to HTTP Proxy and select the Manual Button.
  4. In the Server field, enter the IP address of your development machine.
  5. In the port field, enter port 8888 (the default port to which Charles binds).
  6. Leave Authentication set to Off.

And that’s all there is to it. Now, open Mobile Safari and go to your Web Application’s URL (or any page on the web for that matter). On your development machine, in Charles you will receive a prompt with the IP Address of your Mobile Device, click “Allow” and you are all set. When you are done working, make sure to turn off HTTP Proxy on your device.

Additional Note

While this article may be focused on Mobile Web Applications, these same configurations apply to all HTTP traffic from any application on your device that requires resources over the web.

DHTMLX Touch 1.0 Released

Wednesday, November 23rd, 2011

Last week, shortly after I blogged about the release of jQuery Mobile 1.0, I received an email informing me of the release of another Mobile Web Framework: DHTMLX Touch 1.0.

Being that I was unfamiliar with DHTMLX Touch (as I have been using jQuery Mobile almost exclusively), I was quite interested to learn more; and, having tried the Examples and reviewed the Documentation, I was rather impressed by DHTMLX Touch.

And so, if you haven’t already, check it out.