| • Deskana | |
| Jul 10 2017, 2:45 PM |
| F8731827: beta-label-and-bottom-link-report.png | |
| Jul 13 2017, 4:45 PM |
| F8713334: Beta-explicit-explanation.png | |
| Jul 12 2017, 11:36 AM |
| F8713331: Beta-icon-and-direct-report.png | |
| Jul 12 2017, 11:36 AM |
| F8713328: beta-label-and-bottom-link.png | |
| Jul 12 2017, 11:36 AM |
| F8690922: Screen Shot 2017-07-10 at 15.42.57.png | |
| Jul 10 2017, 2:45 PM |
Visual diffs in VisualEditor are early in their lifecycle and evolving over time. I've been considering this feature as being in beta, as it's going to change a lot more. We don't indicate that to users anywhere in the interface, though. Should we indicate this to users somehow, so they know they can expect imperfections, and changes over time?
I think something fairly subtle would do fine. Quick and dirty mockup to illustrate the kind of thing I'm thinking of:
I think it makes sense to communicate the beta status. This could help to (a) show it's something new (making users curious to give it a try) and (b) keep people open to accept some glitches that may happen (assuming it is not final). Some possible solutions:
I'd recommend the former unless further clarifications are actually needed.
Communicating something is in beta can also help people feel invited to participate in the process, but if that is among our goals we may want to provide a more clear way to participate: provide feedback, report directly a sub-optimal diff, or learn more about the visual diffs in general. In any case, we need to consider that users are in the middle of confirming a transaction so keeping options minimal and non-intrusive seems a must here.
I think the most important part is to provide a way for users to leave feedback - such a feature would make it obvious that there are known issues and that the feature is under active development.
Good points. Making feedback buttons prominent in Wikimedia products generally backfires as we end up with far more feedback than we can respond to. I assume the feedback button within VisualEditor is a little buried for the same reason. What do you suggest? Another quick and dirty idea: maybe we could show a feedback button if you hover over the selector for visual diff mode.
I guess the volume of feedback depends on how prominent the entry point for feedback is. In this case if the feedback option is provided at the end of a specific sequence of steps (save changes > review your changes> visual > report feedback), I don't expect the feedback to be too much to handle. If that is still a concern, deploying the feedback entry point gradually to different wikis can help to keep the volume under control.
In terms of how to (a) announce the feature is in beta and (b) provide an entry point for feedback, I explored some possible general directions (since both aspects are independent, more combinations may be possible):
Another general aspect to consider if we want to explicitly signal the feature as "beta" is to consider when to remove such signal. Since we probably don't want to keep the beta indicator for too long to keep it relevant.
@Pginer-WMF Thanks for the mockups! I think the first mockup is the most suitable. I prefer the copy from the second, since I think "Report incorrect display" focusses the feedback more. We should keep the interaction the same as the first mockup though (link, open feedback page).
If there are no objections or further suggestions, I'll consider the question resolved and plan to close this task tomorrow. I'll file a follow-up task for implementation.
Longer rationale:
The logo used in the second isn't used anywhere else to my knowledge, so going for the simple labelling of it as "beta" is probably best. A one-click report is ideal, but there are data flow problems: we don't presently have a pipeline for that to transmit useful information to us, and it might have to do some creepy things to do so like send us a copy of the diff which the user might not expect and isn't entirely consistent with our privacy policy.
The copy in the third mockup subtly implies that other areas of the product are not works in progress, which isn't true since we're generally agile in our development. I think that's quite a pedantic argument though; most users won't care about that, and the fact is that this area of the software is more likely to change much more than others. That could maybe be fixed with copy changes. It does provide the best explanation of what's happening, but I think it's probably better to keep it simple.
Sounds good to me. I created an updated mockup in case it's needed as a reference to be added to the ticket description:
The logo used in the second isn't used anywhere else to my knowledge, so going for the simple labelling of it as "beta" is probably best. A one-click report is ideal, but there are data flow problems: we don't presently have a pipeline for that to transmit useful information to us, and it might have to do some creepy things to do so like send us a copy of the diff which the user might not expect and isn't entirely consistent with our privacy policy.
I used a placeholder icon trying to pick from the existing ones in the repo, but we still need to come with a good icon to represent the "new feature" concept. There are many possible options but not a clear winer yet (we used to have a circle with a kind of burst inside that was removed from the repo, a rocket was considered at some point, a gift box is also used by some products...).
We've decided what we're doing, so closing as resolved. Follow-up task for implementation is T170665: Inform users inside the editor that visual diffs are in beta .
Just noting that BetaFeatures uses the lower case beta - β (may not be suited for i18n)