WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from George Stephanis Toggle Comment Threads | Keyboard Shortcuts

  • George Stephanis 9:26 pm on January 15, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    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.

     
    • utkarshd_42 5:40 pm on March 7, 2014 Permalink | Log in to Reply

      Hi sir,
      I would like to work on the search initiative for the coming GSoC 2014. Can you suggest me as to how to proceed further with the code that has already been completed?
      And what will be my objectives that I have to complete.

      • George Stephanis 5:44 pm on March 7, 2014 Permalink | Log in to Reply

        Have you read the history of posts on this p2 already?

        • Utkarsh Dixit 6:57 pm on March 7, 2014 Permalink | Log in to Reply

          Yes, i’ve already read the entire history of posts. In the ideas page the objectives weren’t specified clearly and i don’t know whether or not you were active on the mailing list, so had to comment here

        • Utkarsh Dixit 7:42 pm on March 7, 2014 Permalink | Log in to Reply

          I’m also going through the codebase of the current plugin available for omnisearch. Hoping to work for the search initiative :)

      • Utkarsh Dixit 4:51 am on March 9, 2014 Permalink | Log in to Reply

        Hi sir,
        Can you suggest me some other improvements that you would like to see in the search initiative. Even the ideas that haven’t yet been planned or thought of completely. Hope that I will be able to complete most of them :)

      • Utkarsh Dixit 5:50 pm on March 9, 2014 Permalink | Log in to Reply

        Hi sir,
        This includes all the patches I have worked on till now, including the patch for asynchronous search. Please look into it. Its my first time contributing to WordPress so my code might not be upto the par or possible full of bugs. Please suggest changes, approaches, ideas anything that you think might help me.

        https://github.com/utkarshd420/omnisearch-patch/

    • Utkarsh Dixit 5:06 am on March 8, 2014 Permalink | Log in to Reply

      “the biggest task at present seems to be unifying all the search forms in the administrative interface to feed into a global search ”

      We could already use the code given for omni search plugin and could probably change the action parameter of each search form in the admin panel with a hidden input of

      <form id="posts-filter" action="” method=”get”>

      Plugin should be activated for this… Therefore we can use the plugin already build to unify all the search fields in the admin panel..
      is this approach feasible? It works well (I’ve tried for the search posts form)..

    • Utkarsh Dixit 2:18 pm on March 8, 2014 Permalink | Log in to Reply

      I’ve also tweaked the codebase ,of the plugin, a little now it shows the the no. of posts (if found).. Not much a change, but now I have the basic understanding of the way this plugin works.. Waiting for some further updates :)

    • Utkarsh Dixit 11:16 am on March 9, 2014 Permalink | Log in to Reply

      Trying to include the suggestions of posts to search in the plugin too, using AJAX to do it… I’ll share the patches one it’s completed. Hoping to complete it soon.

      • George Stephanis 9:56 pm on March 9, 2014 Permalink | Log in to Reply

        Howdy.

        Sorry for the delay getting back to you, just a bit overwhelmed with other stuff this weekend.

        I’ve actually just added you as a committer to the plugin itself — it’s terrific to see someone eager to start working on it.

        I’ll respond in more detail to the above tomorrow! :)

      • George Stephanis 9:57 pm on March 9, 2014 Permalink | Log in to Reply

        I would suggest in the interim, though, to read up on Core’s Coding Standards and Styles — things like including spaces, and always using braces for conditionals as an example.

        http://make.wordpress.org/core/handbook/coding-standards/php/

        • Utkarsh Dixit 7:15 pm on March 10, 2014 Permalink | Log in to Reply

          Thanks for the link. Have gone through all the coding standard. Will use them from the next time. :)

          Sir, will you be attending this?
          http://make.wordpress.org/core/2014/03/10/gsoc-irc-chats/

          • George Stephanis 9:18 pm on March 10, 2014 Permalink | Log in to Reply

            Yup, I’ll be there. :)

            • Utkarsh Dixit 4:49 pm on March 11, 2014 Permalink

              Hi sir,
              Was going across the IRC chat logs when came upon this

              ” often our search acts more like a filter — if I search for “Jaquith” on the posts screen I see a listtable of posts, it doesn’t say what context (or even necessarily what matched if not the title) in the results ”

              I tried making a patch for it… If the search term is in the post or the content of the page it is displayed as

              $title
              …..something something something $search_term something something something….

              In each row.
              I had to tweak the wordpress codebase a little ( WPINC\class-wp-posts-list-table and WPINC\class-wp-list-table)

              Will upload the patch soon and provide the link on this forum :)

            • Utkarsh Dixit 6:15 pm on March 11, 2014 Permalink

              There is a slight mistake in the earlier comment I had made changes in wp-admin/includes/ and not in WPINC. Sorry for the above mistake.

    • Utkarsh Dixit 7:09 pm on March 11, 2014 Permalink | Log in to Reply

      https://github.com/utkarshd420/omnisearch-patch

      Also updated the patch I have explained here:
      http://make.wordpress.org/core/2014/01/15/search-initiative-on-hold/#comment-13044

      Hope you will look into it :)
      Please provide me feedback, bugs and further approaches you would like the search initiative to have. :)

      PS: tried my best to adhere to the coding standards might have some deviations though, as its my first time contributing to WordPress. Hope you don’t mind. :)

    • Utkarsh Dixit 7:54 pm on March 12, 2014 Permalink | Log in to Reply

      Hi sir,
      This is in regards with the gsoc chat session.. will you be available between 11:30 am to 8:00 pm UTC, tomorrow i.e. 13/3/2014?
      I would really like to discuss the current patches that I have provided as well as the new approaches that we can take on improving omnisearch.
      Please mention the timings that you will be available at (If you won’t be able to attend during the above time).
      Thanks :)

      • George Stephanis 8:07 pm on March 12, 2014 Permalink | Log in to Reply

        Just joined the channel now, I should be online around that span. I may be idling, so feel free to poke me there, or on #wordpress if ever needed — `georgestephanis`

    • Utkarsh Dixit 6:08 pm on March 15, 2014 Permalink | Log in to Reply

      Hi, couldn’t find you on the IRC Channels so am posting here, following (utkarshdixit11.wordpress.com) is the link to my proposal. please go through it once and suggest me any necessary changes that might be needed. Thanks :)

  • George Stephanis 4:49 pm on December 9, 2013 Permalink
    Tags: , ,   

    Search Initiative Chat Recap 

    Link: http://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 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.

     
    • Scott Kingsley Clark 5:00 pm on December 9, 2013 Permalink | Log in to Reply

      I wonder if exclude_in_search vs include_in_search should be used for interoperability with post type args and the new meta field API we’re working on. What should the default be is the main question here, assume all fields added will get included in searches, or make the default to exclude unless that default is overridden.

      • George Stephanis 5:06 pm on December 9, 2013 Permalink | Log in to Reply

        Possibly instead of having it be a straight boolean, let folks set it explicitly as ‘include’ or ‘exclude’ — and let whatever’s calling them default whichever way it prefers (or to a configurable/filterable value) if not specified?

    • Eric Andrew Lewis 5:34 pm on December 9, 2013 Permalink | Log in to Reply

      Querying post meta data has been a contentious topic. With the current schema and API, querying many meta keys with a search term will not perform well at scale.

      I’ve heard lead developers say that creating complex queries on post meta is doing it wrong (although I can’t find something to cite in that regard), and post meta should exclusively be used for outputting in templates. Although I haven’t heard a top-down recommended alternative to this prickly architectural question. For custom post(/content) types, some projects have invented their own method for dealing with this. BuddyPress uses tables for all of its data objects. Pods creates tables dynamically for custom content types.

      Perhaps a topic to have an IRC summit on, or even its own working group.

    • George Stephanis 1:21 am on December 14, 2013 Permalink | Log in to Reply

      Major apologies, all. I was laid out with a migraine this afternoon and completely lost track of the meeting this afternoon.

  • George Stephanis 9:37 pm on December 4, 2013 Permalink
    Tags: , ,   

    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 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!

     
    • Rouven Hurling 9:58 pm on December 4, 2013 Permalink | Log in to Reply

      Friday or Wednesday evening? think you didn’t write the Shortcode correctly.
      Either way I would love to help with this, but I’m not going to make it on Friday and there seems to be no one in IRC right now, so I guess that means that it’s on Friday.

      • George Stephanis 4:00 pm on December 5, 2013 Permalink | Log in to Reply

        Sorry — I wrote out the [time] shortcode with just the time, and didn’t specify a date, so it seems to keep assuming the current date. Will fix. Yes, I’d meant on Friday.

    • David Radovanovic 10:55 pm on December 4, 2013 Permalink | Log in to Reply

      Please count me in. I would be happy to offer any support.

    • Christian Foellmann 3:38 pm on December 5, 2013 Permalink | Log in to Reply

      I see you are planning on using tabs.

      We already have the assets for horizontal (e.g. network/site-info.php and associated css) and vertical (current help with add_help_tab) tabs but no integration with the Settings API/SomeName API to use it in wp-admin for custom sites.

      How about integrating tabs generation into core to use it in “all these” places?

      • George Stephanis 4:01 pm on December 5, 2013 Permalink | Log in to Reply

        Well, maybe. There’s a lot of ways to do it, and I don’t want to bite off more than we can reasonably chew. I’d love to have you chip in on the implementation if you’d like to tackle the tabs, though.

    • Scott Kingsley Clark 5:46 pm on December 5, 2013 Permalink | Log in to Reply

      I should be around for the meeting, will be representing Metamorphosis since Eric Lewis won’t be able to make it.

  • George Stephanis 10:17 pm on November 11, 2013 Permalink
    Tags: ,   

    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 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 [category]” 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 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! :)

     
    • Scott Kingsley Clark 1:22 am on November 12, 2013 Permalink | Log in to Reply

      I built the Filters plugin to expand on providing a better UX for searching and filtering on multiple fields and taxonomies at once. It uses Thickbox inline but I plan on integrating the Media Modal possibly instead, for a nicer UI with a less buggy popup.

      http://wordpress.org/plugins/filters/

      I would hope that any solution that is built, can support filtering my fields and taxonomies in a better way than it is now.

      • George Stephanis 3:38 pm on November 12, 2013 Permalink | Log in to Reply

        We’d certainly welcome your input as this develops. As someone with prior experience building an addition to the search experience, it’d be invaluable input.

    • Dwain Maralack 6:09 am on November 12, 2013 Permalink | Log in to Reply

      I love the global Admin search bar and think Ajax search should be built in as the has become the standard.

    • RicaNeaga 2:49 pm on November 12, 2013 Permalink | Log in to Reply

      Please consider if a third-party search api is a viable solution (to be included / implemented alongside wordpress installation).

      For example vbulletin now bundles sphinxsearch.com , and they say for large websites (with large databases) this addition is a ”performance enhancement that will allow you to offload search from your MySQL database”.

      • George Stephanis 3:35 pm on November 12, 2013 Permalink | Log in to Reply

        I don’t believe it’s something that we would bundle with core, but — as I remarked above — the hooks will certainly be in place that a third-party provider could provide a plugin to replace or supplement existing results if desired.

  • George Stephanis 10:35 pm on November 4, 2013 Permalink
    Tags:   

    Upcoming Global Admin Search (née Omnisearch) Meeting 

    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:

     
  • George Stephanis 5:11 pm on October 23, 2013 Permalink
    Tags: , , ,   

    Omnisearch / Global Admin Search, Final Pitch 

    Plugin: http://wordpress.org/plugins/omnisearch/
    Diff: https://cloudup.com/cC6IbXxoHXN

    Previous posts:

    http://make.wordpress.org/core/2013/08/14/present-your-3-8-feature-idea-at-tomorrows-meeting/#comment-9948

    http://make.wordpress.org/core/2013/08/30/omnisearch/

    http://make.wordpress.org/core/2013/10/08/omnisearch-user-testing/

    IRC chats in #wordpress-core-plugins:

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-08-30&sort=asc#m21304

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-12&sort=asc#m23506

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-19&sort=asc#m24911

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-26&sort=asc#m25942

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-10-10&sort=asc#m27386

    We were a small, but scrappy group. It was mostly myself, @japh, and @lessbloat.

    Omnisearch currently adds three ways to search.

    • A Dashboard Widget:
      Omnisearch Dashboard Widget
    • An admin page under the Dashboard:
      Omnisearch Admin Page
    • And as a search box on  the adminbar — when you’re on the admin side of the site:
      Omnisearch Admin Bar

    All three turn up the same results page:

    Omnisearch 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.

     
    • Andrew Nacin 6:43 pm on October 23, 2013 Permalink | Log in to Reply

      My suggestions on UI: The search tool in the toolbar is very likely sufficient placement for this. Drop the dashboard widget and the menu item. Add a “Search everywhere” link to each individual search results page in the admin, next to “Search results for “%s”. There’s no reason to force this onto people — just let it be naturally discovered in times of need.

      If no results are found for a section, it may be okay to omit that section entirely, rather than showing an empty table and taking up 100+ vertical pixels. If no results are found at all, it could just be a simple single line of feedback, rather than scrolling through a bunch of empty tables.

      Is the “Search Pages” button/link helpful? They see all of the results here (presumably with pagination). Maybe clicking the name of the section should take them to that particular page (with the search conducted) to allow for filtering and such. Otherwise, it seems like clutter.

      I see that plugins is searchable, along with posts, pages, and media. What about themes? Custom post types? Taxonomies? Settings? Importers? Admin screens & keywords? Etc. (A lot of this came up with @markjaquith was kicking around this exact idea a year or two ago.)

      My suggestions on naming: simply call it “search”. When discussing it in code, call it an admin search or the dashboard search or whatever. “omnisearch” sounds like (and, in Jetpack, is) a gimmicky product name. There’s no need for a tagline. “Search” is a pretty natural and common feature; let it speak for itself.

      Will note that comments are also searched on P2s. Would be more interested in hearing additional use cases for this. I think a lot of it comes down to increasing uses of custom post types. As of right now, since it only supports posts/pages/comments/media/plugins, it’s not really “everywhere” yet.

      I think the feature implementation is pretty close for core — certainly could be smoothed out over the course of a merge.

      • George Stephanis 7:25 pm on October 23, 2013 Permalink | Log in to Reply

        My suggestions on UI: The search tool in the toolbar is very likely sufficient placement for this. Drop the dashboard widget and the menu item. Add a “Search everywhere” link to each individual search results page in the admin, next to “Search results for “%s”. There’s no reason to force this onto people — just let it be naturally discovered in times of need.

        Good call. Depending on how DASH goes, if it ever migrates to a fixed column of static stuff like in this older mockup, it may be worth including this there as a search field. The primary reason for all the avenues was to have them available, then pare them down in the merge.

        Agreed on sacking the widget and probably the menu item. I’m not sure if it would make more sense to have the menu item there if you’re on that page at the time, but hide it if you’re not? Or if that would be confusing from a UX perspective.

        If no results are found for a section, it may be okay to omit that section entirely, rather than showing an empty table and taking up 100+ vertical pixels. If no results are found at all, it could just be a simple single line of feedback, rather than scrolling through a bunch of empty tables.

        I’d prefer the line of feedback, it might play nicer with results sections that load in results after dom.ready via js for latency reasons.

        Is the “Search Pages” button/link helpful? They see all of the results here (presumably with pagination). Maybe clicking the name of the section should take them to that particular page (with the search conducted) to allow for filtering and such. Otherwise, it seems like clutter.

        Actually, just to keep it short, it only displays the first five results (adjustable via a filter) (and possibly would be wise to have customizable in Screen Options). To dig deeper into a given section they need to click the link for that specific section. This also avoids a large degree of confusion as to results page refreshes when paginating — which list table is it paginating? They all use the same query argument!

        A potential down-the-road enhancement would be to enable pagination via js on specific tables, but for the moment, it’s just capped at five.

        I see that plugins is searchable, along with posts, pages, and media. What about themes? Custom post types? Taxonomies? Settings? Importers? Admin screens & keywords? Etc. (A lot of this came up with @markjaquith was kicking around this exact idea a year or two ago.)

        Themes could be, I excluded it initially, as it seemed to me to be a much more infrequent task.

        Custom post types aren’t included by default, as they can have such disparate data structures, that forcing them into a single custom list table may not end well. They’re easy to include, though, like so: https://gist.github.com/georgestephanis/6926206

        Taxonomies, settings, and importers are all feasible, this is just the baseline that was felt to be most useful to the most people, while still keeping the UI reasonably simple. We could always offer them, but have them hidden by default in Screen Options. If that’s the consensus, I’ll add them in.

        My suggestions on naming: simply call it “search”. When discussing it in code, call it an admin search or the dashboard search or whatever. “omnisearch” sounds like (and, in Jetpack, is) a gimmicky product name. There’s no need for a tagline. “Search” is a pretty natural and common feature; let it speak for itself.

        Maybe Global Search then. There’s so many searches in the admin already, that a ‘Search’ label without context could be more confusing than helpful.

        • Raam Dev 7:32 pm on October 23, 2013 Permalink | Log in to Reply

          Maybe Global Search then. There’s so many searches in the admin already, that a ‘Search’ label without context could be more confusing than helpful.

          I also vote for ‘Search’. Putting ‘Search’ on the Dashboard tab provides the necessary context and helps indicate that we’re not searching any one particular section but rather the whole site.

    • Sam Sidler 6:48 pm on October 23, 2013 Permalink | Log in to Reply

      A few questions:

      • What was the rational for putting Omnisearch under “Dashboard” in the admin? Not saying it’s the wrong place, just curious if other places might make more sense, especially since it’s permanently located on the top right of the admin interface.
      • Why only show the search box when you’re on the admin side? Other than “Edit Post”, it would be the only thing that changes between admin side and not.
      • Related: Why show the entire box instead of just a search icon? Whoops, I realized I misunderstood this. :)
      • Does this search custom post types? I’d take off the “search everything” tagline if it doesn’t search literally everything.

      Otherwise than those questions, looks like good work. I’m on the side of Omnisearch being a bit too gimmicky, but would love to hear what others think.

      • George Stephanis 7:32 pm on October 23, 2013 Permalink | Log in to Reply

        RE: under Dashboard in the admin, it’s legacy that I worked up initially. In Jetpack, it’s under the Jetpack menu item, but when merging it into WPCOM, I didn’t have that available, and put it under Dashboard. I’m not particularly attached to it, and would be happy to drop it from the menu as mentioned above.

        RE: why only the admin side, that was because the search in the admin bar is already there on the front-end, and I didn’t want to change that form’s behavior. If other folks would rather have adminbar search be Omnisearch at all times, I’m fine with that as well — we’d just need a fallback or capability check if logged out users had it displayed to them.

        RE: CPTs: It can, I had just intentionally left them off initially due to the disparate data structures they can represent, with the bulk of it potentially in postmeta — I wasn’t sure how well it would search them, and if displaying them in the list table would look in any way reasonable or representative of what they’re storing.

        • Sam Sidler 7:53 pm on October 23, 2013 Permalink | Log in to Reply

          RE: why only the admin side, that was because the search in the admin bar is already there on the front-end, and I didn’t want to change that form’s behavior. If other folks would rather have adminbar search be Omnisearch at all times, I’m fine with that as well — we’d just need a fallback or capability check if logged out users had it displayed to them.

          It feels like strange behavior for the search icon in the admin bar to have two different behaviors, depending on the view. I’d be interested to see what user testing would say on that. Easy enough to change anyway.

          RE: CPTs: It can, I had just intentionally left them off initially due to the disparate data structures they can represent, with the bulk of it potentially in postmeta — I wasn’t sure how well it would search them, and if displaying them in the list table would look in any way reasonable or representative of what they’re storing.

          I think they should get included, but you said above (and showed!) that it’s not hard to add. Perhaps we can wait for feedback post-merge.

    • Bryan Petty 7:20 pm on October 23, 2013 Permalink | Log in to Reply

      As far as the admin bar search goes, what are your thoughts about the fact that there is already currently a search bar on the admin when browsing the frontend on a site, which pulls up the regular search results page on the frontend. I know you’ve stuck with keeping the search on the frontend the same as it is now, but do you think that behavior should change for an admin/editor/author? How might that be affected by roles and capabilities?

      @sams Does your theme you tested with this not have search?

      Also, not just “gimmicky”, but I think calling it “Omnisearch” instead of just “search” is actually detrimental once it’s considered the official built-in search functionality (as opposed to begin able to identify it as an add-on provided by Jetpack).

      Also, I get this fatal with the plugin (with *multisite* WP trunk):
      “Fatal error: Call to undefined function wp_is_mobile() in /home/bryan/Projects/wordpress/src/wp-content/plugins/omnisearch/omnisearch-core.php on line 14″

    • memuller 5:11 pm on October 24, 2013 Permalink | Log in to Reply

      About the name, I think just “search”, as nacin suggested, might work.
      @georgestephanis, while I agree that it may be confusing given the presence of many “search” functionalities, I believe that’s an issue with the other search functionalities, not with this one. Since this search will be the de-facto admin search – that is, it will be enough in most cases – it makes sense for its name to be just “search”. The “global” here is unnecessary – the name “search” should be reserved to the most general and useful case possible, and this plugin is that case. Aditionaly, “global” implies the existence of more types of search – which is the case, but the user does not need to be exposed to that confusion so early.

      The issue, them, is to make sure that all other search functionalities are named differently; that all instances of “[custom post name] search” or “theme search” are always named in such way as to make clear that they are more limited in scope or functionality.

      Omnisearch is inadequate for the same reasons – the name won’t be a selling point for this feature, so a descriptive, simple name wins. That name would – for example – be a pain to I18N teams.

      Otherwise, this is awesome – it will greatly help finding stuff in huge sites; and the API for including custom posts is looking good. I really hope to see this on 3.8.

    • George Stephanis 9:01 pm on October 24, 2013 Permalink | Log in to Reply

      Okay, got two changesets in just now.

      http://plugins.trac.wordpress.org/changeset/793194/omnisearch
      http://plugins.trac.wordpress.org/changeset/793196/omnisearch

      To-accomplish yet, based on feedback from above:

      • Drop the table output from empty result sets.
      • Add in the links to “search globally for %s” to the end of the normal archive tables when a search has been performed.
      • ???

      Current version is 0.9, installable from http://wordpress.org/plugins/omnisearch/

    • Gregory Cornelius 7:35 pm on October 27, 2013 Permalink | Log in to Reply

      Nice work.

      I wasn’t exactly sold on the idea initially, but seeing the search a bit more tightly integrated with the admin UI instead of just hanging out under Dashboard, its potential is starting to emerge. UX-wise I sorta wish that the results were more unified and less of a direct reflection of the data schemas. Perhaps, all post-like content could be combined into a single group in a manner not unlike how search results are handled in the Link modal in the visual editor. It would also be nice if the results could be re-ordered by clicking the table headings or maybe even experiment with removing the headings.

      Thinking about the search field, I wonder if some sort of autosuggestion of results built from matches on post titles across post types with a “Show All Results” link at the top of the list. This would make the dashboard feel a lot more responsive for power users that are used to using search tools like Spotlight, Alfred, Quicksilver, or even the new Window 8 thingy. Eventually, I could even imagine the results including the results from the content of the various admin screens, especially the settings. It would be kind of neat if searching “Disable comments” included a link to the Discussion Settings.

      Maybe the search bar could also be integrated into the new DASH dashboard if/when that component is integrated. And, as the tool becomes more refined and useful, I think it would be nice if the field somehow became a bit more prominent in the admin bar. At the very least, it would be nice if the animation to open the field was a lot faster.

    • George Stephanis 8:37 pm on October 27, 2013 Permalink | Log in to Reply

      Just upped the plugin again. Posts/Pages are now decended from the WP_Posts_List_Table class, which lets a lot of stuff like custom columns and displaying taxonomies work out of the box. I’m about to auto-include custom post types as well, if their UI is exposed in the admin.

      Also switched it so it displays a blurb, instead of an empty table, if there’s no results. Also skips the link to search that data type in more depth if there was no results.

    • sandeepbagchi 7:48 am on October 31, 2013 Permalink | Log in to Reply

      Is it possible to add filters for searching?
      Date Search: “Search To And Search From”
      Search In Category: dropdown with multiple selection
      Search In Posts or Search In Pages or Search In Available Custom Post Types (drop down with multiple selection)

      After taking all the inputs a query can be formed to refine the search?

    • Sarah Gooding 8:02 pm on November 11, 2013 Permalink | Log in to Reply

      Is it possible to include an auto-suggest while typing and load results via AJAX instead of whisking the user away onto another page – similar to how it’s done in the http://wpjarvis.com plugin (see demo on that page)? This seems like a more elegant implementation. I understand that there’s a lot of data to show in the results but if there was any way to make it more compact I think the experience would be improved. Of course, I may be missing a lot of the complexity involved here…

  • George Stephanis 1:07 pm on October 8, 2013 Permalink
    Tags: , user testing   

    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: https://www.usertesting.com/videos/dQBRyueQ9EsMAv1OsQrQmg%3d%3d?back=%2Fdashboard%3Fnew_study_id%3D%23study_905321

    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)

     
  • George Stephanis 4:00 pm on August 30, 2013 Permalink
    Tags: , ,   

    Omnisearch! 

    Howdy, folks!

    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.

    Interested parties include @japh, with @lessbloat helping to design some user testing to determine its usefulness as a part of core.

    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' ) ) ] :

    http://wordpress.org/plugins/omnisearch/

     
    • George Stephanis 9:23 pm on August 30, 2013 Permalink | Log in to Reply

      First meeting was just @lessbloat and myself, discussing how to properly test.

      It looks like the plan is going to be to get a dummy install together with a large set of sample data, and deliver some tasks to find content. Some will be directed at finding media, some may be directed at finding a specific post or comment, and some may be at finding a snippet of text with no context as to where it may be.

      Once done, we’ll see which completion paths the user tried to take to accomplish the tasks.

      Then we’ll test again, but with Omnisearch available. Probably with some subtle hints to it, but certainly not enough to spell out exactly how they do it. I’d like to add in a couple new ways to access Omnisearch, such as a dashboard widget, and see which paths (admin bar search, menu item, dashboard widget, or other) the users use to get there. If there is a clear preference to one over another, let’s make sure it’s available in the final result.

      For now, I’ll be getting the content ready to import into a dummy site to test with early next week, around Tuesday-ish. We should have some data and results next week.

  • George Stephanis 5:19 pm on May 3, 2012 Permalink
    Tags: android, mobile, target devices, ui enhancements   

    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.

    Target Devices

    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.

    Resolving Incompatibilities

    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.

    UI Enhancements

    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.

     
    • Isaac Keyet 6:27 pm on May 3, 2012 Permalink | Log in to Reply

      Great work guys, looking forward to everyone having this. Tablets are here to stay!

    • donnacha 6:47 pm on May 3, 2012 Permalink | Log in to Reply

      I am grateful that work is being done on touch UI, it’s definitely the future, but … the Kindle Fire at 50% of Android tablets? Seriously?

      It is disturbing to hear that scarce dev resources are been allocated based upon comScore figures, they are an industry joke and base their numbers upon a highly suspect interpretation of private page view data. Their MO has always been to drive forward their main business, which is essentially an extortionate racket against websites, by generating sensational headlines and anything Apple-related is a sure-fire hit.

      IDC today released their figures, based upon actual shipments: iPad is 68% of the entire worldwide market of 17.4m tablets, the Fire is 4% (around 15% of Android tablets) and is soundly beaten by Samsung in 2nd place.

      http://www.idc.com/getdoc.jsp?containerId=prUS23466712

      Again, I am grateful that this work is being done but you should wait until at least six months before anointing any new tablet as a sort of standard, especially as Amazon have not even revealed how many post-Christmas returns they received.

      It is also worth noting that the upcoming Fire 2 is rumoured to be radically different machine i.e. the first Fire was a rush job to catch the Christmas market, the 2 may follow a very different design philosophy and that would put your UI decisions back to square one.

      I’ve never seen a Fire or Samsung tablet in real life but I presume that Samsung are running a less proprietary and, therefore, more representative version of Android than Amazon, why not target that instead?

      • George Stephanis 7:58 pm on May 3, 2012 Permalink | Log in to Reply

        While we had the Fire and iPad as our ‘target’ devices, please don’t misunderstand this as stating that they are the only devices that we paid any attention to.

        All our work is based on coding web standards — building for the future of the web so that the work we do today is maintainable and will look just as good (if not better) tomorrow. When we say that something is a ‘target device’ it just means that these are the devices that we’re making the conscious decision to purchase and test thoroughly on. I can tell you that we’ve also done a great deal of testing in a number of other Android tablets, BlackBerry Playbook tablets, Android Phones, and Windows Phone 7/7.5 devices.

        The reason for the Fire being a target device was that it was more likely to need a bit of special attention to get it up to working order. The native browser that comes bundled with stock Android works beautifully, but the bundled Amazon Silk browser has some problems, to put it graciously, primarily due to running an outdated version of WebKit as the rendering engine. There’s also a lot of missing CSS3 properties. If anyone would like to contact Amazon, one of the people to speak with would be Jon Jenkins ( twitter: @jonjenk ) — he does a lot of work on their Silk browser.

        Regarding your IDC citation, I’d be very intrigued to learn what devices they are including in their tablet calculations — the significant bump for Samsung may very well be due to the release of the Galaxy Note, which could have been more aptly lumped in with tablets than phones.

        • donnacha 8:31 pm on May 3, 2012 Permalink | Log in to Reply

          Thanks for clarifying what was meant by ‘target’ George, I took the other meaning but, yes, I can see that you would need to target extra attention towards the quirks of the Fire and the unique nature of Silk, even if it is not the leading Android tablet.

          I’m not actually sure what product lines were included in the Samsung numbers, I’m only going on the press release that I linked to, but I agree that the term “tablet” should only really include screens 7″ and up, the Note at 5.3″ strikes me as more of an overgrown phone than a tablet.

          The distinction between comScore and more reputable operations such as IDC is, though, still important to bear in mind when you are making decisions. One conducts closed box surveys heavily skewed towards people dumb enough to waste their time on incentivised surveys, the other does it’s best to jigsaw together an accurate reflection of reality based upon available shipping data.

          • George Stephanis 8:37 pm on May 3, 2012 Permalink | Log in to Reply

            Just for reference, the target devices were decided at some point before January 11th, when they were announced at the weekly dev chat.

    • Emil Uzelac 7:04 pm on May 3, 2012 Permalink | Log in to Reply

      Great job indeed, fantastic stuff. Keep up the good work.

    • Dan 9:24 pm on May 3, 2012 Permalink | Log in to Reply

      just disable the visual editor if the browser doesn’t support it

      Big win, I’ve worked with a lot of users that were frustrated that the editor didn’t work on their older Android devices. Nice job!

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel