Sessions must die
Many e-commerce sites have session timeouts. Dawdle too long between the moment you enter the site and the moment you actually want to buy something, and you will be presented with an unpleasant message. The words “session timeout” will be there, drowned in a sea of technobabble, and you will have to restart from scratch. Using a bookmark will often have the same effect.
At this point, you may well be tempted to go shop elsewhere; indeed, it is the only principled response to such blatant contempt for customers. You will notice that successful sites like Amazon.com do not make their customers suffer such hassles – once you’re in, you are in, whether you have to take a lunch break or not. I don’t buy the security argument either – there is nothing sensitive about the contents of a cart, security belongs at checkout time, not browse time.
The reason why such crimes against usability are perpetrated is that business requirements too often take a back seat to technical expediency, paradoxically most often due to lack of technical competence. Many web development environments keep track of what you do on a website, the contents of your cart, and so on, in “sessions”, portions of memory that are set aside for this book-keeping purpose. They cannot be set aside forever, and must be purged to make room for new customers.
The tyro programmer will leave the default policy in place, which is to dump the session altogether and place the burden of recovering state on the customer. More experienced programmers will implement the session mechanism in a database so it can be kept almost indefinitely. In an era where disk space costs a dollar or two per gigabyte, and a desktop computer has enough processing power to crunch tens of thousands of transactions per minute, there is no justification for not doing so.