UX Review: Searcher

[BenJam]

Help Needed!

If you use Libraries.io to do any of the following tasks we would love to hear from you. Please get in touch with us in the comments, by email or in our open chat channel.

---

In the following we look at a specific audience, their goals or common tasks, map out entry points, user flows and potential drop of points. These flows are informed by analytics data and walk throughs with users. Where drop offs occur we highlight what the user needs and/or expects to see and how well these expectations are met. Finally we outline modifications to be made at each point of the user flow.

Audience/Persona

This ticket tackles common uses from the perspective of the searcher.

User need

Ada is a developer who has been assigned a ticket to improve a slow-performing ruby application. She's heard that pg-hero is really useful for highlighting slow database queries. She would like to check it out and decide whether to use it.

She's interested in whether the project is well used, documented and supported, who the maintainer(s) are, who has contributed, how many dependencies the project has, whether using the project would result in further restrictions on her own application, how responsive maintainers are to issues and improvements, whether there are any known vulnerabilities and finally what alternatives are available.

User Flows

• Google search > /project
• Chrome autocomplete > /search > /project(s)
• / > search input > project(s)
• /project > search input > /search > /project(s)
• /search > /search > *

Behaviour and traffic

• 98% of users flow straight into a /project page (e.g. /github/jondot/awesome-react-native`) from Google.
• For the ~2% using the search 16% search from / while 16% search from /search?q= presumably performing a second search or using autocomplete in chrome.
• Once a search is performed exit rate is 26%, stayed by a huge 60% on (entrance)
• 31% of searchers then add refinements
  with an average page depth of ~6 thereafter, avg. duration ~6 minutes indicating that users

Enhancements

Search

• add SourceRank score, to results to make it easier to compare packages (left in favour of Add code quality metrics for projects #78)
• consider breaking SourceRank score into sections (code, documentation, community, dependencies) (left in favour of Add code quality metrics for projects #78)
• make refinements clearer
• use ordinal dates for 'updated by'
• make it more obvious that the number is the current version

Project/Repository

• Make a clearer distinction between metadata (licence, version, etc) and content (readme)
• Only show the topmost section of the readme
• Have a more defined seperation between facts (contributors, versions etc) and content ) readme, licence, contributors, issue template, changelog).
• Show only current release or current and last major release (left in favour of More useful release information #1473)
• Promote project 'statistics'
• Use ordinal for last/first release
• promote top/latest contributors
• promote/unpack the dependency tree details (currently under the readme)

Goals

/Search

• increase number of searches (indictor of stickiness) Currently 2.79%
• maintain avg. max page scroll on results pages (results are accurate). Currently 0.2%
• decrease avg. exit rate (results are relevant). Currently 26%
• not sure about avg. time after search (results are helpful). Currently 5:50
• not sure about avg. number of refinements needed. Currently 31%

/Project

• decrease proportion of searches from project page (indicator that first hit is good)
• decrease avg. max page scroll (important information is topmost)
• decrease avg. time on page (important information is well presented)
• not sure about avg. pages/session.
• not sure about exit rate.

[BenJam]

Looking for feedback @andrew.

[BenJam]

closed in #1459