Revisions: UI a bit unusable when you have ALOT of revisions

[lancewillett]

It could be a good idea to limit to last 25 or 50 revisions in the new UI.

I came across an extreme example of this on a WordPress.com site today, where I have something like 130 revisions for the Custom CSS post type. But, this same issue could apply to core post types, though—posts and pages—if the number is high enough.

When I loaded the revisions page, the "calculating revision diffs" message rans for a few minutes, and then "arrow" to move with was moved way off the screen to the right, creating a horizontal scrollbar.

The next and previous buttons are obscured by the long scrubber timeline graphic.

Screenshot attached.

[adamsilverstein]

also noted in #23935. because the tick marks require a certain minimum amount of space, a given screen width can only accommodate a set number of tick marks. we might be able to make this minimum a bit smaller (currently ​10 pixels).

should we set a maximum number of revisions to display, or limit the number based on screen size? what about the revision list meta box on the post page, same limit? i don't know why someone would want to store over a hundred revisions, but if we disabled that option i'm sure we would find out :)

[ocean90]

​IRC log from todays dev chat.

• Limit revisions
• Add a naviagtion under the slider older/newer or 1-50|51- 100
• hard refresh, but two-handle not available on old screens
• Exclude pagination in "compare two"

[a.hoereth]

Rough pagination for revisions

[a.hoereth]

​24056.2.patch adds rough functionality for pages. Waiting for dev feedback before investing more time in it.

At the moment this adds pages with 5 revisions each! Change 'pageSize' parameter of wpRevisionsSettings in wp-admin/revision.php:86. Furthermore this breaks "compare two revisions" functionality.

How should the pagination functionality be designed? The current revision needs to be somehow highlighted and be sticky on all pages I guess. Also this sucks for comparing two revision which many revisions apart. Maybe solvable by making the current revision AND the currently focused revision sticky?

[a.hoereth]

Rough pagination implementation for revisions. Breaks stuff!

[adamsilverstein]

note: see - ​patch on #23901 to allow close to 100 revision tick marks

[ocean90]

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

[adamsilverstein]

Replying to ocean90:

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

why is it unusable, because of time for page to load? prioritizing the load for the selected revision would be very helpful, still not sure how paging will work.

[a.hoereth]

Prioritize revision fetching according to temporal distance to the handle/handles

[a.hoereth]

Replying to adamsilverstein:

Replying to ocean90:

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

why is it unusable, because of time for page to load? prioritizing the load for the selected revision would be very helpful, still not sure how paging will work.

demo for 24056-prioritize.patch: ​http://www.screenr.com/gpI7

[adamsilverstein]

Replying to a.hoereth:

Replying to adamsilverstein:

Replying to ocean90:

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

why is it unusable, because of time for page to load? prioritizing the load for the selected revision would be very helpful, still not sure how paging will work.

demo for 24056-prioritize.patch: ​http://www.screenr.com/gpI7

very nice work, this will really help with a large number of revisions... i like your approach to the load prioritizing. the screencast show its working perfectly in one handle mode.

in two handle mode it is very close, still slightly off: when the left handle stops, only the comparisons for dragging the right handle are reloaded - the left handle comparisons haven't changed because the right handle hadn't moved, so they aren't reloaded.

therefore, i would expect ticks around the right handle position to load when stopping the left handle and conversely the ticks around the left handle to load when the right handle stops; in your patch, comparisons around _both_ handles are loaded, it should be the left or right depending on which handle just stopped.

hope that makes sense!

[a.hoereth]

Replying to adamsilverstein:

Replying to a.hoereth:

Replying to adamsilverstein:

Replying to ocean90:

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

why is it unusable, because of time for page to load? prioritizing the load for the selected revision would be very helpful, still not sure how paging will work.

demo for 24056-prioritize.patch: ​http://www.screenr.com/gpI7

[...]

therefore, i would expect ticks around the right handle position to load when stopping the left handle and conversely the ticks around the left handle to load when the right handle stops; in your patch, comparisons around _both_ handles are loaded, it should be the left or right depending on which handle just stopped.

I can't really see the difference in loading behavior. For me it reloads all tickmarks without my patch as well: ​http://www.screenr.com/vAI7 (gets interesting at 1:40+)
No matter which handle is dragged, all tickmarks are (visually) reloaded. But: We do not clean up data, so backbone reuses already available diffs while still visually reloading them (internal cid stays the same) - I guess ;)

[adamsilverstein]

Replying to a.hoereth:

Replying to adamsilverstein:

Replying to a.hoereth:

Replying to adamsilverstein:

Replying to ocean90:

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

why is it unusable, because of time for page to load? prioritizing the load for the selected revision would be very helpful, still not sure how paging will work.

demo for 24056-prioritize.patch: ​http://www.screenr.com/gpI7

[...]

