Command & Query: a better filter and search for developers on MDN

The Mozilla Developer Network is in the process of a complete redesign. Findability and readability are 2 important focuses. Visually, we can support this with a cleaner, responsive, more flexible docs template and new styles across the site. Technically, we can support this with our implementation of elastic search and rethinking how we are tagging and providing access to our content.

Implementing elastic search was a big improvement, but what else can we do to support both the discovery of our content and the behaviors of our developer audience? Below, is a UI proposal that I am working on with Jannis Leidel and David Walsh that I call "Command & Query". Also explained are 2 additional levels of implementation. Presenting lower effort implementation options allows us to choose what variation we can implement now (our MVP) given our other priorities, launch blockers, or desire to test certain aspects of this concept, and build on after launch to reach the full design goal. 

 

Command & Query - full concept

The Command & Query concept allows all users the ability to hand-select multiple filters from a drop-down menu while allowing experienced users to type in short-hand commands for specific filters. The search field UI can handle displaying and removing multiple filters that the user has chosen.

Simple UI for entering search term and manually selecting filter type.

Thanks to David (@DavidBruant) and Jesús (@tx2z) for your javascript and front-end magic over our MDN Paris hack weekend. We've made a lot of progress! See demo video below. 

Work in progress. Code prototype sans final styles.

Possible styling for command & query UI

 

Examples of command and filter UIs:

Duck Duck Go allows for a single filter entered by key command or selecting from drop down menu.

GitHub's search UI

Chosen, Harvest's jquery plugin. Also see David Walsh’s blog post about Chosen
http://davidwalsh.name/demo/jquery-chosen.php

The mockup below demonstrates how search query shares the search field with multiple filters and supports 3 levels of user interaction. 1) For users entering a simple search, they can enter their query and search as normal. 2) For users wanting to view and choose from all filters offered, they can manually select from the drop-down menu. 3) For users that are familiar with filter commands, they can type the short-hand command behind '#', directly into the field (hitting enter commits it). '#' indicates that a word is a filter. Words without a # are simply a search term.

 

Advanced user adds filters by typing command in combination with search term.


Iterative Steps 

a. Query, no command - a simple, all visual UI for all user types

In this variation, we still have a visual way for all users to apply filters, but key commands would not yet exist. A query/search term is the only item allowed in the search field in this example. A drop-down menu exists to allow users to select multiple filters. The filters chosen are not reflected in the search field, but are indicated in the drop-down menu itself, therefore greatly simplifying the search field UI for implementation. 

The next steps for this iterative implementation is to add the ability to enter commands via the search field and drop-down menu and represent chosen filters in the search field.. 

b. Command by text - text input filtering only for advanced users

In this variation there is no visual UI for adding or viewing filters. All user types will not benefit in using filters at launch as this would only be a functional prototype to be sure filters are working as expected when paired with a search term. Functionally, the filter commands (a word preceded by #) will be able to be typed into the search field and will be reflected in the search results page, but only for users who know about the filters and what their corresponding commands are. I consider this a functional prototype for filtering itself, but not one that supports all of our users and allows them to benefit from filtering. Our filter commands would not allow for spaces in this example since we are using spaces to separate commands from each other and search terms.

 The next step for this iterative implementation is a visual layer (drop down and "Chosen" style filter display) to support use of filters by all user types.

 

The Command & Query UI offers a more powerful search for all MDN users, while supporting a command method for advanced users to quickly add filtering to a search query. I look forward to seeing how a UI like this can perform with MDN content and the addition of our new styles and templates. If we do not have time before launch to test, get feedback from the community, and implement the full solution, we also have the option to start with the smaller steps shown above.  

The new MDN is being designed iteratively, while users opt into a beta of the site and try out changes as they are released. They respond by filing bugs and giving us feedback via IRC (#mdn) and and mailing lists. MDN does not exist without our community and contributors, and while we are heads-down trying to work as quickly as we can to get the initial foundation of the new MDN built, it is important to balance this with sharing our ideas and getting feedback from the community. Your feedback and discussion is always welcome!