Closed Bug 920971 Opened 11 years ago Closed 11 years ago

The search box in the header looks broken

Categories

(developer.mozilla.org Graveyard :: Design, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Jeremie, Unassigned)

References

Details

(Whiteboard: [needs UX])

Attachments

(4 files)

Attached image 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.
Attached image 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.
this has been reported as a UX issue in several bugs, and also through conversations with users. We should address this.
Whiteboard: [needs UX]
Blocks: MDNLaunchBlockers
No longer blocks: 910513
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.
Status: NEW → RESOLVED
Closed: 11 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Any usability study on search features has established that the search box should look like a box. From a quick googling:
http://www.nngroup.com/articles/search-visible-and-simple/
http://usabilitygeek.com/10-usability-guidelines-for-the-search-interface/
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 - http://cl.ly/image/1W1k2O1Y0c3C
Approximate size of field - http://cl.ly/image/3y3a0t1B252S


David and Sean, thoughts?
Flags: needinfo?(smartell)
Flags: needinfo?(dwalsh)
Current look on grey pages (most common pages)
Current look on non-grey page (less common)
Holly, are these two looks what is expected?
Flags: needinfo?(hhabstritt.bugzilla)
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 http://www.fastcodesign.com/1673209/how-facebook-fixed-the-biggest-design-flaw-in-graph-search 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.
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)
The following will solve for better discoverability of the search field and appearance inconsistency between (non-search results) grey pages.
Current Blue Pages: http://cl.ly/image/3g1Z1Q0C0H1r
Current Grey Pages: http://cl.ly/image/3i1p230M3A2O

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 http://cl.ly/image/2p0k2u460a2o (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 http://cl.ly/image/1E0j1O0l003c
--- For grey pages, the style and color of field will stay as-is (white) http://cl.ly/image/2m2l0e0p123z

Wireframe - http://cl.ly/image/1W1k2O1Y0c3C
Approximate size of field - http://cl.ly/image/3y3a0t1B252S

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)
+1 to Holly's comments here.
Flags: needinfo?(smartell)
(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 http://cl.ly/image/1J3n3E1a0f3G
- Add the search icon to the Homepage navigation just as you've done on the Search Results page (but white, like navigation text) http://cl.ly/image/2s0b0E1l3s3l
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)
Approved. Go forward.
Flags: needinfo?(aspivak)
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/d3887cc1c8f412264b3e3657cbf48430f5ce8a24
fix bug 920971 - Change navigation search box to new spec

https://github.com/mozilla/kuma/commit/e2f5e68542d968c1f4527c678e8c73eea519744e
Merge pull request #1616 from darkwing/search-nav-update-920971

fix bug 920971 - Change navigation search box to new spec
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: