The User Makes the Rules
Users have deep-rooted expectations about the semantics of "back" and "reload." "Back" means "show me what I was looking at before I was looking at this." "Reload" means "show me the present state of the content whose past state Im seeing right now." When designers dont respect these conventions, users become confused and transactions are derailed.
For example, I was expecting a UPS package to arrive at my home one morning, based on tracking information from the UPS Web site as of a few days before. Id kept the Web page detailing package progress open on my desktop, reloading a few times each day to see if things were moving along.
When I clicked the "reload" button, the date-time stamp on the page would change, suggesting up-to-the-minute information—but my package, supposedly on track for West Coast delivery that day, was still shown as sitting in Kentucky. I called UPS, and a representative told me that my package was on a truck in my neighborhood as of that morning.
That seemed odd: After all, we were both looking into the same database. I tried hitting my browsers "back" button (taking me to a status summary page) and then reclicked that pages link to "View package progress." Voilà! Suddenly, the progress was fully shown, confirming departure from my local delivery depot at dawn.
Id be a dreadful curmudgeon if I didnt accentuate the positive here. After all, Id been able to track the item that I was expecting—a piece of gear being repaired—all the way through the service process merely by entering my phone number on a Web page. When the service center shipped my gear, its Web site displayed a tracking number that linked right into the UPS system. If Id merely believed UPS projected date of delivery, rather than digging for details, I would have been accurately informed. Theres much more right than wrong with this picture.
Even so, something is wrong with a Web site that mimics the act of reloading but does not actually update the content that the user most wanted to see. Thats not the users mental model of "reload," and I have to wonder if there are similar gaps between mental model and reality in developers expectations of Web services APIs.
You see, I dont really want to click "reload" at all. What I want from next-generation IT is an always-on view of what matters to me: My expected deliveries are here, my children (based on their cell phone locations) are there. My next appointment is across town this soon, at a location that will take me this long to reach with current traffic conditions. My next eWEEK deadline is too soon, for an assignment that will probably take too much time to write based on this mornings updated page-layout plan—after a meeting in this many minutes with these people about this project involving these documents and messages. My future desktop and handheld environments will have to be consistent and intelligent in obtaining and relating current information from all these varied sources.
Unless, of course, I dont want current information but actually want to see exactly what I saw before—for example, when auditing a decision process to see who knew what when. When I click "back," should I see the previous cyberspace location as it was or as it is? I see both behaviors at various sites, and as pages become more active thanks to AJAX-style (Asynchronous JavaScript and XML) interactions, the meaning of "back" is becoming ever more slippery.
It would be useful, it seems to me, for "back" to mean "show me what I saw before the last action that I took" combined with "tell me if whats at this location has changed since I saw this view." Would this be difficult? Yes. The alternative, though, is user confusion now and Web stagnation tomorrow.
Peter Coffee can be reached at peter_coffee@ziffdavis.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
