single page apps, URL hash setting, bookmarking, & the back button.

[David Mark]

??? What's "wrong" with the line?

Andrew Poulos

And more to the point, it confirmed my "suspicion" that it was not an
XHTML document )at least not served as one.) Quotes indicate that IE
doesn't support such documents, so it was a foregone conclusion.

 

[Peter Michaux]

Aha!  So, the user should not expect bookmarking a single document to
preserve the state.  Case closed.

I don't think that closes anything. You are simply replying to and
agreeing with yourself.

Peter

 

[Peter Michaux]

They expect it to bookmark the page, not preserve *state*.

When a user creates a bookmark, they expect it to bookmark the page.
In an page that is heavily updated dynamically using JavaScript the
user doesn't necessarily recognized when the full page transitions
occur. If a large portion or the focal portion of the page changes,
the user may equate that with a full page change. So in that case, the
user would expect the bookmark to preserve the state of the single
page web app.

Nobody would.

That statement is not based on observable data. Clearly people do
expect the bookmark to preserve state. At the very least the
developers of pages using URL hash-setting expect a bookmark to
preserve the state.

Not in the whole history of Web browsers has that ever
worked.

Again a statement not based on fact. With script, it works now in many
browsers.

It's just "Web2.0" script kiddie nonsense

I think the name calling detracts from any technical points you are
trying to make.

that does that and
it's never been prevalent enough to supplant previous expectations
about bookmark behavior.

In my opinion, you are way overestimating the user's understanding of
a strict definition of what a page change is and how to recognize one.

With large sites like GMail and Facebook using URL hash-setting
navigation, user expectations are likely to change.

Peter

 

[Peter Michaux]

On Jul 7, 3:52 pm, PointedEars wrote:

Broken by design (try using the back button)

It is not broken by design and you proclaiming it is does not make it
so.

You could argue that the implementation is broken as the back button
does not work properly. That, however, can be fixed.

and that site is a crock anyway

You have only stated you think that site "is a crock" without any real
reason. Judgements without reason don't change my opinion about how
useful that site is to me.

Peter

 

[Peter Michaux]

On Jul 7, 3:52 pm, PointedEars wrote:

Not to mention that they could have easily done that right as those
fragments are not fantasies.  Do you understand how they screwed it
up?

How would you have implemented that page?

Peter

 

[David Mark]

I don't think that closes anything. You are simply replying to and
agreeing with yourself.

BS. You can see that it was a bad snip. I replied to:

"For example, Yahoo! Maps does not look like multiple documents in one
document."

And are you still arguing these points after all of this? Seems
beyond belief. You wrote some of the best articles on progressive
enhancement using (as acknowledged) several of my ideas and
suggestions. Two years later you want to synthesize navigation
history entries for slide shows and won't listen when I tell you it is
a ludicrous design?

And Google and Facebook are your examples? I wouldn't rush to blog
about this one. It's a dog.

 

[Peter Michaux]

I actually think this is a worthwhile discussion. Despite Davids
protestations, GMail and Facebook have demonstrated that the technical
hurdles can be overcome to use hash-linking

For a site that is concerned only with a set of relatively new browser
version, the hurdles are not that great.

If you are writing a page for the general web then the technique may
not be advisable. It may never be advisable on the general web.

Before DOM manipulation came along and made things complicated, the
intent of the URL was to return you to the same resource every time.
Nothing has really changed except that developers have started adding
lots of state changes within a single document. Providing equivalent
browser-friendly navigation manipulation has been slow to catch up,
but the point of this discussion is to talk about how, not to say
"just don't do".

But those arguments are not even a discussion for this group. There
are plenty of other groups who are much more attuned to the needs of
[non-expert] users then a JavaScript language group.

Many of us design user interfaces also so I believe discussing the
user experience merits of a JavaScript-enabled technique are on topic
for this group.

The point is not
whether this is good usability or not (that decision will be made
elsewhere),

It can be made here too.

but whether it can be implemented.

It appears to be implementable at least in relatively new versions of
the major browsers.

Btw, it seems odd that small players like Gmail and Facebook
"small"?


successfully use it, and you (David) won't even entertain a discussion
on implementation. I suggest that they know more on the subject of how
people use their sites than you do.

I would imagine they (especially Google) have usability testing groups
that look over the shoulders of users to see how they interact with
pages. I also imagine they have many support emails about what users
like or do not like.

Peter

 

[David Mark]

When a user creates a bookmark, they expect it to bookmark the page.
In an page that is heavily updated dynamically using JavaScript the
user doesn't necessarily recognized when the full page transitions
occur. If a large portion or the focal portion of the page changes,
the user may equate that with a full page change. So in that case, the
user would expect the bookmark to preserve the state of the single
page web app.


