[wp-meta] [Making WordPress.org] #450: Better differentiation required on search results pages

[Making WordPress.org]

#450: Better differentiation required on search results pages
--------------------------+-------------------------------------
  Reporter:  siobhan      |      Owner:
      Type:  enhancement  |     Status:  new
  Priority:  high         |  Component:  developer.wordpress.org
Resolution:               |   Keywords:
--------------------------+-------------------------------------

Comment (by coffee2code):

 Questions/considerations arising from the mockup:

 * Would a default text search (as performed from the
 [http://developer.wordpress.org/reference/ 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.

--
Ticket URL: <https://meta.trac.wordpress.org/ticket/450#comment:5>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org