The Web-browser actions of "back" and "reload," along with a history of visited locations, have become widespread user interface metaphors. Browser-style buttons invite us to explore file systems, review online documents and access digital media—whether or not were on a network and whether were viewing resources that are local or remote. It figures that just as we reach the point where everyone knows how these things work, the content creation community is changing 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.
Guru Jakob Nielsen offers advice on designing applications for usability.
Click hereto watch the video.
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.
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 email@example.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.