Hi all,
I'm breaking out this discussion about Flow/talk pages (apologies for repeatedly breaking the megathread, but this is a well-scoped subject which deserves its own thread).
Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there (pun intended).
== Document mode ==
There are not many examples of document mode discussion systems beyond wikis. You sometimes see people use collaborative realtime editors as such, because people want to talk in the same space where they work, but Google Docs provided alternatives (a pretty powerful comments/margin system and built-in chat) early on, for example.
The current talk page system is a document mode system. Individual comments have unclear boundaries (a single transaction can result in multiple comments, signed or unsigned; indentation levels are unpredictable and often inconsistent). All the joys and pain points of working on the same document are present (a heavily trafficked talk page will see many edit conflicts). You can't easily show comments in multiple contexts (cross-wiki, via email, as a notification, etc.) because of the boundary problem.
You could try to make a document mode system work better. On the basis of wikitext, you can do some very basic things, like the "new section" link I added to MediaWiki back in July 2003 [1], when I wrote: "This feature could also be the first stage of a more sophisticated discussion system, where the next stage would be auto-appending signatures and providing a 'Reply to this' link after each comment."
But due to the aforementioned unpredictability, even making a "reply" link work consistently (and do the right thing) is non-trivial. You can get some of the way there, and the Wikipedia Teahouse actually has a gadget, written by Andrew Garrett (more on him below) that does precisely that.
https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
Note the "Join this discussion" link. It does give you a pop-up, and posts the comment for you in the right place, with indentation (it does not auto-sign, but instead tries to teach users the signature habit which they'll need to use on other talk pages).
It may be worth doing more research and development on this, to see just how far we can get without changing the fundamentals, since a wholly new system may still be years out for wide use. However, there are inherent limitations due to the lack of a predictable and consistent structure.
You could go further down the road of a document mode or hybrid system, but IMO not without introducing fully predictable comment markers (think <comment id="234234">Bla ~~~</comment>) -- which would pollute the wikitext, be fragile (e.g. accidental or deliberate corruption of identifiers), and probably be considered unacceptable in a system that still supports unlimited wikitext editing for those reasons.
== Structured ==
I personally gave up on patchwork on top of talk pages about 10 years ago. The advantages of having comments clearly identified as such are many:
- Display comments in arbitrary order, arbitrary threading style - Search comments across date ranges - Search comments by author - Track comments as comments, not as diffs - Monitor changes at any part of a comment thread - Display comments independent of a given document (e.g. email, cross-wiki, etc.) - Display comment metadata in different formats easily (e.g. timestamps) - Update author names after a username change without having to update documents - Enables third parties to build new UIs (think Wikiwand for comments) more easily - Ability to tag/categorize individual comments/threads - and more.
I identified some of these reasons when I wrote the proposal for LiquidThreads in October 2004 [2]. At that point, the Wikimedia Foundation had 0 employees, and this was too large an effort to likely get traction just from ad hoc volunteering. So after some time, I managed to persuade third parties to fund development, including Wikicities and WikiEducator, and found a developer to do the initial work, David McCabe. David did a good initial job but the system had many known issues and was only deployed at a small scale.
At the same time, I think there were many things about even the original design that were good (and aren't found in most other forum systems):
- It preserved "headers" on top of the threaded conversation as community-editable wiki-like spaces - It had a full history model for the thread itself, not just comments - It preserved comments essentially as individual wiki pages, with their own history - It had a built-in notion of thread summaries, collaboratively written, for closing comments
As WMF started to grow, it took on development of LiquidThreads -- with one developer, Andrew Garrett, who did an amazing job cleaning up the codebase and rethinking many of the assumptions David had made. LQT got to a point where some Wikimedia wikis actually requested for it to be enabled and traction started to build in favor of it. To this date, it is still found in some nooks and crannies in the Wikimedia universe.
translatewiki.net still uses it for its support page, and MediaWiki.org for its support desk, which are probably the highest profile uses left, and both get a fair bit of comment traffic.
Andrew did a ton of work on the project, but he himself recognized many architectural issues he wanted to address, and there are also UI assumptions we wanted to revisit. The project didn't have a team behind it at that time -- just one very talented part-time developer who was still at university! This was when WMF was barely growing to do development work, picking up some stuff (like LQT and FlaggedRevs) that had been simmering at a smaller scale before then.
In 2011, Brandon Harris, the first person at WMF ever to be tasked exclusively with design responsibilities, took a crack at some initial redesign drafts [5][6], which still contain many ideas worth looking at. But we pulled the plug at that time, because we recognized that we simply didn't have the personpower to put the resources behind the project to actually get it anywhere near completion -- and that a major architectural overhaul was required to do so.
A new effort was launched about a year ago, now resourcing a full team including design, development, product management, community support. (We're still pretty short staffed on UX research, QA, and data analyst support, but we make do.) As the team (including Andrew with his LQT experience under his belt) thought through the architectural needs of a modern discussion system, they decided that the LQT architecture was not salvageable. A migration script [7] is in development by Andrew himself.
The Flow architecture [8] differs in some important ways from LQT, including:
- Flow doesn't pretend that comments are "pages", instead using its own separate tables to manage them. This is architecturally important to give us more flexibility on how to store, version, query, search, and describe comments.
- Flow is built from the start to store comments in a central datastore, to make it easier to display comments and relevant notifications cross-wiki.
- Flow users Parsoid's HTML underneath, to prepare it for VisualEditor.
I don't think the architecture is perfect, but it should be a reasonable foundation to build on and iterate from.
The Flow UI, similarly, represents a first pass at this point. A lot of basic functionality is still missing. Things we know will make users happy (like cross-wiki features) are still ways out. It doesn't support VisualEditor yet, and yet its wikitext input suffers from any issues Parsoid does -- decisions made to future-proof the architecture have negative short term impact.
And like any brand-new UI, it could use lots of micro-optimization -- glitches here and there, which you may not even consciously notice, but which give you the feeling that you're using not-quite-ready software. Which you are.
At the same time, we know from user studies that talk pages are incredibly hard for new users to figure out. The semantics are just extremely different from anything else on the web. So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them. This parallels the long adoption of LQT for support desk type forums.
In this context, we also want to do some systematic measurement: How does such a system affect the # of comments posted, and the quality of the discussion?
We expect that we'd need to focus in on this use case in production for quite some time to get it right and really get people to fall in love with the system as it improves. At the same time, there may be other use cases that are less contentious and could serve as additional trials -- like talk pages in Wikidata.
We're not pushing an aggressive schedule on Flow -- we understand it needs to happen at the pace of the communities, since you can't build an "opt-out" for this kind of system (unlike VisualEditor). So the schedule is going to have to give as needed.
And as above, I'm open to us putting some short term effort into talk page improvements that can be made without Flow -- knowing it's still some time out. But based on the above long term functional and architectural considerations, I think a system that treats comments/threads as structured information, rather than as documents, is ultimately necessary, so I'd argue against procrastinating. It's going to be hard enough as it is to get this done without putting it on the backburner once more.
Finally, any comment that is about specific Flow UI aspects should be treated with a massive block of salt. The UI will evolve dramatically as we learn what works for new and experienced users alike.
Sincerely, Erik
[1] https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html [2] https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760 [3] https://translatewiki.net/wiki/Support [4] https://www.mediawiki.org/wiki/Project:Support_desk [5] https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design [7] https://gerrit.wikimedia.org/r/#/c/119243/ [8] https://www.mediawiki.org/wiki/Flow/Architecture
On Fri, Sep 5, 2014 at 9:49 PM, Erik Moeller erik@wikimedia.org wrote:
Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there <snip>
I think there's actually a much more fundamental question:
Who is "we"?
-Pete [[User:Peteforsyth]]
Hoi, "We" includes anyone who wants to be involved and does not exclude him or herself by his or her own actions or choices. Thanks, GerardM
On 6 September 2014 07:09, Pete Forsyth peteforsyth@gmail.com wrote:
On Fri, Sep 5, 2014 at 9:49 PM, Erik Moeller erik@wikimedia.org wrote:
Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there <snip>
I think there's actually a much more fundamental question:
Who is "we"?
-Pete [[User:Peteforsyth]] _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 6 September 2014 07:11, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, "We" includes anyone who wants to be involved and does not exclude him or herself by his or her own actions or choices. Thanks, GerardM
Incorrect.
Erik's email includes phrases like "We're not pushing an aggressive schedule on Flow". This clearly means that "we" refers to the Wikimedia Foundation and excludes unpaid volunteers who hold no responsibility or authority for the deployment schedule.
Fae
On Sat, Sep 6, 2014 at 9:50 AM, Fæ faewik@gmail.com wrote:
On 6 September 2014 07:11, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, "We" includes anyone who wants to be involved and does not exclude him or herself by his or her own actions or choices. Thanks, GerardM
Incorrect.
Erik's email includes phrases like "We're not pushing an aggressive schedule on Flow". This clearly means that "we" refers to the Wikimedia Foundation and excludes unpaid volunteers who hold no responsibility or authority for the deployment schedule.
Incorrect.
In such a long text, "we" can obviously refer to both "the Foundation" and "the community" (both of which Erik is a member of), depending on context. There would be little point in Erik asking "Do we want discussions to occur in document mode, or in a structured comment mode?" on a public mailing list, when he just wants to ask a Foundation-internal question, right? Pretty obvious, really, unless your goal is to distract from the actual topic.
Refer to the signature Erik used. The rationale that employees when acting as employees somehow are to be wearing a hat of an unpaid volunteer was worn out when superprotect was invented. On 6 Sep 2014 14:22, "Magnus Manske" magnusmanske@googlemail.com wrote:
On Sat, Sep 6, 2014 at 9:50 AM, Fæ faewik@gmail.com wrote:
On 6 September 2014 07:11, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, "We" includes anyone who wants to be involved and does not exclude him
or
herself by his or her own actions or choices. Thanks, GerardM
Incorrect.
Erik's email includes phrases like "We're not pushing an aggressive schedule on Flow". This clearly means that "we" refers to the Wikimedia Foundation and excludes unpaid volunteers who hold no responsibility or authority for the deployment schedule.
Incorrect.
In such a long text, "we" can obviously refer to both "the Foundation" and "the community" (both of which Erik is a member of), depending on context. There would be little point in Erik asking "Do we want discussions to occur in document mode, or in a structured comment mode?" on a public mailing list, when he just wants to ask a Foundation-internal question, right? Pretty obvious, really, unless your goal is to distract from the actual topic. _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hi Erik,
While I have a lot of reservations about the usefulness of the Media Viewer, I agree with you that talk pages are now inefficient for all and complex for new users. Personally I am willing to try any system which offers the features missing in the current talk pages, specially removing the need for manual signatures.
Regards,
Yann
2014-09-06 10:19 GMT+05:30 Erik Moeller erik@wikimedia.org:
Hi all,
I'm breaking out this discussion about Flow/talk pages (apologies for repeatedly breaking the megathread, but this is a well-scoped subject which deserves its own thread).
Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there (pun intended).
== Document mode ==
There are not many examples of document mode discussion systems beyond wikis. You sometimes see people use collaborative realtime editors as such, because people want to talk in the same space where they work, but Google Docs provided alternatives (a pretty powerful comments/margin system and built-in chat) early on, for example.
The current talk page system is a document mode system. Individual comments have unclear boundaries (a single transaction can result in multiple comments, signed or unsigned; indentation levels are unpredictable and often inconsistent). All the joys and pain points of working on the same document are present (a heavily trafficked talk page will see many edit conflicts). You can't easily show comments in multiple contexts (cross-wiki, via email, as a notification, etc.) because of the boundary problem.
You could try to make a document mode system work better. On the basis of wikitext, you can do some very basic things, like the "new section" link I added to MediaWiki back in July 2003 [1], when I wrote: "This feature could also be the first stage of a more sophisticated discussion system, where the next stage would be auto-appending signatures and providing a 'Reply to this' link after each comment."
But due to the aforementioned unpredictability, even making a "reply" link work consistently (and do the right thing) is non-trivial. You can get some of the way there, and the Wikipedia Teahouse actually has a gadget, written by Andrew Garrett (more on him below) that does precisely that.
https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
Note the "Join this discussion" link. It does give you a pop-up, and posts the comment for you in the right place, with indentation (it does not auto-sign, but instead tries to teach users the signature habit which they'll need to use on other talk pages).
It may be worth doing more research and development on this, to see just how far we can get without changing the fundamentals, since a wholly new system may still be years out for wide use. However, there are inherent limitations due to the lack of a predictable and consistent structure.
You could go further down the road of a document mode or hybrid system, but IMO not without introducing fully predictable comment markers (think <comment id="234234">Bla ~~~</comment>) -- which would pollute the wikitext, be fragile (e.g. accidental or deliberate corruption of identifiers), and probably be considered unacceptable in a system that still supports unlimited wikitext editing for those reasons.
== Structured ==
I personally gave up on patchwork on top of talk pages about 10 years ago. The advantages of having comments clearly identified as such are many:
- Display comments in arbitrary order, arbitrary threading style
- Search comments across date ranges
- Search comments by author
- Track comments as comments, not as diffs
- Monitor changes at any part of a comment thread
- Display comments independent of a given document (e.g. email,
cross-wiki, etc.)
- Display comment metadata in different formats easily (e.g. timestamps)
- Update author names after a username change without having to update documents
- Enables third parties to build new UIs (think Wikiwand for comments)
more easily
- Ability to tag/categorize individual comments/threads
- and more.
I identified some of these reasons when I wrote the proposal for LiquidThreads in October 2004 [2]. At that point, the Wikimedia Foundation had 0 employees, and this was too large an effort to likely get traction just from ad hoc volunteering. So after some time, I managed to persuade third parties to fund development, including Wikicities and WikiEducator, and found a developer to do the initial work, David McCabe. David did a good initial job but the system had many known issues and was only deployed at a small scale.
At the same time, I think there were many things about even the original design that were good (and aren't found in most other forum systems):
- It preserved "headers" on top of the threaded conversation as
community-editable wiki-like spaces
- It had a full history model for the thread itself, not just comments
- It preserved comments essentially as individual wiki pages, with
their own history
- It had a built-in notion of thread summaries, collaboratively
written, for closing comments
As WMF started to grow, it took on development of LiquidThreads -- with one developer, Andrew Garrett, who did an amazing job cleaning up the codebase and rethinking many of the assumptions David had made. LQT got to a point where some Wikimedia wikis actually requested for it to be enabled and traction started to build in favor of it. To this date, it is still found in some nooks and crannies in the Wikimedia universe.
translatewiki.net still uses it for its support page, and MediaWiki.org for its support desk, which are probably the highest profile uses left, and both get a fair bit of comment traffic.
Andrew did a ton of work on the project, but he himself recognized many architectural issues he wanted to address, and there are also UI assumptions we wanted to revisit. The project didn't have a team behind it at that time -- just one very talented part-time developer who was still at university! This was when WMF was barely growing to do development work, picking up some stuff (like LQT and FlaggedRevs) that had been simmering at a smaller scale before then.
In 2011, Brandon Harris, the first person at WMF ever to be tasked exclusively with design responsibilities, took a crack at some initial redesign drafts [5][6], which still contain many ideas worth looking at. But we pulled the plug at that time, because we recognized that we simply didn't have the personpower to put the resources behind the project to actually get it anywhere near completion -- and that a major architectural overhaul was required to do so.
A new effort was launched about a year ago, now resourcing a full team including design, development, product management, community support. (We're still pretty short staffed on UX research, QA, and data analyst support, but we make do.) As the team (including Andrew with his LQT experience under his belt) thought through the architectural needs of a modern discussion system, they decided that the LQT architecture was not salvageable. A migration script [7] is in development by Andrew himself.
The Flow architecture [8] differs in some important ways from LQT, including:
- Flow doesn't pretend that comments are "pages", instead using its
own separate tables to manage them. This is architecturally important to give us more flexibility on how to store, version, query, search, and describe comments.
- Flow is built from the start to store comments in a central
datastore, to make it easier to display comments and relevant notifications cross-wiki.
- Flow users Parsoid's HTML underneath, to prepare it for VisualEditor.
I don't think the architecture is perfect, but it should be a reasonable foundation to build on and iterate from.
The Flow UI, similarly, represents a first pass at this point. A lot of basic functionality is still missing. Things we know will make users happy (like cross-wiki features) are still ways out. It doesn't support VisualEditor yet, and yet its wikitext input suffers from any issues Parsoid does -- decisions made to future-proof the architecture have negative short term impact.
And like any brand-new UI, it could use lots of micro-optimization -- glitches here and there, which you may not even consciously notice, but which give you the feeling that you're using not-quite-ready software. Which you are.
At the same time, we know from user studies that talk pages are incredibly hard for new users to figure out. The semantics are just extremely different from anything else on the web. So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them. This parallels the long adoption of LQT for support desk type forums.
In this context, we also want to do some systematic measurement: How does such a system affect the # of comments posted, and the quality of the discussion?
We expect that we'd need to focus in on this use case in production for quite some time to get it right and really get people to fall in love with the system as it improves. At the same time, there may be other use cases that are less contentious and could serve as additional trials -- like talk pages in Wikidata.
We're not pushing an aggressive schedule on Flow -- we understand it needs to happen at the pace of the communities, since you can't build an "opt-out" for this kind of system (unlike VisualEditor). So the schedule is going to have to give as needed.
And as above, I'm open to us putting some short term effort into talk page improvements that can be made without Flow -- knowing it's still some time out. But based on the above long term functional and architectural considerations, I think a system that treats comments/threads as structured information, rather than as documents, is ultimately necessary, so I'd argue against procrastinating. It's going to be hard enough as it is to get this done without putting it on the backburner once more.
Finally, any comment that is about specific Flow UI aspects should be treated with a massive block of salt. The UI will evolve dramatically as we learn what works for new and experienced users alike.
Sincerely, Erik
[1] https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html [2] https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760 [3] https://translatewiki.net/wiki/Support [4] https://www.mediawiki.org/wiki/Project:Support_desk [5] https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design [7] https://gerrit.wikimedia.org/r/#/c/119243/ [8] https://www.mediawiki.org/wiki/Flow/Architecture -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Saturday, September 6, 2014, Erik Moeller erik@wikimedia.org wrote:
So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them.
What about setting up some kind of Flow self-service for projects? Let play to those wiling to play, in the way they think it's best for their projects.
Potential requirements to join the Flow self-service:
* At least one tech ambassador volunteering to act as contact between the project and the Flow team, summarizing community feedback in the channels agreed (mw:Talk:Flow, etc). * Community agreement after a public discussion in the project. * Selection of a first page to try Flow.
When the requirements are met, Flow is enabled in that project and activated in that page. A month of trial follows, and after that the community must evaluate whether it is worth activating Flow in more pages or wait. Maybe at some point the admins of the project can control in which pages Flow is deployed?
While we (Wikimedia movement) dedicate so much time to negotiate incremental deployments of Flow in some sensitive and tough arenas, maybe there are huge regions in our communities where editors would welcome a test of this feature. The feedback of these early adopters would help fine-tuning Flow and to better define the development priorities, since longer term use of regular editors provides a more complete perspective than power users in mediawiki.org alone.
Hi,
That seems a sensible plan. I am thinking of the help desk on Commons (in English or in another language) as a good testbed.
Regards,
Yann
2014-09-06 17:09 GMT+05:30 Quim Gil qgil@wikimedia.org:
On Saturday, September 6, 2014, Erik Moeller erik@wikimedia.org wrote:
So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them.
What about setting up some kind of Flow self-service for projects? Let play to those wiling to play, in the way they think it's best for their projects.
Potential requirements to join the Flow self-service:
- At least one tech ambassador volunteering to act as contact between the
project and the Flow team, summarizing community feedback in the channels agreed (mw:Talk:Flow, etc).
- Community agreement after a public discussion in the project.
- Selection of a first page to try Flow.
When the requirements are met, Flow is enabled in that project and activated in that page. A month of trial follows, and after that the community must evaluate whether it is worth activating Flow in more pages or wait. Maybe at some point the admins of the project can control in which pages Flow is deployed?
While we (Wikimedia movement) dedicate so much time to negotiate incremental deployments of Flow in some sensitive and tough arenas, maybe there are huge regions in our communities where editors would welcome a test of this feature. The feedback of these early adopters would help fine-tuning Flow and to better define the development priorities, since longer term use of regular editors provides a more complete perspective than power users in mediawiki.org alone.
-- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 06.09.2014 13:39, Quim Gil wrote:
On Saturday, September 6, 2014, Erik Moeller erik@wikimedia.org wrote:
So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them.
What about setting up some kind of Flow self-service for projects? Let play to those wiling to play, in the way they think it's best for their projects.
Potential requirements to join the Flow self-service:
- At least one tech ambassador volunteering to act as contact between
the project and the Flow team, summarizing community feedback in the channels agreed (mw:Talk:Flow, etc).
- Community agreement after a public discussion in the project.
- Selection of a first page to try Flow.
Hi Quim,
actually, this is exactly what is happening now and this is what caused this turmoil yesterday night.
FLOW was once deployed on two en.wp WikiProjects in the past, Wikiroject:Breakfast and another one, i do not remember which on off the top of my head. The Wikiproject participants agreed to use their talk pages as a testbed, and it was announced reasonably broadly. Volunteers, including me, tried installed FLOW and discovered that it is substandard and can not be used for any reasonable discussion. The test was terminated, some feedback was generated, some of it was taken onboard, the rest presumably not.
Yesterday, we discovered that FLOW was installed as a test in the Teahouse, a place whose purpose is to welcome newbies. I am not using the Teahouse, but the argument which I have heard was that FLOW was installed on a page inaccessible from the main Teahouse page and thus unlikely to be visited by newbies. Apparently, there was some discussion in the Teahouse, and the consensus was that FOW should not be installed. Since FLOW was installed clearly against the community will and since it is clearly still substandard, we had to act somehow. Danny got a warning at his talkage, the FLOW page was protected, and I had to send a message here, which in the end of the day started this discussion.
This is not the way FLOW should be deployed.
To me, Wikidata deployment was an example of successful Wikimedia project deployment which went relatively easily (even though there are still users having a strong opinion against Wkidata). The reasons it went so smoothly were that (i) it was clear what the end goal is, what should happen at what stage, and what are the needed steps; (ii) there were a large amount of volunteers and ambassadors from the first day sharing the idea and helping to explain it and to fix the bugs; (iii) Support was always and easily available, including Danny and Lydia, and they were really willing to listen to us and to help us, not to impose their vision.
I am afraid with Flow we are still not even at (i). Whereas after Erik's message I understand what he wants in very general terms, the implementation is completely open. In these terms, Facebook or PHP are both FLOW. I guess we start from the concept, and the next step would be for volunteers to instal Flow a their talk pages. If they can survive for a couple of months, we can talk about it further.
Cheers Yaroslav
(The self-service suggestion and the opinions below are mine, posted here with the best of my community intentions.)
Hi Yaroslav,
On Saturday, September 6, 2014, Yaroslav M. Blanter <putevod@mccme.ru javascript:_e(%7B%7D,'cvml','putevod@mccme.ru');> wrote:
actually, this is exactly what is happening now and this is what caused this turmoil yesterday night.
The situation you describe and the hypothetical self-service process I suggested are different.
I guess we start from the concept, and the next step would be for
volunteers to instal Flow a their talk pages. If they can survive for a couple of months, we can talk about it further.
Discussing concepts is better done while trying prototypes, alphas, betas (and we have been doing this for Flow for about a year now). For instance, I believe mw:Winter is progressing in the way it is progressing thanks to a good balance between conceptual discussions, prototyping iterations, and actual testing. Flow itself is progressing well thanks to the limited deployments in some real pages.
Allowing users to activate Flow in their Talk pages would fit in the self-service idea. If the development team decides to open this possibility, I will not hesitate in joining the trial.
On 6 September 2014 05:49, Erik Moeller erik@wikimedia.org wrote:
Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode?
I rather think the more fundamental question is (for any software solution) "does this tool enable us to build the encyclopedia, better than its predecessor?".
- Update author names after a username change without having to update documents
So if I say in a discussion in which you participated, much earlier, "I agree with what Eloqeunce said", and you subsequently change your user name to ErikM, my comment would be made nonsensical?
On Sat, Sep 6, 2014 at 6:49 AM, Erik Moeller erik@wikimedia.org wrote:
Hi all,
<snip>
Sincerely, Erik
[1] https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html [2] https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760 [3] https://translatewiki.net/wiki/Support [4] https://www.mediawiki.org/wiki/Project:Support_desk [5] https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design [7] https://gerrit.wikimedia.org/r/#/c/119243/ [8] https://www.mediawiki.org/wiki/Flow/Architecture -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
This email almost exactly embodies what I mean when I say that we are told not to worry, everything will be OK in the earlier stages of development, when in the later stages near deployment we're being told that the feature has been under development for months or even years, and only *now* we come with all these demands.
-- Martijn
Erik,
I think a lot of reasons for the "document mode" commenting system got missed. But there are very good reasons we must retain that.
One huge thing is that article talk pages are not only for discussions, but also for metadata (article assessments, history, Wikiproject data, as examples from the English Wikipedia). The top of the talk page also, on many pages, serves notices and FAQs to new visitors to the talk page.
For reviews like that, it may be necessary to have wikitext act as wikitext, another very significant concern. ("Your use of Template:Example is what's causing the text formatting to break in that section, because it does like this: (insert example). You should actually use {{example|arg1|arg2}}.") In other cases, subpages or other pages need to be transcluded in, and all the functions of the transcluded page must be preserved. Discussion pages aren't -only- used for discussion.
I think there's a serious flaw in thinking with the current development processes, that Wikipedia needs to be more like Facebook, or Instagram, or Twitter to attract new users. Jan-Bart has even mentioned Quora at several points. Quora is cool. I love Quora. But that's not Wikipedia, and it's not what Wikipedia should aspire to. They're not a competitor. (For that matter, there -are- no competitors, we give our "product" away for free, not only to read but to repackage and reuse!)
Making the interface easier to use is fine, but never at the expense of quality or flexibility. The second is the real sticking point here. We need maximum flexibility to handle complex discussions and complex problems. We may need some stuff at the top of the page, not left in "infinite scroll" hell. (Infinite scroll has to be one of the worst, user-unfriendliest UI ideas I've ever seen.) We need the ability to rapidly archive "forum" style posts or stuff that's become unproductive, and we need -any- editor able to do that, not just admins. Non-admin editors help out all the time in that regard. We need the ability to have real archives; again, infinite scroll with or without search is nowhere near a replacement for that. We need the ability to easily wikilink to specific sections.
Adding some "rails" is fine, but never at the expense of the underlying functionality. VE, once it works, is the model to look at there: It supplements, not supplants, the existing functions. That will be a huge step in the right direction, the problem there was not design but execution. Once it works properly, that issue goes away.
With Flow, the issue is flawed design. Supplanting current talk page functionality will not work. We need the flexibility of subpages and freely editable documents. The only other option there would be to use article-space subpages for that, and that would be messy and horribly inefficient.
Facebook, Twitter, forums, etc., don't need that, but it cannot be emphasized enough that we ***are not, and should not aspire to be or look like, a social media site***. We handle complexity that sites designed around "LOL OMGZ LOLCAT PIX!" do not need to handle.
The resistance you're seeing here is you're trying to take things right out of someone's hand, while they shout "Hey, I was USING that, and this thing you're trying to hand me won't do the same thing!". No amount of tweaks to Flow will change that, unless you can somehow layer it onto existing talk pages rather than replacing them. But any workable solution must retain that backwards compatibility, as VE will.
Maybe Flow could see limited use in a few newbie help areas to aid them in making the transition from reader to editor, but serious editors will by and large not want it sitewide. Ease-of-use helpers will be much more easily accepted, provided they're actually ready for wide scale use when rolled out as site defaults and have easy opt outs. Why not, at the very least, try the less radical change first and see how it works?
Todd
On Fri, Sep 5, 2014 at 10:49 PM, Erik Moeller erik@wikimedia.org wrote:
Hi all,
I'm breaking out this discussion about Flow/talk pages (apologies for repeatedly breaking the megathread, but this is a well-scoped subject which deserves its own thread).
Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there (pun intended).
== Document mode ==
There are not many examples of document mode discussion systems beyond wikis. You sometimes see people use collaborative realtime editors as such, because people want to talk in the same space where they work, but Google Docs provided alternatives (a pretty powerful comments/margin system and built-in chat) early on, for example.
The current talk page system is a document mode system. Individual comments have unclear boundaries (a single transaction can result in multiple comments, signed or unsigned; indentation levels are unpredictable and often inconsistent). All the joys and pain points of working on the same document are present (a heavily trafficked talk page will see many edit conflicts). You can't easily show comments in multiple contexts (cross-wiki, via email, as a notification, etc.) because of the boundary problem.
You could try to make a document mode system work better. On the basis of wikitext, you can do some very basic things, like the "new section" link I added to MediaWiki back in July 2003 [1], when I wrote: "This feature could also be the first stage of a more sophisticated discussion system, where the next stage would be auto-appending signatures and providing a 'Reply to this' link after each comment."
But due to the aforementioned unpredictability, even making a "reply" link work consistently (and do the right thing) is non-trivial. You can get some of the way there, and the Wikipedia Teahouse actually has a gadget, written by Andrew Garrett (more on him below) that does precisely that.
https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
Note the "Join this discussion" link. It does give you a pop-up, and posts the comment for you in the right place, with indentation (it does not auto-sign, but instead tries to teach users the signature habit which they'll need to use on other talk pages).
It may be worth doing more research and development on this, to see just how far we can get without changing the fundamentals, since a wholly new system may still be years out for wide use. However, there are inherent limitations due to the lack of a predictable and consistent structure.
You could go further down the road of a document mode or hybrid system, but IMO not without introducing fully predictable comment markers (think <comment id="234234">Bla ~~~</comment>) -- which would pollute the wikitext, be fragile (e.g. accidental or deliberate corruption of identifiers), and probably be considered unacceptable in a system that still supports unlimited wikitext editing for those reasons.
== Structured ==
I personally gave up on patchwork on top of talk pages about 10 years ago. The advantages of having comments clearly identified as such are many:
- Display comments in arbitrary order, arbitrary threading style
- Search comments across date ranges
- Search comments by author
- Track comments as comments, not as diffs
- Monitor changes at any part of a comment thread
- Display comments independent of a given document (e.g. email,
cross-wiki, etc.)
- Display comment metadata in different formats easily (e.g. timestamps)
- Update author names after a username change without having to update
documents
- Enables third parties to build new UIs (think Wikiwand for comments)
more easily
- Ability to tag/categorize individual comments/threads
- and more.
I identified some of these reasons when I wrote the proposal for LiquidThreads in October 2004 [2]. At that point, the Wikimedia Foundation had 0 employees, and this was too large an effort to likely get traction just from ad hoc volunteering. So after some time, I managed to persuade third parties to fund development, including Wikicities and WikiEducator, and found a developer to do the initial work, David McCabe. David did a good initial job but the system had many known issues and was only deployed at a small scale.
At the same time, I think there were many things about even the original design that were good (and aren't found in most other forum systems):
- It preserved "headers" on top of the threaded conversation as
community-editable wiki-like spaces
- It had a full history model for the thread itself, not just comments
- It preserved comments essentially as individual wiki pages, with
their own history
- It had a built-in notion of thread summaries, collaboratively
written, for closing comments
As WMF started to grow, it took on development of LiquidThreads -- with one developer, Andrew Garrett, who did an amazing job cleaning up the codebase and rethinking many of the assumptions David had made. LQT got to a point where some Wikimedia wikis actually requested for it to be enabled and traction started to build in favor of it. To this date, it is still found in some nooks and crannies in the Wikimedia universe.
translatewiki.net still uses it for its support page, and MediaWiki.org for its support desk, which are probably the highest profile uses left, and both get a fair bit of comment traffic.
Andrew did a ton of work on the project, but he himself recognized many architectural issues he wanted to address, and there are also UI assumptions we wanted to revisit. The project didn't have a team behind it at that time -- just one very talented part-time developer who was still at university! This was when WMF was barely growing to do development work, picking up some stuff (like LQT and FlaggedRevs) that had been simmering at a smaller scale before then.
In 2011, Brandon Harris, the first person at WMF ever to be tasked exclusively with design responsibilities, took a crack at some initial redesign drafts [5][6], which still contain many ideas worth looking at. But we pulled the plug at that time, because we recognized that we simply didn't have the personpower to put the resources behind the project to actually get it anywhere near completion -- and that a major architectural overhaul was required to do so.
A new effort was launched about a year ago, now resourcing a full team including design, development, product management, community support. (We're still pretty short staffed on UX research, QA, and data analyst support, but we make do.) As the team (including Andrew with his LQT experience under his belt) thought through the architectural needs of a modern discussion system, they decided that the LQT architecture was not salvageable. A migration script [7] is in development by Andrew himself.
The Flow architecture [8] differs in some important ways from LQT, including:
- Flow doesn't pretend that comments are "pages", instead using its
own separate tables to manage them. This is architecturally important to give us more flexibility on how to store, version, query, search, and describe comments.
- Flow is built from the start to store comments in a central
datastore, to make it easier to display comments and relevant notifications cross-wiki.
- Flow users Parsoid's HTML underneath, to prepare it for VisualEditor.
I don't think the architecture is perfect, but it should be a reasonable foundation to build on and iterate from.
The Flow UI, similarly, represents a first pass at this point. A lot of basic functionality is still missing. Things we know will make users happy (like cross-wiki features) are still ways out. It doesn't support VisualEditor yet, and yet its wikitext input suffers from any issues Parsoid does -- decisions made to future-proof the architecture have negative short term impact.
And like any brand-new UI, it could use lots of micro-optimization -- glitches here and there, which you may not even consciously notice, but which give you the feeling that you're using not-quite-ready software. Which you are.
At the same time, we know from user studies that talk pages are incredibly hard for new users to figure out. The semantics are just extremely different from anything else on the web. So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them. This parallels the long adoption of LQT for support desk type forums.
In this context, we also want to do some systematic measurement: How does such a system affect the # of comments posted, and the quality of the discussion?
We expect that we'd need to focus in on this use case in production for quite some time to get it right and really get people to fall in love with the system as it improves. At the same time, there may be other use cases that are less contentious and could serve as additional trials -- like talk pages in Wikidata.
We're not pushing an aggressive schedule on Flow -- we understand it needs to happen at the pace of the communities, since you can't build an "opt-out" for this kind of system (unlike VisualEditor). So the schedule is going to have to give as needed.
And as above, I'm open to us putting some short term effort into talk page improvements that can be made without Flow -- knowing it's still some time out. But based on the above long term functional and architectural considerations, I think a system that treats comments/threads as structured information, rather than as documents, is ultimately necessary, so I'd argue against procrastinating. It's going to be hard enough as it is to get this done without putting it on the backburner once more.
Finally, any comment that is about specific Flow UI aspects should be treated with a massive block of salt. The UI will evolve dramatically as we learn what works for new and experienced users alike.
Sincerely, Erik
[1] https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html [2] https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760 [3] https://translatewiki.net/wiki/Support [4] https://www.mediawiki.org/wiki/Project:Support_desk [5] https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design [7] https://gerrit.wikimedia.org/r/#/c/119243/ [8] https://www.mediawiki.org/wiki/Flow/Architecture -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Sat, Sep 6, 2014 at 8:03 AM, Todd Allen toddmallen@gmail.com wrote:
Erik, One huge thing is that article talk pages are not only for discussions, but also for metadata (article assessments, history, Wikiproject data, as examples from the English Wikipedia). The top of the talk page also, on many pages, serves notices and FAQs to new visitors to the talk page.
Yes, this is supported in Flow through wiki-editable headers. These are community-editable like a wiki page. LQT simply used the existing talk page for this purpose and hooked into its history and permissioning, while Flow manages them separately, and its history features are still very rudimentary for that reason.
For reviews like that, it may be necessary to have wikitext act as wikitext, another very significant concern. ("Your use of Template:Example is what's causing the text formatting to break in that section, because it does like this: (insert example). You should actually use {{example|arg1|arg2}}.")
There's nothing in Flow's design that makes this impossible. There are some inconsistencies to work through due to the use of Parsoid's HTML for comment storage, and some extensions that may just be fundamentally incompatible with a comment-based approach in their current form (e.g. page-level translation, etc).
We need the ability to rapidly archive "forum" style posts or stuff that's become unproductive, and we need -any- editor able to do that, not just admins.
Flow has a few features relevant to this right now, all still experimental:
- You can hide a topic from view (collapses it, others can undo) - You can summarize or "close" a topic (others can reopen, both actions update the summary, close also collapses) - You can edit a topic's title - You can hide an individual comment (collapses it, others can undo)
In the current permission system (which is easy to change) the only thing that is lightly restricted is editing other people's comments.
The underlying reasoning here is to try to support patterns that exist in our community, while discouraging problematic changes. Comments that solely consist of personal attacks can still be collapsed by anyone, editing is discouraged except in special circumstances (and hence restricted to admins); users don't have to monitor their own comments for inappropriate edits.
Whether that's correct or not, I personally don't have a strong opinion on. In LQT, we left comments openly editable, and I never observed a problem with it; I think the arguments on both sides of this issue are a bit out of proportion.
Back in 2004 I tried a little experiment by creating https://en.wikipedia.org/wiki/User:Eloquence/Comment_policy and adding it to my signature, to see if a subtle indicator would have more people actually do anything interesting with my comments. It never did. A year before I also tried to introduce a policy called "Remove personal attacks" on en.wp: https://en.wikipedia.org/w/index.php?title=Wikipedia:Remove_personal_attacks...
This was hotly debated, and when/where to edit other people's comments is actually still somewhat ambiguous in policies across wikis. English Wikipedia acknowledges: "There is no official policy regarding when or whether most personal attacks should be removed, although it has been a topic of substantial debate. "
Just yesterday, as I was talking with Fram on Danny's talk page about his .. slight escalation, another user popped in striking out Fram's comments, then another user reverted that, ... so, there's a fair bit of potential for conflict in this, which we do see a little bit of every day.
German Wikipedia more explicitly encourages anyone to remove attacks except people who are the subject of them, but cautions that users who are subject of personal attacks should be careful, because it can exacerbate a conflict. It then proceeds to explain that administrators are encouraged to completely delete personal attacks using revision deletion. https://de.wikipedia.org/wiki/Wikipedia:Keine_pers%C3%B6nlichen_Angriffe
I think the strongest argument to keep comments openly editable, at least initially, is that it's most consistent with policies as currently written (most policies I've seen generally discourage editing other people's comments, but have a few exceptions like the one above). If, after much debate, communities want to adopt different policies, then Flow's permissioning could be changed to reflect them. Keeping the "Hide" type functionality in place for now would be a good way to play with alternatives without immediately limiting options.
We need the ability to have real archives; again, infinite scroll with or without search is nowhere near a replacement for that.
100% agreed. But with actual metadata for comments that's structured and searchable, you can build much better search features -- search by author, by date range, or even categorize/tag individual threads. Archives in a well-built discussion system can be much more useful than the current system of copying text around.
We need the ability to easily wikilink to specific sections.
Again, none of that is limited by the architecture. Right now you can - - wikilink to a Flow board ([[Talk:Flow]]) - wikilink to a topic on a board ([[Topic:Some id|Some title]]) - URL-link to a specific version of that topic
The history features are pretty rudimentary right now, as noted above; that's mostly because the project (as noted in the original message) decided to get rid of LQT's tie-in into the page architecture of MediaWiki. That's an expensive decision, because by treating comments as pages, you get a lot of stuff for free -- but it's motivated by a desire to build UIs and an overall storage and retrieval architecture that really make sense for a discussion system, rather than a document mode system. So give them time to build out the scaffolding.
With Flow, the issue is flawed design. Supplanting current talk page functionality will not work. We need the flexibility of subpages and freely editable documents.
These are just assertions, however. I liked your earlier comments because they are testable against the architecture (even if the current implementation, early as it is, will fail many of these tests). What real world needs cannot be met by a comment-centric architecture for .. commenting? How important are they?
Erik
Hi,
Is there a page somewhere where I can see a detailed functional specification of this product, showing how it'll work, what functions/features it will include in it's MVP state, and such? I know about the page on Mediawiki ( https://www.mediawiki.org/wiki/Flow ) that talks about things in generalities and answers some specific questions in the FAQ, but I've not been able to locate any document that tells me exactly what it will *do*.
I have to confess that I'm not entirely confident that the rollout of Flow will be any smoother than the rollout of Visual Editor or MediaViewer, largely because I'm not entirely confident of what it is that I'm supposed to be getting. I'd be delighted to be corrected on this point if there is something out there that I've missed.
Cheers, Craig
On 6 September 2014 14:49, Erik Moeller erik@wikimedia.org wrote:
Hi all,
I'm breaking out this discussion about Flow/talk pages (apologies for repeatedly breaking the megathread, but this is a well-scoped subject which deserves its own thread).
Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there (pun intended).
== Document mode ==
There are not many examples of document mode discussion systems beyond wikis. You sometimes see people use collaborative realtime editors as such, because people want to talk in the same space where they work, but Google Docs provided alternatives (a pretty powerful comments/margin system and built-in chat) early on, for example.
The current talk page system is a document mode system. Individual comments have unclear boundaries (a single transaction can result in multiple comments, signed or unsigned; indentation levels are unpredictable and often inconsistent). All the joys and pain points of working on the same document are present (a heavily trafficked talk page will see many edit conflicts). You can't easily show comments in multiple contexts (cross-wiki, via email, as a notification, etc.) because of the boundary problem.
You could try to make a document mode system work better. On the basis of wikitext, you can do some very basic things, like the "new section" link I added to MediaWiki back in July 2003 [1], when I wrote: "This feature could also be the first stage of a more sophisticated discussion system, where the next stage would be auto-appending signatures and providing a 'Reply to this' link after each comment."
But due to the aforementioned unpredictability, even making a "reply" link work consistently (and do the right thing) is non-trivial. You can get some of the way there, and the Wikipedia Teahouse actually has a gadget, written by Andrew Garrett (more on him below) that does precisely that.
https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
Note the "Join this discussion" link. It does give you a pop-up, and posts the comment for you in the right place, with indentation (it does not auto-sign, but instead tries to teach users the signature habit which they'll need to use on other talk pages).
It may be worth doing more research and development on this, to see just how far we can get without changing the fundamentals, since a wholly new system may still be years out for wide use. However, there are inherent limitations due to the lack of a predictable and consistent structure.
You could go further down the road of a document mode or hybrid system, but IMO not without introducing fully predictable comment markers (think <comment id="234234">Bla ~~~</comment>) -- which would pollute the wikitext, be fragile (e.g. accidental or deliberate corruption of identifiers), and probably be considered unacceptable in a system that still supports unlimited wikitext editing for those reasons.
== Structured ==
I personally gave up on patchwork on top of talk pages about 10 years ago. The advantages of having comments clearly identified as such are many:
- Display comments in arbitrary order, arbitrary threading style
- Search comments across date ranges
- Search comments by author
- Track comments as comments, not as diffs
- Monitor changes at any part of a comment thread
- Display comments independent of a given document (e.g. email,
cross-wiki, etc.)
- Display comment metadata in different formats easily (e.g. timestamps)
- Update author names after a username change without having to update
documents
- Enables third parties to build new UIs (think Wikiwand for comments)
more easily
- Ability to tag/categorize individual comments/threads
- and more.
I identified some of these reasons when I wrote the proposal for LiquidThreads in October 2004 [2]. At that point, the Wikimedia Foundation had 0 employees, and this was too large an effort to likely get traction just from ad hoc volunteering. So after some time, I managed to persuade third parties to fund development, including Wikicities and WikiEducator, and found a developer to do the initial work, David McCabe. David did a good initial job but the system had many known issues and was only deployed at a small scale.
At the same time, I think there were many things about even the original design that were good (and aren't found in most other forum systems):
- It preserved "headers" on top of the threaded conversation as
community-editable wiki-like spaces
- It had a full history model for the thread itself, not just comments
- It preserved comments essentially as individual wiki pages, with
their own history
- It had a built-in notion of thread summaries, collaboratively
written, for closing comments
As WMF started to grow, it took on development of LiquidThreads -- with one developer, Andrew Garrett, who did an amazing job cleaning up the codebase and rethinking many of the assumptions David had made. LQT got to a point where some Wikimedia wikis actually requested for it to be enabled and traction started to build in favor of it. To this date, it is still found in some nooks and crannies in the Wikimedia universe.
translatewiki.net still uses it for its support page, and MediaWiki.org for its support desk, which are probably the highest profile uses left, and both get a fair bit of comment traffic.
Andrew did a ton of work on the project, but he himself recognized many architectural issues he wanted to address, and there are also UI assumptions we wanted to revisit. The project didn't have a team behind it at that time -- just one very talented part-time developer who was still at university! This was when WMF was barely growing to do development work, picking up some stuff (like LQT and FlaggedRevs) that had been simmering at a smaller scale before then.
In 2011, Brandon Harris, the first person at WMF ever to be tasked exclusively with design responsibilities, took a crack at some initial redesign drafts [5][6], which still contain many ideas worth looking at. But we pulled the plug at that time, because we recognized that we simply didn't have the personpower to put the resources behind the project to actually get it anywhere near completion -- and that a major architectural overhaul was required to do so.
A new effort was launched about a year ago, now resourcing a full team including design, development, product management, community support. (We're still pretty short staffed on UX research, QA, and data analyst support, but we make do.) As the team (including Andrew with his LQT experience under his belt) thought through the architectural needs of a modern discussion system, they decided that the LQT architecture was not salvageable. A migration script [7] is in development by Andrew himself.
The Flow architecture [8] differs in some important ways from LQT, including:
- Flow doesn't pretend that comments are "pages", instead using its
own separate tables to manage them. This is architecturally important to give us more flexibility on how to store, version, query, search, and describe comments.
- Flow is built from the start to store comments in a central
datastore, to make it easier to display comments and relevant notifications cross-wiki.
- Flow users Parsoid's HTML underneath, to prepare it for VisualEditor.
I don't think the architecture is perfect, but it should be a reasonable foundation to build on and iterate from.
The Flow UI, similarly, represents a first pass at this point. A lot of basic functionality is still missing. Things we know will make users happy (like cross-wiki features) are still ways out. It doesn't support VisualEditor yet, and yet its wikitext input suffers from any issues Parsoid does -- decisions made to future-proof the architecture have negative short term impact.
And like any brand-new UI, it could use lots of micro-optimization -- glitches here and there, which you may not even consciously notice, but which give you the feeling that you're using not-quite-ready software. Which you are.
At the same time, we know from user studies that talk pages are incredibly hard for new users to figure out. The semantics are just extremely different from anything else on the web. So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them. This parallels the long adoption of LQT for support desk type forums.
In this context, we also want to do some systematic measurement: How does such a system affect the # of comments posted, and the quality of the discussion?
We expect that we'd need to focus in on this use case in production for quite some time to get it right and really get people to fall in love with the system as it improves. At the same time, there may be other use cases that are less contentious and could serve as additional trials -- like talk pages in Wikidata.
We're not pushing an aggressive schedule on Flow -- we understand it needs to happen at the pace of the communities, since you can't build an "opt-out" for this kind of system (unlike VisualEditor). So the schedule is going to have to give as needed.
And as above, I'm open to us putting some short term effort into talk page improvements that can be made without Flow -- knowing it's still some time out. But based on the above long term functional and architectural considerations, I think a system that treats comments/threads as structured information, rather than as documents, is ultimately necessary, so I'd argue against procrastinating. It's going to be hard enough as it is to get this done without putting it on the backburner once more.
Finally, any comment that is about specific Flow UI aspects should be treated with a massive block of salt. The UI will evolve dramatically as we learn what works for new and experienced users alike.
Sincerely, Erik
[1] https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html [2] https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760 [3] https://translatewiki.net/wiki/Support [4] https://www.mediawiki.org/wiki/Project:Support_desk [5] https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design [7] https://gerrit.wikimedia.org/r/#/c/119243/ [8] https://www.mediawiki.org/wiki/Flow/Architecture -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
I composed the following as part of a longer message, but I decided not to send it unless others were having similar issues since I'm on track to exceed my monthly allowance of posts here ;):
" There's one thing in this discussion that troubles me greatly.
We've got a treasure trove of information/feedback in this thread from some of the people who are most knowledgable about the software and the problems it's trying to solve. Are we sure we're capturing all of the take-aways somewhere? How about the unresolved concerns? Is anything getting lost in transient discussions here or elsewhere?
I set out to answer this myself.
First, I looked for the talk page on Flow. Here it is: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow&action=hi... The first things to strike me are that it is very long, very active, very unstructured, and archived across 10 pages and counting. Hmmm. Same questions as above, applied to exponentially more threads.
Next, I went to bugzilla: https://bugzilla.wikimedia.org/buglist.cgi?component=Flow&list_id=342315... . Much more structured and captures some requirements in a workflow. Not so good for discussing higher-level issues, however. Moreover, that doesn't seem to be what the development team is keeping their backlog in. Off to trello. . .
I'm an experienced development manager that has been evangelizing agile programming of all stripes since 2001, and it took my searching the Flow talk page and clicking on a specific task to figure out how to list the backlog in trello. I think this is the right link in case you're looking for it yourself: https://trello.com/b/HD0lBssr/flow-backlog. A lot of these items link back to bugzilla and to another Flow discussion page. . .
. . .on the MediaWiki site conducted in Flow itself: https://www.mediawiki.org/wiki/Talk:Flow. I think I'll stop here, although there are more places where Flow is discussed, and I haven't even gotten in to the mainspace pages that are edited by the Wikimedia and MediaWiki developers to communicate outwards to the broader community. "
The summary of the tl;dr version is that it seems like there are opportunities to improve the discussion of Flow, starting with conducting it in fewer places and adding all takeaways as requirements to a workflow we can all track. The next step would be a discussion around prioritizing these requirements. Has this been done for Flow with full community involvement? If not, I think the WMF should take the lead on this one and show the community that it has taken the lessons from the recent MV experience and other poorly received rollouts to heart.
WMF, I appeal to you directly when I ask you to get us more involved, and, moreover, get us more invested in the success of Flow starting now by leading a discussion too many on this list and elsewhere have said hasn't happened and/or hasn't been heeded.
,Wil
On Sun, Sep 7, 2014 at 7:28 PM, Craig Franklin cfranklin@halonetwork.net wrote:
Hi,
Is there a page somewhere where I can see a detailed functional specification of this product, showing how it'll work, what functions/features it will include in it's MVP state, and such? I know about the page on Mediawiki ( https://www.mediawiki.org/wiki/Flow ) that talks about things in generalities and answers some specific questions in the FAQ, but I've not been able to locate any document that tells me exactly what it will *do*.
I have to confess that I'm not entirely confident that the rollout of Flow will be any smoother than the rollout of Visual Editor or MediaViewer, largely because I'm not entirely confident of what it is that I'm supposed to be getting. I'd be delighted to be corrected on this point if there is something out there that I've missed.
Cheers, Craig
On 6 September 2014 14:49, Erik Moeller erik@wikimedia.org wrote:
Hi all,
I'm breaking out this discussion about Flow/talk pages (apologies for repeatedly breaking the megathread, but this is a well-scoped subject which deserves its own thread).
Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there (pun intended).
== Document mode ==
There are not many examples of document mode discussion systems beyond wikis. You sometimes see people use collaborative realtime editors as such, because people want to talk in the same space where they work, but Google Docs provided alternatives (a pretty powerful comments/margin system and built-in chat) early on, for example.
The current talk page system is a document mode system. Individual comments have unclear boundaries (a single transaction can result in multiple comments, signed or unsigned; indentation levels are unpredictable and often inconsistent). All the joys and pain points of working on the same document are present (a heavily trafficked talk page will see many edit conflicts). You can't easily show comments in multiple contexts (cross-wiki, via email, as a notification, etc.) because of the boundary problem.
You could try to make a document mode system work better. On the basis of wikitext, you can do some very basic things, like the "new section" link I added to MediaWiki back in July 2003 [1], when I wrote: "This feature could also be the first stage of a more sophisticated discussion system, where the next stage would be auto-appending signatures and providing a 'Reply to this' link after each comment."
But due to the aforementioned unpredictability, even making a "reply" link work consistently (and do the right thing) is non-trivial. You can get some of the way there, and the Wikipedia Teahouse actually has a gadget, written by Andrew Garrett (more on him below) that does precisely that.
https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
Note the "Join this discussion" link. It does give you a pop-up, and posts the comment for you in the right place, with indentation (it does not auto-sign, but instead tries to teach users the signature habit which they'll need to use on other talk pages).
It may be worth doing more research and development on this, to see just how far we can get without changing the fundamentals, since a wholly new system may still be years out for wide use. However, there are inherent limitations due to the lack of a predictable and consistent structure.
You could go further down the road of a document mode or hybrid system, but IMO not without introducing fully predictable comment markers (think <comment id="234234">Bla ~~~</comment>) -- which would pollute the wikitext, be fragile (e.g. accidental or deliberate corruption of identifiers), and probably be considered unacceptable in a system that still supports unlimited wikitext editing for those reasons.
== Structured ==
I personally gave up on patchwork on top of talk pages about 10 years ago. The advantages of having comments clearly identified as such are many:
- Display comments in arbitrary order, arbitrary threading style
- Search comments across date ranges
- Search comments by author
- Track comments as comments, not as diffs
- Monitor changes at any part of a comment thread
- Display comments independent of a given document (e.g. email,
cross-wiki, etc.)
- Display comment metadata in different formats easily (e.g. timestamps)
- Update author names after a username change without having to update
documents
- Enables third parties to build new UIs (think Wikiwand for comments)
more easily
- Ability to tag/categorize individual comments/threads
- and more.
I identified some of these reasons when I wrote the proposal for LiquidThreads in October 2004 [2]. At that point, the Wikimedia Foundation had 0 employees, and this was too large an effort to likely get traction just from ad hoc volunteering. So after some time, I managed to persuade third parties to fund development, including Wikicities and WikiEducator, and found a developer to do the initial work, David McCabe. David did a good initial job but the system had many known issues and was only deployed at a small scale.
At the same time, I think there were many things about even the original design that were good (and aren't found in most other forum systems):
- It preserved "headers" on top of the threaded conversation as
community-editable wiki-like spaces
- It had a full history model for the thread itself, not just comments
- It preserved comments essentially as individual wiki pages, with
their own history
- It had a built-in notion of thread summaries, collaboratively
written, for closing comments
As WMF started to grow, it took on development of LiquidThreads -- with one developer, Andrew Garrett, who did an amazing job cleaning up the codebase and rethinking many of the assumptions David had made. LQT got to a point where some Wikimedia wikis actually requested for it to be enabled and traction started to build in favor of it. To this date, it is still found in some nooks and crannies in the Wikimedia universe.
translatewiki.net still uses it for its support page, and MediaWiki.org for its support desk, which are probably the highest profile uses left, and both get a fair bit of comment traffic.
Andrew did a ton of work on the project, but he himself recognized many architectural issues he wanted to address, and there are also UI assumptions we wanted to revisit. The project didn't have a team behind it at that time -- just one very talented part-time developer who was still at university! This was when WMF was barely growing to do development work, picking up some stuff (like LQT and FlaggedRevs) that had been simmering at a smaller scale before then.
In 2011, Brandon Harris, the first person at WMF ever to be tasked exclusively with design responsibilities, took a crack at some initial redesign drafts [5][6], which still contain many ideas worth looking at. But we pulled the plug at that time, because we recognized that we simply didn't have the personpower to put the resources behind the project to actually get it anywhere near completion -- and that a major architectural overhaul was required to do so.
A new effort was launched about a year ago, now resourcing a full team including design, development, product management, community support. (We're still pretty short staffed on UX research, QA, and data analyst support, but we make do.) As the team (including Andrew with his LQT experience under his belt) thought through the architectural needs of a modern discussion system, they decided that the LQT architecture was not salvageable. A migration script [7] is in development by Andrew himself.
The Flow architecture [8] differs in some important ways from LQT, including:
- Flow doesn't pretend that comments are "pages", instead using its
own separate tables to manage them. This is architecturally important to give us more flexibility on how to store, version, query, search, and describe comments.
- Flow is built from the start to store comments in a central
datastore, to make it easier to display comments and relevant notifications cross-wiki.
- Flow users Parsoid's HTML underneath, to prepare it for VisualEditor.
I don't think the architecture is perfect, but it should be a reasonable foundation to build on and iterate from.
The Flow UI, similarly, represents a first pass at this point. A lot of basic functionality is still missing. Things we know will make users happy (like cross-wiki features) are still ways out. It doesn't support VisualEditor yet, and yet its wikitext input suffers from any issues Parsoid does -- decisions made to future-proof the architecture have negative short term impact.
And like any brand-new UI, it could use lots of micro-optimization -- glitches here and there, which you may not even consciously notice, but which give you the feeling that you're using not-quite-ready software. Which you are.
At the same time, we know from user studies that talk pages are incredibly hard for new users to figure out. The semantics are just extremely different from anything else on the web. So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them. This parallels the long adoption of LQT for support desk type forums.
In this context, we also want to do some systematic measurement: How does such a system affect the # of comments posted, and the quality of the discussion?
We expect that we'd need to focus in on this use case in production for quite some time to get it right and really get people to fall in love with the system as it improves. At the same time, there may be other use cases that are less contentious and could serve as additional trials -- like talk pages in Wikidata.
We're not pushing an aggressive schedule on Flow -- we understand it needs to happen at the pace of the communities, since you can't build an "opt-out" for this kind of system (unlike VisualEditor). So the schedule is going to have to give as needed.
And as above, I'm open to us putting some short term effort into talk page improvements that can be made without Flow -- knowing it's still some time out. But based on the above long term functional and architectural considerations, I think a system that treats comments/threads as structured information, rather than as documents, is ultimately necessary, so I'd argue against procrastinating. It's going to be hard enough as it is to get this done without putting it on the backburner once more.
Finally, any comment that is about specific Flow UI aspects should be treated with a massive block of salt. The UI will evolve dramatically as we learn what works for new and experienced users alike.
Sincerely, Erik
[1] https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html [2] https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760 [3] https://translatewiki.net/wiki/Support [4] https://www.mediawiki.org/wiki/Project:Support_desk [5] https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design [7] https://gerrit.wikimedia.org/r/#/c/119243/ [8] https://www.mediawiki.org/wiki/Flow/Architecture -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hoi, You missed the multiple discussion pages in all the "other" languages. They are certainly as observant, as eloquent and they have different use cases and issues as well. Thanks, GerardM
On 8 September 2014 06:26, Wil Sinclair wllm@wllm.com wrote:
I composed the following as part of a longer message, but I decided not to send it unless others were having similar issues since I'm on track to exceed my monthly allowance of posts here ;):
" There's one thing in this discussion that troubles me greatly.
We've got a treasure trove of information/feedback in this thread from some of the people who are most knowledgable about the software and the problems it's trying to solve. Are we sure we're capturing all of the take-aways somewhere? How about the unresolved concerns? Is anything getting lost in transient discussions here or elsewhere?
I set out to answer this myself.
First, I looked for the talk page on Flow. Here it is:
https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow&action=hi... The first things to strike me are that it is very long, very active, very unstructured, and archived across 10 pages and counting. Hmmm. Same questions as above, applied to exponentially more threads.
Next, I went to bugzilla:
https://bugzilla.wikimedia.org/buglist.cgi?component=Flow&list_id=342315... . Much more structured and captures some requirements in a workflow. Not so good for discussing higher-level issues, however. Moreover, that doesn't seem to be what the development team is keeping their backlog in. Off to trello. . .
I'm an experienced development manager that has been evangelizing agile programming of all stripes since 2001, and it took my searching the Flow talk page and clicking on a specific task to figure out how to list the backlog in trello. I think this is the right link in case you're looking for it yourself: https://trello.com/b/HD0lBssr/flow-backlog. A lot of these items link back to bugzilla and to another Flow discussion page. . .
. . .on the MediaWiki site conducted in Flow itself: https://www.mediawiki.org/wiki/Talk:Flow. I think I'll stop here, although there are more places where Flow is discussed, and I haven't even gotten in to the mainspace pages that are edited by the Wikimedia and MediaWiki developers to communicate outwards to the broader community. "
The summary of the tl;dr version is that it seems like there are opportunities to improve the discussion of Flow, starting with conducting it in fewer places and adding all takeaways as requirements to a workflow we can all track. The next step would be a discussion around prioritizing these requirements. Has this been done for Flow with full community involvement? If not, I think the WMF should take the lead on this one and show the community that it has taken the lessons from the recent MV experience and other poorly received rollouts to heart.
WMF, I appeal to you directly when I ask you to get us more involved, and, moreover, get us more invested in the success of Flow starting now by leading a discussion too many on this list and elsewhere have said hasn't happened and/or hasn't been heeded.
,Wil
On Sun, Sep 7, 2014 at 7:28 PM, Craig Franklin cfranklin@halonetwork.net wrote:
Hi,
Is there a page somewhere where I can see a detailed functional specification of this product, showing how it'll work, what functions/features it will include in it's MVP state, and such? I know about the page on Mediawiki ( https://www.mediawiki.org/wiki/Flow ) that talks about things in generalities and answers some specific questions in the FAQ, but I've not been able to locate any document that tells me exactly what it will *do*.
I have to confess that I'm not entirely confident that the rollout of
Flow
will be any smoother than the rollout of Visual Editor or MediaViewer, largely because I'm not entirely confident of what it is that I'm
supposed
to be getting. I'd be delighted to be corrected on this point if there
is
something out there that I've missed.
Cheers, Craig
On 6 September 2014 14:49, Erik Moeller erik@wikimedia.org wrote:
Hi all,
I'm breaking out this discussion about Flow/talk pages (apologies for repeatedly breaking the megathread, but this is a well-scoped subject which deserves its own thread).
Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there (pun intended).
== Document mode ==
There are not many examples of document mode discussion systems beyond wikis. You sometimes see people use collaborative realtime editors as such, because people want to talk in the same space where they work, but Google Docs provided alternatives (a pretty powerful comments/margin system and built-in chat) early on, for example.
The current talk page system is a document mode system. Individual comments have unclear boundaries (a single transaction can result in multiple comments, signed or unsigned; indentation levels are unpredictable and often inconsistent). All the joys and pain points of working on the same document are present (a heavily trafficked talk page will see many edit conflicts). You can't easily show comments in multiple contexts (cross-wiki, via email, as a notification, etc.) because of the boundary problem.
You could try to make a document mode system work better. On the basis of wikitext, you can do some very basic things, like the "new section" link I added to MediaWiki back in July 2003 [1], when I wrote: "This feature could also be the first stage of a more sophisticated discussion system, where the next stage would be auto-appending signatures and providing a 'Reply to this' link after each comment."
But due to the aforementioned unpredictability, even making a "reply" link work consistently (and do the right thing) is non-trivial. You can get some of the way there, and the Wikipedia Teahouse actually has a gadget, written by Andrew Garrett (more on him below) that does precisely that.
https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
Note the "Join this discussion" link. It does give you a pop-up, and posts the comment for you in the right place, with indentation (it does not auto-sign, but instead tries to teach users the signature habit which they'll need to use on other talk pages).
It may be worth doing more research and development on this, to see just how far we can get without changing the fundamentals, since a wholly new system may still be years out for wide use. However, there are inherent limitations due to the lack of a predictable and consistent structure.
You could go further down the road of a document mode or hybrid system, but IMO not without introducing fully predictable comment markers (think <comment id="234234">Bla ~~~</comment>) -- which would pollute the wikitext, be fragile (e.g. accidental or deliberate corruption of identifiers), and probably be considered unacceptable in a system that still supports unlimited wikitext editing for those reasons.
== Structured ==
I personally gave up on patchwork on top of talk pages about 10 years ago. The advantages of having comments clearly identified as such are many:
- Display comments in arbitrary order, arbitrary threading style
- Search comments across date ranges
- Search comments by author
- Track comments as comments, not as diffs
- Monitor changes at any part of a comment thread
- Display comments independent of a given document (e.g. email,
cross-wiki, etc.)
- Display comment metadata in different formats easily (e.g. timestamps)
- Update author names after a username change without having to update
documents
- Enables third parties to build new UIs (think Wikiwand for comments)
more easily
- Ability to tag/categorize individual comments/threads
- and more.
I identified some of these reasons when I wrote the proposal for LiquidThreads in October 2004 [2]. At that point, the Wikimedia Foundation had 0 employees, and this was too large an effort to likely get traction just from ad hoc volunteering. So after some time, I managed to persuade third parties to fund development, including Wikicities and WikiEducator, and found a developer to do the initial work, David McCabe. David did a good initial job but the system had many known issues and was only deployed at a small scale.
At the same time, I think there were many things about even the original design that were good (and aren't found in most other forum systems):
- It preserved "headers" on top of the threaded conversation as
community-editable wiki-like spaces
- It had a full history model for the thread itself, not just comments
- It preserved comments essentially as individual wiki pages, with
their own history
- It had a built-in notion of thread summaries, collaboratively
written, for closing comments
As WMF started to grow, it took on development of LiquidThreads -- with one developer, Andrew Garrett, who did an amazing job cleaning up the codebase and rethinking many of the assumptions David had made. LQT got to a point where some Wikimedia wikis actually requested for it to be enabled and traction started to build in favor of it. To this date, it is still found in some nooks and crannies in the Wikimedia universe.
translatewiki.net still uses it for its support page, and MediaWiki.org for its support desk, which are probably the highest profile uses left, and both get a fair bit of comment traffic.
Andrew did a ton of work on the project, but he himself recognized many architectural issues he wanted to address, and there are also UI assumptions we wanted to revisit. The project didn't have a team behind it at that time -- just one very talented part-time developer who was still at university! This was when WMF was barely growing to do development work, picking up some stuff (like LQT and FlaggedRevs) that had been simmering at a smaller scale before then.
In 2011, Brandon Harris, the first person at WMF ever to be tasked exclusively with design responsibilities, took a crack at some initial redesign drafts [5][6], which still contain many ideas worth looking at. But we pulled the plug at that time, because we recognized that we simply didn't have the personpower to put the resources behind the project to actually get it anywhere near completion -- and that a major architectural overhaul was required to do so.
A new effort was launched about a year ago, now resourcing a full team including design, development, product management, community support. (We're still pretty short staffed on UX research, QA, and data analyst support, but we make do.) As the team (including Andrew with his LQT experience under his belt) thought through the architectural needs of a modern discussion system, they decided that the LQT architecture was not salvageable. A migration script [7] is in development by Andrew himself.
The Flow architecture [8] differs in some important ways from LQT, including:
- Flow doesn't pretend that comments are "pages", instead using its
own separate tables to manage them. This is architecturally important to give us more flexibility on how to store, version, query, search, and describe comments.
- Flow is built from the start to store comments in a central
datastore, to make it easier to display comments and relevant notifications cross-wiki.
- Flow users Parsoid's HTML underneath, to prepare it for VisualEditor.
I don't think the architecture is perfect, but it should be a reasonable foundation to build on and iterate from.
The Flow UI, similarly, represents a first pass at this point. A lot of basic functionality is still missing. Things we know will make users happy (like cross-wiki features) are still ways out. It doesn't support VisualEditor yet, and yet its wikitext input suffers from any issues Parsoid does -- decisions made to future-proof the architecture have negative short term impact.
And like any brand-new UI, it could use lots of micro-optimization -- glitches here and there, which you may not even consciously notice, but which give you the feeling that you're using not-quite-ready software. Which you are.
At the same time, we know from user studies that talk pages are incredibly hard for new users to figure out. The semantics are just extremely different from anything else on the web. So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them. This parallels the long adoption of LQT for support desk type forums.
In this context, we also want to do some systematic measurement: How does such a system affect the # of comments posted, and the quality of the discussion?
We expect that we'd need to focus in on this use case in production for quite some time to get it right and really get people to fall in love with the system as it improves. At the same time, there may be other use cases that are less contentious and could serve as additional trials -- like talk pages in Wikidata.
We're not pushing an aggressive schedule on Flow -- we understand it needs to happen at the pace of the communities, since you can't build an "opt-out" for this kind of system (unlike VisualEditor). So the schedule is going to have to give as needed.
And as above, I'm open to us putting some short term effort into talk page improvements that can be made without Flow -- knowing it's still some time out. But based on the above long term functional and architectural considerations, I think a system that treats comments/threads as structured information, rather than as documents, is ultimately necessary, so I'd argue against procrastinating. It's going to be hard enough as it is to get this done without putting it on the backburner once more.
Finally, any comment that is about specific Flow UI aspects should be treated with a massive block of salt. The UI will evolve dramatically as we learn what works for new and experienced users alike.
Sincerely, Erik
[1] https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html [2] https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760 [3] https://translatewiki.net/wiki/Support [4] https://www.mediawiki.org/wiki/Project:Support_desk [5]
https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png
[6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design [7] https://gerrit.wikimedia.org/r/#/c/119243/ [8] https://www.mediawiki.org/wiki/Flow/Architecture -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Thank you for this overview and history, Erik!
On Fri, Sep 5, 2014 at 9:49 PM, Erik Moeller erik@wikimedia.org wrote:
Hi all,
And as above, I'm open to us putting some short term effort into talk page improvements that can be made without Flow -- knowing it's still some time out.
Is there a good wiki page for brainstorming/discussing these kinds of talk page improvements (that may or may not be part of Flow?)
I always find it helpful in these kinds of conversations to try and imagine what concrete changes would help me on a day to day basis, as an editor and discussion participant, since it can be hard to envision what working with a whole new system would be like or to wrap one's head around the whole universe of discussions that take place on talk pages.
best, -- phoebe
wikimedia-l@lists.wikimedia.org