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 <[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 -~----------~----~----~----~------~----~------~--~---
