WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: 3.8 proposal Toggle Comment Threads | Keyboard Shortcuts

  • Mel Choyce 7:43 pm on October 23, 2013 Permalink
    Tags: , 3.8 proposal, , mp6   

    MP6 — 3.8 Proposal 

    The WordPress admin has not had a major visual overhaul since 2.7, and its age is starting to show. In a rapidly changing web environment where users are starting to expect good design, we need to make sure that our aesthetics match — better yet, exceed — their high expectations.

    MP6 is a movement towards modernity. It is an exploration into the infinite possibilities that exist for improvement within our existing framework. It is a tenderly crafted visual update to the admin that we all know and love. MP6 is the future.

    Screenshots

    What problems are we trying to solve?

    The current wp-admin has:

    • An outdated visual appearance.
    • Outdated technology.
    • Low contrast.
    • Suboptimal readability.

    We’ve solved these problems with the following:

    Modern aesthetics

    • Open Sans — a font as free as we are.
    • Cleaner styles — goodbye decoration, hello simplicity. Affordances still welcome.
    • Let it breathe — increased spacing between elements, which allow for better overall hierarchy and whitespace to guide the eye.

    Improved contrast and readibility

    • Higher contrast dark default color scheme — great for eyes of all ages.
    • Lower contrast light default color scheme — helpful for those with dyslexia and sensitivity to light.
    • Refined typography — larger font sizes, crafted with better readability in mind.

    Future-forward

    Inherently HiDPI

    • Vector icons — beautiful and crisp at any resolution.
    • CSS effects instead of images — cleaner, faster, and more flexible.

    Responsive

    Why MP6?

    Results

    While we haven’t explicitly user tested this new skin, it’s been running on WordPress.com for months with minimal issues. The same old WordPress admin functionality is still there, just with a fresh coat of paint.

     
    • lessbloat 7:56 pm on October 23, 2013 Permalink | Log in to Reply

      Let me be the first to say:

    • Nile Flores 8:12 pm on October 23, 2013 Permalink | Log in to Reply

      I like the idea of the color choice, but personally… I’d like the color choices to go further. I’m using my own version not too far off from this idea using my own brand’s signature colors.

    • Daniel Bachhuber 8:12 pm on October 23, 2013 Permalink | Log in to Reply

      Looking good! One programming note: Shouldn’t the screenshots be uploaded to WordPress to prevent link rot?

    • Daniel Bachhuber 9:14 pm on October 23, 2013 Permalink | Log in to Reply

      I’d like to pitch an idea I’ve been mulling over for the last week: MP6 as WordPress’ (Twitter) Bootstrap for the admin.

      For those not in the know, Bootstrap is a collection of UI / UX patterns, and their corresponding CSS / JS. The goal for Bootstrap is to make it much easier to get your web application up and running — many common UI / UX problems are solved for you. Want a login form? Boom. Want a modal? Bam.

      As a plugin developer, I poach from WordPress admin UI elements as often as I can. For instance, button primary is a godsend. Laziness is probably the primary reason, but consistency is probably more important. As you can find going through the Bootstrap website, there are many UI / UX patterns not defined in the WordPress admin that could be defined in MP6.

      It would, clearly, be additional work. I think taking on the work could provide these advantages:

      • Promote greater UI / UX consistency between core, plugins, and themes. A usable style guide seems like a reasonable, reachable outcome.
      • Clean up rough edges in existing styles. Making your code reusable, and having others use it, is guaranteed to improve the quality.
      • Make my life much easier.
      • Manny Fleurmond 9:16 pm on October 23, 2013 Permalink | Log in to Reply

        A reference for the dasicons would also be nice

        • Mel Choyce 10:20 pm on October 23, 2013 Permalink | Log in to Reply

          We have an unofficial guide here: http://melchoyce.github.io/dashicons/ (It’s missing a couple recent changes, I’ll be updating it soon)

          @helen mentioned the MP6 style guide below. @ryelle created an MP6 helper class page for hooking into color schemes within the MP6, and it could also be a good place to integrate a dashicons reference and instructions page.

      • Helen Hou-Sandi 9:19 pm on October 23, 2013 Permalink | Log in to Reply

        This is what I have been talking about for quite a while and have started to work on, but it’s a slow road when you’re alone.

        P.S. define(‘MP6_STYLE_GUIDE’, true);

      • Mel Choyce 10:20 pm on October 23, 2013 Permalink | Log in to Reply

        + 1,000,000

      • saas 5:09 am on October 24, 2013 Permalink | Log in to Reply

        I would be happy to see “(Twitter) Bootstrap” being a core of admin UI, it will surely make life of dev’s like me much easier (frankly I also find current UI based on .scss files quite easier to use, special thanks to @ryelle for providing .less version of for dev’s like me, keep up the good work @ryelle)

        But it would be good if we could and should or would use “Twitter Bootstrap” for core admin UI, it will bring a standard for not only admin UI but also will provide a guideline for building frontend UI, which will not be possible if we keep working on existing UI files (MP6), we will have to adapt it in a way, so we can bring more than just a rapid prototyping or ease of use.

        As we all know its been a dream for us to customize not only frontend / login screen but also admin UI to match the client website’s color scheme and brand. Which MP6 started to resolve but to seriously considering MP6 to be a part of core, we should bring all the tools (from gurus toolbox) on the wordpress table and pick the right tools for future of wordpress UI (admin, login screen, themes, plugins) and bring harmony between these so we can represent clients brands better.

        While we are on the UI topic, I would like to throw another suggestion out in the wild regarding which is regarding “UI Builder or Page Builder” it will be awesome if we could build such thing in core and using “Twitter Bootstrap” as a core UI framework with help build “Page Builder” a solid solution for our current UI building (generator) needs.

        I remember reading article regarding “Page Builder” being built for core but don’t remember it’s url, but I am sure you guys already know.

        So +!o,000,oo to Twitter Bootstrap :)

      • Scott Kingsley Clark 1:43 pm on October 28, 2013 Permalink | Log in to Reply

        Where do I send all of my +1′s? I’ve got a bag full just for you!

    • @ubernaut 12:51 am on October 24, 2013 Permalink | Log in to Reply

      hey everyone finally got a chance to put together my comments regarding the space efficiency issue i have been talking about in the office hours. While i do appreciate the concept of more white space i think that the removal of all of the separators does to some extent create a significant amount of whitespace in and of itself i believe it is possible to have the best of both world so to speak, anyway here is my post:

      http://ubernaut.wordpress.com/2013/10/21/mp6-the-other-side-of-the-coin/

    • Amy Hendrix (sabreuse) 3:20 am on October 24, 2013 Permalink | Log in to Reply

      I sometimes forget MP6 isn’t already the real admin. Totally in favor of getting it merged ASAP.

    • Gage Morgan 1:21 pm on October 25, 2013 Permalink | Log in to Reply

      You guys can’t ditch this idea like you did the Custom Post Formats UI. This NEEDS to be released in Core 3.8.

    • jeffr0 12:57 pm on October 28, 2013 Permalink | Log in to Reply

      Concerning MP6, color styles and custom menu icons. I’m using MP6 with the Midnight color scheme and although they don’t look terrible, the custom menu icons for some of the plugins I’m using don’t look very well. They look better or worse depending on the color scheme used.

      http://i2.wp.com/www.wptavern.com/wp-content/uploads/2013/10/CustomIcons.jpg?resize=146%2C243

      What can I do to inform plugin developers that they will now need to update their menu icons so that they look good with the different color schemes provided by MP6?

    • Central Geek 4:05 pm on October 28, 2013 Permalink | Log in to Reply

      WordPress is evolving, that’s for sure. I wasn’t too impressed with the MP6 plugin at first, but it is coming along very well. I think it would be great merge into WP core.

    • Helen Hou-Sandi 5:06 am on October 29, 2013 Permalink | Log in to Reply

      I moved development of the component + style guide thing to GitHub, as it’s more suited toward a developer-specific portal and isn’t meant for end user distribution: https://github.com/helenhousandi/wp-style-guide

    • mrwweb 4:08 pm on October 30, 2013 Permalink | Log in to Reply

      Can someone clarify whether this is nominating MP6 with or without the recently-added Widget admin changes? Until recently, that was its own project.

    • Ipstenu (Mika Epstein) 9:05 pm on October 30, 2013 Permalink | Log in to Reply

      Is there any way to have the toolbar reflect the css colors on the front end? It’s always black, and I kinda want to see sexy seaweed up front. :)

    • godhulii_1985 3:41 pm on November 1, 2013 Permalink | Log in to Reply

      User feedback:

      Is there any way that current leftmost column menu will retain its colour? (#21759B or #333333) All the left menu panel colours here were hurting my eyes. It would be better if current colours also exist in new colour schemes.

    • padelisspart 1:44 pm on November 2, 2013 Permalink | Log in to Reply

      OMG, So beautiful!!!

    • OriginalEXE 10:48 pm on November 5, 2013 Permalink | Log in to Reply

      First of all, I am all for this change, please add it to 3.8

      Next, I have one question. Will ‘mp6-highligh’ class change it’s name if this would be merged to core? I am asking because I am building interface now and would like to use ‘mp6-highlight’ class so that active item in the interface would adjust based on the color scheme chosen in the users profile.

      Thanks

    • LoweryAustin 7:03 pm on November 6, 2013 Permalink | Log in to Reply

      I am really enjoying MP6 so far but I found a bug in the css with Tinymce Split buttons. I wanted to share the fix so I wrote a post on it here:
      http://austinlowery.com/mp6-css-bug-with-tinymce-split-buttons/

      Is there a better place to file a bug report on this?

    • Ipstenu (Mika Epstein) 10:04 pm on November 6, 2013 Permalink | Log in to Reply

      Just ran into a layout ugly with Importers

      http://cl.ly/image/1n1i2d362A2I

      Does not happen on Plugin installs (the pop-in looks fine)

    • Rajesh Namase 12:07 pm on November 10, 2013 Permalink | Log in to Reply

      So nice, now users can choose different colors for dashboards. Font also looking nice,

    • keha76 8:03 am on November 13, 2013 Permalink | Log in to Reply

      I think that it’s an overall improvement that is really needed! But the admin menu feels unorganized without any menu dividers at all, a thin subtle gray 1px line would do it just fine.

  • lessbloat 7:40 pm on October 23, 2013 Permalink
    Tags: , 3.8 proposal, ,   

    DASH – 3.8 proposal 

    Prerequisite: Must have latest version of MP6 installed and activated.
    Plugin link: https://github.com/growthdesigner/wp-dash

    Visual comparison

    The existing dashboard (the page you see by default when you log into WordPress) looks like this:

    It hasn’t been touched in years, leaving it feeling a tad bloated, and dated. Here’s what the dashboard looks like with our plugin enabled:

    What’s changed?

    We tackled 5 major areas, and made them each separate includes within our plugin (separate php, js, and css files).

    • We combined “WordPress Blog”, “Other WordPress News”, and “Plugins” to form the new simplified “WordPress News” plugin.
    • We merged “Recent Comments” into the new “Activity” widget, which now also shows you any scheduled posts and your most recently published posts.
    • We converted “QuickPress” into “Quick Drafts” putting the emphasis more on drafting ideas than publishing, and we merged in “Recent Drafts”.
    • We removed the “Number of columns” screen option. Instead the dashboard is now responsive, and shows the appropriate number of columns based on your screen resolution.
    • The Right Now widget was visually reduced.

    Here are a few extras:

    • We removed incoming links (which doesn’t seem to really work anymore).
    • We replaced the “Dashboard” H2 title with a fun group of friendly welcome text and idioms.
    • We added a bunch more hooks for greater extensibility from any of the dashboard widgets.
    • There’s a fun little smiley if you delete all posts and comments

    What problem is your feature plugin trying to solve?

    While functional, WordPress’ dashboard page hasn’t kept up with the rest of WordPress. We mean to improve the experience of the first page of WordPress. Streamline it, clean it up looking at all the widgets, and make it responsive.

    We’d also love to see future development in the new activity widget, where plugin developers can add more “activity stream” related content.

    What other potential solutions did you explore?

    If you work backwards through http://make.wordpress.org/ui/tag/dash/ you’ll get a pretty good idea. We met weekly in IRC, and brainstormed/iterated daily via our Skype channel.

    Have you done user testing?

    Nope, but if this get’s the “all clear”, we’re more than happy to do that.

     
    • Brandon Wamboldt 10:11 pm on October 23, 2013 Permalink | Log in to Reply

      Your GitHub link has no link in the href attribute and just points to the current page…

    • Mel Choyce 10:25 pm on October 23, 2013 Permalink | Log in to Reply

    • Louy Alakkad 10:24 am on October 24, 2013 Permalink | Log in to Reply

      Amazing, I like the idea. Except the H2 thing :)

    • portfola 5:21 pm on October 24, 2013 Permalink | Log in to Reply

      This is way cool, thanks!

    • memuller 6:18 pm on October 24, 2013 Permalink | Log in to Reply

      I’ve been testing this plugin on my WordPress network for a couple of weeks. I didn’t collect hard data, but I’ve heard a few things informally.

      Feedback has been, broadly, of three kinds:
      – people don’t notice the change unless it’s mentioned; but once they do, they’re happy about it.
      – people don’t notice the change, and are neutral about it – they think it’s not a significant improvement, or that they won’t use it anyway.
      – people notice the change, and are happy about it.

      I think that not noticing the change is an issue, but it’s hard to avoid that – most users in this installation are already “trained” to ignore the Dashboard, since it’s not useful for them (without custom widgets).

      Some users noticed the change due to the absence of the “Right Now” widget and its characteristic coloured numbers for comment status – apparently, they draw the eye more than I thought.

      It’s interesting to note that, once I started using MP6 in this same network many months ago, quite a few users mentioned how the dashboard looked “clunky” and outdated when compared to the much more modern interface.

      Overall, I’m quite happy with the results. I liked some of the initial ideas for this project a lot, but most of them were discarded in favor of a less groundbreaking approach – which was a good move (albeit a sad one); since the result now is a clear, faultless, solid and expansible improvement. It’s hard to argue against it.

      • lessbloat 6:49 pm on October 24, 2013 Permalink | Log in to Reply

        This feedback is amazing! Thank you for being so detailed/descriptive. I feel like you summed it up really well in your final paragraph. While I would have loved to have had some of that other stuff as well, I’m content to see this as a good stepping stone for even more awesome stuff down the line.

    • Eric Andrew Lewis 10:06 pm on November 3, 2013 Permalink | Log in to Reply

      The changes here all make sense to me.

    • demoman2k10 3:17 pm on November 22, 2013 Permalink | Log in to Reply

      Love all the changes please tell me someone is looking at an overhaul of the Plug-in… This is way outdated and would be great to have some better abilities to SEARCH Plug-in’s by Support for version, Newest and other methods. Would like to see it work and function more like one of the stores offered by Apple, Microsoft or Google even. A section for paid and free would be nice as well. As nothing is more frustrating then downloading something that doesn’t work unless you pay for it.

    • codel1417 1:36 am on November 25, 2013 Permalink | Log in to Reply

      the new dash which shows up in 3.8 beta 1 is now even more useless. at least an option to add multiple rss feeds to the dashboard in seperate boxes. i used the other wordpress news box but never cared for the wordpress updates box or the plugins and now its kinds forced apon me

    • allm 2:22 am on December 15, 2013 Permalink | Log in to Reply

      “We removed the “Number of columns” screen option. Instead the dashboard is now responsive, and shows the appropriate number of columns based on your screen resolution.”

      Well, the way it is build now does not feel like the appropriate number of colmns is chosen. If the admin-area shows up on a wide screen and there are only 2 active columns, I still see 4 columns. The 2 on the right are not used, and the 2 on the left are really narrow.

      Actually, if I decrease the width of the browser window to the point where there are only 3 columns my active columns are getting wider.

      I would propose either:

      . get the ‘number of columns’ screen option back
      OR
      . set the appropriate number of columns as is done now BUT NEVER MORE THAT THE ACTUAL NUMBER OF COLUMNS.

  • Matías Ventura 7:34 pm on October 23, 2013 Permalink
    Tags: , 3.8 proposal, , thx38   

    THX38 “Theme Experience” Overview 

    Re-imagine a theme experience that is beautiful, visually focused (able to display more/bigger screenshots), fast, and mobile-ready. Plugin url: http://wordpress.org/plugins/thx38/

    Initially we were covering themes.php and install-theme.php. Time and dev resources constraints forced us to focus the last few weeks solely on getting themes.php fully ready.

    Screen Shot 2013-10-23 at 5.18.19 PM

    Screen Shot 2013-10-23 at 5.18.29 PM

    Screen Shot 2013-10-23 at 5.18.44 PM

    Problem Solving

    Problems:

    • A very text and information heavy interface for something that is eminently visual.
    • Convoluted presentation of your current theme, your installed themes, and adding new ones.

    First user test with current admin interface showed the amount of time between arriving at themes.php and understanding what was going on (which themes are installed, how to add new ones, etc) was quite big, going to the install themes screen took them ages. In contrast, tests ran with the THX plugin showed us the interface was grasped very fast, and people got to the install themes page in a matter of seconds.

    Solutions:

    • Moved theme descriptions to a details overlay, and streamlined the presentation to its bare bones.
    • Removed tabbed interface and made adding new themes organic to the grid presentation.
    • Focused on perceived performance, made theme browsing and search faster, with a fully responsive design at all stages.
    • Added url triggers for opening specific themes, as well as arrow-keys navigation while browsing the detailed view.
    • Added basic support for multiple screenshots per theme, and bigger display.
    • Focus on the customizer as the primary action for your current theme.

    The installing themes screen was left as a prototype for the future.

    User Testing

    Early user testing clearly showed understanding and interacting with the screen is not easy. One user eloquently said, “I was thinking I would have a screen with a bunch of themes to look at.” For install-themes, filters proved to be hard to use paired with the fact the words users think of to describe themes aren’t present in the theme keywords we offer.

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

    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…

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