Wikipedia:Flow/Design FAQ

Frequently asked questions about the visual and interaction design strategy we're taking on the Flow project.

Why is the design using a fixed-width? What about my widescreen monitor?

This gets into what is called a measure. The human eye is able to best read large volumes of text when the lines are capped at a certain length. This reduces eye fatigue.

Fixed-width is useful for the following reasons:

1. It makes it easy for the eye to jump to the next line.
2. It provides resting spots for eye away from big blocks of text.
3. Usability tests demonstrate that this reduces stress level.
4. Best practice is 13 words per line, 50% of total screen width.

Why is there so much whitespace/padding?

While most think white space = wasted space, the benefits from having whitespace and padding outweighs the wasted space concern. Whitespace is used for your eyes' resting spots. It helps you focus on content and increases content comprehension by 20%, which is important in discussing complicated issues. It decreases user unsatisfaction, which could result in an unhealthy discussion and harassment. We know what kind of harm to productive conversations misunderstandings and misinterpretation can do.

In addition to the above, white space helps structure a wall-sized amount of text, communicates the relationship between content, and improves scannability and readability. "The eye cannot focus on excessively close lines and … the reader expends energy in the wrong place and tires more easily. The same also holds true for lines that are too widely spaced ... Where reading is smooth and easy, the meaning content of the words is grasped more clearly[.]" The optimal text leading is x1.5 of the text size. Text size we will be using is 16pt at 25pt leading

See also:

• Whitespace myth
• Best practices analysis
• mw:Wikimedia Foundation Design/Whitespace

How will the limited indenting/threading system help?

Mobile readership is growing dramatically (currently, representing almost 1/4th of total pageviews to Wikipedia), so we need to build for a future where we have users who are purely mobile-only. Multiple indentations will have problems displaying on a small screen.

There are also many general usability arguments out there for why discussion systems that use indentation (also called nesting, branching, or threading) to indicate the relationship between comments are problematic. As Joel Spolsky writes:

Branching is very logical to a programmer's mind but it doesn't correspond to the way conversations take place in the real world. Branched discussions are disjointed to follow and distracting. (...) Branching makes discussions get off track, and reading a thread that is branched is discombobulating and unnatural. Better to force people to start a new topic if they want to get off topic.

We want to structure conversations in a way that makes sense and fosters a healthy discussion. The framework we're proposing places more emphasis on discussing the topic and less on tangents. (Users can still engage in tangents with one another, but the primary action that is emphasized is responding to the topic.) To complement this system, we are planning to add the ability to easily split tangents off into new topics, since it's likely that long tangents are, in fact, different discussions altogether. What we want to de-emphasize (without entirely disabling) are long back-and-forth tangents between two users that have no relation to the main topic. This is usually the hallmark of an unhealthy conversation or just one that needs to be moved off to a user talk page.

This is our first stab at a structure that we think might work for the WikiProject discussion space; this exact framework may not make sense in other discussion spaces on Wikipedia, and that's okay – we can have different configurations of threading in different places. We're very open to other ideas and experiments with discussion structure. If you feel like this isn't working, please let us know why, providing as much context as possible so we can understand how to better tailor this framework to the kinds of conversations you might have on a WikiProject talk page.

Why are we using colored-buttons, instead of plain-text-link buttons?

Plain text links are still used on non-primary actions. Not that they are less important, they are, however, not as important as the colored buttons that place emphasis for the ease of the user to know what to click next in a particular workflow. The blue-colored button signifies a progressive action that requires more steps ahead, while a green-colored button signifies the final progressive action. Links are used in areas where the link needs to be deemphasized and/or not very encouraged to use.

Why are the buttons so big?

For emphasis and contrast from blocks of texts. Links, even when blue and underlined, contribute to a less structured view. They make sense within a block of text, not when specific steps are required to get something done.

Are you working on a design without JavaScript, for users with accessibility or browser concerns?

The short answer is "yes"; the long answer is "it's complicated." Designing for accessibility is different than designing for non-Javascript systems, though they are often conflated. Note that building this functionality in takes time, so early versions of testable prototypes may not behave as expected or desired.

It is also important to set certain expectations regarding non-JavaScript versions. The software will work, but it will not work optimally. Also, given the nature of the way Flow is designed to behave, disabling Javascript "for performance reasons" may actually create poorer performance than with Javascript.

For example, Flow will make use of a technology called lazy loading that will reduce immediate request overhead for browsers that have Javascript enabled. This will have the effect of causing the pages to appear to load faster than the non-JavaScript version, which will require all elements to load before achieving full functionality. Replying to a post with Javascript enabled will be done in-line and quickly, in the background, while replying without Javascript will require loading a new page, submitting the reply, and then reloading the discussion.

Where did the Table of Contents go?

Since Flow Boards are, for lack of a better word, "infinite", the concept of a table of contents doesn't scale. Initially, we'll be experimenting with a robust and intelligent "search and filter" system. If it turns out that the search system is insufficient, we'll explore options around dynamic topic listing.

Why is the text grey instead of black?

Pure black text is harsher for the eye to read on a white background, due to strong color contrast. Text will start to flicker, users will experience eye fatigue and strain, and they will be tempted to stop reading. If my eyes gives me a limited amount of time to read and try to understand a discussion thread, especially a complicated one, I'm more likely to get frustrated and give up. That's not a good user experience. The benchmark of text color on white backgrounds to avoid these issues is #333.

Why does it look like Facebook/Twitter/StackExchange, etc.?

The Wikipedia community has very different values from many of the other popular discussion websites. But the important thing to remember is that those sites have done lots of elaborate user research and A/B testing to find what works best for facilitating discussions, reducing flame-wars, and creating inviting and easy-to-use interactions. We don't want to reinvent the wheel when it comes to the basics of online discussion, and we don't want to create something that breaks most Internet users' expectations of what a discussion system looks and behaves like. Flow should be intuitive enough for anyone to use without having to read a manual, and that means following the best practices of discussion interface design.

However, we are aware that the discussion system on Wikipedia is more than just a tool for communication, but also a medium for collaboration and consensus-based decision-making. We are going to keep iterating and responding to your feedback on how to better serve those usages.

In addition to the sites you may be familiar with, here are some others that have structured discussion systems:

1. YouTube
2. Flickr
3. PhpBB
4. Simple Machines Forum
5. Gawker
6. Discourse
7. Gizmodo
8. StackOverflow
9. Medium
10. Quora
11. Tumblr
12. The Verge
13. Reddit
14. Livejournal

If there are patterns from these sites that you think might be interesting to explore on Wikipedia – or if there are patterns you feel do not belong in a Wikipedia discussion! – please let us know!

Why does the interface say "x"?

Some of the wording in the interface is placeholder text, and will change soon. All of the wording in the interface will (eventually) be localizable, so it can be changed in each language (and by each wiki) as is necessary.

Why are we using this Topic and Post order?

Topic order

Infinite scroll, and the elimination of the need to archive - this aspect necessitates top-posting.

More intuitive for newcomers - New topics appearing at the top follows the forum and social-media (and much other software such as email) standard.

Post order

Replies to topics appearing oldest to newest (top to bottom) also make sense as a way of encouraging users to read through the existing conversation before jumping in to comment.

Where can I find more details?

Some more notes, design iterations, and ideas, can be found at mw:Flow Portal/Design.