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

Flow is a project of the Collaboration team at the Wikimedia Foundation to build a modern discussion and collaboration system for Wikimedia projects. Flow provides features that are present on most modern websites, but which are not possible to implement in wikitext. For example, Flow automatically signs posts, threads replies, and permits per-topic notifications.

The main goals for the Flow project are:

  • to make the wiki discussion system more accessible for new users
  • to make the wiki discussion system more efficient for experienced users
  • to encourage meaningful conversations that support collaboration

Flow has been deployed on user talk and wiki-wide discussion pages on various languages and projects, as well as Mediawiki.org – see Flow/Rollout. In September 2015, the team released an opt-in beta feature for wikis that request it, which will allow users to turn on Flow for their own user talk page – see Flow/Request Flow on a page.


Development status[edit]

As of February 2017, Flow is still being actively maintained. The team is supporting the product and will continue to fix bugs and to make sure that people who are using Flow continue to have a good experience. Communities can try Flow, knowing that there are some limitations and that additional major features will probably not be added during the next few months.[1]

However, Flow has not scheduled for major development since the middle of 2015. "Not in active development" means that significant new features are not being created at this time. The Collaboration Team remains interested in the project and in providing an improved system for structured discussions. Some communities have decided to use Flow and are asking for support.[1]

For the near term, Collaboration team is focusing on Edit Review Improvements project. However, after that work is done, there are some often-requested areas for improvement in Flow which the team plan to improve. To make decisions about the way forward in this area and future developments (scheduled for June 2017[2]), a survey has been sent to many Flow users in September 2016,[1] results published in January 2017. Those results will be used to support a decision for the Wikimedia Foundation’s Editing department plans for the next fiscal year.


New users on English Wikipedia have become less and less likely to participate in on-wiki discussions,[3] in spite of a growing and mostly automated body of messages directed at them.[4][5] We also know that free-form wikitext talk pages present a significant barrier to new users[6][7][8] and even some experienced users.[9]

In addition, experienced users often employ a suite of workarounds to help them manage and keep track of the many ongoing conversations that they're involved in, using tools that aren't necessarily well-suited to the task. For example, watchlists and diffs are page-level tools, making it hard to distinguish between the conversations that users are interested in and the ones that they're not. Experienced users can waste a lot of time checking diffs on an active talk page, especially if the most active conversation isn't the one that they're interested in following.

We believe that user expectations for a modern discussion system are increasingly diverging from the reality of talk pages today, and that all of our users deserve discussion and collaboration software that meets their needs.

Expectations Current reality
  • Easy to distinguish topics
  • A clear "reply" button
  • Obvious and consistent comment authorship
  • Automatic "signing"
  • Notifications of replies to all discussions
  • A simple comment field
  • Rigid predictable technical restrictions on who can edit what
  • Conversations that thread to infinite depth
  • Inconsistent reply system (whose talk page hosts the conversation?)
  • Comment authorship shown at the end of comment or not at all
  • Wikitext/code
  • Notifications only when the conversation happens on their own talk page or someone links to their userpage
  • Full page or Full section editing only
  • Fluid social conventions on which edits stand scrutiny, which do not, and which are objectionable
Users expect a modern and intuitive discussion interface.

Talk pages—as a discussion technology—are antiquated and are not intuitive.

Users are surprised by the cultural norms of the community.

