Usability, etc.

How to Create Leaflet Control and Layer Plugins

Sun, 19 Jun 2016 00:00:00 +0100

This post explains how to implement control and layer plugins for the Leaflet JavaScript mapping library. Although the Leaflet documentation has a plugin authoring guide, the guide focuses on best practices for organising, presenting and demonstrating Leaflet plugin code. In this post, I focus on explaining the structure and lifecycle of Leaflet plugins. Template code for creating Leaflet control and layer plugins is available on GitHub under the MIT license.

Leaflet Control Plugins

Leaflet control plugins add user interface controls that act on a Leaflet map or it’s layers. Two examples of Leaflet controls are the zoom control and the layers control shown at the top left and top right of the following Leaflet map:

Creating a Leaflet Control Plugin

Leaflet control plugins are JavaScript classes that extend the Leaflet L.Control class. A common naming convention is to add the name of the control plugin to Leaflet’s namespace, which is L. The following code creates a control plugin with a class named L.MyLeafletControl:

L.MyLeafletControl = L.Control.extend({
  options: {
    position: 'topright'
  },

  ...

}

The extend method of L.Control takes a single object parameter that contains the properties and methods the plugin will add to the L.Control subclass. Many control plugins have a set of default settings. In the code snippet above, the options object contains a single position setting with a default value of topright.

The standard Leaflet plugin creation pattern is to implement a factory function that enables the creation of the plugin to be chained with other function calls:

L.myLeafletControl().addTo(map);

The common convention is to name the factory function after the class of the control plugin but make the first letter lower case.

L.myLeafletControl = function(options) {
  return new L.MyLeafletControl(options);
};

The Control Plugin Lifecycle

The following methods are called when a control plugin is added to a Leaflet map:

initialize()
onAdd()

Leaflet calls the initialize method when an instance of a control plugin is created with a call to new. In the following initialize method, we call L.Util.setOptions to combine the values of the default settings (specified by the options object parameter passed to the L.Class.extend method) with the values of the settings for this instance of the control plugin, which are specified by the options object passed as a parameter to the initialize method.

initialize: function(options) {
  L.Util.setOptions(this, options);
  // Continue initializing the control plugin here.
 }

Any further set up code for the control plugin should be added to the initialize method after the call to setOptions.

Leaflet calls the onAdd method when the control is added to the map with the following method calls:

control.addTo(map);
map.addControl(control);

Control plugins are user interface elements that Leaflet displays on top of the map. The onAdd method must return the DOM element that contains the user interface of the control. In the following example, we create a HTML div element with a class of my-leaflet-control to enable the control to be styled with CSS (1).

onAdd: function(map) {
  var controlElementTag = 'div'; // 1
  var controlElementClass = 'my-leaflet-control';
  var controlElement = L.DomUtil.create(controlElementTag, controlElementClass);

  // Continue implementing the control here.

  return controlElement; // 2
}

After creating the div container for the control, add any other code required to implement the control before returning the control DOM element (2).

Leaflet calls a third control plugin method called onRemove when the control is removed from the map:

control.removeFrom(map);
map.removeControl(control);

The onRemove method is the place to tear down your control by releasing resources and removing event listeners, etc.

onRemove: function(map) {
  // Tear down the control.
}

Styling

Leaflet control plugins can be styled with CSS like any other DOM element. Here we add style rules to the my-leaflet-control CSS class that we added to the control’s container div element in the onAdd method above:

.my-leaflet-control {
  // Style the Leaflet control plugin here.
}

Leaflet Layer Plugins

Leaflet layer plugins enable Leaflet to display new types of layers.

Creating a Leaflet Layer Plugin

Leaflet layer plugins are JavaScript classes that extend the Leaflet L.Layer class. A common naming convention is to add the name of the layer plugin to Leaflet’s namespace, which is L. Here, let’s create a plugin control with a class named L.MyLeafletLayer:

L.MyLeafletLayer = L.Layer.extend({
  ...
)}

The standard Leaflet plugin creation pattern is to implement a factory function that enables the creation of the plugin to be chained with other function calls:

L.myLeafletLayer().addTo(map);

The common convention is to name the factory function after the class of the layer plugin but make the first letter lower case.

L.myLeafletLayer = function(options) {
  return new L.MyLeafletLayer(options);
};

The Layer Plugin Lifecycle

The following methods are called when a layer plugin is added to a Leaflet map:

initialize()
onAdd()

Leaflet calls the initialize method when an instance of the layer plugin is created with a call to new. A common layer plugin pattern is to pass the latitude and longitude position of the layer as a key/value pair of the options parameter passed to the initialize method. Recording the position of the layer (1) enables the plugin to update the layer correctly when responding to zoom events (described below).

  initialize: function(options) {
    this._latLng = options.latLng; // 1
    // Continue initializing the layer plugin here.
  }

Leaflet calls the onAdd method when the layer is added to the map:

layer.addTo(map);
map.addControl(layer);

So far, creating a Leaflet layer plugin has been very similar to creating a control plugin. The main difference between layer and control plugins is in the amount of work the onAdd method needs to perform. A common pattern when implementing the onAdd method of a layer plugin is to begin by retain a reference to the map to be able to use it when handling events (1).

Next, the onAdd method creates the DOM element that will contain the layer (2). Although it is common for Leaflet layer plugin authors to implement the layer as a DOM element, it is not a requirement. For example, Mike Bostock has a nice example of overlaying an SVG element on a Leaflet map.

Regardless of whether the layer is implemented as a DOM or SVG element, it is important to add the leaflet-zoom-hide CSS class to the element (3). Leaflet hides elements with the leaflet-zoom-hide class while the map is zooming to improve performance (3).

Unlike a Leaflet control plugin, which is added to the map with a call to map.addControl(control), Leaflet layer plugins must explicitly add themselves to the overlay pane Leaflet makes available for plugins (4).

After adding itself to a Leaflet map, a layer plugin must start listening for Leaflet’s viewreset event (5). Leaflet generates a viewreset event whenever the user zooms the map. The _updatePosition method is our custom viewreset event handler that is responsible for repositioning the layer as the map is zoomed.

Since the _updatePosition method performs the calculation for positioning the layer correctly on the map, we call it now to give the layer a correct initial position (6).

onAdd: function(map) {
  this._map = map; // 1

  var layerElementTag = 'div'; // 2
  var layerElementClasses = '.my-leaflet-layer leaflet-zoom-hide'; // 3
  this._layerElement = L.DomUtil.create(layerElementTag, layerElementClasses);

  // Continue implementing the layer here.

  map.getPanes().overlayPane.appendChild(this._layerElement); // 4
  map.on('viewreset', this._updatePosition, this); // 5
  this._updatePosition(); // 6
}

Whenever the map is zoomed, the latitude and longitude position of the layer (set when the layer was created) will have different coordinates on the screen. To reposition the layer after a zoom, the _updatePosition method first recalculates the screen coordinates of the layer with the latLngToLayerPoint method (1). Next, the screen coordinates of the layer’s DOM element are updated with the new screen coordinates (2).

_updatePosition: function() {
  var position = this._map.latLngToLayerPoint(this._latLng); // 1
  L.DomUtil.setPosition(this._layerElement, position); // 2
}

Leaflet calls a layer’s onRemove method when the layer is removed from the map:

layer.removeFrom(map)
map.removeLayer(layer)

Just like the onRemove method of a Leaflet control plugin, onRemove method of a layer plugin is the place to tear down a layer by releasing resources and removing event listeners. In addition, the layer should remove itself from Leaflet’s overlay pane (1) and stop listening for viewreset events (2).

onRemove: function(map) {
  map.getPanes().overlayPane.removeChild(this._layerElement); // 1
  map.off('viewreset', this._updatePosition, this); // 2
  // Continue tearing down the layer here.
}

Styling

Leaflet layer plugins can be styled with CSS like any other DOM or SVG element. Here we add style rules to the my-leaflet-layer CSS class that we added to the layer’s container div element in the onAdd method:

.my-leaflet-layer {
  // Style the Leaflet layer plugin here.
}

Improve your Code by Refactoring to Nouns and Verbs

Sun, 06 Sep 2015 00:00:00 +0100

To quote the refactoring pioneer, Martin Fowler:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Improving the readability of your code will enhance its usability for your future self and for other developers. In this post I’ll teach you a technique I use when programming that will make your code read more like English. When your code reads more like English, you will need fewer comments to document your methods. Instead of explicitly writing comment blocks that describe what a method does, you will express those comments in the way you name your methods and in the way you compose your method calls.

The basis of this refactoring technique is to think about your methods in terms of nouns and verbs. Noun methods return items to work on and verb methods perform operations on noun items. Each type of method should have a meaningful name that is itself a noun or a verb. In addition, adding prefixes like in and suffixes like of to method names can make your code read even more like English.

Time for an example.

In this post I’ll use a JavaScript example that uses jQuery to show and hide a search box user interface element. However, the code is very simple and you won’t need any experience with jQuery to follow along. Also, I’ll use the terms method and function interchangeably because this refactoring technique is applicable to any language with a function- or method-like language feature.

The search box is a HTML input element:

<input id="search-box">

Let’s start with a function that hides the search box by adding a CSS class called hidden, which is defined as:

.hidden {
  display: none;
}

Adding this class to a HTML element will hide the element and removing this class will show the element.

The hideSearchBox function adds the hidden class to the search box by selecting the search box element with its ID using the jQuery selector $("#search-box") and then calls the jQuery addClass function on the search box element:

function hideSearchBox() {
  $("#search-box").addClass("hidden");
}

The companion method showSearchBox shows the search box by removing the hidden class from the search box element:

function showSearchBox() {
  $("#search-box").removeClass("hidden");
}

These two functions implement verbs (hiding and showing) on a noun (the search box element). Let’s start by factoring out the hide and show verbs into their own functions

function hide(element) {
  element.addClass("hidden");
}

function show(element) {
  element.removeClass("hidden");
}

We can then write the hideSearchBox and showSearchBox functions as:

function hideSearchBox() {
  hide($("#search-box"))
}

function showSearchBox() {
  show($("#search-box"))
}

Now we can factor out the search box element selector into its own noun function:

function searchBox() {
  return $("#search-box")
}

We can then rewrite the calls to hideSearchBox and showSearchBox from

hideSearchBox()
showSearchBox()

hide(searchBox())
show(searchBox())

Now that we’ve factored out the noun and the verbs, we’re starting to build up a language in our program for handling HTML elements. It’s now easy to show and hide other HTML elements by first creating a new noun function to return the element and then using the result of the new noun function as the parameter of the show or hide verb functions.

Let’s look at another example where we can refactor a function that converts its single parameter from milliseconds into seconds.

function inSeconds(milliseconds) {
  return (milliseconds / 1000)
}

Although this function is pretty clear—it converts milliseconds to seconds by dividing by 1000—it contains the magic number of 1000. In other situations, the meaning of a magic number might not be obvious so we would document it with a comment. However, we can remove the need for the comment by refactoring the magic number into its own value function, millisecondsPerSecond:

function inSeconds(milliseconds) {
  return (milliseconds / millisecondsPerSecond());
}

function millisecondsPerSecond() {
  return 1000;
}

By moving the magic number into its own function we’ve made the inSeconds function crystal clear. Also, since the body of the millisecondsPerSecond function is a single return statement, there is no need to document it further; the name of the function documents the return value of the function.

By creating self-documenting value functions like millisecondsPerSecond, you can also avoid cluttering your classes with instance variables, which also makes your code more readable. Additionally, wrapping values in functions enables you to override them in subclasses.

Notice the in prefix of the inSeconds function above? Prefixing function names with prepositions like in and of also helps to build up English-like function calls. Another example of this is the toggleAnimationOf function below, which uses Of to connect the toggle verb with the element being toggled:

function toggleAnimationOf(element, animationDuration) {
  …
}

Using the techniques I’ve shown you so far, we can build up more complex function calls that still reads very naturally:

toggleAnimationOf(searchBox(), inSeconds(searchBoxAnimationDelayInMillis()))

function searchBoxAnimationDelayInMillis() {
  return 500;
}

Summary

By renaming your methods and functions as nouns and verbs and by refactoring your method and function calls, you can improve the usability of your code by making it easier to read by your future self and other developers. As a reminder, here are the noun and verb functions we used in this post:

Nouns	Verbs
`searchBox()`	`hide()`
`millisecondsPerSecond()`	`show()`
`searchBoxAnimationDelay()`	`inSeconds()`
	`toggleAnimationOf()`

Finally, although I call this a refactoring technique, with practice you will be able to write code using nouns and verbs from the beginning.

Learn More

When you build up a language of methods and functions within a program, you’ve created an internal Domain Specific Language (DSL).

Learn more about improving your code by refactoring and how to write better code the first time round in Clean Code by Bob Martin.

How to Access Your iCloud Drive Folder in the Terminal App

Mon, 20 Jul 2015 00:00:00 +0100

iCloud Drive is available as a folder in the Finder on Mac OS X Yosemite (10.10) and later. However, iCloud Drive doesn’t act like a normal Finder folder, which is problematic when you want to work with iCloud Drive in the Terminal app:

iCloud Drive is not listed as a folder in your home folder
You can’t drag the iCloud Drive icon at the top of a Finder window onto the Terminal to copy and paste its path

Although seemingly inaccessible, iCloud Drive is squirrelled away by OS X in your Library folder:

~/Library/Mobile\ Documents/com~apple~CloudDocs

The following command changes the current working folder to your iCloud Drive folder:

cd ~/Library/Mobile\ Documents/com~apple~CloudDocs

That’s a lot to type each time you want to work with iCloud Drive on the command line. You can make life easier for yourself by setting up an alias in your Bash profile. Add the following line to your .bash_profile file with a text editor:

alias ic='cd ~/Library/Mobile\ Documents/com~apple~CloudDocs'

Since .bash_profile is a hidden file, you won’t ordinarily see it listed in the Finder. Use the following command to open your .bash_profile file in the default text editor:

open ~/.bash_profile

Now, to starting working with iCloud Drive on the command line, open Terminal and type:

ic

and you will be taken to your iCloud Drive folder. Although I’ve used the alias ic, you can use whatever suites you.

Troubleshooting Twitter API Application Authentication Failures

Wed, 08 Jul 2015 00:00:00 +0100

All developers know the frustration of finding out that once functioning code no longer works. This can happen when your previously working Twitter API application no longer connects to the Twitter API because of an authentication failure. In this post I’ll show you how to solve a common cause of Twitter API application authentication failures.

If you’re using Twitter4J on the command line, for example, you’ll likely see something like this:

[Wed Jul 08 11:37:49 BST 2015]Establishing connection.
[Wed Jul 08 11:37:50 BST 2015]401:Authentication credentials (https://dev.twitter.com/pages/auth) were missing or incorrect. Ensure that you have set valid consumer key/secret, access token/secret, and the system clock is in sync.

This output gives two possible explanations for the failure:

Your application is not using a valid consumer key/secret pair or a valid access token/secret pair
Your system clock is not in sync

Since your application was just working, it’s unlikely that the consumer key/secret pair or the access token/secret pair are at fault but it’s worth checking. You can find the consumer key/secret and access token/secret pairs for your application at apps.twitter.com under the Keys and Access Tokens tab for your application.

I’ve found that a common cause of authentication failure is the system clock explanation: the Twitter API requires that the clock of the system on which you’re running your application must be in sync with Internet time.

Synchronising your system’s clock is a simple matter of reaching out to an Internet time service. For example, use the following command to synchronise the Ubuntu system clock:

sudo ntpdate ntp.ubuntu.com

After updating your system’s clock, your Twitter API application will probably start working again.

Compactly Visualizing Data with a Double-Ended Bar Chart

Tue, 30 Jun 2015 00:00:00 +0100

This post describes a double-ended bar chart that compactly visualizes two numeric values in a single table cell. Visualizing a column of values with double-ended bar charts makes it easy to see trends and outliers in the data.

The double-ended bar chart was inspired by sparklines and double-sided bar charts.

Sparklines are information-dense graphics often presented in table cells or next to accompanying text. Although many different sparkline styles have been developed, the most common kinds display bar and line charts that present the variable of interest on the vertical axis.

Double-sided bar charts display horizontal bars aligned on a central vertical axis. This type of chart typically compares the value of two variables, such as the number of male and female births on the horizontal axis over a number of years on the vertical axis.

The double-ended bar chart combines the compact representation of a sparkline with the horizontal layout of the double-sided bar chart.

Example

Although the double-ended bar chart can display any two numeric values, it was designed to compactly present the positive and negative sentiment in a table of tweets.

Sentiment analysis assigns a numeric value to a text by analysing the emotional content of the text.

In this example, the sentiment scores were calculated by SentiStrength, which assigns two scores to a text. The positive score is an integer between 1 and 5 that represents the amount of happiness or positivity in the text; the greater the positive score, the greater the amount of happiness or positivity. In contrast, the negative sentiment score is an integer between -1 and -5 that represents the amount of sadness or negativity in the text; the smaller the negative score, the greater the amount of sadness or negativity.

Calculating the Bar Lengths

The maximum width of both the left and right bars is half the width of the table cell. The width of each bar is the maximum width of the bar multiplied by the proportion of the bar’s value to the bar’s maximum value.

For example, when displaying SentiStrength sentiment scores, the maximum value of both the left and right bars is 5. If the width of the table cell is 100 pixels, a positive sentiment score of 4 is represented by a bar with a width of 4 / 5 * 50 = 40 pixels. Similarly, a negative sentiment score of -3 is represented by a bar with a width of 3 / 5 * 50 = 30 pixels.

In practice, adding a few pixels of padding around a double-ended bar chart visually separates it from the table cell borders and from it’s neighbouring cells.

Implementation

I implemented the double-ended bar chart in the above example as a custom table cell renderer for the Java Swing JTable component. The following diagram shows the Java class hierarchy of the double-ended bar chart.

The GraphicTableCellRenderer class is the base class that extends the JComponent class and implements the TableCellRenderer interface. This class clips the contents of the JComponent object to the bounds of the table cell.

The DoubleBarChartTableCellRenderer class extends the GraphicTableCellRenderer class to draw the double-ended bar chart within the clipped table cell bounds. This class has properties that specify the values represented by the left and right bars.

The SentimentBarChartTableCellRenderer extends the DoubleBarChartTableCellRenderer class and implements the getTableCellRendererComponent method. This class takes the Object-typed value parameter and casts it as object that contains the positive and negative sentiment scores that provide the values for the left and right bars.

A Test for Identifying Categorical Data

Wed, 27 May 2015 00:00:00 +0100

This post describes a method for identifying whether a data set is composed of categorical values. Automatically identifying whether a data set contains categorical values enables applications to make use of such data without requiring users to supply this information.

Categorical data is composed of a limited number of possible values. For example, a table column representing gender would contain the text values male and female. This column contains categorical data because it holds only two values regardless of the number of rows. In contrast, a table column containing the text of a set of tweets does not contain categorical data because although some of the values might be repeated—as in the case of retweets—most of the values will be unique. Since repeated value can occur in non-categorical data, a test is required to differentiate between a data set composed of categorical values and a data set composed of non-categorical values that may contain repeats.

The following algorithm provides a useful test for identifying categorical data:

Calculate the number of unique values in the data set.
Calculate the difference between the number of unique values in the data set and the total number of values in the data set.
Calculate the difference as a percentage of the total number of values in the data set.
If the percentage difference is 90% or more, then the data set is composed of categorical values.

When the number of rows is less than around 50, then a lower threshold of 70% works well in practice.

A Responsive YouTube Plugin for Jekyll

Wed, 01 Apr 2015 00:00:00 +0100

This post introduces a plugin I developed to embed responsive YouTube videos in Jekyll websites. Jekyll is a static website generator that is extended with plugins written in Ruby. Responsive videos automatically adjust their dimensions to fit the HTML element in which they are embedded, even when the size of that element changes. Furthermore, the dimensions of responsive videos always maintain the aspect ratio.

Installation

Download the responsive-youtube-jekyll-tag.rb file from GitHub and copy it into the _plugins folder of your Jekyll website. If you are monitoring changes with jekyll serve you will need to stop Jekyll and re-run jekyll serve to make Jekyll notice the new plugin.

NOTE: The Responsive YouTube Jekyll plugin is for self-hosted Jekyll sites. If you are using Jekyll to host a website with GitHub Pages, this plugin will not work correctly. GitHub Pages does not run third-party Jekyll plugins for security reasons. However, you can use the Responsive YouTube Jekyll plugin with GitHub pages if you build your Jekyll website locally and push your website to GitHub, as described in this SitePoint article.

Use

Responsive YouTube videos are included in a Jekyll post or page with a Liquid tag and the unique ID of the video:

{ % youtube <YOUTUBE VIDEO ID> %}

Example

For example, to embed the video with the link https://www.youtube.com/watch?v=tnq2gwBhvCc use the following tag:

{ % youtube tnq2gwBhvCc %}

tnq2gwBhvCc is the YouTube video ID.

The plugin uses Twitter Bootstrap’s responsive embed CSS and JavaScript to make YouTube videos responsive. The example liquid tag above will insert the following HTML and Bootstrap CSS classes into the post or page:

<div class="embed-responsive embed-responsive-16by9">
  <iframe class="embed-responsive-item" width="560" height="315"
    src="https://www.youtube.com/embed/tnq2gwBhvCc" frameborder="0"
    allowfullscreen=""></iframe>
</div>

which embeds the following video:

Download

The Responsive YouTube Plugin for Jekyll is open source on GitHub under the MIT License.

Designing a User Interface for Credit Card Expiry Dates

Sun, 22 Mar 2015 00:00:00 +0000

Designing a user interface for capturing credit card expiry dates is an interesting, multifaceted problem. To work though this problem, we need to ask three questions:

What default values should be used for the expiry date?
What are the opportunities for users to make errors when transcribing the expiry date from the card to the user interface?
How can we support data entry by reducing the cognitive load on users to help prevent errors?

Two common user interface styles for collecting credit card expiry dates are a pair of text input boxes and a pair of dropdowns. Throughout this post, I’ll refer to these two styles as the text box UI and the dropdown UI.

Text Box UI	Dropdown UI

What should the default value be?

Providing reasonable defaults is a good user interface design guideline. Defaults both minimise the work required by users to enter data into software and explain the user interface by providing example values. Using this guideline, providing a default expiry date seems like a good approach.

The default month can have one of twelve possible values. Although arbitrary, we may choose January because it’s the beginning of the year. In contrast, we need to put more thought into the default year. The oldest valid card will expire in the current year. If the current year is 2015, for example, there are no valid cards that expire in 2014 or before, so our default year value must be at least 2015. If we assume that credit cards have a maximum lifetime of five years, then the newest cards will expire in 2020. This gives a range of years from which to choose the default year: 2015, 2016, 2017, 2018, 2019 or 2020. Inevitably, though, the choice is still arbitrary since none of these years is any more likely to be correct than the others.

Whichever default month and year value we choose, we’ll be correct for only a small number of users that happen to have cards that expire in that month and in that year. But isn’t it better to have a correct default value for some users than for none at all? As the saying goes: even a stopped clock is correct twice a day. Is there actually a disadvantage of providing a default value that only suits a minority of users? Actually, there are two disadvantages, both of which stem from the need for users to change the default value to the correct value.

The first disadvantage of providing a default expiry date is that users must actually notice that the expiry date is incorrect. Since credit card entry form UIs generally ask for the credit card number before the expiry date, after entering the credit card number, users that see the default expiry date may assume that the UI has populated the expiry date based on the card number.

The second disadvantage of providing a default expiry date is that users may have to perform extra work to replace the default value with the correct value. For example, the text box UI requires the user to replace the default text. This text replacement step can be mitigated if the default text is automatically highlighted when users click on the input box or tab into it; the default value will be replaced on the first keystroke. The dropdown UI fairs better in this case because choosing the correct value takes the same amount of work regardless of the current value.

Based on this analysis, I would recommend not using default values that are actual months and years. Instead, use placeholder values that illustrate what data is required. However, before choosing the format of the placeholders, let’s look at the kind of errors users can make when entering expiry dates.

Opportunities for Data Entry Errors

The data entry task is to accurately transcribe the month and year of the expiry date as printed on the card. Users can make syntactic and semantic errors when transcribing data from the credit card to the UI. Syntactic errors occur when users enter values that are not valid; semantic errors occur when users enter valid values that are not correct. The dropdown UI is able to prevent all syntactic errors because the only values available to choose from are valid. However, users can still make semantic errors when they enter the wrong month or the wrong year.

The text box UI is more limited in its ability to prevent syntactic errors. For example, users can enter an invalid month, such as 60, which can occur when users transpose 06 for June. To prevent this kind of error, implementations of the text box UI could disallow users from entering any digit other than 0 or 1 as the first digit in the month input box. Since any positive year is valid, the year input box need only disallow users from entering a minus to prevent year syntax errors. Although the text box UI is able to prevent some syntactic errors, just like the dropdown UI, the text box UI is also unable to prevent semantic data entry errors.

Although we can prevent syntactic errors by using the dropdown UI, we can’t prevent semantic errors. Therefore, we need to design a UI that supports a data entry task that will always be prone to error. To do that, we need to understand the underlying cause of the errors.

Credit cards use a standard expiry date format of two month digits followed by two year digits (MM / YY). However, UIs for capturing expiry dates are far from standard. Whenever the UI differs from this format, there is an opportunity for users to make data entry errors.

The following table lists each variation of the text box and dropdown UIs. The table also lists the translations that users must perform when transcribing the month and year digits from the card to the UI and the comparisons required to validate the transcription.

	Month		Year
User Interface	Translation	Validation	Translation	Validation
	None	Direct	None	Direct
	None	Direct	Enter the 20 prefix before entering the two year digits on the card	Compare the two year digits on the card with the last two digits in the year text box
	None	Direct	None	Direct
	None	Direct	Prefix the two year digits on the card with 20 before selecting the year	Compare the two year digits on the card with the last two digits of the selected year option
	Map from month number on the card to month name in the UI	Map from month number on the card to month name in the UI	None	Direct
	Map from month number on the card to month name in the UI	Map from month number on the card to month name in the UI	Prefix the two year digits on the card with 20 before selecting the year	Compare the two year digits on the card with the last two digits of the selected year option

Supporting the Data Entry Task

The greater the difference between the format of the expiry date on the card and the format of the expiry date in the UI, the greater the cognitive load on users when transcribing and validating their transcription. For example, the following form of the dropdown UI puts the greatest cognitive load on users because it has a different format than a credit card for both the month and year. Additionally, the month dropdown requires users to translate the number of the month on the card to the name of the month.

To support the data entry task, we need to reduce the cognitive load on users. The following forms of the text box and dropdown UIs both match the format of the expiry date on the card exactly. As a result, these UIs place the least cognitive load on users and reduce the likelihood of transcription and validation errors.

To support users when entering credit card expiry dates, I recommend using the following version of the dropdown UI with the default values of MM and YY for the month and year. This version requires no translation for either the month or the year and is able to prevent all syntactic errors.

Using Transparency to Visualise Information Density

Mon, 09 Mar 2015 00:00:00 +0000

This posts explains how to use transparency to visualise information density. When visualising geocoded data points on a map, for example, it’s common to plot each location with a marker. When many data points are located in the same geographical area, the markers drawn later will overlay the markers drawn earlier. When the markers are opaque, it’s difficult to tell at a glance how many data points are located in each region. The following example shows geocoded tweets authored about the Boston marathon.

In this example, it’s clear that the tweets follow the marathon’s route. However, it’s not clear where the greatest concentrations of tweeters are. Zooming into the map is one way to move the markers apart to reveal the markers underneath. However, this requires an extra interaction that can be avoided with transparency.

When map markers are drawn in a transparent colour, the accumulation of pixels in the same map region increases the density of the marker color in that region. The viewer can see at a glance that areas with a deeper shade of colour represent more data points. The following example shows the same data drawn with transparency. The concentrations of tweeters are now clearly visible.

Using transparency is a very simple technique that involves adding the alpha channel to the color. In the RGB color model, each color is described with three components: red, green and blue. In the RGBA color model, a fourth component, alpha, is added that controls the transparency of the color formed by the values of the red, green and blue components.

The following example shows a Google map with a set of circular overlays centred on points of latitude and longitude. Although some circles have greater area than others, by drawing the circles in a transparent colour, the circles beneath other circles are not obscured and the overlapping pixels build up the color density.

To add transparency to Google map overlays, simply set the fillOpacity property for the overlay. The value of the fillOpacity property ranges from 0 to 1, where 0 is fully transparent (i.e. invisible) and 1 is fully opaque.

The following code snippet shows how to create a red circular Google maps overlay with 35% opacity. The fillColor property value of #FF0000 sets the color of the circle to red. The fillOpacity property value of 0.35 sets the opacity to 35%.

// Create a new circular Google Maps overlay
circle = new google.maps.Circle({
  center: latLng,
  radius: radius,
  strokeOpacity: 0.5,
  strokeWeight: 1,
  fillColor: "#FF0000",
  fillOpacity: 0.35,
  map: map,
});

Although 35% is a low opacity value, each circle must have a low opacity value to create the density effect when the pixels of one circle are drawn on top another circle.

Use Animation to Help Users Notice User Interface Changes

Tue, 03 Feb 2015 00:00:00 +0000

This post explains why you should use animation to help users notice changes in your user interface. When interacting with software, users focus on the task they want to perform, not on the software itself. As a result, some users just don’t notice UI changes that occur in one descrete step, even if they caused those changes. For example, I’ve been at usability tests where users didn’t realise that a sidebar pane was opening or closing even when those users repeatedly clicked on the toggle button to open and close the pane.

Whenever user actions causes changes in the state of your user interface, consider animating those changes. Don’t assume that users will notice changes in your UI, even if they interact with controls that initiate those changes. Animating UI changes gives users time to notice those changes happening. Animations don’t have to (and shouldn’t) last long; most of the animations I use last around 350 milliseconds.

Three excellent opportunuties for animation are:

inserting and deleting data
disclosing and hiding controls
opening and closing panes

Most smartphone and tablet users have seen insert and delete animations. Guesture-based interaction with animations on smaller screens provides an intimate interaction between user and device. However, animation is particularly important when this interaction intimacy does not exist, such as when users interact with native or web-based applications with a mouse on larger screen sizes. Often, the larger the screen size, the less likey users are to notice changes.

The video below shows how smooth animation enables users to notice changes in the Xcode, OmniGraffle and Word applications on Max OS X. Notice that Word’s ribbon animation should be much smoother.

Usability, etc.

How to Create Leaflet Control and Layer Plugins

Leaflet Control Plugins

Creating a Leaflet Control Plugin

The Control Plugin Lifecycle

Styling

Leaflet Layer Plugins

Creating a Leaflet Layer Plugin

The Layer Plugin Lifecycle

Styling

Further Reading

Improve your Code by Refactoring to Nouns and Verbs

Summary

Learn More

How to Access Your iCloud Drive Folder in the Terminal App

Troubleshooting Twitter API Application Authentication Failures

Compactly Visualizing Data with a Double-Ended Bar Chart

Example

Calculating the Bar Lengths

Implementation

A Test for Identifying Categorical Data

A Responsive YouTube Plugin for Jekyll

Installation

Use

Example

Download

Designing a User Interface for Credit Card Expiry Dates

What should the default value be?

Opportunities for Data Entry Errors

Supporting the Data Entry Task

Using Transparency to Visualise Information Density

Use Animation to Help Users Notice User Interface Changes