New workflow for subscribing to command feeds
1 view
Skip to first unread message
Atul Varma
Aug 12, 2008, 8:36:33 PM8/12/08
to ubiquity...@googlegroups.com
Hi everyone,
Today we've decided to redesign the workflow for subscribing to command feeds. There were a few problems with bookmarking a feed and tagging it with "ubiquity": one issue was that tagging bookmarks is actually something that a lot of users don't know how to do, and which Firefox doesn't provide the best user interface for. Another is that we'd like to be able to give the user some information about the security implications of subscribing to a command feed, and some information about how much they can trust the code, before they commit to allowing chrome-privileged code onto their computer.
Additionally, one of the problems with bookmarking raw JavaScript files in particular was that it wasn't at all friendly to non-technical end-users, and it also didn't provide any opportunities for the script author to embed or link to rich information about the code such as HTML documentation, screencasts, unit tests, and the like. To resolve this, I added functionality to Ubiquity last week [1] that allows HTML pages to include <LINK REL="commands"> tags in their <HEAD> element to specify an associated script file. Bookmarking such a page is essentially equivalent to bookmarking the JavaScript file that they point at.
That said, we still had to solve the other problems with bookmarking. So our new idea for the workflow is this: firstly, it will no longer be possible for raw JavaScript files to be subscribed to; they must be "pointed to" by an HTML page via a <LINK> tag in an effort to be user-friendly and encourage good documentation. To subscribe to a command feed, a user simply navigates to the feed's HTML page; once there, Ubiquity will automatically detect the appropriate <LINK> tags and display a notification informing the user that there are commands available on the page, like so:
http://www.toolness.com/images/20080812172012.jpg
If the user clicks the "Subscribe..." button and the command feed is untrusted (which is the default for now), they are taken to a warning page, whose contents and layout will look something like this, courtesy of Jono:
http://hg.toolness.com/ubiquity-firefox/raw-file/244ece84b672/ubiquity/chrome/content/confirm-add-command.html
If the user then clicks the "I know what I'm doing. Subscribe to it!" button, the feed is added to the list of subscribed feeds, which can be viewed (and modified) via the about:ubiquity page (which is accessible from a number of places, including ubiquity's built-in "help" command).
Note that this workflow pertains only to commands that users now have to bookmark: it has no relevance to the built-in commands that come with Ubiquity.
For reference, an example of a sample command feed that uses a <LINK> tag can be found here:
http://hg.toolness.com/ubiquity-firefox/raw-file/7435416f211a/examples/sample-cmd.html
As of the current revision, we don't have this fully working yet; the notification pane displays, but nothing else really does, and the bookmark-tagging method we're all used to is still the way to go. But it'll change soon and I just wanted to let everyone know so that they can start updating their third-party commands to the newest (and hopefully better) way of doing things.
As usual, any feedback or questions about this change are welcome.
- Atul
[1] http://hg.toolness.com/ubiquity-firefox/rev/d319fabdb4ed
Today we've decided to redesign the workflow for subscribing to command feeds. There were a few problems with bookmarking a feed and tagging it with "ubiquity": one issue was that tagging bookmarks is actually something that a lot of users don't know how to do, and which Firefox doesn't provide the best user interface for. Another is that we'd like to be able to give the user some information about the security implications of subscribing to a command feed, and some information about how much they can trust the code, before they commit to allowing chrome-privileged code onto their computer.
Additionally, one of the problems with bookmarking raw JavaScript files in particular was that it wasn't at all friendly to non-technical end-users, and it also didn't provide any opportunities for the script author to embed or link to rich information about the code such as HTML documentation, screencasts, unit tests, and the like. To resolve this, I added functionality to Ubiquity last week [1] that allows HTML pages to include <LINK REL="commands"> tags in their <HEAD> element to specify an associated script file. Bookmarking such a page is essentially equivalent to bookmarking the JavaScript file that they point at.
That said, we still had to solve the other problems with bookmarking. So our new idea for the workflow is this: firstly, it will no longer be possible for raw JavaScript files to be subscribed to; they must be "pointed to" by an HTML page via a <LINK> tag in an effort to be user-friendly and encourage good documentation. To subscribe to a command feed, a user simply navigates to the feed's HTML page; once there, Ubiquity will automatically detect the appropriate <LINK> tags and display a notification informing the user that there are commands available on the page, like so:
http://www.toolness.com/images/20080812172012.jpg
If the user clicks the "Subscribe..." button and the command feed is untrusted (which is the default for now), they are taken to a warning page, whose contents and layout will look something like this, courtesy of Jono:
http://hg.toolness.com/ubiquity-firefox/raw-file/244ece84b672/ubiquity/chrome/content/confirm-add-command.html
If the user then clicks the "I know what I'm doing. Subscribe to it!" button, the feed is added to the list of subscribed feeds, which can be viewed (and modified) via the about:ubiquity page (which is accessible from a number of places, including ubiquity's built-in "help" command).
Note that this workflow pertains only to commands that users now have to bookmark: it has no relevance to the built-in commands that come with Ubiquity.
For reference, an example of a sample command feed that uses a <LINK> tag can be found here:
http://hg.toolness.com/ubiquity-firefox/raw-file/7435416f211a/examples/sample-cmd.html
As of the current revision, we don't have this fully working yet; the notification pane displays, but nothing else really does, and the bookmark-tagging method we're all used to is still the way to go. But it'll change soon and I just wanted to let everyone know so that they can start updating their third-party commands to the newest (and hopefully better) way of doing things.
As usual, any feedback or questions about this change are welcome.
- Atul
[1] http://hg.toolness.com/ubiquity-firefox/rev/d319fabdb4ed
Blair McBride
Aug 12, 2008, 10:21:17 PM8/12/08
to ubiquity...@googlegroups.com
Have been waiting for this post since I saw the relevant code commit :P
Anyway...
Anyway...
This reminds me a lot of how Feeds work in Firefox. Which, IMO, work great.
One noticeable difference (and a problem, I think) is that currently
there's no way for a page to advertise more than one command. Feeds in
Firefox handle this by providing a menu if there are multiple feeds,
which I think would work great for Ubiquity too.
This would also necessitate a "name" property for the <link/> tag.
Also, if the user accidentally dismisses the message telling them about
a command, there's no way for the user to get it back without reloading
the page. The way this is handled by Feeds is to always display an icon
in the location bar - very unobtrusive, but works well. Its not exactly
the same, as there's no message intruding into the content space. But
feeds are extremely common, whilst Commands aren't (yet!). So that
message will be the main point of discoverability for quite awhile.
Another issue is for people who visit a lot of pages that offer
Commands. That message intruding into the content space is going to get
*very* annoying for these people. The "remember password" message solves
this by adding a "Never for this site" button. Unfortunately, using this
would completely disable adding commands for that page, whereas it
should only be the huge alert message that should be disabled. An icon
in the location bar would solve this issue as well as the issue I
described in the previous paragraph.
Regarding that abomination of an eye-sore that is the warning page now:
I think using the same style as the phishing warning would work well. It
needs to hit home that this could potentially do really bad things like
delete all your porn. And the phishing warning strikes fear into the
common people, without permanently damaging their retinas like the
current page does.
(This was discussed in the IRC channel earlier, but thought I'd put out
the idea into this discussion as well.)
- Blair
Jono
Aug 13, 2008, 12:59:54 AM8/13/08
to ubiquity...@googlegroups.com
I have just committed a fix which styles the warning page to look like the browser's built-in phishing-warning page. (This turned out to be really easy to do -- all I had to do was to link to the CSS file for the phishing-warning page, already included in chrome://content). So, the blinking is gone and it will no longer make your eyeballs bleed.
--Jono
--Jono
Blair McBride
Aug 13, 2008, 2:20:07 AM8/13/08
to ubiquity...@googlegroups.com
Looks great :)
- Blair
Aza
Aug 13, 2008, 11:56:24 AM8/13/08
to ubiquity...@googlegroups.com
Great work, guys!
Alex Faaborg posted some thoughts for redesigning FF messages:
http://blog.mozilla.com/faaborg/2007/03/06/would-you-like-to-redesign-notification-in-firefox-yes-not-now-never/
The long term solution to our messaging woes are, I think, there. In particular the physical connection between the URL/chrome location of the Ubiquity-commands-available icon solves many of the affordance problems.
These are some screens for what the FF team is thinking about for "site identity"
-- aza | ɐzɐ --
Alex Faaborg posted some thoughts for redesigning FF messages:
http://blog.mozilla.com/faaborg/2007/03/06/would-you-like-to-redesign-notification-in-firefox-yes-not-now-never/
The long term solution to our messaging woes are, I think, there. In particular the physical connection between the URL/chrome location of the Ubiquity-commands-available icon solves many of the affordance problems.
These are some screens for what the FF team is thinking about for "site identity"
-- aza | ɐzɐ --
Aza
Aug 13, 2008, 11:59:03 AM8/13/08
to ubiquity...@googlegroups.com
PS., I love Ubiquity.
I had the url to an image, but not the image itself. Thus:
CmdUtils.CreateCommand({
name: "url-to-image",
takes: {"image url": noun_arb_text},
execute: function( url ) {
CmdUtils.setTextSelection( "<img src='%s'/>".replace(/%s/, url) );
}
})
-- aza | ɐzɐ --
I had the url to an image, but not the image itself. Thus:
CmdUtils.CreateCommand({
name: "url-to-image",
takes: {"image url": noun_arb_text},
execute: function( url ) {
CmdUtils.setTextSelection( "<img src='%s'/>".replace(/%s/, url) );
}
})
-- aza | ɐzɐ --
Aza
Aug 13, 2008, 11:59:38 AM8/13/08
to ubiquity...@googlegroups.com
PS., I love Ubiquity.
I had the url to an image, but not the image itself. Thus:
I had the url to an image, but not the image itself. Thus:
CmdUtils.CreateCommand({
name: "url-to-image",
takes: {"image url": noun_arb_text},
execute: function( url ) {
CmdUtils.setTextSelection( "<img src='%s'/>".replace(/%s/, url) );
}
})
-- aza | ɐzɐ --
On Wed, Aug 13, 2008 at 11:56 AM, Aza <a...@mozilla.com> wrote:
Aza
Aug 13, 2008, 11:59:43 AM8/13/08
to ubiquity...@googlegroups.com
PS., I love Ubiquity.
I had the url to an image, but not the image itself. Thus:
CmdUtils.CreateCommand({
name: "url-to-image",
takes: {"image url": noun_arb_text},
execute: function( url ) {
CmdUtils.setTextSelection( "<img src='%s'/>".replace(/%s/, url) );
}
})
I had the url to an image, but not the image itself. Thus:
CmdUtils.CreateCommand({
name: "url-to-image",
takes: {"image url": noun_arb_text},
execute: function( url ) {
CmdUtils.setTextSelection( "<img src='%s'/>".replace(/%s/, url) );
}
})
-- aza | ɐzɐ --
On Wed, Aug 13, 2008 at 11:56 AM, Aza <a...@mozilla.com> wrote:
Aza
Aug 13, 2008, 11:59:03 AM8/13/08
to ubiquity...@googlegroups.com
PS., I love Ubiquity.
I had the url to an image, but not the image itself. Thus:
CmdUtils.CreateCommand({
name: "url-to-image",
takes: {"image url": noun_arb_text},
execute: function( url ) {
CmdUtils.setTextSelection( "<img src='%s'/>".replace(/%s/, url) );
}
})
I had the url to an image, but not the image itself. Thus:
CmdUtils.CreateCommand({
name: "url-to-image",
takes: {"image url": noun_arb_text},
execute: function( url ) {
CmdUtils.setTextSelection( "<img src='%s'/>".replace(/%s/, url) );
}
})
-- aza | ɐzɐ --
On Wed, Aug 13, 2008 at 11:56 AM, Aza <a...@mozilla.com> wrote:
Abi
Aug 13, 2008, 12:36:48 PM8/13/08
to ubiquity-firefox
Haha, Aza, you love Ubiquity way too much...
Anyways, I like the idea of having a icon in the location bar similar
to the ones for feeds and bookmarks (I guess subscribing to Ubiquity
commands could be classified as a Level 1 notification) as Blair
proposed.
One of the problems with having a notification is that it still forces
the user to take some action. In the case of password manager, this
makes sense because the notification is only displayed after you enter
your password. But in this case, it is likely that the user would want
to read through the page, understand what the command does and then,
subscribe to the command. Having this as an icon would solve this and
be very unobtrusive at the same time (and add the ability to display
and subscribe to multiple commands from the same page).
On Aug 13, 11:59 pm, Aza <a...@mozilla.com> wrote:
> PS., I love Ubiquity.
>
> I had the url to an image, but not the image itself. Thus:
>
> CmdUtils.CreateCommand({
> name: "url-to-image",
> takes: {"image url": noun_arb_text},
> execute: function( url ) {
> CmdUtils.setTextSelection( "<img src='%s'/>".replace(/%s/, url) );
> }
>
> })
>
> -- aza | ɐzɐ --
>
> On Wed, Aug 13, 2008 at 11:56 AM, Aza <a...@mozilla.com> wrote:
> > Great work, guys!
>
> > Alex Faaborg posted some thoughts for redesigning FF messages:
>
> >http://blog.mozilla.com/faaborg/2007/03/06/would-you-like-to-redesign...
> >>http://hg.toolness.com/ubiquity-firefox/raw-file/244ece84b672/ubiquit...
Anyways, I like the idea of having a icon in the location bar similar
to the ones for feeds and bookmarks (I guess subscribing to Ubiquity
commands could be classified as a Level 1 notification) as Blair
proposed.
One of the problems with having a notification is that it still forces
the user to take some action. In the case of password manager, this
makes sense because the notification is only displayed after you enter
your password. But in this case, it is likely that the user would want
to read through the page, understand what the command does and then,
subscribe to the command. Having this as an icon would solve this and
be very unobtrusive at the same time (and add the ability to display
and subscribe to multiple commands from the same page).
On Aug 13, 11:59 pm, Aza <a...@mozilla.com> wrote:
> PS., I love Ubiquity.
>
> I had the url to an image, but not the image itself. Thus:
>
> CmdUtils.CreateCommand({
> name: "url-to-image",
> takes: {"image url": noun_arb_text},
> execute: function( url ) {
> CmdUtils.setTextSelection( "<img src='%s'/>".replace(/%s/, url) );
> }
>
> })
>
> -- aza | ɐzɐ --
>
> On Wed, Aug 13, 2008 at 11:56 AM, Aza <a...@mozilla.com> wrote:
> > Great work, guys!
>
> > Alex Faaborg posted some thoughts for redesigning FF messages:
>
>
> > The long term solution to our messaging woes are, I think, there. In
> > particular the physical connection between the URL/chrome location of the
> > Ubiquity-commands-available icon solves many of the affordance problems.
>
> > These are some screens for what the FF team is thinking about for "site
> > identity"
>
> > -- aza | ɐzɐ --
> > The long term solution to our messaging woes are, I think, there. In
> > particular the physical connection between the URL/chrome location of the
> > Ubiquity-commands-available icon solves many of the affordance problems.
>
> > These are some screens for what the FF team is thinking about for "site
> > identity"
>
>
> >> > If the user then clicks the "I know what I'm doing. Subscribe to it!"
> >> > button, the feed is added to the list of subscribed feeds, which can be
> >> > viewed (and modified) via the about:ubiquity page (which is accessible
> >> > from a number of places, including ubiquity's built-in "help" command).
>
> >> > Note that this workflow pertains only to commands that users now have to
> >> > bookmark: it has no relevance to the built-in commands that come with
> >> > Ubiquity.
>
> >> > For reference, an example of a sample command feed that uses a <LINK>
> >> > tag can be found here:
>
> >>http://hg.toolness.com/ubiquity-firefox/raw-file/7435416f211a/example...
> >> > If the user then clicks the "I know what I'm doing. Subscribe to it!"
> >> > button, the feed is added to the list of subscribed feeds, which can be
> >> > viewed (and modified) via the about:ubiquity page (which is accessible
> >> > from a number of places, including ubiquity's built-in "help" command).
>
> >> > Note that this workflow pertains only to commands that users now have to
> >> > bookmark: it has no relevance to the built-in commands that come with
> >> > Ubiquity.
>
> >> > For reference, an example of a sample command feed that uses a <LINK>
> >> > tag can be found here:
>
Blair McBride
Aug 13, 2008, 10:22:09 PM8/13/08
to ubiquity...@googlegroups.com
Yes, I love Alex Faaborg's mockups. But its a pity its only a mockup
at this stage. That's one of the areas that I think a lot of
extensions make a huge mess out of.
at this stage. That's one of the areas that I think a lot of
extensions make a huge mess out of.
That site identity mockup is new to me - is there an associated blog
post for that image, or is it a hush-hush confidential internal
document?
- Blair
On Thu, Aug 14, 2008 at 3:56 AM, Aza <a...@mozilla.com> wrote:
> Great work, guys!
>
> Alex Faaborg posted some thoughts for redesigning FF messages:
> http://blog.mozilla.com/faaborg/2007/03/06/would-you-like-to-redesign-notification-in-firefox-yes-not-now-never/
>
> The long term solution to our messaging woes are, I think, there. In
> particular the physical connection between the URL/chrome location of the
> Ubiquity-commands-available icon solves many of the affordance problems.
>
> These are some screens for what the FF team is thinking about for "site
> identity"
>
>
>
Aza
Aug 14, 2008, 1:35:02 AM8/14/08
to ubiquity...@googlegroups.com
Almost nothing here is hush-hush. I do not know if that is from a blog post, but it is from the larger-design that didn't make it into the Larry upgrade to Firefox (i.e., the thing that shows when you click the icon to the left of the URL bar).
-- aza | ɐzɐ --
-- aza | ɐzɐ --
Atul Varma
Aug 14, 2008, 12:38:15 PM8/14/08
to ubiquity...@googlegroups.com
Good points, Blair, especially regarding the weaknesses of the new workflow. My one concern, though, is the use of an icon as the primary UI element; Aza's post on this explains things well:
http://humanized.com/weblog/2007/06/25/the_end_of_an_icon/
As an example in regards to the RSS icon: I'd have difficulty explaining this to my mom over the phone. "Just click on the blue icon with the semicircle thingys coming out of it to the right of your address bar..." :)
That can be resolved to some extent by having a really easy-to-explain and easy-to-recognize icon, though, like the star for favorites. Any ideas on what a good icon would look like? We've got an icon for Ubiquity in the works, but it's not really easy to verbalize at all.
I'm not sure how I feel about the idea of multiple command feeds per page, because of the complications in usability it presents. There's some nice advantages in having a one-to-one correspondence between command feeds and pages. For instance, if we go the icon route, I really like the way that the favorites star is hollow or filled to indicate whether the page is bookmarked or not; it allows the star to function not only as an interface element, but as useful information, too. But this wouldn't be possible if a single page had multiple feeds.
Additionally, there's a bit of confusion in regards to what a "command feed" is for: the example I gave contains only one command, but the idea is that such a feed would be the delivery mechanism for small suites of functionality. In Enso terms, Enso Launcher would be one feed, while Enso Words would be another. While it's certainly technically possible to make things more granular--e.g., provide users with the option to subscribe to the "go" command but not the "open" command--I'm not sure if the customizability is worth the increase in decision-making for the end-user. It feels a bit like the preferences dilemma.
Lastly, I think that as a new technology, it's nice for command feeds to have maximum visibility; certainly the notification pane that appears now would be annoying if command feeds were as ubiquitous (heh heh) as RSS feeds, but that's clearly not the case at the moment, and as such it may be useful to guide the user as much as possible. So it might make sense to keep the current mechanism for 0.1 and implement a more scalable one in a future release.
Thoughts?
- Atul
http://humanized.com/weblog/2007/06/25/the_end_of_an_icon/
As an example in regards to the RSS icon: I'd have difficulty explaining this to my mom over the phone. "Just click on the blue icon with the semicircle thingys coming out of it to the right of your address bar..." :)
That can be resolved to some extent by having a really easy-to-explain and easy-to-recognize icon, though, like the star for favorites. Any ideas on what a good icon would look like? We've got an icon for Ubiquity in the works, but it's not really easy to verbalize at all.
I'm not sure how I feel about the idea of multiple command feeds per page, because of the complications in usability it presents. There's some nice advantages in having a one-to-one correspondence between command feeds and pages. For instance, if we go the icon route, I really like the way that the favorites star is hollow or filled to indicate whether the page is bookmarked or not; it allows the star to function not only as an interface element, but as useful information, too. But this wouldn't be possible if a single page had multiple feeds.
Additionally, there's a bit of confusion in regards to what a "command feed" is for: the example I gave contains only one command, but the idea is that such a feed would be the delivery mechanism for small suites of functionality. In Enso terms, Enso Launcher would be one feed, while Enso Words would be another. While it's certainly technically possible to make things more granular--e.g., provide users with the option to subscribe to the "go" command but not the "open" command--I'm not sure if the customizability is worth the increase in decision-making for the end-user. It feels a bit like the preferences dilemma.
Lastly, I think that as a new technology, it's nice for command feeds to have maximum visibility; certainly the notification pane that appears now would be annoying if command feeds were as ubiquitous (heh heh) as RSS feeds, but that's clearly not the case at the moment, and as such it may be useful to guide the user as much as possible. So it might make sense to keep the current mechanism for 0.1 and implement a more scalable one in a future release.
Thoughts?
- Atul
Blair McBride
Aug 14, 2008, 5:45:54 PM8/14/08
to ubiquity...@googlegroups.com
> My one concern, though, is the use of an icon as the primary UI element
I know - I dislike it too. But I'm not suggesting we do-away with the
current method - just complement it.
> We've got an icon for Ubiquity in the works, but it's not really easy to verbalize at all.
How ironic!
How about a speech bubble as an icon? Its a well-known
internationally-recognized symbol, simple, and goes with the natural
language part of Ubiquity.
> There's some nice
> advantages in having a one-to-one correspondence between command feeds and
> pages.
Good point. The one-to-one relationship really works well for Ubiquity.
- Blair
Jono
Aug 16, 2008, 10:35:44 PM8/16/08
to ubiquity...@googlegroups.com
How about a speech bubble as an icon? Its a well-known
internationally-recognized symbol, simple, and goes with the natural
language part of Ubiquity.
The only problem with that is that people will probably think it means something to do with "chat" or instant messaging.
I don't have any better ideas right now, though.
--Jono
Atul Varma
Aug 18, 2008, 10:22:34 AM8/18/08
to ubiquity...@googlegroups.com
We could also use a big stylized letter "U", for "Ubiquify this!". Not sure how good it'd be for i18n, but at least it's easy to verbalize.
- Atul
- Atul
a...@mozilla.com
Aug 18, 2008, 12:01:30 PM8/18/08
to ubiquity...@googlegroups.com
it doesn't really matter what icon we use as long as we have an
animation that connects Ubiquity messages with the location of its
icon. That "physical" connection should be enough to teach users where
those types of messages will be hiding.
animation that connects Ubiquity messages with the location of its
icon. That "physical" connection should be enough to teach users where
those types of messages will be hiding.
--
-- aza | ɐzɐ --
Reply all
Reply to author
Forward
0 new messages