On Mon, Oct 12, 2009 at 11:14 PM, Daniele S. <oppifjel...@gmail.com> wrote: > and what about moles? and toolbars?
Moles don't make much sense without toolstrips, so yeah, they are discontinued, too. Though browser actions popups are very similar to moles. In fact, they look a little nicer.
> toolstrip can have multiple buttons and the toolstrip bar has more estate > than the browseraction bar.
That's true. Part of Chrome's style is that is super minimal, so we've been trying to come up with good extensibility points that preserve that.
> Chrome extensions system is not bloated, instead it lacks feature, why are > you removing things instead of adding? :O
Just like with Chrome itself, we're very picky :).
It is not quite clear for me - where do I have to move code from
toolstrip?
Background page is not an option because I need a per-window execution
context which 'lives' as long as browser window do.
Denis
On 13 окт, 12:30, Aaron Boodman <a...@chromium.org> wrote:
> On Mon, Oct 12, 2009 at 11:14 PM, Daniele S. <oppifjel...@gmail.com> wrote:
> > and what about moles? and toolbars?
> Moles don't make much sense without toolstrips, so yeah, they are
> discontinued, too. Though browser actions popups are very similar to
> moles. In fact, they look a little nicer.
> > toolstrip can have multiple buttons and the toolstrip bar has more estate
> > than the browseraction bar.
> That's true. Part of Chrome's style is that is super minimal, so we've
> been trying to come up with good extensibility points that preserve
> that.
> > Chrome extensions system is not bloated, instead it lacks feature, why are
> > you removing things instead of adding? :O
> Just like with Chrome itself, we're very picky :).
> It is not quite clear for me - where do I have to move code from
> toolstrip?
> Background page is not an option because I need a per-window execution
> context which 'lives' as long as browser window do.
You can accomplish the same thing by watching window events in a
background page.
> On 13 окт, 12:30, Aaron Boodman <a...@chromium.org> wrote:
>> On Mon, Oct 12, 2009 at 11:14 PM, Daniele S. <oppifjel...@gmail.com> wrote:
>> > and what about moles? and toolbars?
>> Moles don't make much sense without toolstrips, so yeah, they are
>> discontinued, too. Though browser actions popups are very similar to
>> moles. In fact, they look a little nicer.
>> > toolstrip can have multiple buttons and the toolstrip bar has more estate
>> > than the browseraction bar.
>> That's true. Part of Chrome's style is that is super minimal, so we've
>> been trying to come up with good extensibility points that preserve
>> that.
>> > Chrome extensions system is not bloated, instead it lacks feature, why are
>> > you removing things instead of adding? :O
>> Just like with Chrome itself, we're very picky :).
On Tue, Oct 13, 2009 at 3:05 AM, Dan <d...@dancryer.com> wrote: >> That's true. Part of Chrome's style is that is super minimal, so we've >> been trying to come up with good extensibility points that preserve >> that.
> How does this cover extensions along the lines of Firebug?
If you mean how does this cover developer tools, the web inspector already covers most of what firebug does (and some things it doesn't). Over time, I would expect that it will become extensible itself.
If you mean extensions that require a large persistent surface like firebug because they have a lot of information and need to stay visible all of the time, then we don't have a good answer here. This is a frequent request however, so you can expect us to revisit this.
This change is really disappointing. Our plan was to have two simple
single-click action buttons in our extension, and it appears this is simply
not possible with the browser actions implementation (ahem, unless we
install two extensions -- ugh!). Am I missing something?
If there is a chance this decision would be re-visited: Could you not make
it a user option to hide the extension toolstrip?
[mailto:chromium-extensions@googlegroups.com] On Behalf Of Aaron Boodman
Sent: Monday, October 12, 2009 11:31 PM
To: Daniele S.
Cc: Chromium-extensions
Subject: [chromium-extensions] Re: Toolstrips discontinued?
On Mon, Oct 12, 2009 at 11:14 PM, Daniele S. <oppifjel...@gmail.com> wrote:
> and what about moles? and toolbars?
Moles don't make much sense without toolstrips, so yeah, they are
discontinued, too. Though browser actions popups are very similar to
moles. In fact, they look a little nicer.
> toolstrip can have multiple buttons and the toolstrip bar has more estate
> than the browseraction bar.
That's true. Part of Chrome's style is that is super minimal, so we've
been trying to come up with good extensibility points that preserve
that.
> Chrome extensions system is not bloated, instead it lacks feature, why are
> you removing things instead of adding? :O
Just like with Chrome itself, we're very picky :).
On Tue, Oct 13, 2009 at 9:08 AM, Don Schmitt <don...@verizon.net> wrote: > This change is really disappointing. Our plan was to have two simple > single-click action buttons in our extension, and it appears this is simply > not possible with the browser actions implementation (ahem, unless we > install two extensions -- ugh!). Am I missing something?
No, but it would be possible to add a pop-up and put multiple controls in there. This is the same sort of thing that Chrome itself frequently does (see, eg, the wrench menu).
> If there is a chance this decision would be re-visited: Could you not make > it a user option to hide the extension toolstrip?
We actually do have an option to hide the toolstrip in the current implementation (ctrl+alt+b). However, it doesn't solve the problem for people who do want their extensions visible, but don't want to lose the entire strip of vertical real-estate.
Mh. yes, the wrench menu and the page menu looks alike of browser action but
they've native look.Using HTML to render the popup will bring any sort of
user experience and look&feel.
Browser Actions are a good idea but in this shape they're not useful as the
toolstrip.
On Tue, Oct 13, 2009 at 6:46 PM, Aaron Boodman <a...@chromium.org> wrote:
> On Tue, Oct 13, 2009 at 9:08 AM, Don Schmitt <don...@verizon.net> wrote:
> > This change is really disappointing. Our plan was to have two simple
> > single-click action buttons in our extension, and it appears this is
> simply
> > not possible with the browser actions implementation (ahem, unless we
> > install two extensions -- ugh!). Am I missing something?
> No, but it would be possible to add a pop-up and put multiple controls
> in there. This is the same sort of thing that Chrome itself frequently
> does (see, eg, the wrench menu).
> > If there is a chance this decision would be re-visited: Could you not
> make
> > it a user option to hide the extension toolstrip?
> We actually do have an option to hide the toolstrip in the current
> implementation (ctrl+alt+b). However, it doesn't solve the problem for
> people who do want their extensions visible, but don't want to lose
> the entire strip of vertical real-estate.
> We actually do have an option to hide the toolstrip in the current
> implementation (ctrl+alt+b).
it's really hard to access
> people who do want their extensions visible, but don't want to lose
> the entire strip of vertical real-estate.
but there are extensions which don't need to be always at top, so
it would be better to have smaller toolstrip on the right side of
screen
similar to statusbar on the left, which will appear on mouseover
and users will be able to move extension buttons between main toolbar
and this small one
This decision is really bothering me. Despite your claims otherwise
Browser Actions are a decidedly _not_ elegant solution.
Consider the case that I want to build an extension that checks the
current page for a variety of different web analytics script tags
(Google analytics, Omniture, Website Optimizer, others), parse them
for useful info (acct number, check implementation errors, etc), and
if found display an icon with an optional text snippet for each.
Now, imagine GA code and Omniture codes both exist on a given page.
Let's take it from a user's perspective. In the ideal scenario two
icons would be displayed side by side alerting the user with a simple
glance that both are found. This is a zero click operation. If I want
to add a unique onClick to each icon, let's say to pull up that user's
account for each tool, it would be a 1 click operation.
There is no way to get the same user experience with the current
implementation. To accomplish the same with BrowerActions at best I
would have to have many many permutations of icons and a minimum two
click experience - one to find out both codes existed and another to
jump to the account.
This seems like a rather Apple-like move. *You are sacrificing utility
for the sake of asthetics!* The user has made a conscious decision to
download and install this plug-in. It's not as if I'm doing some
driveby irreversable plug/in installation that will rapidly consume
precious screen realestate. If they don't like my design decisions
they can uninstall it. By limiting my development options this way you
are also limiting user choice. Consider the Google Android analogy.
Isn't one of the Android selling points to developers it is more
flexible than the iPhone? (The recent Droid commercials mockingly say
so). And by extension more flexibility means more developers means a
healthier plugin ecosystem means more users?
Please please consider my use case above.
Gabe
On Oct 13, 3:07 pm, Harutyun Amirjanyan <amirjan...@gmail.com> wrote:
> > We actually do have an option to hide the toolstrip in the current
> > implementation (ctrl+alt+b).
> it's really hard to access
> > people who do want their extensions visible, but don't want to lose
> > the entire strip of vertical real-estate.
> but there are extensions which don't need to be always at top, so
> it would be better to have smaller toolstrip on the right side of
> screen
> similar to statusbar on the left, which will appear on mouseover
> and users will be able to move extension buttons between main toolbar
> and this small one
On Mon, Oct 26, 2009 at 5:16 PM, Gabe <gabefran...@gmail.com> wrote: > This decision is really bothering me. Despite your claims otherwise > Browser Actions are a decidedly _not_ elegant solution.
> Consider the case that I want to build an extension that checks the > current page for a variety of different web analytics script tags > (Google analytics, Omniture, Website Optimizer, others), parse them > for useful info (acct number, check implementation errors, etc), and > if found display an icon with an optional text snippet for each.
It seems like there could be a page or browser action that says "there are some interesting analytics tags on this page", then you click that to get more information.
While I agree that this makes the experience more clicks, it seems more it fits in better with Chrome's own UI. It also prevents users from getting into a situation where they have lots of buttons but only need a few of them.
In any case, we are keeping an eye out for places where we don't meet the use cases and will keep them in mind when designing future UI surfaces for extensions.
When designing these UI cases please remember that installing and uninstalling a plug-ins is a user choice. The extension should be allowed to be as ugly and cluttered as it wants. If the user doesn't like it they will uninstall it. This top-down decision making is un-Googley.
On Tue, Oct 27, 2009 at 2:16 PM, Aaron Boodman <a...@chromium.org> wrote: > On Mon, Oct 26, 2009 at 5:16 PM, Gabe <gabefran...@gmail.com> wrote: > > This decision is really bothering me. Despite your claims otherwise > > Browser Actions are a decidedly _not_ elegant solution.
> > Consider the case that I want to build an extension that checks the > > current page for a variety of different web analytics script tags > > (Google analytics, Omniture, Website Optimizer, others), parse them > > for useful info (acct number, check implementation errors, etc), and > > if found display an icon with an optional text snippet for each.
> It seems like there could be a page or browser action that says "there > are some interesting analytics tags on this page", then you click that > to get more information.
> While I agree that this makes the experience more clicks, it seems > more it fits in better with Chrome's own UI. It also prevents users > from getting into a situation where they have lots of buttons but only > need a few of them.
> In any case, we are keeping an eye out for places where we don't meet > the use cases and will keep them in mind when designing future UI > surfaces for extensions.
On Tue, Oct 27, 2009 at 11:26 AM, Gabriel Francis <gabefran...@gmail.com> wrote: > When designing these UI cases please remember that installing and > uninstalling a plug-ins is a user choice. The extension should be allowed to > be as ugly and cluttered as it wants. If the user doesn't like it they will > uninstall it. This top-down decision making is un-Googley.
Ah, you wield that word like a Googler.
Unfortunately, we have seen from other systems that users do not actually uninstall plugins they don't want; they just suffer. Often they do not know how to get rid of a plugin, or they want one feature, but not all the other features.
The shape of v1 of the Chromium extension system is an attempt to guide developers into treating the UI as carefully as the Chromium team itself does. It may not work, but we think it's an experiment worth trying. If it fails, we can always add, but we cannot realistically take away.
I still stand that keeping the toolstrip and making -show-extensions-
on-top the
default behavior is still best.
I realized recently the very few people knew that this trigger even
existed!
See screenshot at http://thebrauergroup.com/labs/ if you've never used
that trigger
It removes the need for an extra bar at the bottom and still allows
the extreme versatility that toolstrips have to offer. Without
toolstrips, Chrome doesn't have a fighting chance competing on the
extension front with FireFox or even (dare I say it) IE.
On Oct 28, 4:00 am, Aaron Boodman <a...@chromium.org> wrote:
> On Tue, Oct 27, 2009 at 11:26 AM, Gabriel Francis <gabefran...@gmail.com> wrote:
> > When designing these UI cases please remember that installing and
> > uninstalling a plug-ins is a user choice. The extension should be allowed to
> > be as ugly and cluttered as it wants. If the user doesn't like it they will
> > uninstall it. This top-down decision making is un-Googley.
> Ah, you wield that word like a Googler.
> Unfortunately, we have seen from other systems that users do not
> actually uninstall plugins they don't want; they just suffer. Often
> they do not know how to get rid of a plugin, or they want one feature,
> but not all the other features.
> The shape of v1 of the Chromium extension system is an attempt to
> guide developers into treating the UI as carefully as the Chromium
> team itself does. It may not work, but we think it's an experiment
> worth trying. If it fails, we can always add, but we cannot
> realistically take away.
