| schoenbaechler added a comment. |
Hi & thanks for your comments @Charlotte, adding them to this task as well.
Hey Robin,
Thanks for this! Comments inline:
Hi Sharvani, thanks for the update! Looping in @Daisy, @Dmitry, @Rita and @Carolyn to this email thread.
I followed Daisy's protocol and found the following discrepancies in version 2.7.269-alpha-2019-01-12:
- Users need to be logged in to their accounts in the current alpha to unlock the "App editor tasks" menu item and dialogs. This is currently not mentioned in the protocol.
This is expected behaviour and will need to be added to the protocol as per our email conversation last week.
- When setting multiple languages in the app's onboarding after initial launch as described in T207334, the second "Title description" edit triggers the Translating tile descriptions editing has been unlocked dialog. If no additional languages are set in the app's onboarding (or settings), the "More tasks for multilingual editors" item in "App editor tasks" can't be accessed at all (screen).\ Plus, it wasn't completely clear to me when and why sometimes the "More tasks for multilingual editors" appears visually locked (which is sometimes accessible in locked state, sometimes not) and when unlocked. Ideally, it would always be in unlocked state for the usability testing to not cause confusion and to make it easier for participants to "Add languages" if they haven't done it already.
Yes, this is unexpected, and something we definitely need to work out for the final version.
- A edit history/app contributions screen does not exist in the alpha yet. The current indicators that users have in the alpha are on the main view in "App editor tasks" where the interface communicates how many "in-app contributions" they've made thus far and within "Translate title descriptions" or "Add title descriptions". In the latter, they first need to tap the three dots ("More") at the top right, then "My contributions". I think this is sufficient for the usability tests since if users are tapping on either of those indicators then they'd successfully identified the place to find it.\
I think you're right that for the test that it's enough to see whether they can find where it would be.
- In regards to "Oh no - you think you made a mistake (...)": Going back by swiping right works, but it currently doesn't update the visual output of the card with the edit that has been made previously. However, it's saved to the database; so if users navigate out of "App Editor Tasks" and e.g. manually search for that previously edited article, the title description includes the edit they've just made. We can still observe if users are actually going back by swiping right or not.\
Also added these comments to Daisy's Edit Action Android Feed Planning Protocol/Survey doc and to the corresponding Phab ticket (
T211109). IMO the things listed are not necessarily blockers for the test, we just need to be aware of it. What do you think @Rita and/or @Carolyn?
I would tend to agree. Thanks for going through the alpha so thoroughly and updating the tickets, Robin. Really appreciated!
Cc: Sharvaniharan, schoenbaechler, ABorbaWMF, Aklapper, Dbrant, dchen, RHo, Charlotte, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, cmadeo, LawExplorer, _jensen, D3r1ck01, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
