Brent Eades writes:
> Am deep in the process of redesigning the Bank's Web site, and am
> wondering how best to do the following:
>
> On each page of the site will be a fairly lengthy text-based navigation
> column running down the left. It will be exactly the same on each page,
> *except* that I want to highlight the currently-selected page/section --
> probably by the usual convention of removing the href tag from it so it's
> not a link:
There are eight million ways to do this, and frankly all of them
have their strengths and weaknesses. Doing it client-side is much
more fraught with peril, so I'd advise focusing on a server-side
solution first, then add-on a client-side solution for those whose
clients support it.
On the server-side question, it'd be trivial to have the SSI exec
a perl script that loads in the links, de-hrefs the current page link,
and prints it. On the other hand, there's a non-negligible delay of
spawning a process, loading the perl interpreter, reading the script
file, etc, for such a small return. Intermediate solutions would be
having a script that generates a navbar for each page and either saves
each in a separate SSI-includable file or inserts them into the static
files.
If you're running a modern web server (like apache) there are a
variety of modules that support PHP or embedded Perl for server-side
scripting. In such a case, the overhead would be trivial.
It's too bad most servers don't by default support a
"boilerplate" SSI function where the SSI is loaded into the cache and
reloaded only when a data file is changed. It would be slightly more
than trivial to build some sort of SSI preprocessor that traverses the
site directory structure, imports "static" SSIs, and saves the file.
On the client side, using a Javascript of some sort to go to the
links table and set the cell background colors appropriately is
probably the best bet.
Some general architecture/navigation advice from my experience on
a fairly large bank site:
The one thing I always wanted to do but could never get a clear
consensus on from upper management was to push all of the concrete
parts of the web site to the main page. Not necessarily to take over
the main page, but to have at least a substantial section that lists
everything concrete you can *do* at the site, like:
apply for a credit card
apply for a mortgage
apply for a checking account
etc.
The tendency seems for large organizations to lose focus, to get
all interested in pushing fluff at the user. Part of this has to do
with typical corporate fuzziness, but another part with a lack of
understanding of the type of interaction. Encourage them to think of
the website experience as a replacement for over-the-counter
interactions with tellers, where unfortunately though the user has a
goal, the teller can't just ask them what it is.
This is just an educated guess on my part, but I'd say that most
users don't arrive a site's main page by accident; nor do they arrive
because they're randomly surfing different banks, wondering which one
is best for them. Most of the time they arrive looking for something.
It'd be nice if a web site could have a natural language parser that
could carry on a dialogue (this is on my projects list :-) but it
can't. Most of the time the "design" of the site - the layout of each
page and the architecture of all of the pages - simply can't
anticipate what the user's desires are(*).
(* This results in large part because of a combination of three things.
1) lack of design skill on management's part,
2) lack of concrete, measurable, usable user data and demographics, and
3) lack of willingness to spend anything on getting the above.)
However, most of the time there aren't really that many "real
things" that the site can do. The list of services is really quite
short, though the brochureware surrounding and obscuring them can be
quite extensive. The list of questions a user might ask are infinite.
The list of real things you can provide are quite finite. Which is
easier to figure out?
Think in terms of a FAQ. The reason FAQs work so well is because
they are quite simple and task-oriented, and because they
traditionally evolve over time; the structure of the FAQ is based on
recurring user questions. This is the brute force approach to
usability engineering. It works, but you don't have that sort of
time, nor the infrastructure to support it(*). Instead, it's simpler
to list the things that the user can really do, with links to a
"shortcut" page for each thing.
(* You should be talking to your bank's consumer help desk about
setting up infrastructure to respond to email requests; make sure
you also set up procedures for the web team to learn from the
requests and improve the site. The ultimate would be real-time
chat response for lost & confused users, where the chat service
would have knowledgable "tellers" who know and understand all the
material and are responsible for helping formulate site refinements
to cut down on future questions. It'll never happen, but it's nice
to dream...).
The shortcut page should summarize, in one short paragraph, what
the thing is, with links to explanatory material and the actual forms.
If the user has been here before, the shortcut page should let them
quickly zip to the section where they start filling out the data.
Think of the shortcut page as a "view from above" of the section. All
told it should be one screen at most.
Steven J. Owens
[EMAIL PROTECTED]
____________________________________________________________________
--------------------------------------------------------------------
Join The NEW Web Consultants Association FORUMS and CHAT:
Register Today at: http://just4u.com/forums/
Web Consultants Web Site : http://just4u.com/webconsultants
Give the Gift of Life This Year...
Just4U Stop Smoking Support forum - helping smokers for
over three years-tell a friend: http://just4u.com/forums/
To get 500 Banner Ads for FREE
go to http://www.linkbuddies.com/start.go?id=111261
---------------------------------------------------------------------
