Once we have an acceptable, working prototype, we’ll revisit how to present the interface for comparing two different revisions. @nacin suggested, and we generally agreed, that a single slider with two grabbers would likely be a workable approach, but we’ll discuss that further once the above interface is implemented.

@karmatosed will prepare a revised mockup for tomorrow that incorporates the slider introduced in #23497, and @adamsilverstein will tweak the prototype as well so that comparing a revision to the current version is the default behaviour.

The feeling is that we’re straying from our intended goals, and I didn’t want to wait until our Thursday office hours to refocus.Â After tomorrow’s meeting, I’ll post a more detailed recap of where the Revisions team stands.

As has been the case for many sessions now, Monday’s revisions office hours focused on changes to the UI. @karmatosedprovided new mockups, influenced by a thread on the Accessibility blog. @adamsilverstein also posted a series of patches on #23396 that begin to implement the general direction we’ve chosen for UI updates (aside: we’ll do our best to keep future mockups on this ticket, for easier discovery; until now, most have been posted in the comments on these update threads). We are certainly approaching a consensus on the new design, but have held off on any significant UI-specific coding until we’re confident that our efforts won’t be wasted.

We started today’s office hours by reviewing @karmatosed‘s latest mockups for the revisions screen. We’re in agreement that these reflect the direction we’ll take, so @adamsilverstein will begin coding the changes in preparation for Monday’s meeting. As some concerns have been raised about the use of red and green, @karmatosed will post to the Accessibility group’s P2 asking for feedback on the current mockups. She will also explore the use of patterns to differentiate additions and deletions, as suggested by @helen.

@westi made a few suggestions, based on his recent experiences with Revisions, which we’ve agreed to incorporate. For clarity, the current version will be included in the revisions list to provide a stronger connection with the overall revisions workflow. Second, we decided that when first landing on the revision screen for a given post, we should show the diff of the current version and its immediate predecessor revision; since most users are probably looking for this anyway, why not save them a step?

Lastly, we chatted about the status of code-oriented tickets scoped for 3.6. A few (#16215, #22289, and #19932) have patches, which we’ll be reviewing and providing feedback on before Monday’s meeting. With any luck, we can land at least one in Core before the next dev chat. Beyond that, development on the remaining tickets should progress over the weekend, with the aim of having more patches to review for our next office hours.

For reference, the tickets that are in scope for 3.6 (at least at this point), can be found here.

Yesterday’s meeting focused on revisions to the revisions interface :). @lessbloat joined us to ask some great questions, and helped refocus the UI changes that have been proposed and mocked up so far. We started off by trying to identify the major uses of revisions, and settled on two primary cases: undoing mistakes by finding the last correct revisions, and reviewing changes as part of an editorial workflow.

In light of those focuses, we’ve decided to revisit the UI mockups we’ve (namely, @karmatosed and @adamsilverstein) worked on so far. The general consensus is that they’ve become overly complicated, and led to feature creep (looking at you, line-by-line accept/reject capabilities). @karmatosed is working on some new mockups for Thursday’s office hours. One possible source of inspiration may be @benbalter‘s post forking plugin.

On the code side, @mdawaffe worked out a pretty comprehensive patch for the display of incorrect authors on revisions (#16215). We’ll be reviewing that, along with the patches added to the other tickets we’ve scoped for 3.6. As was the case when I last posted, progress is slow at this point due to travel and the ongoing UI discussions.

I spent some time with @benbalter‘s plugin and merged that with some of the ideas that seemed ‘easy wins’ from a UI view. It’s mainly a tidy up in a lot of respects. I did one with notes but understand this feature probably will not be included – I just wanted to see what it looked like.

I felt the picking in the post forking plugin worked well for that instance but may be overly complicating for us as the ‘new’ would always be the newer version so that’s what I was keeping to by you just picking 2. I didn’t add a submit or confirm as figured if you picked 2 it could reload – we may want to reconsider this as perhaps a pause through clicking something could be useful.

@nacin popped in to mention that he’ll be working on the API for draft changes to published content. This will overlap with, but shouldn’t take away from, the revisions efforts our team is working on. For reference, the ticket’s we’ve scoped for 3.6 are listed here.

Overall, progress this week has been tentative, mostly focused around #16215 and #16847; thanks to @adamsilverstein for his efforts on those tickets thus far. A big area of focus in the near-term will be the UI improvementsâ€”there’s been a fair bit of discussion on this front in the comments here and here.

Our next meeting is Monday, January 28, at 1600 UTC. At the moment, our office hours on Thursdays conflict with the Post Formats team, so one of us will have to move. We’ll keep the hours listed in the sidebar updated as we move forward.

these look good. if we combine the comparison view, it would be nice to bring the revisions list up and to the left. on long pages, users may not see the list of revisions at all; i posted a mockup above. i will be a few minutes late to the meeting today, but look forward to discussing these.