Why new Firefox 13 'load tabs on demand' is bad UX. | Hacker News Reader

Why new Firefox 13 'load tabs on demand' is bad UX.

renesd.blogspot.co.uk

14 pointsillumen26 comments

I don't care if it is bad UX, I prefer it. I also turn off all the different types of preloading in Chrome, but that's another story.

The loading of a page hardly takes any time at all, and I generally have to reload the page when I finally get to older tabs anyways. And, this is silly, but it feels wasteful to have all tabs loaded all the time when I'm only using one or a few at any given moment.

Also I wouldn't mind if someone invented the "next great thing" to get us away from tabs. They are unwieldy, encourage tab-hoarding, and it is difficult to quickly locate a specific tab within a nontrivial number of open tabs. My overloaded tab bar causes more anguish than my email inbox.

We used to do this in Chrome in our pre-release days. It was annoying to use so we turned it off. The downside is that our session restore startup time could definitely be better for large numbers of tabs. We could do a better job of prioritizing loads. The right balance is doing the right thing for the user without exposing an implementation detail IMO.

Interesting.

Putting in the work to just improve the speed is the hard fix usually. But I guess firefox and chrome are fairly optimized for loading already.

However, some good heuristics might help. Things like number of tabs, most common tabs used, active tab, time to load and responsiveness(frame rate, latency etc) would be good indicators.

I'm not sure how good hard coding stuff in like number of tabs would be. Whilst just loading up to 8 tabs would probably work, these numbers seem to change over time. Like the oldIE 4 connections limit for example. But! With frequent automatic updates, this value could be tweaked later if needed.

Cpu, and IO could be set based on the indicators as well.

Why not something like:

  If *n* tabs >= x

      Load tabs on demand

  Else

      Load tabs in background

x can be set by default at some arbitrary number and also be changed.

Problem is, X will change based on a bunch of factors - type of browsing, screen real-estate, etc. If that isn't taken into account, it could result in what the user perceives to be a jarring interface shift.

We could use much more subtle algorithms - what about loading visible page, then queuing up X background tabs to concurrently load (based tab order)? What about a logarithmic backoff (ie, load up visible and several background pages, then slowly load others)?

Fact is, user-time is valuable, compute time (and for most users) bandwidth is not. What's valuable should be prioritized.

The problem with Chrome not having such an option is not just limited to startup time when restoring a session. Having too many open tabs causes the resource consumption to go through the roof (especially RAM and CPU cycles). I can easily have several hundreds of tabs in Firefox (in combination with tab groups) because I usually use different small subsets of tabs during my sessions so the resource usage is quite manageable.

I've said it times and again: Chrome is optimized for a single use case (i.e. few tab users) at which it excels but tends to break down quickly once you leave its comfort zone, unless you have a fairly powerful system. Maybe the project leader nudge, nudge could divert some resources to make Chrome scale better. ;-)

Except for users that have dozens of tabs loaded because they're digital packrats, and don't care about most of them most of the time.

Like me. I can easily reach over 450 tabs, and have been using this feature since Firefox 4, when it was added.

I fully agree, I currently have 174 tabs open, and that's actually a low number for me (I closed a couple hundred down on the weekend). Having all of them reload when I restart my browser was a nightmare before this feature. Everytime I'd have to hunt down a couple tabs that contain auto-playing videos. All while getting Basic Auth password popups for work related resources.

Plus, it is much better for over-all performance since some websites switched to an interface that polls for updates in the background.

Of course I know I'm not a typical user, so I wouldn't really argue against this being an option that is off by default. But it would very much hurt my user experience if it weren't available at all.

Yeah, it's definitely an improvement for you 50+ tab peoples. Not so good for the 5-8 tab people. I think both groups should get a good user experience though.

I agree. That's why I said I just want to have the option, but I don't care about its initial state :) I wouldn't even care if it were only available in about:config.

I just wanted to mention my viewpoint (started writing it before I saw the other replies), since I find it an important improvement. For example, I won't use Chromium regularly besides testing things in it, because it would be way too painful for me.

