If you’re moving an application to the web, there are a lot of things to keep in mind when designing and testing it. Most of them, however, ultimately boil down to two things: user expectations and user experience. When using a browser, users will have certain expectations of how windows act and how to navigate the application that won’t be the same as a desktop app. The user experience will also be different; there are a lot of things that you can do in a browser that you can’t do in a typical desktop application (and vice versa). These considerations can be seen when you look at specific functionality, as well as looking at the general ways that you access the application.
In a desktop application, users have defined paths that they follow through an application – paths that you can very closely control. With a web application, however, the user has as many options to get somewhere as the browser has ways to navigate. They can proceed through the expected workflow, they can link directly to a page, they can load the bookmark of a page, they can use the back, forward, and refresh buttons, they can load the page from browser history, and more. All of these options have to be tested to ensure there are no holes in your security or errors in your functionality.
A specific variation of this is that in a desktop application, locking a user into a single page (i.e., a modal window) until they finish or cancel may be commonplace as part of a standard workflow. In a browser, this is simply not possible. You have to consider that a user may abandon a workflow at any time to go elsewhere in the application, and then attempt to jump back in halfway through the workflow by click the “Back” button. Any portion of your application that you can link to will be linked to by a user, and this behavior has to be taken into account by your system. They may even have the same page open in multiple tabs, and the system has to be able to handle it.
Another specific issue is that in a desktop application, users are much more accepting of windows opening and closing on a regular basis. New windows giving you a bit of information that stay open until you close them, or opening the details of an item and then closing the window before you move on are commonplace and acceptable in desktop apps, but would be extremely confusing and unfriendly in a web app. Users expect the vast majority of links in browsers to change the content of their current window, not open a new one. This can have a particular impact on lists of items, in that it makes saving your filters and location in a list a lot harder; you can’t just keep the list open in a separate window while you edit the details of a specific item. However, users will expect you to make the list work regardless, so it’s something you have to consider a lot more carefully in a web app than in a desktop application.
There is also the simple fact that while you’ll often only have one way to view a desktop application, the multitude of web browsers (e.g., IE, Chrome, Safari, Firefox, etc.) means that there are many ways to view the web apps. Unless you’re able to set firm usage rules up front, your users will expect to be able to use their personal favorite browser to access your application, and if you don’t take that into consideration, you’ll end up with unhappy users. Different browser options can, of course, cause all sorts of new issues for your application. What looks good in one browser may not in another and functions that work in one browser may cause errors in another. The multitude of browsers also means that something that’s secure in one browser may not be in another. Ultimately, your design may not change because of browser options, but your testing most definitely will as your test plan expands to cover all of the supported browsers and their versions.
To be continued… (Read Part II Starting 26-Feb)