Back arrow should act like back button

[shawnlauzon]

The left caret on each page makes it seem like it should act like a back button. However it does not: it instead launches the page to the front of the stack. That means that going back to go to the page they were on last means clicking through every single one of the issues that were displayed, which seems odd for clicking on a "back arrow".

The UX should not surprise people, and it does now. I suggest either a) Replace the left arrow with a "home" icon on the top left with the current behavior, or b) Keep the left arrow but change its behavior to act like a "back" button.

[Eyas]

@coreyleamon can you give guidance here? I can fix this but I'm curious about the UX perspective.

[coreyleamon]

Hey @shawnlauzon , can you expand on what you mean so I can better understand?

There is only one root home and each page is identical, connecting back to that root. There isn't a way to jump between pages without going back to that root first, so there wouldn't be any clicking through different topics to return to your last page... the last page will always be the root.
cc @Eyas

[shawnlauzon]

@coreyleamon Every time you go press the "back" button on your browser, it brings you through the last topic that you saw. The page stack thus looks like this:

Home -> topic 1 -> Home -> topic 2 -> Home -> topic 3 ...
And so when you get to topic 3 and want to go back to whatever you were browsing before, it brings you back through the list. So the last page is NOT always root ... root is the initial home, and each topic is layered on top of it.

If instead the left arrow acted like the back button, then it would be:
Home -> topic 1
Home -> topic2
Home -> topic 3
And then the back wouldn't bring you through all the topics you just saw.

[shawnlauzon]

@coreyleamon In summary, the left arrow looks like a back button, but it acts like a go home button.

[coreyleamon]

@shawnlauzon The back button in my browser always goes back to the home page, regardless of which topic I was just viewing. The carrot acts the same way, and that was always the intention. It is both a back and a home button, because you shouldn't be able to skip between pages without first going back home. People will be interested in certain accusations; nobody will read through every page... hence the notion of always moving them through the list.

If we want them to be able to move between pages, it should be added as a sequential at the bottom of the page.

[Eyas]

I think Shawn's point is the following:

If you are initially on the Home page, then go to topic 1, then hit the "back" carat, then go to topic 2, your browser history would look like this:

Home --> topic 1 --> Home --> topic 2

If you hit the browser back button once, you'd go to Home. If you hit it again, you'd go back to topic 1. If you hit it yet again, you'd go back to home again.

If you were on the Home page, then go to topic 1. Then hit the browser back button. Then go to topic 2, your history would look like this, instead:

Home --> topic 2

If you hit the back button once, you'd go to Home. If you hit it again, you'd leave the site entirely.

Shawn is suggesting our back carat behaves like a back button, so that it is going back in the location history, instead of adding another "Home" node to the location history.

[coreyleamon]

@Eyas Yes I understand - that would be up to the dev team to make it behave that way, if possible, but it shouldn't affect the user flow.

Honestly, this is an insanely simple site... I doubt people will be trying to move backwards four pages in location history to re-read their first topic when getting back to it is only two clicks with either the carrot or browser back button. And the assumption is any source they are getting to the site from will open a new tab or window to begin with, creating fresh location history in the browser.

[shawnlauzon]

@coreyleamon That's still not what I'm talking about. I'm not trying suggesting users should be able to loop through answers with some "see next topic" button.

The amount of time already spent explaining this is way too much, but since we've already spent this time. Here's the scenario I was in:

1. Open some page, e.g. slate.com
2. Then I manually type https://hillarymyths.org. Cool!
3. Then view any topic (call this topic 1).
4. Press left caret
5. Now view another topic (call this topic 2)
6. Press left caret
7. Now I want to go back to my original page, e.g. slate.com. So I press the back button, thinking it will take me there. Nope, it takes me to topic 2. I need to hit back 4 additional times to get to my original page. If I had hit the back button instead of left caret in 4 & 6, pressing back from home every time would get to original page.

So this is all about user flow.

[coreyleamon]

@shawnlauzon Please see my last comment above. The majority of websites like slate will open an external link as an additional tab because it is common practice to keep users on your website until they intentionally close the window (which makes this an edge case). Changing the carrot to a location history state needs to be addressed by a developer, not me. Changing it to a home button does not solve the problem you are talking about if a user tries to exit backward from the browser.. the history would still be stacked. And, no user I've ever seen (and I've sat through a lot of testing) has tried to use a website pattern rather than the browser back button to exit a website.

Only allowing side-stepping through pages, as I mentioned in the previous comment, would resolve this otherwise.

cc @Eyas

[coreyleamon]

@Eyas Can you help me find out if a dev can make the carrot operate as a browser back button would? If that is not possible, the next option is for us to alter design so users can side-step between pages. Please note this should be lower priority than VQA adjustments, as it is an edge case (most sources will open hillarymyths.org in a new tab). Thank you!

[Eyas]

@coreyleamon We can definitely do that. It would require a tiny bit of JavaScript. We can tackle this once the VQA suggestions are handled.

For posterity (if someone else is considering picking this up): Let's keep the href on the back a tag so that those with JS disabled can still have a reasonable experience. Then we can bind the click event and call event.preventDefault() to do what we want.

[coreyleamon]

@Eyas Perfect — agree to work towards the most common use case first. 👍

[shawnlauzon]

For the record, I don't think implementing side stepping between pages is necessary, and it's certainly not the intent of this issue. And also agree that Issue #137 is more important.

[dglazkov]

FWIW, I think that making the carrot work like a back button seems a bit hacky in principle. For example, if someone deep-links into the site, it seems like the carrot should stop acting like a back button and instead act like a back-to-home button.

[coreyleamon]

I agree with you, @dglazkov , because I've never seen an internal pattern be confused for a browser action. But our peer appears to feel very strongly and creating a back-to-home doesn't resolve the issue of stacking history he brought up. I am willing to go with consensus, whatever it may be, but think the only sensical solution is creating a "previous issue/next issue" scenario.