therefore, i would expect ticks around the right handle position to load when stopping the left handle and conversely the ticks around the left handle to load when the right handle stops; in your patch, comparisons around _both_ handles are loaded, it should be the left or right depending on which handle just stopped.

I can't really see the difference in loading behavior. For me it reloads all tickmarks without my patch as well: ​http://www.screenr.com/vAI7 (gets interesting at 1:40+)
No matter which handle is dragged, all tickmarks are (visually) reloaded.

Edit: My patch does not change anything about data loading, just about the order in which the data is loaded.

corrected this issue in #24346

still need to prioritize loads on opposite handle when stopping in two handle mode instead of both handles.

[a.hoereth]

Replying to adamsilverstein:

Replying to a.hoereth:

[...]

I can't really see the difference in loading behavior. For me it reloads all tickmarks without my patch as well: ​http://www.screenr.com/vAI7 (gets interesting at 1:40+)
No matter which handle is dragged, all tickmarks are (visually) reloaded.

Edit: My patch does not change anything about data loading, just about the order in which the data is loaded.

corrected this issue in #24346

still need to prioritize loads on opposite handle when stopping in two handle mode instead of both handles.

Okay, I will work on this.

[a.hoereth]

​24056-pagination.2.patch enhances my previously implemented pagination feature. Pages are by default set to 50 now.

• On all pages you now get the current live revision at the most right of the slider. This way it is possible to compare posts on other pages to the current post state.
• works in compare two mode
• linking to a specific revision now brings you to the correct page

Further stuff to consider:

• Consider making revisions currently selected in two handle mode sticky when the page changes so they can be compared to revisions on other pages.
• The current and sticky revisions (most right and most left) need to be highlighted / separated somehow. Maybe give this thing more of a "chronological timeline" look and feel, add a clickable separator which brings you to the page in between or something.

[a.hoereth]

fixes missing last page

[adamsilverstein]

Replying to a.hoereth:

​24056-pagination.2.patch enhances my previously implemented pagination feature. Pages are by default set to 50 now.

• On all pages you now get the current live revision at the most right of the slider. This way it is possible to compare posts on other pages to the current post state.
• works in compare two mode
• linking to a specific revision now brings you to the correct page

Further stuff to consider:

• Consider making revisions currently selected in two handle mode sticky when the page changes so they can be compared to revisions on other pages.
• The current and sticky revisions (most right and most left) need to be highlighted / separated somehow. Maybe give this thing more of a "chronological timeline" look and feel, add a clickable separator which brings you to the page in between or something.

looking much better... a few comments/questions

• when clicking on a revision from the list thats on page 2 the correct page is displayed, but the revision is not selected (handle not in correct position)
• what do you mean by this: " On all pages you now get the current live revision at the most right of the slider. This way it is possible to compare posts on other pages to the current post state." ?
• hitting Next at the end of of a page should take you to the next page if there is one (currently its disabled); same for previous button

[adamsilverstein]

Replying to adamsilverstein:

Replying to a.hoereth:

​24056-pagination.2.patch enhances my previously implemented pagination feature. Pages are by default set to 50 now.

• On all pages you now get the current live revision at the most right of the slider. This way it is possible to compare posts on other pages to the current post state.
• works in compare two mode
• linking to a specific revision now brings you to the correct page

Further stuff to consider:

• Consider making revisions currently selected in two handle mode sticky when the page changes so they can be compared to revisions on other pages.
• The current and sticky revisions (most right and most left) need to be highlighted / separated somehow. Maybe give this thing more of a "chronological timeline" look and feel, add a clickable separator which brings you to the page in between or something.

looking much better... a few comments/questions

• when clicking on a revision from the list thats on page 2 the correct page is displayed, but the revision is not selected (handle not in correct position)
• what do you mean by this: " On all pages you now get the current live revision at the most right of the slider. This way it is possible to compare posts on other pages to the current post state." ?
• hitting Next at the end of of a page should take you to the next page if there is one (currently its disabled); same for previous button

also - don't show paging button when only one page

[a.hoereth]

​24056-combined.patch does the following:

• Pagination for single mode (compare two mode only shows page 1, should be fine with 100 revisions per page)
• Prioritization for diff loading
• Refresh slider width on window resize

[a.hoereth]

Replying to a.hoereth:

​24056-combined.patch does the following:

• Pagination for single mode (compare two mode only shows page 1, should be fine with 100 revisions per page)
• Prioritization for diff loading
• Refresh slider width on window resize

Also worth noticing: The most left revision on all but the last page is compared with the newest revision on the next page.

[ocean90]

Patch looks good so far. Waiting for some feedback from Mark.

[a.hoereth]

Looks like this got lowered in priority behind #24425
Therefore: A screencast demonstrating this patch for later integration considerations: ​http://screenr.com/8ssH

[ocean90]

​Generated a post with 200 revisions. It's fast. No issues.

[24520] / #24425