Usability, RIA, and GWT - 6 Questions to Ask your Users

March 25th 2010

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,, 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. “”), 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., 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 in GWT could now be 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.


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!

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (5)
Casper Bang
March 26, 2010
+1. You should write another piece, this time on GWT authorization and authentication. It baffles me why such an important item is not build into GWT.
Eric Jablow
March 26, 2010
About item 2 on history navigation, you might want to consider the approach used in the gwt-presenter library on Google Code, where its place manager system routes references to
, and;brand=Reebok

to the same ‘presenter’, but through a method that allows the presenter to handle the brand option before placing data into the view.
March 26, 2016
Thanks Casper. Funny you mention that, because we’ve spent a lot of time thinking about GWT and authorization…and I think it would be a good idea for a next post, so stay tuned!
Great suggestion, Eric. On a recent project we rolled our own simple MVP framework, similar to gwt-presenter. I like how they manage parameters though (e.g. “brand=Nike”)…their PlaceRequest seems to make this very easy. Thanks for the comment!
Alexander Thiel
March 29, 2010
You may be interested in Restful GWT too for easy history management :
Any feedback appreciated !
March 30, 2010
We’re transitioning from a web 1.0, form-based approach for our application to one built using GWT, and these are some excellent questions to ask before starting such a project.