Omnisearch User Testing

Howdy, all!

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.

View Results:

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 adminadmin (and super 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 JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. 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 patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing..

Our weekly meeting will be as usual, Thursday at 22:00 UTC (6pm Eastern)

#omnisearch, #user-testing