Due to a lot of stuff in my lap for the next few months, I don’t have the time to keep chasing down things for Search. If anyone would like to take point, I’d be glad to help in any way possible, I just don’t have the time to wrangle it personally for the foreseeable future.
Tagged: search Toggle Comment Threads | Keyboard Shortcuts
- The ‘big’ portion of the Search Initiative may have to be delayed unless we get sufficient interest and participation. A small group with little feedback will have significantly more difficulty building something that will necessarily be attractive to the community at large, and have far less chance of adoption.
- x-team (Weston and John) have been working on “admin screen search” here, which is very much in line with the Navigation is often tricky to find a menu item (seen time after time in user testing videos). Possibly suggest admin pages as the user is typing their query? auto-suggest item from the original summation post. However, it would need a search field to hook onto to offer the results. Some questions about how best to cache it were brought up, as that would be expensive to run, but it seemed best to address that after figuring out precisely what it’s going to search and how it’s going to happen.
- Scott and the Metamorphosis team have been working on how to better structure Post Meta for assorted post types and the like. This would mesh quite well with the Not all relevant information is searched. I may have relevant data stored in a postmeta field, but it’s not indexed for searching item from the original summation post. If a `include_in_search` flag could be set on specific meta keys, it could provide far more accurate results, as opposed to the status quo, where postmeta is not used in search (leading to rather difficult situations in CPTs where `content` is not supported or is not representative of the item in question)
We’ll be continuing on December 13 22:00 UTC unless a time that works for more people is suggested in the comments below.
The Search Initiative needs people! We’ve (okay, I’ve) had some terrific feedback from folks already, and would love for the actual work to have a plurality of voices coming together to build it!
What is the Search Initiative?
Glad you asked! The Search Initiative is a collection of smaller tasks aimed at making searching within the admin panel a more unified, streamlined, simpler experience. We are not presently looking to change the search experience on the front-end of sites. Many themes do a variety of display methods for that, and we shouldn’t step on their toes. Instead, the biggest task at present seems to be unifying all the search forms in the administrative interface to feed into a global search. Probably offering tabs for each searchable content type, with a count of the number of entries in each.
There’s also other aspects that can work in parallel, such as client-side suggestions when someone is typing in a search query. So if they begin typing in ‘New P’ — it would autocomplete the links to ‘New Post,’ ‘New Page,’ and ‘New Pachyderm’ (if they’ve got an elephant post type) — and how can we offer more relevant search results on post types by efficiently searching Post Meta as well? I’d love to get some collaboration with Team Metamorphosis on this aspect.
If you’re interested, we’ll be having a chat on Friday evening (after the 3.8 code freeze — this is intentional) at December 6 22:00 UTC in #wordpress-core-plugins on Freenode.
If you’d like to be involved, but either don’t know what IRC or Freenode is, or can’t make it at that time, just drop a comment below and I (we, hopefully) will make sure to loop you in and take your schedule into consideration for future chats.
The Search Initiative has need of all sorts, from Designers and UX prototypers, to folks able to write and perform user testing, as well as back-end and front-end coders willing to help ensure a tight integration with core. Most of all, we need you!
- George Stephanis
- Ryan Boren
- Samuel Sidler
- Mark Jaquith
- Helen Sandi
- Sarah Goodling
- Matt Mullenweg
- Andrew Nacin
We opted to begin by reevaluating what pain points we believed there currently were in the WordPress admin around search.
These are just what we came up with in the chat, please comment afterwards with any additional issues you’d like to see considered. Some of these are pretty big issues, and could easily be spun off into seperate projects. This looks like it is shaping up to be a significantly larger endeavor than was initially run as Omnisearch.
Current Problems to Solve (The Status Quo) (Because the status is NOT quo)
- We have a lot of search forms in the admin, and it’s troublesome to have to find / navigate to the type of thing you want to search before actually searching it. (#)
- When searching, often it’s difficult to know / overly vague why a specific result has been included in the result set. (#)
- Not all relevant information is searched. I may have relevant data stored in a postmeta field, but it’s not indexed for searching. (#)
- When searching, and no results are found, the user hits a ‘dead end’ — no suggestions or path forward is offered. (#)
- Navigation is often tricky to find a menu item (seen time after time in user testing videos). Possibly suggest admin pages as the user is typing their query? (#) — Related plugins: Jarvis and WP-Butler
- We don’t currently support syntactically-aware search queries. “Comments by [user]”, “Posts in [category]” etc. (#)
- There is currently an inconsistency in the adminbar search field. It displays on the front-end of the site, but not on the admin side — due to WordPress not having a unified search results page to send people to on the back-end. (#)
I feel that 1, 4, and 7 are the most similar and the solution for both would be more a single unit, whereas 2, 3, 5, and 6 are more distinct and could be done in parallel or in subsequent iterations.
Possible road forward:
Have a Global Search Page, with some sort of tabbed interface. There would likely need to be an ‘Overview’ tab, and then for each different data type being searched, its own tab. Generic search forms (like the adminbar search) would land on the overview, but if the initial search form designated which bit of content they’d like to search (for example, using the search form on the admin posts page), send them directly to its respective tab, the content of which would be akin to the current search results pages currently dispersed throughout the admin.
We would be able to add in the adminbar search form to the admin (yay consistency) and even auto-suggest based on links off of the current page (akin to Jarvis or WP-Butler) — or leave that to plugin territory.
Parallel projects on the rest would be terrific, as I don’t personally see them as interdependent. They could be iterations or new groups could spring up to tackle them.
That’s what I’ve got, now I’d love to hear your use cases, feedback, and where you’d like to see this headed. Let’s get the feedback in early this time, folks!
Theme filter searching now has an all/any selection box, for people who didn’t like it being exclusively boolean AND. See it here: https://wordpress.org/extend/themes/tag-filter/