I don't think it's reasonable to require the user to specify which tabs to suspend, except, perhaps, if we develop a metric for power-hungry tabs and expose that.
I think there is some potential for UI geared towards particular use-cases which could be overloaded to also allow more aggressive suspend. For instance, WRT my earlier posting, I would expect my pinned tabs to be given stronger priority, and my on-deck-to-read tabs to be treated more like preloaded/rendered bookmarks. There could be other UI advantages in there, like the on-deck tabs for a particular project could group under a single tab with other UI widgets to select which document within the group. -scott On Tue, Jul 21, 2009 at 1:50 PM, Ryosuke Niwa<[email protected]> wrote: > Is it possible to provide an intuitive UI that allows users to choose which > tabs to be suspended? > For example, just like users can click buttons on taskbar to pop up a > particular window, we could provide a small window that pop-in tabs / > windows. And then we can suspend all windows / tab that are popped into. > Ryosuke > > On Tue, Jul 21, 2009 at 9:32 AM, Erik Kay <[email protected]> wrote: >> >> 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 -~----------~----~----~----~------~----~------~--~---
