It’s very tempting, given the power and ease of GWT, to jump in head-first and start building flashy new RIA applications for your customers right away. Slow down! Although I’m not generally an advocate of big design up front (BDUF), there are a few usability requirements that I think you’ll want to understand before you start coding – requirements that will fundamentally shape how you design your client-side GWT architecture, and therefore minimize re-work later.
So, toward the goal of evoking usability requirements, here are 6 important questions to ask your users or business owners:
1. Should the back button be supported and in what capacity?
By default, to the end user, a GWT application will just be one URL (for example, www.myshoestore.com/index.html), and so clicking “back” will just redirect the browser to the previous site visited (which is extremely frustrating). For most applications, this won’t cut the mustard – users will need to keep their trusty friend the back button in some capacity.
The good news is that GWT provides a very simple mechanism, via the History class, to append tokens to the end of the URL (e.g. “www.myshoestore.com/index.html#FindShoe”), in effect creating virtual “pages” or navigation points within the application. Clicking back, using this solution, will revert the browser to the previous token, not the previous site (although it’s on you, in your code, to refresh the state of the application to correspond with the changed token).
The tricky part here, in my experience, is not the implementation, but rather defining with your users where these navigation points are within your application. Remember that this is RIA, so anything’s possible – navigation points can be as fine grain as needed. For example, a user could expand a node in a tree widget, click back, and the app could “un-expand” that node. This might be unnecessarily fine-grained, but it is possible. Most likely, however, navigation points are more coarse grain, for instance different “views” in your application (like in Gmail with the “Inbox” view, the “Compose” view, etc.).
Whatever the decision, it’s critical to define where these points are up front so that they can be built into the application framework.
2. Which screens can be bookmarked?
It’s often the case that users will want to share “places” within your application with others, and while coding for back button support (see above) will take you a step in that direction, it won’t get you all the way there. For instance, if a user does a search for “Nike” and the token “#SearchShoe” is added to the url (e.g. http://www.myshoestore.com/index.html#SearchShoe), when the user shares this URL with a friend, there will still not be enough context in the URL itself to let the application know to load not just the “Search” page but also with the “Nike” result set.
The solution here is to use tokens in the same way we used the query string in traditional web applications – so what used to be http://www.myshoestore.com/search.jsp?shoe=Nike in GWT could now be http://www.myshoestore.com/index.html#SearchShoe-Nike. Again, using the History class, the token “SearchShoe-Nike” would be read, parsed, and the appropriate search result would be loaded. Again, like with back button, the difficulty is not necessarily in writing this code, but understanding up-front which views in your application are “bookmarkable”, and ensuring that your framework supports this.
3. Which widgets will you support?
GWT out of the box comes with a rich set of widgets (trees, grids, menu bars, etc.) that alone will be a huge improvement over the clunky, static HTML components of the traditional web application (think text boxes, buttons, checkboxes, etc.). Oftentimes these will be all you need, but in some cases users will want more.
Fortunately, a number of very utilitarian, high-quality, and flashy open source and commercial widgets are available – things like calendars, charts, or drag-and-drop, etc. Beware, however, because this extra UI bling comes at a price. Off-the-shelf widgets can degrade performance, add application complexity, decrease UI consistency, and cause license problems. In my experience, it’s important, up-front, to assess the general UI needs of the users, identify the definitive set of widgets that will be supported within the application, and then stick to it.
In many cases, trade-offs will have to be made. For example, in a recent project, despite its power and pizzazz, we decided against leveraging GWT-EXT since we perceived the costs to complexity and performance to be too high for our relatively small application. Again, designers, users, and even developers will probably want to take an ala carte approach (a widget from here, a widget from there), but it’s important to keep the big picture in mind, and get everyone on the same page as soon as possible with respect to which widgets are in and out of bounds.
4. Is Internationalization a requirement?
GWT has excellent support for internationalization, but as with any other application, this is a non-functional requirement that is absolutely crucial to know up-front. Externalizing presentation text after the application has been built is time-consuming, risky, and generally not good for your constitution.
5. How will input validation behave?
Most every enterprise application validates user input to some degree, and as any developer knows, this can be done in any number of different ways. For example, in traditional web applications, it was most common that a user would enter all of the data, submit the form, and then the system would check the input and inform the user of any validation errors. Obviously with RIA a richer set of interaction patterns are possible – for instance, data can be validated “just-in-time”, as the user enters it, rather than waiting until the entire form is submitted.
Whatever the right interaction pattern is for your application, it’s important to define this up-front as well, and stick to it for all screens. Knowing how validation should behave will help you pick or design the right validation framework (GWT does not come with validation out of the box but there are open source libraries), and will help ensure that input is validated consistently across your entire application. Failing to do so, and therefore letting developers determine how to validate input on their own screens, is a recipe for complexity, redundancy, and inconsistency.
6. What happens on asynchronous calls?
GWT is obviously based on an AJAX model, making many asynchronous calls via Javascript rather than synchronous page loads. It’s important to know, however, the expectations of the user while these asynchronous calls are being made. Is the entire application frozen until the call returns? Or is the converse true, and the user can still some pieces or components? Which pieces? Should the user be able to cancel an asynchronous call (and what would this mean)? Should a “Progress” bar be shown? And so on.
Because asynchronous calls are the backbone of a GWT application, it’ll be helpful to understand their usability requirements early. In a previous project, we implemented a custom AsyncCallback class that showed an “in progress” modal dialog box whenever an asynchronous call was made to the server. This obviously wouldn’t suit all needs, but it worked for our users.
Conclusion
In conclusion, while definitely not an exhaustive list, I hope these questions at least sparked some thought as to what types of things you’ll want to ask your users and business owners prior to jumping into your GWT code.
And of course I’d love to hear any suggestions or experiences you have. What usability questions would you suggest asking users up front? Please share. Thanks!
