4

I am working on a script that I will most likely be using for all my future websites that prevents the page from refreshing/redirecting when navigating through it. It does this by Manipulating the browser history (unlike hashing, which is kind of a hack to do the same thing).

When a user follows a dead link, there will be a 404 page shown. The problem that I'm facing is that I can't decide whether or not I should keep it in the history that I'm creating. I have total control over the history, and it would seem like a good idea at first. However, I think people might get confused.

What do you think? Should I keep it?

|improve this question
6

I think the user needs to know where he is and what is not working.

So for two main reason I would push a state:

  1. User awareness

  2. User might want to come back to check if it was fixed

Having a dead address visible in the browser gives the user the certainty that the page is not working. The user might want to copy the address and come back later to see if it was fixed, or even come back because the 404 might have been thrown because of a Javascript timeout.

For a more advanced user, if he doesn't see the address changed in the browser he might want to open it in a new tab just to be sure it is the page not working and that the error he is getting is not some JavaScript bug (or timeout callback).

|improve this answer
  • 4
    On a slightly related note, I hate sites that redirect on 404 (without recording the original address) -- if I've (mis)typed an address in the address-bar (or pasted an incorrect address), I now cannot go back an make the one-character correction but have to start over. – TripeHound Nov 10 '16 at 11:06
  • Thanks, Alvaro and TripeHound, you both convinced me. It seems pretty obvious now that I think about it – Gust van de Wal Nov 10 '16 at 11:19
0

Is there a reason, you see that the user would want that extra information in his history?

If not, then there is no point for the same. At least, I cannot think of any reasons why a user would want that detail.

At the same time, I guess, the same information will be recorded on your end, and will be available to you if the need arises

|improve this answer
  • If I start at 'Page A', navigate to 'Page B' then click a link for 'Page C'. 'Page C' is actually a broken link so I see a 404. Luckily this 404 is well designed and has top level navigation so I navigate on to 'Page D'. Eventually I want to go back to 'Page B' and, knowing that I've come through 2 pages since I looked at 'Page B', I hit the back button twice. In your system, my 2 hits would land me back at 'Page A'. – Andrew Martin Mar 28 '17 at 8:46
0

Keep a separated history of the 404/dead pages i.e. in a list or something. This will help you in your analytics.

Considering that you don't save the dead links & 404s, what if user:

  • visits normal page
  • hits a dead link
  • takes the user to a 404 page which you don't save
  • click back to go to normal page
  • click forward to ..? Another dead link?

One option is to not have the forward link(since you're already manipulating the History API, the browser will know that there is no page to go forward to) or the back link(you can delete that from history)

The modern browsers do keep a list of 404s chiefly to eliminate any surprise navigation when moving to/fro the web pages.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.