6 ms·

Breaking it is completely unnecessary too, even with single page apps. It's not all that hard to build a React or Angular apps that use proper links along with

by rpeden 8y ago

Breaking it is completely unnecessary too, even with single page apps. It's not all that hard to build a React or Angular apps that use proper links along with the browser history API. Designed properly, the apps should be able to load their state and render correctly even when deep-linked to somewhere other than the app's top level. This isn't a new concern - I remember paying attention to this back in the old days of SPAs using GWT back in 2009/2010. Unfortunately, many web apps choose to ignore this. On the bright side, lots of them get it right, too.

vanderZwan 8y ago
It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design. The closest thing to an exception being cases where one needs to be logged in to see a page, or when links are consciously invalidated for some other reason. And even then the website/webapp should still just signal this to the user without a bazillion redirects.
- jahewson 8y ago
  Not necessarily: I do not want to click back 30 times to get out of your slideshow and back to my Google results. Thank you.
  - ergothus 8y ago
    But the problem there is that they used a carousel in the first place. Were it content that justified clicking 30 times into it, it would also justify backing out of it 30 times.
    - rpeden 8y ago
      For something like a slideshow, I think you could have it both ways - default to a scroll view that shows all of the slides at once, and make it so clicking a slide shows the slide on a single page that is deep-linkable. The user could then navigate forward and backward between each individual slide page if they so desire. I suppose it's all a matter of trying to do what will best match user expectations. Or just whatever will make them happiest. Maybe call it the principle of least annoyance. Of course, if you make an ad supported slideshow app, maybe you want to show one slide per page to get more ad impressions. I suppose that would be the principle of maximum revenue, along with its corollary (from the user's perspective): the principle of maximum indignation.
    - beat 8y ago
      The problem is that it might take a half-dozen clicks to realize it's not worth reading the other 24, then you need to click back a half-dozen times (worse if there are page reloads during that).
      - ergothus 8y ago
        That's my point though - if it takes a half-dozen clicks to decide it's not worth it, then they weren't using a good format anyway. You likely did the last 5 clicks hoping things would be different after the click - the click itself was NOT a value add. I'm not saying it isn't useful to bypass that to get back, but then you're literally asking the people that made the bad design decision in the first place to make the good one to let you out - and they likely won't, for the same reasons they gave you that UI in the first place.
      - dylan604 8y ago
        Or, use another built-in feature of the browser's back button. Click-and-hold the back button so that you can see a contextual menu with the steps you can go back to quickly. If I click back more than twice, the third is a click-and-hold.
  - deleted 8y ago
    [deleted]
  - vanderZwan 8y ago
    Your example is exactly why we have both History.pushState and History.replaceState[0]. The core question there is whether a new slide represents a new page or not. And in this case, I agree that it doesn't: it's the same page, just in a different state. EDIT: If you mean one of those 20-image slideshows intentionally made to create fake click statistics, I agree that that's absolutely infuriating. But in that case ergothus' comment applies: the real problem is bad faith webdesign in that case. [0] https://developer.mozilla.org/en-US/docs/Web/API/History#Methods https://developer.mozilla.org/en-US/docs/Web/API/History#Met...
    - saidajigumi 8y ago
      And this example pretty much nails the theme: there is no technical reason for these problems. If a website screws it up, it's just bad design at this point. Broad support for history management is well-established at this point: https://caniuse.com/#feat=history https://caniuse.com/#feat=history
  - rayiner 8y ago
    The problem there is the slide show. Converting a series of slides to a page in traditional vertical scrolling format works just fine. Overriding the back button behavior is just expecting a second wrong to make a right. (Ironically, these days I'm relieved when I see a presentation is posted as a PDF: https://people.apache.org/~xli/presentations/history_Intel_CPU.pdf https://people.apache.org/~xli/presentations/history_Intel_C.... I'd much rather load a PDF than deal with all the shitty and insane ways people have figured out how to show presentations in HTML. Cough SlideShare: https://www.slideshare.net/garyachy/dpdk-44585840 https://www.slideshare.net/garyachy/dpdk-44585840)
  - pjc50 8y ago
    That's what "open in new tab" solves.
  - genericid 8y ago
    Try right-clicking the back button. Or complain to your browser maker -- they're responsible for its behaviour.
- SilasX 8y ago
  Virtually every site breaks the back button now. Even reddit will suddenly forget discussions I had closed, and where I was on the page, and then have to reload something, when I all I need it to do was take me back to the same state on the page that I had before.
  - madeofpalk 8y ago
    > Virtually every site breaks the back button now This is just not my experience, at all. I'm extremely sensitive to this issue, and its just not something I see all that regularly any more.
    - SilasX 8y ago
      I was including "fail to return to page state at time link was followed" as "breaking the back button". Reddit, Quora, and sites using Disqus fail that.
- qudat 8y ago
  > if it breaks the back button of the browser, it's the wrong design. Some people don't care about a back button in a single page application and it isn't "trivial" to implement properly. It requires libraries, polyfill support, etc. And in a world where everyone is complaining about js bloat, it should be no surprise why it exists.
- tomjakubowski 8y ago
  > if it breaks the back button of the browser Good luck getting a group of people to agree on what "non-broken" back button behavior is.
  - oneeyedpigeon 8y ago
    All those cases where pressing back repeatedly doesn't actually go back? They're broken. We may not be able to define 'broken' perfectly, nor catch every case, but we can definitely spot the worst! Unless you mash the back button really quickly ...<sigh>
    - msla 8y ago
      Your back button is "broken" every time your last transition from the previous page to the current page changed information on the server, and that information change isn't reflected in the cached version of the previous page your browser helpfully shows you when you hit back. Cache invalidation is a technical solution, and it could conceivably be done with header magic or something, but the real problem is people thinking the back button undoes history and the server (and, possibly, reality) disagreeing.
      - ycombobreaker 8y ago
        Going "back" and showing the old information is accurate. I'm not reloading the prior URL. I'm viewing the last page I looked at. In fact maybe I don't even have network access at the moment (on a subway). I can always opt in to reload the page if I want to see refreshed data.
- vkou 8y ago
  > It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design. What if state should be destroyed when you press the back button? What if I open an image in a photo app, click a button to delete it, and go to a 'deletion successful' page. Should clicking the back button return me to a page containing the image? A page containing 'this image has been deleted'? The website I was on before I was on the photo app? Which actions defines a history-worthy state change? Should clicking around a menu generate 10 history events? What about toggling a checkbox? What about an action that changes most of the information on a page? Should that generate a history event? What if that action is bringing an in-app tab to the forefront? What if there is an obvious history event that should be generated, but there is no good reason for why a user would want to go back to that state? It doesn't even matter how you answer all of the above questions - other people will have different answers for them, and have different expectations for how the back button should work, on the same app.
  - petee 8y ago
    which really cuts to the core of it: shoehorning something that should be its own app into a website -- all your above problems solved. The web was not designed for such use, yet we continue to stretch and abuse whats there and wonder why most sites suck and get it wrong.
    - vkou 8y ago
      How will someone on a laptop run my website as an 'app'? Should I download a Wells Fargo app to my desktop, so that I can do banking with them? And a Google Docs app? And a Seattle City Lights app? Maybe a Progressive app, so I can manage my insurance policy? And one for the Washington DMV? How many problems is running random binaries from random developers at those organizations going to give me? How much more expensive is it to develop apps, over websites? How will you make these apps run on Android, IOS, Linux, MacOS, and Windows? [1] All of these websites have rich app-like functionality. The web was designed as a document store, yes. This is 2018, though - its not used as a document store. It's the place where I do my banking, my shopping, keep my spreadsheets, and make image macros. Turning all of that into non-web apps will just make development more expensive, degrade my user experience, and negatively impact my PC's security. But hey, the upshot is that the sanctity of the back button will be protected! [1] Maybe we could sandbox them... And have a cross-platform 'operating system'[2] where they can run. Maybe even have several such 'operating systems', with similar functionality, but built by different vendors. Vendors like Microsoft, Apple, Mozilla, and Google, maybe? [2] We can even make this 'operating system' support opening static .HTML pages, so that we can 'browse' through them.
briandear 8y ago
Ember does this out of the box.
rhizome 8y ago
Unfortunately, many web apps choose to ignore this I wouldn't be surprised if most if not all tutorials ignore it as well.
komali2 8y ago
As I recall when learning angular (2) and react (whatever 2016 version was), almost every tutorial on the subject of routers would just go "the easy route" that inevitably avoided using the browser history API. I haven't checked in a while, I wonder if this situation improved? A lot of these frameworks market themselves as dead easy, but I always found a gap between the "dead easy start-up" documentation, and the documentation that essentially amounted to "read the source code."

by rpeden 8y ago

vanderZwan 8y ago

It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design. The closest thing to an exception being cases where one needs to be logged in to see a page, or when links are consciously invalidated for some other reason. And even then the website/webapp should still just signal this to the user without a bazillion redirects.

jahewson 8y ago
Not necessarily: I do not want to click back 30 times to get out of your slideshow and back to my Google results. Thank you.
- ergothus 8y ago
  But the problem there is that they used a carousel in the first place. Were it content that justified clicking 30 times into it, it would also justify backing out of it 30 times.
  - rpeden 8y ago
    For something like a slideshow, I think you could have it both ways - default to a scroll view that shows all of the slides at once, and make it so clicking a slide shows the slide on a single page that is deep-linkable. The user could then navigate forward and backward between each individual slide page if they so desire. I suppose it's all a matter of trying to do what will best match user expectations. Or just whatever will make them happiest. Maybe call it the principle of least annoyance. Of course, if you make an ad supported slideshow app, maybe you want to show one slide per page to get more ad impressions. I suppose that would be the principle of maximum revenue, along with its corollary (from the user's perspective): the principle of maximum indignation.
  - beat 8y ago
    The problem is that it might take a half-dozen clicks to realize it's not worth reading the other 24, then you need to click back a half-dozen times (worse if there are page reloads during that).
    - ergothus 8y ago
      That's my point though - if it takes a half-dozen clicks to decide it's not worth it, then they weren't using a good format anyway. You likely did the last 5 clicks hoping things would be different after the click - the click itself was NOT a value add. I'm not saying it isn't useful to bypass that to get back, but then you're literally asking the people that made the bad design decision in the first place to make the good one to let you out - and they likely won't, for the same reasons they gave you that UI in the first place.
    - dylan604 8y ago
      Or, use another built-in feature of the browser's back button. Click-and-hold the back button so that you can see a contextual menu with the steps you can go back to quickly. If I click back more than twice, the third is a click-and-hold.
