Erweiterung:Skin:Vector/2022/Design documentation
https://www.mediawiki.org/wiki/Skin:Vector/2022/Design_documentation
Visual style
1) How do you make decisions about the visual styling of the interface?
- Comments: Vector 2022 takes a highly functional approach to visual styling. All styling has a clear usability justification, such as helping to clarify the page structure (WCAG design pattern), or helping to improve readability. Visual styling of the interface in service of brand recognition is not a concern, given that blue links, infoboxes, and other content templates are the most recognizable elements of the website. Visual styling intended to evoke a certain feeling, or communicate a conceptual idea (e.g. about knowledge, learning, open source collaboration, volunteering, etc.) has not been attempted, due to the global audience of Wikipedia and people's inherently subjective/contextual interpretations regarding design.
General
1) Prioritizing needs
How does Vector 2022 balance reader needs and editor needs (i.e. balance minimalism and density)? What is the criteria for determining when something should become a setting/preference?
- Comments: there is a constant tension between providing a simple, and focused experience for newcomers and readers, and providing a dense, efficient experience for editors and other contributors. Newcomers and readers want to focus on the content, while having access to a few critical tools (such as the table of contents, language switching, and search). The interface should not present them with elements that might be distracting or confusing. On the other hand, editors need to be able to execute complex workflows with minimal friction, and tend to like having as many elements as possible directly on the screen (rather than in menus). This tension is partially why the interface is so configurable, and why there are different default experiences for logged-out vs. logged-in people. Unfortunately it is not possible to provide everyone with an experience that is tailored to their specific needs. MediaWiki is extensible/customizable, which allows certain people to make the experience better fit their needs, however many (or most) people are not able to easily customize their experience, so it's important to meet as many people's needs as possible with out-of-the-box options. One seeming solution here Below is a rough outline of the general prioritization of needs that Vector 2022 aims for:
2) Font size
- Comments: while there is no WCAG criteria for font-size, it seems to be generally recommended that body text be 16px or larger.In terms of applicable research, in 2016 there was a study done using Wikipedia regarding "The Effect of Font Size and Line Spacing on Online Readability". The study used eye-tracking to evaluate the affects of font size and line spacing, and found:
Using a hybrid-measures design, we compared objective and subjective readability and comprehension of the articles for font sizes ranging from 10 to 26 points, and line spacings ranging from 0.8 to 1.8 (font: Arial). Our findings provide evidence that readability, measured via mean fixation duration, increased significantly with font size. Further, comprehension questions had significantly more correct responses for font sizes 18 and 26. These findings provide evidence that text-heavy websites should use fonts of size 18 or larger and use default line spacing when the goal is to make a web page easy to read and comprehend. Our results significantly differ from previous recommendations, presumably, because this is the first work to cover font sizes beyond 14 points.
1 pixel = 72 points / 96, so the range studied in the research (10–26 points) is equivalent to 13.3–34px, and their conclusion, 18 points, is equal to 24px. Similar to how the line-length in Vector 2022 accommodates both focused reading and scanning, the font-size must do the same. A conservative proposal, taking into account scanning, is to increase the font size to 16px to begin with (which would include an increase to the maximum line-length). Summary of community feedback to increasing the font-size here.
3) Settings
Because of the diversity of needs and preferences of people using the interface, it's often difficult to decide on the best default option. In those cases, the idea of creating a setting often arises. However each setting offered comes with a maintenance burden. Each setting/configuration adds a significant amount of complexity to the maintenance and future development of the interface. The design work, development work, QA, data collection, and more all increase in difficulty. Generally speaking, it's also more difficult to discuss, and reason about, the interface as it gets more complex.
4) Link styling
Blue links are a critical part of the Wikipedia reading experience. They are also a sort of visual signature (i.e. part of the Wikipedia brand) that make Wikipedia pages easily identifiable. Because there are often so many blue links within the article content, the question has come up: should links within the interface have a different styling? In other words, do blue interface links diminish the visual attention of the blue content links (because at the end of the day they are just more blue links on the page)? The main argument that all links should be blue, regardless of whether they are content links or interface links, is that non-blue links are difficult to discover. This could be tested by making the table of contents links black, and seeing if usage of the table of contents goes down. Another aspect of this that has come up is: what about links within dropdown menus? For example the language menu, the personal menu, or the page tools menu? Perhaps in those cases discoverability of the links isn't a concern (rather it's discoverability of the menu itself that matters). The main argument that those links should also be blue is: the interface should not have multiple link styles. Links share certain key properties: they navigate to different pages, they can be right-clicked, they can be shared, etc. It can become confusing if two elements with the same properties look different.
5) Links vs. buttons
For some elements in the interface it is difficult to determine if they should be styled as links or as buttons. Log out, for example, has properties of both a link (because it navigates you to a new page), and a button (because it changes the state of the interface). Edit, for example, is technically a link, but might be better understood as a button. Other elements in the interface are clearly buttons, but are styled as links. Two clear examples are the [hide] element next to the table of contents, and the (thank) element on log entries.
6) Confusing icons
Icons reduce the density of the largely text-based interface, and can provide a helpful contrast to the article text. However they can also be confusing to understand initially. There are currently no strict rules about use of icon buttons vs. text buttons vs. icon + text buttons in Vector 2022. One obvious area for improvement is the similarity of the hamburger icon, table of contents icon,
Resources
Interface terms
Work in progress. For ongoing discussion visit this Google Drawing (*should be converted to a phab task).
Prototypes
Spreadsheet of all prototypes made during the development of Vector 2022, some of which might be helpful to reference in future discussions.