Mozillians/Phonebook/Search

A search box is a search box, and no matter how meticulous we’ve designed it, users are going to put whatever they want into it. Mozillians is a “phonebook”, so this problem is not apparent in its fullest form. We'll pivot around the browsing functionality as a way to primarily navigate and let Search be tied to looking for terms the App does not make readily obvious to the user.

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

Controlled Vocabulary Search

Scenario

Mozillians is awesome for searching names, but consider this scenario:

• You’re a user who had just been vouched
• You do want to help make Firefox better, you just don’t know where to start looking
• More specifically, you don’t know the internal lingo used within Mozilla (after all, you’re a volunteer rather than a staff!)
• So you punch “Firefox” into the search bar because it’s 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?

Everything we will do in search—all of the features described below—are designed to address this problem.

Design Principles

• Mozillians as a phonebook app is awesome for searching names, but what will it do if other types of informations are being put in?
• Clarify that groups, locations and other metadata are not people’s name by making it visually distinct in the search box
• Make group and metadata search easier to perform, and discourage “free-text” search on things that are not names. Why?
  • Search may come up empty or with results that are not useful
  • Users might think that our search engine is broken
  • And, by extension, if the search engine is broken, the site itself is broken

There are two parts that we have to have for this to happen:

1. From the dev-side, we’ll need to build the autocomplete functionality itself. Here’s a visual representation of how autocomplete will work to handle partial matches and metadata entries
2. From the content side, we’ll need to have:
   1. A definition list for all most-used groups. It will populate the search result and appear below the group name. StackOverflow has a great example of how a tag and a definition appear next to each other
   2. 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
   3. Other meta information associated with that group: IRC channel, website, wiki and name of community stewards

States

Logged In

• Mock-Up

• Have a search box, but have a list of the top 15-20 groups on the app
• Include introductory text, "Here are a few groups to get you started"
• When user try to search for general keywords like “Help” or “Contribute”, they may mean “How do I get started with helping?” The search result should offer names of stewards. Write: “here are some people who you can contact to start getting Involved with Mozilla”

Individual Results

• General Mock-Up

• However, if a user searches for a name with only one result (remember, we will have name autocomplete, so finding a Mozillians directly is encouraged), the user will be directed straight to that specific profile page, rather than a search result page.
• What happens if there are, say, between 1–4 or 1–8 search results. Should we display all of the results like in Mozilla’s internal phonebook?
• Obviously, when a search result page gets more than these 4 or 8 values, we would only display the name and photo, as per usual

Groups Results

• Display group definition, stewards and other meta information
  • "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
  • Support > SUMO
  • Mozillians > Engagement
  • Feedbacks > Input
  • BrowserID & Persona > Identity
  • Theme, extension > Addons, Marketplace?

Skills Results

• I expect this to be a variation of search for Groups

Location Results

• 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)
  • “Portland, OR, USA” Mockup
• The search engine should display:
  • Map of that location (useful for outsiders and gauging proximity between one city and another)
  • Timezone (useful for planning meetings and appointment)
  • 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

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
• The search engine should display related groups, along with their 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’?”

404 Results

• Mock-up

• When search query is too general or return too many results to be helpful, offer help

Search Tools

• 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
• 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?