Many things about the culture that has grown up around talk pages (such as "talkback" templates or being able to edit other people's comments) are confusing. That is not to say those conventions are wrong, merely not what those users are prepared for.

We believe that a modern user-to-user discussion system will improve the projects.

Better methods for collaboration will improve collaboration, which will improve all of the projects.


Q1 (July-September 2014)[edit]

User-facing features:

  • Subscriptions:
    • YesY Done Subscribe to individual topics
    • YesY Done Auto-subscription for topic user has created or participated in
    • YesY Done Subscribing to Flow board = notifications for new topics on that board
  • Notifications:
    • YesY Done Roll-up notifications for activity, one notification item per topic
    • YesY Done Clicking on a notification takes you to topic page, with unread messages marked with color
    • YesY Done Read/unread state for Flow notifications
    • YesY Done Mark all as read
  • YesY Done Log item improvements for Watchlist and Contributions (initial step done, but bugs in Contributions need to get fixed)
  • YesY Done Hide feature redesign -- actually removing hidden threads from the page, still accessible through history and contributions
  • YesY Done Mobile UI and design - board and threads are done, we'll do update to mobile Echo later

MediaWiki changes:

  • YesY Done Create a namespace for topic pages
  • YesY Done Notifications: dynamic read/unread states

Community partnerships:

  • YesY Done Work with the Co-Op team on changes that we'd need for Flow to be useful to the Co-op.
  • YesY Done Work with the French WP Forum des nouveaux, ditto

Quarterly review following Q1: [2]

Q2 (October-December 2014)[edit]

User-facing features:

  • YesY Done Table of contents
  • In progress In progress Search on a Flow board -- (coming in Q3)
  • In progress In progress Structural UI changes to enable editing other people's comments -- (partly done in Q2, more in Q3)
  • YesY Done LiquidThreads: Transition to wikitext or Flow (based on Andrew's script)
  • N Not done A more sophisticated version of subscribe to a board -- giving users more options on how notifications appear in Echo and in watchlists. (Not done in Q2, but it will definitely come up later on.)
  • YesY Done Review of fixed width and indentation levels. (Just a review. Not a promise.) If we keep fixed width, we need a solution for tables and galleries. (review done, changes coming in Q3)
  • YesY Done Special:EnableFlow to have a more scaleable solution for creating new Flow boards (partly done in Q2 with Liquid Threads conversion, more in Q3)
  • N Not done Turn summarize into a scratchpad area of full wikitext, connected to the conversation. Actual design TBD. (not done in Q2, but it will definitely come up later.)
  • N Not done "Resolved" function -- mark a topic as resolved. Then we build a sort for resolved/unresolved. (Just "closed" in Q2, but we'll return to this.)
  • YesY Done Visual Editor integration with Flow input boxes (coming in Q3)

Community partnerships:

  • YesY Done Continue to work with Co-op and Forum des nouveaux
  • YesY Done Establish more partnerships with communities in other languages, TBA (working with Catalan, Portuguese)

Quarterly review following Q2: [3]

Q3 (January-March 2015)[edit]

The priority in Q3 and Q4 is to work with communities on several different language Wikipedias to deploy Flow on pages and use cases where it can be helpful, and to focus on building features that will help active editors on those wikis to work together, and reach out to new contributors.

User-facing features:

  • YesY Done A new model for indentation for discussion tangents (released, now evaluating the impact)
  • YesY Done VisualEditor integration, with an editing toolbar (first version live, there will be more additions)
  • YesY Done Category support for Topic pages
  • YesY Done Editing other users' posts, with an Echo notification if your post is edited

Community partnerships

  • YesY Done WP languages with Flow-enabled project pages (help, village pump): Catalan, French, Portuguese
  • YesY Done WP languages with Flow test pages: Chinese, Hebrew, Punjabi, Russian, Telugu

Q4 (April-June 2015)[edit]

User-facing features:

  • YesY Done Deleting and moving Flow boards
  • YesY Done Page-width toggle, with Flow board header moved to the siderail
  • YesY Done Mark-as-resolved feature
  • YesY Done Edit patrolling
  • N Not done Search on a Flow board -- postponed until after Q2 2015-2016

Q1 2015 (July-Sept 2015)[edit]

User-facing features:

  • In progress In progress Opt-in for individual user talk page in beta features, on wikis that request it
  • YesY Done Convert LiquidThreads pages to Flow on Mediawiki.org, other wikis that want to convert
  • In progress In progress Split Echo notifications into two icons -- Alerts and Messages

Q2 (Oct-Dec 2015)[edit]

Collaboration team will be working on:

  • Global Echo notifications, cross-wiki
  • Workflows, see the Collaboration team page for more information

Components of the discussion system[edit]

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 Different messages in the same thread will be visually distinguished through design cues. Confirmed MediaWiki users have adopted indentations as a workaround for the difficulty of presenting discrete messages on a completely unstructured blank wiki page. Flow will present messages in a more structured way, using usernames and other design cues to separate posts in a given topic. -
Nesting The current release (as of August 2014) has three levels of threading (or two sets of indentations). Experimental MediaWiki users also use indentations to mark that a message is a direct reply to a specific earlier message, rather than a reply to the ongoing conversation as a whole. This is an important goal for complicated, structured discussions like an RfC, where conversations often diverge into multiple sub-threads. On the other hand, for simpler and shorter discussions, it may be confusing to have to choose between several different ways to "reply". The team is considering ways to simplify the interface for simple discussions, and allow for more complexity in more complex, structured discussions. There will be a lot more discussions and experiments on this subject before we're done. :) -
Navigation and archiving Currently (August 2014), the software features infinite scrolling on a Flow board, with all of the discussions accessible on the same page. A sorting feature allows users to reorder the board's conversations based on the time that the topic was started, or by "recent activity" on the discussion. Individual topic subscriptions and notifications help users to find and manage the conversations that they're actively participating in. In addition to these, the team will create a search feature to find older topics, and there will be a Table of Contents in the side rail to help users navigate quickly between topics on a board. Experimental There's a lot more work to be done on this. One of the core goals for Flow is to make talk page discussions more efficient for experienced users -- finding the discussion that you're looking for (and filtering out the ones that you're not interested in) is a big part of making the system more efficient. Sorting and subscriptions are steps in this direction. We still need to figure out how search/filtering will help users find specific discussions. Discuss
Design density The Flow software is deliberately using more whitespace than wikipedia currently does - whitespace is actually beneficial for reading. On the desktop, the open space on the right will (probably) have the Table of Contents, and a link to archives. Experimental There is a wide range in users' preference for information density. Core MediaWiki is very information-dense, with a completely fluid width and tight line spacing -- and, possibly not coincidentally, experienced MediaWiki users tend to prefer greater information density. (This may be the equivalent of natural selection.) One of the goals for Flow is to make the discussion system more accessible for new users, and part of that may include a less info-dense design. We're still figuring out the right balance, and this may include individual preferences for display density, with Gmail's recent redesign as an example. Discuss
Editing messages Logged-in users can edit their own posts, including markup and templates. 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 below. Experimental This is present in the current version (as of August 2014), 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). We have to look more closely at the use cases that require editing other people's posts. -
Topic order Flow will have "top posting" by default, in the sense that topics are displayed from last-added to first-added: within topics, posts will operate from first-added to last-added within each subthread (normal chronological order). Users can also choose to sort by recently active conversations, to make it easier to find ongoing active threads. Experimental The main reasons for this are explained below, 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. Confirmed -
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 -
Post moderation "Hide", "Delete" and "Suppress" - analogous to revert, revision-deletion and oversight - are current features for Flow, and will be present before the first deployment on Wikipedia. Users will also have the ability to delete/suppress entire threads. Experimental Flow currently includes a version of these features (as of August 2014). However, we're not completely satisifed with how "hidden" and "deleted" discussions are displayed on the Flow board; we'll come back for another revision before the end of the year. -
Input method In the current release (August 2014), wikitext is supported. VisualEditor will be supported later. Confirmed VisualEditor support will come, with collaboration from the VE team. 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). -
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 -

Release and features FAQ[edit]

Is Flow replacing talk pages?[edit]

The Flow discussion features are being used successfully on user talk pages, help spaces and village pump-style group discussion pages.

There are other, more complex use cases for some wiki talk pages, which will be addressed as part of the Workflows project.

What wikis are using Flow?[edit]

As of December 2016, Flow is enabled on 25 wikis (see Flow/Rollout), some of them are using it as a beta feature on user talk pages. You can make a request to have Flow on your wiki (WMF wikis only). The technical process for rollout, is documented at Flow/Rollout#Process.

Can I opt out?[edit]

In terms of viewing, you won't be able to opt out of seeing Flow. If other users have converted their talk pages to Flow pages, or reached consensus that a Wikipedia or article talk page should be converted, there's not going to be a way to avoid using Flow if you want to contribute to that page.

What happens to current talk page discussions?[edit]

When Flow is enabled on an active wiki talk page, the existing dicussions are moved to an archive page. There's a link in the Flow board's side rail to the archive page. Old discussions aren't thrown away; we know how important discussions are to understanding the collaborative history of a wiki page or project.

We won't be able to "convert" wiki talk pages into the Flow format, because there isn't a clear one-to-one correspondence between a wiki talk page edit to a Flow post. It's more respectful to the discussions if we preserve the original format, on an archive page.

What about IP/anonymous editors?[edit]

Anonymous users are able to use Flow-enabled talk pages as any other user. However, subscriptions to individual topics, and notifications based on those subscriptions, will only be available to logged-in users.

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

On a wiki, the discussion system needs to connect to the rest of the wiki systems, including history pages, contributions pages and diffs. It would be harder to integrate a pre-built system than it is to build our own.

Why not use LiquidThreads?[edit]

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: 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.

We have a conversion script that turns LQT discussions into Flow topics, which has now been used to convert all the LQT threads on MediaWiki.org into Flow. Details at Flow/Converting LiquidThreads.

How does Flow handle spam and vandalism?[edit]

In the current release (September 2015), each topic and individual post comes 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. See mw:Extension:Flow/Moderation for technical details.

Does Flow support wikitext or VisualEditor?[edit]

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 VisualEditor. Users are able to pick which they want to use, and the last edit-mode that is used to edit the content within, will be saved as a hidden preference. VisualEditor is used as the "preview" function.

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

Whatever markup Parsoid supports, Flow can support. 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 sandbox, e.g. this topic has some examples.

What happens to my custom signature?[edit]

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 a custom signature; it allows for some visually distinguishing elements, and it allows for forms of identification that extend beyond username (e.g. in a second language). 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.

Can I edit other people's posts?[edit]

Yes. In the current release, autoconfirmed+ users are able to edit the posts of others, to fix problems or look at the wikitext. When you edit another person's post, there's a clear signal on the page that the message has been edited.

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

It's a complex problem, which is why we started with the most basic process first – unstructured user-to-user discussion.

In October 2015 the Collaboration team postponed the Workflows project, which would handle the more complex talk page use cases.

If you are not working on Flow, will the visual editor be enabled on talk pages?[edit]

​No. This question comes up quite often.

  • The visual editor (VE) is designed to edit content, plain pages of text[2].
    • Talk pages aren't content. Many of the tools and design patterns that make VE nice to use to edit content make it poor to use for discussions. ​
    • To make it usable for discussions, we would have to remove or break many of those patterns in VE. We have spent a lot of time researching with users what works best there.
  • VE can't deal with structured discussions and plain-text discussions are not structured discussions.
    • Discussions like they are on traditional talk pages are not structured discussions from a technical perspective, despite the fact there is a certain number of colons or bullet points added to each answer to provide a pseudo-structure. With the current design of classical discussions, a piece of software can't know who has replied to whom – only humans can. There is no real connection between posts (which post is the parent/child of which), which is the definition of a structured discussion.
    • In Flow, each post is independent with a unique ID, linked to other posts and to a Topic (also with a unique ID), with a specific history, and all posts can be targeted precisely. It would be possible in the future to have conversations at multiple places, to move topics or replies, and to create sub-discussions with Flow. Classical talk pages, using VE or not, do not allow that.

I can't use any page on Flow. Why?[edit]

It is probably a compatibility problem. That page may help you.

Why do you use Topics and replies URLs that are not understandable by a human (like Topic:RdZ3SJY7W5Wtr)[edit]

These URLs are an unique ID. Flow has been designed to allow cross-pages and cross-wiki display which an unique ID. It is not possible to have multiple topics titled ''Topic:Hello''. A way to change topic names has been investigated to have something more explicit, like Topic:Hello-RdZ3SJY7W5Wtr, but that still have that necessary unique ID somewhere.

Is there a way to all find pages that use Flow ?[edit]

For wikis using CirrusSearch this can be found using the "contentmodel" keyword, e.g. Special:Search/contentmodel:flow-board. This will only find flow pages, not the threads within them until they are cleanly separated (phab:T73196).

Design FAQ[edit]

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

Whitespace is used for your eyes' resting spots. It helps you focus on content and increases content comprehension by 20%,[10] which is important in discussing complicated issues. It decreases user dissatisfaction, which could result in an unhealthy discussion and harassment. We know what kind of harm to productive conversations misunderstandings and misinterpretation can do.[11]

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

See also[edit]

That being said -- there is a wide range in users' preference for information density. Core MediaWiki is very information-dense, with a completely fluid width and tight line spacing -- and, possibly not coincidentally, experienced MediaWiki users tend to prefer greater information density. (This may be the equivalent of natural selection.) One of the goals for Flow is to make the discussion system more accessible for new users, and part of that may include a less info-dense design. We're still figuring out the right balance, and this may include individual preferences for display density, with Gmail's recent redesign as an example.

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

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

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]

The buttons in Flow are part of OOui (previously from 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]

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.

Why is there gray text?[edit]

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.[17][18]

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

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]

