Revision team proposed changes patches for testing

[adamsilverstein]

this ticket is for tracking & testing proposed changes to revisions, i have uploaded several patches that replicate some of the changes we have been discussing.

1. Revisions Post Meta box - more context in that list - ​http://f.cl.ly/items/1L2S2h310G2u2q0o1x3P/patch1.png

2. Revisions list on revisions.php - more context/detail in that list - ​http://f.cl.ly/items/0T1S2x42341t2o1k2s3m/patch2.png

3. Revisions page with revisions list to the left of revision - ​http://f.cl.ly/items/3q3y3N290X2I452C442d/patch3.png (added responsive design, revision list left of diff compare on wide screen, below on narrower screen)

4. Diff combined view - ​http://f.cl.ly/items/2T3h3p2U0p1T3S0o3c10/patch-withcombinedview.png

5. Diff view in HTML - uses wp_kses_post to process HTML, not using frame technique (yet); added some details above diff as well - ​http://f.cl.ly/items/131U2F0K262o1a2A342i/final.png

6. alternate version that shows changed text without color bubble, language in right bubbles now added/removed not added/deleted, also centered text in labels and changed to darker red/green for colors - ​http://f.cl.ly/items/2V331s2v1a040w3T3c1U/final-alternatea.png

on smaller screens, the comparison uses the full width and the revision list drops below - ​http://f.cl.ly/items/1f2G3P0J243a3v3V3u2c/smallscreen.png

[adamsilverstein]

meta box details

[adamsilverstein]

add details to inner meta box

[adamsilverstein]

responsive design puts revision list to left on wider screens

[adamsilverstein]

combined diff view (HTML)

[adamsilverstein]

WYSIWYG views

[adamsilverstein]

alternate color version, no bubbles around content

[adamsilverstein]

mix of last two patches colors

[mark-k]

I don't know if this is the proper place but IMO the revisions table at revisions.php suck. Hard to put the finger on exactly what sucks there but I guess that one of the bigger things is that it doesn't look and behave like other tables in WP.

My suggestion is to have 3 coloumns in the table

title - the title of the revision

time - creation time of the revision

author - the author of the revision.

Actions should be shown on mouseover and include restore, select for compare, view. show, and delete.

new action "Delete" - right now there is no interface to delete a revision. not sure if it is on purpose or just an omission (maybe a revision contained some content I prefer that it will not be even in the privacy of the DB)

new action "View" - show the post/page as it will look on the front end if it was restored

new action "Show" - show the content in the revision.php page without restoring it.

Not sure about the "select for compare" but the current way of selecting revisions is ugly. why do I need to specify which is the new and which is the old when we have the revision date, and why should I be limited by the UI to a two way compare?

If the resulting table is small then maybe it can be displayed instead of the current revision table displayed at the post & page editing pages.

[adamsilverstein]

thanks for your comments. i think we all agree the revision tables are currently lousy! we've been mocking up lots of ideas for improvements- see this ​blog post for some recent ideas.

i like your suggestions for actions in the revision list, in ​one of our early mockups we had compare from, compare to, delete and restore below each revision. for now the delete idea was dropped, see #9681.

