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? Would you use the technique again? Would you advise against
    it?

    Peter
    Peter Michaux, Jun 26, 2009
    #1
    1. Advertising

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

    On Jul 3, 8:52 pm, kangax <> wrote:
    > 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". 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!

    >
    > I see that Safari 2.0.4 (last one in 2.x series) refreshes the page (or
    > rather goes into some kind of an infinite loading state). 3 series
    > (3.0.4) already doesn't have such "problem". There are still users with
    > Safari 2.x out there, of course, but I suppose much fewer than two years
    > ago.
    >
    > If Safari 2.x refreshes the page, doesn't it mean that users get page
    > refresh but still end up with a proper hash in an address bar and so can
    > bookmark it?
    >
    > It also appears that Opera 8.54 refreshes the page, but 9.5 already
    > doesn't (on Mac OSX). I couldn't test any other ones in between.


    Thanks for looking into those versions! I now remember that infinite
    loading business with Safari and Yahoo! Maps.

    Yes refreshing means the page still ends up having the hash but the
    general goal of speediness due to not refreshing the page is lost. If
    all browsers refreshed when setting the hash, I would guess no one
    would use the approach I described.

    Peter
    Peter Michaux, Jul 4, 2009
    #2
    1. Advertising

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


    It also causes the browser to scroll the element into view. This can be
    implicated in a degradation strategy.

    I've been using that RESTful technique for about eight years.

    --
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Jul 6, 2009
    #3
  4. Peter Michaux

    David Mark Guest

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

    On Jul 6, 3:57 am, Garrett Smith <> wrote:
    > 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". 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.

    >
    > It also causes the browser to scroll the element into view. This can be
    > implicated in a degradation strategy.
    >
    > I've been using that RESTful technique for about eight years.


    Haven't we all. But it is hardly appropriate here. There's no
    element to scroll to (and these apps don't work without scripting.)

    The main lesson here is that the user who expects *page* bookmarks to
    persist the current state of the page exists only in the minds of
    developers (perhaps they are thinking of themselves.)
    David Mark, Jul 6, 2009
    #4
  5. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 6, 1:02 am, David Mark <> wrote:

    > The main lesson here is that the user who expects *page* bookmarks to


    You are still thinking of the web is a collection of pages. I don't
    think the situation is that simple anymore.

    Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?
    I doubt you do. They are applications. In many applications when you
    reopen them they return to the state they were last in. Wouldn't it be
    great to be able to bookmark a few different states and then open
    directly to those states? My text editor does this in a way with
    "projects" and I like it a lot.

    As applications are deployed on the web as single-page apps, for lack
    of a better term, we want to have more advanced navigation suitable to
    an app.

    I was just using Facebook to look at some photos from a friend. I was
    clicking "next" repeatedly and the application was replacing only the
    image and the URL hash. It was very snappy and I didn't have to scroll
    down or see a jarring jump scroll down with each page load.

    > persist the current state of the page exists only in the minds of
    > developers (perhaps they are thinking of themselves.)


    I don't think so. While looking at the photos, it looks like the page
    is changing because the focal part of the page is changing. Because it
    seems like the page is changing, I and I think any user who is
    accustom to page changes expect the URL to always be representative of
    the page being viewed. To get the smooth and snappy forward navigation
    of "Ajax updates", that means keeping the URL in sync with the content
    using URL hash-setting.

    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 6, 12:26 pm, Peter Michaux <> wrote:
    > On Jul 6, 1:02 am, David Mark <> wrote:
    >
    > > The main lesson here is that the user who expects *page* bookmarks to

    >
    > You are still thinking of the web is a collection of pages. I don't
    > think the situation is that simple anymore.


    I'm thinking of what bookmarks do. Obviously I know some pages can be
    interactive.

    >
    > Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?


    What does that mean?

    > I doubt you do. They are applications. In many applications when you
    > reopen them they return to the state they were last in.


    So? Lots of documents do that to, typically with cookies. Who cares?

    > Wouldn't it be
    > great to be able to bookmark a few different states and then open
    > directly to those states?


    It's not that great and not new.

    > My text editor does this in a way with
    > "projects" and I like it a lot.


    Why are you telling me this? Unless it is on a Mac, I probably wrote
    your text editor. If it actually restores its size and state
    properly, that's mine. If it comes up maximized then "restores" to
    the same size or comes up minimized, etc.; that's somebody else. But
    seriously, can we cut to the chase?

    >
    > As applications are deployed on the web as single-page apps, for lack
    > of a better term, we want to have more advanced navigation suitable to
    > an app.


    Who is we? And we don't always get what we want. Browsers are
    browsers, not operating systems. Do you see how they will never be
    the latter? Web3.0 (whatever it may be) will not involve scripted
    navigation hacks. Why waste time trying and testing (and discussing!)
    such nonsense?

    >
    > I was just using Facebook to look at some photos from a friend. > I was
    > clicking "next" repeatedly and the application was replacing only the
    > image and the URL hash. It was very snappy and I didn't have to scroll
    > down or see a jarring jump scroll down with each page load.


    A slide show? Is this whole series of questions a joke?

    >
    > > persist the current state of the page exists only in the minds of
    > > developers (perhaps they are thinking of themselves.)

    >
    > I don't think so. While looking at the photos, it looks like the page
    > is changing because the focal part of the page is changing.


    Fooling yourself. Slide shows don't imply navigation. It looks to
    you like you are navigating because some script is navigating for you
    in an ill-advised attempt to make one document look like several. If
    it didn't create that illusion of navigation, it wouldn't raise
    expectations about bookmarks.

    > Because it
    > seems like the page is changing, I and I think any user who is
    > accustom to page changes expect the URL to always be representative of
    > the page being viewed. To get the smooth and snappy forward navigation
    > of "Ajax updates", that means keeping the URL in sync with the content
    > using URL hash-setting.


    Smooth and snappy? I think I'm going to vomit. You are used to pages
    with unload listeners.
    David Mark, Jul 6, 2009
    #6
  7. Peter Michaux

    David Mark Guest

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

    On Jul 6, 12:26 pm, Peter Michaux <> wrote:
    > On Jul 6, 1:02 am, David Mark <> wrote:
    >
    > > The main lesson here is that the user who expects *page* bookmarks to

    >
    > You are still thinking of the web is a collection of pages. I don't
    > think the situation is that simple anymore.
    >
    > Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?
    > I doubt you do. They are applications. In many applications when you
    > reopen them they return to the state they were last in. Wouldn't it be
    > great to be able to bookmark a few different states and then open
    > directly to those states? My text editor does this in a way with
    > "projects" and I like it a lot.
    >
    > As applications are deployed on the web as single-page apps, for lack
    > of a better term, we want to have more advanced navigation suitable to
    > an app.
    >
    > I was just using Facebook to look at some photos from a friend. I was
    > clicking "next" repeatedly and the application was replacing only the
    > image and the URL hash. It was very snappy and I didn't have to scroll
    > down or see a jarring jump scroll down with each page load.
    >
    > > persist the current state of the page exists only in the minds of
    > > developers (perhaps they are thinking of themselves.)

    >
    > I don't think so. While looking at the photos, it looks like the page
    > is changing because the focal part of the page is changing.


    Also, swapping images on a document does not indicate navigation to
    any group I can think of. Slide shows typically have their own
    forward and back buttons as well.

    You mentioned above that the page doesn't scroll. I assume then that
    this slide show is not at the top of the document either. The fact
    that it does *not* scroll is a dead giveaway to any user savvy enough
    to pay attention that the browser did *not* navigate, so there's no
    need to twiddle with the history to avert potential confusion (there
    is no confusion.)

    I'd be surprised as hell if a slide show broke my browser's back and
    forward buttons (and more than a little put off by such a silly design
    decision.) In other words, if I want to navigate back to the document
    before the one with the slide show, I better not see the slide show
    swap an image as a response to that action (else it is goodbye to that
    site.)

    > Because it
    > seems like the page is changing, I and I think any user who is
    > accustom to page changes expect the URL to always be representative of
    > the page being viewed. To get the smooth and snappy forward navigation
    > of "Ajax updates", that means keeping the URL in sync with the content
    > using URL hash-setting.


    Having written about a hundred slide shows and re-vamping dozens more,
    I've never seen such a thing, nor can I imagine how it would make
    swapping images any more smooth or snappy.
    David Mark, Jul 7, 2009
    #7
  8. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 6, 6:38 pm, David Mark <> wrote:
    > On Jul 6, 12:26 pm, Peter Michaux <> wrote:
    > > On Jul 6, 1:02 am, David Mark <> wrote:


    > You mentioned above that the page doesn't scroll.  I assume then that
    > this slide show is not at the top of the document either.  The fact
    > that it does *not* scroll is a dead giveaway to any user savvy enough
    > to pay attention that the browser did *not* navigate, so there's no
    > need to twiddle with the history to avert potential confusion (there
    > is no confusion.)


    I think the user group you are describing is *extremely* small. The
    people on c.l.js may be some of the only members of such a group. Many
    people don't know what a "browser" is.

    http://pleaseenjoy.com/project.php?cat=4&subcat=&pid=131&navpoint=2

    If I use the word "browser" to non-programmers, people frequently
    scrunch up their face until I say "Internet Explorer", "Firefox", or
    "Safari". If I choose to say the name of a browser they don't use they
    get even more confused.

    If they don't know what a browser is they are not likely going to
    notice or understand the subtitles of scrolling on page load.

    > I'd be surprised as hell if a slide show broke my browser's back and
    > forward buttons (and more than a little put off by such a silly design
    > decision.)  In other words, if I want to navigate back to the document
    > before the one with the slide show, I better not see the slide show
    > swap an image as a response to that action (else it is goodbye to that
    > site.)


    I like the opposite behavior you do. In fact, that means I like the
    traditional, non-JavaScript, history behavior where each picture in
    the slide show has its own complete HTML page.

    > > Because it
    > > seems like the page is changing, I and I think any user who is
    > > accustom to page changes expect the URL to always be representative of
    > > the page being viewed. To get the smooth and snappy forward navigation
    > > of "Ajax updates", that means keeping the URL in sync with the content
    > > using URL hash-setting.

    >
    > Having written about a hundred slide shows and re-vamping dozens more,
    > I've never seen such a thing, nor can I imagine how it would make
    > swapping images any more smooth or snappy.


    Setting the URL hash when changing the image in a slide show does not
    make it snappier. It does increase intuitive usability for bookmarking
    and emailing the current image's link since it is always up-to-date in
    the browser's address bar. Whether or not the URL for each image is
    added to the history is an independent issue but I think adding it for
    a slide show is a good idea. Adding it for Yahoo! Maps may not be a
    good idea as the user may be making many temporary changes along the
    way.

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

    David Mark Guest

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

    On Jul 6, 11:34 pm, Peter Michaux <> wrote:
    > On Jul 6, 6:38 pm, David Mark <> wrote:
    >
    > > On Jul 6, 12:26 pm, Peter Michaux <> wrote:
    > > > On Jul 6, 1:02 am, David Mark <> wrote:

    > > You mentioned above that the page doesn't scroll.  I assume then that
    > > this slide show is not at the top of the document either.  The fact
    > > that it does *not* scroll is a dead giveaway to any user savvy enough
    > > to pay attention that the browser did *not* navigate, so there's no
    > > need to twiddle with the history to avert potential confusion (there
    > > is no confusion.)

    >
    > I think the user group you are describing is *extremely* small. The
    > people on c.l.js may be some of the only members of such a group. Many
    > people don't know what a "browser" is.
    >
    >  http://pleaseenjoy.com/project.php?cat=4&subcat=&pid=131&navpoint=2
    >
    > If I use the word "browser" to non-programmers, people frequently
    > scrunch up their face until I say "Internet Explorer", "Firefox", or
    > "Safari". If I choose to say the name of a browser they don't use they
    > get even more confused.
    >
    > If they don't know what a browser is they are not likely going to
    > notice or understand the subtitles of scrolling on page load.
    >
    > > I'd be surprised as hell if a slide show broke my browser's back and
    > > forward buttons (and more than a little put off by such a silly design
    > > decision.)  In other words, if I want to navigate back to the document
    > > before the one with the slide show, I better not see the slide show
    > > swap an image as a response to that action (else it is goodbye to that
    > > site.)

    >
    > I like the opposite behavior you do. In fact, that means I like the
    > traditional, non-JavaScript, history behavior where each picture in
    > the slide show has its own complete HTML page.


    Then write it like that and make sure the slide show is the focal
    point of the document (unlike what you described before.) You don't
    need to try to simulate navigation. Browsers know how to do it and do
    it very well.

    >
    > > > Because it
    > > > seems like the page is changing, I and I think any user who is
    > > > accustom to page changes expect the URL to always be representative of
    > > > the page being viewed. To get the smooth and snappy forward navigation
    > > > of "Ajax updates", that means keeping the URL in sync with the content
    > > > using URL hash-setting.

    >
    > > Having written about a hundred slide shows and re-vamping dozens more,
    > > I've never seen such a thing, nor can I imagine how it would make
    > > swapping images any more smooth or snappy.

    >
    > Setting the URL hash when changing the image in a slide show does not
    > make it snappier. It does increase intuitive usability for bookmarking
    > and emailing the current image's link since it is always up-to-date in
    > the browser's address bar. Whether or not the URL for each image is
    > added to the history is an independent issue but I think adding it for
    > a slide show is a good idea. Adding it for Yahoo! Maps may not be a
    > good idea as the user may be making many temporary changes along the
    > way.


    Making an image swapper twiddle the location to simulate navigation is
    a *terrible* idea. Think about it.
    David Mark, Jul 7, 2009
    #9
  10. Peter Michaux

    David Mark Guest

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

    On Jul 6, 11:34 pm, Peter Michaux <> wrote:
    > On Jul 6, 6:38 pm, David Mark <> wrote:
    >
    > > On Jul 6, 12:26 pm, Peter Michaux <> wrote:
    > > > On Jul 6, 1:02 am, David Mark <> wrote:

    > > You mentioned above that the page doesn't scroll.  I assume then that
    > > this slide show is not at the top of the document either.  The fact
    > > that it does *not* scroll is a dead giveaway to any user savvy enough
    > > to pay attention that the browser did *not* navigate, so there's no
    > > need to twiddle with the history to avert potential confusion (there
    > > is no confusion.)

    >
    > I think the user group you are describing is *extremely* small. The
    > people on c.l.js may be some of the only members of such a group. Many
    > people don't know what a "browser" is.


    You are making my point for me, so I assume you didn't understand.
    There is no need to simulate navigation if there is no confusion (and
    there can't be any confusion for people who aren't paying attention or
    don't know what they are looking at in the first place.) You are
    programming for that small group of people who know the difference and
    they don't want you to mess with their navigation history.

    [snip]
    David Mark, Jul 7, 2009
    #10
  11. Peter Michaux

    Matt Kruse Guest

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

    On Jul 6, 11:26 am, Peter Michaux <> wrote:
    > Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?
    > I doubt you do. They are applications. In many applications when you
    > reopen them they return to the state they were last in. Wouldn't it be
    > great to be able to bookmark a few different states and then open
    > directly to those states?


    Just a side note to this long and mostly fruitless discussion...

    The "state" of a page is very open to interpretation. I think what you
    are arguing for is for some intelligence on the part of the web site/
    app in making sure that the url shown in the address bar will return
    the user to a reasonable location to view what they are currently
    viewing.

    For example, if I compose an email in GMail and bookmark it halfway
    through writing, I don't expect that bookmark to always take me back
    to a half-written email. If I'm partially scrolled down through a long
    document, I don't expect the url to take me back to the exact scroll
    point.

    If I'm looking through an interactive slideshow of pictures, I
    wouldn't expect the url to return me to the exact picture I'm looking
    at, but rather the beginning of the slideshow itself. You may think it
    should go directly to the picture. The "right" way to handle it
    depends on the users, the site/app, and context. It's those sites that
    do it well and give users what they reasonably expect that become
    popular.

    Despite David's baseless objections, I think that intelligent use of
    hashes to form a reusable/shareable url is a great thing. It's not
    perfect, and it will probably be replaced in the future with a better
    alternative, but for right now it works. And it's very handy. Use it,
    but be sure to consider what your users expect to return to when they
    are viewing any particular url.

    I think that objections like "that's not what it's meant for" or "it
    breaks my fast navigation" or "there are better ways to do it" are
    irrelevant sometimes. Just like life, technical solutions evolve. They
    are not designed from the top down to be strictly correct and logical.
    What we work with in web design is a combination of thousands of
    layers of technological innovations piled on top of each other over
    decades of hacking and trying out new ideas. Not perfect, but good
    enough. It is the imaginative use of old ideas for new purposes that
    is the source of these innovations. Those who object to this
    advancement because they don't fit within their strict, stale model of
    how things "ought to be" will left behind to whine to people about the
    "good ol days" like some old man, while the people who embrace it will
    benefit from it and see greater ideas emerge. IMO.

    Matt Kruse
    Matt Kruse, Jul 8, 2009
    #11
  12. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 8, 10:50 am, Matt Kruse <> wrote:
    > On Jul 6, 11:26 am, Peter Michaux <> wrote:
    >
    > > Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?
    > > I doubt you do. They are applications. In many applications when you
    > > reopen them they return to the state they were last in. Wouldn't it be
    > > great to be able to bookmark a few different states and then open
    > > directly to those states?

    >
    > Just a side note to this long and mostly fruitless discussion...
    >
    > The "state" of a page is very open to interpretation. I think what you
    > are arguing for is for some intelligence on the part of the web site/
    > app in making sure that the url shown in the address bar will return
    > the user to a reasonable location to view what they are currently
    > viewing.


    Yes that is what I'm suggesting.


    > For example, if I compose an email in GMail and bookmark it halfway
    > through writing, I don't expect that bookmark to always take me back
    > to a half-written email.


    Perhaps you don't expect that but...

    Why are you bookmarking your half-written email? Are you bookmarking
    it because you want to have GMail, in general, bookmarked? Do you
    think the number of users who bookmark half way through writing an
    email want to bookmark GMail in general or is it so infrequently used
    that the ability to bookmark could be given a different goal?

    What if that bookmark did return you to your half-written email? Would
    that be bad? Perhaps you'd like it even though it wasn't what you
    expected?


    > If I'm partially scrolled down through a long
    > document, I don't expect the url to take me back to the exact scroll
    > point.


    When I read long page like the HTML specifications, the ability to
    bookmark a particular part of the page and return to it immediately is
    a benefit to me. At least for an unchanging page, that is very close
    to the concept of restoring the amount of page scroll. I can also post
    a link here to the middle of a page:

    http://www.w3.org/TR/html401/struct/lists.html#h-10.3.1


    > If I'm looking through an interactive slideshow of pictures, I
    > wouldn't expect the url to return me to the exact picture I'm looking
    > at, but rather the beginning of the slideshow itself. You may think it
    > should go directly to the picture. The "right" way to handle it
    > depends on the users, the site/app, and context. It's those sites that
    > do it well and give users what they reasonably expect that become
    > popular.


    Yes, in the end natural selection rules.


    > Despite David's baseless objections, I think that intelligent use of
    > hashes to form a reusable/shareable url is a great thing. It's not
    > perfect, and it will probably be replaced in the future with a better
    > alternative, but for right now it works.


    Thanks to kangax's response in this thread, I now know that HTML 5 is
    improving the use the hash for this purpose for the near future:

    http://groups.google.com/group/comp.lang.javascript/msg/b6da13ee3dcf1fd3


    > And it's very handy. Use it,
    > but be sure to consider what your users expect to return to when they
    > are viewing any particular url.
    >
    > I think that objections like "that's not what it's meant for" or "it
    > breaks my fast navigation" or "there are better ways to do it" are
    > irrelevant sometimes. Just like life, technical solutions evolve. They
    > are not designed from the top down to be strictly correct and logical.
    > What we work with in web design is a combination of thousands of
    > layers of technological innovations piled on top of each other over
    > decades of hacking and trying out new ideas. Not perfect, but good
    > enough. It is the imaginative use of old ideas for new purposes that
    > is the source of these innovations. Those who object to this
    > advancement because they don't fit within their strict, stale model of
    > how things "ought to be" will left behind to whine to people about the
    > "good ol days" like some old man, while the people who embrace it will
    > benefit from it and see greater ideas emerge. IMO.


    I agree.

    Not all new ideas are good ones or last even short tests of time. Some
    ideas do. The reason I started this thread is it seems that URL hash-
    setting has been perceived as useful by quite a few people and is
    implementable in a large percentage of currently used browsers.

    Peter
    Peter Michaux, Jul 8, 2009
    #12
  13. Peter Michaux

    David Mark Guest

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

    On Jul 8, 1:50 pm, Matt Kruse <> wrote:
    > On Jul 6, 11:26 am, Peter Michaux <> wrote:
    >
    > > Do you think of Microsoft Excel as a page? Is Adobe Photoshop a page?
    > > I doubt you do. They are applications. In many applications when you
    > > reopen them they return to the state they were last in. Wouldn't it be
    > > great to be able to bookmark a few different states and then open
    > > directly to those states?

    >
    > Just a side note to this long and mostly fruitless discussion...


    And what sort of fruit have you brought to the table?

    >
    > The "state" of a page is very open to interpretation. I think what you
    > are arguing for is for some intelligence on the part of the web site/
    > app in making sure that the url shown in the address bar will return
    > the user to a reasonable location to view what they are currently
    > viewing.


    Rotten.

    >
    > For example, if I compose an email in GMail and bookmark it halfway
    > through writing, I don't expect that bookmark to always take me back
    > to a half-written email. If I'm partially scrolled down through a long
    > document, I don't expect the url to take me back to the exact scroll
    > point.


    Not exactly fresh insights, but lucid at least.

    >
    > If I'm looking through an interactive slideshow of pictures, I
    > wouldn't expect the url to return me to the exact picture I'm looking
    > at, but rather the beginning of the slideshow itself. You may think it
    > should go directly to the picture. The "right" way to handle it
    > depends on the users, the site/app, and context. It's those sites that
    > do it well and give users what they reasonably expect that become
    > popular.


    LOL. Getting popular is about advertising, not ridiculous JS
    shenanigans.

    >
    > Despite David's baseless objections, I think that intelligent use of


    As usual, you can't read to save your life. I guess my "baseless"
    objections are like my "unwarranted" criticism of jQuery (which you
    requested in the first place.)

    > hashes to form a reusable/shareable url is a great thing.


    It's a great thing! Read your posts aloud before sending.

    > It's not
    > perfect, and it will probably be replaced in the future with a better
    > alternative, but for right now it works. And it's very handy.


    It works! See above (or virtually any other post on this subject.)
    It's very handy! Like hell. Use cookies, genius.

    > Use it,
    > but be sure to consider what your users expect to return to when they
    > are viewing any particular url.


    Oh sure, recommend something completely unneeded that is known to be
    broken in recent browsers (with something better on the horizon
    anyway.) What sort of an automatic rebuttal are you? Everything I
    say, you come along and offer a contradiction, no matter how much of a
    stretch. You sound like an idiot every time.

    >
    > I think that objections like "that's not what it's meant for" or "it
    > breaks my fast navigation" or "there are better ways to do it" are
    > irrelevant sometimes.


    I think that your posts are irrelevant sometimes. Be fair, virtually
    all of the time.

    > Just like life, technical solutions evolve. They


    Yeah, that's life. Again, invest in a tape recorder. See how you
    sound spouting this BS.

    > are not designed from the top down to be strictly correct and logical.


    You have the phony intellectual act down pat.

    > What we work with in web design is a combination of thousands of
    > layers of technological innovations piled on top of each other over
    > decades of hacking and trying out new ideas. Not perfect, but good
    > enough. It is the imaginative use of old ideas for new purposes that
    > is the source of these innovations.


    You are welcome. Whose innovations are replacing all of your old bad
    ideas (e.g. browser sniffing?)

    > Those who object to this
    > advancement because they don't fit within their strict, stale model of
    > how things "ought to be" will left behind to whine to people about the
    > "good ol days" like some old man, while the people who embrace it will
    > benefit from it and see greater ideas emerge. IMO.


    How out of touch are you? This hash-setting BS isn't even close to
    new. It's from around 2006. It was BS then and it is BS now. End of
    story.

    And what the hell have you innovated in the last few years? Your
    "toolbox" looks pretty stale and last I heard you were using jQuery
    1.2 w/ browser sniffing. Go back to your carp pool.
    David Mark, Jul 8, 2009
    #13
  14. Peter Michaux

    Matt Kruse Guest

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

    On Jul 8, 4:31 pm, David Mark <> wrote:
    > It works!  See above (or virtually any other post on this subject.)
    > It's very handy!  Like hell.  Use cookies, genius.


    Cookies don't solve the same problem. They are irrelevant.

    > Oh sure, recommend something completely unneeded that is known to be
    > broken in recent browsers (with something better on the horizon
    > anyway.)


    Oh I don't know, the concept works well for me. YMMV.

    > How out of touch are you?  This hash-setting BS isn't even close to
    > new.  It's from around 2006.  It was BS then and it is BS now.  Endof
    > story.


    Again, it seems to work well for major web sites. And it works well
    for me.

    > And what the hell have you innovated in the last few years?


    Various things.

    Matt Kruse
    Matt Kruse, Jul 9, 2009
    #14
  15. Peter Michaux

    David Mark Guest

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

    On Jul 8, 10:58 pm, Matt Kruse <> wrote:
    > On Jul 8, 4:31 pm, David Mark <> wrote:
    >
    > > It works!  See above (or virtually any other post on this subject.)
    > > It's very handy!  Like hell.  Use cookies, genius.

    >
    > Cookies don't solve the same problem. They are irrelevant.


    You haven't been following the conversation. All of the perceived
    "problems" have been addressed.

    >
    > > Oh sure, recommend something completely unneeded that is known to be
    > > broken in recent browsers (with something better on the horizon
    > > anyway.)

    >
    > Oh I don't know, the concept works well for me. YMMV.


    How exactly does a concept work? Are you saying it sings to you or
    something? In reality, it doesn't work (as has been demonstrated.)

    >
    > > How out of touch are you?  This hash-setting BS isn't even close to
    > > new.  It's from around 2006.  It was BS then and it is BS now.  End of
    > > story.

    >
    > Again, it seems to work well for major web sites.


    And how would you know that?

    > And it works well
    > for me.


    In what way? I bet if I saw your site (assuming it exists), I could
    tell you how it would work without these hacks. Could is the
    operative word. Doubtful I would bother as you are a lost cause.

    >
    > > And what the hell have you innovated in the last few years?

    >
    > Various things.


    Yes, you've really set the world on fire with those various things.
    Can't wait to see what stuff you come up with next.
    David Mark, Jul 9, 2009
    #15
  16. Peter Michaux

    Matt Kruse Guest

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

    On Jul 8, 10:04 pm, David Mark <> wrote:
    > > Cookies don't solve the same problem. They are irrelevant.

    > You haven't been following the conversation.  All of the perceived
    > "problems" have been addressed.


    I've read the whole thread. Using a url hash allows the sharing and
    bookmarking of url's to return to a given page in a web site/app in a
    given state or view. Cookies do not allow this.

    Your argument is that this functionality shouldn't even be required,
    thereby avoiding the "problems" altogether. Unfortunately for you, it
    is a useful and common feature, so your recommendation is irrelevant.

    > > Oh I don't know, the concept works well for me. YMMV.

    > How exactly does a concept work?


    Very well, as I said. Didn't you read?

    >  Are you saying it sings to you or
    > something?  In reality, it doesn't work (as has been demonstrated.)


    It does work. In some browsers, there are problems. I will gladly
    ignore those browser problems and just not support those browsers. Any
    users with those browsers simply can't use my site/app (or some of the
    functionality). No big deal. The advanced functionality offered by
    using the solution surely outweighs the fraction of a percentage of
    users that might experience problems. I will never code to the lowest
    common denominator just to avoid excluding a fraction of a percentage
    of potential users. It's not worth it.

    If you are worried about those few users with browsers that would have
    problems, then you are welcome to explore a different solution. YMMV.

    > > Again, it seems to work well for major web sites.

    > And how would you know that?


    Because these sites have many users. If they didn't function well,
    they would not have so many users.

    Sometimes you can actually make _more_ users happy be choosing to
    exclude a small set of users. That's a win.

    > In what way?  I bet if I saw your site (assuming it exists), I could
    > tell you how it would work without these hacks.


    Why would I care, if it already works _with_ these hacks?

    > > > And what the hell have you innovated in the last few years?

    > > Various things.

    > Yes, you've really set the world on fire with those various things.
    > Can't wait to see what stuff you come up with next.


    Awesome! Thanks for the support!

    Matt Kruse
    Matt Kruse, Jul 9, 2009
    #16
  17. Peter Michaux

    David Mark Guest

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

    On Jul 8, 11:39 pm, Matt Kruse <> wrote:
    > On Jul 8, 10:04 pm, David Mark <> wrote:
    >
    > > > Cookies don't solve the same problem. They are irrelevant.

    > > You haven't been following the conversation.  All of the perceived
    > > "problems" have been addressed.

    >
    > I've read the whole thread. Using a url hash allows the sharing and
    > bookmarking of url's to return to a given page in a web site/app in a
    > given state or view. Cookies do not allow this.
    >
    > Your argument is that this functionality shouldn't even be required,
    > thereby avoiding the "problems" altogether. Unfortunately for you, it
    > is a useful and common feature, so your recommendation is irrelevant.
    >
    > > > Oh I don't know, the concept works well for me. YMMV.

    > > How exactly does a concept work?

    >
    > Very well, as I said. Didn't you read?


    Try again. I said "a concept", not "the concept." Regardless,
    concepts don't do anything.

    >
    > >  Are you saying it sings to you or
    > > something?  In reality, it doesn't work (as has been demonstrated.)

    >
    > It does work.


    Sure. It just works.

    > In some browsers, there are problems.


    Oops, trouble in paradise.

    > I will gladly
    > ignore those browser problems and just not support those browsers.


    ....despite the fact that there are much better alternatives. I had
    mentioned the file menu as the only competition for whatever friendly
    "send link" interface you can dream up. Of course, that only works
    for some users. Others would have to copy and paste the URI (and some
    won't know how to do that at all.) A big, friendly "Send a friend
    here" button is looking better and better, isn't it? Those actually
    work in every browser for every user. I suppose the fear is that the
    more sophisticated users (those actually aware of the relationship
    between bookmarks and locations) will be confused if the browser UI
    doesn't exactly replicate the site behavior. Seems irrational.

    > Any
    > users with those browsers simply can't use my site/app (or some of the
    > functionality). No big deal.


    Um, sounds fatal. OTOH, it's no big deal to avoid the whole situation
    (unless you are an aspiring "Ajax developer" looking to spice up your
    profile.) Seems there is a conflict of interest in there somewhere.

    > The advanced functionality offered by
    > using the solution surely outweighs the fraction of a percentage of
    > users that might experience problems.


    Actually, no. Your "advanced" functionality is old hat and easily
    done better in other ways (see above.)

    > I will never code to the lowest
    > common denominator just to avoid excluding a fraction of a percentage
    > of potential users. It's not worth it.


    That's generalized (and inaccurate) pablum.

    >
    > If you are worried about those few users with browsers that would have
    > problems, then you are welcome to explore a different solution. YMMV.


    You always latch on to one tendril of an argument and ignore
    everything else. It doesn't vary in the slightest (even over the
    course of years.) Will you please just disappear over the horizon?

    >
    > > > Again, it seems to work well for major web sites.

    > > And how would you know that?

    >
    > Because these sites have many users. If they didn't function well,
    > they would not have so many users.


    Do you have any idea how stupid your "arguments" sound? I insist you
    try reading them aloud (perhaps to an audience of rational human
    beings) before dumping them here.

    >
    > Sometimes you can actually make _more_ users happy be choosing to
    > exclude a small set of users. That's a win.


    No, you forfeit as usual. Blathering is not arguing.

    >
    > > In what way?  I bet if I saw your site (assuming it exists), I could
    > > tell you how it would work without these hacks.

    >
    > Why would I care, if it already works _with_ these hacks?


    Because then you wouldn't need the hacks and wouldn't have to worry
    about how many users you've excluded.

    >
    > > > > And what the hell have you innovated in the last few years?
    > > > Various things.

    > > Yes, you've really set the world on fire with those various things.
    > > Can't wait to see what stuff you come up with next.

    >
    > Awesome! Thanks for the support!


    Yes, I'm a big fan of your stuff.
    David Mark, Jul 9, 2009
    #17
  18. Re: single page apps, URL hash setting, bookmarking, & the backbutton.

    On Jul 8, 9:37 pm, David Mark wrote:
    > On Jul 8, 11:39 pm, Matt Kruse wrote:


    > > Sometimes you can actually make _more_ users happy be choosing to
    > > exclude a small set of users. That's a win.

    >
    > No, you forfeit as usual.  Blathering is not arguing.


    How about responding to the idea Matt presented? It is a popular idea
    amongst successful marketeers: if you try to please everyone you end
    up pleasing no one.

    Peter
    Peter Michaux, Jul 9, 2009
    #18
  19. Peter Michaux

    David Mark Guest

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

    On Jul 9, 1:05 am, Peter Michaux <> wrote:
    > On Jul 8, 9:37 pm, David Mark wrote:
    >
    > > On Jul 8, 11:39 pm, Matt Kruse wrote:
    > > > Sometimes you can actually make _more_ users happy be choosing to
    > > > exclude a small set of users. That's a win.

    >
    > > No, you forfeit as usual.  Blathering is not arguing.

    >
    > How about responding to the idea Matt presented? It is a popular idea
    > amongst successful marketeers: if you try to please everyone you end
    > up pleasing no one.
    >


    The fact that you have Matt Kruse on your side should (finally)
    convince you that you've got the wrong end of the stick.

    As I have mentioned:

    1. There is no evidence that faux navigation pleases more users than
    it pisses off.

    2. You don't need it anyway; in fact, it adds nothing for the casual
    users that seem to be your biggest concern.

    The solution that works for everyone who allows it (e.g. they don't
    disable scripting and/or cookies) is to set a cookie to record state
    changes. Add a nice friendly button labeled "Send a Friend Here" (or
    whatever) that does a *real* navigation to a form. Your server side
    script has already populated the form with hidden fields based on the
    cookie. The user types in one or more email addresses and clicks
    "Send."

    The proposed solution leveraging the browser's file menu assumes:

    1. The user knows where the file menu is (and can actually get to it.)

    2. The user knows there is a file menu item to send a link.

    3. The user has a properly configured email client (lets out kiosk and
    cafe users.)

    If any of these are false, the presumably hapless user is left to copy
    and paste the location into a Webmail client.

    A friendly button of your own design that does everything for them
    under every conceivable circumstance *plus* avoids these silly and ill-
    advised end-arounds is clearly the best solution. Another bonus is
    that the state is preserved whether they use your specially marked
    bookmark or not.

    End of story? I'm really surprised you couldn't see it coming,
    despite my numerous telegraphs.
    David Mark, Jul 9, 2009
    #19
  20. Peter Michaux

    Matt Kruse Guest

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

    On Jul 8, 11:37 pm, David Mark <> wrote:
    > > In some browsers, there are problems.

    > Oops, trouble in paradise.


    It's not trouble. It's an acceptable fact. I have no problem with it.

    People using old, outdated browsers get broken or limited
    functionality. Big deal. They should upgrade.

    > > I will gladly
    > > ignore those browser problems and just not support those browsers.

    > ...despite the fact that there are much better alternatives.


    "Better" is a qualitative judgment. The alternatives are better in
    your mind. That does not make it so for everyone.

    > A big, friendly "Send a friend
    > here" button is looking better and better, isn't it?  Those actually
    > work in every browser for every user.  


    First, I don't care about _every_ user. Never have.

    Second, your "button" doesn't help in other cases. For example,
    bookmarklets that operate on the current url to add it to a social
    bookmarking site, or submit it to a news sharing service, or begin
    writing a blog about it, or manipulate it in some custom way.

    > > Because these sites have many users. If they didn't function well,
    > > they would not have so many users.

    > Do you have any idea how stupid your "arguments" sound?


    Your responses remind my of my children. "Oh yeah? Well you're stupid
    and you smell like poop!" You rarely say anything constructive. You
    rarely present any actual, reasoned arguments. It's just name-calling,
    "I told you so's" and "if you don't see why that's stupid, I'm not
    going to tell you again." Your signal-to-noise ratio in your posts is
    extremely low. You should work on that.

    The fact that a site has lots of users means it is doing something
    right. Perhaps not the way you think is optimal, but nevertheless they
    are doing it in a way that is good enough to survive and possibly
    thrive.

    > > Sometimes you can actually make _more_ users happy be choosing to
    > > exclude a small set of users. That's a win.

    > No, you forfeit as usual.  Blathering is not arguing.


    It doesn't matter to me that you ignore this basic truth.

    > > > Can't wait to see what stuff you come up with next.

    > > Awesome! Thanks for the support!

    > Yes, I'm a big fan of your stuff.


    And I of yours! Can't wait for the next awesome release of the
    monolithic Dojo cross-browser generalized scripting library/framework!

    Matt Kruse
    Matt Kruse, Jul 9, 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:
    303
    Natty Gur
    Jan 27, 2004
  2. sylvia sil
    Replies:
    1
    Views:
    595
    Curt_C [MVP]
    Dec 29, 2004
  3. rp
    Replies:
    1
    Views:
    491
    red floyd
    Nov 10, 2011
  4. timothytoe

    Adding data to URL for bookmarking

    timothytoe, Apr 14, 2008, in forum: Javascript
    Replies:
    3
    Views:
    76
    timothytoe
    Apr 14, 2008
  5. Peter Michaux
    Replies:
    102
    Views:
    764
    Thomas 'PointedEars' Lahn
    Jul 17, 2009
Loading...

Share This Page