## Translate descriptions
| Before | After | Tapping the dice | Description published | Going back after a translation has been added
| {F28286330} | {F28286332} | {F28295785} | {F28295788} | {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?