This article points out (correctly) that tabbed browsers throw away information about how tabs are connected, but it fails to give any argument for why that information is valuable.
I'm not convinced of this feature. It provides a large visualization, that costs a lot of screen space, and I don't see what user need all that extra information is providing.
> but it fails to give any argument for why that information is valuable.
I often find myself opening several new tabs while browsing, and suddenly wanting to go back to a certain page I've seen.
To do this, I need to search for the tab which contains the page that I want to revisit in its history, which is a pain.
Another option is to look through the browser history, but you loose the navigation process; so if you would like to access the page that you visited after this one (that you opened in a new tab), you will have to go through the history again.
There's a section at the end about how we got to this approach. You're right that there isn't too much detail there, though.
In short, research on how people interact with information sources shows that we rely on the kinds of connections we're trying to preserve as important queues for remembering and mentally sorting information.
As other posters here have pointed out, purely looking at the informational content it'd be enough to copy over the current tab's history stack when opening a link in a new tab. That doesn't mean that this information is easily consumed, though: while the degree to which this is true varies from person to person, by and large our mind works in a way that we have a hard time grasping connections between nodes in a graph without seeing enough of it at the same time and being able to map it out. If the only way to get any insights into the graph is to look at each tab's history stack individually, that's fine for compuers, but just not too useful for people.
>But if I try to revisit this later, it’s impossible. I can remember what I found, but it wasn’t a linear progression, therefore my browser history is useless.
If I want to find a page I visited more than three days ago, seeing a tree of history is not going to help me much more than seeing a linear list. There is just way too much information to sift through manually.
The obvious solution is to add full-text indexing by page content. And maybe even store pages for offline use. Perhaps when you enter special browsing mode akin to "private browsing" (although it would be the exact opposite, since it would retain more information).
I am aware of the complex issues this would require to solve, but those capabilities would qualitatively transform browsing and give users back some modicum of control over their page navigation. These days Google is our history. We remember a few keywords and instead of sifting through a giant list of URLs we simply search. Again, sifting through giant tree is not going to be any simpler. In fact, in terms of visual identification it might be more difficult than skimming a list.
...
Some simple machine learning algorithm that learns to bookmark and auto-tag pages would be an awesome feature/experiment as well.
...
And filtering open tabs by a keyword. Many people use tabs as a sort of dynamic set of bookmakers. Partly because they (sort of) preserve page content locally.
> The obvious solution is to add full-text indexing by page content. And maybe even store pages for offline use.
I built something that did exactly this, over ten years ago! I was a much less capable developer then, and it never worked as well as I wanted, so it was never truly finished.
Today this would be even harder, with the prevalence of web pages that are actually _heavily_ dynamic apps. Navigation to a new "page" is a much fuzzier concept now. What gets indexed? How do I generally know what content is/is not addressable by URL?
>Today this would be even harder, with the prevalence of web pages that are actually _heavily_ dynamic apps. Navigation to a new "page" is a much fuzzier concept now. What gets indexed?
This kind of stuff is why I am an advocate of progressive enhancement. It's not about whether someone has JS disabled or not. It's about using HTML as a semantic representation of information rather than a mere rendering layer. The second option might seem more convenient at times, but the first one opens a lot more doors for innovation in the long run.
sometimes I get to a dead end and want to navigate back to where I was, but have somehow lost the thread of how I got there, either b/c I was doing cmd + click and lost the tab and / or closed it or because it's now buried in the current tab's history.
I think it's a fairly common occurence for me that I feel like I need to rewind from my current position without losing any of my current context. Especially when I'm tracking down a solution to a specific bug or error message, something that is specific but could have multiple solutions.
Im not convinced this UI is the best solution to this (I built my own implementation of something like this) but I definitely identify with the problem
> sometimes I get to a dead end and want to navigate back to where I was, but have somehow lost the thread of how I got there, either b/c I was doing cmd + click and lost the tab and / or closed it or because it's now buried in the current tab's history.
When I'm researching a subject (like general research), trying a few different approaches for search queries and keywords until I get a result page with some promising results. Opening the promising results in background tabs, but at some point I just click, when I believe it's the last promising result, which then replaces the search result page and its history of previous queries. Then I try the opened tabs, quickly scanning them, closing some if they are obviously not what I need. At some point I decide I may need some more searches, but which of the tabs again had the history with the search queries in them? Did I close it maybe? It's often easier to coax Firefox's awesomebar into revealing one of my recent searches/history and continuing from there cause trying to dig up that one tab with the history you need, at best it only takes me completely out of my flow :)
One of the primary goals of this UX is to address that specific problem. It may not be the best UI for that specific task, but that's not only use case it supposed to serve. I would also argue it's far better UI than ones present in the current browsers.
If you have any specific suggestions how to improve UI to make it even better for that use case we'd be happy to get feedback.
I wish they used an example in which the history of how the decision is made is relevant. In this case, how you found the new pizza place is unimportant. You find it. You go. If you like it you go back. If you don't like it you do another search and skip over this place.
If you wanted to track which articles you read on a site and which you didn't, maybe this type of interface would be useful, but that is what :visited and :active are for.
(By the way, does anyone else think Hacker News should properly implement :active with a different color than :visited so that you can tell what article you just read if you wanted to jump to the comments or look at the next article in line?)
I tend to agree on this, is there a need to keep every trail in the process? probably not.
It's just ephemera, In computing there seems to be an overriding drive to stockpile it for some future date when we will have the ability to analyse it.
I would love to have a feature like this and I've written it down as one of my side-project ideas.
Why is back/forward history helpful on a single tab? (I leave this as an exercise for the reader) That reasoning more or less applies to cross-tab history/state. Previous behaviour was that people contained most of their browsing to a single tab (because browsers didn't have tabs, or they weren't commonly used). Behaviour has changed now to be more cross-tab.
I suspect the primary value will be the ability to find things again.
Imagine if every time you stopped using a fork or a bottle of soap, it disappeared and went into a giant box where you have to search for it by name. Much easier to just have things laid out spatially so when you need something you go to where you used it last. Over time things find a place to live.
A feature that would interest me more, is to have a visual indicator of tab parent tab.
For example, I have tab A, I cmd+click on some links to open them in other tabs. I go read the other tabs. Then, it would help me greatly to have a way to go back to the original tab A. But I'm more after a visual indicator or something non intrusive than a change of paradigm with tons of useless information.
I used to use it, but found that it encourages poor tab hygiene - the lousy default UI actually provides an IMO useful constraint in that it quickly grows easier to sweep stale tabs and windows into a todo or for-later-reading list, or just dispose of them, rather than put up with the annoyance of letting them clutter the UI.
A history graph, on the other hand, seems like a lovely thing to have. My version control systems and my text editor already represent history as a dag, and it's nice to see the same capability arriving in the third of the tools I use all day, every day.
I used to use it, but found that it encourages poor tab hygiene
In my experience the opposite is true; Tree Style Tabs makes it easy to close an entire tree of tabs once you're done with a topic. Or alternatively, to move out one tab which contains the "result" (e.g. the lawnmover that you'll end up buying after 4 hours of research) and then get rid of the rest.
Older versions of IE had something like this. When you opened a new tab from a link in a tab (as opposed to creating a blank tab and writing something in the address bar), it would have the same colour [1].
That's what I was thinking. Don't need fancy graphics, just make the back button work further back than the tab creation. Doesn't even have to be a copy, if they make the history a tree structure in memory.
That last part doesn't work, unfortunately. We looked into doing exactly that, but the way history navigation works is specified quite strictly - and relied upon by existing web content - making this infeasible.
I don't see how this could be true. From the perspective of a web page, it'd be exactly the same as if the user's new-tab clicks were regular clicks instead.
From a user perspective, my main pain point is the prior history running out at the point where I opened a new tab. In many cases I've already closed the tab it came from, and if it's not closed I have to go looking for it.
To a degree that is what we are doing here. There are some technical difficulties there and we plan to write followup post on that as well. That being said having a visual representation of the navigation trail is very useful even if it's just to gain ability to jump few steps back rather than going step by step.
I would like to see a split screen mode applied to trails. Seeing the current page along side the page I visited to get to it would work well on a lot of the sites I visit. For instance, it would be useful to see the main page of HN along side pages I reached from it and be able to click on the HN links to alter the content of the other panel similar to the way side navs work in many apps.
I think this kind of windowing system matches nicely with mobile-first design. This kind of UI becomes even more powerful when you can fit several full apps on the screen at once. I think in the long run, all tools will be designed to fit a mobile form factor, and larger screens will just be for looking at multiple items at once, and for better zooming. Kind of like a newspaper.
"Desktop" apps that put more UI in a single module than could fit on a phone screen are basically unlearnable for the majority of users anyway. At best, they learn a familiar "trail" through the app and ignore most of the UI. Might as well break it up on purpose, since that's how people use it.
Here's a bet (confidence level: I don't know if I really think this, but I might think this): Long-term, the size constraints of "mobile" displays are likely to be an aberration for most applications. We'll get some kind of head-mounted display / glasses with high resolution and a bunch of augmented-reality fanciness, while other interface features disappear into wearables and the environment, and in 10 or 20 years, the phone-sized displays that have come to seem normal will mostly be as forgotten as the temporary popularity of "netbooks" from a few years back.
Meh. Don't like this. For me I _like_ their being no history associated with the new tab - then I never lose track of a central "research" tab and the various separate avenues of exploration that I've opened. IE actually colour codes tabs grouping together pages that have been opened in separate tabs which is handy.
Trails would likely get confusing / complicated quickly, and possibly pose problems for SPAs that interact with tab history.
I've been using an alternative (tab tree[0] I think, posting this from mobile) that has been more stable but I think slightly less configurable and slightly less user friendly.
Man, I'd love to use some kind of hierarchical tab layout, but I like tabs go horizontal and take up basically zero screen real estate (that wouldn't already be taken up, eg title bar, etc)
For all who question "why not just copy history to new tab?": it is part of the trail design. By saying they are not throwing the tab away they have most probably already done that. This will be another screen to view the trail, like the tab exposé on mac safari.
visuals apart, for years I've been searching for browsing history stored as graphs. There's so much information there. I would google my own privacy with this so much.
History in browsers and editors should absolutely be a trer so we can do changes without the risk of losing a state we want. If you undo/go back and then make some change it's often impossible to reach back to before the undo. Why is history as a tree not a more common feature?
I'm not convinced of this feature. It provides a large visualization, that costs a lot of screen space, and I don't see what user need all that extra information is providing.