Sometimes more constraints help produce better designs. Wired did an interesting set of articles on this idea a few months back: http://www.wired.com/culture/design/magazine/17-03/dp_intro
It will be interesting to see if this proves true for browser actions. As Aaron said, we thought hard about the browser actions decision and didn't make it lightly, knowing how it might impact some of you early adopters who've already put in a lot of work on extensions using toolstrips for UI. Chrome is an opinionated project, and some of those opinions have taken me some time to get used to. For an interesting exercise, look at these two pages articulating Chrome's overall design philosophy, and think about applying those ideas to extensions: http://dev.chromium.org/developers/core-principles http://dev.chromium.org/user-experience On Thu, Oct 15, 2009 at 8:22 AM, disya2 <[email protected]> wrote: > > Hi, > > Just today's morning I was thinking hard the about the things jack > mentions. > My personal position as a computer user is "give me a way to make > things look and feel I like". That made me switch to Linux from > Windows and because of that Firefox became my favorite instead of > Opera. The thing I liked most was KDE 3.x panel, I could put it on > top, bottom, left, right, shrink it, make it collapsible, change icon > size and bg transparency... After they released KDE 4 (where I lacked > the features) I had to switch to Gnome because it provides less > flexible but still highly customizable panels. > > Concerning Browser Actions and toolstrip - why not to make a > detachable, movable toolbar where extension developers could put their > HTML like they do in toolstrip? This toolbar could be placed next to > omnibox by default (and look pretty much like browser actions), > attached to statusbar, right or left side like sidebar, be collapsible > (here I mean it could grow on mouse over and hide on mouse out). > Even more, there could be many toolbars: one next to omnibox, another > on left, etc. And extensions html could be dragged on any of them. > > As I understand the main concern against toolstrip is that it is a > waste in case one have only one-two extensions installed. But let the > user decide! If he or she wants a long, descriptive text with a couple > of icons, and the info is more valuable than 24 px of web page real > estate or whatever else, why not to make it possible? As example I > could imagine stock quotes or wheather info. In case user wants a more > compact, lightweight UI then he or she can make extension's author to > do so. > > And last but not least, I need a per-window execution context like I > have in toolstrip.html. Of course I could manage things in background > page listening to window create/close events but that would complicate > many things which are already implemented and tested in my extension. > I just see no reason why not to. > > Thanks, > Denis > > On Oct 14, 11:51 pm, jack <[email protected]> wrote: > > I would like to add my humble opinion on this topic. Though both of my > > extensions (Cleeki and AniWeather) are surely affected, my opinion > > below is, instead, more from a viewpoint of a user. > > > > The lesson I learned from my development experience, more importantly > > as a user, is to avoid making a hard-coded decision on behalf of a > > user, unless a user really doesn't know what he wants. When a group of > > users are pleased because of certain deterministic setting, there > > might be equal amount of users who are unhappy about it, considering > > statistically users are more likely to complain, instead of > > complimenting. Every user is unique, and the best way is to > > accommodate the demand from both sides. In all classic applications > > (Windows Explore, Internet Explorer, Firefox), there is an option to > > hide status bar and I don't know why this is a problem for Chrome. > > Getting rid of an option because some dislike it is like getting ride > > of the disabled permit parking because most drivers won't need it. > > > > Back to browser actions, only allowing one 19px image let the designed > > system immediately reach its upper capacity without any grace space > > for future expanding. IMHO allowing a popup page is like a clumsy > > patch because of this hard-coded architecture. That said, I am pretty > > sure that many users will like it because of its simplicity, but I am > > also confident that there are many users/developers feeling it is too > > restricted. > > > > Of course, the above is just my 2c and in no means I meant to alter > > any decision in Chrome dev because I am standing out of it. But I > > believe if Google Chrome is targeting at gaining some share from the > > severe browser battle, it might be a good idea to consider more from > > users. > > > > Best, > > Jack > > > > On Oct 12, 2:41 pm, Aaron Boodman <[email protected]> wrote: > > > > > Hello all, > > > > > As a few of you have noticed from changes in the bug system, we've > decided > > > to replace toolstrips with a new extensions UI surface area: browser > > > actions<http://code.google.com/p/chromium/wiki/BrowserActions> > > > . > > > Here is what they look like: > > > > > [image: browser_action.png] > > > > > A browser action is a 19px image button that shows up in the main > Chrome > > > toolbar to the right of the omnibox. They can be rendered from a static > set > > > of images in your extension, or you can render them dynamically using > the > > > HTML5 canvas. > > > > > They can also optionally have a popup, which is implemented using HTML, > > > similar to how toolstrips worked. > > > > > We will be disabling toolstrips before the beta release of Chrome 4, so > we > > > encourage extension developers to start converting their extensions to > use > > > browser actions soon. We'll be updating the docs in the coming weeks > with > > > details. > > > Even though we are still in the dev channel of Chrome, where everything > is > > > subject to change, we try to avoid ever breaking APIs. So we didn't > come to > > > this decision lightly. The reason we did it that we got a lot of > negative > > > feedback about the toolstrip shelf across the bottom of the browser. > Many > > > users did not like the wasted space, particularly when only one > extension > > > was installed. > > > > > When we stepped back and thought about the use cases, we came to the > > > conclusion that most extensions don't really need to show complex UI in > the > > > toolbar -- a single button with an expandable area is usually > sufficient. > > > This also had the advantage of being a more prominent location and > fitting > > > better with Chrome's sparse aesthetic. > > > > > While we understand this change is frustrating and won't work perfectly > for > > > every extension, we think it is for the best, and are excited to see > what > > > you can do with it. > > > > > If you want to get started even before we finish the docs, you can take > a > > > look at our samples, which have already been converted: > > > > > - > > > > http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/exte... > > > - > > > > http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/exte... > > > - > > > > http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/exte... > > > - > > > > http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/exte... > > > - > > > > http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/exte... > > > > > I'll post on this mailing list as the browser action API solidifies and > the > > > documentation is completed. > > > > > - a > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en -~----------~----~----~----~------~----~------~--~---