i agree the current list and checkboxes are confusing (although if we get rid of them, can we keep the easter egg? #12816)

your suggestion about a Show action makes me think we should add a preview button into the diff view, currently the only way to show a revision itself is by clicking a revision title in the table.

currently we allow any two revisions to be compared: perhaps we should always assume they are comparing to the current revision -- only let them choose a revision to compare to. this change would simplify the interface, because there is only one list of revisions to choose from; restoring a revision would allow you to compare to that revision.

Replying to mark-k:

I don't know if this is the proper place but IMO the revisions table at revisions.php suck. Hard to put the finger on exactly what sucks there but I guess that one of the bigger things is that it doesn't look and behave like other tables in WP.

My suggestion is to have 3 coloumns in the table

title - the title of the revision

time - creation time of the revision

author - the author of the revision.

Actions should be shown on mouseover and include restore, select for compare, view. show, and delete.

new action "Delete" - right now there is no interface to delete a revision. not sure if it is on purpose or just an omission (maybe a revision contained some content I prefer that it will not be even in the privacy of the DB)

new action "View" - show the post/page as it will look on the front end if it was restored

new action "Show" - show the content in the revision.php page without restoring it.

Not sure about the "select for compare" but the current way of selecting revisions is ugly. why do I need to specify which is the new and which is the old when we have the revision date, and why should I be limited by the UI to a two way compare?

If the resulting table is small then maybe it can be displayed instead of the current revision table displayed at the post & page editing pages.

[mark-k]

+1 for comparing only against the current revision maybe with a filter that will enable plugins to add the ability to select a different revision to compare to.

[adamsilverstein]

compare only to current, action links, css updates (colors)

[adamsilverstein]

i added an updated patch for testing that removes the checkbox columns, puts the author info in a column, and puts actions below the revision date, it looks like this:

[adamsilverstein]

meta box with table layout, comment mockup

[adamsilverstein]

comments in meta box (mockup), table layout

[adamsilverstein]

added one more diff with table layout in revisions meta box, changed date format to make it more readable, and added mock up of comment editing area, comments would also show in this list.

[adamsilverstein]

I am uploading several mockup patches for testing (ignore extra copies). these patches implement (approximately) the ​recent mockups provided by @karmatosed. Notes below.

Most of the designs in this go round are similar, with just slight layout modifications.

​Version 1. version-1.diff
Lots of changes -

• from the edit post page click a revision takes you right to the comparison view - comparing the current revision to the selected revision.
• also shown is a revision comment (but we don't have a place to enter or edit these).

on the diff screen

*added and removed lines in the upper right. currently these numbers are actually calculated lower down on the page and moved up on the page using CSS. I did this for expediency, but we pay want to re-work.

• comments are shown at the top of the pages
• clicking two compare checkboxes initiates a diff between the two, the oldest revision title is always shows on the left
• note the left column always displays removed lines, the right column displays added lines, both columns display lines that are unchanged, i think this is confusing
• the 'compare revisions' button is gone, and there is no way to actually restore a revision - we need to resolve that
• the revision diff is stored, computed and shown on three fields - post_title, post_content and post_excerpt. before this diff the field name was shown down the left hand column (​like this). this diff removes that column entirely.

looks like this:

​Version 2. version-2.diff

• dropped the top noted
• header layout changed
• did not implement mockup gray background on revision list, stuck with standard alternating color background
• added back compare revisions button for accessibility, needs thought

looks like this:

​Version 3. version-3.diff

*small layout changes (i see now that i missed one layout changed, but got it in version 4 below)

looks like this:

​Version 4. version-4.diff

• change text colors, add line-through; instead of red/green background to indicate changes
• +/- old/new along middle spine looks like this:

​Version 5. version-5.diff

*some layout changes
*repeats lines added/removed count above each column
looks like this:

also, i added a few additional variations,

• diff 6
  • starts based on version 3, and adds responsive design
  • for screen sizes 980px wide or larger, displays the revisions list to the left of the diff view
  • removes the comments column from the revision list
  • pictured below at three width screens, middle size needs attention

widescreen

small screen

midsize screen

• diff 7
  • displays diff in combined view with removed and added lines combined, a narrow column down the right side indicated sections that are removed or added. i think this view shows the changes between the two revisions most clearly.
  • there is still no link to 'restore revision', perhaps a button at the upper right? or back in revision list.

[jb510]

I personally like the 2 column side by side display with solid color boxes (Version 2). I dislike the strike through. I dislike the 3 side by side columns.

I really dislike the current UI for selecting revisions to compare, it's terribly confusing. I wanted to add a mockup but haven't found time to make it, but I'd far prefer a dropdown selector above each of the columns (left and right) that allowed comparing any revision.

Changing things so comparisions can only be made between the current revision and old revisions seems reasonable but you lose the ability to see who made what change. Currently you can compare revision 10 by User A and revision 9 by User B and see who made what change. I think if things are changed to only compare to the current revision that attributing each change to a particular user needs to be considered. Perhaps a not on each red/green box attributing who it was that made that change? I wouldn't call it extremely critical to me, but it does seem like we're losing functionality that should at least be discussed before abandoning.

[karmatosed]

Revision mockups from meeting

[karmatosed]

I've just added some revised mockups from the things we talked about in the last meeting in irc. There are a number of experimentations on there along with the format we talked about.

[karmatosed]

I added ​http://core.trac.wordpress.org/attachment/ticket/23396/revisions9.png in light of the discussion today and modified slider approach to the revisions area.

[adamsilverstein]

updated

[adamsilverstein]

i decided to explore the idea of rewriting the revisions page using javascript and backbone. i created a new ticket to make applying the patch easier - see #23497. in that ticket i also applied the latest design direction from this ticket.

[karmatosed]

I've updated a mockup bringing in the slider and the button we'll explore at some point later for comparing 2 revisions but for now just a reminded of that functionality.

​http://core.trac.wordpress.org/attachment/ticket/23396/revisions11.png

[ethitter]

Replying to karmatosed:

I've updated a mockup bringing in the slider and the button we'll explore at some point later for comparing 2 revisions but for now just a reminded of that functionality.

Looks good. The idea of a slider to coarsely locate the desired revision, and buttons for fine-grained selection, seems like a smart approach.

Thought on comparing two different revisions: keeping with this design, we could slide the slider and buttons over the left revision, and add in an identical set above the right version. With that, any change to either side would update the diff automatically.

[adamsilverstein]

Replying to ethitter:

Replying to karmatosed:

I've updated a mockup bringing in the slider and the button we'll explore at some point later for comparing 2 revisions but for now just a reminded of that functionality.

Looks good. The idea of a slider to coarsely locate the desired revision, and buttons for fine-grained selection, seems like a smart approach.

Thought on comparing two different revisions: keeping with this design, we could slide the slider and buttons over the left revision, and add in an identical set above the right version. With that, any change to either side would update the diff automatically.

thinking about two sliders: do we need to show both at once?

what about using accordion or tabs for compare TO and compare FROM... when you switch to the compare TO slider, the revision being compared FROM freezes and dragging the slider changes what you are comparing TO. switch back to the compare FROM slider and the revision being compared TO freezes and the slider changes what you are comparing FROM.

if we do it this way, i can pre-generate the diffs for each revision whenever the tab is changed (based on the current revision) and we will still get the rapid paging/sliding. also it seems simpler than having two sliders visible at once;

[adamsilverstein]

something like this:

[ethitter]

Replying to adamsilverstein:

thinking about two sliders: do we need to show both at once?

No, not necessarily. Freezing the one when changing the other probably makes more sense than letting users tweak both sides of the compare. Something to discuss during the next chat for sure.

[karmatosed]

I've updated with mockups from the extra meetings hours discussion.

​http://core.trac.wordpress.org/attachment/ticket/23396/comparing-two.png

​http://core.trac.wordpress.org/attachment/ticket/23396/comparing-one.png

[ethitter]

Replying to karmatosed:

I've updated with mockups from the extra meetings hours discussion.

​http://core.trac.wordpress.org/attachment/ticket/23396/comparing-two.png

​http://core.trac.wordpress.org/attachment/ticket/23396/comparing-one.png

Thanks for the quick turnaround!

@adamsilverstein is going to investigate a range slider, so we'd end up with just a single slider and two grabbers as I understand things; this approach would also mean that the previous and next buttons would hide during a "compare two" scenario. That said, he's going to focus on the single comparison first, so we can iterate on the compare-two version a bit more in the meantime.

[adamsilverstein]

looks like its straightforward to add a second handle to the slider. technically this is not a range slider, just a two handles slider.

the comparison code always compares the newer to the older revision, so i think it makes sense that the sliders can't overlap and also block each other.

for example: you have 10 revisions, by default you are comparing the current version to the 1st (most recent) revision (or another revision if you clicked on it in the list perhaps). the current version would be represented by the leftmost position on the slider, the next spot to the right would be the 1st revision now, you drag the right hand slider handle to the right so you are comparing say current to revision 8. next, you drag the left hand slider handle to the right, which shows comparisons between the revision you drag to (left) and revision 8 (right), but you can't go past revision 7 (one to the left of where the right handle is set). you leave the left handle at revision 3, the display is comparing revision 3 & revision 8. at this point, you can start dragging the right handle and you are viewing diffs from revision. again the right handle is bound by the left, so you can't go past revision 4 one to the right of the left handle.

this logic is a visual representation of what the current code actually does, it always compares newer->older, and it doesn't allow you to compare a revision to itself (although its fun to try). the left handle is the left revision and the right handle is the right revision.

thoughts?

[adamsilverstein]

Replying to karmatosed:

I've updated with mockups from the extra meetings hours discussion.

​http://core.trac.wordpress.org/attachment/ticket/23396/comparing-two.png

​http://core.trac.wordpress.org/attachment/ticket/23396/comparing-one.png

i have a question about the +/- symbols; in the earlier mockups these appear next to each diff change, in this version they are absent. i like the way this cleans up the diff view but am worried it makes it harder to see changes. should i remove from the code diff?

[adamsilverstein]

work continues on the revisions team rewrite for 3.6 in ticket #23497