The search box in the header looks broken



Mozilla Developer Network
4 years ago
4 years ago


(Reporter: Jeremie, Unassigned)



(Whiteboard: [needs UX])


(4 attachments)



4 years ago
Created attachment 810506 [details]
The issue

As the search box is not visible and the light blue box surrounding the search icon is not balance it looks like the search box is broken.

It's not obvious to know that it will open on mouse hover or on focus

It would help the user to figure it's a collapsable element with a little icon improvement (for example with an arrow on the left) to make clearer there is a specific behavior here.

Comment 1

4 years ago
Created attachment 810507 [details]
Enhancement proposal

Here is a proposal to enhance the discoverability and the predictability of the feature.
I like this idea.  I have made things better but I'll keep this around as an idea.


4 years ago
Duplicate of this bug: 922937

Comment 4

4 years ago
this has been reported as a UX issue in several bugs, and also through conversations with users. We should address this.
Whiteboard: [needs UX]


4 years ago
Blocks: 925144
No longer blocks: 910513

Comment 5

4 years ago
Is this still an issue? I took a look at what David has implemented right now and like how it functions and looks. We need to consider that in the navigation we still need to save room for the developer program link once that content is available.
Ali?  Can you have a look here and let me know what is to be done?
This issue could be a good candidate for an A/B test, assuming it isn't too 
difficult to set up the experiement.  Does anyone want to try it?
Holly says this looks good, so I'll take my update as good to go.
Last Resolved: 4 years ago
Resolution: --- → FIXED
Note that we see it as a button on Demo Studio or on zones but not on the regular pages (gray on gray I believe).

So for most pages there was no changes, so we can't consider it as FIXED.
Resolution: FIXED → ---
Any usability study on search features has established that the search box should look like a box. From a quick googling:

Comment 11

4 years ago
I'm not sure if you read through those entire articles, but I don't agree with everything said in Usability Geek. Also, once the field is expanded we are covering all of the guidelines, besides having an explicit search button. 

I am open to testing a couple of variations and have one suggestion for modifying the design. 

Here is some background on choices regarding search:
- We have to plan ahead for 'developer program' to fit in the top navigation - not a reason to compromise usability, but a reason to have think about how much space we should allow for a search field.
- On the homepage and search results page we have a big search field displayed front and center in the web page. When the user lands on these pages one of the top use cases is that they have a question in mind that they want answered. If they don't want to browse through links in the nav or homepage, they will see the prominent search field. Once the user lands on a docs page, they are more likely to be closer to their answer and may also find what they need in the sub nav, related links, and docs navigator (which isn't implemented yet). The search field will still be accessible in the top right of the page, where according to the articles Rik linked to, is where users expect to find it. 
- We think of the user as being in 1 of 2 modes. Search or browse. We essentially allow the user to switch modes in the top nav. When the user clicks into the search in the main nav, the field takes over the navigation and the user can focus on searching. This also provides us with enough space to allow the user to not just focus on search, but use our filter UI in a clean interface with plenty of space. Again, we are planning ahead for something you do not see implemented yet.

If we are getting many comments that the search icon looks like a button we should listen to these comments, but we should also understand that the user still notices where the search is located and we don't require any additional clicks to start searching by presenting it this way. Just one click and the focus is in the search field. 

This should not be seen as a blocker, but here is one suggestion to modifying the design:

David had something similar in a mock-up at one point if I remember correctly. Extend the left side of the search box to the left a few pixels so that instead of a square, we have a rectangle. This area will then appear as a mini-field for the first state. Once the user clicks into the field, it will expand as it does now. For the Homepage and Search Results pages we still need to present the search as we are doing right now because we are already displaying a big search field in the web pages and it is unnecessary to have 2 search fields shown on the page at once.

Wireframe -
Approximate size of field -

David and Sean, thoughts?
Flags: needinfo?(smartell)
Flags: needinfo?(dwalsh)
Created attachment 824598 [details]
Screen Shot 2013-10-30 at 12.05.05.png

Current look on grey pages (most common pages)
Created attachment 824599 [details]
Screen Shot 2013-10-30 at 12.07.05.png

Current look on non-grey page (less common)
Holly, are these two looks what is expected?
Flags: needinfo?(hhabstritt.bugzilla)

Comment 15

4 years ago
Hi Jean-Yves, I'll meet with Sean and David to discuss search styles and get back to you. I thought that the box around the search icon was present on the grey pages as well, so we will need to be sure we have a style for this and are consistent between grey and non-grey pages.
Holly: Thanks for the background.

I think one of the issues is not using a white box, something we're all used to. See for a feedback from a Facebook redesign. The search field on the homepage suffers a lot from this I believe.

