On Wed, Jul 22, 2009 at 6:08 PM, Brian Rakowski<[email protected]> wrote: > The most promising things I found from the design challenge were the history > view in "Favitabs n' Drawers" (see attached image). The cool thing about it > is that it shows how long the tabs were open. I find other history views > that only show the time at which the page was loaded very unintuitive. > I also still like the idea of "to read" tabs. The challenge is finding a > simple gesture that would allow users to identify tabs or links that should > go in the "to read" queue. I feel like this would dramatically cut down on > the number of open tabs and also remove my fear of losing interesting pages > that I wanted to get back to.
There's a plugin for FF called Taboo that kinda does this. But I haven't found it hugely compelling - the experience needs to be a bit smoother. One thing that occurred to me just now is to be able to tick tabs as well as cross (i.e. close) them. A ticked tab would go onto some kind of temporary bookmark list when closed, so I could easily get it back. Unticking it would remove it (or maybe just getting it back would untick it). > > On Wed, Jul 22, 2009 at 9:54 AM, Linus Upson <[email protected]> wrote: >> >> With a good heuristic, I think it will be very unlikely that we'll kill a >> renderer that has useful state. What are the chances that a tab on a site >> that I don't go to often, and that I opened 30 tabs ago has js/dom state >> that is critical for me? Mobile browsers already euthanize unused >> tabs aggressively. Since so few users have 20+ tabs open at once perhaps we >> can just reset their expectations for what happens if they accumulate a >> large number of tabs. Perhaps the heuristic could be tied to the mythical >> great overflow UI. For all of these heavy users I suspect they would prefer >> chrome to remain zippy fast with large tab sets rather than paging a >> renderer that 99.9% of the time doesn't have any interesting state. >> Linus >> >> On Tue, Jul 21, 2009 at 2:03 PM, Scott Hess <[email protected]> wrote: >>> >>> 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 -~----------~----~----~----~------~----~------~--~---
