Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Au contraire, the back button behaves exactly as it should. It's not how users would expect it to function, but it does obey the stack.


What you just said makes no sense. If a button doesn't follow what the users expect to happen then the button is broken!


Not true. A back button is meant to "go back to previous state". When you click a link, then back, you will go back to the previous page or position on the same page depending on the link you clicked.

Similarly, if you enable a lightbox and your page goes behind a modal image, hitting back will behave exactly the way it should, i.e. take you back to your previous state.

I'll go one step further and say that a lightbox implementation that doesn't do this should be considered broken since it breaks user expectations. This does raise the question of judging a user's intent when he presses the back/forward button while there is something modal on his screen, but let's save that for some other time.


Steps to reproduce broken button:

  1) Open the demo page
  2) Click image
  3) Click 'X' in top left of image
  4) Click different image
  5) Click the 'X' in the top left of image
  6) Click browser's 'back' button
  7) Observe how you're staring at the image, not the hacker news page you came from.
The problem is that clicking the 'X' should pop the image off the stack, not just add another page ("#home") to the stack.

Opening an image then hitting back works as it should, though.


Here's another demo to reproduce the "broken" back button:

  1. Go to http://en.wikipedia.org/wiki/Hacker
  2. Click the "Innovation" link in the ToC on the right
  3. Click the "Entertainment" link (you can just see it) under the "Innovation" one.
  4. Click the back button.
  5. Observe how you're not taken back to Hacker News.
Now imagine this is a really long page of FAQs, with a "Return to top" after each question, and the same ToC at the top (something a clueless user probably sees everyday [I know I do on O2's site all the time]). You can see how it begins to look like a browser implementation problem.

Maybe the browser should automatically pop all "#<identifier>"s associated with a URL from its history stack if a user reaches the original URL again (via backs or clicking some in-page link, doesn't matter); I don't know. But I honestly consider this a browser implementation problem, not a web developer problem. I think anything we've been doing till now has been to mitigate this and we shouldn't have to.


The solution is not to change browser behavior, that's fine. Just remove the hashtags from the images so the URL doesn't change when you click on the picture.


Does that make it "broken" or just incompatible with your expectations? Would other non-technical users have the same expectations? It's possible other users will want to go "back" to the image they last visited.

Consider if this was done just HTML 4 and no CSS or Javascript. You would click a thumbnail and a new page would be loaded with a full size version of the image. You would then click a "close" button that would take you to the page with the thumbnails again. If you hit "back" you would go back to the image.

The way the page currently works follows the "stack" of what I actually visited by clicking links. If I want to reverse my workflow after visiting all 5 images and closing between them, I personally would expect the back button to go through all 5 images. From this perspective, doing the same effect with Javascript that doesn't update the stack might surprise me if after clicking 10 links on this page, a single click of the browser back button skips 10 steps of my workflow and returns me to HN.


I understand your argument, and it makes sense; however, I disagree.

The user clicks the image in order to see it full-size. The lightbox overlays the page that the user is on. The user is not conscious that they are navigating to a new page, or even just a part of the page that they weren't at before (to the #image). Though the workflow is in actuality following a link, the user is not aware that they are following a link, so the back button functionality doesn't work as expected.

Links are well understood by everybody that uses the Web. They change the page that you're on to a new page, or a new part of the page. Lightboxes were invented so that the user doesn't need to leave the page, or the part of the page, that they are on.

So in my mind, lightboxes that don't behave like lightboxes and instead behave like links are broken.


I don't have any experience with developing lightboxes but couldn't the 'X' button just use javascript to go back in the history (instead of directly hiding the image). Or is that how most lightboxes work but because this one cannot use javascript it is not possible to do so?


Does it make sense for a user to have to go back through the entire stack of photos they viewed to go to the page before they arrived at the lightboxing page? Not at all. There is a distinct difference between usable states and modal images. With states you want the rich navigable history and the other you want to open it and close it, but not page through it.


Actually, it does exactly what I ( an Android user ) expect the back button to do and what I've wanted every lightbox to do. Sometimes the css for the close button is wrong, or the js is messed up and the close button doesn't work. The back button closing the lightbox is exactly what I want.


I like the particular use-case you suggested, but I'm going to play the devil's advocate. If I close the lightbox, I do not expect the lightbox to re-open. I know there's mixed feelings on this one. Thoughts?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: