Problem (Video)
| Old design |
 |
- Participants expected to see a preview of the reading list on the web in the usability tests.
- They asked for more information and context before a list was imported.
- Importing something unknown felt weird to the participants.
Possible solutions
- Since there's a legal/community constraint not to show previews on the web (yet), we're going to explore previewing a shared reading list in the app before the actual import happens (Slide)
- We should consider renaming "Import" to "View" or "Saved"
Design (Figma)
1) Receive  | 2) Preview  | 3) Save  | 4) Saved  | 5) View  |
1) Receive:
- User receives reading list via messaging app.
- This is the journey when the app is installed. For the landing page flow, check out T327905.
2) Preview:
- Users tap the link and are taken to this view in the app.
- This reuses the existing reading list detail screen design but only has one call to action (Save).
- Use a default list name structure:
- Title: Shared list
- Description: %datetime (e.g. Jan 31, 2023, 11:05 AM)
3) Save:
- Users tapped the "Save" CTA, triggering a dialog. The dialog allows users to name the list and select the articles to save.
- Hide the optional "description" field to reduce cognitive load.
- Design does not feature a select/deselect all button to reduce cognitive load and safe screen estate
- As the dialog contains quite some content, the keyboard is disabled, and the reading list name defaults to "Shared list %datetime". Users can tap the input field to rename it.
- Challenge: How is scrolling handled? It needs to be explored by engineers (@cooltey featured this behavior in a prototype a while ago)
4) Saved:
- Snackbar confirms that the reading list has been saved.
- The "New" indicator shows that the reading list has been added.
- Where the list is added depends on the user’s "Sort" setting.
4) View: Users can view the list as usual after the list is added.
APK: https://github.com/wikimedia/apps-android-wikipedia/pull/3829
