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.
Updates from George Stephanis 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!
WordPress Global Admin Search Evolves To Tackle Bigger Problems, George Stephanis, RicaNeaga, and 2 others are discussing. Toggle Comments
After the feedback in the merge chat today, it looks like we’ve got a bit more work to do on the global search spine.
Based on a quick survey, it looks like Monday, November 11, 20:00 UTC (3pm EST) is likely to be the best time for the most people.
As we’ve done before, we’ll meet in #wordpress-core-plugins on Freenode, and I’ll give a shout in advance on #wordpress-dev for anyone that may be lurking in there.
Putting up the bat-signal:
Other folks who spoke up during the merge chat that I’d love to have join us:
IRC chats in #wordpress-core-plugins:
Omnisearch currently adds three ways to search.
- A Dashboard Widget:
- An admin page under the Dashboard:
- And as a search box on the adminbar — when you’re on the admin side of the site:
All three turn up the same results page:
And all is happy with the world.
We were trying to solve the proliferation of different search forms for different data structures in the admin. When trying to find content, it’s inconvenient and difficult to always navigate to the right data structure and then search it — especially if you’re unsure if something was in a comment or a post (all too frequent in p2s)– and you just want to pull in all relevant results.
Other things we’d considered were potentially adding an Alfred-like pop-up modal where you could enter omnisearches, and see results from the menus on the page that happen to match — very much like WP Butler’s current functionality. We opted not to add it in this pass, though, figuring better to keep a slimmer implementation.
Our user testing confirmed that this was a definite win. In fact, the user even remarked that there should be a centralized search when we had them running through the initial steps where they were to search each data structure independently, before activating Omnisearch and seeing how that compared.
We’re eager to hear any feedback on code, methods, or even name. I’ve had some people mention that they’d prefer it have a less ‘marketing’ name, and more of a generalized “Global Admin Search”. I prefer Omnisearch for brevity, but would love to hear some discussion on the pros and cons of whether it would be better to use a more general name.
Sorry for the delay, been a chaotic week or so. Just got the results of some user testing back thanks to the assistance of @lessbloat.
Here’s my notes:
- User remarks that there is no obvious intermediary way to search things. Seems frustrated about having to go from the current page, to the archive page, to search.
- Unrelated Bug: (possibly due to browser extension?) For some odd reason, when the user selects the search box, it jumps below the list table. Really odd behavior in IE 10.
- Dislikes native WordPress functionality of the “Search” in the adminbar expanding when selected (native is only on front-end, Omnisearch expands this functionality to admin ui as well) — believes it should be natively expanded. Reiterated several times. Perhaps look at making it drop down a search box on hover (kinda like twentyfourteen does), rather than expanding on click and shifting things about? Unsure.
- Found Bug: Reply hoverlink in comments list [in omnisearch] doesn’t function properly (missing JS hook).
- “Overall, I would say that this is a much better tool, much better layout.”
The user seems very positive, seemed to consider it a great win for usability. Pointed out a few bugs (as noted above — only notable one I caught with Omnisearch itself being the hoverlinks in the Comments to reply didn’t work), which I’m about to patch.
Our weekly meeting will be as usual, Thursday at 22:00 UTC (6pm Eastern)
WordPress › Omnisearch / Global Admin Search, Final Pitch « Make WordPress Core, George Stephanis, Nico, and 2 others are discussing. Toggle Comments
Terribly sorry for the delay, but I’m pleased to announce that Omnisearch will be meeting
Fridays at 5pm Eastern Time, 21:00 UTC, Thursdays at 6pm Eastern Time, 22:00 UTC, in #wordpress-core-plugins on freenode. Happy to adjust it later, if that’s too early or late for folks in other timezones.
Omnisearch is a central search form, meant to simplify the process of finding what you’re after. It is designed only for the WordPress Admin Interface — not the front end.
By default, it searches Posts, Pages, Media, Comments, and the Plugins Directory. However, it’s easy to hook into, and provide custom results from third-party modules, such as Grunion Contact Form in Jetpack.
Omnisearch has been living in Jetpack for a few months now, and has gotten mostly positive reviews. The only complaints that I’ve heard were that it doesn’t search media (which has since been added), the relevance isn’t always ideal (it just uses the default search that happens when you use the existing search form on the posts page or the like), and some coming from a misunderstanding where they were expecting it to be on the front-end of the site — not merely an admin tool.
If interested, you can install it yourself here, which will override the version in Jetpack if you happen to have that installed [ I made sure to only include the Jetpack one if ( ! class_exists( ‘WP_Omnisearch’ ) ) ] :
We’ve had some terrific progress made in the realm of supporting touch interfaces and tablet UIs for 3.4!
The main areas that we’ve focused on for this release were improving touch support in the user interface, resolving incompatibilities for our target devices, and enhancing the UI’s methods for adapting to more restrictive screen sizes.
Our target devices for the 3.4 release were the iPad and the Kindle Fire. The iPad stands as an obvious choice, and the Kindle Fire’s steep climb to over 50% of market share amongst Android tablet devices justifies its presence as well.
Improving Touch Support
For touch-supportive devices, we’ve added a fantastic jQuery extension to the core, jQuery UI Touch Punch. This has enabled ‘drag and drop’ support on mobile devices. Whether editing a post, customizing the dashboard, or modifying a Nav Menu, you’re now able to easily reposition items on a touch interface to your heart’s content, just as you would on your desktop browser.
Caveat: Windows Phone Devices
Windows Phone 7/7.5 phones are wonderful devices. Unfortunately, when Microsoft based the phone’s web browser off IE9, they didn’t add in any touch support. As such, there is no way to detect touch events in the browser — `
ontouchstart` doesn’t exist. Dragging support does not work on Windows Phone 7/7.5 devices, but should on Windows 8 tablets and phones when released.
This boiled down primarily to the Kindle Fire. The version of WebKit used in the Kindle Fire’s native Silk browser doesn’t support the contentEditable attribute, so TinyMCE wouldn’t work! To accomodate for this, we added an override to test for the version of webkit that the client is using, and just disable the visual editor if the browser doesn’t support it. This patch should also cross-apply to older versions of iOS and Android as well.
In Ticket #20015, we migrated the dashboard and write screen columns to use primarily @media queries, rather than the JS that had previously been used. This should provide some performance optimizations in mobile browsers.
The Tableteer team for 3.4 was comprised of Andrew Ozz, Zach Abernathy, and George Stephanis.