The favicons in the search field are creating a significant amount of visual complexity in our product. They are using a wide range of colors, and they reduce the relative discoverability of nearby controls like reload and stop. Proposal: -Display a search magnifying glass where the current favicon is -If the field is being editing display a go button on the right, similar to the behavior of the location bar -Keep the self describing text if the field is empty, even if it has the focus (this is the indicator of which engine will be used). We would still of course use the favicons in the secondary menu for users to choose an engine that they would like to use.

If we do this, it'd be great to load the favicons dynamically, a la bookmarks, instead of storing them in the search plugin as a default.

I was just now finally able to fully figure out why the google favicon is so problematic. We are using color in this area of our UI to indicate status with peripheral vision: yellow > bookmarked green > go, or ready to hit enter blue > reload red > stop And at the same time the google favicon is emanating all four of these exact same colors simultaneously. So when you glance over, you can't as quickly figure out what is going on.

(In reply to comment #1) > If we do this, it'd be great to load the favicons dynamically, a la bookmarks, > instead of storing them in the search plugin as a default. I don't think that has anything to do with this bug; please file a separate one. Also explain why you'd want that. AFAIK (and after checking with Harvey) graphics such as favicons aren't considered "code" and are not subject to licensing issues. This bug is about removing the search engine logo from the search bar field, instead replacing it with the name of the search engine as self describing text. As long as we do that for all search engines, I think it's a fine change, and one that will help calm down the UI a lot as Alex suggests.

The icon/label next to the left of the arrow in a combo box indicates the current selection among the choices in the drop-down list. It will be confusing to have the arrow for the drop down list next to that arrow instead. Consequently, if the search engine icon goes then I think a new UI for switching search engines is needed.

Is it possible to keep the actual design but use colorless logos? With the proposed design, it will disable the following usecase. 1) Go in the search field 2) Type your query 3) Change your search engine using Cmd+arrow

