Unexpected noun behavior in 0.5 and more...

[Edwin Khodabakchian]

I am working on migrating the feedly commands to 0.5. I have some
feedback+suggestions and I am seeing some bizarre behavior

1) feedback regarding API compatibility. Next time you are breaking
the API, I think that it would be nice to not automatically upgrade
the users from 0.2 to 0.5. Not a big deal now because the number of
users are small but this will become increasingly important specially
given that with twitter even a small handful of users can make a lot
of noise.

2) feedback regarding behavior. In 0.5 I see a bizarre behavior where
nouns are invoked as the user starts typing (even before a command is
selected). This is problematic from a performance perspective when
async nouns are defined - ends up generating a lot of unnecessary http
requests and callbacks.

3) when the user selects a command which includes and object and an
alias, the parser seems to select by default the option where the
object encapsulates everything. If the user selects the second options
and continues typing, the parser does not seem to remember the user
choice and reselects the first option in the list.

Thanks

[Jono DiCarlo]

Hi Edwin,
Thanks for your feedback.

> 1) feedback regarding API compatibility. Next time you are breaking
> the API, I think that it would be nice to not automatically upgrade
> the users from 0.2 to 0.5.

You are right to be concerned. We didn't break backwards
compatibility lightly. We tried to get *everything* forseeable that
would break backwards compatibility together and do it all in this one
release, so we don't think we'll ever have to do another one that
breaks it. I blogged more about this issue here:
http://jonoscript.wordpress.com/2009/06/25/ubiquity-0-5-preview-release-at-last-the-international-edition/

> 2) feedback regarding behavior. In 0.5 I see a bizarre behavior where
> nouns are invoked as the user starts typing (even before a command is
> selected).

That's working as designed -- it is trying to analyze the input to see
if it matches any nountypes; if it does it will produce verb
suggestions based on the nouns. This is to help with the case where
the user selects text and brings up ubiquity; the case where the user
selects text and uses the context menu; cases where no verbs match the
input; and for the benefit of languages that have their nouns before
their verbs in normal sentence order.

> This is problematic from a performance perspective when
> async nouns are defined - ends up generating a lot of unnecessary http
> requests and callbacks.

About an hour ago, I pushed a new version of Ubiquity (0.5pre2) that
includes a performance fix Brandon did in
https://ubiquity.mozilla.com/hg/ubiquity-firefox/rev/582e0e7ca551 . I
haven't publicized it yet, but if you re-download
http://ubiquity.mozilla.com/xpi/ubiquity-latest-beta.xpi now, you
should get 0.5pre2.

You are right that the change in algorithm does do more calls than the
old one used to, but it has a lot of other advantages, and with the
last fix the performance hit has been minimized.

> 3) when the user selects a command which includes and object and an
> alias, the parser seems to select by default the option where the
> object encapsulates everything. If the user selects the second options
> and continues typing, the parser does not seem to remember the user
> choice and reselects the first option in the list.

I'm not sure what you mean by "a command which includes an object and
an alias". Can you please give an example? (What you input, what
gets suggested, what you think should be suggested instead.)

Thanks,
--Jono, Mozilla Labs

[Edwin Khodabakchian]

Hi Jono,

Thanks for your responsiveness.

Regarding nouns, if this is done by design and is necessary, then
please provide us with a configuration knob on the noun to allow some
nouns not to participate into this and only be activated when the
command has been selected: all our nouns are async and even with the
latest xpi, there is a noun invocation on every character entry - I do
not see how you could otherwise make such a pattern scale.

Regarding selection we have a save-for-later command with an alias
which can include a set of tags. If I type:
save-for-later test as qa, tag2
the parser will select the option where the object is test as qa,
tag2. The second option is object:= test, alias := qa, tag2 If I
select that and continue typing to add more tags, it will go back to
automatically selecting the first option.

-Edwin

On Jun 25, 4:31 pm, Jono DiCarlo <jdica...@mozilla.com> wrote:
> Hi Edwin,
> Thanks for your feedback.
>
> > 1) feedback regarding API compatibility. Next time you are breaking
> > the API, I think that it would be nice to not automatically upgrade
> > the users from 0.2 to 0.5.
>
> You are right to be concerned.  We didn't break backwards
> compatibility lightly.  We tried to get *everything* forseeable that
> would break backwards compatibility together and do it all in this one
> release, so we don't think we'll ever have to do another one that

> breaks it.  I blogged more about this issue here:http://jonoscript.wordpress.com/2009/06/25/ubiquity-0-5-preview-relea...

>
> > 2) feedback regarding behavior. In 0.5 I see a bizarre behavior where
> > nouns are invoked as the user starts typing (even before a command is
> > selected).
>
> That's working as designed -- it is trying to analyze the input to see
> if it matches any nountypes; if it does it will produce verb
> suggestions based on the nouns.  This is to help with the case where
> the user selects text and brings up ubiquity; the case where the user
> selects text and uses the context menu; cases where no verbs match the
> input; and for the benefit of languages that have their nouns before
> their verbs in normal sentence order.
>
> > This is problematic from a performance perspective when
> > async nouns are defined - ends up generating a lot of unnecessary http
> > requests and callbacks.
>
> About an hour ago, I pushed a new version of Ubiquity (0.5pre2) that