That statement is not based on observable data. Clearly people do
expect the bookmark to preserve state.

What people? They must be very disappointed that bookmarks never did
that. As mentioned, cookies did. Not the average user knows what
either is. They can sometimes detect when somebody has broken their
browser though they likely won't know who to blame. I do.

At the very least the
developers of pages using URL hash-setting expect a bookmark to
preserve the state.

Isn't that what I said several times in this thread? Only the goofy
developers notice it and they are showing off for their similarly
sense-impaired colleagues. They may rationalize that they are
providing a more "intuitive" user experience, but that's classic
cognitive dissonance.

Again a statement not based on fact. With script, it works now in many
browsers.

No, you seemingly misunderstand again (which seems impossible.)
Bookmarks have never preserved state. Period. You are looking at an
illusion you created and buying into it. Made up hashes are not
states. You are creating a new URI, which has only one state. That's
why you have to mess with window.location, which is an outrageously
ill-advised scheme given that cookies (and even SQL) are available to
preserve states, without creating any of the problems associated with
faux history entries.

I think the name calling detracts from any technical points you are
trying to make.

Who am I calling names? Everyone will have figure out for themselves
if that shoe fits. None of this is new, BTW. The idea has been
floated, sunk and branded as "script kiddie" (or simply "backwards"
might be more to the point.) Don't join *that* club.

In my opinion, you are way overestimating the user's understanding of
a strict definition of what a page change is and how to recognize one.

How many times are you going to make my point for me? My primary
argument is that the users have no idea what to expect. Why create an
illusion for people without expectations? I know any semi-Web-
literate user will not expect an image swap (e.g. slide show) to
create a new history entry.

With large sites like GMail and Facebook using URL hash-setting
navigation, user expectations are likely to change.

Change from nothing concrete to something else you can't pin down?
I'm telling you they don't know what they are looking at (and don't
care.)

And I'm still waiting for a real example. Obviously slide shows were
a bad choice. Thomas went with a botched tabbed dialog (ironic given
your article on creating a similar enhancement.) What is your idea
that demands messing with *my* browser history? I bet it will turn
out to need no such thing. There's just no way that an argument of
"users expect bookmarks to work" is ever going to fly (I sure as hell
wouldn't design something that breaks bookmarks and most users
wouldn't notice if I did.)

 

[Peter Michaux]

On Jul 7, 7:26 pm, Hamish Campbell wrote:

That sounds like a commercial. Guaranteed you don't have to change
the location for make a usable slideshow.

"usable" is not a boolean property of a slideshow or a single-page web
app.

Did you see the best example Thomas could come up with?

You don't know it is the best example he could find.

Do you
understand how it illustrates how few people know enough to accomplish
this particular enhancement (without breaking the browser?)

I don't see any benefit in discussing what other people are not able
to implement. We already know there are many bad scripts on the web.

And that
was a much simpler example as they didn't even use script to change
the location (just to switch the tabs.) That should pretty much close
the book on this.

You still haven't stated what is wrong with the design of the page
behavior. Sure they haven't fixed the back button behavior but they
could. That is not a problem with the design.

LOL. Then there are a lot of disappointed users out there as
bookmarks do no such thing. Never have.

I've presented several examples of sites where bookmarks do preserve
state. See Yahoo! Maps, for example.

Thomas' (bad) example is
just three document fragments that have been rearranged with script to
look like a tabbed dialog. That's not state.

Which tab is selected is definitely page state.

And state is (and always has been) persisted with cookies (and
sometimes SQL these days), not made-up hashes.

In my opinion, page state should never be preserved with cookies. That
adds weight to the HTTP requests, the preservation of state is
volatile, and cookies cannot be bookmarked or emailed.

Again, that's my point. So why are you worrying about creating an
illusion for users with no expectations to begin with.

That is not what he wrote. They do have expectations. They expect that
a bookmark preserves whatever their impression is of "current page".
If the page is changing dramatically as they interact then they may
interpret those changes as page changes.

If you think
about it, you are creating an illusion for other Web developers (the
illusion that you are "cool" enough to do tricks like this.)

I think it improves usability for non-savvy users and also adds easier
navigation control for those who understand what is happening.

As
illustrated, even with a simplified example, the crack W3C developers
blew it.

That is not a black mark on the technique itself. It is not very
difficult to implement properly when it is known that browsers
supporting the necessary features are in use.

Wrong. This is a fundamental design error. Do not do it under any
circumstances. If you can't understand why at this point, you really
need to think about what you are doing.

I don't think that you've made a compelling case. All I've read is
quite a lot of "don't do it because I'm an expert and I say so" and
name calling. Neither of those approaches are moving.

I suggest that Google's JS developers are completely clueless,

I'm a user and I enjoy using several of their web applications daily.

I'll tell you this, if I navigated to one of their documents with a
slide show, flipped through a dozen slides and had to hit back 13
times to get back where I was in the first place, I'd delete all
bookmarks to the site immediately. I have little doubt that most
users would feel the same way,

Before Facebook used URL hash-setting for their slideshow navigation,
they used full page refreshes. That means that it would be 13 clicks
on the back button to get where you were before the slide show. "Most
users" did not stop using Facebook. In fact, Facebook has a quickly
growing user base. People seemed to like the Facebook user experience.

but were not asked to articulate their
position to Facebook's incompetent Web designers.

I don't know how you can claim the web *designers* or even the web
*programmers* at Facebook are incompetent. I use Facebook regularly
and don't have any troubles with it.

Again, if you see lots of Web designers/developers doing something
(especially on large sites); it's probably the wrong thing. It's not
a new theory and seems to hold true every time. Is it news that most
Web developers are completely incompetent, even without scripting?
What chance do they have to make a correct decision *with* scripting?

Why are you worried about other people's abilities to implement a
technique?

Peter

 

[David Mark]

How would you have implemented that page?

Are you kidding? Didn't we once discuss tabs here for a month (and
then you wrote an article on the subject?) My ideas on the subject
are largely unchanged (and are no longer free in most cases.)