It's already an option in the Firefox options/preferences UI.

In the "General" preferences in Firefox 13, if you have "Show my tabs from last time" selected, there's a checkbox for "Don't load tabs until selected".

In Firefox 15 and later, the checkbox is in the "Tabs" pane so it's always accessible: http://zpao.com/posts/making-restore-on-demand-accessible/

I know, which is why FF is my main browser. I'm just arguing the importance of the option for my personal usage patterns.

It's great the option is there, and thanks SO much for pointing it out. Now for me as one of the 5-8 tab people, restoring tabs will be a good experience. You get 39 hero points, and 72.55 gold stars.

However, I'm of the opinion that options are bad UX too (until you find them :). It's better when the experience is just good. I know that's asking a lot... but I think it's possible with some combination of the ideas mentioned in this discussion to automatically do the right thing for most users.

Sounds like the ideal would be: preload the most recent N (configurable?) tabs.

That wouldn't hurt me :) I could even imagine it being useful to be able to automatically load the surrounding context (say N pages left and right). Or load all adjacent pages on the same domain as the active tab, which would be quite useful if one often browses manuals.

So, the behavior you're talking about is basically treating the tab bar as a hybrid "what I'm about to read after closing this" and "what I stopped reading and might get back to after closing this" queue. For this type of browsing behavior, I would go even further than just not restoring tabs. I would unload backgrounded tabs with "simple" content[1] when they've not been in use for a while (say, half an hour, plus not being in the 5-10 most-recently-used tabs), only keeping the URL and, say, the scroll-position. (Plus maybe <input> contents if you don't want to be cruel to the web developers who haven't yet heard of localStorage.)

[1] It would be interesting to define a heuristic for what qualifies as a "simple" webpage. Perhaps anything that doesn't do any JS setTimeouts or websocket connection creation would count? It'd likely be best to just leave it to the web server to declare "simplicity" of a page as a header, the same way companies can declare "recyclable" on boxes. One would wonder if any company would bother to use this if it meant their own tab would seem slower-to-reload than their competitors', though...

What about throttled loading ? processing wise, what is in the background will have 5% cpu allocated.

One thing that comes to mind is to do all the actual loading of assets (HTML, CSS, images, JS, etc) but don't decompress/run anything. That way it can be done 100% in the background and then spin up quickly without having to hit the network once a tab is clicked.

Might have to look into trying something like that out; I work on Gecko, but in totally different parts of the code, so it'd be a fun little experiment if nothing else.

Resource prefetch would be good. I don't even know if it's possible for applications to throttle cpu/thread usage.

Threads and processes can be given a lower priority.

Edit for @barrkel: you can also do more advanced resource shaping on some OSen. Like limiting the number of network connections per second, and limiting the bandwidth. There are also cpu throttling possibilities where you can make sure a process only runs max 10% of cpu. Or as you say, putting scheduling into the app is another possibility.

Lower priority does nothing to throttle activity unless there is a higher priority thread available to run; if the machine is otherwise idle, lowest priority threads will use 100% of CPU resources. If you want to avoid high CPU graphs, whirring fans from increased heat, etc., you need to make the thread or process sleep occasionally.

For a thread, that's best done with explicit coding; for a process that isn't sharing resources with other processes, you can get away with more invasive freezing from the outside.

I guess it's possible to code a tiny arbiter that will wake 'background' thread every few ms.

This seems like an issue only power users will have for the most part. Firefox even has an option to disable this for power users.

However, with that being said, I'm not a big fan. I think agumonkey's throttled loading is a nice idea though.

There's definitely different groups of users here. Without being able to spy on firefox users, I'd guess the 5-8 tabs people are a decently sized group. The one tab people, and the 50-400 tab people are probably other sizable groups.

The new change helps out the 50-400 tab people a lot. Each group could all do with a good UX though.

Off-topic: has anyone on HN spent time cataloguing either good UX choices or bad UX choices in today's web? I'm slowly beginning to take interest in user experience design (I'm a backend developer).

Reply on news.ycombinator.com