Fragments, states, bookmarks, navigation, etc.

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.)
 
O

optimistx

David Mark said:
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.)

Thanks for your opinion, interesting. When I as a newbie do not naturally
recognize experts and
"experts" in Javascript, it would be nice to have names or nicks of some
real experts (in addition to you, of course) to learn of their scripts and
articles instead of "experts".
 
D

David Mark

Thanks for your opinion, interesting. When I as a newbie do not naturally
recognize experts and
"experts" in Javascript, it would be nice to have names or nicks  of some
real experts (in addition to you, of course) to learn of their scripts and
articles instead of "experts".

There are several related disciplines that contribute to the eventual
success or failure of a design: programming and general problem
solving, JS and browser scripting, as well as HTML (and XML)
authoring, CSS and Web server administration.

Generally speaking, programming requires a certain aptitude and
education that you can't pick up in this newsgroup (and certainly not
from blogs.) HTML, CSS and server administration have their own
groups, which I rarely visit, so I can't help you much there (other
than to steer you clear of the alt branch.) As far as markup goes,
Jukka Korpela comes to mind.

As for the Javascript language, there are numerous experts here.
Richard Cornford, Martin Honnen, Lasse (sorry forgot spelling of last
name), Thomas Lahn, Kangax, etc. Crockford pops up occasionally
(despite turning out to be human on some points, he knows the language
inside and out.) I know I'm leaving some people out. John Harris is
a good source for OO advice. Stockton for anything related to dates,
math and optimization.

As for browser scripting, most of my ideas came about from studying
Richard's examples and advice. Thomas, Kangax, Peter Michaux and RobG
usually have good advice as well. The recently departed (from this
NG) Randy Webb set me straight on some basic misconceptions when I
started posting here regularly a couple of years back (and yeah, I
argued till I was blue in the face on some of them.) Going way back
in time, Jim Ley (of jibbering.com) is sorely missed around here.
That guy got me off browser sniffing (and once called me a muppet, but
I deserved it at the time.) A few of them write blogs, but most do
not (probably too busy writing scripts), but there's always the
archives...

And I'll tell you who not to listen to. Virtually anyone who has ever
promoted a general purpose Javascript library (there are very few
exceptions.) They are a delusional (and often disingenuous) lot.

And generally speaking, I don't think even one of the aforementioned
people (or experts in other related groups) would recommend
subscribing to the Wile E. Web Developer (genius) school of thought
that is currently in vogue (e.g. the fundamentally backwards and over-
the-top Ajax strategies discussed in this thread.) In other words,
don't construct a giant catapult to attack a small bird. You'll end
up crushed by a boulder every time. ;)
 
D

David Mark

[snip]
And generally speaking, I don't think even one of the aforementioned
people (or experts in other related groups) would recommend
subscribing to the Wile E. Web Developer (genius) school of thought
that is currently in vogue (e.g. the fundamentally backwards and over-
the-top Ajax strategies discussed in this thread.)  In other words,
don't construct a giant catapult to attack a small bird.  You'll end
up crushed by a boulder every time.  ;)

For those mystified by that last paragraph (presumably outside the
US):

http://vids.myspace.com/index.cfm?fuseaction=vids.individual&VideoID=7622124

Haven't seen that since I was a kid, but it still holds up.
Illustrates several key concepts. See the poor coyote gathering
empirical evidence and finding out the hard way the futility of using
such evidence to predict the behavior of a complex system. And he ran
every end-around in his playbook to get that damned catapult to work.
Far more illuminating (and entertaining) than all of the John Resig
videos combined. :)
 
M

Matt Sach

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.

[snip a whole load of informative stuff]

I'm new to the group, and I immediately lost a load of time reading
the 140+ posts in "that other thread". I have to confess I had some
misgivings about the "fantasy hash" method, even though it's been used
on a site developed by my company, but I really thought you were being
an arse in the way you were trying to convince others of their
supposed folly. It seemed to me (and to others, after finishing
reading the thread) that you were never really explaining WHY you
thought it was such a bad idea.

THIS post however sets it all right. I can see *exactly* what you were
trying to get across. Thank you very much :)

The reason we ended up using it in a site was because the client
basically wanted to emphasise the "visual aesthetic" of their posh
hotel. The original spec said that each "page" (really, it stretches
the word to breaking point to call them that) had to display a set of
images in a sort of fading slideshow behind very minimal content.
Those images were intended to be cropped at three resolutions
(800x600, 1024x768 and 1280x1024) so that the resolution could be
dynamically selected depending on the viewport size. As soon as I saw
the design I started saying "No", but "clients are always right", or
at least always stubborn.

The length of time it took to load all the images and start the
slideshow was, on the whole, FAR more than it took to read any of
their tiny little content areas, so people would be navigating away
before ever seeing the other images. The client was desperate for
their users to wait and see all their lovely photographs. Thus arose
the painful suggestion of doing all the content changing in AJAX,
followed by the fantasy hash solution to maintain correct navigational
interaction (back button, bookmarks).

I'm not sure how we could have achieved the same effect without doing
this end-around on page reloads ("We could do it all in Flash, right?"
said the MD; that suggestion didn't last long). Of course, the site
design in the first place was pretty terrible. Unfortunately it seems
I had no say in that, despite trying.

Anyway, thanks again for a good explanation.
 
E

Evertjan.

Gregor Kofler wrote on 16 jul 2009 in comp.lang.javascript:
Matt Sach meinte:

[snip]
but "clients are always right"

Only if you let them pay for such atrocities. (Everyone has a price :))

