WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from February, 2013 Toggle Comment Threads | Keyboard Shortcuts

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

  • samuelsidler 11:15 pm on August 14, 2013 Permalink
    Tags: , ,   

    Present your 3.8 feature idea at tomorrow’s meeting 

    Tomorrow’s WordPress 3.8 meeting at Thursday 18:00 UTC is a great time to present your feature idea to the community. Many groups have already started forming around different ideas.

    Comment on this post with a group name to add your group to the list of projects presenting tomorrow. Make sure you bring the following things with you:

    • What problem(s) are you trying to solve?
    • What proposal solution(s) are you interested in exploring?
    • When and where is your group communicating?
    • Who has joined your group so far?
    • If you’ve selected someone to lead your group, who is your lead?
    • If you’ve already started work on your plugin, bring a link to your plugin page.

    See you tomorrow!

     
    • Matt Mullenweg 11:21 pm on August 14, 2013 Permalink | Log in to Reply

      And as many mockups / visuals / links to existing solutions as possible.

    • tomdryan 12:23 am on August 15, 2013 Permalink | Log in to Reply

      It’s not a feature per se, but is there a group looking at global usability improvements throughout WP that would make using WP a more pleasant experience, especially for new and casual users?

      I would happy to lead or participate in such a Usability group.

      • Sam Sidler 12:25 am on August 15, 2013 Permalink | Log in to Reply

        In general, I think you want the UI group. Minor usability updates can take place in any release cycle, including 3.7.

    • Justin Sternberg 12:31 am on August 15, 2013 Permalink | Log in to Reply

      I’m not ready to claim a big-picture group, but we at WebDevStudios have put some time and effort into re-thinking the admin’s widget admin page.
      A good post summarizing our vision, and some proof of concept mockups: http://webdevstudios.com/2013/08/14/webdevstudios-take-on-a-wordpress-core-widget-ui-refresh/
      Our p2 for discussion around the subject, open to the public:
      http://core.webdevstudios.com/
      A github repo with the skeleton of a plugin for iterating:
      https://github.com/WebDevStudios/WordPress-Widgets-Refresh

      There are also other discussions revolving around the subject both new and old.
      Shuan Andrew has some really intriguing thoughts & mockups and even a prototype:
      http://www.shaunandrews.com/
      & has posted a survey for the subject on this blog:
      http://make.wordpress.org/core/2013/08/14/howdy-everyone-theres-been-a-lot-of-discussion/

      Ipstenu has two posts discussing the subject (which we based a lot of our ideas on):
      http://make.wordpress.org/core/2013/08/08/excellent-3-8-brainstorm-session-today-people-talked-about/#comment-9697

    • shaunandrews 12:39 am on August 15, 2013 Permalink | Log in to Reply

      I’ve been thinking a lot about widgets, menu’s, post-formats-as-content-blocks, and a grid-view for the media library. A few links to share for tomorrow:

    • Konstantin Obenland 12:56 am on August 15, 2013 Permalink | Log in to Reply

      Featured Content.
      It is part of Twenty Fourteen and it would finally provide a canonical solution that is portable between themes. I talked to a lot of people in the last week, the group that has assembled around it is fairly impressive, and @wonderboymusic has already updated the base plugin with a first proposal.

    • Ryan McCue 2:30 am on August 15, 2013 Permalink | Log in to Reply

      JSON REST API.

      Working on it for now as part of GSoC, which means only I can write the core code for it at the moment, but there’s tonnes of extras around it that need doing until GSoC ends, and plenty of feedback to get at this stage. @japh, @jshreve, @mzaweb, @mordauk, @coenjacobs, @markoheijnen have all expressed interest in this for 3.8, plus @bpetty and @ericmann who are my current mentors.

      • Ryan McCue 2:35 am on August 15, 2013 Permalink | Log in to Reply

        GSoC’s pencils down date is September 23 (about 6 weeks away), which is when I’ll call the GSoC part done and move on to the core project part. In the meantime, anything out of scope is free game, including multisite, further JS API work, integrated unit tests, and any other new APIs (options? widgets?).

      • Japh 2:36 am on August 15, 2013 Permalink | Log in to Reply

        Yep, would love to get in on this one.

      • Andrew Nacin 3:13 am on August 15, 2013 Permalink | Log in to Reply

        I think this will need more time. Which, by the way, is completely OK. Let’s just be wary of saying “for 3.8″ — it should remain as a plugin until it and core are both ready.

        • Ryan McCue 3:58 am on August 15, 2013 Permalink | Log in to Reply

          Definitely. I’d like to push hard to get it ready for 3.8, but if it ends up slipping then that’s not a big deal, IMO.

        • Bryan Petty 3:58 am on August 15, 2013 Permalink | Log in to Reply

          Right, definitely, but worth mentioning that it could be awesome to see a large focus on this with a full team and lots of eyes.

          This probably should not be happening, but I know there’s at least one mobile project putting bets on this making good progress quickly.

    • Matías Ventura 3:19 am on August 15, 2013 Permalink | Log in to Reply

      Theme Experience for 3.8 and beyond, or THX38 for short.

      To significantly improve and re-imagine the admin theme screens for a better user experience. More beautiful, visually focused, fast, and up to date with the current times of mobile ubiquitousness, flexible resolutions and retina devices. Aiming to bridge the admin themes.php and the .org directory experiences, so that searching for and installing a theme is equally rewarding and consistent no matter where you start. Initial thread. Anyone who is up for this, please, chime in.

    • Mel Choyce 2:37 pm on August 15, 2013 Permalink | Log in to Reply

      Content Editing User Experience (CEUX)

      This group will be focused around streamlining and improving the overall content editing experience in WordPress. We’ll be exploring better methods for curating and formatting content within the post and page editors. We have a preliminary set of mockups that we’ll be expanding and iterating on as we start.

      Currently involved in this group are @wonderboymusic, @saracannon, @DavidHickox, and to a lesser extent @joen will be contributing feedback and ideas. We’ll also be communicating closely with the Page + Menu team. @jenmylo has graciously agreed to advise this group. We’ll be working out a time and place for meetings shortly.

      The content blocks plugin has been set up here.

    • jacob.dubail 3:47 pm on August 15, 2013 Permalink | Log in to Reply

      I was bummed that I missed the last 3.8 meeting. Hoping it’s not too late to get involved. See ya’ll online in a couple hours.

    • Siobhan 5:19 pm on August 15, 2013 Permalink | Log in to Reply

      Admin Help

      This group will focus on creating useful help for WordPress users within the admin. We’ll start by conducting research into the problems that users are having, and research into the tools available to us. We’re also looking into how other platforms implement admin help. Once we have identified the problem we will select the right tools and get to work with mockups then plugin. We have put together some specs for the project, started work on user testing, and looking at tools.

      So far involved in the group are: me, @trishasalas, @jazz3quence, the docs team, and we will be getting input from the accessibility team. Other people who expressed an interested are @japh, @ipstenu, @dllh, @JerrySarcastic, @kimparsell We’ve been using make/docs for discussions so far (under the admin help tag), and will set a regular time for meetings soon.

    • George Stephanis 6:08 pm on August 15, 2013 Permalink | Log in to Reply

      Omnisearch!

      jetpack.me/support/omnisearch

      • George Stephanis 6:26 pm on August 15, 2013 Permalink | Log in to Reply

        DNS has been sketchy, so wanted to get a slug in first.

        History:

        Back when working on 3.5, @lessbloat worked up a new Welcome Screen that we worked on. In the trac ticket, #21368-core, @rhc3 mentioned his Hopscotch plugin that indexed the page’s links to provide suggestions and autocomplete for when someone was having a hard time tracking down what they wanted to do in the menu. It also included hooks to let third parties offer results as well. Some of this functionality was later duplicated by Japh Thompson of Envato, as a part of WP Butler.

        The search functionality wound up getting sacked, but I’ve had the idea of a ‘search-everything’ field in my mind ever since then.

        I built it out, wound up rolling it into Jetpack as a central core, to quickly iterate and make available but it’s built extensibly so any plugin can provide results. I think it’s a terrific UX win, and would like to test it and offer it for inclusion into core.

        • Japh 10:24 pm on August 15, 2013 Permalink | Log in to Reply

          I’d like to be involved with this (obviously, as I built WP Butler to serve a similar function) :)

    • MartyThornley 6:10 pm on August 15, 2013 Permalink | Log in to Reply

      I started a quick plugin as a proof of concept ( very early ) for rethinking the user and site signup and login process, especially concerning multisite. The idea is to consolidate and streamline it all. Also, to make things easier, make the urls more friendly – with /signup, /signin, /signout. https://github.com/MartyThornley/better-signups

    • @ubernaut 6:14 pm on August 15, 2013 Permalink | Log in to Reply

      here’s an idea which may be too crazy and it’s very basic so far no mock ups or anything but basically it to as much as possible do away with the distinction between front end and back end. Inspiration of this idea belong to Matt’s 2013 Stat of the Word speech and the problem of blog abandonment also some belongs to the existence of p2 as well.

      i have found that when teaching people that are new to wp that dichotomy between front and back end (which makes perfect sense to me btw) is a tumbling block and doing away with it may be very beneficial for learning curve.

      Obviously there are some task and admin stuff that would still need to exist but i think it could be very limited fro many user roles.

      • Avryl 12:45 am on August 16, 2013 Permalink | Log in to Reply

        @ubernaut I’d really like to help with this in any aspect. Who’s currently working on this? Are the people here still interested?

        • @ubernaut 5:23 pm on August 16, 2013 Permalink | Log in to Reply

          Great! Well trishasalas also expressed interest and George Stephanis also agreed to help me break down my idea to see exactly what it would take.

          Right now i’m just taking a day or two to think out the different aspects of how i invasion the all to work. mainly the idea i think in my head at least at this point is basically bring all the tools normally only accessible in the admin area to the front end via sort of context sensitive modal overlays.

          i guess i wanted to throw together a few simple mockups together so people could see what i’m thinking. I’m going to try to get a thread started so it will be easier to collect our thoughts on the will update here with a link once i have that going.

      • paaljoachim 2:54 pm on August 19, 2013 Permalink | Log in to Reply

        Frontend editing is an area that really needed to make things easier in learning about how to use WordPress. I helped a friend of mine who uses wix.com and it uses the frontend to edit the page. Wix is more basic but it has two important features: Easy for the user to select a skin/theme/template and from there they use the frontend to edit the skin. There is a video showing some of this on their web site. Incorporating backend features into the frontend is as see it a must. I look forward to helping in whichever way that I can.

        • @ubernaut 10:23 pm on August 19, 2013 Permalink | Log in to Reply

          • paaljoachim 9:54 am on August 20, 2013 Permalink | Log in to Reply

            Hey ubernaut. I see your screenshots and my mind began thinking. I have posted the below on your web site as well:

            Thinking out loud about the process…
            WordPress installed.
            The first thing one sees is the default theme front page. A box up in the right corner to login. The user logs in. The dashboard bar shows at the top. Since it is the first login a link below the login box is seen: “tour the interface.” User clicks and a short video is seen.

            Showing:

            • How to select a theme from the front end. Perhaps a link all the way to the right of the Dashboard top bar with the name of “Choose Theme”. Click the link and see a drop down of small thumbnails and at the bottom of the drop down a see additional themes option. As the user moves the cursor over the thumbnails they are automatically bigger to the side of the drop down showing 2-3 fairly large screenshots with some key info below the screenshots. The user selects a theme and the front end automatically adjusts to show the theme selected.
            • Hover over elements on the page an outline is seen and one can click inside and an edit bar is seen.
            • Drag elements around to replace.
            • Turn on grid to align elements.
            • Click directly on an menu link to move to the page.
            • At the top Dashboard bar click the +New (OR use the Template button next to it to use an existing saved page) to create a post/page/category.

            A blank page is seen and blocks are seen on the right side (depending on if it is a post/page/category). Main elements – Header, menu, sidebar, content, footer.
            Elements (widgets, shortcodes, block elements all in one).
            One drags the various elements to create the page. Click the save button top right to the left of the login area. Beside it is the copy page button on hover it will say save as template.
            Create a new page – and at the top right – save, copy, use template button.

            A lot of these things can be very similar on the backend and frontend.

    • Helen Hou-Sandi 6:23 pm on August 15, 2013 Permalink | Log in to Reply

      New overall admin style, by way of MP6. I will serve as interim lead while MT is on sabbatical.

    • lessbloat 6:31 pm on August 15, 2013 Permalink | Log in to Reply

      Dashboard

      I plan to play around with some ideas for ways to update the dashboard. Perhaps simplify it a bit. Look at ways to possibly make it more easily extensible/customizable.

  • shaunandrews 3:32 pm on August 14, 2013 Permalink
    Tags: , ,   

    Howdy everyone! There’s been a lot of discussion over the last week or two around widgets for 3.8. Inspired by @lessbloat, I’ve made a short survey with a few basic questions about widgets and how you use them. It you could, please take a few minutes to share your thoughts:

    Take the Widgets Survey

    Thanks!

     
    • pekz0r 5:21 pm on August 14, 2013 Permalink | Log in to Reply

      I think we should rethink the whole widget and rewrite of the whole widget API, not just the hot up the widgets screen.
      I want widgets to be a lot more flexible and pluggable. First of all, it should be extremely easy to create a widgets. Everything that should be needed should be a function/file/hook for the configuration form and one function/file/hook for the presentation. It would also be cool to have a widget repository like the repositories for plugins and themes so you can install new widgets with a simple click right in wp-admin.

      I would also like a simple solution for using these Widgets in the content areas, not just the sidebars. Maybe by using shortcodes to add a widet to a content area or, even better, just use them as objects(like videos and images) that you can resize and drag around. Widgets would be more like pluggable views than inflexible sidebar boxes.

    • Nashwan Doaqan 5:42 pm on August 14, 2013 Permalink | Log in to Reply

      Survey Completed :)

    • Sallie Goetsch 6:18 pm on August 14, 2013 Permalink | Log in to Reply

      The question about the number of sidebars is problematic. First, actual sidebars or widgetized areas? Second, which theme on which site?

  • Jen Mylo 1:53 pm on April 23, 2013 Permalink
    Tags: , deadlines   

    Post Formats, Schedules, and Philosophy 

    Post Formats UI is looking like this right now:
    Screen shot 2013-04-23 at 9.05.04 AM

    This seems confusing, because it looks like they are icons to insert something (Image, Gallery, Link, Video, etc), but instead of launching a popup to insert a link or an image, the screen changes and the navigation that was just used to choose disappears completely. (Note: If Standard had some indication of being the default/current selection it wouldn’t be as confusing)

    Clicking on one — say Link — makes the UI change, the big icon row go away, and a format switcher link drops below the title rather than keeping its visual hierarchy above the post stuff, and it’s generally disorienting.

    Screen shot 2013-04-23 at 9.09.35 AM

    If the user thinks, “Whoa, what happened, I better change format again,” and they click on the “Change format’ link under the title field and next to the “Enter URL” instruction, the screens morphs again to this:

    Screen shot 2013-04-23 at 9.12.41 AM

    Where the icon strip is back, but the link field has disappeared and the icon next to Add New Post is still a link. This is super confusing. Does it still think it is a link bc they didn’t actively choose to return to standard, they just chose to see the options? If that’s so, why did the url field disappear?

    Looking at the release schedule:
    Screen shot 2013-04-23 at 9.40.18 AM
    We launched Beta 1 on April 4, and it’s been almost 3 weeks without a follow-up beta 2.
    …I am wondering if the post formats ui is really prime time ready, or if it should be one of the very first thing sto land in a 3.7 branch so we can get the things that are completely ready into the hands of users sooner rather than later?

    Since I’m outside the core dev group now, I’ve been on both sides of the deadline delay dance. I know how hard it is to let go of something that feels like it is thisclose to done. And I know that just about everyone on the core team will be thinking right about now that I should shut up (and I’m okay with that, because it used to be my first response to deadline questions to core, too). But we have this philosophy posted on wordpress.org:

    Deadlines Are Not Arbitrary

    Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release. We aspire to release three major versions a year because through trial and error we’ve found that to be a good balance between getting cool stuff in each release and not so much that we end up breaking more than we add.

    Good deadlines almost always make you trim something from a release. This is not a bad thing, it’s what they’re supposed to do.

    The route of delaying a release for that one-more-feature is, literally, a rabbit hole. We did that for over a year once, and it wasn’t pleasant for anybody.

    The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.

    I’m not trying to be a troublemaker or imply that anyone isn’t doing everything they can — I know for a fact that people are working themselves into the ground on this release. Nor am looking to incite a debate about deadlines or all the explanations of how we fell behind this time (I’ve been following along, everything is really pretty normal). But would it be better to not try to squeeze it all in, get out what we can ship now (including the awesome 2013 theme that regular people still don’t have access to), and take a quick breath to relax before diving back in on a new cycle? Shipping is a feature, too. ;)

     
    • mordauk 2:01 pm on April 23, 2013 Permalink | Log in to Reply

      I love where the new post formats UI is going, but I have to agree with Jen about the confusion a lot of users are going to see. When playing with them last week, I caught myself asking some of the exact same questions Jen mentioned above, and I’m a “power” user.

      If it is one or the other, I’d prefer to see 3.6 pushed back a bit so that it can still include the new post formats.

      • Jon Brown 5:47 pm on April 23, 2013 Permalink | Log in to Reply

        Ditto. Current UI is confusing for all the reasons Jen documented. I was actually starting to like the UI just before beta,, but beta 1′s change post format link is awful. Fix or punt, but don’t release it like this. Do keep API’s either way, I’d assume changing those might cascade into post revision changes?

        • lisafirke 10:38 pm on April 24, 2013 Permalink | Log in to Reply

          On the UI, yes, it’s confusing, even to an experienced user. The fix doesn’t seem that tough, though. Keep in mind that icons don’t have to carry all the weight. Words are useful, too! What would be wrong with adding a simple: “Choose a post format:” label?

          Also, standard icon shouldn’t be a pin. That to me signifies a *sticky* post.

      • Harish Chouhan 11:42 am on April 25, 2013 Permalink | Log in to Reply

        Yup pushing back 3.6 seems better path. So much work has been put into this already. The Tabs that were there very early in the development of 3.6 were annoying but more usable. Hiding and displaying the Post Format icons, involves extra click and confusion.

    • Caspar 2:05 pm on April 23, 2013 Permalink | Log in to Reply

      tbh, I have no idea why post formats made it into core. They have, so it’s useless to complain. But if Links got removed from core into a plugin, so should post formats.

      The UI itself looks very nice, though, if one likes the feature. Yet I think Jen is right: give it the time it deserves. I don’t think a majority of users would miss it if it had to wait until 3.7.

      • George Stephanis 2:06 pm on April 23, 2013 Permalink | Log in to Reply

        Post formats have been in core for some time now. It’s just the UI implementation that’s new, to make it easier for people to use, as well as implementing the custom fields for each.

        • Jen Mylo 2:17 pm on April 23, 2013 Permalink | Log in to Reply

          UI enhancements are, well, enhancements. This is what the schedule says about Beta 1:

          From this point on, no more commits for any new enhancements or feature requests in this release cycle, only bug fixes. Any enhancements/feature requests not completed and committed by this point will be punted to future. Please don’t get angry and complain when this happens; it’s necessary to get us to an on-time release. You can keep working on your pet ticket and have it ready for early 3.7.

          Saying that the UI was an overall bug is enough stretch to snap a tendon. :)

          • Aaron D. Campbell 2:20 pm on April 23, 2013 Permalink | Log in to Reply

            The new UI was in before beta but the tests revealed bugs. I think that saying we’re trying to stretch the definition of bug to include the original UI enhancement is an equally tendon-snapping stretch.

            • Jen Mylo 2:35 pm on April 23, 2013 Permalink

              Poor usability isn’t really a bug, it’s unfinished design.

      • Mike Schinkel 8:52 pm on April 23, 2013 Permalink | Log in to Reply

        I have no idea why post formats made it into core. They have, so it’s useless to complain. But if Links got removed from core into a plugin, so should post formats.

        In hindsight, compared to my opinion when they were first announced, I definitely have to agree. With everything you just said, except the first part; I do have an idea of why.

    • John Blackbourn (johnbillion) 2:07 pm on April 23, 2013 Permalink | Log in to Reply

      +1 on punting the post formats UI to 3.7, and releasing 3.6 with the other great features we have, including Twenty Thirteen. I think to bring this UI up to scratch we need to re-address it without the impending delay of 3.6 looming over our heads.

    • Aaron D. Campbell 2:09 pm on April 23, 2013 Permalink | Log in to Reply

      Where the icon strip is back, but the link field has disappeared and the icon next to Add New Post is still a link. This is super confusing.

      I agree that the icon should change back to standard. That’s a bug.

    • Chip Bennett 2:10 pm on April 23, 2013 Permalink | Log in to Reply

      +1 to releasing the Post Formats UI updates when they’re ready: either by delaying 3.6, or punting the implementation to 3.7.

      Can we keep the underlying functions, though? Standardizing on post-format related post custom meta data, and standard data fields for each post format type, is equally (if not more) important than the UI improvements.

      • Jen Mylo 2:13 pm on April 23, 2013 Permalink | Log in to Reply

        I would agree.

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

        +1

      • Beau Lebens 2:50 pm on April 23, 2013 Permalink | Log in to Reply

        Can we keep the underlying functions, though? Standardizing on post-format related post custom meta data, and standard data fields for each post format type, is equally (if not more) important than the UI improvements.

        Definitely agree on this bit.

      • Konstantin Kovshenin 2:57 pm on April 23, 2013 Permalink | Log in to Reply

        What exactly is the benefit of keeping the APIs to access meta data, without keeping the UIs exposing that data?

        • Chip Bennett 3:20 pm on April 23, 2013 Permalink | Log in to Reply

          Because the back end isn’t the only place that those meta-data are exposed? Theme-rendering of the meta data is completely unaffected by back-end UI.

        • Drew Jaynes (DrewAPicture) 3:55 pm on April 23, 2013 Permalink | Log in to Reply

          I can see some benefit in keeping the APIs to access the metadata, which is to make it available and allow the wider WordPress community to innovate and iterate on that information. Of course, it doesn’t really solve the issue of Twenty Thirteen relying on that metadata and having no UI to handle it.

          • Chip Bennett 4:50 pm on April 23, 2013 Permalink | Log in to Reply

            The API handles migration of appropriate data to post meta data. Could that be confusing? (Where did my video go?) Sure. That can be addressed, though, with simple metaboxes for relevant data, even without the contextually changing icons/UI. And post format selection is already available via meta box.

        • Drew Jaynes (DrewAPicture) 4:05 pm on April 23, 2013 Permalink | Log in to Reply

          I’m with @chipbennett that we should either extend the release or punt the UI to 3.7 while at the same time keeping and exposing the underlying functionality.

          As I said in response to @koveshenin, I can see one major benefit of exposing the meta data APIs as allowing for community innovation and iteration. I’d like to see us expose the APIs and maybe package core’s version of the UI into a plugin. The ability is there, the implementation is not and I’d like to see us give it a better measure of caution before we roll it as a core UI.

        • krogsgard 4:10 pm on April 23, 2013 Permalink | Log in to Reply

          I already do custom UI interfaces for clients w/ post formats, and the new functions and standard meta data conventions are enormously helpful for future proofing a custom UI. If the UI gets bumped, keeping the new functions will still be a big win for theme developers.

      • Marcus 6:38 pm on April 23, 2013 Permalink | Log in to Reply

        +1

        the ui is too important to rush, since it’s used by everyone

    • Hassan 2:18 pm on April 23, 2013 Permalink | Log in to Reply

      I don’t really think that Post Formats UI are that important of an addition to make the release date pushed back again and again. I know some people might want it, but for me I’ll probably won’t use it all. Btw, if my theme doesn’t support it, I won’t see it, right?

      So, yeah… I don’t mind pushing it to v3.7 instead. I’d rather ship something fully tried, tested, and trued than half-bake it and rush the release.

    • mindctrl 2:24 pm on April 23, 2013 Permalink | Log in to Reply

      I’d like to see this come in 3.6, even if that means pushing back the date. If this version is all about “content”, and Twenty Thirteen is all about blogging, it makes sense that this UI makes it in and launches with 3.6 and the theme.

      I don’t think there are millions of people sitting around tapping their feet saying WordPress 3.6 better come on 4/29, or even know that’s the date. The devs and core team, sure. Users, not so much. It is about the users, right?

      The rabbit hole thing kinda doesn’t apply in my mind. It’s not adding one more feature here or there. It’s getting one of the centerpiece features of this release finished and included.

      If everyone agrees to push back the release date and that no work gets done in 3.6 that’s unrelated to Post Formats UI, there is no rabbit hole.

      • Daniel Dvorkin (MZAWeb) 2:31 pm on April 23, 2013 Permalink | Log in to Reply

        Personally, I don’t really like the new Post Formats because I don’t find it very useful for my use cases. Having said that, I must say this argument makes a whole lot of sense.

        • Nashwan Doaqan 4:15 pm on April 23, 2013 Permalink | Log in to Reply

          I agree with you, The post formats is not very useful to me, but maybe for others it may be very important … anyway after all work on The New Post Formats UI it will be hard thing to move it to 3.7 :(

        • nofearinc 9:31 pm on April 23, 2013 Permalink | Log in to Reply

          I do agree with you; don’t get their concept, not sure if I will. I’ve seen other systems using this approach though and it would be interesting to see what users would judge here if they get an access to the post format switcher. It’s still a common blogging platform even if we build CMS-based stuff out of it.

          Problem is we can’t easily deprecate anything that’s open to the public and it might be the new ‘Links’ thingy that lives and dies notoriously.

        • mattyrob 10:47 am on April 24, 2013 Permalink | Log in to Reply

          I can’t see a use for this section either so I’ve hidden it on my testing sites.

          That said, if this is supposed to be a new core feature of 3.6 then releasing a new version without it and bumping to 3.7 seems ill advised.

          I’d say get it fixed, delay the release to all this to happen (and if possible while fixing it, allow it to be hidden from the Screen Options).

      • kevinjohngallagher 11:02 pm on April 23, 2013 Permalink | Log in to Reply

        I don’t think there are millions of people sitting around tapping their feet saying WordPress 3.6 better come on 4/29, or even know that’s the date. The devs and core team, sure. Users, not so much. It is about the users, right?

        I disagree.

        It’s not about “millions” of people, it’s about the businesses and organisations that based themselves on top of WordPress. As we move out of the small shops, and small website builds into larger engagements (Government, Enterprise, Education, and Charity sectors) we start to hit more and more procedural issues and legislation.

        There is a huge challenge for many of us of balancing Open Source agility against Service Level Agreements. We’re navigating digital security engagements, code freezes and legal red tape (hello disability discrimination act versus our love of mouse-only hover menus and slight shading that colour blind people cant see) – and these things are planned well in advance.

        For example, the Release Date for WP3.6 is the same week as the big bank holiday weekend in the UK (most don’t happen in both Scotland and England), so we’ve had to make plans around it in February. We are so focussed on blogging end users that we forget about the business ecosystem thats built around WP beyond that of 5 or less people organisations.

        if we want WordPress to scale, in a non-technical sense, then we need to address some of the fundamentals of our product management.

        • mindctrl 12:49 pm on April 24, 2013 Permalink | Log in to Reply

          Major WP versions are mostly about features, and if your SLAs for large organizations require you to be on the cutting edge of Feature 1.0 at release time, you just might be insane. :)

    • Ryan Boren 2:35 pm on April 23, 2013 Permalink | Log in to Reply

      The four month deadline is so fanciful as to be arbitrary. It always has been. Historically, we just can’t do a major release with a marquee UI feature in that time, certainly not without heroic efforts of the 3.5 sort. So we end up facing decisions like this. Every single release we wonder if we have to punt the marquee feature. Punting often requires major surgery that can be as much work as finishing the feature. Punting is demoralizing. Four month releases are empty promises that bring us here.

      • Jen Mylo 3:09 pm on April 23, 2013 Permalink | Log in to Reply

        I used to argue that a 6-month schedule was more realistic with the kinds of features we choose, so I don’t disagree with you, but the people who made the 3.6 schedule and chose the scope for it are the core leads, no?

        At least change the schedule page if a decision was made to push back release by a month or whatever.

      • kevinjohngallagher 10:43 pm on April 23, 2013 Permalink | Log in to Reply

        I can’t disagree with you Ryan, but in an agile methodology – and again thats what the core team has embraced – it’s a completely moot point.

        Every completed work that is signed off in each sprint that matches “definition of done” makes it into a releasable candidate. Work that is not integrated into the “master branch” isn’t released.

        The issue is not a 4 month, or a 6 months or a 4 week or a 12 month release cycle, it’s the management of scope of what can be done in that time period. Can we release a new WordPress version every 4 months? yes. Can we release a new WordPress version every 4 weeks? yes. Can we do that regardless of the amount of scope we presume we can deliver? heck no!

        The developers that work on care are amazing. As a failed developer myself I’m always in awe of what gets done. But there are 4 factors in the engineering pyramid: Scope, Time, Quality and Resource.

        > When Scope is more than should fit into time, and resource stays the same, the only variable that moves is quality.

        In WP’s history, thats usually to the detriment of edge cases. Especially when we’re talking about UI changes.

        Historically, we just can’t do a major release with a marquee UI feature in that time

        That to me suggests that Marquee UI features should be done over 2 (or more) releases. We should release features when they are ready in accordance with our definition of done. Releasing a feature that isn’t up to our MVP isn’t going to do any good, and neither is changing our release date. We shouldn’t try to change our release date to fit in with our feature set, nor vice versa.

        I suggest the Project Manager reads: http://ma.tt/2010/11/one-point-oh/

        Punting often requires major surgery that can be as much work as finishing the feature

        Thats a very different issue. We should be managing integration in the most decoupled way possible. Tight coupling of features into the core so that they *have* to ship is a scary scary path that leads through “bloatville” to “dependancy-city”. If something can’t be built as a plug-in, then thats the issue that should be solved first.

    • Scott Taylor 2:36 pm on April 23, 2013 Permalink | Log in to Reply

      I would argue that the deadline is entirely arbitrary, and it was never realistically altered based on shifting resources. That being said, we had a previous UI iteration we were all proud of, and then user testing said otherwise. The new UI tested about 3 million times better (I’m a data scientist by trade). Since we are in beta (shipping late for sure), now is the perfect time for more testing and tweaks, not less.

      In the past few weeks, we have landed some huge and wildly complex commits, but there are not a litany (or really any) of those left. There are things here or there, but none (?) are blockers.

      I agree it’s crunch time, but I would rather we all pull together and use our noggins rather than criticize and shelf it. What’s *really* missing? *How much* needs to change? @lessbloat and I rejiggered the entire UI in 1-2 days. I doubt that kind of effort is needed again or a that complete reboot is necessary

    • Tom J Nowell 2:36 pm on April 23, 2013 Permalink | Log in to Reply

      I’d suggest:

      • The post format icons should never go away, they provide a second purpose as an indicator and feedback once clicked, hiding them removes that function and forces the user to either remember what they clicked, or figure out from scratch if they’re looking at an existing post.
      • Icons and labels at the moment look arbitrary as if they’re just floating in the middle
      • When opening a new page, how do you know that it’s a standard post, it’s not highlighted in any way or shown to be active. It’s not obvious that the icons are a toggle/selection
      • The icons look more like buttons, actions, that they do something rather than set a status/toggle/selection

      So I’d say that they would be better as tabs, always visible, or at least with a separating line so it’s clear that they are separate from the controls underneath and have a high level purpose, associating them with the Add New Post rather than the content box.

      • Jen Mylo 3:11 pm on April 23, 2013 Permalink | Log in to Reply

        I would agree that keeping the icons present would be less disorienting.

      • Andrew Ozz 8:46 pm on April 23, 2013 Permalink | Log in to Reply

        A post format is something that should be chosen once at starting a new post. It could be changed later but that would mean loosing/removing some of the data that the user has entered (well, we don’t “loose” the data but it becomes unreachable/useless).

        In that terms hiding the icons after a post format has been set makes sense. Perhaps the link can be more prominent and be above the title field (or whatever field is at the top for the current format).

        Keeping all post format icons visible at all times is not good imho. We still need to educate many users what post formats are and how they can be used. Part of this is that changing a post format comes at a cost.

      • Erlend Sogge Heggen 10:46 pm on April 23, 2013 Permalink | Log in to Reply

        +1 for icons never going away. If that was the case however, I think it should be possible to turn off post formats altogether. If you’re using a format-supporting theme but your client is only interested in making ordinary posts, you’d want those tabs out of there.
        +1 for making them look more like tabs.

    • Tom J Nowell 2:46 pm on April 23, 2013 Permalink | Log in to Reply

      Here’s a UI that fixes the issues, doesn’t have the pretty images, but that can be fixed ( look at your browser tabs for an example )

      http://alexking.org/wp-content/uploads/2011/10/format-standard-510×244.png

    • Justin Sainton 2:49 pm on April 23, 2013 Permalink | Log in to Reply

      I’d agree with Pippin, Scott and Ryan. Do what’s necessary (which most agree, is not much) to ship with this in 3.6. We’ve already lost one original content feature (to @danielbachhuber and @kovshenin‘s great malaise), I don’t see the benefit in shipping without a Post Format UI.

      It also seems that the general opposition to the new UI is “It’s awkward…people won’t know what to do…it’s jarring” – all of that is also true of the Post Format concept in general, we heard the same arguments when the initial API was introduced. Give people time and give them credit to work it out.

      • Jen Mylo 3:01 pm on April 23, 2013 Permalink | Log in to Reply

        Millions of people have no trouble understanding the concept with Tumblr. Regular users don’t even think about “post formats,” they think about “posting a video” or whatever the format is.

        • kevinjohngallagher 9:57 pm on April 23, 2013 Permalink | Log in to Reply

          The difference with Tumblr is that it is not a post format change, it’s a post type.
          We have post types (with custom UIs to look like post formats), and post formats that have the same functionality as post types.

          Post formats are essentially standardised custom post types with a unified UI – but only accessible from a totally different place in the admin section.
          ( CPT called “quotes” is a main navigation link, while post formats is inside post, and then choose quote)

          Post Formats are a great idea, but in a rush to get them out the door in 3.1 we took a tactical decision rather than a strategic decision which has led us to where we are now.

    • nphaskins 3:02 pm on April 23, 2013 Permalink | Log in to Reply

      I think it’s right on the money how it’s currently sitting. I wasn’t too keen on how it sat previously (small icons and boxes) so to the guys who re-jigged it, I think you did a stellar job. I’ve been using this (the new UI and functions) extensively over the past week or so as I’ve been rebuilding a few products against the current beta and the current UI. I find it quite nice and don’t consider it confusing at all. I asked my wife to look, and she knows nothing about web shit, and even she could figure it out.

      I’m typically a “hard to please” kind of person and I really do think that this is damn close to being kosher.

    • Nashwan Doaqan 3:03 pm on April 23, 2013 Permalink | Log in to Reply

      The new post format UI is a main feature in 3.6, I can’t imagine the 3.6 version without it… but if you think it is not ready yet you can move it to 3.7 and focus on other bugs tickets…

      My opinion is to do one idea perfectly is better than doing a lot :)

    • BobDunn-Trainer 3:10 pm on April 23, 2013 Permalink | Log in to Reply

      Yes, I do believe if it is released, we will all adapt, even though it is confusing for the average user. The big question is will they even attempt to use these, or totally ignore them. Putting them up front and center will force them to at least try to understand.

      At our last WordPress meetup we did an overview of 3.6. I asked all the casual users to raiser their hands. Then I asked them to keep their hand up if they had ever used post formats or even understood them. All hands when down.

      From the perspective of the people I work with, casual users, I am good either way ;)

    • Stuntbox 3:20 pm on April 23, 2013 Permalink | Log in to Reply

      I’m just one person, but I’d vote for keeping Post Formats in 3.6. Until now, the lack of any kind of admin UI has made Post Formats an incomplete feature. Most casual users aren’t using or discovering them because it’s completely invisible to them without a UI.

      Tweaking and refining the existing UI design seems like it would benefit from this shipping. While there’s been user testing on the Post Formats UI, it’s limited in scope compared to the total number of users who will be exposed to it and provide useful feedback once it goes live.

      It also seems like there are small tweaks that can be made to improve the current UI without punting on it altogether or causing huge delays. Things like simply updating the main heading in the admin UI as the user makes a selection. It won’t cure everything, but it would be a subtle reinforcement if it changed from “Add New Post” to “Add New Image Post”, etc, as a user made selections. (I know I’m getting off topic here, but you get the idea.)

    • Robert Dall 3:27 pm on April 23, 2013 Permalink | Log in to Reply

      On Schedules:

      To use an analogy… If the ferry is always late… I don’t say the ferry is broken… I say change the scheduled…

    • Grant Palin 4:46 pm on April 23, 2013 Permalink | Log in to Reply

      The post formats basic functionality has been in place for some time already. I’m surprised there hasn’t been an official UI for it sooner. It’s something I think is core to blogging, and could be worth pushing on it a little bit more to get it done now. And ship it when it is ready, rather than committing to a deadline. I thought the 3.6 cycle was surprisingly short anyway, so there’s room to extend it a bit.

    • Knut Sparhell 5:02 pm on April 23, 2013 Permalink | Log in to Reply

      My first impression after seeing this new post format UI was: How elegant! Sometimes something will feel confusing to someone. When introducing new features the questions should be if the UI at least is educating and guiding the road to understand the purpose.

      These post formats are a major leap forward. Removing (punting) this would reduce 3.6 to a release that just fixes some old bugs. Push the scheduled dates a few weeks more and get it released.

      Lesson to learn is to start working on major new features in the cycle preceding the cycle it’s going to be released. Use a plugin to iterate, like with the MP6 project.

      • Jen Mylo 5:29 pm on April 23, 2013 Permalink | Log in to Reply

        I do think the icons look elegant. Remember that in 3.7 that icon style will be replaced by the icon style in MP6, so it will likely have a pretty different feel.

        • kevinjohngallagher 10:01 pm on April 23, 2013 Permalink | Log in to Reply

          I think thats an issue right there.

          We’re considering releasing something that we KNOW we’re not happy with, and that is changing next release anyway.

          Why are we forcing multiple UI changes on our users?

          I personally like the UI, though the UX is lacking, but if we’re changing it anyway – what are the advantages of releasing it?

    • Arnan de Gans 6:05 pm on April 23, 2013 Permalink | Log in to Reply

      Sure let’s turn WP into the next Facebook :(
      Can these buttons be hidden in a jquery slide in/out kinda thing?

      Think of the 2nd screenshot, where you click the “change” format and a section slides out pushing all elements on the page down. You click the post format you want. It slides back up and the below form changes accordingly.

      That’s unobtrusive, non-confusing and is “trusted” since some other sites use a similar approach for posting items or hiding options.

    • Scott Taylor 6:51 pm on April 23, 2013 Permalink | Log in to Reply

      I have yet to hear specifics from anyone about what they want to change and how. No patches, no mockups, no explanation of what actually sucks and a plan to start attacking it. So, sounds like we’re still in beta and could use some Trac activity from those with an opinion.

      I’ve been actively working on this stuff for the past 3 months and most of the people on this thread have had light involvement, if any at all. I am trying to figure out what is constructive about pointing fingers right now.

      • Jen Mylo 7:01 pm on April 23, 2013 Permalink | Log in to Reply

        I’m not trying to point fingers, as I said. I’m trying to get us to take a look at what is ready to go and what still needs more work, and re-assess the scope/schedule as needed. I also didn’t say it sucked, I said it was confusing, and I posted a step by step outline of why along with screenshots. I have been on the receiving end of the “should it be cut so we can ship” with a WordPress release many times, so I get it that defensiveness is the first reaction. Everything you just said, I’ve said before.

        If the decision is to extend the cycle and try to deliver in May instead, that’s a valid outcome too, but it’s not reflected anywhere on the schedule, which still says there’ll be a beta every week. Being late isn’t the end of the world, but going 3 weeks without another beta makes it seem that there are bigger problems than just fixing bugs, and if the schedule needs to be adjusted/updated to allow for more design/dev time then it should be.

        *I’ve *also* been the pm in the past who extended the dev cycle without updating the schedule page, and got comments asking about it on this blog, so I understand the natural reaction to that is, “Hey, we’re spending all our time on the product, don’t hassle us about a blog page.” :)

    • Matt Mullenweg 7:32 pm on April 23, 2013 Permalink | Log in to Reply

      We shouldn’t take this personally. Features get adding and removed from releases all the time, even ones I’ve advocated for or worked on, and even at the eleventh hour.

      It’s also very normal to get tons of feedback after all the work on a feature has been done, or often after it’s been shipped.

      Even if it was pulled from core entirely, the work could be put into a plugin that we can see how it gets adopted and used in the WP ecosystem.

      • toscho 9:02 pm on April 23, 2013 Permalink | Log in to Reply

        I think this is a good idea. We could put it into a plugin and ask the users to allow us collecting usage data to see what elements should find a way into 3.7. Empirical data would surely help.

      • nofearinc 9:35 pm on April 23, 2013 Permalink | Log in to Reply

        Sounds like the best way to test something major and trendy without risking to think about deprecating and cleaning the codebase afterwards. +1

      • kevinjohngallagher 10:07 pm on April 23, 2013 Permalink | Log in to Reply

        I’m not against this thinking at all.

        My concern from a purely Project / Product management point of view is that the decision was made to tightly couple this specific change with an external dependancy in the 2013 theme.

        I’m a huge believer in MVP, or MMS depending on where you did your Agile training, and that we’ve fallen foul of the desire to push things into a core release when they weren’t ready before.

        I also believe that this is a prime example of the 80/20 rule causing issues with the decision making for core. As we move more towards CMS and away from purely blogging, WP.com is always going to enforce “purely blogging” concerns/issues/features into the 80 camp.

        [One] can’t imagine the fun conversations that we’ve already had with government agencies around the delay in the beta2 of their chosen CMS due to blogging UI concerns…

      • Erlend Sogge Heggen 11:05 pm on April 23, 2013 Permalink | Log in to Reply

        The plugin route for developing and testing flagship features across several cycles has proven to work very well for MP6. I hope the WP team will adopt this method for more core features in the future.

        In this instance though, I don’t see why it would be necessary. Even with its current quirks (make it always-on and tabbed-styled and it’s perfect imo) the new post format UI is a HUGE step forward for this very little known feature, all because of an incomplete UI.

        No one’s going to be worse off for this update. They’re either gonna continue making standard posts like they used to, or they’re gonna click those buttons and start learning about post formats.

        • Matt Mullenweg 3:00 am on April 24, 2013 Permalink | Log in to Reply

          FWIW, being freed from core was the best thing that ever happened to MP6.

          I do think people will be worse off with this update though. It’s really disheartening to see the confusion that people have when they face the dashboard and the post page, and the overwhelming majority of people who start WP give up without ever making a first post. I think for reasons like Jen pointed out and that came up in user testing.

          The downside of not putting it in is there will be 4-5 months until the next release. Since people think it’s worth waiting at least a month for that doesn’t seem that bad. The downside of putting it in would be the millions of new WP users that are exposed to it for the 4-5 months until the next release (assuming we even do another iteration on it immediately post-release, which we’re not historically great at).

      • mor10 1:21 am on April 26, 2013 Permalink | Log in to Reply

        Putting Post Formats in a plugin is definitely the right thing to do. The UI and implementation is confusing but more importantly most current themes don’t have much support for the feature and the output in these themes will be unreliable if not bizarre. Additionally Post Formats are only relevant for blogging. For those who primarily use WordPress as a CMS they are a distraction and end up being in the way. The key questions here are: Do new users understand how Post Formats work? And do WordPress users actually want and use Post Formats at all?

        • kbiglione 3:45 pm on April 26, 2013 Permalink | Log in to Reply

          This is exactly the problem. New users are baffled by post formats as it is, and the new UI doesn’t do much to solve that problem.

          Honestly, the new UI seems designed to promote a feature that hasn’t been embraced by theme designers. It’s almost as if we’re doubling down on a bad decision (adding Post Formats to core).

    • Mike 8:40 pm on April 23, 2013 Permalink | Log in to Reply

      Very dumb idea to pull it out! It is better – if necessary to delay the release. If the process works and it’s the GUI that is the problem [for some] just add a toggle to disable it in the Writing settings.

      The Post Formats concept – as presented is very clever, even radical. That’s what a WordPress release should be – moving the bar, innovating, taking blogging to where it’s never been before. It is very likely that this attempt – while far superior to the previous version – is not perfect. But an insular GUI testing audience is not the best group to really charter a path through future waters.

      WordPress is too big now to rollout helium releases. Too many people are putting in big efforts. Taking the Post Formats changes out at this point is disrespecting the great work that’s gone into developing it and disappointing large numbers of developers and users looking forward to innovating with yet another groundbreaking WP technology.

    • Chris M. 8:41 pm on April 23, 2013 Permalink | Log in to Reply

      Give it time. Here’s a thought from the UI perspective:

      http://screencast.com/t/7WMDyVgc1

    • Samuel Wood (Otto) 9:36 pm on April 23, 2013 Permalink | Log in to Reply

      I say delay the schedule, address the minor concerns that remain. and roll out up to a month late if needed.

      This is the big feature for 3.6. It’s the one that has gotten the most work. And at this point, I think the UI concerns remaining seem relatively minor and fixable, with proper suggestions and input. Nothing here looks like it’s drastically broken enough to go to the MAJOR task of ripping it all out of core just in order to do a release and hit the deadline.

      Deadlines Are Not Arbitrary, this is true. But that point is there specifically to address the issues of feature-creep and unmitigated-scope-expansion. This is neither of those things. Taking the time to make some relatively minor adjustments and polish to the UI seems minor by comparison to hitting that deadline at-all-costs.

      • Samuel Wood (Otto) 9:42 pm on April 23, 2013 Permalink | Log in to Reply

        Specific suggestions to address the UI concerns in the OP:

        • Make the “current” format have a highlight of some type. Slight background shading. Something.
        • Instead of putting the “change format” below the title, have a selection-action cause the bar to scroll upwards, hiding it or reducing its space-on-page. Not completely hiding it, maybe leave the text visible, and still shaded to show the current format.
        • On mouseover or some other form of indication of change, scroll the bar back down again, but without scrolling the whole page down. Make it overlay the existing area, then change the displayed UI when a new format is selected.
      • kevinjohngallagher 10:21 pm on April 23, 2013 Permalink | Log in to Reply

        Brother,

        I agree with your premise in an abstract sense, but not in the specific one.

        We should not stick to a release schedule (really a guideline) just because we posted it, but we should also be aware that companies and organisations do plan against the schedule as posted.

        Given that agile, and we’re using the modified Scrum methodology, states that every sprint has a releasable product as per our “definition of done”, one has to wonder how we’re so off track. I can’t be alone in having a meeting with a client tomorrow morning who will ask why there is no Beta2 at the date when RC2 was meant to be released.

        If we’ve bitten off more than we can chew, then we need to change something:

        • ship with what works (and meets our definition of done) and push the rest to the next release as per the management methodology that we prescribed to

        OR

        • delay the launch to squeeze in as much as possible, and accept that the amount of UAT testing is going to diminish.

        My concern is that every time we’ve made a UI change where we’ve shipped it ASAP, we’ve caused issues. I’m all for release early, release often; i’m all for an agile methodology; but that way of thinking requires a lean model where you release the Minimum Viable Product every time possible. This is not the MVP of 3.6.

        We need to get out of Developer mode and into release management mode. Thats incredibly hard for amazing developers to do. it’s so hard to say, damn it we’re close but it’s just not ready. But we’ve been here before, lets learn some lessons (Capital P Dangit… Inaccessible menus in 3.3… inability to log out without a mouse in 3.3 and 3.4 etc etc).

        • Samuel Wood (Otto) 9:43 pm on April 24, 2013 Permalink | Log in to Reply

          Sorry, you lost me when you started talking “agile” and “scrum” and all that other nonsensical project management stuff that I kinda don’t care anything about.

          I’m talking about this specific case. Not a methodology. Not some buzzword-heavy stuff that is, IMO, completely meaningless to real-world software development. I don’t subscribe to any of that jazz, and am totally uninterested in arguments based on it.

          For this specific case, at this specific time, the UI seems quite good and only needs some minor improvements to be polished enough to be usable. That’s what I’m saying. Is it worth delaying a bit to finish it? I say “yes, it is”.

          If you have arguments relating to that particular, I’d be happy to listen to them. I’m a coder, I speak as a coder. I don’t do project management, nor have any opinions based on it.

          • Konstantin Kovshenin 9:15 am on April 25, 2013 Permalink | Log in to Reply

            +1 billion.

          • kevinjohngallagher 6:59 pm on April 27, 2013 Permalink | Log in to Reply

            I’m a coder, I speak as a coder. I don’t do project management, nor have any opinions based on it.

            Totally here you. So can I ask then, WHO IS THE PROJECT MANAGER?

            Is it worth delaying a bit to finish it? I say “yes, it is”.

            Cool. When you say “delaying a bit”, how much is “a bit” ?
            10 minutes? 1 day? 1 year? 1 month? 1 week?

      • Mel Choyce 2:11 am on April 24, 2013 Permalink | Log in to Reply

        +1. We’ve already made good strides improving the usability of the post formats UI, and I think with some further tweaking and testing we can get it done for 3.6.

    • nathanrice 2:24 am on April 24, 2013 Permalink | Log in to Reply

      Not that anyone is taking a vote, but as was mentioned earlier, I really don’t see why Links was removed, but post formats needs to be a core feature.

      Or if it MUST be core feature, why the UI needs to be exposed to users with themes that don’t DO ANYTHING in particular with the data, or to users who don’t need, or don’t want, post formats or the associated UI to be part of their publishing experience.

      Or if it MUST be forced on users regardless of whether their theme supports it or they want it (ugh), then why does it HAVE to be part of 3.6? I’m not even sure it’s conceptually sound, much less functionally sound.

      So I’m with Matt, there’s good reason to make this into a plugin, test and iterate, get feedback, and maybe one day it makes it into core.

    • Mark Jaquith 7:16 am on April 24, 2013 Permalink | Log in to Reply

      The concerns here seem relatively minor, and can be addressed with a few small tweaks. The treatment we have now tested very well (whereas the one in beta 1 did not).

      I was going to make this point, but I’ll just quote Ryan:

      Punting often requires major surgery that can be as much work as finishing the feature.

      This is absolutely the case here. It it were a matter of removing a file and shipping an RC, that might be a different conversation. If people are willing to help out, we can get these tweaks done tomorrow and ship another beta.

      • Knut Sparhell 8:57 am on April 24, 2013 Permalink | Log in to Reply

        How much work is it to remove the new post formats UI from trunk? This has to be compared with the work that remains to make the feature and the UI great.

        Do another iteration on the UI presented here, before making a decision. You guys in the post formats team have done so much great work. It’s already 90% perfect.

    • bobbingwide 1:12 pm on April 24, 2013 Permalink | Log in to Reply

      Simple question. Is there an approved design for the post formats UI? Failing that, documentation on what each post format is supposed to do and how it does it.

    • Tom Auger 4:02 pm on April 24, 2013 Permalink | Log in to Reply

      Hi Jen, thanks for this post. I also agree the the current UI is confusing, but I also really like it, AND I also agree with others who point out that changing a post format once the post has been started can be a Bad Idea. Our UI should allow, but not facilitate any workflow that involves changing the post format after the fact.

      So:
      1. When you create a new Post, the input fields are all greyed out until you select one of the post formats.
      2. Once you have selected a post format, the currently selected post format icon remains lit up, and aligned to the left, just above the title. The remaining post format icons collapse under (and behind) this icon – in other words, they disappear.
      3. Where the strip used to be, we now have the text that says “Change post format”.
      4. Clicking this link invokes some kind of confirmation that essentially says “data could be lost”.
      5. Clicking the confirmation brings back the Post Formats ribbon, while greying out the other input fields again.

      The only thing I don’t like is if you want to just get in and write a Post post, you still have to click on the “Post” format icon before you can get started. One solution would be to enable a third-level flyout on the “New Post” menu item that lists miniature versions of the post format icons, so you can jump right into creating the type of post format you want.

      • Mark Jaquith 7:05 pm on April 24, 2013 Permalink | Log in to Reply

        Clicking this link invokes some kind of confirmation that essentially says “data could be lost”.

        It isn’t lost, actually. I don’t know if that changes your thoughts on anything. Whether or not the choosing UI should be always visibile is pretty much the last big decision to be made.

        • mindctrl 9:55 pm on April 24, 2013 Permalink | Log in to Reply

          The old UI was always visible. That’s not to say the new one has to follow suit, but the current sliding out of view is awkward. I’d prefer it stay visible, highlight the current selection (color icon for active?), and ditch the “change format” text link (which BTW is disconnected from the previous format choosing location).

          To repeat an earlier statement about image post format, the “Link URL” box is confusing at best. Nothing there that suggests “this is the place your image will link to”. Also, I’d guess that most people will be interacting with the media library “Select/Upload Image” far more than the “Image HTML or URL” box. Something should be changed there. The latter is far too prominent, imo.

          The “Image HTML or URL” box is very large, almost suggesting more than one URL can be pasted. However it doesn’t work if you try it. But more importantly, if you paste a long URL and decide to erase it and replace it with another, the box totally disappears. (I should add this to Trac).

      • Brent Logan 8:29 pm on April 24, 2013 Permalink | Log in to Reply

        I disagree that changing post formats is a bad idea. I use post formats and change formats *all the time.* Here are some examples:

        1. An image in the post becomes the point of the post so it changes from standard to image.
        2. An aside becomes a status and maybe back again. (I have changing definitions, for what is what.)
        3. A gallery gets culled to a single image.
        4. A standard becomes a quote.

        It’s really no big deal to change formats. At least, it shouldn’t be. The tabbed interface used by FavePersonal is easy to use, shows the current format, and makes it easy to switch between formats. http://crowdfavorite.com/wordpress/themes/favepersonal/

        Sure, not everyone is going to want or use post formats. Give them an option to hide the UI. But for those of us who are waiting for this, make it easy to switch, please.

    • Franz Josef Kaiser 4:31 pm on April 24, 2013 Permalink | Log in to Reply

      After reading that MP6 will be integrated/finalized for WP 3.7, I can’t understand why the post formats UI was ever proposed for 3.6. When we already got a new UI in the line, why not introduce new features right when we got it? Would lower the needed UI work, would integrate better, would be more consistent.

      For now just pulling the UI (or post formats completely) out of core and delivering it as plugin that “does phone home” to provide feedback sounds like the only right decision. +1 for that idea.

    • mor10 6:26 pm on April 26, 2013 Permalink | Log in to Reply

      I just demoed the current iteration of the Post Formats UI to someone unfamiliar with WordPress but familiar with online publishing applications in general. This is what he said:

      “Based on the UI, my assumption would be that I could write an article and when I wanted to insert an image, a quote, a gallery, a video, or whatever, I just hit the appropriate button above and the fields that show up allow me to do that. What actually happens is not at all what I anticipated.”

      I think there are several issues with the way Post Formats have been implemented in general and how they are presented here, but the most important thing right now is that there is an assumption new users will automatically know what post formats are. The way they are presented doesn’t give any indication of what they are or how they work, and the interpretation of my friend is far more intuitive than the one being assumed by proponents of the current UI.

      • Matt Mullenweg 12:17 am on April 27, 2013 Permalink | Log in to Reply

        I was thinking about this a lot yesterday, and it could actually be an interesting approach to a next-gen editor if you think of a post as a series of blocks some of which are full-width and some of which are pulled to the left or right with the text flowing around them. These blocks could be a quote, image/caption, video, gallery of several images, slideshow… with the first two covering 95% of what frustrates people when trying to “lay out” posts. Imagine it a bit like the Storify creator, or a TGD story, or post on Joen’s blog, though there’s probably a better example of what I’m talking about out there somewhere.

        • Mike 8:26 am on April 27, 2013 Permalink | Log in to Reply

          There are quite a few “block” CPT plugins (or one could roll his/her own CPT) and with the Display Posts Shortcode plugin (for example) it is easy to insert these into posts.
          Another option is to go back one step to the Media CPT features and re-design the approach to inserting media elements into posts. This would extend existing core technologies that already offer quite a bit and preserve workflow traditions.
          It comes down to what is desired out of the box. I like Beta 1 with a settings option to disable the new GUI (similar to turning off the Tool Bar).
          While it’s not perfect (what is?) it would be great to take an holistic approach to an overhaul of the edit post page that re-examines what’s there and reconsiders how to approach extensibility going forward.

        • mor10 6:06 am on April 28, 2013 Permalink | Log in to Reply

          I recently worked on a site where we did something very similar: instead of displaying images, video, and audio mixed in with the content, these elements were pulled out and placed in the area usually used for the sidebar. It worked especially well with image galleries because it allowed us to display the images in larger sizes with full captions. There is something there for sure.

    • Matt Mullenweg 9:16 pm on April 26, 2013 Permalink | Log in to Reply

      I know it’s not fashionable at the moment, but we should include the Press This posting screen in our support for formats if we’re going to do it right in a core release.

    • KirkM 4:59 pm on April 27, 2013 Permalink | Log in to Reply

      As a veteran user of WordPress and chronic (albeit quiet) WordPress beta tester, the only real thing I find confusing about the new post format layout is that there’s nothing there to tell the user what exactly those icons are for. Okay, so it may seem obvious to some but in real use, it ain’t so obvious. But this has already been said.

      From my point of view, some added text, above the post format icons, that simply stated something like “Choose your Post Format” or “Change you Post Format” or simply “Post Formats”. Anything that will tell the user exactly what those buttons are for. You could even add a “Learn More” link after the post format “title” that opens a page in another browser window/tab that briefly explains what each post format does and what it’s used for. But for the now adding description “title” above the post format icons would be enough?

    • paaljoachim 8:40 pm on April 27, 2013 Permalink | Log in to Reply

      I just do not get it. Why of why have multiple post types, when all one needs is one post type.
      There is a toolbar above the content area that the group could have spent time on improving. For adding media there is the Add Media button. Everything else there is the existing toolbar and the toolbar needs improving to make creating and adding content easier and better looking.

      I did see the http://wpusertesting.com/videos/DC7-7.mp4 and totally agreed with how she did things. I do believe that most new users will also create posts in a similar way.

      The more options available the more confusion the result can be. One Page type and one Post type seems like a good option to me, and then make the toolbar for adding/editing content amazing easy to use.

    • ezhil 4:00 am on April 29, 2013 Permalink | Log in to Reply

      The current post format reminds me of tumblr interface. wordpress is mostly used as cms and for regular websites. This post format would typecast wordpress as a personal blogging s/w. i hope we can add a settings option to enable/disable this so that it would be usefull for people who wants it.

    • Jeff Cohan 2:07 pm on April 29, 2013 Permalink | Log in to Reply

      I know I’m late to the party. And all of you probably have more WordPress knowledge in the tips of your pinky fingers than I do in my old brain.

      But here’s my $0.02 on the issue of POST FORMAT CHOOSING/SWITCHING:

      Forget icons. Forget tabs. Put the Post Format options in the “Publish” meta box, after the “Published on” section. Make it work like the “Status” and “Visibility” options: a select menu with an “Ok” submit, which causes the UI to display the pieces appropriate for the selected format. Default (obviously) would be standard.

      For users who don’t know/care about Post Formats (yet), the choosing/switching function would be out of the way. For those who do, they know where to get it.

      There. I said it.

      • eburnett 11:23 pm on May 1, 2013 Permalink | Log in to Reply

        I don’t know – I kind of like the whole new post interface direction…makes things simpler for getting familiarized with the backend – one thing I absolutely can’t stand is when someone loads on a base install of WordPress, peeks around a little stops short then says “Oh yeah, I tried WordPress…it doesn’t do anything”

    • eburnett 6:25 pm on April 30, 2013 Permalink | Log in to Reply

      Great. It looks nice and all but a few caveats. Where’s M4A? Don’t get me wrong, I’m all for open source, open web but I haven’t even taken a look at the video and I’m worried that I’m going to meet similar problems there too…so if I were a content provider, and I wanted to make use of the new supported post types, then turn around and sell, first off – I don’t want to start off with a lossy format – I love open source, but not lossy audio. MP3/OGG is simply not a road everyone is going to turn down, simply because some people don’t like Apple. On the other front, you have the post/memory-limit/file-upload size aperture issue, 2 of which simply can’t be dealt with a plugin after PHP 5.3 (PHP_INI_PERDIR) pertaining to video, this is very promising where some host limits can be as low as 64mb. Prepare the tickets for this “whammy” bar, it looks nice – I wish it could do what it sets out to (it would make things so much simpler for the new comer end user).

      On another note, I was really disappointed with TwentyThirteen, I thought the orange concept was just a pre-fab and not the actual design release (the theme is not what is bothering it’s the tools behind it) I was expecting this theme to show off a lot more in respect to customizer options, advanced theme settings, after seeing the inclusion of audio – not just a player but an actual working playlist worked into the theme much like iTheme’s AudioBlock attempts to do. As the codex expands, I was definitely hoping this theme would showcase and comment a lot of developer notes on what we should be looking for in developments in the codex, new supported post types, advanced settings, jquery updates – instead it kind of feels like there’s more attention being given to underscore…if that be the case then you need to show us how to make full use of theme options and the like. Anyhow, keep up to good work and hopefully you’ll find a graceful medium for us as I for one, would like to be able to make use of 3.6, once it is truly ready, and hope to see more developer notes in the underscore framework. Thanks.

      • eburnett 8:39 pm on April 30, 2013 Permalink | Log in to Reply

        Nice…disregard comments regarding m4a – apparently this is on my end. Wasn’t working on my test server – only when I converted over to mp3 could I upload. I loaded up beta over on my host and it’s working there, thanks.

    • francesdath 9:19 am on May 3, 2013 Permalink | Log in to Reply

      Also late to the party and delurking here, not sure if this is the right place for this, but. A couple of minor things I’ve noticed while using 3.6 dev (no particular order):

      If I add audio or video file, I can’t then remove it. Or can I? I don’t see any obvious ‘x’ icon like on an image in Visual mode.

      Video placeholder image. I’ve been using custom fields for video for a long time (with mediaelements or Flowplayer), and always added a placeholder image to avoid having an empty black player showing which doesn’t provide any clue as to the video content. Possibly too many steps for simplicity in Post Formats, but I think it could be good.

      Having an option for uploading subtitles with the video might be good.

      Enabling/disabling some or all post formats. It seems for me that the all new post formats icons show irrespectively of declarations in functions.php. I’ve been using Crowd Favourites’ plugin for a while and like that only the ones I’ve included appear. I think this for themes that don’t support post formats and/or haven’t declared specific ones these should be hidden. Is this the way it’s supposed to work now, or am I doing something weird?

      Somehow I liked the icons more when they were smaller and didn’t stretch over the right sidebar. I think mainly as it is now feels slightly not as I’m used to seeing the division of these two areas.

  • Helen Hou-Sandi 7:49 am on March 15, 2013 Permalink
    Tags: ,   

    Post Formats UI Update, 3/14 

    As noted in The Road to 3.6 Beta 1, we’ve got quite a bit going on for post formats. Many of the tickets are in need of testing (including unit tests) and then a commit. As always, there are a few different fronts: UI/administration, data, and parsing. Here’s where we are with each, and what needs to get done. There’s a large variety of tasks here, and we are seeking contributors to help :)

    (More …)

     
    • Luke Gedeon 3:32 pm on March 15, 2013 Permalink | Log in to Reply

      “Add New Post: Status” in the refreshed layout wireframes shows permalink above status field (Hey User, what’s up?) and has no title. As a user, having the status field above permalink feels more natural.

      As a dev, I wonder if we could use the Title field to capture the status instead of a custom field. This would allow normal processing to generate the permalink and put the order of fields into something closer to what a user might expect.

      When generating output for a status it “might” be preferable to hide the title even in themes that don’t recognize post formats. If that is case, core could return an empty title and the status stored in title as content. My preference would be to receive the status as a title anyway, since that would look best in most themes I have looked at.

      • Helen Hou-Sandi 7:13 pm on March 18, 2013 Permalink | Log in to Reply

        Status is not a custom field – it’s post_content. I don’t think we’re going to be able to get so adventurous with the status format edit screen layout – it’s quite likely that it’s going to just look the same as aside – title optional (toggle or otherwise), regular editor area. I also don’t think core should just turn titles off in a theme – that’s completely up to the theme to decide. A theme may very well use the_content in a way that looks like a title – 100% presentation layer, not data.

    • Dravel 5:27 pm on March 15, 2013 Permalink | Log in to Reply

      As a regular “John Doe” user of WordPress I must say that the plan of ditching the tabs in favor for the drop down thingy from @lessbloat is a major disappointment. The tabs were a new fresh style (needed one to) to a stale design part of post area itself.

      Reverting to a style that best described as 1995-ish when we are in fact roaming in the year 2013 is a huge step back, not to speak of the user unfriendliness the current iteration presents (http://make.wordpress.org/core/2013/02/22/post-formats-ui-update-221/#comment-8182), that little blob before the “Enter title here” does in no way even hint that there’s option’s lurking there. As a blogger I want it easy and straight forward, not guessing around before I can actually start to write my things.

      The tabs were ok and had a fresh thing to it, shoot even a vertical row of the icon’s made by @melchoyce with a sub title “Post Format” as a <h2> heading right under the “Enter title here” is way better than a obscure drop down thing, especially from a user friendly point of view.

      Just 0.2 cent from a regular John Doe user

      • Helen Hou-Sandi 7:18 pm on March 18, 2013 Permalink | Log in to Reply

        There are a lot of problems with the tabs interaction-wise. They are not adaptive to screen widths, especially smaller ones, incorrectly represent selecting a format as a primary action when in reality it is one that is performed once and then left alone, and they cause confusion among users, both “regular” and ones we tend to think of as knowing better (like the very people writing patches). Some users interpret the tabs as needing to fill out all of them rather than making a generally-one-time choice that sticks, and yet others saw ones like “Audio” and “Video” as being points for inserting media into their content. We have a lot of exploration to do, but tabs are definitely not it. Again, I regret having put them in even as temporary UI – the distraction caused has been a bit time-consuming to respond to.

      • jltallon 1:00 pm on March 20, 2013 Permalink | Log in to Reply

        From another “John Doe” user (+developer +project manager):
        @lessbloat‘s proposal at the URL below is right on: discoverable, intuitive, unintrusive, practical… good.

        Though I’m a bit wary of content parsing, I trust you to get it right, and the “teeny” mode will be of much help in guiding the users along the right way (input the “correct” content). Less meta is good for performance, too.

        0.02€ from me :)

    • Hugh 9:25 pm on March 15, 2013 Permalink | Log in to Reply

      I’m a lurker, but can someone point me to a post or discussion on the history of post formats? I am curious to know why the post formats for audio and video are not separate content types. – I’m sure there is some good thought behind this but being newish I’d just like to read why it is the way it is.

      • Helen Hou-Sandi 7:22 pm on March 18, 2013 Permalink | Log in to Reply

        I suppose the Codex has some information about what post formats are: http://codex.wordpress.org/Post_Formats, notably “A Post Format is a piece of meta information that can be used by a theme to customize its presentation of a post.”. Separate content types (post types) would not show up in a blog archive by default and are not posts, whereas these are supposed to be posts that just happen to contain audio or video (or quote, image, gallery, chat transcript, or link). Think of post formats as a way for users to structure/think about the content of their blog posts and as a way for theme devs to be able to customize the presentation layer of a given format.

    • WraithKenny 8:38 pm on March 18, 2013 Permalink | Log in to Reply

      “…what it means to re-initialize TinyMCE…” Is there a ticket or comment on which scenario would require TinyMCE to be reset?

    • Scott Taylor 10:22 pm on March 18, 2013 Permalink | Log in to Reply

      I am on a plane home from my Mexication – I am going to refresh my patches tonight, based on the fact that #23282 finally landed (editors note: woo hoo!). The patch on #23282 had some new functions (`has_shortcode()`, `shortcode_exists()`, `get_tag_regex()`, et al) that were present in ~5 different patches. Will also streamline any dupe’d code elsewhere among the patches that haven’t been committed. That being said , #23673 should be the next one to go in.

  • lessbloat 4:40 pm on February 27, 2013 Permalink  

    Menus Update, 2/27 

    We’ve all been distracted with other stuff these past 2 weeks. DrewAPicture put together a parent ticket for all of the remaining menu items.

    Remaining Tasks

    I’d like to try and wrap all of these up ASAP.

     
    • Travis Northcutt 4:46 pm on February 27, 2013 Permalink | Log in to Reply

      What’s the ticket?

    • Cor van Noorloos 8:00 am on March 1, 2013 Permalink | Log in to Reply

      Hi Dave, I hope it still would be OK to have a few suggestions/comments?

      The .nav-menus-php .delete-action a { color: #bc0b0b; } currently is in the wrong color (should be red) and it missing the 1px 2px padding.

      Besides that I think the new menu contains a bit to much info (or perhaps displayed at the wrong place).

      Instead of a complete walkthrough I’d prefer some strong statements like “No menu’s yet” as is done almost everywhere else.
      Or if required a general .description classed paragraph with some further explaination including some anekedote about Jazz.

      The #nav-menu-header also looks a bit awkward. Especially its height. (it always has, even though it’s looking much better now. +1)
      Have you thought about moving .button button-primary above and below the metabox?

  • lessbloat 5:26 pm on February 8, 2013 Permalink
    Tags: ,   

    Menus Office Hours (Feb 7) 

    Here’s a recap of yesterdays office hours.

    Work accomplished since last office hours

    Major items discussed

    1) Theme locations continues to be our biggest design challenge. We discussed a bunch of options and decided to go with checkboxes for theme locations for now – while we continue to stew on alternative approaches.

    2) We discussed having settings at the top or the bottom, and settled on them being on the bottom.

    On the docket

    • Refactor accordion code (@lessbloat)
    • Re-assess CSS in latest patch (currently 23119.28.1.diff), and move colors to colors.css (Looking for a volunteer here)
    • Browser compat testing (Looking for a volunteer here)
    • No JS testing (Looking for a volunteer here)
    • Code review (Looking for volunteers here – hopefully from multiple people)
    • Commit what we’ve got

    After that

    • Any additional accessibility work
    • Additional code refactoring
    • Am I missing anything?

    p.s. @DrewAPicture, I added a title this time just for you. ;-)

     
    • Drew Jaynes (DrewAPicture) 5:57 pm on February 8, 2013 Permalink | Log in to Reply

      RE: title, “He can be taught!”

      We also need to do an extensive round of RTL testing as well as completing docblocks for any new functions we’re introducing, @access private or not.

      I can start on no-js testing this weekend.

    • sireneweb 4:50 pm on February 11, 2013 Permalink | Log in to Reply

      Hi, very nice :)
      When you use Mega drop down menu, you can’t delete all children from main menu. It would be great if we can Expand/Collaspe main menu and delete all children sub menu from main menu

      • lessbloat 6:14 pm on February 11, 2013 Permalink | Log in to Reply

        I asked @jkudish to gather some data around avg number of menu items per menu for sites on WP.com. Out of 1000 random sites (with at least one menu added), here’s what the distribution looked like:

        Excluding the menus with zero items added, the average comes out to 5.

        So, based on this data, should we make some sort of expand/collaspe menu item functionality a part of core, or keep it in plugin territory?

        I think my preference would be to keep it as a plugin, but I’d love to hear everyones thoughts.

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