Reading/Web/Desktop Improvements/Fifth prototype testing

Background and context
Over the past two years we have made various structural changes to the interface. We have moved the search box, the language switcher, and the table of contents. We have organized certain links and tools into menus. And we have limited the content width, added a sticky header, and moved the page title above the page toolbar. Now, with all of these various elements situated in the updated interface, we are turning our attention to the visual design of the interface. By visual design we mean the styling of text, buttons, borders, backgrounds, and spacing in the interface.

Historically our approach to visual design has been simple and functional. We add little styling, if any, to the HTML elements which simplifies the interface both for people using it and for people designing and building it. It also means that our visual design is rather timeless (versus us chasing visual style trends, and then needing to change the visual style every couple of years). Looking at the screenshots below we can see how in Monobook and Legacy Vector visual design is used primarily to divide the regions of the interface, including separating the content from the interface. Both of the skins also have a small amount of personality: Monobook has a black and white image of a book in the background, as well as dark border around lists and tabs, and Vector uses a light blue accent color for some borders and gradient backgrounds. Some initial questions that have guided our visual design process for Vector 2022 are: can we use visual design to further improve the interface? Do we think that visually dividing the regions of the interface, like Monobok and Vector do, is helpful? Do we think the skin needs some additional personality? At what point does the visual design become too much, such that it might become distracting or make the interface confusing? What if we do as little as possible, and take a super minimalist approach similar to the original Wikipedia interface?

Giving feedback
We would love your feedback regarding any of the following design decisions (you do not need to review every section; focus on the ones that are most interesting to you):

In order to give feedback:
 * 1) Menus and toggle switches
 * 2) Borders and backgrounds
 * 3) Active section in the table of contents
 * 4) Logo in the header
 * 5) Blue link and visited link colors
 * 6) Font size


 * Start with two tabs open: this page (which has the context, mockups, and proposals), and your feedback form (where you will indicate your opinions, questions, and suggestions)
 * Most sections of this page also include a prototype, which you should open in a third tab. Each of the prototypes includes an options panel in the bottom-right corner, which allows you to view the different options.
 * Some sections include a proposal from us, which is the option that we think is the best.

Please keep in mind:


 * There might be good options that are not presented here. Feel free to suggest something else if you think it would work better than the options below.
 * If you are comfortable with design and/or coding please feel free to include mockups or prototypes of your ideas (this is not required).
 * Design, and visual design specifically, can be subjective. While we are all entitled to our own opinions we ask that you do your best to explain yours, and how they relate to our design goals of simplicity and usability.
 * If you are submitting your own ideas we would appreciate if you indicate your level of experience with design.

Design files: Sketch, Figma, Google drawings

Code: GitHib repository with base prototype

'''We appreciate amateur designers, and respect experienced designers. We will review all feedback and ideas, and ultimately we will rely on the judgement of experienced designers to make the final decisions.'''

1. Menus and toggle switches
The original Wikipedia interface was mainly text, links, and buttons. Over time we have developed new elements, such as menus and toggle switches. These new elements are not quite links or buttons in the traditional sense, and our approach to styling them has not been entirely consistent. We have an opportunity, with Vector 2022, to develop a consistent approach to the styling of these elements.

1.1 Menus
We use several menus in our interface. In their most simple form menus have two elements: a menu trigger, and menu items. We need to decide how to style both parts of the menu. We're considering blue vs. black, and bold vs. non-bold styling. Please review the options and let us know which one you most prefer and why.

Prototype
Link to prototype: https://di-visual-design-menus.web.app/Brown_bear

You can switch between the different options using the panel at the bottom-right of the prototype. The menu triggers and menu items will update accordingly. Please make sure to check all the menus: search, user menu, language menu, and tools menu.

Our current preference
Blue menu trigger, blue menu items, not bold.

Our reasoning: we think that styling menu triggers in blue will make the interface the easiest for people to use. We think that styling them in bold makes the interface feel imbalanced (particularly in cases where we would have a bold menu trigger next to a non-bold link). We imagine the main concern here is: what if people confuse menu triggers for links? We think that given the context (for example the menu trigger label, as well as the down arrow next to the menu) that people are unlikely to confuse them for links, and we also think that if people do confuse them for links the consequences are little to none. As for the menu items, since they are usually links we think it makes sense to style them the same as we style other links.

