The Search Initiative

The Search Initiative

IRC Chat Log

In Attendance:

  • 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 adminadmin (and super 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)

  1. 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. (#)
  2. When searching, often it’s difficult to know / overly vague why a specific result has been included in the result set. (#)
  3. Not all relevant information is searched. I may have relevant data stored in a postmeta field, but it’s not indexed for searching. (#)
  4. When searching, and no results are found, the user hits a ‘dead end’ — no suggestions or path forward is offered. (#)
  5. 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
  6. We don’t currently support syntactically-aware search queries. “Comments by [user]”, “Posts in [categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging.]” etc. (#)
  7. 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party 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! 🙂

#omnisearch, #search