Flow Browser

The zoomable Web browser that automatically organizes your tasks.

How might we manage information overload on the Web?

This is the question that I researched for my master’s thesis at the Touro College Graduate School of Technology. To answer this question, I built a demo Web browser, named Flow. This article will review the design process behind Flow.

Demo of Flow browser

Table of Contents

1. Master’s Thesis Presentation (2019)
2. The Problem
3. Browser History: How Did We Get Here?
4. Research a. Studies on Tabbed Browsing b. Studies on Multitasking
5. Competitive Analysis
6. Insights a. Personas b. Problems with Tabbed Browsing c. Web-Browsing Structure d. Inspiration e. Guidelines for Browser Design
7. My Previous Solutions
8. Designing Flow a. User Flow b. Sketches c. Design System d. Code
9. Demo a. Welcome to Flow! b. Browsing and Searching in Flow c. Opening Links in Flow d. Page-Switching and Page-Closing in Flow e. Links Always Open in the Right Place f. Flow Keeps Your Tasks Separate
10. Next Steps a. Source Code b. An Outline of a Humane Web-Based OS

Master’s Thesis Presentation (2019)

This case study is based my master’s thesis presentation. I’ve placed it here for anyone who prefers to watch it.

[embed]Flow Browser — UX Thesis Presentation, by me

The Problem

Has this ever happened to you?

Pie Comic, by John McNamee

We must solve Granny’s problem before her granddaughter becomes a granny herself!

100 tabs in Chrome (left) and in Firefox (right)

This is the infamous ‘too many tabs’ problem. Accomplishing anything on the Web can get extremely difficult when browsers have to deal with an embarrassment of tabs. Chrome makes tabs way too small; Firefox hides extra tabs off-screen. Neither actually helps you organize anything.

Browser History: How Did We Get Here?

How did browsers deal with multiple pages in the past?

WorldWideWeb (1990) — the first Web browser

The very first browser, Tim Berners-Lee’s WorldWideWeb, opened each link in a new window. This clearly led to the ‘too many pages’ problem, because people soon invented the Back button.

Line Mode Browser — the first browser with a Back command

It was Mosaic that popularized the Back button, which hid all those pages within the window’s history. But you could still create separate windows, so that lead to the ‘too many windows’ problem! It wasn’t long until someone invented tabs, which everyone else copied.

InternetWorks (1994) — the first tabbed browser

Now, if you want to find a Web page you were recently reading, it might be in a different window in a different tab within that window hidden behind the Back button! The more tabs you have, the worse it gets! All the previous solutions are now getting in the way of proper organization.

By 2007, people started noticing, leading Aza Raskin to publish this design challenge:

Humanized Puzzler: Firefox Tabs (2007)

I’ve been trying to solve this problem ever since.

Research

Studies on Tabbed Browsing

How casual and power users use tabs and the Back button (Mozilla, 2010)

In 2010, Mozilla published a study on tab usage in Firefox users. They found that casual users prefer to open each link in the same tab and, therefore, rely on the Back button to revisit pages. Power users, on the other hand, prefer to open each link in a new tab and, therefore, rely on tab-switching to revisit pages. This is because both the Back button and the tab bar show you your browsing history. Having both features is somewhat redundant, and so users generally prefer to rely on one and ignore the other.

In 2015, Nielsen Norman Group published a related study. Their results were very similar, but they grouped people by age. They found that millennials are generally page parkers: they like to open many links in new tabs for later. Older users, on the other hand, are parallel browsers: they “pogo-stick” between a central hub (the parent page) and its links.

[embed]How many tabs do you have open right now? (Twitter poll by @firefox on Nov 7, 2019)

In 2019, Mozilla asked on Twitter how many tabs people had open. Most people had at least 10 tabs open, while many people had even more than that. Based on the previous studies, it seems likely that the “don’t judge me” group consists of power users / parallel browsers.

Studies on Multitasking

Browser tabs make it easy to multitask, but not so easy to focus on one task. How does that affect how we use the Web? A study of media multitasking found that some people are heavy media multitaskers. These people are more suspect to irrelevant stimuli. Consequently, they are less capable of filtering out irrelevant tasks and are (surprisingly) 167 ms slower at task-switching than light media multitaskers. Therefore, browsers should make focusing easy and unnecessary multitasking difficult, while necessary multitasking should be as efficient as possible.

Competitive Analysis

For my competitive analysis, I looked at many different takes on how to improve tabbed browsing. There were a few research browsers:

Tree Trailblazer (2008), Contextual Tab Manager (2009), and Bento Browser (2018)

Tree Trailblazer is wonderfully similar to my own Firefox ZUI concept from 2010. Both are similar to the Pad++ Web Browser from 1996. Of these research browsers, Tree Trailblazer is the most suitable for general browsing. Its main issue is that the interface is a bit more complex than it needs to be.

Next, some solutions augment your browser with tab groups and trees:

Firefox Tab Groups, Opera Tab Stacks, and Tree Style Tab

