From MediaWiki.org
< Flow(Redirected from Flow Portal/FAQ)
Jump to: navigation, search

This page hopes to answer the frequently asked questions about the Flow project – the team, scope, release plans, features, and design.

Project and team overview[edit | edit source]

Nomenclature[edit | edit source]

The following nomenclature is used in this document to avoid confusion. This nomenclature is development-facing, not user-facing, and terms may change when visible to the user.

  • Board - a collection of Subscriptions. There may be only one Board per page. You can view any page's Board at Special:Flow/Some_page_name.
  • Flow-enabled - a wiki can specify which pages and namespaces should display a Flow board. For example, several projects' Talk pages, or all User_talk pages.
  • Header - content at the top of a Board (introductory text and such). There are/will be limitations on what can go in the header.
  • Subscription - the "connective tissue" between a Board and a Topic.
  • Topic - a "workflow instance". In the discussion space, this is a single discussion. This document concerns itself primarily with discussion workflows; however it should be noted that workflow instances can take many forms. Topics may be subscribed to by multiple Boards.
  • Summary - a Topic can be summarized. Other workflows might be more elaborate, e.g. "Closed. Answer #7 to this question was accepted by the originator on 2013-10-15".
  • Post - an atomic reply, comment, or object whose parent is a Topic.
    • Comment - synonymous with Post.
    • Reply - a child Post of another Post. In the October prototype, there is only one level of replies and these are called "Tangents".
    • Branch - a series of Posts that are all ultimately children of a single Post.
  • MVP - an acronym standing for "Minimum Viable Product".
  • Flow team - WMF staff working on the Flow project (including developers, designers, analysts, and product managers)
  • Core Features team - WMF development team that builds and maintains features like PageCuration, Echo notifications, and Flow. This team will primarily be focused on Flow this fiscal year (July 2013-July 2014)
  • Extension:Flow, aka "Flow" - the software product, which has two components: a discussion system and a workflow engine. The Flow team will be working primarily on the former this fiscal year (July 2013-July 2014).
  • w:WP:Flow or mw:Flow Portal - the Flow Portals, or homepages.

Development principles[edit | edit source]

With any complex software project, it's almost impossible for the designers, developers and product people to know everything. This is a particular problem in an environment like that of the Wikimedia projects - due to the sandbox-like nature of the place, there are tens of thousands of different workflows, different user needs, and different problems. Even if we could accurately identify all of them, we can't necessarily tell if our solution is the right one until we put it in front of users.

Accordingly, we're keeping two things in mind while we're developing the Flow software. First: we are partners with the community on this. Editors are welcome and encouraged to participate in the development process, pointing out things we've missed, identifying and describing new workflows, and helping keep us honest - when something hits this level of complexity, it's impossible to make things work without as many people helping as possible. Before and after we build things, we'll open a conversation about the feature. Second: a lot of the work we're going to do, at least initially, is experimental: we don't know if it's the right implementation of a feature. If it's not, we'll be happy to roll it back.

Components of the discussion system[edit | edit source]

Here's a brief list of the main feature areas for a discussion system, a description of what the plan is for each one, notes about the status, and links to any ongoing discussions. It'll be regularly updated to factor in new discussions, and to note the permanency of the feature.

Component Solution in Flow Status Notes Discussion
Message separation and nesting Different messages in the same thread will be visually distinguished through both design cues and indentation. The first release will feature two levels of threading (or, one set of indentation), for reasons explained in the Design FAQ. Experimental The limited indentation is something we want to try, but we're fully aware that it may not turn out to be practical, and happy to experiment with more levels of threading if necessary. We discussed the advantages/disadvantages of limited versus unlimited indentation (and different limits on indentation) at this feedback request thread - more feedback would be welcome :). -
Navigation and archiving The Flow software features infinite scrolling on a talkpage, and will be combined with a search infrastructure; there won't be a table of contents. It will have a toggle to collapse all threads. Experimental This is something we're going to have to actively collaborate to make work; little is more important than actually accessing and navigating between discussions. If the search functionality isn't satisfactory (once implemented) we can experiment with other ways to get the same information. Discuss
Design density The Flow software is deliberately using more whitespace than wikipedia currently does - whitespace is actually beneficial for reading. Having said that, the current intended level of whitespace is something we're happy to alter as is needed, and is also smaller than the level displayed in the prototype. TL;DR, it won't be as sparse as it currently looks :). Experimental This is something we're going to discuss when we've got the prototype ready for wide-scale testing, and again when we've deployed it to the wikiprojects that have opted-in. Discuss
Comment editing Flow as it is configured currently doesn't allow users to edit the comments of others - the pros and cons of this are discussed more in the FAQ. Logged-in users can edit their own comments, including markup and templates. Experimental This will be present in the prototype we'll show to the community before deploying it on-wiki, but it's a configuration setting: we can allow it if people want (or allow it to only administrators, or only autoconfirmed users, for example). (no ongoing thread)