I'll ask again. Can anyone not see how these ostensibly competent
developers botched this comparatively simple enhancement?

 

[Peter Michaux]

My point is this: the way in which many websites work has changed, for
good or for bad. The way the browser handles navigation has not
changed fundamentally, so it seems like good practice to allow the
browser to continue to behave the way it was intended and is expected,
*given* that the website is making a lot of state changes to
individual pages.

It seems like there is a case for them, and if there is a set of
guidelines for doing it 'right', maybe that is what we should be
talking about, rather than the myriad ways to screw it up (of which, I
accept, there are many!).

This is a well put point and I think this is exactly why hash-links
have appeared. People want the benefits of DHTML to modify the page
quickly and significantly but the navigation to work the way it did/
does without JavaScript around. In fact, handling the URL issues is
completing the illusion of a full page change DHTML is mostly
providing without the latency of a real full page change.

Peter

 

[Peter Michaux]

Of course. That's done with a query, which is normally processed
server side (thought not necessarily.) It's only done with a hash
when there is actually a fragment by that name (or ID.)

Perhaps it was only done "when there is actually a fragment by that
name" in the past but clearly that is not the case now as single page
apps are using the hash for other purposes.

You aren't really saying anything related to the design decision.
Seems this whole thread has been one generalized statement after
another. It's like everybody is sure this is their new toy and can't
see the potential choking hazard. I'm telling you it's there.

Sure danger is there. The first character of script adds danger to the
page.

If you don't like the generalizations then focus on an example. Of all
the examples mentioned, I think Yahoo! Maps is the strongest example
of using hash-setting well. I think the "permalink" link in Google
Maps is a very poor user experience in comparison to the Yahoo! Maps
hash-setting.

The Web has caught up to what is possible, but virtually
everything is being done wrong.

And yet the web is still a huge success.

Peter

 

[David Mark]

This is a well put point and I think this is exactly why hash-links

No, it isn't. I've already answered the question from every
conceivable angle. Cookies top the list and they don't break
bookmarks. On the contrary, they work together like magic. Want to
highlight sending state-tinged links to friends? Can you not compete
with the browser's file menu? You know the technical details (tack on
a query, not a hash.)

have appeared. People want the benefits of DHTML to modify the page
quickly and significantly but the navigation to work the way it did/
does without JavaScript around.

I don't know who these people are and only vaguely followed that
anyway. How does the presence of JS affect navigation? Oh, when
incompetent programmers pollute the history, break the back button,
etc. Yeah, I want it to work like it dis without Javascript around.
No question.

In fact, handling the URL issues is
completing the illusion of a full page change DHTML is mostly
providing without the latency of a real full page change.

If there was no full page change, there was no navigation. You don't
need to create illusions for users with no expectations. Those with
expectations are likely savvy enough to figure out your "send a link"
interface (and that using the browser's file menu instead does not
send along the state of the document.) They'll figure out that
navigation works as it did before the Ajax suicide squads became
prevalent. Do keep in mind that this "technique" has been used for
years, despite it being known to cause major problems (in major
browsers no less.) That's the mindset. Now you say "all browsers"
work? It's like this whole thread is a bizarre put-on.

 

