Better differentiation required on search results pages

[siobhan]

On the search results page, it's not obvious what is a hook, function, class, or method: ​https://developer.wordpress.org/?s=get_post

We need a method for flagging which is which. I'm not sure what the best approach is, but here are some suggestions:

1. colour coding
2. separating them and listing them separately on the same page
3. some sort of flag for each one

[Sofia Rose]

Here are the designs for the search results pages i have so far:

Badges
View – ​http://developer.compositeuk.co.uk/badges/?s=get_post
Branch (GitHub) – ​https://github.com/SofiaRose/wporg-developer/tree/feature/Search-Badges
Note: Once theres a way to differentiate between actions and filters the Hooks Badge (H) will be replaced with a Action Badge (A) and a Filter Badge (Fi).
Note: Mobile styles not yet created.

Filters
View – ​http://developer.compositeuk.co.uk/filters/?s=get_post
Branch (GitHub) – ​https://github.com/SofiaRose/wporg-developer/tree/feature/Search-Filters
Note: Filters still show up when theres no results on search page this will not happen in the next draught.

Badges & Filters
View – ​http://developer.compositeuk.co.uk/both/?s=get_post
Branch (GitHub) – ​https://github.com/SofiaRose/wporg-developer/tree/feature/Badges%26Filters

Which design do you prefer?

In a discussion on skype we thought about making all deprecated badges red, whats everyones thoughts on this?

What are peoples thoughts on hiding deprecated items in the search results and having a show deprecated filter?

[siobhan]

Discussion of this issue here: ​http://make.wordpress.org/docs/2014/05/25/devhub-search-results-badges/

[melchoyce]

Had a chance to meet with Siobhan in person this week, and she asked me to take a quick look at the search results page, which I've attached (CodeRef-Search.png​). After some discussion, we thought it would be good to go with a quick way to filter through different kinds of results (functions, hooks, etc.), since there might be a case when you'd like to see more than one filter at the same time, but not every filter. Clicking to select/deselect a checkbox should automatically update the results you see on the page.

The current search results page is also pretty hard to scan if you're just quickly looking through to find your result, so Drawing inspiration from ​https://developer.mozilla.org/en-US/, I've simplified the titles and updated the size and spacing to increase hierarchy. Clicking through to the individual function/etc. page will show the full info, so I don't think it's super important to show the arguments on the results page.

[coffee2code]

Questions/considerations arising from the mockup:

• Would a default text search (as performed from the ​code reference landing page) result in everything being listed by default? (Basically as is done now; we're just adding the ability for the user to deselect the things they aren't interested in to pare down the results after the fact.)
• Would we add the search-filter checkboxes to appearances of the search form throughout the site, or do they only appear as options on the search results page?
• Changes to the search results page should also incorporate a search input (see #493, which I think applies especially to the search results). If implemented as a top-of-the-page search like the code reference landing page, it would negate the need to introduce a sidebar to the search template just for showing the search-filter checkboxes. Or would the search form become widget-like in the sidebar?
• Should the appearance of the search results page influence how the other archive listings look? The only real difference between the search listing and the archive listings is the integration of the different content types (functions, hooks, etc), which necessitated visual differentiation (and thus, this ticket). If other aspects of the search results listing get changed (font size, removal of syntax highlighting, removal of arguments, etc), should they also be done throughout the site for other listings?

I debate the merit in displaying the full path to the linked resource as is also done on the Mozilla site. The search results are in a very structured, limited, and evident URL layout. The resource name and type (which are apparent from the linked result title and the bolded text prepending the description) constitute most of the path. To me, showing the full URL only makes sense if the resources would come from disparately located resources.

[zamfeer]

I really like Mel's solution for displaying the code type (eg. Function) and I like the more standard blue color for the links. But what this mockup doesn't account for are the functions, etc. that include parameters ​http://developer.wordpress.dev/?s=post. I don't think the current colors to differentiate the parameters and function names are right, but I do think it makes sense to have multiple colors for them.

I also really like the filtering system, and I think it would be good to integrate them into the reference landing page as well rather than displaying all types by default and requiring users to filter them only after the search.

I made a patch for #493 that adds a smaller search form to the header of internal pages. But if we use this sidebar filter, it would make more sense to place this smaller search form in that sidebar.

I don't see much value for displaying the full URL. I think simply showing the title, type and description would be great.

[coffee2code]

In 742:

Code Reference: add search form to search results page.

• Add search form to top of search results page
• Add breadcrumb for search results page
• Make searchform template applicable outside of reference landing page

See #450, #494.

[coffee2code]

In 743:

Code Reference: add search summary info to top of search results page

props melchoyce.
see #450.

[coffee2code]

In 781:

Code Reference: streamline UI for archive/search listings

• Add content-reference-archive.php template and use it for archive and search listings
• Add wporg_filter_archive_excerpt() and use it to prefix post type label to excerpts in archive listings
• Add wporg_filter_archive_title() and use it to append '()' to titles for function-like post types in archive listings
• Add get_line_number() to get either start or end line number
• Display simplified archive listing (no full method signature, no parts highlighting)
• Add post type label, source file relative path, and start line number to archive listed items

fixes #450
props nicolealleyinteractivecom