So the summary of this bug is actually serious, we need to get all of the search engines packaged with Firefox (across every localization), to provide a specific RGB value that they would like used for the active state of their engine in the Firefox search bar. Details here: http://areweprettyyet.com/5/searchBar/ For engines that don't provide a color, we'll probably fall back to extracting one from their favicon (bug 634139), or using the same neutral color of the navigation toolbar.
I am opposed to this, fwiw. I confess I don't understand the rationale for using different colors rather than a single color to draw attention to the search bar. Have we done any research that says this will help, or would a consistent, attention-grabbing color be equally effective? It adds administrative overhead in keeping on top of search engine branding, and when the search engines change their brand/color scheme (which does happen every so often), and we'll have to stay on top of it (and push updates) for when the sites undergo branding/identity changes. It doesn't happen often (every 2-3 years, it seems), but when you multiply that across multiple search engines and locales, it means there will have to be an owner. I'd like to keep complexity down as much as possible, because updating plugins (from experience) can be a royal pain.
>I confess I don't understand the rationale for >using different colors rather than a single color to draw attention to the >search bar. The goal is to reduce mode errors by leveraging the user's peripheral vision. Our current design creates a lot of mode errors. The normal steps are: -You switch the engine to wikipedia -You do a wikipedia search [wait several hours] -You do a google search -You end up on wikipedia We can alternatively address this by making the search bar spring loaded (switches back to default after use), however that could be viewed as a revenue play, or evil (in reality we are just trying to create an interface that doesn't lead to constant mode errors, and doesn't surprise the user). By leveraging stronger colors when the field is engaged, user's will over time know what to expect when they hit enter, and won't be as likely to be confused or surprised. The field will do a much better job of exposing it's current state to the user. Having these colors is considerably more important for a re-design of of the search bar and location bar that we want to propose later on, but since that is more complex and controversial, I'm starting out with requesting the colors for a minor adaptation of the current search bar UI.
Alex, why is the favicon we already display in the search bar not enough to distinguish between different installed search engines? Why would users better recognize the search engine by colors instead? Is your plan to completely get rid of the favicon? If yes, which colors should be used for user installed search engines? Has there been made a study about that specific topic? I would be interested in the results.
The favicon isn't dominant enough to draw attention to itself, and in the case of mode errors, the user believes that the application is in a mode that it isn't actually in (so they have no incentive to draw their attention to the favicon proactively). The additional consideration is that we want to UI to be monochrome when it is not actively in use, details about that are here: https://bugzilla.mozilla.org/show_bug.cgi?id=592909#c2 >Has there been made a study about that specific topic? I would be interested in >the results. The best way for us to capture that with Test Pilot would be to look at searches for the same string to two different engines in quick succession. Currently all of our data consists of observed usage, and anecdotal accounts of mode errors (but it isn't just a theory, the interface clearly makes mode errors easy).
(In reply to comment #2) > By leveraging stronger colors when the field is engaged, user's will over time > know what to expect when they hit enter, and won't be as likely to be confused > or surprised. The field will do a much better job of exposing it's current > state to the user. That's the bit I was missing. What may make sense here is to propose a spec change to OpenSearch at the same time, so this can be added as a field, or to make it a MozSearch parameter that we share with our providers. My primary concern here is admin overhead because, well, I'm selfish like that. Thanks for taking the time to explain it. I'd ask that in addition to this we propose a modification to the opensearch spec and, failing that, add the color as a moz param and make our search providers/partners aware what we're doing and make sure there's no objection.
That all sounds good. I would be surprised if we encountered any resistance because fundamentally we're trying to increase their brand awareness. Also the new design uses their brand as a verb, which is something they are also all eager to establish in the collective vernacular.
Kev: given the accelerated ship schedule for Firefox 5, we really need to get this bug resolved in a week or so. Working on bug 592909 is the only immediate way for us to start to address the visual cruft we have between the two bars. When the user is not interacting with the search field we need it to be monochrome, since we use gold, green, blue and red as indicators in the location bar, and all four colors currently appear simultaneously in the google favicon, cluttering our ability to represent state. Also: what would happen if we just happened to pick colors for each of the engines? Would this potentially violate an existing contract, or just be bad form?
In response to comment 2 about the confusion about switching engines, is it really the case that most users even change the engine frequently beyond what they've set as default? I generally use Google for everything. If I want a Wikipedia article for a specific topic, I just Google "wikipedia cat" or something. Using Google Chrome where they don't even have a search bar, the lack of a visual indicator for what search engine I'm using isn't a hindrance. In addition to comment1, I would add that the verbal branding of the search engine almost makes it seem like Google/Yahoo or whatever is partially responsible for the browser, kind of confusing with the Firefox text in the upper left.
How about instead of switching search engines, instead of the magnifiging glass icon in the search bar there could be separate icons for each search engine. So I enter my search string and then click on the google icon to search on google, or I click on Wikipedia icon to search wikipedia. Still would need a default engine though in case I just enter search sting end hit enter...
Images aren't always as descriptive as actual text. Some of the icons are better than others, but one of the problems with the current interface is that the icon isn't as recognizable and obvious for the user to consistently realize that they have the interface in a particular mode.
Summary: Ask search engine partners to specify their favorite color → Determine colors for each search engine
Morphing the bug to us just picking some colors so that we can move forward. If an engine complains we'll default them over to green.
Repinged Google, Yahoo!, Bing, Yandex, Amazon, and eBay asking for input. Alex, can you point me at the implementation method? Are we going to modify mozsearch entries?
(In reply to comment #12) > Alex, can you point me at the implementation method? Are we going to modify > mozsearch entries? I have a patch in bug 592909, but I haven't implemented different colors for different search providers yet. I'm not sure how we would do that. If we only want to support colors for our default search providers, we could just hard-code the colors into our CSS files, then do something like setting an attribute on the button based on the search provider to select the appropriate color. That seems less robust than allowing search providers to specify colors in mozsearch entries, but I'm not sure what issues come along with that. One concern is that if we want to use a gradient for the background, as we're currently doing for the green button in UX builds, would we ask the search providers to specify that? That seems very error-prone, so if we don't do that we would need a way to convert a single color value into a gradient.
Amazon has asked that we use hex #FF9900 for their button color.
(In reply to comment #13) > (In reply to comment #12) > > Alex, can you point me at the implementation method? Are we going to modify > > mozsearch entries? > > I have a patch in bug 592909, but I haven't implemented different colors for > different search providers yet. I'm not sure how we would do that. If we > only want to support colors for our default search providers, we could just > hard-code the colors into our CSS files, then do something like setting an > attribute on the button based on the search provider to select the > appropriate color. It may be something we want to see if OpenSearch would consider adding it to the spec, so it can be used within a plugin. Not sure if there'd be interest in doing that though, given it's limited applicability atm. Failing that, I'd focus on defaults for now, but there are a lot of different providers in l10n builds, and that could turn into some serious administrative overhead. For the gradient stuff, would it make sense to just limit it to dark/light rather than a custom colour (lime green to pink come to mind to "increase visibility").
eBay has asked that we use hex #005DAA for their button color. (blue) Bing has asked that we use hex #FFA615 for their button color. (orange) Yahoo! has asked that we use hex #7B0099 for their button color. (purple) Yandex and Google should have a color to us by mid next week.
We'll likely want to layer the gradient over their color so that there is a consistent 3D effect. Also so that the shape matches the rest of our buttons.
You need to log in before you can comment on or make changes to this bug.