構造化された議論/よくある質問

 展開と機能、よくある質問

トークページは構造化された議論に置き換わっていますか？

構造化した議論の会話の機能は、利用者トークページでもヘルプ名前空間、井戸端型のグループ協議でも有効に使ってもらっています。

どのウィキが構造化した議論を採用している？

See Structured Discussions/Wikis).

オプトアウトできますか？

閲覧の観点では、構造化した議論を「見ない」ことは不可能です。 構造化した議論を有効にしてあるページでは、そのページに投稿しようとするとこの機能を避ける方法はありません。

現在のトークページの議論はどうなる？

進行中の議論のページに構造化した議論ツールを採用すると、既存の議論は過去ログページへ移動されます。 構造化した議論のボード上、脇の方に過去ログへのリンクボタンがあります。 古くなった議論は、除去したりしません。協議は過去のものであっても、特定のウィキのページやプロジェクトを皆さんがどんな形で共同作業してきたかなど理解でき、重要だからです。

ウィキのトークページを、構造化した議論のフォーマットに「変換」することはできません。なぜならば、構造化した議論の投稿と既存のウィキトークページの間には明確な1対1の対応関係がないからです。 投稿された当時の形式を保って過去ログ化すると、どの議論も、より尊重されるのではないでしょうか。

What about IP/anonymous editors?

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

Why didn't we use a pre-built system, like PHPBB or Discourse?

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?

LiquidThreads (LQT) was an early attempt at creating a structured discussion system. It had 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 Structured Discussions topics, which was used to convert all the LQT threads on MediaWiki.org into Structured Discussions. Details at Flow/Converting LiquidThreads.

How does Structured Discussions handle spam and vandalism?

メインのページ: Help:Structured Discussions/Administration

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)

Because Structured Discussions 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, Structured Discussions is integrated with the AbuseFilter and the global and local Spam Blacklist. See mw:Extension:Flow/Moderation for technical details.

Does Structured Discussions support wikitext or VisualEditor?

Both. Structured Discussions 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.

Because Structured Discussions stores content in HTML rather than Wikitext, Parsoid may rewrite wikitext when previewing or saving and re-editing. Those rewrites will usually be non-damaging.

Does Structured Discussions support all the templates and other markup we need in discussions?

Whatever markup Parsoid supports, Structured Discussions can support. Generally speaking, anything users commonly need to use (mathematical symbols, references, templates) can be added to a Structured Discussions 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?

Structured Discussions does 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 Structured Discussions boards could cause serious issues and errors in how the page is displayed.

Can I edit other people's posts?

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.

Instead or in parallel of Structured Discussions, will VisualEditor be enabled on talk pages?

No. This question comes up quite often.

• VisualEditor (VE) is designed to edit content, plain pages of text.
  • Talk pages aren't encyclopedic 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.
• Traditional talk page discussions often appear fairly well-structured through the use of section headers, indentation and the like. However, this kind of structure cannot be parsed by software to determine with certainty who has replied to whom.
  • In Structured Discussions, 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 Structured Discussions. Classical talk pages, using VE or not, do not currently have that feature, and adding it might prove cumbersome.

I can't use any page on Structured Discussions. Why?

It is probably a compatibility problem; see Structured Discussions/Known problems.

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

These URLs are an unique ID. Structured Discussions was designed to allow cross-pages and cross-wiki display which have a unique ID. It is not possible to have multiple topics titled ''Topic:Hello''. A way to change topic names was 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 Structured Discussions ?

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

I don't want Structured Discussions on my talk page. Is it possible to change it back to the old wikitext style?

It is. However, note that your existing talk page content will have to be moved to an archive, as the default wikitext model is incompatible with Structured Discussions.

On a wiki where Structured Discussions are deployed by default on user talk pages, you'll need an admin at your wiki to perform that change and follow the local rules about Structured Discussions on talk pages. For other Wikimedia wikis, contact an admin or post at your village pump or similar.

Procedure by admins:

1. Move the user's current talk page content to an archive page.
2. Go to Special:ChangeContentModel and enter the user talk page. Then select wikitext as the new content model. Type a reason and hit enter.

On a wiki where Structured Discussions are available as a Beta feature for talk pages, go to the Beta preferences and unselect the preference "会話ページでの構造化された議論".

Design FAQ

Why is there so much whitespace/padding?

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 dissatisfaction, 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. The text size used for Structured Discussions is 16pt at 25pt leading.

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 Structured Discussions 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 2013 redesign as an example.

See the following for more discussion and analysis of whitespace and font sizes on the web:

• Whitespace myth
• Best practices analysis

Why is there limited indenting/threading of comments?

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

Why are we using big colored buttons?

The buttons in Structured Discussions 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?

The aim is to make most of the core Structured Discussions 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 Structured Discussions is designed to behave, disabling JavaScript "for performance reasons" may actually create poorer performance than with JavaScript. For example, the plan is for Structured Discussions to 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?

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. Structured Discussions 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?

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.