Mozillians/Phonebook/Search

Mozillians as a phonebook app is awesome for searching names, but what will it do if other types of information are being put in?

Think of this scenario as a user: you've just been vouched; you do want to help make Mozilla's products better and just don't know where to start looking; you don't know the internal lingo used within Mozilla. So, the first thing you'll do is punch in "Firefox" into the search because its Mozilla's most well-known product, or use a generic term, like "websites". What would appear in the search result? Would it solve the user’s problem of knowing where to look? Would it make him use Mozillians effectively?

To clarify, groups, skills, locations and other metadata are not people’s name and is a standard user need in regards to search and finding other Mozillians. They should be visually distinct. To do this, the will make group and metadata search easier to perform, and discourage “free-text” search on things that are not names. Everything we will do in search—all of the features described below—are designed to address this problem.

Functional Principles

Search should be done confidently. We do not want users to search for something that’s not in our vocabulary list and find nothing. Help them:

1. Complete queries
2. Correct errors
3. Provide tools to facet search

AutoComplete

Autocomplete will easily allow users to search for names, groups, skills, locations and other metadata. It reduces a lot of burden on the user to be smart about their choices on search and provide a large amount of information and value in return. Here’s a visual representation of how autocomplete will work to handle partial matches and metadata entries. This is done in two ways:

1. A synonyms list for the same, so when people use common terms to search for things, we can direct them to groups that relate to that term. Here’s the start of a synonyms list
2. Correlating metadata for groups and people to these results. For example, if someone searches for "http://support.mozilla.org", they'll receive an autocomplete dropdown result for the "Support" group as that is listed in its "website" field.

Tag Tips

To increase discoverability of groups, skills and locations, and reduce the need for users to go through the search field for every query, the Mozillians Phonebook will offer "Tag Tips" on the hover of tags within search results. We're looking for simple metadata (i.e. description, steward and # of members) within these tips. StackOverflow has a great example of how a tag and a definition appear next to each other.

When occasions arise, we will also display these tips onscreen. For example, when you search for a group, you want to know about that group’s metadata, so we will display these infos onscreen rather than make it a tooltip that appears on hover.

Implementation

• tracking bug

States

.01 - Logged In

• Logged in mock-up
• Logged in + good first bug mock-up

We'll want to have a search box visible at the top of the app, but have a list of the top 15-20 groups on the app within the content area. The mock-ups above offer the copy and information to be shown.

.02 - Individual Results

• General search result mock-up

So, when a user search for something that cannot be autocompleted (for a text in the bio, for example), and where no synonym can be found, the search engine should perform a normal search. If a user searches for a name with only one result, the user will be directed straight to that specific profile page, rather than a search result page. When there are between 2 or more search results, we should display all individual results much like Mozilla's current paid-staff phonebook.

There is a limit on the number of full individual results we can display on the search result page before it feels slow and heavy-handed (all those bios!) We know that it is a number between 2 and around 15, but we’d need to research and look into best practices to determine the ideal number.

To summarize, this is what would happen when your search query returns a certain number of results:

• 1 — go directly to the user’s profile page
• 2 to <15 — display full individual results on the search result page
• >15 — display abbreviated results, the way we do it today

.03 - Groups Results

• "WebDev" Mock-Up

When user search for common terms for group, change the search query to the actual group name that people uses. For example:

• • Websites should be WebDev
  • Help, Support > SUMO
  • Mozillians > Engagement
  • Feedbacks > Input
  • BrowserID & Persona > Identity
  • Theme, extension > Addons, Marketplace?

The search engine should display group definition, stewards and other meta information. The mock-up above details this state.

.04 - Skills Results

Skills do not have individual pages like "Groups" as they are capabilities that are used by contributors to fulfill tasks. They do not have a Steward nor any metadata attached. The search results page will simply display people results of those with that specific skill.

.05 - Location Results

• “Portland, OR, USA” Mockup

People might want to see how many Mozillians in an area in order to organize an event, plan a meeting, etc. and might also want to know if there is a MozSpace in the area that they could join (it’s a great way to meet staff). So, we should show that metadata when they are available.

The search results page should display:

• Map of that location (useful for outsiders and gauging proximity between one city and another)
• Timezone (useful for planning meetings and appointment)
• # of members in that location (ie. number of user who has the same location data in their profile), this is useful for planning meetups and even make certain executive decisions, like whether to open a new Mozspace, or sponsor a technology event in that city.

.06 - Aggregate Groups Results

• “Firefox” Mock-Up

New/Potential contributors may only know of the “Firefox” product name, but there are many teams and communities that make releasing "Firefox" possible. So, when a Mozillian types in Firefox, we'll need to likely show a list of related groups via our Synonyms List instead of an actual group. We can mitigate the amount of information to show here and offer suggestions in the autocomplete dropdown.

As a result, a user will see the following:

1. When user search for “firefox”, say “do you mean ‘firefox mobile’, ‘fx-team’?”
2. When user search for “mozilla”, say “do you mean ‘moco’, ‘mozilla labs’?”

.07 - Empty Search Results

• Mock-up

When a search query does not return any string, the search engine should offer an "I'm sorry" message as well as the Logged In view below.

.08 - Wrong Keyword, and Keyword Mismatches

• Wrong keyword and search suggestions mock-up

Examples:

• Firefox could be misspelled “fire fox”, “firebox”, “foxfire”, etc.
• Mozilla could be misspelled “modzilla”, “mozila”, “mozzila”, etc.

If a user presses enter with a mispelled search term, we should show the Empty Search Results page.

.09 - Special Cases: Search Only for Stewards

• Contribute mock-up

When user try to search for keywords like “Contribute” or "Help", they may mean “How do I get started with helping?” The search engine should do a search for the “stewards” group and then display the results.

Search Tools

1. Allow user to display vouched users, non-vouched users, or both. This will help Vouched Mozillians view any non-vouched Mozillians and help Stewards and Reps to do so. This could be put into the admin panel as well, so this is a decision for the development on what makes their lives easier.