D
David Mark
As recently discussed to death in another thread, there seems to be a
lot of confusion about fragments, states and the end-users' ability to
share links.
First off, fragment identifiers have nothing to do with state. Each
indicates a separate address.
<div id="bylocation"> ... </div>
<div id="byinput"> ... </div>
<div id="bysomethingelse"> ... </div>
Links within the site may reference these fragments like this:
<a href="page.html#bylocation">By Location</a>
<a href="page.html#byinput">By Input</a>
<a href="page.html#bysomethingelse">By Something Else</a>
Now, one popular enhancement is to show just one DIV at a time and to
style the links as tabs. Fair enough, but this *requires* preventing
the default click action (which is what the W3C forgot to do on their
validator page.) Doing so will prevent the location from changing
with the tabs (typically not a big deal.) Failure to do so will break
the back button (or set you down a long winding road involving timers
and/or non-standard listeners.) That's a huge deal and a self-
defeating end-around.
The perceived big deal about the location is that Web-savvy users will
not be able to paste links to individual tabs in emails, chat rooms,
etc. If a design absolutely requires enabling such actions, there is
certainly an easy solution that has been around as long as the Web and
is guaranteed to work in any usable browser. It doesn't require a
line of script either. Use queries:
<a href="page.html?bylocation">By Location</a>
<a href="page.html?byinput">By Input</a>
<a href="page.html?bysomethingelse">By Something Else</a>
Hard to believe you were just one character away ("?" rather than
"#".) But omigosh, that will refresh the whole page! Yes, that
brings us back to the standard "Web 2.0" paradox. Adding huge scripts
and unload listeners makes for a miserable (and inefficient) browsing
experience. As our solution requires no script at all and it has been
explained how to avoid unload listeners for all occasions, fast
history navigation comes into play. Navigating forward or back within
the site happens *instantaneously*, preserving the *entire* state of
each document and the server is completely oblivious (zero hits per
navigation.) Bookmarks work perfectly (of course), as do all of the
other standard browser features like "Send a Link."
Not "cool" or Ajax-y enough for you? That's life. The typical Ajax
site hits the server constantly on navigation, preserves nothing of
the departed pages, requiring long delays each time the forward or
back buttons are used (which is quite often in a typical browsing
session.) You don't need a room full of "usability experts" to tell
you which solution is preferable to users, not to mention server
administrators and the people who pay for all of this (bandwidth is
not free.)
On a semi-related note, consider a map page, which is less likely to
work with such a scheme (though it is certainly not an
impossibility.) The stated desire in the other thread was to allow
users to easily share links. The end-around presented can only serve
to make the standard browser features work in a new (and potentially
confusing) manner. That's hardly a compelling interface; in fact,
it's a complete cop-out. If you consider the many ways that bookmarks
are exchanged on the Web today, it should be clear that a "Share"
button that invokes a dialog provides a world of possibilities that
are not part of the standard browser bookmark interface. A custom
interface (probably a wizard of some sort) allows for branding and
activity tracking, not to mention plenty of screen real estate to show
off your newfound Ajax abilities. No email client is required, so
Webmail, kiosk and cafe users are covered. It's a no-brainer compared
to no interface at all. I'm sure groups as diverse as users,
administrators, marketers and venture capitalists would all agree.
Having recently worked on just such an interface for a client, I'm not
going to provide any more details. Needless to say, mutated locations
with fantasy hashes were not used (and were never considered AFAIK.)
And as for the somewhat unrelated issue of preserving the *states* of
dynamic documents between sessions, that is done with cookies or SQL.
The latter is part of HTML5, just like the much cited hashchange
event. Unlike the event, support for SQL is trivial to detect. It
was brought up that a cookie adds weight to requests. Does it take
more or less characters to send a number (e.g. a ZIP code) than a
tacked-on hash? In any case, the difference is minimal (certainly
insignificant for today's sites) and thus irrelevant to the design.
When you consider how few requests are made when browsing a
competently designed site (without unload listeners to screw up
navigation), this particular issue evaporates like the rest.
Alternatively, you can look at incompetent designs on the Web, guess
that some room full of smart people signed off on them after furious
study and assume that copying their antics will lead to better sites.
I doubt Google's "engineers" asked anyone about the usability of
broken back buttons or javascript: links. Like most Web designers/
developers, they are simply too incompetent to be believed (perhaps
that's the sticking point.)
lot of confusion about fragments, states and the end-users' ability to
share links.
First off, fragment identifiers have nothing to do with state. Each
indicates a separate address.
<div id="bylocation"> ... </div>
<div id="byinput"> ... </div>
<div id="bysomethingelse"> ... </div>
Links within the site may reference these fragments like this:
<a href="page.html#bylocation">By Location</a>
<a href="page.html#byinput">By Input</a>
<a href="page.html#bysomethingelse">By Something Else</a>
Now, one popular enhancement is to show just one DIV at a time and to
style the links as tabs. Fair enough, but this *requires* preventing
the default click action (which is what the W3C forgot to do on their
validator page.) Doing so will prevent the location from changing
with the tabs (typically not a big deal.) Failure to do so will break
the back button (or set you down a long winding road involving timers
and/or non-standard listeners.) That's a huge deal and a self-
defeating end-around.
The perceived big deal about the location is that Web-savvy users will
not be able to paste links to individual tabs in emails, chat rooms,
etc. If a design absolutely requires enabling such actions, there is
certainly an easy solution that has been around as long as the Web and
is guaranteed to work in any usable browser. It doesn't require a
line of script either. Use queries:
<a href="page.html?bylocation">By Location</a>
<a href="page.html?byinput">By Input</a>
<a href="page.html?bysomethingelse">By Something Else</a>
Hard to believe you were just one character away ("?" rather than
"#".) But omigosh, that will refresh the whole page! Yes, that
brings us back to the standard "Web 2.0" paradox. Adding huge scripts
and unload listeners makes for a miserable (and inefficient) browsing
experience. As our solution requires no script at all and it has been
explained how to avoid unload listeners for all occasions, fast
history navigation comes into play. Navigating forward or back within
the site happens *instantaneously*, preserving the *entire* state of
each document and the server is completely oblivious (zero hits per
navigation.) Bookmarks work perfectly (of course), as do all of the
other standard browser features like "Send a Link."
Not "cool" or Ajax-y enough for you? That's life. The typical Ajax
site hits the server constantly on navigation, preserves nothing of
the departed pages, requiring long delays each time the forward or
back buttons are used (which is quite often in a typical browsing
session.) You don't need a room full of "usability experts" to tell
you which solution is preferable to users, not to mention server
administrators and the people who pay for all of this (bandwidth is
not free.)
On a semi-related note, consider a map page, which is less likely to
work with such a scheme (though it is certainly not an
impossibility.) The stated desire in the other thread was to allow
users to easily share links. The end-around presented can only serve
to make the standard browser features work in a new (and potentially
confusing) manner. That's hardly a compelling interface; in fact,
it's a complete cop-out. If you consider the many ways that bookmarks
are exchanged on the Web today, it should be clear that a "Share"
button that invokes a dialog provides a world of possibilities that
are not part of the standard browser bookmark interface. A custom
interface (probably a wizard of some sort) allows for branding and
activity tracking, not to mention plenty of screen real estate to show
off your newfound Ajax abilities. No email client is required, so
Webmail, kiosk and cafe users are covered. It's a no-brainer compared
to no interface at all. I'm sure groups as diverse as users,
administrators, marketers and venture capitalists would all agree.
Having recently worked on just such an interface for a client, I'm not
going to provide any more details. Needless to say, mutated locations
with fantasy hashes were not used (and were never considered AFAIK.)
And as for the somewhat unrelated issue of preserving the *states* of
dynamic documents between sessions, that is done with cookies or SQL.
The latter is part of HTML5, just like the much cited hashchange
event. Unlike the event, support for SQL is trivial to detect. It
was brought up that a cookie adds weight to requests. Does it take
more or less characters to send a number (e.g. a ZIP code) than a
tacked-on hash? In any case, the difference is minimal (certainly
insignificant for today's sites) and thus irrelevant to the design.
When you consider how few requests are made when browsing a
competently designed site (without unload listeners to screw up
navigation), this particular issue evaporates like the rest.
Alternatively, you can look at incompetent designs on the Web, guess
that some room full of smart people signed off on them after furious
study and assume that copying their antics will lead to better sites.
I doubt Google's "engineers" asked anyone about the usability of
broken back buttons or javascript: links. Like most Web designers/
developers, they are simply too incompetent to be believed (perhaps
that's the sticking point.)