[David Mark]

Perhaps it was only done "when there is actually a fragment by that
name" in the past but clearly that is not the case now as single page
apps are using the hash for other purposes.

Only done by people who know what they are doing. We both know that
excludes most Web developers (particularly when scripting is
involved.)

Sure danger is there. The first character of script adds danger to the
page.

That's a silly thing to say. Big trip from "hello world" to "goodbye
usability."

If you don't like the generalizations then focus on an example.

I've focused on every one presented, asked for more, as well as any
questions. Nothing so far.

Of all
the examples mentioned, I think Yahoo! Maps is the strongest example
of using hash-setting well. I think the "permalink" link in Google
Maps is a very poor user experience in comparison to the Yahoo! Maps
hash-setting.

This is that one exception that proves the rule. Google got it
"right." Quotes indicate I haven't looked at it, am sure the
implementation is weak and the word "permalink" should not be involved
(in any public site for that matter as few people other than Web
developers know what it means.)

And yet the web is still a huge success.

Now I am going to throw up. Seriously, were you kidnapped by aliens?

Everything is relative. And I put it to you that the Web is a huge
mess and a dismal failure in many cases. If you've got to pigeonhole
it, I think most users would vote for the "huge mess" classification.

 

[Peter Michaux]

What people? They must be very disappointed that bookmarks never did
that. As mentioned, cookies did. Not the average user knows what
either is. They can sometimes detect when somebody has broken their
browser though they likely won't know who to blame. I do.


Isn't that what I said several times in this thread? Only the goofy
developers notice it and they are showing off for their similarly
sense-impaired colleagues. They may rationalize that they are
providing a more "intuitive" user experience, but that's classic
cognitive dissonance.

You wrote "nobody would" and I easily provided an counter-example of
people that would.

No, you seemingly misunderstand again (which seems impossible.)
Bookmarks have never preserved state. Period.

Without question, bookmarks have always preserved state. At the very
least they preserve the state of the browser: which page the browser
is showing.

Bookmarks have even preserved page state. Suppose I bookmark a page
with http://example.com/asdf.html#one. When that page is loaded it
will be scrolled into position. That is a restoration of the scroll
state of the page.

You are looking at an
illusion you created and buying into it. Made up hashes are not
states. You are creating a new URI, which has only one state. That's
why you have to mess with window.location, which is an outrageously
ill-advised scheme given that cookies (and even SQL) are available to
preserve states, without creating any of the problems associated with
faux history entries.

Hash-setting does not necessarily imply pushing new entries on the
browser's history.

Who am I calling names? Everyone will have figure out for themselves
if that shoe fits. None of this is new, BTW. The idea has been
floated, sunk and branded as "script kiddie" (or simply "backwards"
might be more to the point.) Don't join *that* club.

You haven't made any technical points about why hash-setting is a bad
idea. You've done little more than say you just don't like it.

How many times are you going to make my point for me? My primary
argument is that the users have no idea what to expect.

The user has expectations based on intuition and past experience
(perhaps with non-script slide shows, for example.)

Why create an
illusion for people without expectations?

On the contrary, it is creating an illusion that matches people's
exceptions.

I know any semi-Web-
literate user will not expect an image swap (e.g. slide show) to
create a new history entry.

They don't know it is implemented as an image swap. All they know is
what they see has changed. In a slide show without script that would
mean a page refresh. In a slide show with script making the image swap
the user may still interpret the change as a page change.

I don't find the slide show example as compelling as the Yahoo! Maps
example.

Change from nothing concrete to something else you can't pin down?
I'm telling you they don't know what they are looking at (and don't
care.)

They care that what they are looking at (for whatever their assessment
of "what they are looking at" means) can be restored with a bookmark.

And I'm still waiting for a real example. Obviously slide shows were
a bad choice. Thomas went with a botched tabbed dialog (ironic given
your article on creating a similar enhancement.) What is your idea
that demands messing with *my* browser history?

Hash-setting does not imply adjusting the browser history.

