Update – I’ve published a lower level guide to Gears over on my other site: you can view Part 1 here.

The opportunities presented by allowing users to access web applications off-line are huge. In situations where internet access is unavailable, or where connectivity can disappear without warning (such as with certain providers in Ireland), providing a consistent experience to users is important. Simply saying, “you can’t do work now” is not enough for users that rely on an application.

Thinking about potential barriers to (me) relying on web applications for “important” functions, reliability of access is quite high on the list. For certain applications, such as word processing, task management & time tracking, to be “primary use” availability needs to be guaranteed. There is a difference between it being inconvenient when something is unavailable (such as news in your RSS feeds), and it being a big problem (such as losing work because your Internet Connection drops and you can’t save it).

There are a number of ways that this type of offline functionality can be introduced. ReadWriteWeb have published a number of articles on this in the past (linked at the end of the post), including a very good one recently which looked at ways taking web apps out of the browser’s control can be achieved. In it, they linked to a very good video of a presentation on developments with Google Gears (video on Youtube, 54 minutes long) which looks at some of the options when providing offline accessibility in web-based applications.

Gears is an open source project which aims to :

• Let web applications interact naturally with your desktop
• Store data locally in a fully-searchable database
• Run JavaScript in the background to improve performance

One of the most interesting approaches discussed (and one that I hadn’t heard of before) was using functionality provided by the dojo JavaScript toolkit which allows applications to check what local storage options are available (it looks for Gears, Flash storage, HTML5), and use one of them. The options are presented through dojo Storage in dojo Offline.

Off-line web application access can help to overcome some issues facing widespread adoption of web applications. Whether this type of functionality is “sold” as a feature up front, or simply integrated into services to help provide a more complete user experience remains to be seen. As versions of applications that traditionally lived on the desktop make their way onto the web, users will expect to have a similar experience. If the experience is sub-standard, what is the motivation for moving?

Forms of Date Input

“Flat Calendars”

Many websites have relied on representations of “traditional” paper-based calendars, showing rows of days and dates which the user can click.

from Google Calendar

The screenshots above and below show two alternatives for the flat calendar approach: the first (above), displays the calendar on the screen so it is immediately visible to the user when the page loads. The second (below), is a “pop-up”, meaning they rely on user interaction (e.g. clicking on a button or link or in a text box) to make the calendar appear.

from Avis Car Rental

“Drop Down” Lists

A second option is a drop down list style date input. These are most commonly seen in forms where credit card expiry dates are asked for. The use a fixed list of dates, which minimises the chances of a user making a mistake.

from Budget Car Rental (…where I spent some time working long time ago!)

“Natural Language” Approach

The final option I am going to look at is a newer approach. It allows the user to type the date and (or) time into a text box. The application then interprets this and translates it from how the user has phrased it, into an “acceptable” (from a programming perspective) date format. An example of this is shown in the images of the (very useful) web app Remember the Milk.

which the application then interprets as:

Impressive eh?! This is particularly impressive because it promotes a more natural interaction between the system and the user. It does not force the user to rely on one representation of dates and times, instead, it adapts to how the user naturally expresses themselves. This should be the case, as highlighted by Cornelis in an article on the diversity of date input methods:

…it is hard to find any pattern or rationale why one website has chosen for model X [for date input] while the other has chosen model Y. The suspicion would rise that the date input method is often dictated by the way the backend would ‘like’ it. This is a situation which neither we, as interaction designers and consultants, nor the end user should settle for.

The (brief & slightly) More Technical View

Providing functionality like this is obviously much more complex than giving the user a drop down list to select from. There are Open Source JavaScript libraries that can provide much of the functionality for you (finding one of these stopped me from going past the paper planning stage of writing my own JavaScript Library to handle this…thankfully!!). Examples include Date.js (released under the MIT License), and Datetime Toolblocks (released under a modified GPL).

Choosing the best Date Input Option

Given the options, what should be considered when choosing how you ask your users for a date (edit: emm…not that kind of date, you know what I mean). Here are some points, which are all related, to consider:

1. Frequency of use. If the user visits the site / application infrequently, making how the input works as obvious as possible is wise. By providing a flat calendar, that is modelled on paper-based calendars, users do not need to adjust to new types of interaction. If the user visits the application frequently, they may be more responsive to learning how to use novel forms of interaction (if they are of benefit).
2. Trade off between ease of use and speed of use. With some of the date input methods, there is a trade-off between ease-of-use and speed-of-use. While the Remember the Milk model of date input is fast (I find it faster than a flat calendar because you don’t need to use a mouse), for users unfamiliar with it, it is not easy to use initially.
3. Type of user. The profile of your user will impact every aspect of your design; the date input method is no different. If your users technical awareness or skill level is not low, then as simple a means of interaction is required. If they are at a higher level, again more innovative and productive means of interaction can be used.
4. The design of you application. The overall design of the application can be of influence. Sometimes, it is not practical to include a flat calendar on the screen, instead, due to space constraints, or other design limitations, pop-ups may need to be used.
5. Cultural aspects. As date formats differ between countries, for example 10-3-08 means different things to users in Ireland and in the US. Making users aware of these differences, and ensuring that your application is aware of how to handle them is crucial in order to avoid inaccurate inputs.

The usability of any web application should be a key concern in web design & development. Reducing the amount that any user has to adapt, and making interaction requirements obvious, will improve usability. The innovation in date inputs outlined are one such way that this interaction can be improved for certain types of web applications.

www.gerandgus.com

The site itself is built on WordPress, which allows allows the site owners to keep everyone up-to-date with latest news and changes, without having to rely on a web developer. It also allows users to interact with the site owners (useful, because its meant for a group of people that know each other) through comments on blog posts. WordPress is an Open Source blogging platform, or as its developers describe it:

…a state-of-the-art publishing platform with a focus on aesthetics, web standards, and usability. WordPress is both free and priceless at the same time.

The site also uses a number of web-based services to provide additional information to users, and allow people to interact in different ways. Firstly, because the wedding is in the south of Spain rather than Galway, Google Maps was used to help people find their way from the Airport to the hotel. Google Maps provides tools which allows you to customise their maps in different ways. For this site, we customised the map to give both the location of the airport and hotel, as well as using it to calculate the shortest route and give driving directions and an approximate driving time. More details on using Google Maps for these types of services are available from the Google Maps documentation.

The site uses another Web-based service, Flickr, to share photographs. This allows the site owners, and their friends, to edit, label and store their photos in one place, before they are displayed as part of the Wedding Website. Again, this is possible by using the tools provided by Flickr – further details are available from their services documentation (these services are only for non-commercial use; commercial use must be arranged with Flickr). To create the fancy Photo Gallery used to display pictures once they were taken from Flickr, the very easy to use open source Galleria photo gallery (based on JQuery) was used.

Combining Open Source applications and web-based services, with a web design that made everyone happy, resulted an extremely flexible, and very functional wedding website.

I have the wedding to look forward to now….

I’ve spent a bit of time experimenting with the admin-side of the application and the features look impressive so far.  The next step is to take a look at the templating system to see how complex the layouts used are…