Tab grouping is generally a good solution (and it’s the one I currently use), but it still requires too much manual work. Tree Style Tab is even better, as the tree display automatically organizes all your tabs. The interface, however, takes up much screen real estate.

Finally, the market is saturated with tab organizers:

OneTab, Toby, Tabli, TooManyTabs, Workana, and Infinite Tabs Manager

Unlike tab-grouping, these products are not fully integrated with the browser, making the issue of manual labor even more acute.

Insights

Personas

The research shows that there are generally two types of people when it comes to browsing:

Two types of Web-browsing personas: the parallel browser and the page parker

Ideally, we want a browsing interface that combines the pros of each persona’s behavior while removing the cons: tasks are separated, but page revisitation is quick. Such an interface should improve Web browsing for everyone.

Problems with Tabbed Browsing

The ‘too many tabs’ problem can be broken down into several issues:

1. Tab triage: tabs are intermixed, with no visible structure, so it’s hard to know what to do first.

The difficulty of tab triage

2. Tab-finding: tabs can become hard to identify and easy to lose.

So many tabs! But where’s Waldo?

3. Page revisitation: pages can easily be lost behind the Back or Forward buttons. This problem gets worse when you open a link in a new tab. Suppose you close the originating tab. Now, if you want to go to the previous page, you can’t, because the Back button doesn’t store the history of the originating tab!

1. Open a link in a new tab. 2. Close the original tab. 3. Try to go back… You can’t!

4. Loss of focus / state of flow: both your time and your focus are lost when multitasking, waiting for pages to load, choosing a tab, deciding whether to open a link in the current tab or a new one.

When do I need to read this link? Now, or later?

Web-Browsing Structure

xkcd #214: The Problem with Wikipedia (2007)

I was inspired to solve the Humanized design challenge when someone posted xkcd #214: The Problem with Wikipedia. All of the pages in this tree are related and neatly organized. In real life, however, you would have a bunch of related Wikipedia tabs in the middle of other unrelated tabs. So, I realized that we need to:

1. Group pages based on the browsing tree,
2. Separate the trees, and
3. Simplify each tree (if possible).

How do we simplify a tree? Suppose we start with this structure:

Tree structure for a typical browsing session

If you open each page in a new tab, then each node is a tab, with the tabs ordered depth-first. Thus, when reading each page, you’d follow this order:

Depth-first traversal of the browsing tree

In other words, we can safely discard a dimension from the two-dimensional tree while retaining the logical (depth-first) order:

A 2-dimensional tree viewed 1-dimensionally

This ordering is how one would usually want to traverse the tree.

Inspiration

Besides xkcd, my design was greatly inspired by two other sources. First is the “ZoomWorld” concept, from *The Humane Interface *(2000), by Jef Raskin (father of Aza Raskin, who created both the Humanized design challenge and Firefox’s original Tab Groups). This concept was an outline of how computing could be improved by switching to a zoomable user interface (ZUI). Although ZoomWorld was never completed, as Jef Raskin passed away, we can still view Aza’s demo:

Aza Raskin’s Flash demo of ZoomWorld (2005)

My other inspiration was Palm webOS, especially its beautiful stacked-cards interface:

Palm webOS (2009)

Guidelines for Browser Design

Putting everything together, I have come up with four guidelines that all browser designers should follow:

1. Group related pages automatically.
2. Keep track of the browsing structure.
3. No Back button: don’t replace the current page when a link is opened.
4. Display full pages instead of little tabs.

My Previous Solutions

Since 2007, I’ve been designing solutions to the ‘too many tabs’ problem and iterating on them.

The first solution that I published was Firefox ZUI, in 2010 (which I began in 2008):

Firefox ZUI, by me (2010)

This was a zoomable interface that looked just like xkcd #214. This was later followed by Ubiquitous Firefox, which I was invited to publish on the Mozilla Labs blog in 2011:

Ubiquitous Firefox, by me (2011)

This interface kept tabs but replaced the Back/Forward buttons with a visual interface for the tab’s history/tree. In 2012, I revisited this concept and reimagined it as a zoomable interface:

‘Ubiquitous Firefox’ Revisited, by me (2012)

Finally, I created a refined interactive mockup of this concept at Touro College in 2017, which I called Tab-Free Browser:

Tab-Free Browser, by me (2017)

Designing Flow

In designing the browser, I created a user flow, a couple of sketches, and a design system.

User Flow

User flow for Flow

Sketches

Two alternate sketches for Flow

Design System

Design system and high-fidelity mockups for Flow

Note that the design system is extremely simple, as there are virtually no administrative debris.

Code

I wanted to program a functional demo of my browser, so I could demonstrate it with any input. I inquired on Stack Overflow about how I might build a browser using Web languages. In the end, I chose to create a Chrome app.

‘Web browser interface using HTML/CSS/JS?’ on Stack Overflow, by me

Demo

Welcome to Flow!

Welcome to Flow!

