You may be on to something, but I think it's more complex than this. For example bookmark systems don't work because people use them for a number of conflicting purposes (my list of things to read every day, a simple history system, a 'to read' list, a collection of links for research), which have different UI requirements. I think the same thing has happened with tabs (and there's a surprising amount of overlap). Here are the use cases I know I wind up using: - a few long running apps that need to keep running, potentially notifying me of new events (calendar, mail, chat, buildbot, etc.) - a few pages that I'm currently actively using (a screenshot from a bug I'm looking at, some reference documentation, a writely page I'm editing between compiles, etc.) - a "to read" list of pages that I started reading but didn't finish yet (sometimes this is a collection of related pages when researching something) - I'm sure there are others.
In my use case, 80% of my tabs could easily be killed / suspended (or even hidden altogether) without any downside to me. The problem is that there isn't a way to automatically figure out which ones are which. Which ones have pending state that might be lost? (yes, some of this is bad app design, but there are many like this) Which ones do I expect to keep running all of the time because of notifications? What about that flash game that I left running in the background? Maybe we could come up with some heuristics that could detect some of this automatically, but I worry that there will be so many exceptions that it won't work. That means we'd need to come up with a better UI to express these concepts where the user chose to treat tabs differently in some explicit way. There are a number of extensions that try to do this for some specific use cases (to read lists, pinned tabs, etc.). I'm not sure that these are better than bandaids though. Erik On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee <[email protected]> wrote: > > I feel like people are using tabs as a replacement for a good history > system. At least in all current browser implementations, tabs are > "running". Even if we can make the UI scale to 1000 tabs, the 500 > flash instances that are likely running aren't really going to > perform. The making tab performance scale is a separate technical > issue that will hopefully also improve. > > Looking at a lot of these design videos, they looked more like good > ideas to me for history navigation than tab navigation. If history > was good, I think people wouldn't be so worried about "losing > something" by closing a tab. Having had bad history systems for so > many years, people are now trained to keep tabs open if they ever > might want to look at that page again in the future :\ > > On Sat, Jul 18, 2009 at 1:16 AM, Peter Kasting<[email protected]> wrote: > > http://design-challenge.mozilla.com/summer09/ > > The results of the "Reinventing Tabs in the Browser" challenge have been > > announced. > > "Collapsible Tab Groups" includes among others some things I've proposed, > > including grouping and collapsing groups. > > "Favitabs" reminds me of some old brainstorming ideas from pamg about > > converting certain tabs into favicon buttons. > > Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do > well > > to take a look at some of these. > > PK > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
