Our team discussed the wireframes from the previous section. We considered what would be best for the newcomers, taking into account the preferences expressed by community members, and thinking about engineering constraints. In August 2020, we took the next step of creating mockups, meant to show in more detail what the feature might look like. These mockups (or similar versions) will be used in team discussions, community discussions, and user tests. One of the most important things we thought about with these mockups is the concern we heard consistently from community members during the discussion: structured tasks may be a good way to introduce newcomers to editing, but we also want to make sure they can find and use the traditional editing interfaces if they are interested.
We have mockups for two different design concepts. We're not necessarily aiming to choose one design concept or the other. Rather, the two concepts are meant to demonstrate different approaches. Our final designs may contain the best elements from both concepts:
- Concept A: the structured task edit takes place in the Visual Editor. The user can see the whole article, and switch out of "recommendation mode" into source or visual editor mode. Less focused on adding the links, but easier access to the visual and source editors.
- Concept B: the structured task edit takes place in its own new area. The user is shown only the paragraph of the article that needs their attention, and can go edit the article if they choose. Fewer distractions from adding links, but more distant access to the visual and source editors.
Please note that the focus in this set of mockups is on the user flow and experience, not on the words and language. Our team will go through a process to determine the best way to write the words in the feature and to explain to the user whether a link should be added.
To view these design concepts, we recommend viewing the full set of slides below.
In discussing these designs, our team is focusing on a set of essential questions that we wanted to answer:
- Should structured tasks have its own home/queue or should it be in the same place as ‘classic’ maintenance template tasks?
- Should the edit happen at the article (more context)? Or in a dedicated experience for this type of edit (more focus, but bigger jump to go use the editor)?
- How could we make it possible to discover and do structured tasks both (a) from the homepage and (b) from the organic browsing experience?
- Should we initially show the whole article and all its suggestions? Or highlight only one link at a time in an article excerpt?
- What if someone wants to edit the link target or text? Should we prevent it or let them go to a standard editor? Is this the opportunity to teach them about the visual editor?
- Should giving feedback about the machine recommendation be a focal point? (e.g. "Why should this not link?")
- We know it’s essential for us to support newcomers discovering traditional editing tools. But when do we do that? Do we do it during the structured task experience with reminders that the user can go to the editor? Or periodically at completion milestones, like after they finish a certain number of structured tasks?
- Is "bot" the right term here? What are some other options? "Algorithm", "Computer", "Auto-", "Machine", etc.?" What might better help convey that machine recommendations are fallible and the importance of human input?