Ponderings for magic words

[Guy Fraser]

I already pondered about making magic words extensible here:
http://groups.google.com/group/ubiquity-core/browse_thread/thread/c2ce330eb1ef1452

Thought the idea deserved it's own thread. :)

magic.add({
name: '...',
aliases: ['...','..'],
homepage: '...', // optional
icon: '...', // optional - url to icon for this magic
license: '...', // optional - comma separated list of licenses
summary: '...', // optional - a short summary of what this magic does
description: '...', // optional - longer description of this magic
suggest: function() { // mandatory
}
});

The suggest() method (for want of a better name) would do the magic. I
envisage that there could be different types of magic based on the
nature of the magic word.

For example "here" could relate to the current text area, the current
document, my geolocation, etc. I'm really not sure how to deal with
this as I have no idea how the current magic words function.

I'd imagine that the suggest method would be passed an object that
describes the current command somehow so that it could then work out
what verbs and nouns are in use and either return a value, a list of
suggestions or somehow manipulate the command object.

Maybe people could list suggestions for magic words in to this topic
or a page somewhere so we can see what sort of features would be
needed.

[Guy Fraser]

Addendum: In cases where magics display a list of suggestions and the
user chooses a specific suggestion, maybe display the icon for the
associated verb or noun next to the magic word and have it's tooltip
show a summary of what the magic word currently represents?

[Guy Fraser]

Must ... stop ... having ... ideas ... after ... original ... post!!

Been pondering about the magic words a bit more - the suggest method
would be scoped to a Command object (or have it passed in as argument)
describing current command, eg. tokenised.

I imagine it will be possible for a command to have multiple
tokenisations while it's being edited so you'd need an array of
possible tokenisations? Or maybe the parser would just call the magic
multiple times, once for each tokenisaiton?

Each token in the command would state whether it's a verb, noun, magic
or "unknown" (eg. a non-validating string where a noun should be or
something that could be a noun or a magic but not yet sure).

You'd need to know which token applies to the current magic word and
have simple methods for traversing the tokens, eg. find me the
previous verb or tell me what sort of noun it's expecting, etc.

Each token would need properties like:

.text - the text shown in the command line
.value - the current value of that text as an "input object", or null
if it should be ignored
.tooltip - a tooltip to show when the mouse hovers over the text
.type - noun, verb, magic, unknown
.suggestions - list of suggestions for this token, if applicable

Aside: I'm thinking that verbs would even have suggestions - as you
start typing a verb, it's suggestions are the verbs that match the
typed text (with the selected suggestion appearing top of the list).

Another aside: Entries in the suggestion list should have more
properties - eg. if dates appply to them, browsing history items, then
the "today" magic word could filter that suggestion list to items
browsed today.

Taking the "today" magic word as an example, depending on verb/noun
context it could set it's own token value to either todays date or a
filtered list of suggestions, or null and filter an adjacent token
suggestion list to today.

[Blair McBride]

Have you read Jono's blog post about this?
http://jonoscript.wordpress.com/2008/08/27/plumbing-and-the-magic-word-it/

Its definitely something I'd like to see explored. There are a lot of
contextual data available, that the user shouldn't have to explicitly
fetch themselves.

- Blair

[Jono]

Hi Guy!

A lot of the proposed magic words are actually specific to certain noun-types.  That is, while "this" (to get the selection), "these" (proposed to get multiple selections) "and" ( proposed to chain commands together) are universal across different commands and data types, other proposed magic words only make sense as arguments for a single noun-type, e.g. "url" (gets url of the page, only makes sense for noun_type_url, which doesn't exist now but should.)  In the same way, "here" to get current geoLocation by IP only makes sense for noun_type_address (or noun_type_location, or whatever we end up calling it.)

So a lot of proposed magic words can simply go into noun type impelmentations.  For an example, see noun_type_geolocation inside of the patch attatched to ticket 211: http://labs.toolness.com/trac/attachment/ticket/211/patch2.diff

If it turns out that there is a need for more magic words that are truly general as opposed to noun-type specific, then I am in full agreement that they should be extensible, with the ability to be imported from third-party command feeds.

So, exercise for the mailing list readers: propose a new magic word whose usefulness is not bound to any particular noun type.

--Jono

[Guy Fraser]

Jono wrote:
> So, exercise for the mailing list readers: propose a new magic word
> whose usefulness is not bound to any particular noun type.

This question would be better put to the main list IMHO as there are
more end-users there and it's their feedback that counts most.

[Davanum Srinivas]

find starbucks near "whereiam" / "home" / "me" ?

-- dims

--
Davanum Srinivas :: http://davanum.wordpress.com

[Guy Fraser]

Davanum Srinivas wrote:
> find starbucks near "whereiam" / "home" / "me" ?
>

"me" instead of "whereiam"

(so me can be a geolocation)

[Davanum Srinivas]

i like "it" as well to denote current selected text. (map it / save it
/ email it etc).

On Wed, Sep 3, 2008 at 12:27 AM, Jono <ebj...@gmail.com> wrote:

--
Davanum Srinivas :: http://davanum.wordpress.com

[Guy Fraser]

Wiki page to discuss magic words:
https://wiki.mozilla.org/Labs/Ubiquity/Magic_Words