GraphicalMicrosummaries: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Add graphics, fill out ome more text. still a draft.)
(more edits.)
Line 5: Line 5:
=What's this about?=
=What's this about?=


Traditional bookmarks are completely static, 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 arguably had some usability benefits, by letting the user more quickly identify bookmarks).
This is a proposal for a new Firefox 3 feature.


Firefox 1.5 and 2.0 have made bookmarks dynamic by introducing LiveBookmarks (RSS feeds) and LiveTitles (microsummaries). But even these dynamic modifications are still text based, like traditional bookmarks.
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.


Graphical microsummaries would build upon these improvements by adding -- wait for it -- graphical elements to the bookmark entry. This allows for higher information density than plain text, and improves the abaility of a bookmark entry to convey relevant, dynamic data that the user is interested in. Not to mention is looks cool. Bling bling, baby!
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.


xxx relationship (none) to the full HTML/RTF stuff I've seen mentioned?
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, [https://bugzilla.mozilla.org/show_bug.cgi?id=341347 Bug 341347] proposes allowing rich text (full HTML) microsummaries. Graphical microsummaries could be a stepping stone towards this.


= Types of graphics =
= Types of graphics =


This feature would provide a small number of "standard" formats. (As opposed to, say, a blank sea of pixels that you can draw anything into). The goal is to provide a simple interface for content providers to use. "Just plug in the data, and *bam*!"
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."


(Side note: future work might provide a raw rendering interface to allow the content provider to draw anything, or we maybe some kind of plugin scheme to allow the community to develop their own formats.)
Here's a few examples of the types of graphics that might be available:


(Side side-note: ok, now that I think about an open system would be a big win. *handwaving* Maybe some kind of XML middleware thing that allows converting raw data to nice <canvas> input.)
[[Image:Examples.png|Example of some sparkline-esque graphics found online]]


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


[[Image:Examples.png|Example of some sparkline-esque graphics found online]]
* 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 =
= XML Format =


* similar to existing XML generators
To be determined...
* provide a few standard formats
 
** sparklines
* similar to current microsummary XML generators?
** etc
* data source
* some customization?
** extract from page
** color
** raw data feed
** ...
* display format
* example
** graphic format
** customized options (colors, range, etc)


= Core notes =
= Core notes =


Implementing this type of microsummary display format would probably be done by introducing a new type of <menuitem> binding in [http://landfill.mozilla.org/mxr-test/mozilla1.8.x/source/toolkit/content/widgets/menu.xml#81 menu.xml]. Bookmarks <menuitem>s currently use the #menuitem-iconic binding (note: top-level bookmark toolbar entries are slightly different).
Implementing this type of microsummary display format would probably be done by introducing a new type of <menuitem> binding in [http://landfill.mozilla.org/mxr-test/mozilla1.8.x/source/toolkit/content/widgets/menu.xml#81 menu.xml]. (Bookmark <menuitem>s currently use the #menuitem-iconic binding, and top-level bookmark toolbar entries are slightly different).


I did some experimentation with changing the binding's <content>, with mixed results. On the Mac, the application menu bar entries (ie, Bookmarks menu) won't show extra images or style (native widget issues?), although entries under the toolbar will. Linux apparently works ok, and Windows wasn't tested.
'''ISSUE:''' Feature is dependent on platform support.


'''ISSUE:''' Feature is dependent on platform support. Might only work in toolbar?
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>.
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>.
(Side note: Does Vista's high-DPI mode thingie give us more pixels to play with vertically? 16px or so is rather cramped.)

Revision as of 00:12, 24 October 2006

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>.