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.

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.

.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.
• People 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)

The search engine should display:

1. Map of that location (useful for outsiders and gauging proximity between one city and another)
2. Timezone (useful for planning meetings and appointment)
3. Number 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 - Related Groups Results

• A lot of people know us by the “Firefox” product name, so new Mozillians is likely to type in Firefox
  • “Firefox” Mock-Up

1. First, the search engine should display related groups, along with definitions
   • When user search for “firefox”, say “do you mean ‘firefox mobile’, ‘fx-team’?”
   • When user search for “mozilla”, say “do you mean ‘moco’, ‘mozilla labs’?”
2. Then, we would also do a normal keyword search, and put it below.

.07 - Empty Search Results

• Mock-up

When a search query does not return any string, the search engine should say that there is no search result that contains “santa claus”, for example

.08 - Wrong Keyword, and Keyword Mismatches

• Wrong keyword and search suggestions mock-up

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

First, the search engine should say that there is no search result that contains “foxfire”, for example

• 1. If the keyword has a synonym, treat it as if the search was done for the right keyword
  2. If the keyword has no synonym, we ask user to search again

.09 - Special Cases: Search Only for Stewards

• Contribute mock-up

• When user try to search for keywords like “Contribute”, 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
   • Question: what is the use for this sorting mechanism? Is this used for vouching multiple users?
   • Could we make this an admin-only feature? Search should be as lightweight as possible, and the less filters and facets we have, the better
2. Allow sorting users alphabetically via their full names
   • Remember that name searching is going to run on autocomplete, so full-match searches are already encouraged
   • When user search for nothing but partial or common names (Dave, Mike, John, James, Mary), the search engine should already sort the result by either last name or first name
   • Which one makes the most sense, given cultural differences and varying importance of first vs. last names? Should we do both?