Back Button For Browsing Hyper Text

One thing which almost everyone can agree upon is that the way which the "back" button behaves in just about every WebBrowser is bad! For a lot of scholarly research on this, see http://www.cosc.canterbury.ac.nz/~andy/web_navigation.html

One thing which almost nobody seems to agree upon is how it should behave.

I think that nothing I shall see

: is ugly as a menu tree

for when from leaf to leaf I'd leap

along the branches I must creep.

: -- Ode to a Menu System, "probably" by Richard Fowell

I proposed the back button when the first browser came out. It was part of the plan in 88. But I sent an email to mosaic through a friend's account at UT in Austin. The thing works nice. Simply because you need to be able to go back. That allows tree browsing.. link we do on youtube. And the location bar should save the chronicle history. Some browsers only save the cashe for the "forward" button(also my invention). If you go back then you need to go forward.

I am worried that this site is a propaganda site since they erased the corrected history of modern "hypertext" (punctuation) which I invented in 87. Google Ngram viewer was also hacked. Hypermail was erased from 88 to 93.

Who are you that proposed the back button? I erased the "corrected history of modern 'hypertext'" as it contained no corroborating evidence but did have a link to a site selling vaporisers, so I assumed it was commercial spam. If you have some evidence to back up your claims of invention, I'll put it back. Unfortunately, unsubstantiated claims of inventions are not uncommon, and rarely bear up under scrutiny.

The current model is the "stack". "Back" and "forward" navigate through a history list of pages in the order they were originally viewed. When a new page is loaded by any means other than "back" or "forward", all the items which were "forward" from the current position in the history are removed from it, and the new page is appended.

One proposed model is the "temporal". It follows directly, if one accepts the principle that the back button should go through pages in the order which the browser most recently displayed them. Loading a page causes it to be added to the end of the history list. Whenever the back and forward buttons are used, each revisited page is added to the end of an invisible secondary history list. Whenever a page is loaded by any other means, the secondary list is cleared and its old contents are appended to the primary, visible history list. There is further debate upon whether or not older, duplicate entries should be deleted from the primary list at the time the lists are merged.

Another proposed model is the "tree". There is no secondary list, so items are never duplicated. Whenever a new page is opened by any means other than "back" or "forward", it is added as an immediate child of the page which was visible at the time. The "back" and "forward" buttons traverse the tree in prefix order. Therefore, the history does not necessarily actually have to be stored or displayed as a tree; it may be a list, and the behaviour will still be as described here. Advocates of this model want it to be displayed as a list for the purposes of "back" and "forward", but suggest that there be other interfaces which display it as a tree.

It might be best to distinguish between "tree" and "insert flat", the sole distinction being that in the former, the history is presented as a tree; and in the latter it is presented as a list.

There has also been some discussion of ways that both "temporal back" and "tree back" could be provided, as two separate buttons, both always available.

Discuss. I'm very interested in this question; I intend to refactor the page frequently, to keep discussion focused.

I advocate the temporal. The stack seems very unnatural to me; I can't imagine when I'd want it or why. -- DanielKnapp

Those ideas should be programmed as plugins to MozillaBrowser/MozillaFirefox, and tested in reality. It may sound good in theory, but maybe they are not so great in practice. I agree that the actual implementation sucks, but does not suck very hard. -- JuanPabloNunnezRojas.

I believe that the tree construct does exist as a MozillaFirefox extension already - Digger/Diggler, if memory serves

BackIsNotUndo

CategoryWebBrowser