Some of the Web technologies we use
are very unreliable, mainly due to the
way the various browsers handle them, or
don't. Thankfully, the problem is
decreasing because of the general
adoption of version four or five
browsers, but it is unlikely to go away
entirely.
As designers, we have to decide whether
we are going for the lowest common
denominator - ie any browser, or the
majority of browsers. It makes little
sense to target one particular browser
except in a controlled intranet
situation.
This all comes down to identifying the
target audience. Are they 'general
public' or a more closely defined group
of people? The subject of the site
usually dictates this. A site that
publishes train or plane timetables
should be accessible from a mobile phone
or PDA device, and the 'browsers' in
such equipment will the very most basic.
To use, say, Java applets on a general
public site is immediately alienating
some 20% of possible visitors. Flash has
good penetration as far as plug-ins go,
but there are still a very significant
number of people who can't, or won't use
it. There are even people who surf with
their basic graphics switched off.
In an ideal situation, a site should
still be usable without plug-ins,
JavaScript, Flash, Java, Cascading Style
Sheets etc, these being used merely to
enhance the site for the people that can
use them.
It comes down to a choice of whether you
use good ol', plain vanilla HTML and
reach everyone or introduce another
element which enhances the look and
functionality of the site, but at the
expense of losing potential customers.
This is a design decision that should
not be taken lightly!
Ah, frames. You either love them, or you
hate them!
Although the concept has been with us
for some time, there are people who use
them quite happily and others who, hands
raised, back away in mortal fear.
One of the main excuses for not using
them is that some browsers can't handle
them. That may have been true in the
past, but those browsers are in such a
minority now they can be safely ignored
- unless, of course, you know that a
significant proportion of your readers
are using old browsers or surfing on
mobile phones!
Then there are people who don't really
understand frames and made an utter mess
of designing a framed site. Admittedly,
it takes a little more skill, knowledge
and effort to produce a successful
framed site and if you do feel the need
to produce a parallel <noframes> site as
well, it will ultimately cost the client
more.
Used well, frames should be unobtrusive.
If you are aware of them, then there is
probably something wrong. You've seen
those sites where the window has
horizontal and vertical scrollbars on
every frame and ones which recurse on
one another so that you get frames
within frames within frames... These
things shouldn't happen, it just takes a
little understanding.
Just like tables, the borders of frames
are best hidden in most instances.
Borders are like the scaffolding on
buildings, fine during construction, but
should be removed when the work is done.
Table and frame borders have a
utilitarian look about them making the
pages look 'homespun' and unprofessional.
Scrollbars are necessary when a page's
content overflows the frame but if you
are in control of your design efforts,
you should try to keep visible
scrollbars to the absolute minimum.
Apart from cluttering the look of the
screen, they nibble away at that most
precious commodity - screen real estate.
If you switch-off scrollbars, you are
effectively fixing the frame size and
anything inside it that doesn't fit will
be clipped. Just remember that text
changes in size from one user's machine
to another depending on their platform,
browser and personal preferences.
Graphic images are always a predictable,
absolute pixel size. If you put only
graphics in frames, there is little
chance of accidental overflow. If you
put text in a frame, you can, at least,
restrict its width using a table - so
you only get a vertical scrollbar.
Frames offer several advantages to
designers.
The basic concept allows some frames to
remain static whilst others change. You
might, for instance, want a common top 'banner'
frame and a side navigational frame on
every page and only one 'content' frame
which changes. Providing that you get
your 'frameset' right to start with,
this is good from the user's point of
view as it simplifies navigation and
usability.
Using frames also has the major
advantage of allowing you to pass
JavaScript variables from one page to
another. The only other way to do this
is to use cookies, but the general
paranoia about infringement of privacy
means that many people switch off the
acceptance of cookies leaving your
efforts high and dry.
For most purposes, it is only necessary
to have two or three frames. Each
individual frame requires a separate
HTML file and these are all
choreographed and stage-managed by a
master page called the 'frameset'. The 'frameset'
specifies the position and size of the
frames and the names and locations of
the HTML files that will initially
occupy those frames. It can also specify
what happens when the browser doesn't
support frames by using the <noframes>
tag.
Here is a summary of the advantages and
disadvantages of frames.
