Search Initiative: On Hold

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.

#omnisearch, #search

Search Initiative Chat Recap

Link: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-12-06&sort=asc#m36279

In Attendance:

Topics Discussed:

  • 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 adminadmin (and super 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 MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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.

#feature-plugins, #omnisearch, #search

The Search Initiative needs YOU!

the-search-initiative

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 adminadmin (and super 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 MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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-coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-plugins on Freenode.

If you’d like to be involved, but either don’t know what IRCIRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net. or Freenode is, or can’t makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). it at that time, just drop a comment below and I (we, hopefully) will make sure to loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. you in and take your schedule into consideration for future chats.

The Search Initiative has need of all sorts, from Designers and UXUX User experience 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!

#feature-plugins, #omnisearch, #search

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 sitesite (versus network, blog), 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ 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

Theme filter searching now has an all/an…

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/

#boolean, #filter, #search, #themes