The default order in the current release is: new topics appear at the top of the page, and new posts within those topics appear at the bottom, below older posts. There is also a sorting feature that allows users to see the most recently active topics at the top.

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/updated content. New/updated 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.

Development principles[edit]

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.

Who's working on Flow?[edit]

See: Collaboration/Team

Contact and links[edit]


  1. 1.0 1.1 1.2 Based on James Forrester's message on wikimedia-l mailing-list, September 2016
  2. 2.0 2.1 Based on James Forrester's message on wikimedia-l mailing-list, June 2016
  3. New user participation in deletion discussions and community discussion spaces.
  4. Bytes added to English Wikipedia by namespace
  5. Messages to new users by type.
  6. User test results
  7. WMF Usability study highlights 1
  8. WMF Usability study highlights 2
  9. Experienced user responses
  10. UI Design Newsletter – December, 2005, Human Factors International
  11. Norman A. Johnson, Randolph B. Cooper and Wynne W. Chin, Anger and flaming in computer-mediated negotiation among strangers, Decision Support Systems, Volume 46, Issue 3, February 2009, Pages 660–672
  12. Barbara Chaparro, J. Ryan Baker, A. Dawn Shaikh, Spring Hull, & Laurie Brady, [1] The Software Usability Research Lab (SURL), July 12, 2004
  13. Michael Martin, Typographic Design Patterns and Best Practices, Smashing Magazine, August 20th, 2009
  14. Mobile Pageviews, Wikimedia Report Card
  15. Jeff Attwood, Web Discussions: Flat by Design, Coding Horror blog
  16. Joel Spolsky, Building Communities with Software, Joel on Software blog
  17. Aries Arditi, Designing for People with Partial Sight and Color Deficiencies, Lighthouse International
  18. Oliver Reichenstein, The 100% Easy-2-Read Standard, iA