Also please keep in mind that it is okay if there are menus that are exceptions to this rule and need to be styled differently. For example, for the menus in the Visual Editor toolbar it might make sense to have black menu triggers. That's okay, we want to start by deciding on the default styling here.

1.2 Toggle switches
Toggle switches are used to show and hide parts of the interface. For example the  element within the table of contents is a toggle, and the   element towards the top of the Recent changes page is also a toggle. Similar to menu triggers we are considering blue vs. black and bold vs. non-bold. Please review the options and lets us know which one you most prefer and why.

Prototype
Link to prototype (Article page): [add link]

You can switch between blue and black using the panel at the bottom-right of the prototype. There are two toggles to view: the  element within the table of contents, and the   element in the Tools menu.

Link to prototype (Recent changes page): [add link]

You can switch between blue and black using the panel at the bottom-right of the prototype. There are two toggles to view: the  element underneath the page title, and the   element within the Active filters panel.

Our current preference
Blue toggle switches, not bold.

Our reasoning: again, these elements are not links, however we think that styling them in blue is the best approach to ensure they are discoverable.

2. Borders and backgrounds
Should we add borders and backgrounds to help divide up the regions of the interface, and if so how should they look? As we mentioned in the Background and context section above, both Monobook and Vector use backgrounds and borders to separate the interface from the content. Backgrounds and borders can also add personality to the interface. However it is difficult to know how functional or necessary they are. We've created several options with progressively more/darker backgrounds and borders. Please review the options and let us know which two you most prefer and why.

Prototype
[add link to prototype]

3. Active section in the table of contents
The table of contents is now on the side of the article, and is fixed in place so it remains visible as you scroll down the page. A new feature is that the table of contents indicates which section of the article you are currently reading (we call this the "active section"). Currently, following from a pattern used on the Article/Talk tabs, the active section in the table of contents is black, and the non-active sections are blue. We like this pattern because it is simple, not distracting, and used elsewhere. We could also use additional styling to indicate the active section. Please review the options and let us know which one you most prefer and why.

Prototype
Link to prototype: https://di-visual-design-toc-active.web.app/Otter

4. Logo in the header
...

5. Blue link and visited link colors
The Web Content Accessibility Guidelines (WCAG), version 2 define a minimum contrast level for links: "For usability and accessibility, links should be underlined by default. Otherwise, link text must have at least 3:1 contrast with surrounding body text, and must present a non-color indicator (typically underline) on mouse hover and keyboard focus." Since we do not underline links by default, our link color choice must meet the 3:1 contrast requirement.

In order to check the contrast of our links with our body text we can use the contrast checker provided by WebAIM.

Current colors
Contrast between current blue link color and body text color : 1.89:1 (❌ Fail) — link to results

Contrast between current visited link color and body text color : 1.01:1 (❌ Fail) — link to results

Proposed colors
Contrast between proposed blue link color and body text color : 3:1 (✅ Pass) — link to results

Contrast between proposed visited link color and body text color : 3.06:1 (✅ Pass) — link to results

Prototype
[add link to prototype]

Proposal
Use  for blue links, and   for visited links.

Our reasoning: the proposed colors meet the minimum contrast with surrounding body text, whereas the current colors do not. Additionally, the proposed blue link color is already part of the Wikimedia Design Style Guide, and is used on our mobile websites as well as in various project logos, so we will be gaining consistency.

6. Font size
The mission of our movement is to provide all of the world's knowledge to as many people as possible. Currently the majority of the knowledge we offer is in the form of text. Research has shown that typographic settings (such as font size, line length, and line height) influence the experience of reading text, both in terms of general comfort (i.e. eye strain and fatigue), and comprehension and retention. Therefore it is important for us to use optimal typographic settings in our interface. An important factor to keep in mind when determining what is optimal for our projects is that people engage both in in-depth reading, as well as scanning of text.

In a previous phase of the project we evaluated the line length of text and concluded that between 90–140 characters per line is optimal (link to writeup). Recently we have spent time researching font size. The most convincing research we have found thus far is ...

Prototype
...

Proposal
...