# Design improvements for Editor tasks
The following design suggestions base on @dchen’s [[ https://docs.google.com/presentation/d/114bLL_sdh_7oRBGm1rseav9sTH7qqN1QVh-fAG1qp0c/edit?ts=5c74299b#slide=id.g3cb0e00524_0_0 | research slide deck ]]. To better understand the changes in the course of the redesign, the screens below show a before/after state and contain written details about the changes.
👉 Oh, and there’s a flow chart. **[[ https://overflow.io/s/24PSRV/ | Check out it out here]]** to grasp context more quickly.
---
## Copy changes
Please check out the [[ https://docs.google.com/spreadsheets/d/1t0IWXoSz7EYBS6LrQM5fV_qZ6paK_sFRjnCp9H7rEPo/edit#gid=0 | copy master doc ]] for all strings used in the designs. I made adjustments to the copy and simplified language wherever possible. I’ll try to keep it in sync with the designs but please use the sheet as a source of truth since designs can outdate quickly. Some of the major changes include:
**App editor tasks -> Editor tasks**
People are using the features we are building **in an app**. They make real edits to Wikipedia after all. Let’s call it what it is: Editor tasks. It’s more concise and easier to understand.
**Add/translate title description -> Add/translate description**
The term “title description“ is confusing for people who don’t have 15 years of edit experience on Wikipedia and Wikidata. We want to make editing as accessible as possible and reach people that haven’t edited before. Let’s talk about adding and translating descriptions. We can still provide details about the history of the term “title descriptions“ in the “Help/Support“ area.
---
## Onboarding
| Before | After
| {F28282655} | {F28289632}
- Dialog is always shown when first accessing “Editor tasks“ are first accessed. Yes, also after previously interacting with an unlock message.
- General visual design and copy changes
---
## Editor tasks
| Before | After (translation locked) | Translation unlocked | Translation unlocked w/o multiple languages
| {F28282682} | {F28286234} | {F28286247} | {F28286238}
- Removed “Levels“ for the minimum viable product (V1), [the icon was confusing users in usability tests](https://docs.google.com/presentation/d/114bLL_sdh_7oRBGm1rseav9sTH7qqN1QVh-fAG1qp0c/edit?ts=5c74299b#slide=id.g4cde51cc2a_0_192). Also we need to put more thought into possible gamification features before we introduce them.
- Optimized information structure and affordance of “My contributions“ area at the top
- Profile image is only shown when available. No placeholder is displayed, username and contributions are left aligned when no profile image is set.
- Added icon to “More tasks for multilingual users“ (consistency).
- Simplified visual design in general.
---
## Translate descriptions
| Before | After | Tapping the dice | Description published | Going back after a translation has been added
| {F28286330} | {F28286332} | {F28286427} | {F28286865} | {F28286449}
- Replaced bidirectional with unidirectional icon to improve awareness of translation direction. Deemphasized it (54% black), since it’s a secondary action. Tapping the icon still swaps the language. These changes are based [on these findings](https://docs.google.com/presentation/d/114bLL_sdh_7oRBGm1rseav9sTH7qqN1QVh-fAG1qp0c/edit?ts=5c74299b#slide=id.g4cde51cc2a_0_95).
- The presented card is always shown in the language in the “From“ language.
- The card itself is **one tap target**. A clear call to action (“Add German translation“) indicates users the task at hand.
- The possibility to read the article has been removed in this view to not disrupt the edit flow.
- To indicate users that a random card w/o title descriptions is shown, the dice, known from the “Randomizer“ feature is reused (([s. usability testing](https://docs.google.com/presentation/d/114bLL_sdh_7oRBGm1rseav9sTH7qqN1QVh-fAG1qp0c/edit?ts=5c74299b#slide=id.g3a3c923459_0_267)). The existing interface is perfect in this scenario.
- A “Description published“ snackbar informs users about a successful contribution ([Slide 25](https://docs.google.com/presentation/d/114bLL_sdh_7oRBGm1rseav9sTH7qqN1QVh-fAG1qp0c/edit?ts=5c74299b#slide=id.g4cde51cc2a_0_151)).
- Once a description has been added, the card indicates it (“Translated by you“) and the familiar edit pencil icon is displayed. The card still is one tap target and tapping this card again takes users back to the “Add/translate description“ with the translation they previously added
- The card feed lists all cards that users have interacted with (not only the one’s that have been edited) and should keep its “History“ per edit session.
- Previous and next arrows are only shown when they’re available to reduce complexity of the interface.
- [ ] Question to devs: Can we show more of the article text based on the users screen height? The more content from the article, the better (more context for users). The minimum article text that should be shown is 3 lines.
---
## Translate description
| Before | After | Tapping bottom sheet | Pulling sheet even further to the top
| {F28287271} | {F28287222} | {F28287387} | {F28287390}
- Input field is active when users arrive on this screen (keyboard is visible).
- Introducing a bottom element to easily access articles. Ideally, the bottom sheet displays more text than it does currently. This could be achieved by not showing preview images in the current implementation of the bottom sheet. Furthermore, it could be scrollable and show even more text.
- Bottom sheet allows copy pasting of text (as it does now).
- Tapping “Read article“ opens the article.
- The article view should use a regular back button. Usability tests revealed ([Slide 28](https://docs.google.com/presentation/d/114bLL_sdh_7oRBGm1rseav9sTH7qqN1QVh-fAG1qp0c/edit?ts=5c74299b#slide=id.g4cde51cc2a_0_28)), that the back button is disrupting the current edit flow. The visuals above show a way to solve the back button dilemma for the entire app.
- “Open in a new tab“ is already covered with the tab feature on the article page that’s why it’s removed in the designs.
- Once users start typing, the Continue button (tick) turns blue (#36c) to lead users to the next step (review screen)
- Overall improved visual design.
- [ ] Question: Can we remove legal info and only show it on the “Review translation“ screen?
---
## Review description
| Before | After | View after tapping “Continue“ (tick)
| {F28287795} | {F28287800} | {F28287844}
- Review screen shows article in **target language**
- Review screen shows more article text
- Tick is emphasized in blue (#36c)
---
## Add description(s) flow
| {F28287883} | {F28287891} | {F28287900} | {F28287907} | {F28287911} | {F28287924}
- Bases almost completely on the “Translate description(s)“ flow
- Does not display a language dropdown to switch languages (also if multiple languages have been set in the app). It always uses the app’s primary language.
- Slight variations in labelling:
- “Add translation in %language%“ --> Add description
- “Translated by you“ --> “Added by you“
---
## Todos
- [ ] My contributions
- [ ] Design/optimize “Info“ screen
- [ ] Notification concept
- [ ] Design example screens for RTL treatment
- [ ] Upload all screens to Zeplin once this has been distributed/split into tasks.