Firefox/Projects/About:newtab
Contents
Overview
Drivers: Dan Mills (thunder), Aza Razkin (aza), Edward Lee (Mardak)
Get involved: by hopping onto #labs on irc.mozilla.org or clicking on Discussion and leaving your comments
- Description
- Instead of a blank page, the new tab page should present useful task-centric navigation options based on the user's history.
Goals / Use Cases
- be perceptibly as fast as about:blank to load
- allow user to re-open previously closed tabs
- offer navigation targets that are likely to be of use to the user
- do not break the user's mental "flow" or otherwise interrupt a user task
Non Goals
- act as a content aggregator for "new" material
Download
- Install the latest Firefox 3.1 beta (required)
- Install the latest about:tab extension
History
We've been iterating frequently to find a good balance for the new tab page. Below are an outline of a couple of the major decisions and why we made them.
- No Thumbnails. This is the largest departure from the original mockups and other browsers. After trying a number of different layouts we reached a couple realizations:
- Thumbnails are a high-noise, low-information-density medium. Few people have a strong association between a site and it's zoomed-out view. The association to name and fav-icon is much stronger.
- In small-scale tests, the upper-left corner of a site was much easier to identify a site by than the full site. That's because the upper-left is where the site's logo normally resides.
- Safari's implementation shows a number of the pitfalls. Having looked at a couple folk's screens they often and two or more sites which look almost identical (multiple WordPress logins), sites hidden because of failed logins, and sites indistinguishable because they all approach white.
- The one thing thumbnails give is a visceral feeling. That's lacking in the current design.
- Polite. We've tried a number of ways to make the new tab page polite -- to stay out of your way. In particular, we tried the right side of the screen and the bottom of the screen. Both felt weird, and people remarked on them.
- The most active attempt at being polite was the ill-fated cognitive shield idea. The cognitive shield hid the frequently accessed sites until you moved the mouse. Although the implementation got in the way of the idea (the shield looked clickable, and people got frustrated as it vanished as they tried to use it), it highlighted an interesting point: the ambient news part of the new tab page is actually very useful.
- Grayscale. Originally, we thought that a fully grayscale display (especially of thumbnails) would be beneficial in being polite. The theory seemed to flag in practice: color is a main way of differentiating sites. The current design is mostly grayscale, with favicons in color.
- All of our attempts at adding animation, while sexy, seemed to distract if activation could happen inadvertently.
- Automatic RSS. In almost all versions we've automatically shown RSS feeds from the sites you visit often. It enables a low-cost way of getting ambient-information updates on your sites. This often removes a navigation step of going to a site, finding what's new, and clicking. We originally showed RSS updates in light gray and right justified. Over time, we've made the text darker and left justified it for legibility.
- Search. Search was added only
- Whimsy/Visceral. The only design that had a sense of whimsy or viscerality -- that would cause people to fall in love -- was the cognitive shield animation, which we removed. Adding that whimsy may be as simple as putting in a water-mark logo of Foxkeh or a FF Robot. In the future, we should think about personal usage charts (think simple version of about:me -- did you know you spent 25% of your time on Facebook?, etc) and other forms of whimsy.
- Contextual Actions. We originally tried this as large buttons, but that felt clunky and heavy-weight. In the end, we settled with actionable sentences. That way, it was a bit easier to scan and understand what was going on. Currently the actions are buttons, but it probably makes more sense to make them hyperlinks. The search should queue off the search provider selected in the chrome search-box, or should be settable in page at the location of search. Map currently defaults to Google Maps, but should probably take it's queue from something in the protocol handler?
- In-Page Settings. Instead of forcing people to make changes to the new tab settings in the extensions dialog, we've added a button in context for making the page blank again. Currently, this is a toggle. In a full version, it would bring up an in-page DIV which would have two options. The first would be to have the page be blank or not. The second would be a slider that sets the page-zoom level.
- Undo Close Tab. Most Firefox users don't know that they can undo a tab close. We surface that ability here: if you've just closed a tab, the natural thing to do is open a new one and try to navigate there again. We've oscillated between having that action available in the "You might want to..." section and as a fake infobar. We're still undecided which is better.
- Reordering. From the beginning we had the ability to re-order. Because of this, we don't need a "pin" option. If the user moved something somewhere, that's where they mean it to be.
Unfinished
- The settings icon should not just toggle, but bring up a DIV area with three options. The first is for whether the page should be blank or not. The second is a slider that sets the page-zoom. The third is a slider for determining the max number of frequently viewed sites to show.
- Adding a site is currently incomplete. The flow should be, click add a site, have an auto-suggestion (populated via the awesomebar) box where you type the URL to add, clicking done then adds the new site to page. Escape should cancel out, etc.
- Undo remove. After the user clicks "remove" we need an "undo" functionality a la the one-click undo of Gmail.
- Speed. New tab still loads too slowly. (There are plenty of optimizations opportunities).
Future
- Personas Integration. The new tab page should integrate with personas so that the browser is, in fact, personal on all levels.
- More Contextual Actions.
- Tie in to about:me.
- Contextual Navigation. I'm on X and always go to Y. The new page should make that easy.
Add-on Development
This is an overview of how the add-on was designed and various aspects like performance and security.
Design
About:Tab mainly consists of a new tab xhtml file that imports data modules (sites, feeds, clipboard) to dynamically generate html to display sites and actions. The modules provide cross-page persistent data and caches results for fast access.
- overlay browser window
- browser.js tweaks
- BrowserOpenTab open new tab page
- browser.js URLBarSetURI clear new tab location
- register ambient rss listener
- prefetch sites
- prefetch feeds for first 10 sites
- browser.js tweaks
- new tab text.xhtml
- dynamically build site list
- request a number of sites from the site module (async)
- each site item starts starts from a html template
- populate fields with site data (title, url)
- request feeds for site from feed module and add them (async)
- find search queries for search boxes
- dynamically adjust which sites are hidden based on vertical space
- site list configuration
- jQuery sortable for reordering of listing
- inform site module which site was moved or removed
- (+) add site button with input field that asks sites module to find a site
- record an added site to the sites module
- feed +/- buttons to adjust num feeds and save to site module data
- actions
- check if the most recent closed tab isn't a new tab then show it
- check if the clipboard has anything recent and suggest search
- detect if clipboard matches other patterns and suggest action
- switcher/configuration
- allow switching to other view
- store which page to load in pref
- dynamically build site list
- site module
- handle requests to get a certain number of sites
- callback with slice of cached results if cache is big enough
- async fetch top sites from db: url, title, favicon
- clean up results like trim subtitles, moz-anno, set default #feeds
- handle move/remove/add by adjusting cache structure
- remember which pages are removed and don't refetch them into cache
- support find with navhistory autocomplete
- handle requests to get a certain number of sites
- feed module
- handle requests to get feeds for a page url
- callback with results if in cache
- async fetch feeds by looking up feed then requesting feed
- clean up feeds by trimming, replacing html-like entities
- automatically refresh cache every 20 minutes
- handle requests to get feeds for a page url
- clipboard module
- get clipboard data
- pretend there's nothing if it's old (45 seconds)
Performance
- + caching of sites and feeds
- + prefetching sites and feeds
- + background feed fetching
- + saving an image of the old sites and fading it out with real html
- - dynamic finding of site search boxes
Security
The new tab page runs with chrome privileges so it can access module data and make calls back to them. There's a lot of web content that can get on the page such as site titles, feeds and things in the clipboard. The main thing is to add content as text instead of html to avoid executing remote scripts. Keeping content strings short/trimmed also makes remote difficult.
- site titles
- subtitles are dropped and total length trimmed
- feed title
- html tags like < are replaced with < and trimmed
- action detectors
- registered detectors can do stuff, but right now it's only a local map command
- privacy
- fetching feeds gives away that the person visits the site..
- fetching is done in the background like how feeds
- use moz-anno:favicon to prevent hitting the network
Strings
There are strings scattered throughout, but these can be consolidated in a single .properties file. There's some use of PluralForm to pluralize "feed items" when customizing #feeds. Detectors provide a string for a button, e.g., "Map" so the API probably needs to be adjusted to support localization.
Some strings might need to adjusted to simplify localization such as actions concat: "(search) for ..., or (map) it"
Styling
All the styling is done with an in-page css style, but this should eventually be pushed out to support per-platform styles. (No more mac buttons on windows!)
Testing
So far things have been manually tested, but various interfaces exposed by the modules could easily be unit tested. Pushing more logic out of the new tab page would probably make it easier to test. Then basic testing of the new tab page could be automated to make sure it gets populated and allows interaction with sites/actions.
Potential Firefox Implementation
Instead of having a "smart" new tab xhtml file that builds itself, it could be a dumb, bare-bone page that just loads pre-generated html for sites/feeds and actions. The only other dynamic code run on opening a new tab would be to wire-up callbacks to handle configuration and opening pages plus adjusting how many sites are displayed based on available screen space.
The majority of the page building logic can then be pushed to a module that updates the site html every 20 minutes on feed update as well as updates actions html on close tab, clipboard copy or text select. This background updating will make the new tab page load much faster as it just needs to render html instead of building it.
All these modules (html builder, sites, feeds, clipboard, actions) can be combined into a single new tab module. Each sub-module would cache its data and store it into a top-level cache javascript object. The add-on doesn't support cross-session data storage, but this could be easily done by JSON-ing the top-level cache and saving it into a pref.
There's various one-time behaviors that should run at start-up, and this can be handled by loading the javascript module. This would load the JSON cache from the pref as well as install the feed listener and prefetch sites and feeds.
With most of the logic pushed into the module, unit tests can be written to probe each of the sub-modules' interfaces.
Browser changes are minimal and just need to make the new tab action open the new tab page. There's recent (trunk?) code that checks an array of uris to hide. Potentially we would want to register about:tab to open up the new tab page.