I bet it will turn
out to need no such thing. There's just no way that an argument of
"users expect bookmarks to work" is ever going to fly (I sure as hell
wouldn't design something that breaks bookmarks and most users
wouldn't notice if I did.)

Yahoo! Maps is a fine example of using hash-setting to the benefit of
the user.

Peter

 

[Peter Michaux]

And are you still arguing these points after all of this?  Seems
beyond belief.  You wrote some of the best articles on progressive
enhancement using (as acknowledged) several of my ideas and
suggestions.

The use of hash-setting is not counter to the idea of progressive
enhancements.

Two years later you want to synthesize navigation
history entries for slide shows

Yahoo Maps!

and won't listen when I tell you it is
a ludicrous design?

You are not saying why it is a ludicrous design. Just saying so has no
influence on me.

And Google and Facebook are your examples?

I mentioned Yahoo! Maps much earlier in this thread as the example I
found most compelling. I've been on the fence about GMail and
Facebook. Facebook strikes me as the weakest of the three use cases.

Peter

 

[Peter Michaux]

Now I am going to throw up. Seriously, were you kidnapped by aliens?

Everything is relative. And I put it to you that the Web is a huge
mess and a dismal failure in many cases. If you've got to pigeonhole
it, I think most users would vote for the "huge mess" classification.

Wow. If you think the web has not been a huge success...I don't know
what to make of that. The web is one of the greatest successes in the
history of computing. The web has enabled massive information sharing
like no other time in the history of man. It has enhanced freedom of
speech to a point where it would be virtually impossible to censor
anyone. The fact that the web is so tolerant to poorly written source
files is amazing technical feat. The fact that web is so completely
intertwined many people's every day and work lives is testament to its
utility and popularity. The list goes on and on.

I'm confident most people would judge the web a huge success. They
would also judge Google and Facebook as successes. You seem to judge
none of these things as successes which seems impossible to
reconcile.

Peter

 

[Peter Michaux]

Now you say "all browsers" work?

I have slipped up with the typing at least once in this thread.
Without question, all browsers don't work well with hash-setting. As I
mentioned and kangax confirmed, old version of Safari, for example,
don't work well with hash-setting.

Wherever I have written "all browsers work" without qualification, I
have meant "all recent versions of the major browsers."

Peter

 

[David Mark]

I have slipped up with the typing at least once in this thread.
Without question, all browsers don't work well with hash-setting. As I
mentioned and kangax confirmed, old version of Safari, for example,
don't work well with hash-setting.

Wherever I have written "all browsers work" without qualification, I
have meant "all recent versions of the major browsers."

Which we both know carries no weight at all. I thought this case was
closed years ago. Odd end-around gimmick, something you don't need,
known to cause problems, frequently mixed with browser sniffing, etc.
Why are we discussing this again?

 

[David Mark]

You wrote "nobody would" and I easily provided an counter-example of
people that would.

Just so happens it was irrelevant unless you were trying to prove my
point.

Without question, bookmarks have always preserved state. At the very
least they preserve the state of the browser: which page the browser
is showing.

OMFG. I'll pretend you didn't write that.

Bookmarks have even preserved page state. Suppose I bookmark a page
withhttp://example.com/asdf.html#one. When that page is loaded it
will be scrolled into position. That is a restoration of the scroll
state of the page.

Again, that's a *fragment*, which is what hashes are for. I've
mentioned this six times already. The containing document would have
state preserved as cookies as the hash is obviously *taken*.

Hash-setting does not necessarily imply pushing new entries on the
browser's history.

But that's the case we've been discussing all along. Do you now want
to replace the current entry instead? What possible good would that
do? It could certainly do some bad (i.e. reload the whole document),
but I can't think of anything to be gained from such an operation.
Cookies are what you want here. There's even SQL now in WebKit-based
browsers. Leave the hash alone.

You haven't made any technical points about why hash-setting is a bad
idea. You've done little more than say you just don't like it.

That's completely untrue. I've described in detail how the design is
flawed, why it isn't needed and demonstrated that every example design
posted thus far is flawed and/or broken. If you missed that, I
suggest you start over from the beginning.

The user has expectations based on intuition and past experience
(perhaps with non-script slide shows, for example.)

"Non-script" slide shows are typically a document with n static
images.

On the contrary, it is creating an illusion that matches people's
exceptions.


They don't know it is implemented as an image swap. All they know is
what they see has changed. In a slide show without script that would
mean a page refresh. In a slide show with script making the image swap
the user may still interpret the change as a page change.

You seem to want to argue this forever. I don't share that desire.
Do what you want, but realize you are rationalizing at best. God
knows, you haven't even tried to make any technical points here. The
whole thread is an embarrassment IMO.

I don't find the slide show example as compelling as the Yahoo! Maps
example.

I find neither compelling (or worthy of discussion at this time.)

They care that what they are looking at (for whatever their assessment
of "what they are looking at" means) can be restored with a bookmark.

I can't make heads or tails of that.

Hash-setting does not imply adjusting the browser history.

See above.

Yahoo! Maps is a fine example of using hash-setting to the benefit of
the user.

Sounds like a commercial. No technical merit at all.