GraphicalMicrosummaries: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(more braindump)
(Add graphics, fill out ome more text. still a draft.)
Line 1: Line 1:
=WORK IN PROGRESS=
=UI Mockup=


==why==
[[Image:Msumm.png|Photoshopped UI mockup of graphical microsummaries]]


* limitations of text
=What's this about?=
* looks cool!


===other future MS work===
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).


full HTML/RTF?
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.


== UI Mockup ==
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!


(insert photoshop mockups here)
xxx relationship (none) to the full HTML/RTF stuff I've seen mentioned?


== Graphical types ==
= 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 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*!"
Line 22: Line 21:
(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.)
(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.)


== XML Format ==
Here's a few examples of the types of graphics that might be available:
 
[[Image:Examples.png|Example of some sparkline-esque graphics found online]]
 
= XML Format =
 
* similar to existing XML generators
* similar to existing XML generators
* provide a few standard formats
* provide a few standard formats
Line 32: Line 36:
* example
* example


== 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]. Bookmarks <menuitem>s currently use the #menuitem-iconic binding (note: top-level bookmark toolbar entries are slightly different).

Revision as of 21:33, 23 October 2006

UI Mockup

Photoshopped UI mockup of graphical microsummaries

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

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.

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!

xxx relationship (none) to the full HTML/RTF stuff I've seen mentioned?

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*!"

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

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

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

Example of some sparkline-esque graphics found online

XML Format

  • similar to existing XML generators
  • provide a few standard formats
    • sparklines
    • etc
  • some customization?
    • color
    • ...
  • example

Core notes

Implementing this type of microsummary display format would probably be done by introducing a new type of <menuitem> binding in menu.xml. Bookmarks <menuitem>s currently use the #menuitem-iconic binding (note: 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. Might only work in toolbar?

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