Reinventing the wheel
September 18, 2000
Personalization is nothing new to computing. Of course, desktop applications
have been providing "preferences" features for years. But for most
of us, the web has been an exercise in 'back to the womb' regression
therapy, with our computers wound up in the fetal position as we
re-experience most of the techniques that have already matured in the local
operating system environment.
Search engines have long offered a simple staple of web-based
personalization, a drop down menu where you can choose whether to view 10
or 20 or X results per page. Herein lies the bedrock principle behind
personalizing techniques: "I, the server, am going to dig up a bunch
of data to deliver to you; please tell me how you would like it
delivered." A worthy goal, indeed, as we remember that a server really
is supposed to serve us.
Early search engine personalization suffered a serious flaw, though. Each
time you visited the site, you had to select your preferred result size
again. The site had no way to remember what you personally liked, a feature
that we've long taken for granted on the desktop, since our applications
can save our preferences on the hard disk. In fact, the situation is worse
than that -- the web, or the
HTTP
protocol specifically, is stateless
in nature. This means it has no memory at all, and can't even remember
anything from one web page to another.
E-commerce
led the way in developing techniques to work around the
inherently stateless nature of the web. When you visit a favorite on-line
retailer, you may not want to re-enter all of your personal information for
each purchase. Retailers knew that it would be easier to attract consumers
by smoothing this process. It's become de rigeur for retailers' web sites
to 'remember' your name, address, and sometimes even credit card information
which you can access using a unique login/password combination. In fact,
Amazon.com so fully automated their form of personalization -- which they
named the "one-click purchase" -- they proudly filed for a patent
for the technique. Great controversy swirled around the granting of this
patent, in large part because the technology relies on well-known techniques
which are mostly contained in this article alone.
But personalization isn't just for shopping. The search engine AltaVista
spun off a new search interface called
Raging Search
that offers a high degree of personalization, some functional, some
purely aesthetic.
The State of Statelessness:
Cookies
Achieving "state" (or perhaps "statefulness"?) is part
of the personalization equation; using that information, carried from user
session to session, in modifying the behavior of your scripts is the second
part of the equation. First let's consider some techniques for maintaining
state -- personalization information across pages and sessions -- and in
our examples by the end of this article we'll use some of this information
to modify the behavior of a Perl script.
From a programming point of view, one of the easiest ways to store
personalization information statelessly is to rely on cookies, a
now-infamous technology pioneered by Netscape. A cookie is really quite
simple: a key-value pair stored on the visitor's computer, with information
tying the data to the site that created it. When the browser re-visits a
site that issued cookie data, the cookie data can be retrieved by the site.
In essence, cookies let your web site leave a 'tag' on someone's machine,
and you can pick that tag up at a later date, allowing you to 'remember'
information over time.
An unfortunate emulsion of misunderstanding and abuse has given cookies a
suspect reputation in some people's eyes. Savvy web sites can deploy cookies
in ways that help them piece together the browsing behavior of users who
visit certain sites. Fans of the X Files worry about what this information,
if collected, reveals about them (very little, really, since the data is
only useful in aggregate). Consequently, it's considered good ethics to
advise visitors when and why your site uses cookies. There are also some
good practical reasons not to use cookies, but more sophisticated methods
of statelesness instead, which we'll discuss shortly.
The main advantage of using cookies is that they're simple to program, thus
speeding development time.
Cookies also suffer from several disadvantages.
- One, as we mentioned are the social/ethical/perception issues
surrounding their use.
- More tangibly, cookies have a limit to how much data they can hold.
- Most significantly, though, cookies lack portability: the statefulness
of cookie data is tied to an individual computer, rather than an
individual person. When that person visits your site from a different
computer, they have no access to their personalization settings.
Despite these factors, we'll look concretely at using cookies in the final
section of this piece. We'll also see that they still have their uses, even
if not an all-in-one solution.
The Perl You Need to Know Part 17: Personalization Methods Part 1 With a look at Cookies
The Perl You Need to Know
Statelessness Sophistication
|