> includes a performance fix Brandon did inhttps://ubiquity.mozilla.com/hg/ubiquity-firefox/rev/582e0e7ca551.  I
> haven't publicized it yet, but if you re-downloadhttp://ubiquity.mozilla.com/xpi/ubiquity-latest-beta.xpi now, you

[Jono DiCarlo]

Hi Edwin,
Your last email set off a flurry of design discussion here in Mountain
View. I think your point about async noun calls has hit on a serious
problem.
We came up with several possible ways to combat this, but in general I
think that a better solution is to solve the underlying problem of how
often nouns are being queried, rather than to give opt-outs to
individual nouns. Since this is of interest mainly to people working
on core ubiquity development, I'm going to start a thread on the
ubiquity-core mailing list (ubiqui...@googlegroups.com) to discuss
possible strategies for making orders-of-magnitude cuts in the number
of network calls being sent out. Of course, anyone who wants is
welcome to come over to that list to participate in the discussion.
It's just going to get very technical very fast since we'll have to go
deep into the parser algorithms to figure this out.
--Jono

On Jun 25, 4:54 pm, Edwin Khodabakchian

[Edwin Khodabakchian]

Great. I am going to finish the 0.5 feedly migration today. Please let
me know if I can be of any help.

I have one more P1 request: I think that once the user selects and
tabs on one command, it would be great if ubiquity could "focus" on
that command. By focus I mean do not suggest things that are not
centered around that command.

For example we have a feedly-tweet (aka tweet command). The user
starts typing t, w, and then selects that command from the list of
suggestion, then the other tw commands and any other commands
(delicious feedly-twitter...) should be moved out of the equation. I
think that this will have both a usability benefit for the user (no
getting confused by other commands) and more importantly performance
benefits (the 0.5 feels slower than the older 0.2 and the UI seems to
flicker a lot more).

I think that there is a bug related to the preview point: I am not
able to use the feedly tweet command but I am able to use its other
name feedly-tweet. If I select tweet and start typing a message, the
screen goes blank.

[Edwin Khodabakchian]

I did not want to sound too negative: I really like the notion of a
semantic parser - I think that it will help developer design commands,
rationalize the interface and simplify translation so kudos for that!

[Jono DiCarlo]

Hi Edwin,
No, you didn't sound too negative. You brought an important problem
to our attention.

If you want to follow our progress on fixing this issue, see
https://ubiquity.mozilla.com/trac/ticket/799, https://ubiquity.mozilla.com/trac/ticket/797,
and https://ubiquity.mozilla.com/trac/ticket/800 .

Our solution involves treating nountypes that do external calls
differently from nountypes that do not do external calls -- so in a
way, we're implementing the feature you asked for when you said
nountypes should be able to opt out of certain queries. From now on,
nountypes should have an attribute called noExternalCalls if they do
not require any external calls. A full explanation will be added to
the developer tutorial / API documentation real soon.

--Jono

On Jun 25, 6:00 pm, Edwin Khodabakchian

[Jono DiCarlo]

> I have one more P1 request: I think that once the user selects and
> tabs on one command, it would be great if ubiquity could "focus" on
> that command. By focus I mean do not suggest things that are not
> centered around that command.

Yes!!! That's perfect!
I am now slapping my forehead that I didn't think of this before,
because that is absolutely the right thing to do for the user. On a
tab keystroke, just drop all other verbs out of the suggestion list.
Like, duhhhhh. The command the user was on when they hit tab is
obviously the one they want.

It might be a little tricky to implement, since right now our parser
is basically stateless, i.e. after each keystroke it looks at its
input afresh and generates suggestions anew. If tab drops out
unrelated commands, that means that the parser has to keep track of
your input history, because it's not just the present input that the
parser has to look at when generating suggestions, but whether or not
tab was ever hit on the way to that present input. This also raises
the question of how to get back out of the focus and back to the main
suggestion list if I hit tab by mistake. (Other than hitting escape
and starting again from the beginning.)

--Jono

[Jono DiCarlo]

I added a ticket for the modified tab behavior:
https://ubiquity.mozilla.com/trac/ticket/801
I put it in the milestone for version 0.6, since it's too late to make
a big U.I. change like this for 0.5.
--Jono

["mitcho (Michael 芳貴 Erlewine)"]

+1. I've been thinking about this for a while as well but, as Jono
said, our stateless parser doesn't make it easy at the moment.

See also some original thoughts on locking in arguments/roles I had
way back when with regard to the Japanese parser:

http://mitcho.com/blog/projects/ubiquity-in-firefox-japanese/

--
mitcho (Michael 芳貴 Erlewine)
mit...@mitcho.com
http://mitcho.com/
linguist, coder, teacher