 |
|||||||||||
|
|||||||||||
Intranet Applications Face a Design Challenge |
||||||
|
Many builders of application packages for intranets fall into the trap of assuming that their application becomes the center of any interaction that uses it. This ignores the idea the user and their perceptions should actually be the focus. The truth is that many application designers have had to overcome a number of difficulties when it comes to building things for the web. First of all, the web offers much less control over the rendering of an application screen, with the web browser, its version, and even user-controlled settings greatly influencing the size, placement, and behavior of various components. Another issue is the difficulty of tracking and maintaining "state" since browsers were originally conceived simply to view a series of hyperlinked documents. Many of the types of applications found on intranets have their roots in either terminal-based input forms or client-server architecture. And while web application packages to make use of hyperlinks, many applications still do not deal well with the implications of the hyperlink. Take, for instance, a popular application for writing employee performance reviews. Its screen format offers a navigation bar on the left side, with some context specific navigation links along the top. The application is fairly easy to use and offers a number of features to help the review writer by suggesting text and checking language for possible legal issues or poor wording. But the application does not offer the ability to provide contextually appropriate links from each screen to content that is specific to a particular company's process. This means that in implementing the application as part of an intranet, users cannot be offered specific advice on how to proceed in each section. Another, even more troublesome, issue is found in trying to link to an intranet application. Sure, creating a link to an application is easy. But many packaged intranet applications offer only the ability to link to a login screen or to a top level menu. From there, users can make a selection among various functions within the application. This seems to simply follow the model of many desktop applications. The problem is that many of these applications offer functions that are related mainly by the backend system driving them. The functions themselves may be only loosely related, meaning that navigation to the application may come from multiple areas within a typical intranet. Without the ability to link to a specific function within the application, the user must navigate twice. They must first use the navigation provided by the intranet to get to the appropriate area, then navigate within the application to the exact function they seek. For example, an online payroll management package, that mimics the format of the traditional pay stub, also offers a method of checking one's vacation balance, accrual rate, and recent deductions from the paid time off balance. If we consider navigation from the viewpoint of the employee, pages that discuss vacation policy or outline the procedure for requesting vacation would seem to be very natural locations to provide links to this employee-specific vacation information. After all, it is likely that an employee seeking information about vacation related topics is trying to complete a task concerning their own time off, either past or future. The problem is that any such link to this particular application can only deliver the user to a login screen for the payroll application. Upon login, the user is offered menu of choices, one of which is related to vacation balances. This just doesn't make sense. Why should an employee be forced to indicate twice (by their selections) that they would like to see their vacation balance? If we examine common internet interactions a better model can be found. For instance, many authors and others offer book suggestions along with a link to purchase the book from Amazon.com or other book vendor. Clicking such a link will deliver the user to an entry for that particular book on the book vendor site. This has become a common practice on the web. Imagine the confusion that would be caused if such a link simply delivered one to the Amazon.com home page. In fact, noted usability authority Jakob Nielsen mentions the importance of deep linking in a recent Alertbox article. Confusion is sure to result when an employee has selected a link that says "Check your vacation balance," only to be faced with a login screen and a menu of several different choices. Making a user choose two links in succession that essentially promise the same thing reduces the chances that they will be successful in their original task, and leads to greater frustration with the experience. These problems exist, in part, because many application builders are still transitioning from a desktop or client/server application background. The natural start for many desktop applications is simply the opening of the application. In fairness, the techniques that lead to the best user experience on the web are still being discovered and formed. But another factor that has influenced the design of applications for the intranet was "The Great Portal Craze." Don't get me wrong. The idea of organizing information and interactions in one place for simple, useful navigation is marvelous. But we seemed to go through a period in which any company offering an application that was web enabled suddenly decided that their application should become a portal. There were a couple of possible reasons for this. The first was simply the buzzword power of the word "portal." For a period of time a couple of years ago, it was nearly impossible to find a computing trade magazine, conference, or web product brochure that didn't mention "portal" at least once. The second possible reason for the "portal craze" is that many vendors saw the sales leverage that could be gained if their product (or suite of products) actually became the starting point for interactions. By becoming "the portal," a company could expect sales of additional products as companies expanded the range of interactions offered. After all, why not take full advantage of all solutions offered by something that has been essentially chosen as a foundation? The net outcome, however, was that many builders of web applications seemed to begin their design process with diagrams and whiteboard drawings that assumed that the first user action was to enter the application. All action followed from there. This arrogance completely ignores the reality that a user may have traveled through several links just to arrive at the application, with each link refining an idea of what is to be found there. So how do we solve this problem? Well, I have a couple of suggestions. First of all, if you build intranet focused applications (either internally, or as a business) change your approach to enable informational links from your application pages, and make it possible for others to link directly to a specific place within the application. This means not only the ability to link to an area, but the ability to link to a specific record as well. If you need to prompt the user for a username and password along the way, that is fine. Just please don't send that user to a generic top level menu for your application. Second, if you manage an intranet site, add this functionality to the list of "must have" features for any application you buy or rent. If enough folks start asking for these important features, they will eventually become the standard. And when you ask about the possibility of linking to a specific function or record within a web application, pay careful attention to the answer. If the answer is, "Well, you could do that, I suppose," then it's time to dig a little deeper. Also, let's try to convince the builders of intranet applications that their products are not the center of the universe. For an intranet, the center should always be the employee. |
|
|||||
|
|
