Revisions Update(s) for Last Week
These are combined and late (sorry).
Last week we had two successful Office Hours discussions:
- Monday – https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-01-28&sort=asc#m541769
- Thursday – https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-01-31&sort=asc#m544313
We discussed the different mockups that both @adamsilverstein and @karmatosed have been working on with the discussions in the first meeting leading to some new mockups here: http://make.wordpress.org/core/2013/01/25/revision-update-125/#comment-7869
And then @karmatosed created some further mockups after our second meeting bringing together our feedback and the different idea threads:
Outside of the meetings our progress has been slow because most of us have been travelling for conferences / meetups
Our next office hours are today at 16:00 UTC
John Saddington 2:09 pm on February 4, 2013 Permalink
Just curious… are you guys using mockingbird mockup app for these? looks great!
karmatosed 2:23 pm on February 4, 2013 Permalink
The above ones were done in Balsamiq.
Robert Chapin (miqrogroove) 7:42 pm on February 4, 2013 Permalink
What’s the difference between Apply and Discard? Apply to what? Discard from where? What does it mean to discard a removal? I think this needs to be more verbose or more intuitive like Undo and Redo.
lessbloat 10:20 pm on February 4, 2013 Permalink
I played around with an alternate concept this afternoon.
My assumptions
There are two major use cases:
A) Undo a mistake I made
B) Review changes & find mistakes other people have made
With the major use cases in mind, here are the problems I see with the existing UI:
1) With just a date/time stamp and author, there is no way to tell (at-a-glance) what revision you’re after from the post edit page, requiring you to click into revisions.
2) Once you click a link from the post edit page, you are taken to a complete revision (without any comparison showing). This seems backwards to me. Seems like you should be taken to the comparison view by default. As you are oftentimes looking for mistakes, which are much harder to spot in the “complete revision” view.
3) The “Revisions” table at the bottom is super confusing.
4) It’s hard once on the revisions page to quickly move through additional revision sets.
My rough proposal
With those use cases and existing UI problems in mind, here’s what I came up with:
Post edit page
On the post edit page show more details related to each revision (base them off of comparisons with previous revisions):
Or perhaps:
Which adds:
Revisions page
Start off in comparison view:
If you mouse over the black/gray icons, more info would show up in a tooltip:
Then if you clicked the “View previous” button you’d see:
Anyhoo… It’s still super rough, but I thought I’d through the concept out there.
adamsilverstein 5:03 pm on February 5, 2013 Permalink
thanks for the new mockups!
before reading your post, i created a ticket and posed patches that implement some of the mockup concepts we had talked about during office hours – #23396
a few responses -
i really like the idea of entering the revision screen already comparing to the previous revision, i never understood why we have the extra option of viewing a revision by itself.
i still don’t understand the meta box on the post page, even if you can pinpoint the revision you want, which is doubtful, you still have to click into the revisions page to restore the revision. for this reason, and because of use case A, i think a link into the revisions interface belongs near the publish button, see #23352. i would just leave the meta box as is (hidden) and focus on the actual revisions page.
i really like the next/back idea, especially if we can get the view refreshing without page reloads. this will make it easy to go back to find the exact revision a user needs.
the little dot idea with popups, while nifty, is not really accessible. what do you think of the idea of a left column showing the list of revisions? ideally, i’d like to see these grouped when there are more than a certain number, either by user or by hour; otherwise the list becomes unwieldy on posts with many edits.
i’m not sure i get the paradigm of removed on one side and added on the other, how will the user know what the post will look like when the restore the revision? willing to try, but i think i prefer the direction of a combined diff view with labels down the edge.
Midhun Devasia 7:37 pm on February 6, 2013 Permalink
I had an idea about the revision change updates.
What I’m thinking is that, when a user want to find what was changed
1. Show the last changes in Revision meta box.
2. And it should show the “Inline Diff” between last version and its previous version. (Comparing Side by Side or left right methods are more complex for normal users, I think they prefer Stoked text, wth color changes of what they deleted and what they added from the last change or revision )
3. The revision meta should show the abbreviation of Big changes.
4. If he is still can’t idenftify the changes he can link to the revision management page.
5. Show atleast 10-20 revisions on the Revision Metabox, or else pagination/link to revision management page.
The Above points are only for Revision Meta box as considered as Quick Reference of the revisions/changes what they made. can give restore link there too, if he find that was his revision.
I had submitted a rough working patch for the above Inline diff method.
Check my ticket.
http://core.trac.wordpress.org/attachment/ticket/18733/wp_revision_meta_.png
http://core.trac.wordpress.org/attachment/ticket/18733/2Screen1.png
http://core.trac.wordpress.org/ticket/18733
Patch
http://core.trac.wordpress.org/attachment/ticket/18733/Qucik%20Revision.patch
esmi 7:50 pm on February 6, 2013 Permalink
Still rather concerned about the colours being used here — both in the original screenshots & @lessbloats alternative concept screenshots. Can we look at using colours other than red & green? Red/green is the most common form of colour blindness, so this could potentially impact on 10% of all make users. See http://quirm.net/temp/revisions-cb2.jpg for an example of how the original screenshot would look to a user with red/green colour blindness.
I’ve also analysed the foreground/background contrast on both the red & green test. Both fail the recommended 4.5:1 contrasts ratio. The red is 4.3:1 whilst the green only manages a really miserable 2.8:1. Anything below the recommended 4.5:1 ratio will hit visually impaired users (not all of whom use screen reading software) and about 50% of dyslexics.
Peter Westwood 9:12 am on February 7, 2013 Permalink
Your concern is noted and not forgotten, our mockups have focused on the layout of the page and I want to try different colours once we have something implemented so as to address the accessibility issues.