Opened 12 years ago
Closed 11 years ago
#24056 closed defect (bug) (invalid)
Revisions: UI a bit unusable when you have ALOT of revisions
Reported by: | lancewillett | Owned by: | |
---|---|---|---|
Milestone: | Priority: | highest omg bbq | |
Severity: | blocker | Version: | 3.6 |
Component: | Revisions | Keywords: | has-patch |
Focuses: | Cc: |
Description
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.
Attachments (8)
Change History (30)
#1
@
12 years ago
- Component changed from General to Revisions
- Milestone changed from Awaiting Review to 3.6
- Priority changed from normal to high
- Version set to trunk
#3
@
12 years ago
- Keywords needs-patch added
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"
#5
@
12 years ago
- Cc a.hoereth@… added
24056.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 $settings. Furthermore this breaks "compare two revisions" functionality atm.
How should the pagination funtionality be designed? The current revision needs to be somehow highlighted and be sticky on all pages I guess. Further more this sucks for comparing two revision which are long time apart..? Maybe solvable by making the current revision AND the currently focused revision sticky.
#7
follow-up:
↓ 8
@
12 years ago
- Priority changed from high to highest omg bbq
- Severity changed from normal to blocker
This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.
#8
in reply to:
↑ 7
;
follow-up:
↓ 9
@
12 years ago
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.
#9
in reply to:
↑ 8
;
follow-up:
↓ 10
@
12 years ago
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
#10
in reply to:
↑ 9
;
follow-up:
↓ 11
@
12 years ago
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!
#11
in reply to:
↑ 10
;
follow-up:
↓ 12
@
12 years ago
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.
#12
in reply to:
↑ 11
;
follow-up:
↓ 13
@
12 years ago
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.
#13
in reply to:
↑ 12
@
12 years ago
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.
#14
follow-up:
↓ 15
@
12 years ago
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.
#15
in reply to:
↑ 14
;
follow-up:
↓ 16
@
12 years ago
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
#16
in reply to:
↑ 15
@
12 years ago
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
#17
follow-up:
↓ 18
@
11 years ago
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
#18
in reply to:
↑ 17
@
11 years ago
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.
#21
@
11 years ago
Looks like this got lowered in priority behind #24425
Therefore: A screencast demonstrating this patch for later integration considerations: http://screenr.com/8ssH
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 :)