This is Flow. Fun fact: the background is a checkerboard of black and white pixels, just like the original Macintosh.

Browsing and Searching in Flow

[embed]Browsing and searching in Flow

When you browse or search in Flow, the page is added to the canvas and the view zooms in completely on that page. So, as soon as you want to see a page, the browser helps you by showing only that page, full-screen, and without any interface elements or distractions.

Opening Links in Flow

[embed]Opening links in Flow

Each time you open a link, it creates a new page next to the current page. The current page is never replaced by the new link. A page here is not a tab, but the actual page. You never have to waste time deciding whether you want to open a link in the current tab or in a new tab.

Moreover, you don’t need to wait for the browser to load the link you just opened. While the link is being loaded, you can continue reading the page you’re on and opening other links. You don’t have to close the current page until you’re sure you’re done with it.

Page-Switching and Page-Closing in Flow

[embed]Page-switching and page-closing in Flow

To switch between pages, you simply swipe left or right. Your page history is visible and obvious. Nothing is hidden behind the Back button, which is now obsolete.

To close a page, you swipe it away upwards. Rather than using a small button to close a page, we use direct manipulation to remove a page. This is the benefit of using pages to represent themselves, rather than indirect interface elements, such as tabs or buttons.

Links Always Open in the Right Place

[embed]Links always open in the right place

In every single browser, if you go back to an older page and open a link, the Forward pages disappear. This is not the case in Flow. Pages remain on your canvas until you purposefully remove them.

Moreover, when you open links from a page, the pages that are created appear in the right place and in the right order— right next to the current page, rather than at the very end of the page stack. Flow will keep track of the relationships between parent and child pages, so that links will always open in the logical place.

Flow Keeps Your Tasks Separate

[embed]Flow keeps your tasks separate

When you perform a new search or open a new page from scratch, a new stack of pages is created. That way, tasks are always separate, and manual organization is never necessary. Zooming out allows you to see all of your tasks and the pages open within each one.

Since tasks and are automatically organized, the ‘too many tabs’ problem is moot. Moreover, we have replaced the various methods of organizing pages — Back/Forward buttons, windows, tabs, and tab groups — with the simpler and more obvious concepts of pages and page stacks. This is how browsers should have been designed in the first place!

Next Steps

I would like to refine the code for my demo and build something that others could test. From there, we need an MVP, so people can actually use this browser in the real world. I am looking for collaborators to help me with programming Flow.

Source Code

The source code for Flow is on GitHub.

An Outline of a Humane Web-Based OS

My ultimate goal is not just to solve the ‘too many tabs’ problem, but also to solve the problems of modern computing, as outlined by Jef Raskin in *The Humane Interface*. To do that, I hope to improve Flow to the point where it’s a a an entire Web-based OS — one that works quite differently from and more humanely than other operating systems. Materializing this vision will require funding.

This is a brief outline of my plan for Flow:

1. Allow items on the screen to be rearranged arbitrarily.
2. Add grouping, so you can have related page stacks in their own separate space. To see this space, you zoom into that group. Groups can also be nested.
3. Allow stacks or groups to be resized, so that more more important items are big, while less important items are small. To see smaller items, you zoom in. With the addition of this feature, the browser can effectively be called a ZUI (zoomable user interface).
4. Abolish the transient property of Web pages by storing each one offline automatically for you. Thus, if a page is open, it’s yours to read or modify as you please. Moreover, the page’s history as your modify or reload it should be stored as well.
5. Use this interface as a zoomable file manager, where everything can be organized: Web pages, downloaded files, and your own files. So, instead of looking for the file you downloaded, it opens up right there in your stack, no different from any other page. Similarly, your own files and folders could automatically show up as grouped pages. You never have to think about the artificial distinction between online pages and offline files. Pages and other files can be organized together in whatever way you find useful.
6. Instead of apps, which are inhumane, we introduce commands that work everywhere. Since, in Flow, everything is a page, there’s essentially one file format. This makes it much easier for a command that’s you’ve installed (or written) to work absolutely anywhere, instead of being trapped inside an application. This step is crucial to saving humanity from the tyranny of ‘applications’.
7. All pages should be shareable, such that any page on your system could have multiple people collaborating on it in real time. Publishing to the Web is now similarly easy.
8. With this interface approaching the point where it is the main window onto all your data, we need the ability to store it all online in the server of your choice (encrypted, of course!). Thus, you never have to worry about having enough storage, as data could be loaded and unloaded on any of your devices as needed. Such a service could be offered as the business model for Flow (a humane business model that doesn’t rely on advertising or hiding source code!).

These are some of the features that Flow should eventually incorporate. The browser’s page-based design makes it natural to solve not just the tab problem but other major problems of computing as well. This is all because, in HCI terms, Flow is *document-centric rather than application-centric*.

Ultimately, the goal here is w̶o̶r̶l̶d̶ d̶̶o̶m̶i̶n̶a̶t̶i̶o̶n to make the world a better place!