(In reply to comment #5) > Is it possible to keep the actual design but use colorless logos? > > With the proposed design, it will disable the following usecase. > 1) Go in the search field > 2) Type your query > 3) Change your search engine using Cmd+arrow That's not possible, unless we get the mark-holder's permission. While we can ask, the answer will be an emphatic "no". Color is an important part of brand, and the provider's style guides are pretty explicit on modifying the marks, including making any changes to color.

(In reply to comment #6) I presume Comment 5 was rather a reply to Comment 0. Regarding Comment 0: I don't see any "significance" in visual Complexity here at all. The "wide range of colors" are actually an Advantage since they reflect the Unity of a Site's/Search Provider's Brand. And the "relative discoverability" of other Navigation Toolbar Items - if at all being affected - should - especially in the Case of new introduced ones like Stop/Reload - conform with already present Items what are given since several Fx Versions and a lot of User get used to and not the other Way round just to Fix some assumed Side Effects, no?

(In reply to comment #7) > > Regarding Comment 0: > I don't see any "significance" in visual Complexity here at all. > The "wide range of colors" are actually an Advantage since they reflect the > Unity of a Site's/Search Provider's Brand. I have to emphatically disagree. As a user, I don't care about the unity of a search provider's brand. And if I did, integrating their brand into my browser's chrome doesn't aid me in using the search box – I agree that it adds complexity. The (sighted) user is going to have their eyes focused on the search box when they are using it, so the default text should be plenty indication of what engine they have selected. If they aren't using the search box they aren't looking at it – directly or peripherally – so the favicons with all their color are overkill. Using the favicons is at best nifty. It wouldn't be much of an issue except for what Alex pointed out in regard to the favicon colors muddling the colors used for UI feedback. > And the "relative discoverability" of other Navigation Toolbar Items - if at > all being affected - should - especially in the Case of new introduced ones > like Stop/Reload - conform with already present Items what are given since > several Fx Versions and a lot of User get used to and not the other Way round > just to Fix some assumed Side Effects, no? This might be a consideration for modifying a UI element, but I don't see this as an argument against removing a UI element (or at least this UI element). Even then, while what users are accustomed to can't be ignored, there is no blanket ban on changing the purpose or conventions of part of the interface just because some elements were there first. That would result in a lack of any kind of cohesion in the design.

Mockups of what this would look like. - Replace search favicon with magnifying glass glyph - Go button at end if editing

(In reply to comment #9) > Created attachment 495555 [details] > Streamlined Search Field Mockup - i01 > > Mockups of what this would look like. > > - Replace search favicon with magnifying glass glyph > - Go button at end if editing Why the enormous Go button? Feels kind of jarring and seems unnecessary. How about the urlbar's Go arrow that you get when moving Stop and Reload back to the left? Another solution might be to reduce the opacity of the favicon so that you're still reminded where the search will go when hitting Accel+K (i.e. when you didn't necessarily read the placeholder text before focusing the search bar).

(In reply to comment #10) > Why the enormous Go button? Feels kind of jarring and seems unnecessary. How > about the urlbar's Go arrow that you get when moving Stop and Reload back to > the left? I think that if the "big" go button is the default for urlbar, I don't understand why searchbar don't use the same go button.

Consistency with the urlbar is a poor reason to introduce clutter here (a ux-minimalism bug!). If anything the urlbar layout should be revisited.

Yes, but for consistency, the button would not be so big and colored by default, only when the input has focus, which does not seem to be the case on this mockup.

The mockup shows a combination of the states. I'm aware that the Go button would only appear when editing.

I'm fine with making both buttons lighter (perhaps similar to the un-hovered reload button), and then just turning green on hover.

I use the search box quite a lot and frequently change the provider. How will you be able to tell what provider is selected when the search box is not empty? My search box is only empty for the first few minutes after loading the browser. Can you transition to the provider specific icon when the search box gets focus? Then it won't clutter the UI most of the time but you'll be able to clearly see the provider when you actually go to perform a search.

This patch leaves the search engine label on the right side of the textbox. I was trying to align it with the left side of the box, then have it move right on focus, but I had trouble figuring out how to get that to work (the left alignment, not the transition). I still have to figure out what we'll do when the input text reaches the search engine label.

Comment on attachment 497891 [details] [diff] [review] wip (osx only) (In reply to comment #19) > Created attachment 497891 [details] [diff] [review] > wip (osx only) This patch does not match the proposal: > -Keep the self describing text if the field is empty, even if it has the focus > (this is the indicator of which engine will be used). When the field is not empty, the search engine label should not appear. Clicking the search engine label should focus the textbox. The search engine label should be vertically aligned with the input text. If we decide to merge the search engine label into the right-side button, then the first two of three issues no longer apply.

(In reply to comment #19) > Created attachment 497891 [details] [diff] [review] > wip (osx only) > > This patch leaves the search engine label on the right side of the textbox. I > was trying to align it with the left side of the box, then have it move right > on focus, but I had trouble figuring out how to get that to work (the left > alignment, not the transition). > > I still have to figure out what we'll do when the input text reaches the search > engine label. Can't you use a placeholder for the search engine label? You can style the placeholder with :-moz-placeholder if needed.

(In reply to comment #21) > Can't you use a placeholder for the search engine label? You can style the > placeholder with :-moz-placeholder if needed. No, we want the text also to display when the textbox is focused, which the placeholder attribute does not support.

(In reply to comment #22) > (In reply to comment #21) > > Can't you use a placeholder for the search engine label? You can style the > > placeholder with :-moz-placeholder if needed. > > No, we want the text also to display when the textbox is focused, which the > placeholder attribute does not support. This inconsistency sounds weird to me... but I guess you guys know what you are doing :)

What about all the other search fields? about:config, download manager, history and bookmarks. Each of those search fields should have at least the new magnifier icon. OR leave the magnifier where it is (works fine right now and uses the same layout/icons as search fields under Windows) and just remove the search engine favicon from the search field. You'd just have to find a place for the drop down arrow.

In bug 594050 the UX team proposed that the go button for the url bar be hidden when the textbox is empty. We should keep that in mind when designing the visual appearance of the search field.

Comment on attachment 498843 [details] [diff] [review] patch - Type something in the search box; select all; cut; go button still there. (Pressing Esc makes the go button disappear.) - Search engine label still 1 pixel too high on OS X (not tested on Win/Lin). - Clicking the search engine label should probably focus the search box. UI opinion (2 cents): The addition of a go button to the search box makes it even more inconsistent with all the other search boxes in OS X. I'd get rid of the go button altogether. It's visually messy, and I think users can figure out how to use the search box without it.

(In reply to comment #27) > UI opinion (2 cents): > The addition of a go button to the search box makes it even more inconsistent > with all the other search boxes in OS X. I'd get rid of the go button > altogether. It's visually messy, and I think users can figure out how to use > the search box without it. I'm not sure about how far OS X users might deviate from the average, but according to https://heatmap.mozillalabs.com/, 24% of users click that button.

(In reply to comment #27) > - Type something in the search box; select all; cut; go button still there. > (Pressing Esc makes the go button disappear.) I can't reproduce this on OSX or Windows. Are you sure this happens?

Apple's online store search (http://store.apple.com/) does the placeholder text well, I think. The placeholder remains even after you focus the field, but the text fades to a lighter gray, which seems to be a good visual cue. Having the placeholder remain completely static until the user inputs some text might seem broken to some users.

Margaret: I know you're still waiting on some mockups from me here. I'll try to get them done, but it might be next week.

Here is a mockup that will: -keep the field monochrome when not in use -avoid any potential mode errors (ux-mode-error) -leverage the user's peripheral vision -potentially set up a nice interaction that we can use later if we merge the location bar with the search bar (go versus search depending on field contents, etc.)

What will determine the color for each search engine? Blue and green might clash with the meaning of blue and green badges for HTTPS.

It looks like it's the main colour of the favicon. In the Wikipedia example, the background is white, but it is a problem, as Amazon's favicon's main colour is also white (also with black).

(In reply to comment #33) > What will determine the color for each search engine? This is a good question. I think we should have hard coded colors for the search engines included with the browser, and then a default neutral color for additional installed search engines. However, we will need to figure out exactly which colors to use. Alex, can you (or probably Stephen) let me know which colors should be used?

FWIW, I don't think any colour should be used. This is about minimalism and removing colour queues from peripheral vision. IF a colour is used, it MUST be consistent across search engines. We don't have time for fancy jiggery-pokery with favicon detection, etc, and I have some reservations about that approach in general as I think it's based on an expectation that users will readily associate colours to search engine brands, which may be true for Yahoo!, but is not likely true for any other.

I'd stick to a single, consistent button color for the engines, if you go that way. In the mockup in comment #32, the colors seem (loosely) associated with the engines logo/branding. That could potentially create some trademark issues, and it seems to go back to adding visual complexity instead of minimizing it. I'd ask we stay clear of using multiple colors, and stick with a consistent color for the button regardless of engine. This keeps it simple, and also keeps us out of any marks-related problems that may result if we try and use associative colors per engine. Cool design, otherwise. (In reply to comment #35) > (In reply to comment #33) > > What will determine the color for each search engine? > > This is a good question. I think we should have hard coded colors for the > search engines included with the browser, and then a default neutral color for > additional installed search engines. However, we will need to figure out > exactly which colors to use. > > Alex, can you (or probably Stephen) let me know which colors should be used?

Oh, I should mention that I *do* like this streamlining! Especially the no-colour Wikipedia version :)

>FWIW, I don't think any colour should be used. This is about minimalism and >removing colour queues from peripheral vision. I forgot to add this to the mockup, but the button would desaturate (like the reload button), when the field isn't focused. The color was just meant as a very transient peripheral cue of what would happen when you hit the enter key. The visual information added by this is useful to the user if it is momentary and provides information without them having to change their focus. (overall problem this bug is trying to solve is the always on blue/red/green/yellow icon we currently have). Kev: for Firefox 5 could we potentially ask them to pick a color? In the meantime we can just give all engines the same treatment as the go button when focused.

I'm new here, but I was reading through the bugs and I am really interested in this one. My two cents: While many of the more heavy Firefox users do change search engines often, most of the less technologically inclined people I know use the search bar to really use only one search engine. I do not know that many users who actually use the search bar to switch between, say, Google and Bing--or who even use the search bar for Wikipedia searches. From what I have seen, they click there and just search. I suggest that we keep a minimalist look with no colored favicons and no colored search engine backgrounds. The heavy users of Firefox who, like I, do wish to change search engines on a regular basis can still do so, and I don't think we need the favicon/colors to distinguish. It may make it a little easier, but I would much prefer the proposed lack of color in favor of the current implementation.

I updated my patch to match recent discussion (pinstripe theme only for now). Alex, what do you think? I picked somewhat arbitrary colors for the button, based on the Wikipedia button in your mockup, but we can probably ask Stephen for pretty colors. Also, maybe the button text should be gray when the search field isn't focused. Possibly a darker gray than the non-button text?

I used toolbar button styles for the button. It looks pretty good on OSX and Windows, but I'm not sure what to do about Linux because we haven't updated the theme yet. Stephen, do you have any thoughts about what I should do about that? Do you have gradients/shadows I should use?

Comment on attachment 502688 [details] [diff] [review] wip patch v2 >+ oninput="updateEmptyInput();" This still breaks when selecting the entire non-empty input and then cutting (ctrl/cmd+x or via context menu), but it seems like a small enough edge case. I wish oninput were more reliable. :( >+ if (this._textbox.value == "") >+ this._goContainer.removeAttribute("button"); >+ else >+ this._goContainer.setAttribute("button", "true"); Nit: This works just fine, but I prefer the following: if (this.textbox.value) this._goContainer.setAttribute("button", "true"); else this._goContainer.removeAttribute("button"); > <method name="handleSearchCommand"> > <parameter name="aEvent"/> > <body><![CDATA[ > var textBox = this._textbox; > var textValue = textBox.value; > > var where = "current"; >- if (aEvent && aEvent.originalTarget.getAttribute("anonid") == "search-go-button") { >+ if (aEvent && aEvent.originalTarget.getAttribute("anonid") == "search-go-label") { > if (aEvent.button == 2) > return; The side-effect of this is that clicking the label with empty input results in unexpectedly navigating to the search engine's home page. (In Google's case, it navigates to google.com/firefox .) Since the magnifying glass icon is now a label, this feels a bit more strange. We may want to consider making the label do nothing or focus the text field when it's not in button mode. >- skin/classic/browser/searchbar.css >+* skin/classic/browser/searchbar.css What does the asterisk mean? I've come across this but never knew. >diff --git a/browser/themes/pinstripe/browser/searchbar.css b/browser/themes/pinstripe/browser/searchbar.css Since the search submit button is now more of a button, it is more like the go/reload/stop button but doesn't have a hover state like the go/reload/stop button does on OS X. Not sure if that's intended or not. feedback+ with these addressed :)

(In reply to comment #43) > The side-effect of this is that clicking the label with empty input results in > unexpectedly navigating to the search engine's home page. (In Google's case, it > navigates to google.com/firefox .) Since the magnifying glass icon is now a > label, this feels a bit more strange. We may want to consider making the label > do nothing or focus the text field when it's not in button mode. We should file a change on that searchEngine so that the default is google.com, not google.com/firefox fwiw. Eventually google.com/firefox will be going away.

Comment on attachment 502688 [details] [diff] [review] wip patch v2 IIRC, Faaborg specified that switching the search engine while the input was non-empty should search that engine using the input. This patch doesn't do that. We should confirm which behavior is desired.

(In reply to comment #44) > We should file a change on that searchEngine so that the default is google.com, > not google.com/firefox fwiw. Eventually google.com/firefox will be going away. Bug 624625 filed.

(In reply to comment #43) > >- skin/classic/browser/searchbar.css > >+* skin/classic/browser/searchbar.css > > What does the asterisk mean? I've come across this but never knew. It means the file is pre-processed. I needed to add that because I included shared.inc. > >diff --git a/browser/themes/pinstripe/browser/searchbar.css b/browser/themes/pinstripe/browser/searchbar.css > > Since the search submit button is now more of a button, it is more like the > go/reload/stop button but doesn't have a hover state like the go/reload/stop > button does on OS X. Not sure if that's intended or not. I just copied the toolbar button styles for OSX, which don't have a hover state. > feedback+ with these addressed :) Thanks for your comments! :)

(In reply to comment #43) > > <method name="handleSearchCommand"> > > <parameter name="aEvent"/> > > <body><![CDATA[ > > var textBox = this._textbox; > > var textValue = textBox.value; > > > > var where = "current"; > >- if (aEvent && aEvent.originalTarget.getAttribute("anonid") == "search-go-button") { > >+ if (aEvent && aEvent.originalTarget.getAttribute("anonid") == "search-go-label") { > > if (aEvent.button == 2) > > return; > > The side-effect of this is that clicking the label with empty input results in > unexpectedly navigating to the search engine's home page. (In Google's case, it > navigates to google.com/firefox .) Since the magnifying glass icon is now a > label, this feels a bit more strange. We may want to consider making the label > do nothing or focus the text field when it's not in button mode. I think focusing the text field sounds like a good solution.

>IIRC, Faaborg specified that switching the search engine while the input was >non-empty should search that engine using the input. This patch doesn't do >that. We should confirm which behavior is desired. Yeah, in that case the button should change to the text of the newly selected search engine.

I just asked Faaborg, and I misunderstood him. To clarify, when changing the selected search engine using the dropdown menu, the desired behavior is simply to update the text of the search engine label/button, not immediately open the search results page for that engine. (Terminology is so verbose!)

Comment on attachment 501986 [details] screenshots The buttons don't look like this anymore.

I'm currently updating my XP build to test, but this looks good on Windows 7, OSX, and Linux. I feel like Dão is the right person to review this, but his plate seems really full right now, so I'm also flagging Dolske and Gavin in case they want to step in :)

Comment on attachment 503032 [details] [diff] [review] patch v3 Tested out on Windows and OS X on margaret's machines, and viewed linux screen shots. Only nit was changing the initial default size of the search field.

Comment on attachment 503032 [details] [diff] [review] patch v3 Ugh, this is broken on XP. Clearing the review request until I fix it.

How are users supposed to know that this is the search-go button? I mean aside from sense-memory from using Firefox or IE, how are they supposed to know? Why not put the search magnifier button at the end and move the whole search-engine drop-down to the end a'la IE? Or at the minimum maybe put a text arrow at the end of the search engine name?

Margaret: just spoke to Kev about this, we can go ahead and move forward with using green for all of them, and then specify specific colors for individual engines on a case by case basis later.

Both comment (In reply to comment #39) > >FWIW, I don't think any colour should be used. This is about minimalism and > >removing colour queues from peripheral vision. > > I forgot to add this to the mockup, but the button would desaturate (like the > reload button), when the field isn't focused. The color was just meant as a > very transient peripheral cue of what would happen when you hit the enter key. While I agree that's better than a consistent colour, do we not think that the changing colours might not confuse users? It was green before, and now it's yellow, what does that mean? Feels to me like a solution in search of a problem, and the easier thing to do is use a single colour for all search engines. Also means that if the branding changes we don't have to manage that with a change in our code.

(In reply to comment #58) > Both comment (In reply to comment #39) > While I agree that's better than a consistent colour, do we not think that the > changing colours might not confuse users? It was green before, and now it's > yellow, what does that mean? This is predicated upon the assumption that users actually change search engines. Do we have some data on this? Anecdotal example: My mom doesn't. So this wouldn't be a problem for her. So for the (I'm guessing) minority of users who actually do know what a search engine is and how to change it in Firefox, would the colour highlight help them? I'm not sure either way. I don't like that this feels like fashion for the sake of fashion. But generally this is such a minor issue that either solution would work out fine.

No, I don't see how this is predicated on that at all. Separate issues, IMO. We need to make it easier for users to customize and switch between search engines (Fennec does a better job there than we do!) but the question of whether or not we think users will discern branding from a single colour as opposed to ascribing some deeper meaning is orthogonal.

Good point. Backwards looking vs. forward (How the users act now due to okay UI vs. How we want to them act). Granted, there is minimal difference between the current UI and these proposed iterative changes, thus the predication. Overall, does the (proportional) cost of confusion outweigh the gains from an peripheral-vision aid? (Both are hypothetically perceived.) Upon re-read, the original thinking behind the colour branding is to "avoid any potential mode errors (ux-mode-error)." A solution in search of a problem? User confusion: initially yes. With any change comes confusion.

The problem here is ux-mode-error, reallt common after changing the engine since it isn't spring loaded. Also we want these colors for changes to the location bar later, but that's a broader discussion.

But if you look at users who *do* know how to use the search bar, wouldn't they be confused by any coloration? Historically, colors in the search-engine-button indicate that there is a search engine plugin available to add. In 4.0 that was completely removed. Wasn't the whole point of giving a background color to somehow remind the user of the colors of a specific search engine? If the background color isn't going to relate to a specific search engine then is there any point in having a color there at all?

>But if you look at users who *do* know how to use the search bar mode errors aren't about knowing how to use something, they are about being able to maintain state of something in your head for long periods of time successfully. For instance, even people who have added a large number of additional search engines will experience mode errors as they intend to search google, and then actually send the search off to one of the other engines. That said, we can't easily address the mode error problem until search engines give us permission to use a strong brand color. In the meantime we are just going for internal consistency with how the location bar (go/stop/reload) is designed, with stronger styling on hover and focus.

Just my 2 cents to say that if you're going to implement ellipses with the search engines names, how would I recognize something like WordReference's different translators? they are named: "WR English-French" and "WR English-Spanish" etc... (and the icon it's exactly the same too) just saying.

I updated this patch to use the green go-button styles, as per Faaborg's request. I pushed it to the UX branch [1], so you can test it out there. I think we should live with this for a little while to make sure it's what we want before getting it reviewed to land on mozilla-central. [1] http://hg.mozilla.org/projects/ux/rev/a306604e70ef

am I doing wrong if I ask here that maybe could be better to scroll between search engines with mouse wheel without pressing Ctrl key?

(In reply to comment #67) > am I doing wrong if I ask here that maybe could be better to scroll between > search engines with mouse wheel without pressing Ctrl key? That is out of scope for this bug. However, you can file a new bug on that issue, and discussion about it can take place there.

I have a few issues with the test build: 1. I liked the icon better because it gave a quick visual clue which engine was selected. Now I have to always reread the whole text on the right-hand side. 2. The ellipsis looks stupid. For example my Wolfram Alpha search engine is displayed constantly as "Wolfram|Al..." which completely sucks. Especially in the unfocused state there is a lot of free space and it hurts to have this text cut off unnecessarily. Maybe I'm too much a perfectionist, but I don't want to have an ellipsis in the main browser window all the time. 3. When entering text in the search bar the engine name text changes from italic to plain text rendering. This doesn't make sense and gives the impression that the text has changed. 4. Black text on dark green background (when selected) is not very readable. 5. The black text on the green background doesn't look like a button, especially not like a go button. Of course you can simply hit enter, but why bother making a button there if it doesn't look like an and probably no one will use it? 6. There is another issue that feels bad. Without the icon it's harder to see at one glance where the url bar end and the search bar begins. With the icon you had an easy location to aim your mouse at, now you roughly have to aim at a location "somewhere on the right on this white bar in the light blue background", which feels way more complex, at least for me and my brain. Additionally you now have to locate the light gray text with your eyes and read it (see issue 1).

(In reply to comment #69) Here are some tips for interacting more effectively in Bugzilla: > 1. I liked the icon better because it gave a quick visual clue which engine > was selected. Now I have to always reread the whole text on the right-hand > side. This is a fine response. The like isn't nearly as important as the "why" but certainly not a problem. You included both and that's fine. > 2. The ellipsis looks stupid. For example my Wolfram Alpha search engine is > displayed constantly as "Wolfram|Al..." which completely sucks. Especially > in the unfocused state there is a lot of free space and it hurts to have > this text cut off unnecessarily. Maybe I'm too much a perfectionist, but I > don't want to have an ellipsis in the main browser window all the time. Saying that something looks stupid or sucks is not helpful. It's really no different than saying "I don't like it." On occasion, I will say that something looks "smart" or "I like it a lot", and while that doesn't add a lot of value, it also doesn't open new and unclear questions nor does it insult the work of others with any real actionable criticism. > 3. When entering text in the search bar the engine name text changes from > italic to plain text rendering. This doesn't make sense and gives the > impression that the text has changed. What doesn't make sense about it? The engine name text doesn't really change, does it? The text goes away, right? > 4. Black text on dark green background (when selected) is not very readable. Not very readable compared to what? Readable during what action? Directly or peripherally? Most designs have something of a visual hierarchy and not all elements of design are necessarily supposed to be equally readable (less they become distracting for other unrelated tasks.) It would probably be more helpful if you described what it was you were trying to do when you found the readability problem. > 5. The black text on the green background doesn't look like a button, > especially not like a go button. Of course you can simply hit enter, but why > bother making a button there if it doesn't look like an and probably no one > will use it? What does a button look like? Which button should it look more like? Do you have some reason, other than your guess, to assert that "probably no one will use it"? Providing more information with these kinds of criticisms can help to move them from a "I don't like it" discussion to a "here are some things that could improve it" discussion -- which is almost always more productive. > 6. There is another issue that feels bad. Without the icon it's harder to > see at one glance where the url bar end and the search bar begins. With the > icon you had an easy location to aim your mouse at, now you roughly have to > aim at a location "somewhere on the right on this white bar in the light > blue background", which feels way more complex, at least for me and my > brain. Additionally you now have to locate the light gray text with your > eyes and read it (see issue 1). This is a much more complete criticism. You explained what it was you were trying to accomplish when you encountered the problem and specifics of the difficulty. More like this is good. Less like your issue 2 is good. Thanks for the feedback.

the previous two (hidden) comments were mine and were identical to comment 72 but had horribly broken linebreaks that caused page formatting and scrolling problems.

(In reply to comment #72) > Saying that something looks stupid or sucks is not helpful. It's really no > different than saying "I don't like it." On occasion, I will say that > something looks "smart" or "I like it a lot", and while that doesn't add a > lot of value, it also doesn't open new and unclear questions nor does it > insult the work of others with any real actionable criticism. Sorry for my bad language. I'm not native english and I sometimes find it difficult to find the right words. What I don't like is to have a text cut off, that doesn't need to be cut off. See issue 1 and 5. We now have to read the engine name nearly every time we want to search something because we can't be sure that the right engine is selected. This is badly enough, but it's much worse, if the engine name you read every time isn't complete. It's just disturbing because I want to search something in "Wolfram|Alpha", not "Wolfram|Al..." and it's more disturbing because there is enough space to display the complete text, so you might question yourself if the browser is broken or something. All that draws you away from the task you wanted to do, namely searching something. > What doesn't make sense about it? The engine name text doesn't really > change, does it? The text goes away, right? The engine name text doesn't change, but it looks like it changes because the text changes from italic to normal, so there is a small difference in character spacing and visual appearance. > > 4. Black text on dark green background (when selected) is not very readable. > > Not very readable compared to what? Readable during what action? Directly or > peripherally? Most designs have something of a visual hierarchy and not all > elements of design are necessarily supposed to be equally readable (less > they become distracting for other unrelated tasks.) It would probably be > more helpful if you described what it was you were trying to do when you > found the readability problem. This problem is probably not very important and will probably fixed if the other issues are resolved, but if I select the search bar and enter some text the engine name gets a green background and a black text. Because of the issue above and the color change I sometimes "want" to read the text again (because it looks like it may have changed), which I think is more difficult with black text on a rather dark green background. > > 5. The black text on the green background doesn't look like a button, > > especially not like a go button. Of course you can simply hit enter, but why > > bother making a button there if it doesn't look like an and probably no one > > will use it? > > What does a button look like? Which button should it look more like? Do you > have some reason, other than your guess, to assert that "probably no one > will use it"? Providing more information with these kinds of criticisms can > help to move them from a "I don't like it" discussion to a "here are some > things that could improve it" discussion -- which is almost always more > productive. A button looks like a button, if it has a "strong" icon or a raised appearance. The url bar go button looks mainly like a button because of the arrow, not because of the green color. (At least in my point of view). The green area at the end of the search bar has no icon, it just consists of text. It looks more similar to the identity box than a button. Of course you can click the identity box, but you wouldn't expect some real action from clicking it, it just displays security information. For the text on the right of the search bar, it's not clear what happens, if you click it. It could start the search, it could take you to the home page of the search engine, it could display information about the search engine. A "go arrow" or a magnifier icon would be more intuitive to use.

Kudos for Haas. The current implementation IMHO introduce more problems than the original, surely need an improvement, like more intelligent ellipses and need to resemble more to the attachment 500550 [details]. In every case, expect an avalanche of addons that reintroduce the favicon :)

Search Magnifying Glass looks superfluous. Engine choices by clicking on his name is more intuitive, IMHO. No arrows, no loops, only the text box and the name of the engine.

(In reply to comment #76) > Search Magnifying Glass looks superfluous. Engine choices by clicking on his > name is more intuitive, IMHO. > No arrows, no loops, only the text box and the name of the engine. Then you can't use the engine name as "go button". Additionally, I don't think this looks very intuitive. A drop down arrow to choose the engines actually makes sense so I don't see the reason why you removed it. As said above it's not clear from looking at it what clicking on the green area does. It may search, it may go to the home page of the engine, it may display information about the engine and in your design it may even choose the engine. It's not clear and in my option doesn't make sense.

(In reply to comment #78) > Then you can't use the engine name as "go button". > > Additionally, I don't think this looks very intuitive. A drop down arrow to > choose the engines actually makes sense so I don't see the reason why you > removed it. As said above it's not clear from looking at it what clicking on > the green area does. It may search, it may go to the home page of the > engine, it may display information about the engine and in your design it > may even choose the engine. It's not clear and in my option doesn't make > sense. Sounds reasonable. But will you agree that there is no place for the magnifying glass in this appearance?

I don't mind the look when the field is empty as it looks clean and goes with the style of the rest of the navigation bar. Not a fan of the huge button at the end because it lessens the space available for readable text. I can deal with whatever is implemented, though. It looks as intended on Windows 7, but I have noticed an issue with my Nightly-UX on my desktop at work which runs Windows XP, which really bugs me. There are always three side-by-side magnifying glasses of varying shades of color when there should only, obviously, be one. I haven't really had time to test it on a fresh profile; I will tomorrow first thing before I get slammed with work.

When I first read through this thread, I'll admit the new concept didn't seem good, but after experimenting with it a little, it grew on me. Here are a few (mostly small) things I've noticed: 1. Agreed with Haas that black on darkish green is not an ideal color. The go button and identity block both use a shade of green on green, and maybe this color scheme should emulate that. 2. When text is typed in the search bar and then unfocused, the search button on the right has a slight upper shadow that is jarring compared to the rest of the field. Perhaps that style should mimic the style of the reload button, without the shadow. 3. I will also agree that it is not immediately obvious the search engine name can be clicked on in order to search. I'm not sure what should or can be done about this. A main problem I believe is that users might not expect the actual search button to have its text change depending on the selected engine. However, one thing that I know seems out of place for me is the fact that the button only becomes a button after text is typed in. This involves a lot of action on the search bar, including the italic to normal font change. Maybe this was done so that the user has more room to click in order to focus the search. On my screen it's not a huge deal, but it may be more of a concern on small devices; you guys would know more about that than me. Nonetheless, my opinion is that we should keep the button a button always whenever possible. Note that this allows a shortcut to the home page of the search engine, and also might help clarify bug 664106 (or maybe that is an entirely different situation from a UX standpoint). Hope these comments help. I'll be hanging around to see how this moves forward. Good progress so far.

This is the issue I mentioned in comment 80 with the magnifying glasses.

Comment on attachment 542177 [details] Search bar shows three magnifying glasses when using Windows XP yep, that's pretty broken, thanks for catching it.

just my 2 cents: I have a suggestion, you can see how it looks like in the attachements. (One attachement shows the whole window and the other one shows the various states) - on the left there is a dropdown-button with the name of the current search engine - the dropdown-button has the same style as the new identity block on Firefox6 and higher - it has an arrow on the right next to the name, which has the same style as the arrow in the address bar - in the middle is the text "Search" instead of the name of search engine, independed of the current search engine - on the right side there is the magnifying icon, which has the same style as the "reload"-button on the address bar (normal state) - the magnifying icon is green on hover and pressed state, like the "go"-button on the address bar (it doesn't have to be green, that's only a suggestion, maybe the color of the search engine?) the benefits: - the user always sees which search-engine is selected - the text "Search" and the magnifying icon show clearly that the user can search the web - the user sees clearly that the magnifying icon can be pressed to start a search - the style matches with the style of the address bar and the rest of browser - it hasn't too many different colors on the interface - it hasn't any complex icons For me this is the best solution. It looks clean and it is easy to use. That was my idea, I hope it does any good. What do you think?

wow, I was like "now I propose my idea for a search bar" but I just read Jukens proposal and were very similiar to mine, but 10 times better and more accurate. Those are more than just 2 cents :)

(In reply to comment #85) > Created attachment 545700 [details] > searchbar states, for more information see comment 86 This doesn't fit the whole idea of colorizing the button, as it was mentioned here (http://areweprettyyet.com/5/searchBar/# ), quote: > The user's low resolution peripheral still picks up the color of the button, so > they know which search engine they are about to use when they hit enter, even > without having to move their gaze and read the text using their high resolution > fovea. - Colorizing only a hovered/active state of the button is useless. - in your case the search button is way narrower then a button that opens a drop-down list of installed search engines.I think that people hit search button more often then the button that switches engines, the popularity of the button should affect it's width. - I don't like the idea suggested by someone here, that favicon should get hidden. Why? It's tiny enough not to bring the visual noise to the browser's whole appearance.

Margaret, I'd like to argue about your proposal to remove the favicon: > The favicons in the search field are creating a significant amount of visual > complexity in our product. They are using a wide range of colors, and they > reduce the relative discoverability of nearby controls like reload and stop. Their wide range of colors is actually their advantage, as those colors are not just drawn randomly: they form the icon itself, and the icons are easier to recognize. While you fairly noted that they reduce the discoverability of the nearby controls I think you propose a wrong solution of that problem: instead of removing the icon, why not just move it away from those controls? Just move the favicon to the right part of the quick search bar! Could you please personally comment my idea? Removing is easier then restoring, and if you completely remove the favicon from there (not with just a style like "display: none") then it will be harder for me to restore it myself.

(In reply to comment #89) > instead of removing the icon, why not just move it away from those controls? > Just move the favicon to the right part of the quick search bar! I disagree. As I have written above, i think the favicon is also important to see the border between the urlbar and the searchbar or to have a location to aim your mouse at when clicking in the search bar to enter text. Additionally, for left-to-right text, it makes sense to have the favicon as near to the text as possible because then you can see both at the same time when you start to enter text instead of having to look at both ends of the search bar. You write the favicon reduces the relative discoverability of nearby controls like reload and stop. I agree. But I really think this is not the problem of the favicon but of these controls. First they look very unusual there at the end of the urlbar, secondly they are completely unimportant to me. If I want to "go", i hit enter, if I want to reload, i hit F5 or click in the urlbar and hit enter. I think we should leave these buttons as unimportant and undiscoverable as they are and maybe show new users that they can just hit enter. And stopping/reloading is not a really important task, you do it mainly when sites don't load properly and they often don't help, so I don't think we need to make them more discoverable.

Margaret: button needs to activate as soon as the field has focus (or the user changes the engine). Also, let's try out the dominant color algorithm for each button's color.

I've noticed all around the web that the magnifying glass icon is becoming the default choice for the button that start the search in a searchbar. why change the de facto paradigm (used in old Fx as well) ? You can style with the dominant color algorithm the Jukens button that change the search engines, instead of colouring the new, counterintuitive, difficult to style "search" button. This option mantain the periferical view color thing but don't introduce strange/new search behaviours.

(In reply to comment #87) > wow, I was like "now I propose my idea for a search bar" but I just read > Jukens proposal and were very similiar to mine, but 10 times better and more > accurate. > Those are more than just 2 cents :) thank you very much for your feedback :) I did not think that anyone would write something like this. > You can style with the dominant color algorithm the Jukens button that change the search > engines, instead of colouring the new, counterintuitive, difficult to style "search" button. Good idea, this makes more sense instead of colouring the "search" button. Your arguments are not bad.

here is a little update of my suggestion: the "magnifying glass" button is coloured with dominant color algorithm so all requirements are met with my suggestion now

I dislike the new style proposed by mozilla :( IMO, this are the disadvantages: - The magnifying glass icon as a button to start the search is missing. (The magnifying glass icon is the standard button to start a search in most applications, like vfede already wrote in comment 92.) - IMO it is better when the text is flush left instead of right. - The user doesn't know what the colourised button causes. - It isn't mentioned anywhere that the user can "search". - The user will get difficult to get used with the new style, because it is a big change. I already wrote my idea in comment 86 and comment 94. The current version is on comment 94. I have invested a couple of hours time and I found nothing better then my current suggestion. This is just my opinion, what do you think mozilla team? What is your opinion? And I'm sorry for eventual disturbing.

>What is your opinion? that search engines have become verbs, and the name of the engine itself is more recognizable than a vague metaphor to a physical artifact that few people have actually encountered in the real world. The names of the engines are also more descriptive than their favicons. For instance ebay actually tries to write "ebay" in 16x16, which is kind of ridiculous.

(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #96) > >What is your opinion? > > that search engines have become verbs, and the name of the engine itself is > more recognizable than a vague metaphor to a physical artifact that few > people have actually encountered in the real world. The names of the > engines are also more descriptive than their favicons. For instance ebay > actually tries to write "ebay" in 16x16, which is kind of ridiculous. ah, ok thx :) I didn't know the stuff with ebay, interesting. I agree with your opinion, I think the same. My suggestion is based on text instead of icons too. IMO, the suggestion of mozilla is not solve clever, like I already wrote in comment 95. So I posted my idea. It shows another possible solution for the new searchbar. So what do you think about my idea? Can you use anything from it? I only want to get feedback ;) (I got very positive feedback from one user, see comment 87) thx in advance

(In reply to Jukens from comment #97) > So what do you think about my idea? Can you use anything from it? I only > want to get feedback ;) I think the idea in general is interesting but I see a few issues: 1) I think looking at icons still easier than reading text for determining if the right engine is selected. 2) I'm not complete sure how the dominant color algorithm should work and if it's always possible to find good colors, for example for search engine providers that use multiple colors in their color scheme or their logo. 3) I think there is a high probability that multiple search engines get the same color, compared to the chance that multiple engines have a very similar logo. 4) It's probably difficult to make the magnifier icon look good on all these different colors. For example I think it looks really bad at the magenta yahoo background in your screenshot. 5) Text needs more space than the old icon. 6) I'm not sure how you would handle long engine names. Using an ellipsis would probably be annoying as I have explained in comment 69, but showing the complete text every time is obviously a bad idea, too.

> I think the idea in general is interesting but I see a few issues: Thank you very much :) > 1) I think looking at icons still easier than reading text for determining > if the right engine is selected. Ok, everyone has their own opinion. I think about 50% are for icons and other 50% for text. It's difficult to say what is better. Both have their advantages and disadvantages. For me the favorite is text. > 2) I'm not complete sure how the dominant color algorithm should work and if > it's always possible to find good colors, for example for search engine > providers that use multiple colors in their color scheme or their logo. Yes, I agree. But the sense of the dominant color algorithm is to find a color that most matches. I think the implementation on the Windows 7 taskbar with a dominant color algorithm works very nice, so I am optimistic about mozilla's implementation. > 3) I think there is a high probability that multiple search engines get the > same color, compared to the chance that multiple engines have a very similar > logo. Yes, I agree. But I don't think that anytime it would find the exactly same color. There were small differences between the colors. > 4) It's probably difficult to make the magnifier icon look good on all these > different colors. For example I think it looks really bad at the magenta > yahoo background in your screenshot. Yes, I noticed it too ;) But my "screenshots" are not the best quality. I propose that the magnifying glass icon has a brighter color on darker backgrounds. > 5) Text needs more space than the old icon. > 6) I'm not sure how you would handle long engine names. Using an ellipsis > would probably be annoying as I have explained in comment 69, but showing > the complete text every time is obviously a bad idea, too. Yes, I noticed it too. Maybe the name can stand in short form when the searchbar is inactive. When it is active then the whole name is displayed. I think today many people have a widescreen, so the searchbar could be wider by default. I also think my suggestion has enough space for long search texts. (about 20 characters are definitely no problem) I think Opera has the best solution at the moment. e.g. Opera writes "search using Google" instead of only "Google", which is more meaningful. Are there any plans to change the current proposal of mozilla, or mozilla wants definitely to land it? (I found many comments here of people who are not happy with the proposal of mozilla.)

IMHO the Mozilla's proposal was great only on paper and on "areweprettyyet". In the field it is really forcing many many things and imho breaking them up. I disagree with "the name of the engine itself is more recognizable than a vague metaphor to a physical artifact that few people have actually encountered in the real world" in comment 96: The "floppy disk save icon", although is an awful depiction of "saving action", is recognized as a "save icon" by people that never saw a floppy disk. We can talk for ages about how wrong this is, but it is the standard save icon for the people. The "magnifying glass icon" is even more familiar on the web: Google uses it, Google has 90% market share, 90% of people know what that means. And I use the Google example just as an example, nothing more. Even Firefox used that icon so far :) Surely the name of the WebSite (it is not always the name of a Search Engine) is "more recognizable" than the website icon, but it's surely not "more recongizible" than the magnifying glass as the "search" Action. In the current implementation of this bug the magnifying glass is used for the drop down menu that select a different search engine. Now, how the "magnifying glass" icon concept could be associated to this action (changing engine) better than to the "search action" ? I really don't see it. I hope the great discussion on this bug can produce a really good and "streamlined" search bar :)

FYI,I do 90% of my(mouse)searches with multiple search engines in the Search Box, rarely use the ABar. The idea that the Name is more recognizable than the Icon is just plain ludicrous. Remove the name sure, that's what I've done, looks real clean. Remove the icon !.......what are you guys smoking? In all honesty if Chrome had a separate versatile search box like the current Fx's I'd seriously consider using it.

One thing that concerns me about this is custom search plugins. How will custom plugins, which often have to resort to rather long descriptive names, be handled? As an example, I use a plugin called "Google Images Classic" but there are many with even longer descriptive names. If an ellipsis system is used, how would it know where to cut off the name? Authors of custom search plugins often use custom favicons to help distinguish them from the normal search. My Classic Google Images search for instance uses the old boxy Google Images icon that makes it immediately obvious that is is both Google Images, and the older version. If it is shortened to "Google..." then there is no distinction.

(In reply to patrickjdempsey from comment #102) Already noticed that, some engines like WordReference EN>FR (translator) have the important part of the name at the end. Ellipsis is murderer :)

Wait a minute. Humor me when I now argue just to keep the search field unchanged. No formal UX experience here, so take from this what you will. The problem as I see it seems to be that Google's favicon is too colorful. The argument is that this is inconsistent with the minimalist design, and that it makes the stop button less discoverable presumably when it turns red. Sure, this is annoying, but if we take a step back we'll see there are very good reasons behind this design. We should agree that the search bar needs to have a constant reminder of the selected provider. This can't be a button, as in Faaborg's proposal, because then the button for search is neither a recognizable "search" image nor a verb. Where should this reminder be? It is minimalism to group it together with the provider selection. In LTR languages this should be to the left of the search query, since the user's normal workflow should be selecting the provider before entering the query. If this is done, there is no reason to give the search button on the right separate (dominant) colors; that would seem to be contrary to minimalism and may even cause mode errors. This brings me to Jukens's suggestion to replace the favicon with the name of the provider. People have argued this is a bad idea because of ellipses, which I won't repeat in any more detail. People have also been recently arguing it is a good idea because the name may be more recognizable than an icon. Perhaps, but why do we even want the provider to be that recognizable? When the search field is empty, the italicized placeholder text serves that purpose. During frequent usage, we should want the user to focus on the query and use the icon merely as a subtle reminder of the provider. Replacing the provider by its text name, especially when it comes before the query, forces the user to read the provider name, detracting focus from the query. Therefore, in my view, the current setup is the most user friendly out of all the current proposals. An added bonus is that, in my opinion, it also looks better. I love a lot of what has been done with the FF UI so far, but I think it's important to not by accident improve one area at a possibly bigger expense in another. P.S. To give credit where it is due, I've been influenced a lot by Haas's posts.

(In reply to Teddy Ni from comment #104) > Wait a minute. Humor me when I now argue just to keep the search field > unchanged. No formal UX experience here, so take from this what you will. > > The problem as I see it seems to be that Google's favicon is too colorful. > The argument is that this is inconsistent with the minimalist design, and > that it makes the stop button less discoverable presumably when it turns > red. Sure, this is annoying, but if we take a step back we'll see there are > very good reasons behind this design. > > We should agree that the search bar needs to have a constant reminder of the > selected provider. This can't be a button, as in Faaborg's proposal, because > then the button for search is neither a recognizable "search" image nor a > verb. > > Where should this reminder be? It is minimalism to group it together with > the provider selection. In LTR languages this should be to the left of the > search query, since the user's normal workflow should be selecting the > provider before entering the query. > > If this is done, there is no reason to give the search button on the right > separate (dominant) colors; that would seem to be contrary to minimalism and > may even cause mode errors. > > This brings me to Jukens's suggestion to replace the favicon with the name > of the provider. People have argued this is a bad idea because of ellipses, > which I won't repeat in any more detail. People have also been recently > arguing it is a good idea because the name may be more recognizable than an > icon. > > Perhaps, but why do we even want the provider to be that recognizable? When > the search field is empty, the italicized placeholder text serves that > purpose. During frequent usage, we should want the user to focus on the > query and use the icon merely as a subtle reminder of the provider. > Replacing the provider by its text name, especially when it comes before the > query, forces the user to read the provider name, detracting focus from the > query. > > Therefore, in my view, the current setup is the most user friendly out of > all the current proposals. An added bonus is that, in my opinion, it also > looks better. I love a lot of what has been done with the FF UI so far, but > I think it's important to not by accident improve one area at a possibly > bigger expense in another. > > > P.S. To give credit where it is due, I've been influenced a lot by Haas's > posts. wow, your arguments are very interesting and brought to the point. I also think that the current implementation of the searchbar is not bad. But if it stays that way, the design must change, so that it matches with the rest of the browser UI: - The magnifying glass icon should be gray like the other icons. - The magnifying glass icon should have the same style on all windows themes. (the other buttons look the same on every theme) - It would be nice if the icon of the search engine would have the same style like the new identity block on Firefox 6 and higher. (like my suggestion, but icons instead of text) My opinion is: make a better suggestion then the current OR the searchbar stays like now (with little style improvements)

I updated this patch to use colors for the search engines that have provided colors over in bug 634140, and I can add more colors as the other search engines respond. I just added these colors in the CSS files, but I could imagine extending the search service to include a search button color in the future, so that non-default engines can specify their own colors. I based the styles off Stephen's mockup: http://people.mozilla.com/~shorlander/searchEngineButton/search-button-color.html I landed this on the UX branch, so you should be able to test it out there tomorrow: https://hg.mozilla.org/projects/ux/rev/096640bd3d3d

Comment on attachment 553965 [details] [diff] [review] patch with colors Before we push this further, I think we need to address at least the usability issue that truncating search engine names can make them useless, as some people have pointed out. (This is off the top of my head. I didn't reread the comments, there may still be other outstanding issues.) We should also take a closer look at whether we can just make the icon grayscale until you hover the icon or focus the search field. People do this all the time on the web and I'm not sure why google and Co. would be stricter with us.

Why can't we just display full name and when typing, the typed text will simply overlay the search engine text?

Mozilla, why do you want to change the way the current standard of how searchbars look like? About 90% of all applications and websites use the magnifying glass icon as the standard button to start a search. It doesn't make any sense to change the current, "good" searchbar. I didn't see anywhere that a button with the name of a searchengine starts a search. And I don't see any benefits in the "new" searchbar. It is also tiring to ask each vendor for a desired color. It does not bring benefits at all. Look at the other browsers, they have easy andstraightforward searchbars. So why so complicated? Look at comment 100, there it has very good arguments. And the most important sentence for me is: > I hope the great discussion on this bug can produce a really good and "streamlined" search bar :) I hope it too. So think about it. There any many ideas. All ideas have their good sides and their bad sides. When you combine some things together, then a good searchbar can arise. As I already said before: MY opinion is: make a better suggestion then the current OR the searchbar stays like now (with little style improvements)

(In reply to Jonathan Haas from comment #78) > (In reply to comment #76) > > Search Magnifying Glass looks superfluous. Engine choices by clicking on his > > name is more intuitive, IMHO. > > No arrows, no loops, only the text box and the name of the engine. > > Then you can't use the engine name as "go button". > > Additionally, I don't think this looks very intuitive. A drop down arrow to > choose the engines actually makes sense so I don't see the reason why you > removed it. As said above it's not clear from looking at it what clicking on > the green area does. It may search, it may go to the home page of the > engine, it may display information about the engine and in your design it > may even choose the engine. It's not clear and in my option doesn't make > sense. And I still think that the loop is an anachronism. It seems foreign in the new design. In the back/forward button you have removed the arrow drop-down menu to simplify the interface. Here may be the same way: drop-down menu appears when right-click on button, or click and hold. And about truncating search engine names: Why can not I change the size of the button with the name of a search engine? Automatic resizing of button and the length of the search fields (depending on the length of the request) may be the solution.

I updated my searchbar suggestion and implemented it. I uploaded my "omni.jar" file to my hoster, because It was too big for Bugzilla. This is the download-link: http://juri790.kilu.de/omni.jar facts: - The search button has the same custom colors as mozilla uses in the nightly-ux build. - The search button has a lighter magnifying glass when the background is dark. - The minimum width of the searchbar is 240px, like described in http://areweprettyyet.com/5/searchBar/. - It has enough space for search engines with long names. (the size of the dropdown button changes) - In some rare cases the height of the searchbar and the height of the buttons is higher than the height of the addressbar. I can't reproduce it. (safe mode fixes this issue) - This implementation ("omni.jar" file) only works with Firefox 6.0.1 (en-US, Windows). changed files: modified: omni.jar\chrome\browser\content\browser\search\search.xml modified: omni.jar\chrome\browser\skin\classic\aero\browser\searchbar.css modified: omni.jar\chrome\browser\skin\classic\browser\searchbar.css modified: omni.jar\chrome\toolkit\skin\classic\aero\global\icons\Search-glass.png modified: omni.jar\chrome\toolkit\skin\classic\global\icons\Search-glass.png added: omni.jar\chrome\toolkit\skin\classic\aero\global\icons\Search-glass-light.png added: omni.jar\chrome\toolkit\skin\classic\global\icons\Search-glass-light.png how to test it: 1. Backup your current "omni.jar" in the Firefox program folder: rename the "omni.jar" file to "omni_backup.jar". 2. Put my "omni.jar" file in the Firefox program folder. 3. start Firefox how to undo changes: 1. close Firefox 2. Remove my "omni.jar". 3. Rename "omni_backup.jar" to "omni.jar". Have fun with my searchbar :) I'm looking forward to get feedback.

I updated my implementation for Firefox 6.0.2. This is the download-link: http://juri790.kilu.de/omni.jar This implementation ("omni.jar" file) only works with Firefox 6.0.2 (en-US, Windows) For more information see previous comment 111.

This is my suggestion in action as a "webm" screencast, sorry for bad quality.

Fix the "glowing" borders of the magnifier on dark backgrounds (like yahoo and ebay), make it an extension and please stop posting it here, this is not the right place for this (btw it's a great work as I already said before). You can continue the discussion for your implementation in the mozillazine users community :) see you there.

(In reply to vfede from comment #114) > make it an extension and please stop posting it here I don't know how to make an extension. I have not understood the instructions :( > this is not the right place for this OK, I'm sorry, I will not post anymore. > btw it's a great work as I already said before Thank you very much :) > You can continue the discussion for your implementation in the mozillazine > users community :) see you there. Is there a topic about this bug? If not where can I discuss? BTW @mozilla: amazon has pages for other countries, which are icluded as search-plugin depending on the language: amazon.ca,amazon.cn,amazon.fr,amazon.de,amazon.it,amazon.jp,amazon.co.uk so the searchengine name is not always "amazon.com". The other engines should be coloured too.

Is this still in development? The button saying "Google" should have blue box shadow on hover instead of the gray thing used now (on UX, Windows 7)

Comment on attachment 553965 [details] [diff] [review] patch with colors ready to land when we have the color for google. Side comment: what happened to the matching button appearance for stop and reload in the location bar? Those switched at some point on UX branch to glowing glyphs. regardling the user's customized search engines having similar text, they probably also had similar icons. But we could display the keyword name in the button (user controlled), as well as the selection. That would be a follow up bug.

This bug's has broken. I think that Google should be green and Twitter should be blue. And why does random sites have to be white? Can we use this method: http://blog.margaretleibovic.com/post/6356312141/dominant-favicon-color to color the button from its favicon? And the drop down arrow should be styled like the one in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=684450

(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #117) > Side comment: what > happened to the matching button appearance for stop and reload in the > location bar? Those switched at some point on UX branch to glowing glyphs. That's bug 684450, which is now on mozilla-central.

Please remove the magnifying glass with an arrow from the design. In this form the design beaten out of the total appearance of the browser. Move the arrow to select the search engine at the right edge of the panel or even unite with the search button, making the menu-button.

If control elements moved to the right, then you can combine the searchbar with the urlbar. This is a continuation of the idea with the back-button.

Has this project been abandoned ? The patch was almost finished.

Unassigning myself, since I'm not working on this anymore. I don't think we ever figured out how to deal with some of the edge-case design problems with this bug, so I think it needs some more design help before an engineer can finish the patch.

New colors on last Shorlander mockup : http://people.mozilla.com/~shorlander/searchEngineButton/search-button-color.html

(In reply to Margaret Leibovic [:margaret] from comment #123) > Unassigning myself, since I'm not working on this anymore. > > I don't think we ever figured out how to deal with some of the edge-case > design problems with this bug, so I think it needs some more design help > before an engineer can finish the patch. I'm kind of late on this, but can you detail and summarize the design problems so someone working on user experience can fix it quickly and easily?

It's been a long time since I've worked on this. Someone from the UX team should chime in here to decide what should happen with this bug.

I understand that this is a bit late in the process, but I've been thinking about this area for a while and figured I'd add my 2 cents. Being less than fond of anything that takes up space in the UI, I always remove the search bar completely - but I've been working on an idea that could make it compact enough for me to actually use it. http://geeksbynature.dk/ux/compactsearch/demo.html The demo isn't complete, in that it doesn't include a way to change the search provider, but it should illustrate the basic idea.

I don't see why that would be useful. My screen is about 1650px wide and in your demo most of the space is unnecessarily used by the url bar. I prefer the current layout because the click (touch) area for the search bar is larger and there is no dynamic resizing or other potentially annoying stuff. Remember that the goal is to reduce visual complexity, but having dynamic resizes and different states for the control (reduced, expanded, ...) are actually making this thing more complex in my opinion. If you have a really small screen your layout might be useful, but in general I don't think it is.

(In reply to Christian Sonne [:cers] from comment #127) > I understand that this is a bit late in the process, but I've been thinking > about this area for a while and figured I'd add my 2 cents. > > Being less than fond of anything that takes up space in the UI, I always > remove the search bar completely - but I've been working on an idea that > could make it compact enough for me to actually use it. > > http://geeksbynature.dk/ux/compactsearch/demo.html > > The demo isn't complete, in that it doesn't include a way to change the > search provider, but it should illustrate the basic idea. I think this could be considered by the UX team. The work on streamlining the search field is probably still wanted though.

Is this still relevant with the new search UI ? Same for bug 675753. What could be interesting is implementing that submit button, so users can easily where they're going, at first sight. And that would also fix the issue where 2 search engines would have the same icons.

(In reply to Tim Nguyen [:ntim] from comment #130) > Is this still relevant with the new search UI ? Same for bug 675753. > > What could be interesting is implementing that submit button, so users can > easily where they're going, at first sight. And that would also fix the > issue where 2 search engines would have the same icons. I think most of the issues here aren't applicable anymore with the new search UI. Stephen is working on a solution for the visibility problem in a different bug (which I can't find at the moment). The solution presented here has some pretty severe scaling issues.