Then again a professional has the duty to his client not to have him
indulge in bad decisions. Acting without that is unprofessional and
unethical.

If money is the final frontier, we would all be crooks.
 
G

Gregor Kofler

Evertjan. meinte:
Gregor Kofler wrote on 16 jul 2009 in comp.lang.javascript:
Matt Sach meinte:

[snip]
but "clients are always right"
Only if you let them pay for such atrocities. (Everyone has a price :))

Then again a professional has the duty to his client not to have him
indulge in bad decisions. Acting without that is unprofessional and
unethical.

Agreed. But some clients just don't want to take good advice. It's all
over the place: meaningless slideshows, "AJAX" - as David pointed out -
thrown in just to be Web 2.0, WYSIWYG editors to beef up content which
would completely disappear otherwise, absurd banner images that leave no
space for the content [1], etc.
If money is the final frontier, we would all be crooks.

That sounds a bit too melodramatic.

Gregor


[1]
http://www.aec.at (500 pixels to the top headline...)
 
E

Evertjan.

Gregor Kofler wrote on 16 jul 2009 in comp.lang.javascript:
Evertjan. meinte:

You don't know if I did.
Perhaps I was just teasing you, quod non, Gregor.
Gregor Kofler wrote on 16 jul 2009 in comp.lang.javascript:
Matt Sach meinte:

[snip]
but "clients are always right"
Only if you let them pay for such atrocities. (Everyone has a price
:))

Then again a professional has the duty to his client not to have him
indulge in bad decisions. Acting without that is unprofessional and
unethical.

Agreed. But some clients just don't want to take good advice.

A professional worth his keyboard would go elsewhere.
It's all
over the place: meaningless slideshows, "AJAX" - as David pointed out
- thrown in just to be Web 2.0, WYSIWYG editors to beef up content
which would completely disappear otherwise, absurd banner images that
leave no space for the content [1], etc.
Indeed.
If money is the final frontier, we would all be crooks.

That sounds a bit too melodramatic.

No it is not, This is the basis of professionalism.
That is why a client should pay you top euros,
not that you help him drawning in het wrong layman's knowledge.

However if you are a low quality professional yourself, so low that you
cannot get paid decently, yes then you are right. That would be dramatic,
not black melodramatic.

This NG would do good to ceep professional standards up for paid jobs,
not encouraging your "everyone does", so what's wrong with it?"
 
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.

[snip a whole load of informative stuff]

I'm new to the group, and I immediately lost a load of time reading
the 140+ posts in "that other thread". I have to confess I had some
misgivings about the "fantasy hash" method, even though it's been used
on a site developed by my company, but I really thought you were being
an arse in the way you were trying to convince others of their
supposed folly. It seemed to me (and to others, after finishing
reading the thread) that you were never really explaining WHY you
thought it was such a bad idea.

Always realize that this group is an ongoing soap opera in many ways.
Some of these "debates" happen over and over again with the same
handful of people involved. I often get tired of making the same
points to the same people repeatedly. I know it's not the easiest
thing to follow though. Searching the archive (at least through GG)
is less than ideal.
THIS post however sets it all right. I can see *exactly* what you were
trying to get across. Thank you very much :)

No problem. I could see that the message was getting buried in
puerile nonsense in that other thread. Some of the semi-regulars have
complexes. They really want to be right at any cost (even logic.)
Barring that, "shrillibusters" often ensue to drown out any message
that makes them look clueless.
The reason we ended up using it in a site was because the client
basically wanted to emphasise the "visual aesthetic" of their posh
hotel. The original spec said that each "page" (really, it stretches
the word to breaking point to call them that) had to display a set of
images in a sort of fading slideshow behind very minimal content.
Those images were intended to be cropped at three resolutions
(800x600, 1024x768 and 1280x1024) so that the resolution could be
dynamically selected depending on the viewport size. As soon as I saw
the design I started saying "No", but "clients are always right", or
at least always stubborn.

Well, the client shouldn't be concerned with the design, just the end
result.
The length of time it took to load all the images and start the
slideshow was, on the whole, FAR more than it took to read any of
their tiny little content areas, so people would be navigating away
before ever seeing the other images. The client was desperate for
their users to wait and see all their lovely photographs. Thus arose
the painful suggestion of doing all the content changing in AJAX,
followed by the fantasy hash solution to maintain correct navigational
interaction (back button, bookmarks).

Yikes. The client is involved in the wrong discussions. Certainly
you could maximize the number of photos viewed without resorting to
this sort of stuff.
I'm not sure how we could have achieved the same effect without doing
this end-around on page reloads ("We could do it all in Flash, right?"
said the MD; that suggestion didn't last long). Of course, the site
design in the first place was pretty terrible. Unfortunately it seems
I had no say in that, despite trying.

Sounds like each document has the same slide show. Maybe I am missing
something, but couldn't you just keep track of the current slide with
a cookie (or the like?)
Anyway, thanks again for a good explanation.

No problem.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,836
Messages
2,569,750
Members
45,545
Latest member
rapter____0

Latest Threads

Top