Mozillians/Phonebook/Search: Difference between revisions

 
(28 intermediate revisions by 2 users not shown)
Line 1: Line 1:
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.
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 ==
== Functional Principles ==
Line 8: Line 12:
# Provide tools to facet search
# Provide tools to facet search


== Controlled Vocabulary Search ==


=== Scenario ===
== AutoComplete ==


Mozillians is awesome for searching names, but consider this scenario:
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. [https://bug737484.bugzilla.mozilla.org/attachment.cgi?id=610454 Here’s a visual representation of how autocomplete will work to handle partial matches and metadata entries]. This is done in two ways:
* You’re a user who had just been vouched
* You’re eager to get started new vouched user
* You don’t know the internal lingo used within Mozilla (after all, you’re a volunteer!)
* So you punch “Firefox” into the search bar because it’s Mozilla’s most well-known product
* And plus, you ''do'' want to help make Firefox better


What would appear in the search result then, and would it solve the user’s problem and make him use Mozillians effectively?
# 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. [https://docs.google.com/spreadsheet/ccc?key=0AkYz4ya3vpPfdGE3TjRGM3Bmb1BYZ21LcnlrREMyc3c Here’s the start of a synonyms list]
# 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.


Everything we will do in search—all of the features described below—are designed to address this problem by making search smarter.
== Tag Tips ==


=== Design Principles ===
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. [http://stackoverflow.com/questions/tagged/c%23 StackOverflow has a great example of how a tag and a definition appear next to each other].


* Mozillians as a phonebook app is awesome for searching names, but what will it do if other types of informations are being put in?
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.
* 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:
== Implementation ==
# From the dev-side, we’ll need to build the autocomplete functionality itself. [https://bug737484.bugzilla.mozilla.org/attachment.cgi?id=610454 Here’s a visual representation of how autocomplete will work to handle partial matches and metadata entries]
* {{bug|737484|tracking bug}}
# From the content side, we’ll need to have:
## A definition list for all most-used groups. It will populate the search result and appear below the group name. [http://stackoverflow.com/questions/tagged/c%23 StackOverflow has a great example of how a tag and a definition appear next to each other]
## 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. [https://docs.google.com/spreadsheet/ccc?key=0AkYz4ya3vpPfdGE3TjRGM3Bmb1BYZ21LcnlrREMyc3c Here’s the start of a synonyms list]
## Other meta information associated with that group: IRC channel, website, wiki and name of community stewards


== States ==


== States ==
=== .01 - Logged In ===
* [https://bugzilla.mozilla.org/attachment.cgi?id=619862 Logged in mock-up]
* [https://bugzilla.mozilla.org/attachment.cgi?id=609243 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 ===
* [https://bugzilla.mozilla.org/attachment.cgi?id=619878 General search result mock-up]


=== Logged In ===
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 [https://bugzilla.mozilla.org/show_bug.cgi?id=694660 '''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.
* [http://people.mozilla.org/~bpitoyo/mozillians/search-ux/2-logged-in.png Mock-Up]


* Have a search box, but have a list of the top 15-20 groups on the app
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.
* 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 ===
To summarize, this is what would happen when your search query returns a certain number of results:
* [http://people.mozilla.org/~bpitoyo/mozillians/search-ux/4-search-results.png General Mock-Up]
* 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


* 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.
=== .03 - Groups Results ===
* 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?
* [https://bugzilla.mozilla.org/attachment.cgi?id=619863 "WebDev" Mock-Up]
* 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 ===
When user search for common terms for group, change the search query to the actual group name that people uses. For example:
* Display group definition, stewards and other meta information
** [http://people.mozilla.org/~bpitoyo/mozillians/search-ux/3a-search-webdev.png "WebDev" Mock-Up]
** We have talked about this above
* 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
** Websites should be WebDev
** Support > SUMO
** Help, Support > SUMO
** Mozillians > Engagement
** Mozillians > Engagement
** Feedbacks > Input
** Feedbacks > Input
Line 68: Line 60:
** Theme, extension > Addons, Marketplace?
** Theme, extension > Addons, Marketplace?


=== Skills Results ===
The search engine should display group definition, stewards and other meta information. The mock-up above details this state.
* I expect this to be a variation of search for Groups
 
=== .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 ===
* [https://bug657071.bugzilla.mozilla.org/attachment.cgi?id=615683 “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 ===
* [http://people.mozilla.org/~bpitoyo/mozillians/search-ux/3c-search-firefox.png “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 [[Mozillians/Phonebook/Search#AutoComplete|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:
# 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’?”
 
=== .07 - Empty Search Results ===
* [https://bugzilla.mozilla.org/attachment.cgi?id=609246 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 [[Mozillians/Phonebook/Search#.01_-_Logged_In|Logged In]] view below.
 
=== .08 - Wrong Keyword, and Keyword Mismatches ===
* [https://bugzilla.mozilla.org/attachment.cgi?id=619881 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.


=== Location Results ===
If a user presses enter with a mispelled search term, we should show the [[Mozillians/Phonebook/Search#.07_-_Empty_Search_Results|Empty Search Results page]].
* 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)
**[https://bug657071.bugzilla.mozilla.org/attachment.cgi?id=615683 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 ===
=== .09 - Special Cases: Search Only for Stewards ===
* A lot of people know us by the "Firefox" product name, so new Mozillians is likely to type in Firefox
** [http://people.mozilla.org/~bpitoyo/mozillians/search-ux/3c-search-firefox.png "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 ===
* [https://bugzilla.mozilla.org/attachment.cgi?id=619882 Contribute mock-up]
* [http://people.mozilla.org/~bpitoyo/mozillians/search-ux/3d-search-404.png Mock-up]


* When search query is too general or return too many results to be helpful, offer help
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 ==
== Search Tools ==
* Allow user to display vouched users, non-vouched users, or both
# 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.
** 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?
Confirmed users
6,300

edits