You are viewing the Articles in the UX Design Category

Simplifying Testing of Sign-up Processes

When testing the various steps of account sign-up, creation and activation processess, one must be mindful of designs which call for unique email addresses to be confirmed for each new account. While this is a generally accepted approach, it does pose a slight challenge when end-to-end testing requires email activation from the address with which the account was created.

Creating multiple Accounts under the same Email Address

Recently, while implementing an account registration feature, I was looking for a simple means of creating and testing multiple user accounts against a single email address, so as to allow for continuous testing without the need to use different email addresses for each test.

Fortunately, a few clever solutions have been available all along in Gmail which can be leveraged for this very problem (in addition to others).

The Plus (+) Trick

Perhaps the simplest means of creating or generating unique email addresses for account creation which will all be sent to the same email address is to leverage the Plus (+) Trick.

For instance, suppose you are testing account creation and activation and want to confirm the sign-up process at someuser@gmail.com. Typically, one would want to test this feature multiple times – either by means of automated testing, manual integration testing, or the like. In order to test the account creation feature continuously using the same someuser@gmail.com account, one can simply create new accounts by appending a plus (+) to their gmail user name, and postfix a unique string of charachters to the plus sign:

In this example, emails sent to any of the addresses above would all go to someuser@gmail.com. With this in mind, it is quite easy to continuously test account creation processess without the need to use multiple (real) email addresses.

The Dot (.) Trick

As with the Plus (+) Trick, similarly, the Dot (.) Trick can also be employed to test account creation under the same email address.

For instance, to test an account creation and activation process feature continuously using the same someuser@gmail.com account, one can simply create new accounts by inserting a dot “.” within their gmail user name:

In this example, emails sent to any of these addresses above would all be sent to someuser@gmail.com.

Concluding Thoughts

As can be seen in the above examples, both the Plus (+) Trick and Dot (.) Trick, respectively, can be used to create and test account sign-up and activation processes against a single email address, greatly simplifying testing.

While the Dot (.) Trick is quite useful, it is obviously limited to a finite combination of pseudo-unique email addresses, and thus, it is better suited for fewer testing scenarios.

For more extensive testing scenarios, the Plus (+) Trick is much better suited, as it allows for seemingly infinite permutations of the same email address, and is ideal for generating addresses from which account creation is to be tested.

HTML5 Input Elements on iOS

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

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.

Styling HTML5 placeholder attribute text

HTML5 placeholder attributes can be leveraged to provide a convenient means of indicating required input formats.

By default, browsers typically implement placeholder attributes as light-grey text. As with all default user agent styles, one will feel compelled to define custom selectors to provide application specific styles to elements, placeholder attributes included.

Styling Placeholder Text

Styling placeholder attributes on input and textarea elements is rather simple; however, one should take care to keep style declarations limited to those of a textual nature; e.g. color, font-size, font-family, etc.

As it stands, HTML5 placeholder attributes can be styled with pseudo-elements in WebKit, and pseudo-classes in both Firefox and IE10; all of which (currently) require vendor prefixes.

Placeholder attribute text can be styled for all supported input element types (text, search, url, tel, email, and password) as follows:

As can be seen, defining styles for placeholder attribute text is quite simple, and such styles can be employed to add subtle enhancements to form elements in modern web apps quite nicely.

Windows 8 Web App Start Screen Tiles

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 www.buildmypinnedsite.com

AT&T Best Practices Guide for App Development

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