An Activity-Based Web Browser
Calum Grant, 21st June 2009
This is my submission for the Mozilla Labs Design Challenge Summer 09. The task is to redesign the web browser user interface to manage the thousands of pages we deal with on a daily basis.
Introduction
The web is becoming more and more embedded into the way we work. A result of this is that we spend a lot more time on line, and dealing with many more web pages. There are many problems of scale – and in the web browser the problem is about finding pages of interest, organising our reading, and managing the thousands of pages we need to read or reread.
The multiple window, multiple tab and bookmark features of browsers are victims of this scale. Multiple browser windows have been replaced by tabs, which in turn no longer scale quite so well. Something new is needed. Bookmarks can get out of control as users struggle with hundreds of bookmarks, or don’t bookmark and can’t find the page again.
A few observations motivate this submission.
Tabs are just short-lived bookmarks. A tab is a short-term store for a web page which you may want to visit quite soon. Pages in tabs are stored in-memory in DOM, whereas bookmarks are stored per URL, and are perhaps cached on disk. These are implementation details. Managing bookmarks is however non-trivial, and when we organise tabs, we are really talking about organising bookmarks.
Web browsing is part of a larger activity. Usually web pages are not viewed in isolation, but are part of an activity perhaps spanning days or weeks. Web browsing can be organised into a workflow. The browser should assist with the entire browsing activity, not just display web pages. The main problem is organising the pages we haven’t read, not the ones that we already have.
Tabs are used to multitask. Often there will be several activities, or sub-activities. Tabs can help organise activities, but the real problem is to support multiple activities in the browser.
This submission organises web pages into activities. Each activity has a number of associated pages, which are divided into unread, read and bookmarked. The browser turns into a reader, where unread pages are read, perhaps bookmarked, and new pages are added to the unread queue. RSS feeds also become part of the activity by adding pages to the unread queue.
The key concept is that when a user middle-clicks on a link (as if to open a tab), then the link is added to the unread queue.
This concept can be delivered as a feature which is independent of tabs. People can still use tabs if they prefer, but hopefully the number of tabs will be greatly reduced as people move to the activity-oriented solution.
Mock-up
Detailed
Description
Conceptual model
The user maintains a list of activities, which can be structured into a tree of sub-activities. Each activity has a list of bookmarks, read and unread pages.
Each browser window has exactly one active activity. There is a root activity which represents all browsing activity which is the default. Beneath the root activity are current activities and completed activities.
Each activity inherits bookmarks, read and unread pages from its sub-activities. I.e. the unread pages in the root activity contain all of the unread pages from all of the tasks.
Bookmarks can be active, meaning that they are re-checked on a periodical basis and marked as unread if the content has changed.
Activity view
The activity view is a kind of enhanced bookmarks organiser, and the feature could even be integrated with the browser bookmarks.
Information visible in the activity view:
· A hierarchy of activities, collapsible.
· Which activities have unread pages, and the total number of unread pages. Numbers count pages from sub-activities.
· An indication of the current activity.
· Pages in each activity. Each page shows the following information:
o Title of page
o Domain of page
o Whether the page is unread (indicated in bold)
o Whether the page is bookmarked (indicated by a red flag)
o Whether the page is an active bookmark (indicated by a green flag)
o A graphical thumbnail of each page (optional).
o Community rating (optional)
o Pages are ordered by any column, default to status (bookmarked, unread, read). Note that all pages visited in the activity are saved.
Figure 1 shows an illustration of the activity view.
Actions available on activities:
· Delete activity.
· Rename activity.
· Move to completed activities.
· Add search terms.
· Add URL.
· Switch to activity (double click on activity).
· Move activity (drag and drop, cut copy paste).
· Start reading activity (menu, button with icon) shows next unread page.
Actions available on pages:
· Delete page.
· Mark page read.
· Mark page unread.
· Make active bookmark (toggle).
· Navigate to page (double click on page), and also changes the current activity.
· Rename page.
· View URL.
· Move page to new activity (drag and drop, cut, copy and paste).
· View page properties (pop up dialog box)
Properties viewable for each page:
· Title of page.
· Domain of the page.
· URL of the page.
· Date the page was added.
· Date the page was read.
· Date page last updated.
· Community feedback on the page, such as rating, safety or Google pagerank.
· Graphical thumbnail of the page.
The activity view could be a display pane which can be hidden, or it could just be rendered DOM in the main browser window. The activity view could be the default start page for the browser.
Web page view
Additional options are provided to support activities. These options are presented in toolbars and in menus. An “activity toolbar” is proposed to group activity-related actions together, which can be disabled if the feature is not used.
The following information is displayed:
· The current activity, which defaults to “all activities”.
· The number of unread pages in the current activity. This also counts the unread pages in any sub-activities.
New actions available on web pages:
· Display activities (button with icon). This switches to the “Activity view”.
· Switch activity (drop-down list). Shows the five most recent activities, the number of unread items per activity, and a “Create new…” option to create a new activity. The “More...” option displays the activities organiser page.
· Go to parent activity (button with icon). Changes the current activity.
· Create activity (button with icon, Ctrl+N). Also “<New>” entry in the activity drop-down. The text in the activity drop-down is highlighted so the user edits the name. Creates a new sub-activity of the current activity.
· Queue link (middle-button click, context menu). Instead of opening a tab in the background, the link is added to the current activity.
· Bookmark link (context menu).
· Active bookmark link (context menu). Adds the link as an active bookmark. RSS feeds can also be added as active bookmarks.
· Previous page (PgUp), allowing the stream of web pages to be read as a book.
· Next unread (button with icon, PgDn key). Navigates to the next unread page, and marks the current page as read. When you scroll down with PgDn, it automatically goes to the next unread item when you read the bottom of the page. PgUp goes back in case you went too far. Pages are displayed in “first in last out” order.
· Skip page (button with icon). Navigates to the next unread page, but marks the current page as unread and puts it to the end of the queue.
· Bookmark current page (button with icon). Adds the page to the current activity’s bookmarks.
· Active bookmark (button with icon). Adds the page to the current activity’s bookmarks but marks the page as active.
· End activity (button with icon). Moves the activity to the “completed activities” activity, and moves to the parent activity.
· Display bookmarks (menu). User can select a bookmark relating to the current activity.
Figure 2 shows the web page view.
Use cases (briefs)
Main workflow User begins browsing. Users create activities, switch activities and complete activities. In each activity users read pages, mark more pages for reading, and bookmark pages. Users visit bookmarks spontaneously or when prompted due to an update of the page.
Begin browsing Browser displays the list of activities and the user selects one (switch activity). Exception: User creates an activity. Exception: User does not select an activity and browses in the “All activities” activity.
Switch activity User displays a list of recent activities, and selects the desired activity. The screen displays the current page in the new activity. Exception: the activity is not a recent activity. User selects option to display the complete list of activities and selects the activity from there.
Create activity User selects the desired parent activity. User commands browser to create an activity and inputs the activity name. The new activity is created as a sub-activity of the current one. The current activity is set to the new activity. Exception: The name conflicts with an existing sub-activity.
Complete activity User selects option to complete the activity. The current activity changes to the parent activity.
Read pages User commands the browser to read the next unread page. The browser displays the next unread page from the current activity (including unread pages from sub-activities). Exception: there are no more unread pages: user is returned to the activity view. Exception: page does not load: normal page load error is displayed, and the page remains unread. Alternate: user skips page.
Manage activities User switches to the activity view, and is able to reorganise the activities in a tree. User can start browsing an activity by clicking on a link or activity. User can organise pages such as mark pages as read or delete pages. Exception: activity names clash. The user is prompted and activities are merged.
Mark page for reading User sees an interesting link and marks the link as “unread”.
Bookmark pages User commands browser to bookmark the current page, or to bookmark a link. Page is added as a bookmark to the current activity. Alternate: User creates an active bookmark.
Visit bookmark User gets the browser to display the bookmarks for the current activity. User selects a bookmark. Navigation proceeds.
Merge activities User moves all pages from one activity into another. User completes the old activity.
Split activity User creates a new activity and moves pages the appropriate pages into the new activity.
Complete activity The user marks the activity as “complete” which moves the activity to the “completed activities” activity.
Reopen completed activity The user moves the activity from the “completed activities” activity to the “current activities” activity. The user can also just select the completed activity and use is even though it has been filed as completed.
Evaluation
A proper evaluation would involve a user study, and there can be no substitute for prototyping a functional interface and soliciting feedback. However the following questions should be posed of any solution:
1. Is the solution simple to use? The activity-oriented browser is probably more complicated than other submissions, and may even fail the “parent test” – could my parents use this? However my parents also rarely have 20 tabs open at the same time. So this is definitely more a tool for the professional who spends hours each day researching particular topics.
2. Is the solution deliverable? The activity-approach involves one more page implemented as a tree view, and a few extra commands on the toolbar. A small database is needed for pages and activities.
3. Is the solution scalable? Today people deal in hundreds of web sites, in the future it will be even more. Scalability is a feature of the user interface as much as the implementation. This submission is designed to manage hundreds of thousands of pages, and can organise activities as “completed” to reduce clutter. A solution which prettifies a list isn’t going to solve scalability.
4. Is the feature optional? Users should be able to ignore/turn off the feature if they don’t want it. In this case, users can still stick with tabs, and the solution works perfectly well with tabs. In fact, different tabs could be used for different activities.
5. Does the solution support all of the scenarios? (See evaluation scenarios below.) The main scenario which this solution appears to support is investigations involving tens of web pages, or activities spanning several days. However even simple tasks like finding a good restaurant involve a degree of research.
6. How well is screen real-estate used? A concern with left-hand panes is that they use too much screen space. A horizontal toolbar on the other hand does not use much space.
7. Is there conceptual integrity? For example is the interface too much of a radical departure, and is the user experience consistent with other applications? Can other internet tasks such as RSS, NNTP and email work with the feature?
8. Completeness of vision? Has the idea been explored fully into a fully-fledged idea.
Evaluation
scenarios
|
Activity type |
Frequency |
Duration |
Number of pages |
|
Research an in-depth topic, involving lots of sub-investigations. |
Monthly |
Days, weeks or months |
1000+ |
|
Short investigation. Exploratory browsing, like a search tree. |
Weekly |
Half an hour |
20 |
|
Answer a brief question, such as look up the weather, a map, an encyclopaedia entry, a technical problem. |
Daily |
5 minutes |
10 |
|
Shopping, including doing product research, reading reviews, finding the best price, placing an order, tracking the order. Can involve bidding on auction sites. Leave a review about the whole experience |
Weekly |
2 hours |
30 |
|
Holiday planning, including browsing web sites, finding the best price, reading reviews, booking multiple activities. |
Twice a year |
4 hours |
40 |
|
Administration tasks, such as paying bills. |
Monthly |
30 mins |
10 |
|
Context switch between different activities. |
Every 5 minutes |
|
|
|
View current information on a periodic basis, such as news and RSS. |
Daily |
45 mins |
20 |
|
Participate in discussions, alerting you when new posts have been added. |
Daily |
15 mins |
10 |
|
Working in web applications such as email and word processing. |
Daily |
1 hour |
10 |
|
Browse aimlessly for amusement. Maintain a list of promising distractions, and flag those which should be revisited or shared in future. |
Daily |
30 mins |
1000 |
|
Porn. I didn’t really want to mention this one but apparently it happens quite a lot. |
?? |
?? |
?? |
Note that these figures are completely made up! I have no idea where to get actual data on this.
Conclusion
The central theme of this submission is that browsers should support the browsing workflow, rather than merely display pages. The activity-oriented browser is designed to organise hundreds of thousands of pages into different activities.
The activity view might be a little complex for new users, but should be easy to grasp for users who spend a lot of time online, and be particularly valuable for students and researchers who spend a lot of time researching on line. But then it is research (no matter how large or small the problem) which tends to throw up a lot of tabs.
About the Author
My current position is as a researcher in endpoint security and control, working for Sophos Plc in the UK, where I have worked for five years. Part of what we do involves securing the web and working with browsers. Prior to that I have worked on web-based information retrieval. I have past research interests in software visualization and visual programming, and programming languages in general. I have a BA and PhD in computer science from the University of Cambridge UK which I received in 2000.