Editing records and advancing forward page by page- how the list refreshes and displays the records #570
Comments
|
I'm seeing a similar refresh issue when doing reconciliation -- if i choose the "double checkmark" icon - or match to all identical cells, it refreshes the entire page and goes back to the top instead of where you last were. I suspect that could be intended behavior to ensure one doesn't have items to revalidate -- but it's a pain when you're on the bottom third of a large list and it keeps taking you back to the top.... |
|
The "refresh-and-goes-back-to-the-first-page-after-a-match-all-identical-cells" issue is a pain in the ass. It should be considered as a high priority issue for reconciliation.
|
thadguidry
added
the
Priority: High
thadguidry
added
the
Theme: UX/Usability
|
@wetneb Can you perhaps provide a quick fix for this issue over the next 2 weeks ? |
|
@ettorerizza after thinking about @thadguidry's suggestions for reconciliation UI I would actually be in favour of a completely different screen setup for reconciliation. During a manual reconciliation session:
So, I would be interested in adding a button "Start reconciliation session", or something like that, which would take you to a completely different screen, tailored for this task. You would do your matches there, and when you get bored you click "Back" and you are back to the normal OR screen. |
|
@thadguidry sure I will look into that |
thadguidry
added
the
help wanted
|
@wetneb Thanks, this is Google Sponsored actually via the Wikidata Reconciliation subproject we have for Phase 1, still ongoing (still money left), so track your time. And yes, a different screen is ideal if not to much trouble. That's what the Freebase Judgement screen did hosted by Freebase Apps back in the day. Its too bad we didn't have the foresight to save that App before it got destroyed by Google, such as what Spencer did with his apps |
|
@wetneb Yeah, you put the right words on something that I felt without formulating it ! When it comes to examine records one by one manually, we move from a logic of columns (a logic of database) to a logic of rows (a logic of spreadsheet) for which the interface is not appropriate. |
|
Just to check - although you aren't changing the facets while you reconcile, you may want to only deal with a filtered set of rows as you go into the reconcile process - would what you are suggesting only deal with the filtered rows (I guess yes, but just to be clear) |
Be careful that there are some cases where you have to look at another column to choose the best candidate. For example, to check if a matched place is in the right country, or if it is the right kind of place (some place names refer to both a municipality and a province).
Another case where it is necessary to look at another column is when the matching is done on a copy of the original column (in order to then visually check the quality of the matching.).
|
|
@ettorerizza sure, looking at other columns is super important - I only proposed to hide the other rows. |
|
Ouch, sorry, I had misread (with the copy-paste of the sentence in front of the eyes, moreover). :/ |
thadguidry
removed
help wanted
|
A lot of different issues are mentioned here:
|
wetneb
added
grid pagination / scrolling
|
I wanted to report this bug to find out that it has already been reported a long time ago. This is really a pain for manual reconciliation because you always get returned to the beginning after each and every reconciled line. (the bug also seems identical to #33 ) |
|
@VojtechDostal have you tried the workaround with the facet mentioned in #33 ? |
Yep, I do that. But sometimes I don't want to match all lines, just some of them, so I inevitably reach line 50 sooner or later. To prevent this I would have to manually mark all skipped lines as "do not match". |
This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and OpenRefine#570
…ne#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, OpenRefine#570 and OpenRefine#572. This reverts commit d7aaac2.
…eshes the grid. Instead, the current page is refreshed. This closes #33, closes OpenRefine#570, closes OpenRefine#572.
…#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and #570 * Revert "(I #2638) Feature to Goto a page directly (#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, #570 and #572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes #570, closes #572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
|
Fixed in 4.0 by #5411. |
…#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and #570 * Revert "(I #2638) Feature to Goto a page directly (#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, #570 and #572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes #570, closes #572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
…#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and #570 * Revert "(I #2638) Feature to Goto a page directly (#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, #570 and #572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes #570, closes #572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
…f the grid (OpenRefine#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and OpenRefine#570 * Revert "(I OpenRefine#2638) Feature to Goto a page directly (OpenRefine#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, OpenRefine#570 and OpenRefine#572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes OpenRefine#570, closes OpenRefine#572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
…OpenRefine#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and OpenRefine#570 * Revert "(I OpenRefine#2638) Feature to Goto a page directly (OpenRefine#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, OpenRefine#570 and OpenRefine#572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes OpenRefine#570, closes OpenRefine#572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
…OpenRefine#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and OpenRefine#570 * Revert "(I OpenRefine#2638) Feature to Goto a page directly (OpenRefine#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, OpenRefine#570 and OpenRefine#572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes OpenRefine#570, closes OpenRefine#572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
…OpenRefine#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and OpenRefine#570 * Revert "(I OpenRefine#2638) Feature to Goto a page directly (OpenRefine#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, OpenRefine#570 and OpenRefine#572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes OpenRefine#570, closes OpenRefine#572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
…OpenRefine#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and OpenRefine#570 * Revert "(I OpenRefine#2638) Feature to Goto a page directly (OpenRefine#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, OpenRefine#570 and OpenRefine#572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes OpenRefine#570, closes OpenRefine#572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
…OpenRefine#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and OpenRefine#570 * Revert "(I OpenRefine#2638) Feature to Goto a page directly (OpenRefine#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, OpenRefine#570 and OpenRefine#572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes OpenRefine#570, closes OpenRefine#572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
…OpenRefine#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and OpenRefine#570 * Revert "(I OpenRefine#2638) Feature to Goto a page directly (OpenRefine#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, OpenRefine#570 and OpenRefine#572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes OpenRefine#570, closes OpenRefine#572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
…OpenRefine#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and OpenRefine#570 * Revert "(I OpenRefine#2638) Feature to Goto a page directly (OpenRefine#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, OpenRefine#570 and OpenRefine#572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes OpenRefine#570, closes OpenRefine#572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
…OpenRefine#5411) * Adapt the GridState interface to separate sorting and pagination. This adds `getRowsBefore` methods, counterpart to the existing pagination methods, so that we can do efficient and correct pagination, solving #33 and OpenRefine#570 * Revert "(I OpenRefine#2638) Feature to Goto a page directly (OpenRefine#2639)" Go back to simply displaying a range of row numbers, because that will enable a solution for #33, OpenRefine#570 and OpenRefine#572. This reverts commit d7aaac2. * Do not move back to the first page when applying an action which refreshes the grid. Instead, the current page is refreshed. This closes #33, closes OpenRefine#570, closes OpenRefine#572. * Specify which actions preserve row and record ids This lets us preserve pagination only when it is guaranteed to show the same part of the data after the operation. * Make paging user-editable like before * Adapt cypress tests
Original author: ericjarv...@gmail.com (May 05, 2012 17:33:44)
An annoying behavior when editing lots of records, page by ascending page;
When editing hundreds of pages of data, this is a real pain, because instead of the user being able to simply click 'next' and have all un-revised/un-edited records be displayed, the user instead must first click the 'back' link to commit the changes, and then click the 'next' link so that those 4 records that took the place of the above modified 4 records, can be reviewed and edited if need-be prior to moving on to the new page. If any of those 4 records are edited, then the problem occurs again, and is further compounded, which is to say, the user has to click the 'back' link again for a measly <4 records.
The correct behavior should allow the user to click the 'next' link without having to worry about un-revised records ending up on the previous page. This should be accomplished by taking the last edited record on the page(e.g.- # 18), and using the next record up(e.g.- # 19) as the record that will display FIRST on the refreshed 'next' page, accounting for any/all records that dropped out of the Facet as a result of the edits.
So, in the above example, when the 4 records(12, 14, 16, and 18) are edited wherein their edits result in their exclusion from/within the Facet, the list, upon clicking the 'next' link, subsequently consolidates downward, wherein # 13 goes down to the # 12 row, # 15 goes down to the # 14 row, # 17 goes down to the # 16 row, and # 19 goes down to the # 18 row. This means that records # 21, 22, 23, and 24 that are on the next/un-seen and un-revised page, end up consolidating down accordingly, ending up on the second page(records 21-30) when the user has clicked through to the 3rd page, hence, the user misses those records as a result. Ideally, Refine should not allow any records that are on the subsequent page to end up on the previous page... the adjustment should be made based on the next page, not based on consolidating downward imo. Or, at minimum, the user should be able to toggle the option, or have a 'next-fixed' link to choose from.
Thanks,
Eric Jarvies
Original issue: http://code.google.com/p/google-refine/issues/detail?id=570
The text was updated successfully, but these errors were encountered: