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
On Wed, Jul 22, 2009 at 6:08 PM, Brian Rakowskibr...@chromium.org 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
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
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
On Wed, Jul 22, 2009 at 10:08 AM, Brian Rakowskibr...@chromium.org 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
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
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
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
+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
On Tue, Jul 21, 2009 at 12:32 PM, Erik Kayerik...@chromium.org 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
On Tue, Jul 21, 2009 at 9:52 AM, Amanda Walker ama...@chromium.org wrote:
On Tue, Jul 21, 2009 at 12:32 PM, Erik Kayerik...@chromium.org 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
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
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
On Tue, Jul 21, 2009 at 8:28 AM, Dean McNameede...@chromium.org 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
14 matches
Mail list logo
