google
[Sync status] Improve contents and layout of sync status
@coreyleamon I hacked together a sync status screen, but it's just the barebones of what's needed to check the sync status for features and observations. Would you like to have a go at a proper design for this interface? The known follow-ups at the moment are:
- [x] Show icon for each status (PENDING, IN_PROGRESS, COMPLETE, FAILED)
- [x] Show related feature caption/name on each line if available (@scolsen)
- [x] Add date/time completed/failed
- [ ] Add number of retries
- [ ] i18n: Make text translatable
- [ ] Create custom layout instead of using multiline string
Screenshot of current UI:
@kdyson FYI
Is this a status screen that conveys the status of uploading data once connected to a network? If so, I have a few questions:
- Is it important for these data lines to be viewed together in a screen, which disassociates them from the geographical representation of the point or polygon?
- Does the user need to manually re-initiate when there is a failure, or could the system make x attempts before being considered "failed"?
- If a data point continues failing to upload, what action can a user take? Will they need to re-submit/recreate the data point?
- Do uploaded data points need to be archived in any way? How long and in what contexts might the user need to maintain visibility of the status even if successful?
Hi @coreyleamon sorry I missed these:
Is this a status screen that conveys the status of uploading data once connected to a network? If so, I have a few questions:
Yes, that's correct.
- Is it important for these data lines to be viewed together in a screen, which disassociates them from the geographical representation of the point or polygon?
I think both may be useful. This list is useful because data collectors want to know which changes were recently made without needing to search for possibly modified features on the map.
- Does the user need to manually re-initiate when there is a failure, or could the system make x attempts before being considered "failed"?
It already does this, we just don't show it yet in the UI. But after X attempts we don't have a well-defined story for how the user either retries or abandons the change.
- If a data point continues failing to upload, what action can a user take? Will they need to re-submit/recreate the data point?
Currently none; see previous point.
- Do uploaded data points need to be archived in any way? How long and in what contexts might the user need to maintain visibility of the status even if successful?
Good q - one option would be a CTA to clear completed items from the list. Wdyt?
@vittorino Let's discuss updated designs for "History and sync status" page?
@gino-m the only outstanding tasks left in this are number of retries (which may not be in the mocks anymore), internationalization, and the custom layout
WDYT about filing new issues for these outstanding tasks? That way we can close this out as complete for the IDF announcement
Particularly, custom layout can be filed as code health, i18n as a new FR (are there additional i18n tasks? Is i18n blocking for IDF announcement?), and potentially dropping the retries if the mocks don't have them anymore.
@jcqli The current impl still shows the enum keys instead of label strings, and the job name doesn't show as a formatted string (just the ID shows). Separate tasks sgtm! Can you create? @scolsen Any chance you could patch these today?
https://github.com/google/ground-android/issues/2319 for translations https://github.com/google/ground-android/issues/2320 for custom layout Unclear what the number of retries should look like so we can file that later as the need arises
@scolsen Can we just show user readable labels for the status instead of constants?
@shobhitagarwal1612 Would you be able to help close out this issue with the UI polish still needed?
