GraphicalMicrosummaries

From MozillaWiki
Revision as of 00:12, 24 October 2006 by Dolske (talk | contribs) (more edits.)
Jump to navigation Jump to search

UI Mockup

Photoshopped UI mockup of graphical microsummaries

What's this about?

This is a proposal for a new Firefox 3 feature.

Traditional bookmarks are completely static; they're just a text label that may not even really describe your interest in the page. The addition of a favicon made things a little less bland (and gave a small usability benefit), but otherwise the basic bookmark has remained the same since the first web browsers.

Firefox 1.5 and 2.0 have made bookmarks dynamic by introducing Live Bookmarks (RSS feeds) and Live Titles (microsummaries). But even these dynamic modifications are still text based, like traditional bookmarks.

Graphical microsummaries would build upon these improvements by adding -- wait for it -- a graphical element to the bookmark entry. This allows for higher information density than plain text, and improves the ability of a bookmark entry to convey the dynamic data desired by the user. Not to mention is looks cool... Bling bling, baby!

On a more grand scale, Bug 341347 proposes allowing rich text (full HTML) microsummaries. Graphical microsummaries could be a stepping stone towards this.

Types of graphics

This feature would make a small number of "standard" formats available to the content provider. (As opposed to, say, a blank image region that would require pixel banging or pre-rendered content). The goal is to allow the provider to simply feed in the raw data values, and select a display format. For example, "show 50%,25%,25% as a pie chart in red, purple, and yellow."

Here's a few examples of the types of graphics that might be available:

Example of some sparkline-esque graphics found online

For discussion:

  • Should we allow more flexibility in the graphic format -- and how much? Limited formats could result in a cleaner user experience, as ugly or inappropriate formats would be excluded. On the other hand, it's an artificial restriction that prevents capable providers from creating innovative formats quickly. Rough potential ideas...
    • Implement a domain-specialized interface that makes improper usage difficult. (say, allow drawing just dots and lines).
    • Allow an arbitrary image to be used (ala favicon). [More of a "graphical bookmark" than a "graphical microsummary."]
    • Allow drawing access via a canvas API or SVG
    • Implement some kind of data-to-graphic plugin scheme (XSLT?) so that new graphical formats can be shared. Maybe the content provider just supplies the raw data, and the user selects/customizes the display format.
  • Is Vista's high-dpi display mode stuff of interest here? We might want to be able to render a graphic in better quality given the ability. (ie, discourage raster-based graphic specifications)

XML Format

To be determined...

  • similar to current microsummary XML generators?
  • data source
    • extract from page
    • raw data feed
  • display format
    • graphic format
    • customized options (colors, range, etc)

Core notes

Implementing this type of microsummary display format would probably be done by introducing a new type of <menuitem> binding in menu.xml. (Bookmark <menuitem>s currently use the #menuitem-iconic binding, and top-level bookmark toolbar entries are slightly different).

ISSUE: Feature is dependent on platform support.

I did some experimentation with changing and expanding the binding's <content>, with mixed results... On the Mac, the application menu bar entries (ie, Bookmarks menu) wouldn't show extra images or style at all (native widget issues?). Entries under the bookmark toolbar would, though. Linux apparently works ok with changed styles (like changing the background color). Windows wasn't tested. Will need some help some people who know these areas to determine how much is possible.

The graphical part would ideally be represented by an <html:canvas> (or maybe even SVG?). I didn't have any luck with a test of that, although it should be possible to have a hidden <canvas> render a data:// URL to display in the XUL's <image>.