If space is a concern, maybe moving the search field in the "Login/Tabzilla" bar could help? That might look awful and unbalanced, I'm just suggesting since this row is pretty empty.

Comment 17

4 years ago
Thanks, Rik. The biggest issue with Facebook's initial design that effected discoverability was that it had no search icon or search field shown until hover. As for color of the search field, this is very easy for us to A/B test, especially on the homepage. While I don't disagree about how search field color can effect usability, I'd rather test this with our users than take what Facebook has learned with their users at 100% value. 

I'll discuss with Sean and David about a style for the field that is consistent across pages and an initial state that is more prominent and discoverable.
Flags: needinfo?(hhabstritt.bugzilla)

Comment 18

4 years ago
The following will solve for better discoverability of the search field and appearance inconsistency between (non-search results) grey pages.
Current Blue Pages:
Current Grey Pages:

1. For Homepage and Search Results pages we will keep nav search as-is (minimized) since we already have a giant search field in these web pages. 

2. For search state in navigation for non-homepage and non-search results pages, do the following:
--- create a "mini-field" to the right of the main navigation that is approximately the width of the 'edit page' button (Icon aligned right in field. Navigation still visible until user clicks into mini-field, when interaction will occur just as it does now - expands and takes over the nav area)
--- Do not apply this to Homepage or Search Results pages.
--- For the blue pages, the style and color of field will stay as-is
--- For grey pages, the style and color of field will stay as-is (white)

Wireframe -
Approximate size of field -

Sean will provide any additional needed styles to implement this.
After launch we can test any field color concerns. 

David, before pushing this change can we take a look to make sure we communicated everything properly to you? Let me know if you have any questions. Thanks!
Clearing "needinfo", let me know when/if this is approved.
I like it. Ali & Jean-Yves, can you check out Holly's mockups? They seem to address all the issues raised here.
Flags: needinfo?(jypenator)
Flags: needinfo?(aspivak)
Looks good to me. Curious to have Jeremie's opinion as he opened the bug.
Flags: needinfo?(jypenator) → needinfo?(jeremie.patonnier)

Comment 22

4 years ago
+1 to Holly's comments here.
Flags: needinfo?(smartell)

Comment 23

4 years ago
(In reply to Jean-Yves Perrier [:teoli] from comment #21)
> Looks good to me. Curious to have Jeremie's opinion as he opened the bug.

Yes, I really like Holly's suggestion :)

The only thing I'm not really fan of, is the idea of having the menu bar changing on some pages (home page menu different than content menu). I think it makes things harder for developers without serious benefit for users. But as it remains better than the previous implementation and limited to some very unimportant pages (homepage and search result) I can live with it.

So in short: Go, go, go (^_^)
Flags: needinfo?(jeremie.patonnier)
Per :habber's #1, does minimized mean hidden completely or the tiny field that it currently is?  Just want to make sure.  Then I think I can start this.
Flags: needinfo?(dwalsh)
Good question, David. This will also partly address Jeremie's concern of inconsistency between pages. For Homepage and Search results page we will display the icon in the same way. 

For Homepage and Search Results page that already have a big search field in the web page, just display the icon with no border. 
- Keep search icon and functionality in Search Results page navigation displayed exactly like you currently have it
- Add the search icon to the Homepage navigation just as you've done on the Search Results page (but white, like navigation text)

Comment 26

4 years ago
I'd like confirmation from Jeremie that this does address his concern, and then I think we are good to go.
Flags: needinfo?(aspivak)
(In reply to ali spivak from comment #26)
> I'd like confirmation from Jeremie that this does address his concern, and
> then I think we are good to go.

Didn't he give his confirmation in c#23?
Yes, he said he really liked it. Even with a " Go, go, go (^_^)"  :) 

I just mentioned in my comment that it will also rid our nav of an additional inconsistency that we had between Homepage and Search Page. This shouldn't need an additional comment from him to proceed since I didn't change anything since he last responded.

(In reply to Eric Shepherd [:sheppy] from comment #27)
> (In reply to ali spivak from comment #26)
> > I'd like confirmation from Jeremie that this does address his concern, and
> > then I think we are good to go.
> Didn't he give his confirmation in c#23?
Ali:  Can we consider this approved?
Flags: needinfo?(aspivak)

Comment 30

4 years ago
Approved. Go forward.
Flags: needinfo?(aspivak)

Comment 31

4 years ago
Commits pushed to master at
fix bug 920971 - Change navigation search box to new spec
Merge pull request #1616 from darkwing/search-nav-update-920971

fix bug 920971 - Change navigation search box to new spec


4 years ago
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.