[chromium-dev] Re: Mozilla design challenge
I think you're somewhat right folks use tabs to enhance or partially replace poor history systems. Instead of going to the root to create a "good" history system and telling users to "stop doing that," perhaps we should be asking how can we enhance what the user wants to do: *Use tabs (in their current highly evolved presentation and placement) to improve on history!* After all, tabs *are* a mechanisms for presenting a vast array of windows in a more usable and orderly fashion than the anarchy of a pseudo-randomly overlapping window set. Such a windowing anarchy is what we had in Netsacape and IE prior to tabbing. To put it another way, tabs *are* a clever history presentation mechanism, and not an abuse of a feature. Several of the videos provide alternate views of tabs. I think providing better views is a very worth-while goal, although I think too often demos abandoned the existing tab UI, and provided wholesale replacement. :-( Brian focused on a nice element, which showed how long tabs have been open. Fundamentally the ability to see tabs differently, rather that moving them automatically, may be a key way to help a user do what is most natural. When I search for a needle in a haystack, one of my goals is avoid moving much hay, as I have a lot of structure in the placement of the existing piles. One really nice element of gmail is that messages are sorted by tagged views, but not really moved (a giant stride when compared with pop and imap message replications in folders). I think we need ways to view the data (what's in a tab, and the history and relationships of tabs) without moving the tabs from where the user placed them. Perhaps we need to help the user achieve the integration, and provide more views of their tabs, that enhance their actions. The "Best in Class: innovative" sadly seems to discard the current tab view (providing a radial view), rather than work to enhance current tab placement and information presentation. For instance, perhaps a new-tab page should (optionally) have a view that graphically looks like a spread sheet descending from the tabs. Something like a tinderbox waterfall which shows history of build bots, should show some history of tabs. Perhaps we should have mouse-over thumbnails (as suggested in some of the videos)... all sorts of ideas spring to mind. Clever innovation such as Nsylvain's enhancement of waterfall presentation that warps time in a traditional waterfall may be applied to make views most useful for various search scenarios. ...but that UI thread seems quite orthogonal to the performance enhancing portions of this thread about how to transparently freeze-dry lingering tabs so that they don't impact performance. I think this freeze-drying can indeed be done well, if not perfectly by heuristics mentioned in this thread. It may be that the heuristics are conservative, but looking at my use cases, I'm convinced heuristics could do an excellent job on the bulk of my tabs, and still have zero lost content (re: lost edits and state) just by being conservative. The only way we'll see if such heuristics *could* cover the bulk of genuine users tabs is to do some data gathering on real users (example: We could sample at each UMA gathering point how many tabs could be conservatively freeze dried). Jim On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~-
[chromium-dev] Re: Mozilla design challenge
On Wed, Jul 22, 2009 at 6:08 PM, Brian Rakowski 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 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 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 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 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
[chromium-dev] Re: Mozilla design challenge
On Wed, Jul 22, 2009 at 11:27 AM, Ojan Vafai wrote: > There are heuristics we can come up with that are fairly safe. Does this topic have to pollute every thread? We now have three different email threads that have turned into discussions about killing background tabs. It's not helping discussion of this topic to have it split over every different email thread that tangentially mentions tabs. My goal with this thread was simply to note some UI design ideas that might interest people, not to solve problems like janky/slow Chromium UX. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mozilla design challenge
There are heuristics we can come up with that are fairly safe. They might be too conservative to be useful though. For example, it should almost always be safe to kill a page that:-has no unload/beforeunload listeners registered -has had no user-interaction that caused JS to execute -has had no user-interaction that changed form field values If we're really worried, we could get arbitrarily strict, e.g. never kill a page with any form fields. But the stricter we get, the less useful this becomes. My definition of safe here is that there generally won't be enough page state lost that the user will notice or care if we kill it. That said, I don't quite get what happens when the user finally switches back to that tab, do we refetch it from the network? What if I was intentionally loading tabs to read because I knew I was going to be disconnected from the network soon (e.g. getting on an airplane)? What if I'm on a bad connection and pages aren't loading well? etc. Ojan On Wed, Jul 22, 2009 at 10:27 AM, David Levin wrote: > There is one internal site that I go to enter some feedback. (It has auto > save now but didn't at one point.) > Recently I don't go there very often. It is entirely possible (and > frequently happens) that I get interrupted while entering feedback and have > to look up other information (during which I look up information from lots > of sources). Then I go back and expect my feedback to still be there. I > would be highly annoyed at any browser that tossed my feedback (which takes > me a while to write). > > An external example of this is the review tool for WebKit (which doesn't > have auto-save and doesn't have a manual draft save mode even). > > dave > > > On Wed, Jul 22, 2009 at 9:54 AM, Linus Upson 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 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 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 >>> 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 /
[chromium-dev] Re: Mozilla design challenge
On Wed, Jul 22, 2009 at 10:08 AM, Brian Rakowski wrote: > 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. Since we already use dragging tabs for other actions (like managing window layout), perhaps when you start dragging a tab we provide an extra drop spot. Conceptually, you're dropping the tab into your backpack to look at later. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mozilla design challenge
There is one internal site that I go to enter some feedback. (It has auto save now but didn't at one point.) Recently I don't go there very often. It is entirely possible (and frequently happens) that I get interrupted while entering feedback and have to look up other information (during which I look up information from lots of sources). Then I go back and expect my feedback to still be there. I would be highly annoyed at any browser that tossed my feedback (which takes me a while to write). An external example of this is the review tool for WebKit (which doesn't have auto-save and doesn't have a manual draft save mode even). dave On Wed, Jul 22, 2009 at 9:54 AM, Linus Upson 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 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 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 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 >> wrote: >> >>> >> >>> I feel like people are using tabs as
[chromium-dev] Re: Mozilla design challenge
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 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 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 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 > 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, 2
[chromium-dev] Re: Mozilla design challenge
On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee 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. Guess we should continue to remove more and more reasons for people to build things in Flash, then = ) > 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mozilla design challenge
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 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 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 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 >>> 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mozilla design challenge
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 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 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 >> 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mozilla design challenge
Can't we have some similar challenge in Chromium for the domui pages? It would be nice to have challenges such as, design the new downloads ui page, history page, or even the new print preview and settings page, etc... Would be nice to see what the users can do if they edit domui pages. Then the UI team (or rest of chromium devs or even the world) will decide which is worth implementing or including in the release. -- Mohamed Mansour On Tue, Jul 21, 2009 at 1:01 PM, Peter Kasting wrote: > On Tue, Jul 21, 2009 at 9:52 AM, Amanda Walker wrote: > >> On Tue, Jul 21, 2009 at 12:32 PM, Erik Kay wrote: >> > 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? >> >> Well, to a first approximation, ones which have had user interaction >> besides scrolling since they were opened? (typing, navigating a link, >> etc.) >> > > I frequently avoid interacting with articles from popular news sites for > thirty seconds or so (as they sit in the background) to let their stupid > interstitial ad timeouts fire. > > Scott Hess' comment that some tabs could be changed into static documents > is accurate from a UX perspective, but as this thread has already mentioned > it's hard to decide which tabs those are. For example, today we load tabs > opened from gmail in the same renderer process as gmail because we don't > realize that those two pages are never going to script each other. If we > don't know page A and page B won't script each other, how can we freeze A or > B? To put it even more simply, if given a tab A, how do we know it won't > run script at some point in the future? > > My own claim is that multiselection of tabs is implementable and useful, > and we should start by implementing that (which in fact Ben is currently > doing, I think), and then see if it helps any of our organization issues. > After that, perhaps some concept of tab pinning would be useful. The idea > here is to add things we know we can do in hopes that better usage patterns > emerge, instead of trying to envision the ideal design from nothing :) > > PK > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mozilla design challenge
On Tue, Jul 21, 2009 at 9:52 AM, Amanda Walker wrote: > On Tue, Jul 21, 2009 at 12:32 PM, Erik Kay wrote: > > 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? > > Well, to a first approximation, ones which have had user interaction > besides scrolling since they were opened? (typing, navigating a link, > etc.) > I frequently avoid interacting with articles from popular news sites for thirty seconds or so (as they sit in the background) to let their stupid interstitial ad timeouts fire. Scott Hess' comment that some tabs could be changed into static documents is accurate from a UX perspective, but as this thread has already mentioned it's hard to decide which tabs those are. For example, today we load tabs opened from gmail in the same renderer process as gmail because we don't realize that those two pages are never going to script each other. If we don't know page A and page B won't script each other, how can we freeze A or B? To put it even more simply, if given a tab A, how do we know it won't run script at some point in the future? My own claim is that multiselection of tabs is implementable and useful, and we should start by implementing that (which in fact Ben is currently doing, I think), and then see if it helps any of our organization issues. After that, perhaps some concept of tab pinning would be useful. The idea here is to add things we know we can do in hopes that better usage patterns emerge, instead of trying to envision the ideal design from nothing :) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mozilla design challenge
On Tue, Jul 21, 2009 at 12:32 PM, Erik Kay wrote: > 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? Well, to a first approximation, ones which have had user interaction besides scrolling since they were opened? (typing, navigating a link, etc.) --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mozilla design challenge
+1. There are tabs which I am using and will use consistently all the time (mail, calendar, things like that). For awhile on Firefox I had those pinned and turned into favicon-only tabs using extensions, and it mostly worked well. Then there are collections of "on deck" tabs associated with things I'm doing. These might be documentation and the like, and mostly I don't need them to be live, I just need them to be easily available, and I'd like them to be grouped together. And then there are one-off tabs like watching a video and looking at someone's photos or reading news, where I'm just going to grind through their contents and dismiss them. There may be new and interesting presentation ideas in there. For a collection of documentation tabs, I might be happy to freeze-dry them in a form which will let me easily come back to them, but which doesn't have to be live at all. Like PDFifying them, except I'd still want them to be resizable and stuff. I'd be very happy if I could do searches over the entire group, or have the browser show me snippets from other docs in the group which might reflect on the doc I'm reading, I'd be super happy if these docs were optimized such that I could flip between them super-duper fast. -scott On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mozilla design challenge
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 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mozilla design challenge
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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