(prior threads)
Topic order Flow will have "top posting", in the sense that what topics will be displayed from last-added to first-added: within topics, posts will operate from first-added to last-added within each subthread (normal chronological order). Experimental The main reasons for this are in the Design FAQ, but we're open to feedback. Discuss
Timestamps Flow currently has human-readable relative (elapsed) timestamps on posts, topics, and history views, which expand to show full UTC time on hover. After initial experimentation with these timestamps on the board and history views, we decided to change to full (exact) UTC timestamps for higher granularity. Experimental -
Wikitext editing Topic titles of Flow posts do not currently render wikitext. Within Flow posts and header areas, virtually all forms of wikitext, extensions (such as mw:Extension:Math), and templates are supported (see Parsoid limitations for templates that do not currently work; these are very rarely used in discussions). Confirmed -
Posts don't update On WMF wikis, Flow stores the parsed HTML of the header area and posts. When you view Flow content you see this stored HTML; when you edit the header area or a post you see the original wikitext and it is parsed again on save. This means that changes to a template will not appear in the Flow headers and posts using it until they are edited. Experimental Flow posts are snapshots of a moment in time, so allowing templates within posts to change days, weeks, or years later, without any outward indication of the change, is not something we want to support. (We realize that while "What links here" doesn't work for Flow content, this feature is more problematic.) Depending on user needs, we may change the way the header area works, so it can accept transclusion or can automatically update for commonly used project and article banners. -
Post moderation "Hide", "Delete" and "Suppress" - analogous to revert, revision-deletion and oversight - are planned features for Flow, and will be present before the first deployment on Wikipedia. As well as applying to specific comments, users will also have the ability to delete/suppress entire threads. Experimental -
Input method As explained below, both VisualEditor and wikitext will be supported. Confirmed The first release will only include wikitext support. We plan to add VisualEditor support via Beta Features, later on. (So that you can opt-in to one, but not the other, and vice-versa). -
Workflows Wikipedia's processes are incredibly complex, and so no rigid one-size-fits-all system will ever work. Instead, we're building a workflow language which users can use to script Wikipedia processes, much like the current template-based process scripting. The differences are that it will integrate with MediaWiki proper and that, as a result, users using the processes won't have to be exposed to the internal gunk. To be discussed You can read more about workflows below or in a recent developer request for comment about them. We're going to do a lot of work talking to the community about the processes that are generally used, over the coming months, so we know what the language needs to do before developing it. (no ongoing thread)

(prior threads)
Page/thread protection This is still to be discussed. Since threads can potentially exist on multiple discussion pages, a protection system that is equitable to users is difficult to get just right. To be discussed -
Auto-signing Flow will attribute content changes automatically (both new-posts, and edits to anything). Sinebot and {{unsigned}} will become unneeded. Confirmed -

Who is working on Flow?[edit | edit source]

The Flow team and their roles can be found at Flow/Team.

Release and features FAQ[edit | edit source]

Is this replacing talkpages?[edit | edit source]

Yes, but not for a long time. Talkpages are incredibly complex, with the number of processes they have to support (discussion closing, unblocking, requested moves) and the number of things a user can do on them – there's some research into this at mw:Flow Portal/Use cases.

The first release (live on English Wikipedia since February 2014) is a trial of Flow on just a few talkpage where community members have volunteered to test the software. Post MVP, we will roll out gradually to more pages and namespaces on a limited opt-in basis. At some point in the future, once the software is stable and a significant portion of active Wikimedians have had a chance to trial it and offer their feedback, we may mandate Flow on all discussion pages, but we have 1-2 years' worth of work ahead of us before that happens.

What pages will be Flow-enabled initially?[edit | edit source]

In the first release, we've enabled Flow on a few WikiProject talkpages. Throughout the rest of 2014, on English Wikipedia, we plan to enable Flow on more WikiProject talkpages, offer Flow as an opt-in Beta feature on user talk, and enable Flow on a small sample of article talk pages – all of these deployments will occur on an opt-in basis, with consensus from community members who use those discussion spaces.

Can I opt out?[edit | edit source]

During the early release period throughout 2014, Flow will be opt-in for existing users – you won't be forced to have it on your talkpage if you don't want it. If you convert to using Flow during the trial period (in a WikiProject discussion space, on your user talk page, etc.), we'll be able to convert the content back into a normal talkpage if needed. In terms of viewing, you won't be able to opt out of seeing Flow. If other users have converted their talkpages to Flow pages, or reached consensus that a Wikipedia or article talkpage should be converted, there's not going to be a way to avoid using Flow if you want to contribute to that page.

