341555 - UI for refreshing a microsummary

Status: RESOLVED FIXED

(Firefox Graveyard :: Microsummaries, defect, P2)

Description

[Myk Melez [:myk] [@mykmelez]]

Users are likely to want to sometimes explicitly update a microsummary, even if the microsummary isn't expired, to ensure they have the most up-to-date summary.

Livemarks includes a "Reload Live Bookmark" item on the context menu for livemark bookmarks which accomplishes this goal.  Microsummary bookmarks should have a similar item on their context menus.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v1: adds "Refresh Live Title" context menu item

This patch adds a "Reload Live Title" item to the context menu for bookmarks with microsummaries.  It works exactly like the "Reload Live Bookmark" item on the context menu for livemarks: you select the item from the menu, and then the microsummary service will silently update the microsummary.

Also, as with livemarks:

* the menu item is hidden on context menus for bookmarks that don't have 
  microsummaries;
* the menu item is present in every bookmark context menu (sidebar, toolbar, 
  menu, manager)

Note that currently the microsummary won't change when users invoke this command if the current microsummary is the most recent one, in which case users won't get any feedback letting them know they successfully invoked the command.

It seems to me that we should somehow indicate to users that we did indeed do what they asked, even if the result is that nothing changed because the microsummary was already up-to-date.  Otherwise they'll wonder whether or not the command worked.

In an earlier conversation in the newsgroup about notifying users when we refresh a microsummary automatically, beltzner said:

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

Perhaps we could also apply this strategy to the case where the user manually refreshes the microsummary, except that when they manually refresh we do a colour pulse even if the microsummary didn't change, so they know we did it, whereas when we automatically refresh a microsummary we only pulse if the microsummary did change.

Comment 2

[Mike Connor [:mconnor]]

Comment on attachment 225926 [details] [diff] [review]
patch v1: adds "Refresh Live Title" context menu item


>+    case "cmd_bm_refreshmicrosummary":
>+      for (i=0; i<length; ++i) {
>+        if (!MICSUMSVC.hasMicrosummary(aSelection.item[i]))
>+          return false;
>+      }
>+      return length > 0;

discussed on IRC with myk, we should offer the context menu option if any of the selected bookmarks have Live Titles 

r+a181=me

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Fix checked in on trunk and 1.8 branch.  Leaving bug open pending Places implementation.

Comment 4

[AKIHIRO Misaki (a.k.a Kuden)]

Attachment: screenshot

I think that this code is necessary. 
menulist#name[droppable="false"] > menupopup {display: none;}

Comment 5

[AKIHIRO Misaki (a.k.a Kuden)]

I'm sorry, my spam comment.. It was mistaken for Bug 337825. 

Comment 6

[Myk Melez [:myk] [@mykmelez]]

This has since been fixed in Places.