- deleted 8y ago
  [deleted]
- vanderZwan 8y ago
  Your example is exactly why we have both History.pushState and History.replaceState[0]. The core question there is whether a new slide represents a new page or not. And in this case, I agree that it doesn't: it's the same page, just in a different state. EDIT: If you mean one of those 20-image slideshows intentionally made to create fake click statistics, I agree that that's absolutely infuriating. But in that case ergothus' comment applies: the real problem is bad faith webdesign in that case. [0] https://developer.mozilla.org/en-US/docs/Web/API/History#Methods https://developer.mozilla.org/en-US/docs/Web/API/History#Met...
  - saidajigumi 8y ago
    And this example pretty much nails the theme: there is no technical reason for these problems. If a website screws it up, it's just bad design at this point. Broad support for history management is well-established at this point: https://caniuse.com/#feat=history https://caniuse.com/#feat=history
- rayiner 8y ago
  The problem there is the slide show. Converting a series of slides to a page in traditional vertical scrolling format works just fine. Overriding the back button behavior is just expecting a second wrong to make a right. (Ironically, these days I'm relieved when I see a presentation is posted as a PDF: https://people.apache.org/~xli/presentations/history_Intel_CPU.pdf https://people.apache.org/~xli/presentations/history_Intel_C.... I'd much rather load a PDF than deal with all the shitty and insane ways people have figured out how to show presentations in HTML. Cough SlideShare: https://www.slideshare.net/garyachy/dpdk-44585840 https://www.slideshare.net/garyachy/dpdk-44585840)
- pjc50 8y ago
  That's what "open in new tab" solves.
- genericid 8y ago
  Try right-clicking the back button. Or complain to your browser maker -- they're responsible for its behaviour.
SilasX 8y ago
Virtually every site breaks the back button now. Even reddit will suddenly forget discussions I had closed, and where I was on the page, and then have to reload something, when I all I need it to do was take me back to the same state on the page that I had before.
- madeofpalk 8y ago
  > Virtually every site breaks the back button now This is just not my experience, at all. I'm extremely sensitive to this issue, and its just not something I see all that regularly any more.
  - SilasX 8y ago
    I was including "fail to return to page state at time link was followed" as "breaking the back button". Reddit, Quora, and sites using Disqus fail that.
qudat 8y ago
> if it breaks the back button of the browser, it's the wrong design. Some people don't care about a back button in a single page application and it isn't "trivial" to implement properly. It requires libraries, polyfill support, etc. And in a world where everyone is complaining about js bloat, it should be no surprise why it exists.
tomjakubowski 8y ago
> if it breaks the back button of the browser Good luck getting a group of people to agree on what "non-broken" back button behavior is.
- oneeyedpigeon 8y ago
  All those cases where pressing back repeatedly doesn't actually go back? They're broken. We may not be able to define 'broken' perfectly, nor catch every case, but we can definitely spot the worst! Unless you mash the back button really quickly ...<sigh>
  - msla 8y ago
    Your back button is "broken" every time your last transition from the previous page to the current page changed information on the server, and that information change isn't reflected in the cached version of the previous page your browser helpfully shows you when you hit back. Cache invalidation is a technical solution, and it could conceivably be done with header magic or something, but the real problem is people thinking the back button undoes history and the server (and, possibly, reality) disagreeing.
    - ycombobreaker 8y ago
      Going "back" and showing the old information is accurate. I'm not reloading the prior URL. I'm viewing the last page I looked at. In fact maybe I don't even have network access at the moment (on a subway). I can always opt in to reload the page if I want to see refreshed data.
vkou 8y ago
> It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design. What if state should be destroyed when you press the back button? What if I open an image in a photo app, click a button to delete it, and go to a 'deletion successful' page. Should clicking the back button return me to a page containing the image? A page containing 'this image has been deleted'? The website I was on before I was on the photo app? Which actions defines a history-worthy state change? Should clicking around a menu generate 10 history events? What about toggling a checkbox? What about an action that changes most of the information on a page? Should that generate a history event? What if that action is bringing an in-app tab to the forefront? What if there is an obvious history event that should be generated, but there is no good reason for why a user would want to go back to that state? It doesn't even matter how you answer all of the above questions - other people will have different answers for them, and have different expectations for how the back button should work, on the same app.
- petee 8y ago
  which really cuts to the core of it: shoehorning something that should be its own app into a website -- all your above problems solved. The web was not designed for such use, yet we continue to stretch and abuse whats there and wonder why most sites suck and get it wrong.
  - vkou 8y ago
    How will someone on a laptop run my website as an 'app'? Should I download a Wells Fargo app to my desktop, so that I can do banking with them? And a Google Docs app? And a Seattle City Lights app? Maybe a Progressive app, so I can manage my insurance policy? And one for the Washington DMV? How many problems is running random binaries from random developers at those organizations going to give me? How much more expensive is it to develop apps, over websites? How will you make these apps run on Android, IOS, Linux, MacOS, and Windows? [1] All of these websites have rich app-like functionality. The web was designed as a document store, yes. This is 2018, though - its not used as a document store. It's the place where I do my banking, my shopping, keep my spreadsheets, and make image macros. Turning all of that into non-web apps will just make development more expensive, degrade my user experience, and negatively impact my PC's security. But hey, the upshot is that the sanctity of the back button will be protected! [1] Maybe we could sandbox them... And have a cross-platform 'operating system'[2] where they can run. Maybe even have several such 'operating systems', with similar functionality, but built by different vendors. Vendors like Microsoft, Apple, Mozilla, and Google, maybe? [2] We can even make this 'operating system' support opening static .HTML pages, so that we can 'browse' through them.

briandear 8y ago

Ember does this out of the box.

rhizome 8y ago

Unfortunately, many web apps choose to ignore this I wouldn't be surprised if most if not all tutorials ignore it as well.

komali2 8y ago

As I recall when learning angular (2) and react (whatever 2016 version was), almost every tutorial on the subject of routers would just go "the easy route" that inevitably avoided using the browser history API. I haven't checked in a while, I wonder if this situation improved? A lot of these frameworks market themselves as dead easy, but I always found a gap between the "dead easy start-up" documentation, and the documentation that essentially amounted to "read the source code."