You are viewing the Articles in the Quick Tips 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.

Quick Tip: Chrome Developer Tools Shortcut Keys

Sometimes it is the more subtle, less obvious features provided by tools which prove to be surprisingly useful. Interestingly, while such features can save developers considerable time and effort, they are often much less apparent, and thus, occasionally overlooked when compared to their main counterparts.

A noteworthy example of some very simple, yet extremely useful features can be found in just a few of the basic Chrome Developer Tools shortcut keys. Below is a brief description of the most convenient shortcuts I find myself using regularly.

Go to Source (Cmd-O)

Perhaps the most useful short-cut available in the sources panel, Cmd-O allows one to quickly search for a specific source file (thanks to @augiemarcello for this one):
Chrome Developer Tools Command-O

Show Functions (Cmd-shift-O)

Another extremely useful feature in the Sources Panel, Cmd-shift-O displays a list of all functions and their corresponding line numbers within the current source file:
Chrome Developer Tools Command-Shift-O

Clear Console (Cmd-K/)

Clears the console when in focus:
Chrome Developer Tools Command-k

Previous/Next Panel (Cmd-[ / Cmd-])

Toggles between Developer Tools Panels (e.g. Elements, Resources, Network, Sources etc.):
Chrome Developer Tools Command-[]

There are quite a few additional shortcut keys available in Chrome Developer Tools, and Jared has done a excellent job of providing a Devtools cheat sheet. I highly recommend trying some of them out; committing to memory those which you find most useful – and sharing them with others as well.

Github Source Anchors

Recently while viewing the documentation and source for Lo-Dash, I noticed an interesting Github feature which allows for linking to any line number within a source file, and highlighting the line when the page is loaded, via URL anchors.

Linking to line numbers in source files

To link to a specific line of code in a source file on Github, simply click on the line number, which updates the URL with an anchor to that particular line number, or manually append an anchor to the URL in the form #L<line-number>.

For example, here is a link to the EventRegistry in the Backbone.EventBroker.

Linking to blocks in source files

After discovering this interesting little feature, I tried out a few other things and found that a block of code can also be anchored to as well, allowing for the block to become highlighted when the page is loaded.

Creating an anchor to a code block is as simple as selecting a line and pressing CTRL+SHIFT while selecting another line. Alternately, the line numbers can be manually added in the hash by specifying start and end line numbers in the form #L<line-number-start>-<line-number-end>. For example, here is a link to the EventBroker.get method.

Considerations

Since source files are likely to change with each commit, it is important to be mindful of the potential side effect of linking to specific line numbers. This is necessary for the obvious reason that changes in source could result in links to line numbers which no longer correspond to the expected code.

That being said, the ability to link to a certain line in a source file is still a rather cool and useful feature, even if only used for sharing links quickly, or for linking to specific commits which are unlikely to change.