Microsummaries: Front-end Implementation
Myk Melez
Front-end Implementation
The initial integration points are the bookmark properties dialog and
the bookmarks toolbar.
Since microsummaries can contain HTML and other unsafe content, they
should be inserted into the UI inside untrusted iframes wherever they
appear.
Bookmark Properties Dialog
The bookmark properties dialog lets the user choose to display a
microsummary for the bookmark. If multiple microsummaries are available,
the dialog lets users choose between them. The dialog retrieves
microsummaries via nsIMicrosummaryService.getMicrosummariesForURI() and
updates the datastore per the user's selection via
nsIMicrosummaryService.setMicrosummary() and
nsIMicrosummaryService.removeMicrosummary().
Bookmarks Toolbar
When a microsummary is set for a bookmarked URI, the bookmarks toolbar
displays the microsummary instead of the page title as the label of the
bookmark. When the microsummary service updates the microsummary, the
bookmarks toolbar updates the label. While the microsummary service is
in the process of updating the microsummary, the bookmarks toolbar
displays some UI indicating that an update is underway (f.e. it replaces
the favicon with a throbber for the duration of the update).
The toolbar displays microsummaries via a template rule that applies
only to bookmarks with microsummaries. The toolbar controller registers
itself with the microsummary service as a microsummary observer in order
to be notified when a microsummary gets updated.
[Is the annotation observer interface sufficient for this task? I.e. is
it sufficient for the toolbar controller to merely register itself as an
annotation observer of the microsummary/content annotation? Probably
not, since the annotation observer doesn't let you observe that an
update to the annotation is underway.]
[The mechanism by which the bookmarks controller identifies and observes
microsummary bookmarks should be extensible (i.e. a generic "metadata
observer") so that future code (both native and extensions) can register
additional bookmark types with metadata whose observation triggers
activity.]
Additional integration points may be defined in the future (f.e.
microsummaries might be displayed as tab labels).
Mike Beltzner
> Front-end Implementation
>
> The initial integration points are the bookmark properties dialog and
> the bookmarks toolbar.
I'm hoping that we'll be able to get some support in the native chrome
for what I've been calling a "notification area" (probably in the status
bar, I'm working up a UI spec to share with everyone by Tuesday) which
will alert the user to the presence of content in the page that can be
handled in rich ways by the browser. Media files, microformats, email
addresses, and microsummaries are examples of things that might
contribute. The experience that I'm hoping to get is something similar
to the RSS experience, where the browser alerts the user to the presence
of the microsummary (although not in the URL bar itself, I think that
might be overkill) so that they know it's there. This should help with
the discoverability of this feature.
> Bookmark Properties Dialog
>
> The bookmark properties dialog lets the user choose to display a
> microsummary for the bookmark. If multiple microsummaries are available,
Cool. I like how your walkthrough shows that the user will be able to
see a preview of how the bookmark will appear. That's slick.
> bookmarks toolbar updates the label. While the microsummary service is
> in the process of updating the microsummary, the bookmarks toolbar
> displays some UI indicating that an update is underway (f.e. it replaces
> the favicon with a throbber for the duration of the update).
Hm. I'm not sure this is necessary unless the user explicitly requests a
refresh (speaking of which, will that be available as a "Reload" action
like on a Live Bookmark?) Unless you think the uSummary refresh will
take a long time?
> Additional integration points may be defined in the future (f.e.
> microsummaries might be displayed as tab labels).
Heh, that's a great idea. I wonder if we should have a global pref that
governs if tabs will show page titles vs. uSummaries. It seems a little
redundant for a user to have the uSummary displayed both in the bookmark
toolbar AND the tab title ... although I guess they could have loaded
the page from a bookmark that wasn't in the bookmark toolbar.
cheers,
mike
--
mike beltzner, user experience lead, mozilla corporation
Myk Melez
> I'm hoping that we'll be able to get some support in the native chrome
> for what I've been calling a "notification area" (probably in the status
> bar, I'm working up a UI spec to share with everyone by Tuesday) which
> will alert the user to the presence of content in the page that can be
> handled in rich ways by the browser.
Sounds like a good idea as this kind of stuff proliferates.
>> bookmarks toolbar updates the label. While the microsummary service is
>> in the process of updating the microsummary, the bookmarks toolbar
>> displays some UI indicating that an update is underway (f.e. it
>> replaces the favicon with a throbber for the duration of the update).
>
> Hm. I'm not sure this is necessary unless the user explicitly requests a
> refresh (speaking of which, will that be available as a "Reload" action
> like on a Live Bookmark?) Unless you think the uSummary refresh will
> take a long time?
In our meeting last week, the Places folks also expressed reservations
about this idea. They thought it would be distracting and annoying, and
we agreed to drop it from the proposal for now.
I can see their point, but I also think there's value in an obvious and
non-instantaneous indication of a microsummary update. Otherwise we
will end up unnerving users whose peripheral vision tells them something
just changed but who can't figure out what it is, especially for minor
changes like "GOOG: 416.38 + 10.22" -> "GOOG: 416.36 + 10.20".
Update indications also serve to reassure users that we are regularly
checking for updates, potentially reducing nervous explicit reloads and
thus reducing overall load on the net. Or perhaps I'm just projecting
my own neuroses onto our audience. :-)
FWIW, I don't think updates will take a long time, especially for
broadband users. In fact, if we eventually decide that we do want to
indicate microsummary updates, we probably shouldn't tie them to load
time, or at least we should define a minimum time-to-indicate to prevent
near-instantaneous loads from having the same "peripheral flicker"
effect that instantaneous changes have.
>> Additional integration points may be defined in the future (f.e.
>> microsummaries might be displayed as tab labels).
>
> Heh, that's a great idea. I wonder if we should have a global pref that
> governs if tabs will show page titles vs. uSummaries. It seems a little
> redundant for a user to have the uSummary displayed both in the bookmark
> toolbar AND the tab title ... although I guess they could have loaded
> the page from a bookmark that wasn't in the bookmark toolbar.
Yeah, they may be somewhat different use cases with different default
prefs to control them. It's still not entirely clear to me when and how
microsummaries on tab labels would be useful, and I suspect there are
other useful places to stick them that we haven't thought of yet.
-myk
Mike Beltzner
> Mike Beltzner wrote:
>
> > I'm hoping that we'll be able to get some support in the native chrome
> > for what I've been calling a "notification area" (probably in the status
> > bar, I'm working up a UI spec to share with everyone by Tuesday) which
> > will alert the user to the presence of content in the page that can be
> > handled in rich ways by the browser.
>
> Sounds like a good idea as this kind of stuff proliferates.
>
> >> bookmarks toolbar updates the label. While the microsummary service is
> >> in the process of updating the microsummary, the bookmarks toolbar
> >> displays some UI indicating that an update is underway (f.e. it
> >> replaces the favicon with a throbber for the duration of the update).
> >
> > Hm. I'm not sure this is necessary unless the user explicitly requests a
> > refresh (speaking of which, will that be available as a "Reload" action
> > like on a Live Bookmark?) Unless you think the uSummary refresh will
> > take a long time?
>
> In our meeting last week, the Places folks also expressed reservations
> about this idea. They thought it would be distracting and annoying, and
> we agreed to drop it from the proposal for now.
>
> I can see their point, but I also think there's value in an obvious and
> non-instantaneous indication of a microsummary update. Otherwise we
> will end up unnerving users whose peripheral vision tells them something
> just changed but who can't figure out what it is, especially for minor
> changes like "GOOG: 416.38 + 10.22" -> "GOOG: 416.36 + 10.20".
I wonder if we might be able to use something like the Basecamp /
Wordpress "colour pulse" to draw attention to the fact that something
has been changed. Both of those applications use JS and CSS to create
a soft flash of background colour to draw attention to the element
that's changed (Basecamp uses a soft yellow, for instance) and then
fades that colour out within a second or so. It might be too much, and
I worry somewhat about how it will work with alternate themes, but if
you're really worried that people won't notice. Hm, also, as I think
about it, that should really only happen if the summary actually
changes, too. Having a flash for a summary that hasn't changed seems
pretty useless.
I'm not running the prototype right now, and the extension seems to be
incompatible with 2.0a1. Is there a new version available somewhere?
> Update indications also serve to reassure users that we are regularly
> checking for updates, potentially reducing nervous explicit reloads and
> thus reducing overall load on the net. Or perhaps I'm just projecting
> my own neuroses onto our audience. :-)
You might just be. I would expect that the microsummary would always
show me the latest information and periodically update itself just
like Live Bookmarks do. I think a bunch of flashing reload icons would
be more distracting to my web experience; I want to know what the
summary is when I look at it, not really before.
> FWIW, I don't think updates will take a long time, especially for
> broadband users. In fact, if we eventually decide that we do want to
> indicate microsummary updates, we probably shouldn't tie them to load
> time, or at least we should define a minimum time-to-indicate to prevent
> near-instantaneous loads from having the same "peripheral flicker"
> effect that instantaneous changes have.
Agreed. Setting them to update at the same frequency as Live Bookmarks
seems like the right thing to do (every 30 minutes?) I don't think
that pref would need to be exposed in the UI, a hidden about:config
field should do unless we hear a lot of screaming from users.
> >> Additional integration points may be defined in the future (f.e.
> >> microsummaries might be displayed as tab labels).
> >
> > Heh, that's a great idea. I wonder if we should have a global pref that
> > governs if tabs will show page titles vs. uSummaries. It seems a little
> > redundant for a user to have the uSummary displayed both in the bookmark
> > toolbar AND the tab title ... although I guess they could have loaded
> > the page from a bookmark that wasn't in the bookmark toolbar.
>
> Yeah, they may be somewhat different use cases with different default
> prefs to control them. It's still not entirely clear to me when and how
> microsummaries on tab labels would be useful, and I suspect there are
> other useful places to stick them that we haven't thought of yet.
Yup. I'm really looking forward to seeing this in A2 builds and
getting the feedback on it.
cheers,
mike
--
[ mike beltzner / user experience lead / mozilla corporation ]
Simon Bünzli
> The initial integration points are the bookmark properties dialog and
> the bookmarks toolbar.
Apparently, Microsummaries are also displayed in the Bookmarks menu, but
not in the Bookmarks sidebar and the Bookmarks manager. This is slightly
confusing (and a pity, since I access my bookmarks only through the
sidebar). Is this intentional or are there more integration points
planned for Firefox 2.0?
Cheers,
Simon