What problems would this solve? =============================== Search is not currently a prominent feature on MDN. We can also use a search results redesign to better connect and promote all the content types we offer across MDN. (docs, users, demos, code samples) Who would use this? =================== Those who use search to access content on MDN. If the user enters MDN at the docs detail page level, we can also use the search results interface to direct the user to related content, facilitating horizontal navigation across MDN. Wireframes will further illustrate this concept. What would users see? ===================== 1) Search in Navigation 2) Options to filter/direct the search query 3) New search results organization 4) Possible concept: within the docs, themselves, a UI that allows the user to skip through search results and related docs that doesn't require them to return to the separate search results page. (see wireframes for further detail) What would users do? What would happen as a result? =================================================== Users would be more drawn to use MDN search to navigate our content. If a user enters MDN at a level below the homepage, they would be more compelled to use our search than leave the MDN search to use Google, for instance. The new search results display would allow the user to see in greater details all we offer on MDN. We will be able to relate our content to one-another. For instance, if a particular doc offers a related code sample and demo, the search results should communicate this. Is there anything else we should know? ====================================== This bug refers to the visual design and interaction of MDN search. A separate bug addresses elastic search.

I will provide a wireframe that describes how search is displayed in navigation, the interaction that happens when performing a search, search results display, filtering options, and search UI possibilities within docs. TBD: Will need to work with MDN team to decide both filtering options and search results display. The level of visual design effected in this phase is dependent on availability of a visual design resource.

This looks like a good size for the bug. It may be X-Large, but I doubt we will need to break it down. As Holly mentioned, we have a separate bug (bug 839214) to get Elastic Search up and running with the current visual style. Looking forward to that wireframe. Will bring the team in for thoughts on filters / result display once that's up, unless you need those ideas before that.

We still need to discuss exactly the capabilities that we have for things like filtering and search results display once we have elastic search working. However, I am posting wireframes with these TBD things in mind.

Updates include: - Search bar and interaction within main navigation - ability to filter search - search results - key commands - docs level search bar (results navigator)

We have a basic Elastic Search and basic results page up and running (although hidden to most users -- let me know if you want to see it!). Maybe Luke or David could say more about how much work it would be to support filtering on the back-end.

Filters for Docs, Demos, and Profiles are straight-forward. Live samples will be more challenging.

Making awesome progress here. Really like what I saw on David's site last week. Moved this into "Selected". A quick question. Would it be possible to do this behind a feature flag? Want to be sure we do some testing and get Holly's eyes on it before we release.

I don't think this is ready to implement quite yet, but we could start preparing to implement it within the MDN dev platform and prototype with real MDN content and filters. These are the outstanding items: - select content filters that work with our content - make sure content is tagged appropriately to work with these filters - simplify search results display - the interaction for expanding/minimizing search needs work... the prototype helped to get the feel of this, but we need to make the search mode a little more intuitive - Do we need a designer to put this in the current MDN template? Also, a larger factor is the Developer Ecosystem project that is getting going quickly now due to the upcoming FxOS releases this summer. If we move ahead with this update to MDN it would be a great way to test how our elastic search works, and be sure it is ready for this larger dev ecosystem umbrella to use as well. Finding a way to implement this soon and prototype with MDN content would be a great way to test this before we have other tasks come our way. However, I just want to give a heads-up that some of the UI surrounding the search may change later. I have updates to the filters and also have better detail around how the "navigator" on the docs pages work depending on where the user enters the docs from (MDN vs. Google search, for instance). I am preparing this for the Dev Ecosystem presentation on Wednesday and will share that with you when it is done.

Thanks for the detailed reply, Holly. One thing we could do is implement a prototype behind a feature flag. What that basically means is that the feature would be available to some small group of people -- maybe just you and others on the team -- and refined over time. When the feature is complete enough, the feature flag would be removed and the feature would become available to all MDN users. Would an approach like that work for you? If so, we could start by building a prototype of your current mockup behind a feature flag.

That works for me. Once we test it and confirm that the filters and results are working well with our content (MDN docs, demos, etc), we may have to alter our design to work with the Dev Ecosystem project before it we implement it for all users. This depends on the timeline and how far the work is for the Dev Ecosystem project. How do you gather feedback and track the use on a feature flag prototype? Is it possible to do quantitative testing or only qualitative?

