Could not really find the exact text to quote, but here is the background of the issue from the surf discussion that actually took place on this list. Several authors were arguing as to whether a web browser should have a tabbing functionality, or should this be dealt by a WM (especially a tiling one). As I see it, the biggest benefit here is that we have several instances of a browser (each has only one page opened) instead of one browser process running with several pages. This way, if a browser must hang or crash, the other instances are kept alive - something like this is already implemented in Google Chrome browser, AFAIK.
But another issue that arose here is that some people may have many (like more than 50) tabs opened at the same time - and the author believes that this cannot be dealt by any WM. The responses were different, beginning from suggestions of picking another WM (or tweaking an existing one) to the idea that author is doing something freaky if he needs so many tabs - which is counterproductive. The latter point of view implied a suggestion that the whole tabbing mechanism is inefficient here. I was thinking about an alternative. My POV is, let's take a relatively infamous 5 +/- 2 rule of human being's operational memory, which suggests that we can keep that amount of objects in our oper. memory at one time. This rule is often used by web designers when evaluating a navigation for a web site - if a user has to go through more than 5 levels to get some page on the resource, he is unlikely to be able to recall his path and will get lost. I think this rule may be applied here perfectly well: a person usually opens many tabs so that he could review them in a queue. He doesn't keep in mind what pages does he have opened, he simply passes to the next one as soon he is finished with the current one. This is why we probably don't really need all those pages opened. A suggestion was made to revisit a bookmarking system. I was thinking about it and here is my suggestion: what if basically do not just bookmark pages? We could have something like a scratchpad area where the user could place and arrange the pages he would like to visit later: it could be tags, a tree structure - anything. But the point is, that we don't just collect links here, but actually download pages to a temporary directory on the disk so that we could recall them fast? This way, they don't occupy the RAM, the user doesn't have to wait for download to review this pages and he could actually take a look at them even if he went offline after they were downloaded (which is nice for a mobile workstation)? Besides, we could get ways for arranging those pages more efficiently than it happens with tabbing. I see several issues here: 1. dynamic content Not sure how this could work in this case - this is a rather technical question, I am not competent here (which is why I would like somebody's comment on this) 2. cases where tabbing actually works I could think of only one of such. Say, I have a page that has several links. I open all those links in the background tabs so that I could review them all quickly. For example, a Wikipedia article that has many terms that are explained on the corresponding pages. Or a list of articles that all actually refer to one matter. Probably my solution doesn't work here. Furthermore, there are several ways I see for implementing this design. 1. one page opened, all others stored to disk 2. one page opened, possibly second (or more) pages opened in a split, vim-esque manner. A common case here is to have two pages opened simultaneously so that I could compare them. Possible to get achieved by using (1) approach in a tiling WM - just open two instances of a browser (both of them should be able to access the same directory on the disk for storing and recalling pages at the same time), the job of screen management is done by the WM 3. use the 5 +/- 2 rule in a stack manner: we do have tabs for 5 pages, everything else gets stored. As soon as we close one of the tabs, a page stored gets recalled to a free tab. I am not sure between (1) and (3), but (1) is definetly simplier - and if we take into account that we can get (2) with it too (which would not so straightforward with (3) approach), it could be a better option. At least, more KISS. With all that being said I would really like to hear what you people think about it. -- wbr, Илембитов
