Epiphany Redesign

This page is under active development. Comments and suggestions are welcome!

This page contains a speculative proposal to redesign key elements of Epiphany's user interface. It is based on the proposition that the best way to develop Epiphany's user interface is to identify how tabs are used, and to provide an alternative interface which is optimised in order to cater to these uses.

Tabs

1. What's wrong with tabs?

• Screen overflow. Tabs flow offscreen when a high number are open. This means that all the open tabs cannot be seen or selected. It also makes the display of newly opened tabs difficult.
• Difficult to navigate. Finding a specific tab can often be difficult, particularly when a large number of tabs are open. Only a small amount of information is available for each tab.
• Using tabs to keep pages open (so that they can be returned to) requires planful action and forethought.
• Users are required to close unwanted tabs - tabs create management tasks for users.
• Their purpose overlaps with existing browser functionality (eg. history and bookmarks) but does not integrate with it.
• Some uses of tabs are not easily discoverable (e.g. that it is possible specify that a link should be opened in a new tab rather than a new window).
• They add another layer of interface complexity.
• They are hidden from many window-switching mechanisms, particularly GNOME Shell's overlay.

• Also, we can do better!

Generally, tabs can be seen as a flexible mechanism that is used for a range of tasks none of which they are optimised to cater for.

2. What are tabs used for?

The uses of tabs can be grouped into a number categories:

1. To enable navigation back to pages which have may be required again in a short period of time, and to keep those pages loaded.
2. To organise and group pages. An example: when online shopping, a user might keep pages open in tabs as a way of creating a shortlist of products that they are interested in buying.
3. To record and load pages which the user wants to read in the future.
4. To compare pages.
5. To keep pages open for easy reference (this might particularly be the case for application-like sites and pages, like Gmail or Twitter).

3. Mapping uses to functionality

Each of the uses of tabs can be allocated to a particular area of functionality, either within the browser or window manager:

The implication of this table: Epiphany (and GNOME) could cater to each of the current uses of tabs by taking three steps:

1. Introduce a browsing queue function to Epiphany.
2. Modify Epiphany's history and bookmarks functionality so that it caters to the common uses of tabs.

3. Enhance window management; allow the side-by-side comparison of windows.

The resulting situation would be an improvement upon tabs, since each area of functionality would be optimised for its most common use.

Design preliminaries

1. Use cases

The following design is intended to fulfill the following use cases. These kinds of uses are currently enabled by the use of tabs.

• Allan is shopping for a new sweater. He performs a search on a shopping website. He browses the list of search results. As he does so, he sees a sweater that he likes the look of. He wants to remember this sweater so that he can compare it with any others that he might consider buying, but he also wants to keep on browsing down the list of search results without losing his place.
• Allan is searching for a recipe for macaroni cheese. He does a Google search and immediately sees three pages which look like they might contain the information he is looking for. He reads each of these pages but none of them contains the recipe. He wants to return to the search results page to see if it contains any results which could contain the inforamiton he is looking for.
• Allan is looking for a picture of the Effiel Tower for a presentation he is putting together, but his Internet connection is slow and each page he opens takes a long time to load. He wants to view each page that he finds once it has loaded, rather than having to wait for each page to load before moving on to the next.
• Allan is looking for a flat to rent on Gumtree. He perform a search, producing a long list of adverts. He reviews the results, identifying adverts to fully read. He rejects some of the adverts, leaving a shortlist to chase up. Some of the flats have already been let. He arranges viewings for others. Some do not respond to his calls, and he decides to ring them another time. He repeats this process using slightly different search criteria. Some of the results link to adverts he has already seen - adverts which he has rejected, organised viewings for, or is planning to call later in the day.

2. Design aims

• Add a 'browsing queue' facility.
• Integrate Epiphany's history, bookmarks and queuing functionality into the browsing experience: these should be available from within the user's current browser window.
• Optimise history and bookmarks for the short and medium term operations that are most common within web browsing practice - 'open the third page I last saw', 'show me the pages I bookmarked in the last hour/day'.
• Automate the caching of pages - Epiphany should cache the pages which a user is likely to want to return to.
  • This could be achieved by caching the most recent pages, or by utilising a more sophisticated prediction algorithm.
• Cater to netbooks and widescreen displays by using a minimum amount of vertical screen space.
• Browsing history, bookmarks and queue should be rich, informative and flexible.
• History should provide management facilities like deleting of pages from the history, sorting and bookmarking.
• Adding to queue and bookmarks should be quick and should not interfere with the task of browsing.
  • One click bookmarking is necessary for this.
• Enable users to write notes on their bookmarked pages?

3. Secondary design aims

• Modernise the home page.
• Clean up the main toolbar.

The design

The following mockups are intended to suggest an approach to organising the various components of Epiphany's interface. They are also meant to explore the feasibility of removing tabs from the browser. The mockups for the history, bookmarks, queue, and home page are meant to be illustrative only.

1. Main interface

Features

• Single toolbar which allows access to history, bookmarks, queue, and start page.
• Combined go, stop and refresh button.

2. History

Features:

• Optimised for navigation of short term history.
• Facilities for removing pages from the history and for one click bookmarking.
• Search and sort functions.
• It should be possible to add pages from the history to the browsing queue.

3. Bookmarks

• Grid view is optimised for the management of recently viewed pages.
• List view enables fine grained navigation.
• Search and sort affect both the topic list and the pages displayed.

4. Browsing queue

Features:

• Pages are added to the queue through middle mouse button or right click context menu. Could pages also be dragged to the queue button?
• Pages in the queue would be automatically loaded.
• Queue and next buttons will grey out when no pages are in the queue.

5. Home page

Features:

• Recent popular pages are selected for display. These can be pinned to the home page.
• Indicates network connection status.

Comments and discussion

• I really like the "Queue" idea and mockup. I think it could go even further by adopting a list view (much like the corresponding bookmark mockup) and allowing people to take notes on the side. That way, the original queue page could evolve smoothly to a kind of "reference set" which could be saved for further reuse. However, since this last feature could be a bit of overkill in regard with traditional browser feature set, that could be the target of a plugin instead, a kind of "improved queue plugin" which would support save and load (BertrandRousseau).