Electric Ants HQ

Note:
I wrote this article as an up-to-date addition to a wishlist thread "Page grouping roadmap" I started with the same name. The nice thing about blog articles is that there's no time limit for editing. Plus, I can add images.


Page grouping is a frequently requested feature for quite long in the Desktop wish-list. The discussions have produced a wide range of ideas with great potential. It's time to look back and decide which of the proposed solutions are realistic as a first step against cluttered page bars.


Which pages belong in a group?

This is a basic question for all page grouping solutions. As expressed in an old post by csant, there is some contradiction of a hierarchical group structure with the network-like structure of the web. However, for page grouping, it is not necessary to categorize the web. We only need to categorize the pages that are open in the page bar, and there are some useful criteria for that.

Proposals and solutions in concurrent products include the categorization by domain name, by the type of service (web, mail client, chat..), predefined filters, or letting the user arrange tabs in groups manually.

I think the best solution so far is seeing those pages as related that were opened as an "open in new tab" link from the same "parent" page (proposed in similar ways by RobbieGee and by non-troppo). This solution provides a predictable organization, and does not require any extra interaction from the user.


Page bar enhancements

The next question is how to present the categories of tabs to the user. An ideal solution needs to provide a good overview of the open tabs, revealing both their names and the relatedness structure, and a quick way to switch from one tab to another. Ideally, every tab is available with one click. On the other hand, the page bar should not occupy too much screen space, so it is often not possible to display the full title of each tab.

The idea of parent and child tabs can already be implemented with minimal changes of the interface. We only need an additional option in preferences > advanced > tabs : "open new tab next to active". The new option would be "Open only Links next to active page." If you click a link to open in a new or background page, it makes sense to open that page next to the active one. With Ctrl-T, it makes more sense to open that page at the end of the page bar, or behind the children of the active page.

From there it is only a little step to non-troppo's color coding, where this group structure is visualized with colors.

An existing possibility for organize pages in groups is to put them into distinct browser windows. This functionality would be much more comfortable if these windows were represented in some way on the page bar (instead or in addition to the OS taskbar).


Multi-layer page bar

The next step is a page bar with two layers: One for the groups, and one for the contents of the active group. An implementation can be seen in the "Tab Groups" FF addon. The groups are organized manually, but parts of the "parent and child page" relationship is automatically realised: Links clicked in the active page will always open in the same group.

A drawback of this representation is that pages in the non-active group are not available with one click, not even visible. At least, the size (number of open tabs) of each group is shown in the group tab.

Building on this idea:

• Temporarily switch to the group contents when hovering the group tab, as in FataL's tab-based dynamic menu.
  
• The same, but with dropdowns.
  
• The same, but show the group tabs in a temporary fade-in toolbar below the active group tabs, so they don't hide the active group (but part of the page instead). Similar to this crappy demo, http://files.myopera.com/Schneemann/files/page%20grouping%20demo.html
  
• Show small-size icons for each tab inside the group tab, as in this crappy Tab grouping mockup. The point here is that only the tabs in the active group get a readable caption (at the cost of toolbar pixels), but still every tab has a representation for one-click access (which can reveal its contents on hover).
  

Mouseover film strip for micro-squeezed tabs

Squeezing a large number of tabs in one row, or having the small-size representation inside a group tab as proposed above, it becomes necessary to reveal the page title and other details) on mouseover. The traditional solution here is a tooltip (with thumbnail). Unfortunately, tooltips tend to pop up with a delay - by purpose, I assume, because they can hide lower parts of the page bar, and of the rest of the interface. I think that tooltips are far from being the best mouseover information.

Better than tooltips?

I imagine a temporary and half-transparent horizontal bar that fades in when hovering a (squeezed-size) tab in the page bar, showing a "zoomed-in" version of the page bar in vicinity of the tab that is hovered, where each tab is wide enough to read the title, and with a colored focus on the hovered tab. Moving the mouse left and right will scroll that horizontal bar, moving somewhere else will make it disappear.

If you want thumbnails, maybe the horizontal bar can be made to look like a film strip that shifts/spins left and right. If you prefer the tooltip, we could still discuss about placing the tooltip in a fixed position, instead of under the mouse pointer. This would look like cutting a hole in the active page, to see what's behind / what comes next.


Highlight related tabs

With this feature, we drop the idea that tabs are to be arranged in disjoint groups. Instead, a "relatedness measure" is defined that tells how much one page is related to another one, depending on different criteria.

To visualize this, we would highlight the tabs that are considered related to the active page and/or to the mouseover tab.

The idea is quite interesting from a Gestalt theory point of view: While the other solutions were based on the Gestalt laws of closure and proximity, this one is based on similarity and common fate. This means, adding this feature can exploit a perceptual channel that otherwise remains unused.

See this demo. In this form it appears more confusing than helpful, but it shows the idea, more or less. An advanced version would have multiple levels of highlighting..


Prioritize the active group (cpu/bandwidth/memory)

That's another advantage: If tabs are organized in groups, it will be easier for Opera to guess which tabs are more likely to be viewed next, so it can use a process and bandwidth management strategy that is based on the groups.

(see Prioritize page loading)


Tree of back/forward links

Not exactly the same as page grouping, but this could be a way to reduce the total number of tabs.
The back/forward history of a page in conventional browser is linear. This means, if you go 3 steps back, and then click another link, the 3 pages in the "forward" history are lost.
In the proposal by alexsisson, "Tree" of back/foward links., the linear page history is extended to a tree, so no pages are ever lost.

See Search Engines Sharing Thread in the official Opera forums.

I put all relevant information in there, so this article is quite redundant by now, and I won't spend time to update.

The basic idea of the search engines presented here is to turn your address bar into a javascript-based commandline, that takes written commands plus arguments. This way, you can create search engines to translate the active page, start a specific radio station on last.fm, etc. This opens much more possibilities than just ordinary searches.

Before Opera 9, it was necessary to edit the search.ini file, or use an external editor, called "Opsed", to create your own search engines. This also meant that a search engine code needs to fit into one line of text. With the new gui features to edit search engines inside Opera, it is possible to copy & paste a multi-line code into the search engine editor. It will still appear as a one-line code in the search.ini, but it helps me to present the code in a readable way.

At the moment I am interested in creating searches that append multiple result pages in one bigger page ("antipagination"). This could be solved by "inline frames", but I don't like to have additional scrollable elements in the page. So, if you know about a javascript hack that helps to append different pages, I would like to see your comment! The finished engine can then be added to the "Search engines sharing thread" in the official forums.

Read more...