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

Discussion in 'Javascript' started by Peter Michaux, Jun 26, 2009.

  1. A couple years ago I remember discussing here the idea of a single
    page application setting the URL hash as a means of allowing
    bookmarking and the back button to work as "expected". Navigating
    through a one page app, the user would see the URL change

    http://example.com/#page1
    http://example.com/#page2
    http://example.com/#page3

    JavaScript would change the hash part of the URL so the user could
    bookmark any screen and return to it. Setting the hash adds to the
    browsers history so the back button also works.

    At the time of the discussion I think there were browsers that
    refreshed the page when setting the URL hash. I believe Safari 1 or 2
    might have been doing this. Perhaps Opera as well. I remember Yahoo!
    maps was setting the URL hash and basically didn't work in some
    browers. Google maps, on the other hand, had and still does have a
    little "link" link that gives the user a permalink they can send to
    others to show the same screen (map position, zoom, etc.)

    At the time, I remember Richard Cornford pointed out that there is or
    was no standard dictating whether or not the browser should refresh
    when the hash is changed through JavaScript. The situation seems to
    have stabilized and all the major browsers do not refresh when setting
    the URL hash through JavaScript. A de facto standard behavior seems to
    have emerged.

    I now see that Gmail and Facebook are both using URL hash setting as a
    means of managing one page applications. Considering these pages both
    take long to load, using Ajax to update little bits of the screen
    (even the whole middle of the screen) is snappier than a full page
    load. (Perhaps good caching could make the snappy same result?)

    With important/popular one-page apps using URL hash setting, it seems
    like a technique that is probably here to stay.

    Has anyone here worked on a big application using URL hash setting for
    navigation management? Any gotcha's learned through experience working
    on them?
     
    Peter Michaux, Jun 26, 2009
    #1
    1. Advertising

  2. Peter Michaux

    David Mark Guest

    Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jun 25, 10:57 pm, Peter Michaux <> wrote:
    > A couple years ago I remember discussing here the idea of a single
    > page application setting the URL hash as a means of allowing
    > bookmarking and the back button to work as "expected".


    An execrable "Web 2.0" end-around if there ever was one. Do not use
    Ajax for navigation.

    Navigating
    > through a one page app, the user would see the URL change
    >
    > http://example.com/#page1http://example.com/#page2http://example.com/#page3


    This is what I'm talking about.

    >
    > JavaScript would change the hash part of the URL so the user could
    > bookmark any screen and return to it. Setting the hash adds to the
    > browsers history so the back button also works.


    It may appear to work in some cases, provided you check the current
    location every split second and update the content to match.

    >
    > At the time of the discussion I think there were browsers that
    > refreshed the page when setting the URL hash. I believe Safari 1 or 2
    > might have been doing this. Perhaps Opera as well. I remember Yahoo!
    > maps was setting the URL hash and basically didn't work in some
    > browers. Google maps, on the other hand, had and still does have a
    > little "link" link that gives the user a permalink they can send to
    > others to show the same screen (map position, zoom, etc.)


    Much better, but how do I know they botched the implementation.

    >
    > At the time, I remember Richard Cornford pointed out that there is or
    > was no standard dictating whether or not the browser should refresh
    > when the hash is changed through JavaScript. The situation seems to
    > have stabilized and all the major browsers do not refresh when setting
    > the URL hash through JavaScript. A de facto standard behavior seems to
    > have emerged.


    Doesn't matter as you don't need it.

    >
    > I now see that Gmail and Facebook are both using URL hash setting as a


    Look at your sources. Nothing says backwards browser scripting
    futility like those two sites.

    > means of managing one page applications. Considering these pages both
    > take long to load, using Ajax to update little bits of the screen
    > (even the whole middle of the screen) is snappier than a full page
    > load. (Perhaps good caching could make the snappy same result?)


    There's nothing snappier than fast history navigation, which requires
    no scripting at all (just the lack of unload listeners, which is sadly
    rare these days.)

    >
    > With important/popular one-page apps using URL hash setting, it seems
    > like a technique that is probably here to stay.


    Look again. IIRC, both of those sites use jQuery (and that sure as
    hell isn't here to stay.)

    >
    > Has anyone here worked on a big application using URL hash setting for
    > navigation management? Any gotcha's learned through experience working
    > on them?


    Yeah, I've untangled several such messes. The lesson is to use Ajax
    only where it makes sense (excludes anything that would confuse or
    break navigation.) In short, overlaid dialogs make sense (in some
    cases), replacing the document content does not.
     
    David Mark, Jun 28, 2009
    #2
    1. Advertising

  3. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jun 27, 11:46 pm, David Mark <> wrote:
    > On Jun 25, 10:57 pm, Peter Michaux <> wrote:


    > > Has anyone here worked on a big application using URL hash setting for
    > > navigation management? Any gotcha's learned through experience working
    > > on them?

    >
    > Yeah, I've untangled several such messes. The lesson is to use Ajax
    > only where it makes sense (excludes anything that would confuse or
    > break navigation.) In short, overlaid dialogs make sense (in some
    > cases), replacing the document content does not.


    Well none of Facebook, GMail, or Yahoo! Maps falls into your later
    option of "replacing the document content." Yes these single page apps
    refresh the focal-point HTML of the page but not necessarily large
    portions of the total page HTML. So I think these single page apps
    fall into the grey-area category along with overlaid dialogs.

    I know I definitely like the hash-setting approach for Yahoo! Maps. It
    just makes perfect sense there, in my opinion, as the changes are
    small and frequent. The changes to the page don't necessarily even
    require anything new to be loaded from the server. I don't like the
    Google Maps approach of having a permalink link that shows the user
    the URL to email to friends. That is putting far too much burden of
    knowledge on the user. Just making a bookmark is a pain that way.

    I'm undecided whether or not the hash-setting approach is necessary or
    beneficial overall in GMail or Facebook. Without changing to a frames-
    based approach, using the hash-setting approach does save having to
    reload the navigation and other constant HTML around the focal-point
    HTML. In that sense, the hash-setting approach is much snappier.

    Peter
     
    Peter Michaux, Jul 4, 2009
    #3
  4. Peter Michaux

    David Mark Guest

    Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 4, 11:48 am, Peter Michaux <> wrote:
    > On Jun 27, 11:46 pm, David Mark <> wrote:
    >
    > > On Jun 25, 10:57 pm, Peter Michaux <> wrote:
    > > > Has anyone here worked on a big application using URL hash setting for
    > > > navigation management? Any gotcha's learned through experience working
    > > > on them?

    >
    > > Yeah, I've untangled several such messes.  The lesson is to use Ajax
    > > only where it makes sense (excludes anything that would confuse or
    > > break navigation.)  In short, overlaid dialogs make sense (in some
    > > cases), replacing the document content does not.

    >
    > Well none of Facebook, GMail, or Yahoo! Maps falls into your later
    > option of "replacing the document content." Yes these single page apps
    > refresh the focal-point HTML of the page but not necessarily large
    > portions of the total page HTML. So I think these single page apps
    > fall into the grey-area category along with overlaid dialogs.


    Then they should skip worrying about navigation (e.g. fantasy hashes.)

    >
    > I know I definitely like the hash-setting approach for Yahoo! Maps. It
    > just makes perfect sense there, in my opinion, as the changes are
    > small and frequent. The changes to the page don't necessarily even
    > require anything new to be loaded from the server. I don't like the
    > Google Maps approach of having a permalink link that shows the user
    > the URL to email to friends. That is putting far too much burden of
    > knowledge on the user. Just making a bookmark is a pain that way.


    If you want to be able to mail bookmarks, then you must design your
    app appropriately. Sounds like Yahoo did not. For that matter, what
    is wrong with a "Send link to a friend" button? Tack a query on the
    end of the URI to indicate the state to the script and you are done.

    >
    > I'm undecided whether or not the hash-setting approach is necessary or
    > beneficial overall in GMail or Facebook. Without changing to a frames-
    > based approach, using the hash-setting approach does save having to
    > reload the navigation and other constant HTML around the focal-point
    > HTML. In that sense, the hash-setting approach is much snappier.


    Guaranteed the whole thing would be snappier if somebody had
    scrutinized the design from the beginning.
     
    David Mark, Jul 6, 2009
    #4
  5. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 5, 5:10 pm, David Mark wrote:
    > On Jul 4, 11:48 am, Peter Michaux wrote:
    > > On Jun 27, 11:46 pm, David Mark wrote:
    > > > On Jun 25, 10:57 pm, Peter Michaux wrote:


    > > Well none of Facebook, GMail, or Yahoo! Maps falls into your later
    > > option of "replacing the document content." Yes these single page apps
    > > refresh the focal-point HTML of the page but not necessarily large
    > > portions of the total page HTML. So I think these single page apps
    > > fall into the grey-area category along with overlaid dialogs.

    >
    > Then they should skip worrying about navigation (e.g. fantasy hashes.)


    I don't see how your conclusion follows. Being able to capture the
    entire state of the page in a URL is handy for bookmarking.


    > > I know I definitely like the hash-setting approach for Yahoo! Maps. It
    > > just makes perfect sense there, in my opinion, as the changes are
    > > small and frequent. The changes to the page don't necessarily even
    > > require anything new to be loaded from the server. I don't like the
    > > Google Maps approach of having a permalink link that shows the user
    > > the URL to email to friends. That is putting far too much burden of
    > > knowledge on the user. Just making a bookmark is a pain that way.

    >
    > If you want to be able to mail bookmarks, then you must design your
    > app appropriately. Sounds like Yahoo did not.


    I don't see how you conclude that. The idea of using a hash-setting
    approach makes it possible in all current browsers to email or
    bookmark the URL in the browser's address bar and have it work. Yes
    when Yahoo! Maps started with hash-setting they were using a feature
    that didn't work in all major browsers but now that feature does work.


    > For that matter, what
    > is wrong with a "Send link to a friend" button?


    Many people will email the URL in their browsers address bar.

    Many people will not see the "permalink" link. It is tiny in Google
    Maps and they should probably not use any more space to make it
    bigger.

    Many people who see the "permalink" link, will not know what it is,
    how to use it, or will just throw their hands up in frustration that
    "this is all too complicated!"

    A "permalink" link doesn't work so well or intuitively with the
    browser's "bookmark this page" feature. People will try to bookmark
    the page and just think "this is broken" as it doesn't save the state
    of the page.


    > Tack a query on the
    > end of the URI to indicate the state to the script and you are done.


    Yes that is how it works to program it. That doesn't mean it works
    well from the user's point of view or his understanding of how web
    addresses work.


    > > I'm undecided whether or not the hash-setting approach is necessary or
    > > beneficial overall in GMail or Facebook. Without changing to a frames-
    > > based approach, using the hash-setting approach does save having to
    > > reload the navigation and other constant HTML around the focal-point
    > > HTML. In that sense, the hash-setting approach is much snappier.

    >
    > Guaranteed the whole thing would be snappier if somebody had
    > scrutinized the design from the beginning.


    That is very vague. There isn't too much information there to which I
    can reply.

    In the case of something like Yahoo! Maps, if your only idea is just
    to have a "permalink" link because hash-setting is non-standard, then
    I think I'd choose hash-setting. The user experience with hash-setting
    is far superior. The JavaScript required to implement it, even polling
    the URL for changes, is almost negligibly small (< 100 lines) and not
    slow. All the browsers are behaving well now. Big applications, which
    have "pull" with browser makers depend on good hash-setting behavior
    so that behavior now has too much web weight to change it.

    We cannot be completely afraid of non-standard behavior. I think it is
    fair to say we probably all depend on certain bits of non-standard,
    but de facto standard, behavior. I use innerHTML, for example, and
    think the ability to write browser scripts would be harmed
    dramatically by removing innerHTML.

    Peter
     
    Peter Michaux, Jul 6, 2009
    #5
  6. Peter Michaux

    David Mark Guest

    Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 5, 10:40 pm, Peter Michaux <> wrote:
    > On Jul 5, 5:10 pm, David Mark wrote:
    >
    > > On Jul 4, 11:48 am, Peter Michaux wrote:
    > > > On Jun 27, 11:46 pm, David Mark wrote:
    > > > > On Jun 25, 10:57 pm, Peter Michaux wrote:
    > > > Well none of Facebook, GMail, or Yahoo! Maps falls into your later
    > > > option of "replacing the document content." Yes these single page apps
    > > > refresh the focal-point HTML of the page but not necessarily large
    > > > portions of the total page HTML. So I think these single page apps
    > > > fall into the grey-area category along with overlaid dialogs.

    >
    > > Then they should skip worrying about navigation (e.g. fantasy hashes.)

    >
    > I don't see how your conclusion follows. Being able to capture the
    > entire state of the page in a URL is handy for bookmarking.


    But there are lots of ways to do that without breaking navigation.

    >
    > > > I know I definitely like the hash-setting approach for Yahoo! Maps. It
    > > > just makes perfect sense there, in my opinion, as the changes are
    > > > small and frequent. The changes to the page don't necessarily even
    > > > require anything new to be loaded from the server. I don't like the
    > > > Google Maps approach of having a permalink link that shows the user
    > > > the URL to email to friends. That is putting far too much burden of
    > > > knowledge on the user. Just making a bookmark is a pain that way.

    >
    > > If you want to be able to mail bookmarks, then you must design your
    > > app appropriately.  Sounds like Yahoo did not.

    >
    > I don't see how you conclude that. The idea of using a hash-setting
    > approach makes it possible in all current browsers to email or
    > bookmark the URL in the browser's address bar and have it work. Yes
    > when Yahoo! Maps started with hash-setting they were using a feature
    > that didn't work in all major browsers but now that feature does work.


    I know they didn't need to do it at all. Browsers are great at
    navigation and there is no need to tack on fantasy hashes to make
    bookmarks work. On the contrary, bookmarks and email do just fine on
    their own, provided they aren't interfered with by ill-advised
    scripting techniques.

    >
    > > For that matter, what
    > > is wrong with a "Send link to a friend" button?

    >
    > Many people will email the URL in their browsers address bar.


    So what? The receiver will see whatever they see. Guaranteed it
    would correspond exactly to what the sender saw if the site's
    designers had thought about such issues from day one. What do you
    think they are trying to avoid? I'd say the primary issue is that
    their documents are weighted down by lots of large scripts.

    >
    > Many people will not see the "permalink" link. It is tiny in Google
    > Maps and they should probably not use any more space to make it
    > bigger.


    That's a generalization. Who knows what many people will see or not?
    If Google made theirs tiny, that is their problem.

    >
    > Many people who see the "permalink" link, will not know what it is,
    > how to use it, or will just throw their hands up in frustration that
    > "this is all too complicated!"


    That's silly. For one, don't call it "permalink" (of all things.)
    And there's plenty of people who couldn't copy the text of a URI or
    understand why such an operation would be needed. You can't provide
    users with something better than that?

    >
    > A "permalink" link doesn't work so well or intuitively with the
    > browser's "bookmark this page" feature. People will try to bookmark
    > the page and just think "this is broken" as it doesn't save the state
    > of the page.


    Not hardly. Bookmarks are for documents and it is very hard to break
    that feature. The average user knows nothing about what "state"
    should be saved with a bookmark.

    >
    > > Tack a query on the
    > > end of the URI to indicate the state to the script and you are done.

    >
    > Yes that is how it works to program it. That doesn't mean it works
    > well from the user's point of view or his understanding of how web
    > addresses work.


    I know one thing, a button that says "Send to a Friend" should not
    require the user to know anything about Web addresses. OTOH, copying
    a URI from the address bar requires some basic knowledge in that area
    (else how would they know what to copy?)

    >
    > > > I'm undecided whether or not the hash-setting approach is necessary or
    > > > beneficial overall in GMail or Facebook. Without changing to a frames-
    > > > based approach, using the hash-setting approach does save having to
    > > > reload the navigation and other constant HTML around the focal-point
    > > > HTML. In that sense, the hash-setting approach is much snappier.

    >
    > > Guaranteed the whole thing would be snappier if somebody had
    > > scrutinized the design from the beginning.

    >
    > That is very vague. There isn't too much information there to which I
    > can reply.


    Well, we can't go back in a time machine. I bet if I looked at either
    of those sites, I could tell you exactly how I would rewrite them.
    I'm a little busy with rewriting other things at the moment though.

    >
    > In the case of something like Yahoo! Maps, if your only idea is just
    > to have a "permalink" link because hash-setting is non-standard, then


    Forget the word "permalink" in this context. Virtually nobody in the
    intended audience knows what it means.

    > I think I'd choose hash-setting. The user experience with hash-setting


    Even a "permalink" button would be better than that, but of course,
    there are more than two choices available. As mentioned, I wouldn't
    do either one.

    > is far superior. The JavaScript required to implement it, even polling
    > the URL for changes, is almost negligibly small (< 100 lines) and not
    > slow. All the browsers are behaving well now. Big applications, which


    "All the browsers?" Come on.

    > have "pull" with browser makers depend on good hash-setting behavior
    > so that behavior now has too much web weight to change it.


    It's still a ridiculous thing to do.

    >
    > We cannot be completely afraid of non-standard behavior. I think it is


    It has nothing to do with standards. It's good design vs. bad. If
    you find yourself cramming an entire application that looks like
    multiple documents into one document, realize that bookmarking
    functionality is going to be lost (barring bizarre workarounds.) Then
    realize what a silly decision that was and make a different one.

    > fair to say we probably all depend on certain bits of non-standard,
    > but de facto standard, behavior. I use innerHTML, for example, and
    > think the ability to write browser scripts would be harmed
    > dramatically by removing innerHTML.


    That's another story.
     
    David Mark, Jul 6, 2009
    #6
  7. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 5, 8:11 pm, David Mark <> wrote:

    > It has nothing to do with standards. It's good design vs. bad. If
    > you find yourself cramming an entire application that looks like
    > multiple documents into one document,


    For example, Yahoo! Maps does not look like multiple documents in one
    document. Yahoo! Maps looks like an application in a web browser. That
    is not a problem in the design of Yahoo! Maps. It is a strength of the
    Yahoo! Maps design.

    The web is not just a collection of documents anymore. It is now a
    collection of documents and applications. Some of the applications
    would be terrible had they been implemented with the mindset of a
    collection of documents.

    > realize that bookmarking functionality is going to be
    > lost (barring bizarre workarounds.)


    I really cannot see what is bizarre about using the URL hash as a way
    to indicate the state of a single-page web app.

    The bookmarking functionality doesn't have to be lost. Using hash-
    setting it can kept just fine in current versions of all the major
    browser.

    Peter
     
    Peter Michaux, Jul 6, 2009
    #7
  8. Peter Michaux

    David Mark Guest

    Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 5, 11:56 pm, Peter Michaux <> wrote:
    > On Jul 5, 8:11 pm, David Mark <> wrote:
    >
    > > It has nothing to do with standards.  It's good design vs. bad.  If
    > > you find yourself cramming an entire application that looks like
    > > multiple documents into one document,


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

    [snip]
     
    David Mark, Jul 6, 2009
    #8
  9. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 5, 11:49 pm, David Mark <> wrote:
    > On Jul 5, 11:56 pm, Peter Michaux <> wrote:
    >
    > > On Jul 5, 8:11 pm, David Mark <> wrote:

    >
    > > > It has nothing to do with standards.  It's good design vs. bad.  If
    > > > you find yourself cramming an entire application that looks like
    > > > multiple documents into one document,

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


    But I think the user *does* expect bookmarking to work. I'm a user. I
    expect it to work.

    Peter
     
    Peter Michaux, Jul 6, 2009
    #9
  10. Peter Michaux

    David Mark Guest

    Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 6, 12:11 pm, Peter Michaux <> wrote:
    > On Jul 5, 11:49 pm, David Mark <> wrote:
    >
    > > On Jul 5, 11:56 pm, Peter Michaux <> wrote:

    >
    > > > On Jul 5, 8:11 pm, David Mark <> wrote:

    >
    > > > > It has nothing to do with standards.  It's good design vs. bad.  If
    > > > > you find yourself cramming an entire application that looks like
    > > > > multiple documents into one document,

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

    >
    > But I think the user *does* expect bookmarking to work. I'm a user. I
    > expect it to work.
    >


    They expect it to bookmark the page, not preserve *state*. Nobody
    would. Not in the whole history of Web browsers has that ever
    worked. It's just "Web2.0" script kiddie nonsense that does that and
    it's never been prevalent enough to supplant previous expectations
    about bookmark behavior.
     
    David Mark, Jul 6, 2009
    #10
  11. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    David Mark wrote:
    > On Jul 6, 12:11 pm, Peter Michaux <> wrote:
    >> On Jul 5, 11:49 pm, David Mark <> wrote:
    >>> On Jul 5, 11:56 pm, Peter Michaux <> wrote:
    >>>> On Jul 5, 8:11 pm, David Mark <> wrote:
    >>>>> It has nothing to do with standards. It's good design vs. bad. If
    >>>>> you find yourself cramming an entire application that looks like
    >>>>> multiple documents into one document,
    >>> Aha! So, the user should not expect bookmarking a single document to
    >>> preserve the state.

    >> But I think the user *does* expect bookmarking to work. I'm a user. I
    >> expect it to work.

    >
    > They expect it to bookmark the page, not preserve *state*. Nobody
    > would. Not in the whole history of Web browsers has that ever
    > worked. It's just "Web2.0" script kiddie nonsense that does that and
    > it's never been prevalent enough to supplant previous expectations
    > about bookmark behavior.


    Apparently it's past time for a reality check:

    <http://validator.w3.org/#validate_by_input>


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, Jul 7, 2009
    #11
  12. Peter Michaux

    David Mark Guest

    Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 7, 3:52 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > David Mark wrote:
    > > On Jul 6, 12:11 pm, Peter Michaux <> wrote:
    > >> On Jul 5, 11:49 pm, David Mark <> wrote:
    > >>> On Jul 5, 11:56 pm, Peter Michaux <> wrote:
    > >>>> On Jul 5, 8:11 pm, David Mark <> wrote:
    > >>>>> It has nothing to do with standards.  It's good design vs. bad.  If
    > >>>>> you find yourself cramming an entire application that looks like
    > >>>>> multiple documents into one document,
    > >>> Aha!  So, the user should not expect bookmarking a single document to
    > >>> preserve the state.
    > >> But I think the user *does* expect bookmarking to work. I'm a user. I
    > >> expect it to work.

    >
    > > They expect it to bookmark the page, not preserve *state*.  Nobody
    > > would.  Not in the whole history of Web browsers has that ever
    > > worked.  It's just "Web2.0" script kiddie nonsense that does that and
    > > it's never been prevalent enough to supplant previous expectations
    > > about bookmark behavior.

    >
    > Apparently it's past time for a reality check:
    >
    > <http://validator.w3.org/#validate_by_input>


    Broken by design (try using the back button) and that site is a crock
    anyway (what sort of reality check is that?)
     
    David Mark, Jul 7, 2009
    #12
  13. Peter Michaux

    David Mark Guest

    Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 7, 3:52 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > David Mark wrote:
    > > On Jul 6, 12:11 pm, Peter Michaux <> wrote:
    > >> On Jul 5, 11:49 pm, David Mark <> wrote:
    > >>> On Jul 5, 11:56 pm, Peter Michaux <> wrote:
    > >>>> On Jul 5, 8:11 pm, David Mark <> wrote:
    > >>>>> It has nothing to do with standards.  It's good design vs. bad.  If
    > >>>>> you find yourself cramming an entire application that looks like
    > >>>>> multiple documents into one document,
    > >>> Aha!  So, the user should not expect bookmarking a single document to
    > >>> preserve the state.
    > >> But I think the user *does* expect bookmarking to work. I'm a user. I
    > >> expect it to work.

    >
    > > They expect it to bookmark the page, not preserve *state*.  Nobody
    > > would.  Not in the whole history of Web browsers has that ever
    > > worked.  It's just "Web2.0" script kiddie nonsense that does that and
    > > it's never been prevalent enough to supplant previous expectations
    > > about bookmark behavior.

    >
    > Apparently it's past time for a reality check:
    >
    > <http://validator.w3.org/#validate_by_input>
    >


    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?

    Reality check indeed (for you.)
     
    David Mark, Jul 7, 2009
    #13
  14. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 8, 9:43 am, David Mark <> wrote:
    > On Jul 7, 3:52 pm, Thomas 'PointedEars' Lahn <>
    > wrote:
    >
    >
    >
    >
    >
    > > David Mark wrote:
    > > > On Jul 6, 12:11 pm, Peter Michaux <> wrote:
    > > >> On Jul 5, 11:49 pm, David Mark <> wrote:
    > > >>> On Jul 5, 11:56 pm, Peter Michaux <> wrote:
    > > >>>> On Jul 5, 8:11 pm, David Mark <> wrote:
    > > >>>>> It has nothing to do with standards.  It's good design vs. bad. If
    > > >>>>> you find yourself cramming an entire application that looks like
    > > >>>>> multiple documents into one document,
    > > >>> Aha!  So, the user should not expect bookmarking a single document to
    > > >>> preserve the state.
    > > >> But I think the user *does* expect bookmarking to work. I'm a user. I
    > > >> expect it to work.

    >
    > > > They expect it to bookmark the page, not preserve *state*.  Nobody
    > > > would.  Not in the whole history of Web browsers has that ever
    > > > worked.  It's just "Web2.0" script kiddie nonsense that does that and
    > > > it's never been prevalent enough to supplant previous expectations
    > > > about bookmark behavior.

    >
    > > Apparently it's past time for a reality check:

    >
    > > <http://validator.w3.org/#validate_by_input>

    >
    > 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?
    >
    > Reality check indeed (for you.)


    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 with Ajax behaviors to
    build highly interactive and usable websites.

    For example:

    > Bookmarks are for documents and it is very hard
    > to break that feature. The average user knows
    > nothing about what "state" should be saved with a bookmark"


    And..

    > They expect it to bookmark the page, not preserve *state*.
    > Nobody would. Not in the whole history of Web browsers
    > has that ever worked.


    I disagree. If the state of the page has changed significantly then
    users absolutely expect the bookmark to carry the state. Remember, not
    a lot of users are even conscious of the URL or what it means.

    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. The point is not
    whether this is good usability or not (that decision will be made
    elsewhere), but whether it can be implemented.

    Btw, it seems odd that small players like Gmail and Facebook
    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.
     
    Hamish Campbell, Jul 8, 2009
    #14
  15. Peter Michaux

    David Mark Guest

    Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 7, 7:26 pm, Hamish Campbell <> wrote:
    > On Jul 8, 9:43 am, David Mark <> wrote:
    >
    >
    >
    > > On Jul 7, 3:52 pm, Thomas 'PointedEars' Lahn <>
    > > wrote:

    >
    > > > David Mark wrote:
    > > > > On Jul 6, 12:11 pm, Peter Michaux <> wrote:
    > > > >> On Jul 5, 11:49 pm, David Mark <> wrote:
    > > > >>> On Jul 5, 11:56 pm, Peter Michaux <> wrote:
    > > > >>>> On Jul 5, 8:11 pm, David Mark <> wrote:
    > > > >>>>> It has nothing to do with standards.  It's good design vs. bad.  If
    > > > >>>>> you find yourself cramming an entire application that looks like
    > > > >>>>> multiple documents into one document,
    > > > >>> Aha!  So, the user should not expect bookmarking a single document to
    > > > >>> preserve the state.
    > > > >> But I think the user *does* expect bookmarking to work. I'm a user.. I
    > > > >> expect it to work.

    >
    > > > > They expect it to bookmark the page, not preserve *state*.  Nobody
    > > > > would.  Not in the whole history of Web browsers has that ever
    > > > > worked.  It's just "Web2.0" script kiddie nonsense that does thatand
    > > > > it's never been prevalent enough to supplant previous expectations
    > > > > about bookmark behavior.

    >
    > > > Apparently it's past time for a reality check:

    >
    > > > <http://validator.w3.org/#validate_by_input>

    >
    > > 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?

    >
    > > Reality check indeed (for you.)

    >
    > 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 with Ajax behaviors to
    > build highly interactive and usable websites.


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

    Did you see the best example Thomas could come up with? Do you
    understand how it illustrates how few people know enough to accomplish
    this particular enhancement (without breaking the browser?) 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.

    >
    > For example:
    >
    > > Bookmarks are for documents and it is very hard
    > > to break that feature.  The average user knows
    > > nothing about what "state" should be saved with a bookmark"

    >
    > And..
    >
    > > They expect it to bookmark the page, not preserve *state*.
    > > Nobody would.  Not in the whole history of Web browsers
    > > has that ever worked.

    >
    > I disagree. If the state of the page has changed significantly then
    > users absolutely expect the bookmark to carry the state.


    LOL. Then there are a lot of disappointed users out there as
    bookmarks do no such thing. Never have. Thomas' (bad) example is
    just three document fragments that have been rearranged with script to
    look like a tabbed dialog. That's not state.

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

    > Remember, not
    > a lot of users are even conscious of the URL or what it means.


    Again, that's my point. So why are you worrying about creating an
    illusion for users with no expectations to begin with. 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.) As
    illustrated, even with a simplified example, the crack W3C developers
    blew it.

    >
    > Before DOM manipulation came along and made things complicated, the
    > intent of the URL was to return you to the same resource every time.


    That has no meaning.

    > Nothing has really changed except that developers have started adding
    > lots of state changes within a single document.


    That's not new. It started with IE4. BTW, I was there. ;)

    > Providing equivalent
    > browser-friendly navigation manipulation has been slow to catch up,


    Wrong. Navigation is as it has always been. Just as with popup
    windows, there are lots of incompetent developers out there trying to
    muck it up.

    > but the point of this discussion is to talk about how, not to say
    > "just don't do".


    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.

    >
    > But those arguments are not even a discussion for this group.


    They aren't really arguments at all.

    > There
    > are plenty of other groups who are much more attuned to the needs of
    > [non-expert] users then a JavaScript language group. The point is not
    > whether this is good usability or not (that decision will be made
    > elsewhere), but whether it can be implemented.


    It's just stupid. Usability is often compromised, but that is just a
    side effect.

    >
    > Btw, it seems odd that small players like Gmail and Facebook
    > 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.


    You couldn't be more wrong (on all counts.) How many Web developers
    on the planet know the first thing about progressive enhancement? And
    who wrote the proverbial book on it?

    I suggest that Google's JS developers are completely clueless, even
    about basic accessibility issues. Go to their "My Account" page and
    see how their menu reads without images. Then click "Adsense" and
    notice that the back button breaks. Doesn't get any more basic than
    that (and that's just the tip of the iceberg.)

    And Facebook is no better. I can't believe I'm hearing this argument
    about names again. See how Thomas got burned by assuming the W3C
    developers had a clue? Now you want to use Facebook as an example?
    And do you really think that they asked their users if they wanted a #$
    %@! slide show to disrupt their browsing history? Most of the users
    would have said: huh?

    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, but were not asked to articulate their
    position to Facebook's incompetent Web designers.

    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?
     
    David Mark, Jul 8, 2009
    #15
  16. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 8, 11:55 am, David Mark <> wrote:

    > > Remember, not
    > > a lot of users are even conscious of the URL or what it means.

    >
    > Again, that's my point. So why are you worrying about creating an
    > illusion for users with no expectations to begin with. 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.) As
    > illustrated, even with a simplified example, the crack W3C developers
    > blew it.


    I see where you're coming from, but I wonder - I got an email today
    for a conference that included a maps link that took be straight to
    the right location with popup (Google Maps). That was very useful.

    Would it be fair to say then, that it has a place for specific uses
    (such as non-discrete data like map locations)?

    > > Nothing has really changed except that developers have started adding
    > > lots of state changes within a single document.

    >
    > That's not new. It started with IE4. BTW, I was there. ;)


    You know what I mean - every man and his dog using XHR to load page
    content - for example.

    > > Providing equivalent
    > > browser-friendly navigation manipulation has been slow to catch up,

    >
    > Wrong. Navigation is as it has always been. Just as with popup
    > windows, there are lots of incompetent developers out there trying to
    > muck it up.


    Popup windows where blocked by vendors because people hated them, not
    because they were incompetendly implemented or broke browser
    functionality. There is not going to be a [conscious] user backlash
    against hash-links. People might stop using websites that use hash-
    links because they [unconsciously] find the website hard to use, but I
    don't see that happening.

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

    > I suggest that Google's JS developers are completely clueless, even
    > about basic accessibility issues. Go to their "My Account" page and
    > see how their menu reads without images. Then click "Adsense" and
    > notice that the back button breaks. Doesn't get any more basic than
    > that (and that's just the tip of the iceberg.)


    Heh, my biggest complaint about Gmail is there insistence on moving
    the cursor to next input element on page load - except that I'm
    already half-way through typing my username by that point so I get
    shunted to the password field.

    You are right that they're not exactly shining lights in that regard,
    but still, they've raised the expectation of what is possible.
     
    Hamish Campbell, Jul 8, 2009
    #16
  17. Peter Michaux

    David Mark Guest

    Re: single page apps, URL hash setting, bookmarking, & the backbutton.

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

    [snip]

    > Btw, it seems odd that small players like Gmail and Facebook
    > 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.


    Well, we already know about Google's dilapidated properties. How
    about Facebook?

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

    I'm sure they know people use their sites with IE, so why use XHTML.
    No rurprise that it is not really XHTML:

    http://validator.w3.org/check?uri=h...(detect automatically)&doctype=Inline&group=0

    Errors found while checking this document as XHTML 1.0 Strict!
    Result: 68 Errors, 6 warning(s)

    So it really isn't "strict" anything. Just tag soup. So why would
    these user-conscious developers use a dead language (or rather pretend
    to use a dead language?) They probably copied and pasted it and
    didn't ask their users at all.

    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"
    id="facebook">

    What a waste.

    <head>
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />

    I knew it.

    <meta http-equiv="Content-language" content="en" />
    <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

    Pfft.

    <script type="text/javascript">
    //<![CDATA[

    Gobbledygook.

    [snip a bunch of useless BS]

    //]]>
    </script><noscript> <meta http-equiv=refresh content="0; URL=http://
    www.facebook.com/?_fb_noscript=1" /> </noscript>

    Aha! There's the most basic degradation question: what does it do
    without scripting? Not that.

    Still want to learn from these guys? It should be obvious after five
    minutes and a few dozen lines of markup (excluding bloated inline
    scripts) that these particular developers don't know anything.
     
    David Mark, Jul 8, 2009
    #17
  18. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    David Mark wrote:

    > <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    >
    > I knew it.


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

    Andrew Poulos
     
    Andrew Poulos, Jul 8, 2009
    #18
  19. Peter Michaux

    David Mark Guest

    Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 7, 8:25 pm, Hamish Campbell <> wrote:
    > On Jul 8, 11:55 am, David Mark <> wrote:
    >
    > > > Remember, not
    > > > a lot of users are even conscious of the URL or what it means.

    >
    > > Again, that's my point.  So why are you worrying about creating an
    > > illusion for users with no expectations to begin with.  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.)  As
    > > illustrated, even with a simplified example, the crack W3C developers
    > > blew it.

    >
    > I see where you're coming from, but I wonder - I got an email today
    > for a conference that included a maps link that took be straight to
    > the right location with popup (Google Maps). That was very useful.


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

    >
    > Would it be fair to say then, that it has a place for specific uses
    > (such as non-discrete data like map locations)?


    We aren't talking about the same thing.

    >
    > > > Nothing has really changed except that developers have started adding
    > > > lots of state changes within a single document.

    >
    > > That's not new.  It started with IE4.  BTW, I was there.  ;)

    >
    > You know what I mean - every man and his dog using XHR to load page
    > content - for example.
    >
    > > > Providing equivalent
    > > > browser-friendly navigation manipulation has been slow to catch up,

    >
    > > Wrong.  Navigation is as it has always been.  Just as with popup
    > > windows, there are lots of incompetent developers out there trying to
    > > muck it up.

    >
    > Popup windows where blocked by vendors because people hated them, not
    > because they were incompetendly implemented or broke browser
    > functionality.


    Incompetence and broken browser behavior were definite factors (with
    particular emphasis on the former.)

    > There is not going to be a [conscious] user backlash
    > against hash-links. People might stop using websites that use hash-
    > links because they [unconsciously] find the website hard to use, but I
    > don't see that happening.


    If the bar is only to avoid a world-wide backlash, then virtually
    every design is successful.

    >
    > My point is this: the way in which many websites work has changed, for
    > good or for bad.


    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.

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


    You aren't making any sense at all here. The point is to let the
    browser handle the navigation. That's what it has always done. State
    changes have nothing to do with navigation. They never have. If you
    want to persist state, use a cookie.

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


    I already told you. Leave the location alone. Are you implying there
    is some really cool Website idea that cannot be implemented without
    resorting to faux navigation? Somehow it would confuse the users
    otherwise? I'm telling you there isn't. Additionally, the number of
    ways you can screw it up should be your first indication that I am
    right to recommend complete avoidance.

    >
    > > I suggest that Google's JS developers are completely clueless, even
    > > about basic accessibility issues.  Go to their "My Account" page and
    > > see how their menu reads without images.  Then click "Adsense" and
    > > notice that the back button breaks.  Doesn't get any more basic than
    > > that (and that's just the tip of the iceberg.)

    >
    > Heh, my biggest complaint about Gmail is there insistence on moving
    > the cursor to next input element on page load - except that I'm
    > already half-way through typing my username by that point so I get
    > shunted to the password field.


    Woohoo! I just signed up for a completely accessible, usable Web mail
    service hosted by a huge company that can surely afford droves of
    competent Web developers.

    It's called GMail. DOH! Thr abject failure of all three examples
    cited in this thread (W3C, Google and Facebook--see other post on
    them) is your second indication.

    >
    > You are right that they're not exactly shining lights in that regard,
    > but still, they've raised the expectation of what is possible.


    They've shown some very bad things are possible. Bad things that
    occasionally resemble good ideas to people who either aren't thinking
    clearly or have no idea what they are looking at. I put it to you
    that their Ajax-Web2.0 nonsense would have looked like old hat to me
    in 1998. The Web has caught up to what is possible, but virtually
    everything is being done wrong.
     
    David Mark, Jul 8, 2009
    #19
  20. Peter Michaux

    David Mark Guest

    Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 7, 8:52 pm, Andrew Poulos <> wrote:
    > David Mark wrote:
    > > <meta http-equiv="Content-type" content="text/html; charset=utf-8" />

    >
    > > I knew it.

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


    It is certainly out of place in an XHTML document.
     
    David Mark, Jul 8, 2009
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. vMike

    Bookmarking by User question

    vMike, Jan 24, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    312
    Natty Gur
    Jan 27, 2004
  2. sylvia sil
    Replies:
    1
    Views:
    625
    Curt_C [MVP]
    Dec 29, 2004
  3. rp
    Replies:
    1
    Views:
    543
    red floyd
    Nov 10, 2011
  4. timothytoe

    Adding data to URL for bookmarking

    timothytoe, Apr 14, 2008, in forum: Javascript
    Replies:
    3
    Views:
    89
    timothytoe
    Apr 14, 2008
  5. Peter Michaux
    Replies:
    30
    Views:
    731
    David Mark
    Jul 14, 2009
Loading...

Share This Page