(In reply to Holly Habstritt [:Habber] from comment #10) > That works for me. Great. David, what would be the first part of doing this? Ideally, we want a task that is similar in size to other things on the board. > How do you gather feedback and track the use on a feature flag prototype? Is > it possible to do quantitative testing or only qualitative? We do not have a formal process for things like this, but usually open the feature up to a small number of people, let them play around on it and file bugs for problems they encounter, and then open the feature up to all users once our users seem happy. So really only qualitative. We could do more quantitative research if you have any ideas in mind. I know Luke loves doing metrics.

Per the comments to this point: 1. Sheppy or Jean Yves should create the content filters. I know we have a bunch listed on the homepage now but we should really evaluate them; what's doing well, what do we want to do better, what do we want to focus on? 2. It appears docs are well-tagged but we'd either need to (a) get Tags hooked into elastic search or (b) just do tag searches. Any insight about how this works Luke? 3. "the interaction for expanding/minimizing search needs work... the prototype helped to get the feel of this, but we need to make the search mode a little more intuitive"; I agree with this and maybe we have a discussion; maybe we show the list of search results on the left and when you click a result it loads on the right? I think the results bar above the content is a bit unclear. 4. "Do we need a designer to put this in the current MDN template?" I can implement whatever we decide *but* this mockup seems to not take into account MDN's current design, at least with the expanding search field. I guess I was expecting we'd implement this once the new design was ready, and not necessarily before. Here's the search mockup as it sits now: http://davidwalsh.name/demo/search-mockup/ . Obviously it doesn't use "live" data as I was under the impression we just wanted some simple interaction views. I can try to hook it into real data if elastic search is ready, but I still feel like #3 should be settled before we try to use live data and put it into our templates. Would love to know what you all think though.

Comment on attachment 735500 [details] Phase 1 Redesign: Updated Search (display and interaction) Hi everyone, Joined design group recently. I looked into mockups and these are some observations, ideas. Any feedback welcome.

Hi! I joined the group recently, I got very busy after a Mozilla Hispano WorkWeek, now I'm back on track. I see you are iterating over this, my observations are: - Isn't the proposal really far away from the current design? Maybe I am missing something. - I think that Search is one of the most important features on MDN, and (correct me if I'm wrong), that's why we really care about it, and one of the reasons behind taking all the effort to use ElasticSearch. Search is crucial on any large knowledge base. - Therefore, I think having the search bar hidden under a click/tap action hurts discoverability, it's just a click away, but: do we really need that? It's not like progressive disclosure, it's a top feature. - I like karabajic's approach of having the search bar visible all the time, as is in MDN right now, also in MSDN, StackOverflow, Wikipedia, and many more. - I like karabajic's approach of having the username and the search bar permanently shown. - I have a different take on that, just for the sake of iterating. As you can see on the attachment, also thinking on a probable responsive adaptation in the future. On the other hand, I was also looking at this amazing KB some people built: https://support.mozilla.org/en-US/home Take a look at the home page. What's wrong with that? I think MDN is very suitable for that layout. The taxonomy could easily be arranged into that form. I also like WebPlatform's approach. http://docs.webplatform.org/wiki/Main_Page

Thanks for the great feedback Pablo and Goran! Sorry for the delayed response as I am just returning from 2 work weeks. These are all great feedback and ideas. Here is a little background for contributors. Navigation and interaction are far from final since this bug was created to facilitate a quick prototype so we can identify the many points in our UI where elastic search will benefit MDN. (nav, related docs, filters, search results) There is also other work going on that will ultimately support any design and ux decisions we make. (ie: surveys, user interviews, card sorts, evaluating docs taconomy, etc) Feel free to continue to post feedback if you like and use this bug as an idea sandbox around search UI. Keep in mind that things like navigation, datapoints, and filters have progressed quite a bit since this mockup. Once we have sorted through all the content further and have more feedback from our users I will post them here. Do either of you have feedback on what key commands would be most efficient and also logical given how other sites and services use them? (ie: github, duck duck go) Key commands could be used to trigger search from anywhere in MDN, navigate through results and docs templates quickly, etc.

Posted possible solution since elastic search will be used in redesign in this bug https://bugzilla.mozilla.org/show_bug.cgi?id=839214#c13

Update: Elastic search now performing behind waffle flag. We will incrementally make improvements to the search UI based on what we can support so far with our elastic search. Next up for search results UI: - update summary display to use search display summary first, then first paragraph of article if summary does not exist. - display breadcrumbs in search results summary (http://api.jquery.com/) - expose filters to users (that we are able to as of now), starting with locale - display tags in search results summary

Taking this out of the ES MVP bug tree since it's more of an on-going tracking bug.

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.