At some point in the future (no sooner than 2015), after a great deal of community testing and feedback, we may graduate the opt-in user talk trial to the default experience, enable Flow on new talkpages, begin converting existing talkpages to Flow, etc. If you're concerned about how Flow will look and behave, your best bet is to trial the software early, so you can give us feedback on what needs changing well before we begin discussion on whether or not it should become the default on all discussion pages.

What will happen to current talkpage discussions?[edit | edit source]

The current plan is to archive the talkpage and link to the archives from the talkpage header. Each Board has a header area, for permanent things like project banner templates and archive links to go in. See this copied article talkpage, or mw:Talk:Sandbox.

Ultimately, we plan to have a search feature for Flow that allows users to go through the pre-Flow archives and find content from there, too, but this is not part of the first release.

What about IP/anonymous editors?[edit | edit source]

Anonymous users will be able to use Flow-enabled talkpages as any other user. When Flow is more widely enabled, they'll have Flow-enabled talkpages (again, like any other user).

Why don't we use a pre-built system, like PHPBB or Discourse?[edit | edit source]

The simple answer is that "they won't cut it". The complex answer is that pre-built systems are designed around singular use cases, and Wikimedia projects do not have "singular" use cases. On the English Wikipedia alone, the following are discussions that take totally different forms:

  • User talk
  • Article talk
  • Requests for Comment
  • Request for Adminship
  • Deletion discussions
  • Merge discussions
  • Village pump discussions
  • AN/I
  • Arbcom cases

The list goes on and on. A singular package will not and cannot cover these cases. So we have to build our own.

Why not use LiquidThreads?[edit | edit source]

LiquidThreads (LQT) was an early attempt at creating a structured discussion system. It has both strengths and weaknesses. After exploration and discussion, LQT was abandoned as a solution going forward for several reasons: incredibly poor performance, due to the way individual comments or posts are stored, parsed, rendered, cached, and assembled; no support for globally unique identifiers; and lack of flexibility with regards to workflows and collaboration techniques beyond simple discussion.

How will Flow handle spam and vandalism?[edit | edit source]

In the first release, each topic and individual post will come with a set of moderation features. These are:

  1. Hide (equivalent to reversion/rollback);
  2. Delete (equivalent to revision-deletion), and
  3. Suppress (equivalent to oversight or suppression)

Handling spam and vandalism in Flow should actually be easier than dealing with it on existing talkpages. Because Flow topics and comments exist as discrete elements, a specific post can be removed with a single set of actions: there's no need to go through the page history removing intervening comments, for example. In terms of spam, Flow is integrated with the AbuseFilter and the global and local Spam Blacklist.

Will Flow support wikitext or VisualEditor?[edit | edit source]

Both. Flow is linked into Parsoid, which is the software that VisualEditor uses to read and write wikimarkup. Hooked into that is a wikitext editor and, in later releases, VisualEditor. Users will be able to pick which they want to use.

Will Flow support all the templates and other markup we need in discussions?[edit | edit source]

Yes. Whatever markup Parsoid supports, Flow can support. There may be restrictions on certain magic words or complex templates that affect performance, but, generally speaking, anything users commonly need to use (mathematical symbols, references, templates) can be added to a Flow post. You can see and test templates and other markup in the prototype, eg this thread has some examples. Note that we've only imported a few hundred test templates – more can be requested at w:Wikipedia:Flow/Top templates.

What happens to my custom signature?[edit | edit source]

Flow will not directly support custom signatures, for a couple of reasons. The first is that they're disruptive from a UI point of view. Custom signatures are great for letting people know who said what; they allow for a specific user to be easily, visually distinguishable in discussions. The problem is that the way this comes about is by allowing refactoring of where links live, how they're displayed, and so on. As a result, there's a complete lack of consistency, which hurts the ability of users to navigate easily. One user might have their talkpage link in one place – another in a different place, and with a signature that doesn't actually reveal their username. The second is technical; allowing people to add raw HTML formatting into Flow boards could cause serious issues and errors in how the page is displayed.

Having said that, we appreciate the advantages of custom signatures; it allows for some distinguishing elements, it allows for forms of identification that extend beyond username. We're going to be working a "preferred name" field into the interface to allow for the latter; while it won't be as malleable as the status quo, it will allow for some originality. Your own posts will be visually highlighted to be more easily findable.

Will we be able to edit other people's posts?[edit | edit source]

In the first release, no. Only administrators can modify the posts of others (anyone can edit topic titles, however). As with all design decisions at the early stage of this project, this is open to being revisited if it negatively impacts users.

