#450 closed enhancement (fixed)
Better differentiation required on search results pages
Reported by: | siobhan | Owned by: | coffee2code |
---|---|---|---|
Milestone: | Priority: | high | |
Component: | Developer Hub | Keywords: | |
Cc: |
Description
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:
- colour coding
- separating them and listing them separately on the same page
- some sort of flag for each one
Attachments (1)
Change History (10)
#3
@
11 years ago
Discussion of this issue here: http://make.wordpress.org/docs/2014/05/25/devhub-search-results-badges/
#4
@
10 years ago
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.
#5
@
10 years ago
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.
#6
@
10 years ago
- Cc andrew@… added
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 it 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 in displaying the full URL. I think simply showing the name, type and description would be great.
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?