Atul and I were brainstorming about ways of leveraging (sorry Jono) existing communities to further increase the surface area of innovation (sorry Jono) provided by Ubiquity. It occurred to us (Atul in specific) that it wouldn't be hard to allow Ubiquity scripts to wrap existing GreaseMonkey scripts. That way, you could simply subscribe to GM scripts with Ubiquity -- no more annoying and funky UI.
What do y'all think? Would someone be interested in whipping this up?
-- aza | ɐzɐ -- * I'm appologzing to Jono for using buzz-like words.
Aza wrote: > Atul and I were brainstorming about ways of leveraging (sorry Jono) > existing communities to further increase the surface area of > innovation (sorry Jono) provided by Ubiquity. It occurred to us (Atul > in specific) that it wouldn't be hard to allow Ubiquity scripts to > wrap existing GreaseMonkey scripts. That way, you could simply > subscribe to GM scripts with Ubiquity -- no more annoying and funky UI.
Sounds like a good idea - would it be worth approaching the greasemonkey team to see if it's something they'd be willing to collaborate on?
> Atul and I were brainstorming about ways of leveraging (sorry Jono) > existing communities to further increase the surface area of innovation > (sorry Jono) provided by Ubiquity. It occurred to us (Atul in specific) > that it wouldn't be hard to allow Ubiquity scripts to wrap existing > GreaseMonkey scripts. That way, you could simply subscribe to GM scripts > with Ubiquity -- no more annoying and funky UI.
> What do y'all think? Would someone be interested in whipping this up?
If this would solve the "lose subscriptions when browser history is cleared" bug, I'm 100% for it!
@Guy: We can certainly reach out to the GM community to talk about how to release the functionality. I know Aaron Boodman, but I think we should get something working first.
-- aza | ɐzɐ --
On Mon, Sep 1, 2008 at 4:36 PM, Michael Campbell <
> > Atul and I were brainstorming about ways of leveraging (sorry Jono) > > existing communities to further increase the surface area of innovation > > (sorry Jono) provided by Ubiquity. It occurred to us (Atul in specific) > > that it wouldn't be hard to allow Ubiquity scripts to wrap existing > > GreaseMonkey scripts. That way, you could simply subscribe to GM scripts > > with Ubiquity -- no more annoying and funky UI.
> > What do y'all think? Would someone be interested in whipping this up?
> If this would solve the "lose subscriptions when browser history is > cleared" > bug, I'm 100% for it!
To be honest, I don't see much value in bringing Greasemonkey scripts
to Ubiquity.
I think that Ubiquity should focus on solving the unique problems that
it is positioned to solve first.
Sure, all things done by Greasemonkey can be done by Ubiquity, but
Greasemonkey can do them in a safer way already.
Also, most Greasemonkey scripts don't have any UI, or it is directly
merged into the web page. Not many use the GM_registerMenuCommand
function to expose themselves in the chrome.
Finally, Greasemonkey is strong for handling site specific scripts.
On the other hand, Ubiquity seems best suited for features which
require either interaction, some deep browser integration (controlling
FoxyTunes, controlling tabs, getting suggestions from the
AwesomeBar, ...), or which you don't want to take UI real-estate until
you need it.
It seems to shine for commands like: map, calendar, tabs, insert-link,
send, weather, search, etc. which can be run in any context.
These commands have not been implemented with Greasemonkey before (you
can look at http://userscripts.org for many examples).
These commands are convenient to pull when needed, in context, but
should not take chrome or web page real-estate most of the time.
It would useful for the Ubiquity team to understand Greasemonkey, and
clarify how it aims to differentiate itself.
Injecting user scripts in web pages should not be the definition of
Ubiquity.
Cheers,
Julien
PS: I'm excited about Ubiquity, but I'll still be running and
authoring Greasemonkey scripts for a while ;-)
> @Guy: We can certainly reach out to the GM community to talk about how to
> release the functionality. I know Aaron Boodman, but I think we should get
> something working first.
> -- aza | ɐzɐ --
> On Mon, Sep 1, 2008 at 4:36 PM, Michael Campbell <
> > > Atul and I were brainstorming about ways of leveraging (sorry Jono)
> > > existing communities to further increase the surface area of innovation
> > > (sorry Jono) provided by Ubiquity. It occurred to us (Atul in specific)
> > > that it wouldn't be hard to allow Ubiquity scripts to wrap existing
> > > GreaseMonkey scripts. That way, you could simply subscribe to GM scripts
> > > with Ubiquity -- no more annoying and funky UI.
> > > What do y'all think? Would someone be interested in whipping this up?
> > If this would solve the "lose subscriptions when browser history is
> > cleared"
> > bug, I'm 100% for it!
I think the point of integrating with Greasemonkey is that it will bring in more people to develop Ubiquity commands. And also, it will show that Ubiquity can be used to write scripts that are not neccessarily commands. For example, the keyscape "command" (http://foyrek.com/keyscape.html) is actually more like a GM script or a Firefox extension. But the ease of subscribing to commands (from the user's perspective) and the ease of writing commands in Ubiquity (for the developer) makes Keyscape worth writing in Ubiquity.
Basically, if we integrate with Greasemonkey, we can bring in a lot more people who are interested in similar things.
> To be honest, I don't see much value in bringing Greasemonkey scripts > to Ubiquity. > I think that Ubiquity should focus on solving the unique problems that > it is positioned to solve first.
> Sure, all things done by Greasemonkey can be done by Ubiquity, but > Greasemonkey can do them in a safer way already. > Also, most Greasemonkey scripts don't have any UI, or it is directly > merged into the web page. Not many use the GM_registerMenuCommand > function to expose themselves in the chrome. > Finally, Greasemonkey is strong for handling site specific scripts.
> On the other hand, Ubiquity seems best suited for features which > require either interaction, some deep browser integration (controlling > FoxyTunes, controlling tabs, getting suggestions from the > AwesomeBar, ...), or which you don't want to take UI real-estate until > you need it. > It seems to shine for commands like: map, calendar, tabs, insert-link, > send, weather, search, etc. which can be run in any context. > These commands have not been implemented with Greasemonkey before (you > can look at http://userscripts.org for many examples). > These commands are convenient to pull when needed, in context, but > should not take chrome or web page real-estate most of the time.
> It would useful for the Ubiquity team to understand Greasemonkey, and > clarify how it aims to differentiate itself. > Injecting user scripts in web pages should not be the definition of > Ubiquity.
> Cheers, > Julien > PS: I'm excited about Ubiquity, but I'll still be running and > authoring Greasemonkey scripts for a while ;-)
> On Sep 1, 5:23 pm, Aza <a...@mozilla.com> wrote: > > @Michael: That's be working on herehttp:// > labs.toolness.com/trac/ticket/146
> > @Guy: We can certainly reach out to the GM community to talk about how to > > release the functionality. I know Aaron Boodman, but I think we should > get > > something working first.
> > -- aza | ɐzɐ --
> > On Mon, Sep 1, 2008 at 4:36 PM, Michael Campbell <
> > > > Atul and I were brainstorming about ways of leveraging (sorry Jono) > > > > existing communities to further increase the surface area of > innovation > > > > (sorry Jono) provided by Ubiquity. It occurred to us (Atul in > specific) > > > > that it wouldn't be hard to allow Ubiquity scripts to wrap existing > > > > GreaseMonkey scripts. That way, you could simply subscribe to GM > scripts > > > > with Ubiquity -- no more annoying and funky UI.
> > > > What do y'all think? Would someone be interested in whipping this up?
> > > If this would solve the "lose subscriptions when browser history is > > > cleared" > > > bug, I'm 100% for it!
Abimanyu Raja wrote: > I think the point of integrating with Greasemonkey is that it will > bring in more people to develop Ubiquity commands. And also, it will > show that Ubiquity can be used to write scripts that are not > neccessarily commands. For example, the keyscape "command" > (http://foyrek.com/keyscape.html) is actually more like a GM script or > a Firefox extension. But the ease of subscribing to commands (from the > user's perspective) and the ease of writing commands in Ubiquity (for > the developer) makes Keyscape worth writing in Ubiquity.
> Basically, if we integrate with Greasemonkey, we can bring in a lot > more people who are interested in similar things.
Before we bring more people in to write ubiq commands, we need to mature the way scripts are written. Currently it's a bit haphazard and adding more plugins now just means more plugins will break should structural changes be made later.
Abi has it exactly right, but Guy also has a good point -- although I frankly thing that adding a GM shim would be one of the things least likely to change in the future (as GM is already fairly mature).
On Tue, Sep 2, 2008 at 2:06 AM, Guy Fraser <gfra...@adaptavist.com> wrote:
> Abimanyu Raja wrote: > > I think the point of integrating with Greasemonkey is that it will > > bring in more people to develop Ubiquity commands. And also, it will > > show that Ubiquity can be used to write scripts that are not > > neccessarily commands. For example, the keyscape "command" > > (http://foyrek.com/keyscape.html) is actually more like a GM script or > > a Firefox extension. But the ease of subscribing to commands (from the > > user's perspective) and the ease of writing commands in Ubiquity (for > > the developer) makes Keyscape worth writing in Ubiquity.
> > Basically, if we integrate with Greasemonkey, we can bring in a lot > > more people who are interested in similar things.
> Before we bring more people in to write ubiq commands, we need to mature > the way scripts are written. Currently it's a bit haphazard and adding > more plugins now just means more plugins will break should structural > changes be made later.
Aza wrote:
> Abi has it exactly right, but Guy also has a good point -- although I > frankly thing that adding a GM shim would be one of the things least > likely to change in the future (as GM is already fairly mature).
> -- aza | ɐzɐ --
> On Tue, Sep 2, 2008 at 2:06 AM, Guy Fraser <gfra...@adaptavist.com > <mailto:gfra...@adaptavist.com>> wrote:
> Abimanyu Raja wrote:
> > I think the point of integrating with Greasemonkey is that it will
> > bring in more people to develop Ubiquity commands. And also, it will
> > show that Ubiquity can be used to write scripts that are not
> > neccessarily commands. For example, the keyscape "command"
> > (http://foyrek.com/keyscape.html) is actually more like a GM
> script or
> > a Firefox extension. But the ease of subscribing to commands
> (from the
> > user's perspective) and the ease of writing commands in Ubiquity
> (for
> > the developer) makes Keyscape worth writing in Ubiquity.
> > Basically, if we integrate with Greasemonkey, we can bring in a lot
> > more people who are interested in similar things.
> Before we bring more people in to write ubiq commands, we need to
> mature
> the way scripts are written. Currently it's a bit haphazard and adding
> more plugins now just means more plugins will break should structural
> changes be made later.
I had the same idea awhile ago about Operator - not so much integrating it, but making use of it if the user has it installed. Using the additional contextual data could be quite helpful.
> Aza wrote:
>> Abi has it exactly right, but Guy also has a good point -- although I
>> frankly thing that adding a GM shim would be one of the things least
>> likely to change in the future (as GM is already fairly mature).
>> -- aza | ɐzɐ --
>> On Tue, Sep 2, 2008 at 2:06 AM, Guy Fraser<gfra...@adaptavist.com
>> <mailto:gfra...@adaptavist.com>> wrote:
>> Abimanyu Raja wrote:
>> > I think the point of integrating with Greasemonkey is that it will
>> > bring in more people to develop Ubiquity commands. And also, it will
>> > show that Ubiquity can be used to write scripts that are not
>> > neccessarily commands. For example, the keyscape "command"
>> > (http://foyrek.com/keyscape.html) is actually more like a GM
>> script or
>> > a Firefox extension. But the ease of subscribing to commands
>> (from the
>> > user's perspective) and the ease of writing commands in Ubiquity
>> (for
>> > the developer) makes Keyscape worth writing in Ubiquity.
>> > Basically, if we integrate with Greasemonkey, we can bring in a lot
>> > more people who are interested in similar things.
>> Before we bring more people in to write ubiq commands, we need to
>> mature
>> the way scripts are written. Currently it's a bit haphazard and adding
>> more plugins now just means more plugins will break should structural
>> changes be made later.
Blair McBride wrote:
> I had the same idea awhile ago about Operator - not so much integrating > it, but making use of it if the user has it installed. Using the > additional contextual data could be quite helpful.
Yes that would be Great, Better still it may be easier to Use the Microformats API that comes built into Firefox 3
>>> Abi has it exactly right, but Guy also has a good point -- although I
>>> frankly thing that adding a GM shim would be one of the things least
>>> likely to change in the future (as GM is already fairly mature).
>>> -- aza | ɐzɐ --
>>> On Tue, Sep 2, 2008 at 2:06 AM, Guy Fraser<gfra...@adaptavist.com
>>> <mailto:gfra...@adaptavist.com>> wrote:
>>> Abimanyu Raja wrote:
>>> > I think the point of integrating with Greasemonkey is that it will
>>> > bring in more people to develop Ubiquity commands. And also, it will
>>> > show that Ubiquity can be used to write scripts that are not
>>> > neccessarily commands. For example, the keyscape "command"
>>> > (http://foyrek.com/keyscape.html) is actually more like a GM
>>> script or
>>> > a Firefox extension. But the ease of subscribing to commands
>>> (from the
>>> > user's perspective) and the ease of writing commands in Ubiquity
>>> (for
>>> > the developer) makes Keyscape worth writing in Ubiquity.
>>> > Basically, if we integrate with Greasemonkey, we can bring in a lot
>>> > more people who are interested in similar things.
>>> Before we bring more people in to write ubiq commands, we need to
>>> mature
>>> the way scripts are written. Currently it's a bit haphazard and adding
>>> more plugins now just means more plugins will break should structural
>>> changes be made later.
> Blair McBride wrote:
> > I had the same idea awhile ago aboutOperator- not so much integrating
> > it, but making use of it if the user has it installed. Using the
> > additional contextual data could be quite helpful.
> Yes that would be Great, Better still it may be easier to Use the
> Microformats API that comes built into Firefox 3
> >>> Abi has it exactly right, but Guy also has a good point -- although I
> >>> frankly thing that adding a GM shim would be one of the things least
> >>> likely to change in the future (as GM is already fairly mature).
> >>> -- aza | ɐzɐ --
> >>> On Tue, Sep 2, 2008 at 2:06 AM, Guy Fraser<gfra...@adaptavist.com
> >>> <mailto:gfra...@adaptavist.com>> wrote:
> >>> Abimanyu Raja wrote:
> >>> > I think the point of integrating with Greasemonkey is that it will
> >>> > bring in more people to develop Ubiquity commands. And also, it will
> >>> > show that Ubiquity can be used to write scripts that are not
> >>> > neccessarily commands. For example, the keyscape "command"
> >>> > (http://foyrek.com/keyscape.html) is actually more like a GM
> >>> script or
> >>> > a Firefox extension. But the ease of subscribing to commands
> >>> (from the
> >>> > user's perspective) and the ease of writing commands in Ubiquity
> >>> (for
> >>> > the developer) makes Keyscape worth writing in Ubiquity.
> >>> > Basically, if we integrate with Greasemonkey, we can bring in a lot
> >>> > more people who are interested in similar things.
> >>> Before we bring more people in to write ubiq commands, we need to
> >>> mature
> >>> the way scripts are written. Currently it's a bit haphazard and adding
> >>> more plugins now just means more plugins will break should structural
> >>> changes be made later.
|