Users being allowed to edit the posts of others is atypical and unexpected: nearly every discussion medium on the modern Internet does not allow this, because it breaks the expectation that the comment you are replying to is genuine, and that your comment will not itself be tweaked or corrupted by others. The need to meet this expectation should be balanced with the fact that the community has developed various workflows in discussions and in the talk namespaces that are dependent on that kind of editing and interleaving. See the list of situations where users need to be able to edit comments

How will you support all of the processes Wikipedia uses?[edit | edit source]

It's a complex problem, which is why we're starting with the most basic process – unstructured user-to-user discussion – first. Before we proceed to enable Flow in different namespaces, we will identify the critical workflows that need to be supported with software and build lightweight support for those processes: for example, a simple block/unblock workflow on new user talk pages. In the first 1-2 years of this project, we do not expect to cover 100% of the workflows across all our projects. Because each Wikipedia (and other Wikimedia sites) has developed its own workflows, based on the local social conventions, templates, categories, and bots, there is no easy way to discover all of these processes or build something based on feedback from one Wikimedia community and abstract it to other projects.

Longer term, once we've completed the discussion side of Flow, we may build a workflow engine – a structured language that editors can use to describe a workflow and incorporate it into Flow, for a specific action or a specific page.

Design FAQ[edit | edit source]

Why is the design using a fixed-width? What about my widescreen monitor?[edit | edit source]

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.[1][2]
  4. Best practice is 13 words per line, 50% of total screen width.[3]

We'll keep iterating to make sure Flow falls into the optimal readability range for different size screens.

Why is there so much whitespace/padding?[edit | edit source]

Whitespace is used for your eyes' resting spots. It helps you focus on content and increases content comprehension by 20%,[4] 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.[5]

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[.]"[6][7] The optimal text leading is x1.5 of the text size. Text size we will be using is 16pt at 25pt leading [8]

See also:

Why is there limited indenting/threading of comments?[edit | edit source]

Mobile readership is growing dramatically (currently, representing almost 1/4th of total pageviews to Wikipedia),[9] 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.[10] 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.[11]

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 new discussion.

Why are we using big colored buttons?[edit | edit source]

The buttons in Flow are part of Agora, a new standardized UI library for Wikimedia projects. We use colored buttons to emphasize what to click next in order to complete 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 action is not necessarily encouraged or discouraged (e.g., replying to any specific post).

Are you working on a design without JavaScript, for users with accessibility or browser concerns?[edit | edit source]

Yes, we aim to make most of the core Flow functionality work without JavaScript, on older browsers, etc. 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?[edit | edit source]

Since Flow Boards are, for lack of a better word, "infinite", we're exploring different ways for users to navigate the discussions on a board. The trio of icons at the top of a Flow board collapse and shrink the topics currently loaded down to "topic bars", and you can click a topic bar to collapse/expand it. We're also working on a floating topic navigation element that changes as you scroll to show earlier/later topics.

Why is there gray text?[edit | edit source]

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.[12][13][14]

Why does it look like Facebook/Twitter/StackExchange, etc.?[edit | edit source]

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 other sites we look to for inspiration/guidance 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 are we using this Topic and Post order?[edit | edit source]

The default order in the first release is: new topics appear at the top of the page, and new posts within those topics appear at the bottom, below older posts. In subsequent releases, we will be adding features that will allow users to sort the board to show content in different ways (e.g., filtering for topics by recently activity, showing topics from most to least replies, etc.).

Topic order

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

More intuitive for newcomers and more efficient for seeing new content. New topics appearing at the top follows standard set by many forums, social media, and email.

Post order

Replies to topics appearing oldest to newest (top to bottom) 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?[edit | edit source]

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

References[edit | edit source]

  1. http://psychology.wichita.edu/surl/usabilitynews/62/whitespace.htm
  2. http://sixrevisions.com/usabilityaccessibility/10-usability-tips-based-on-research-studies/
  3. http://www.smashingmagazine.com/2009/08/20/typographic-design-survey-best-practices-from-the-best-blogs/
  4. http://www.humanfactors.com/downloads/dec05.asp
  5. http://www.sciencedirect.com/science/article/pii/S0167923608001851
  6. http://psychology.wichita.edu/surl/usabilitynews/62/whitespace.htm
  7. http://psychology.wichita.edu/surl/usabilitynews/62/whitespace.htm
  8. http://www.smashingmagazine.com/2009/08/20/typographic-design-survey-best-practices-from-the-best-blogs/
  9. http://reportcard.wmflabs.org/graphs/pageviews_mobile
  10. http://www.codinghorror.com/blog/2012/12/web-discussions-flat-by-design.html
  11. http://www.joelonsoftware.com/articles/BuildingCommunitieswithSo.html
  12. http://www.lighthouse.org/accessibility/design/accessible-print-design/making-text-legible/
  13. http://www.lighthouse.org/accessibility/design/accessible-print-design/effective-color-contrast
  14. http://ia.net/blog/100e2r/