Make WordPress Core

Updates from January, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Daniel Bachhuber 1:52 am on February 8, 2013 Permalink
    Tags: ,   

    Editorial Flow Update, 2/7 

    Editorial flow is making progress and hitting interesting questions to answer. Our two primary tickets right now are #12706 and #23314.

    For the first, we’re waiting on feedback on the approach from @nacin. Once we’ve gotten confirmation it’s the right direction, I’ll continue working to make the patch commit-ready.

    For the second, the biggest question was how we should handle revisions for post meta and taxonomy terms. In the interest of getting to a committable patch, we’ll be dropping post meta / custom taxonomy support in favor of just being able to stage edits for the title and body content. Furthermore we’ve decided it would be worthwhile to add a new post type property so this functionality is opt-in. Posts and Pages in core will receive this by default.

    Our primary goals are to have commit-ready patches for both tickets by the beginning of next week. Konstantin’s secondary goal is to chat with @westi and @ethitter and see whether revisions for post meta is within scope for 3.6. My secondary goal is to go through other editorial flow tickets and touch base with where each is at.

    Next office hours are Tuesday, February 12th at 10 am PT / 1 pm ET / 1800 UTC.

    Office hour log

     

    • Jon Brown 2:12 am on February 8, 2013 Permalink | Log in to Reply

      Initially I was disheartened that you guys were dropping metadata support, but read the irclogs and it makes sense and I’m glad their are still advocates for adding it back in later.

      All of which I share only to say, THANK YOU, for such an open and transparent process. Really all the teams are doing a fabulous job and all the communication is hugely appreciated, so thank you for that and all the great work.

    • Erick Hitter 2:21 am on February 8, 2013 Permalink | Log in to Reply

      Tuesday office hours conflict (for me) with the WordCamp Base Theme chat, so I’ll note here that meta revisions are not in scope for 3.6.

      While the relevant tickets (#20564 and #20299) marked as 3.6, we’ve spent a good deal of time on UI/UX, and that will likely continue to be the bulk of our focus for this iteration. @nacin marked both as 3.6 because they block #23314, but we (@westi, @adamsilverstein, @karmatosed, and I) don’t have the availability to address them at this time.

    • crushgear 4:16 pm on February 11, 2013 Permalink | Log in to Reply

      Hi Daniel — you previously requested for some workflow examples. Here’s an example workflow from a WordPress.com VIP publisher:

      1) Writer puts text in WordPress and saves as “pending review” so the editor knows its ready.
      2) An editor goes in and edits the text in WordPress and schedules the post to publish, or publishes immediately if breaking news.
      3) The post goes live. 
      4) A producer goes in and updates the appropriate fields, if they are not already filled out (category, social text, SEO headline etc). Also could fix any typos found post-launch. Probably wouldn’t need approval before going live.
      5) A photo editor goes in and adds a featured image (these changes could go live without approval) and updates the post.

      Revisions:

      • Occasionally they post corrections after a story is published and those changes would need approval.
      • Occasionally they do rolling posts where they update the text or photos as an event goes on. Those updates may or may not need to be reviewed before publish.
      • Often they have rolling photo galleries where they add a photo each day as more photos come from the wire. Those changes they’d want an editor to review before updating the post.

      Suggestions:

      • It would be nice to have the ability to delete a revision without deleting the live post.
      • It would be nice to have the ability to schedule a revision to go live, so that an update can push without a person waiting around.

  • Konstantin Kovshenin 11:45 am on January 29, 2013 Permalink
    Tags: ,   

    Editorial Flow office hours, today (Tuesday) at 1800 UTC.

    I’ve been working on some mockups over the weekend of possible UI implementations for revising published content. Still very draft and a bunch of unanswered questions, nonetheless here are some pictures:

    So the agenda for today’s office hours is to discuss these, and maybe pick a direction (even if it’s totally different from the list above). Since there’s an overlap with the Revisions team, would appreciate if @westi and/or @ethitter popped in.

     

    • John Blackbourn (johnbillion) 1:38 pm on January 29, 2013 Permalink | Log in to Reply

      My vote goes to the first option (http://cl.ly/image/1b401P3B0d3U) which looks like it’ll work well and is surprisingly intuitive.

    • berkun 5:45 pm on January 29, 2013 Permalink | Log in to Reply

      Two thoughts:

      1. Overall the first option seems simplest (assuming these are 4 alternative designs). Only question is why the last screen is needed. It seems each of the options that show under the ‘More’ dropdown is already present. (UI redundancy can be ok, but not sure why it’s needed here)

      http://cl.ly/image/0z2w0P2f0O0V

      2. In the first design details of the publishing status disappear on the 3rd screen. Saying “This version is unpublished” expresses less information than the previous state, where it says “Published on Jan 1st. 12:54″.

      That loss in detail might be fine if we’re certain the user knows they’re working on a revision of something already published and the time it happened is irrelevant. But ideally we’d find an elegant way to tell them both info about when the original was published, *and* info that the current revision is unpublished.

      We could say:

      This version is unpublished
      Last version published at 1/21 12:45

      There’s a small can of worms here in how the schedule field behaves. It’s the only place the last published time appears, yet it goes away depending on what options the user has set.

      • Konstantin Kovshenin 6:07 pm on January 30, 2013 Permalink | Log in to Reply

        Cool, thanks for the feedback Scott! We discussed this briefly in IRC, everybody seemed to like the first version, or at least the direction. We’ll be working on it in #23314 if you’re interested. From the mockup, “view published version” actually links to the same Edit Post screen, only of the published version, so it isn’t really the preview changes button, but yes, all other options are redundant :)

    • Justin Sternberg 6:35 pm on January 31, 2013 Permalink | Log in to Reply

      The publish metabox is already a bit unwieldy without these updates for the standard blogger. What do we think about simplifying the metabox (even more than it currently is) but add functionality in the form of a click to expand type of UI?

    • Justin Sternberg 6:37 pm on January 31, 2013 Permalink | Log in to Reply

      **sorry, bad grammar** “The publish metabox is already a bit unwieldy for the standard blogger without these updates.”

      • adamsilverstein 6:42 pm on January 31, 2013 Permalink | Log in to Reply

        i was thinking the same thing, as were also talking about trying to cram a ‘revisions’ link in there on the revisions refresh.

        i like the idea of hiding with a click to expand functionality, and also the idea of really simplifying the publish box – all most users need is publish or update; move the other functionality to another box called ‘Drafts & Revisions’…

      • Justin Sternberg 6:49 pm on January 31, 2013 Permalink | Log in to Reply

        I’m not sure this is the proper time/place to discuss this, but I like the idea of a post status bar? Like a bar above title/metaboxes that displays info like published date, publish status, revision status, post-format, etc (think browser status bars). Then that info can be removed from the publish metabox and other metabox displaying post info (or hidden in a click-to-expand section of the metabox) and give the user a high-level overview of the post’s status.

        • Daniel Bachhuber 6:55 pm on January 31, 2013 Permalink | Log in to Reply

          I’m not sure this is the proper time/place to discuss this, but I like the idea of a post status bar?

          Could you share a mockup or wireframe? Also, it sounds like this could be built as a plugin first for user testing / viability purposes.

    • adamsilverstein 6:54 am on February 1, 2013 Permalink | Log in to Reply

      i created a new ticket (#23352) to track proposed changes to the publish box from the revisions team that relate to your workflow mockups. what do you think of simplifying publish and moving functionality to a new publish options box?

    • adamsilverstein 6:58 am on February 1, 2013 Permalink | Log in to Reply

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