→Brewer’s Conjecture: in any distributed system. you cannot provide Consistency, Availability. and Partition tolerance. You have to pick two and lose one. |
|||
Line 195: | Line 195: | ||
::::So those are our only alternatives? Either have you spend the next 6 months negotiating a contract with me and every other Wikimedian over what Flow will and won't do, in all languages, across all projects or have you tell us things that are not true? |
::::So those are our only alternatives? Either have you spend the next 6 months negotiating a contract with me and every other Wikimedian over what Flow will and won't do, in all languages, across all projects or have you tell us things that are not true? |
||
::::I withdraw all my previous comments about Flow, because I no longer have any confidence that anything we have been told about Flow is true. I will watch this thread for replies for a while (probably without answering) and then I am going to unsubscribe from this page and focus my efforts elsewhere. --[[User:Guy Macon|Guy Macon]] ([[User talk:Guy Macon|talk]]) 06:32, 27 September 2013 (UTC) |
::::<s> I withdraw all my previous comments about Flow, because I no longer have any confidence that anything we have been told about Flow is true. I will watch this thread for replies for a while (probably without answering) and then I am going to unsubscribe from this page and focus my efforts elsewhere. </s> <sup> (On reflection, I cannot in good conscience do that. This hurts Wikipedia.) </sup> --[[User:Guy Macon|Guy Macon]] ([[User talk:Guy Macon|talk]]) 06:32, 27 September 2013 (UTC) |
||
:::: It is not a question of development. It is a question of honesty. It is a question of doing your best to find the truth and to avoid telling things that are not true. |
:::: It is not a question of development. It is a question of honesty. It is a question of doing your best to find the truth and to avoid telling things that are not true. |
||
Line 207: | Line 207: | ||
:::::But as you say, some users with special permissions might be able to edit somebody else's conversation and there exists a risk of edit conflicts. Well, if you really want to make sure that this risk is not forgotten then an option is to file already an enhancement request in [https://bugzilla.wikimedia.org/ Bugzilla] (MediaWiki Extensions >> Flow). Or you can wait until a functional prototype exists, test this use case and if the bug can be reproduced then let's file it in Bugzilla. |
:::::But as you say, some users with special permissions might be able to edit somebody else's conversation and there exists a risk of edit conflicts. Well, if you really want to make sure that this risk is not forgotten then an option is to file already an enhancement request in [https://bugzilla.wikimedia.org/ Bugzilla] (MediaWiki Extensions >> Flow). Or you can wait until a functional prototype exists, test this use case and if the bug can be reproduced then let's file it in Bugzilla. |
||
:::::And the same goes for automatically signed posts, or any other feature you care about: test it in the prototype when it's available or stamp it in Bugzilla already now as an enhancement request to make sure it's not overseen.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 04:59, 28 September 2013 (UTC) |
:::::And the same goes for automatically signed posts, or any other feature you care about: test it in the prototype when it's available or stamp it in Bugzilla already now as an enhancement request to make sure it's not overseen.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 04:59, 28 September 2013 (UTC) |
||
::::::If they had said that they think the final product will accomplish something that is at least theoretically possible, then "wait for a functional prototype and test" would be viable. That's not what they did here. The wrote -- in the main document that presents Flow to Wikipedia -- that they think the final product will accomplish something that is '''not''' theoretically possible. Not just hard. ''Impossible''. Perpetual motion impossible. Turning lead into gold impossible. Traveling faster than C (speed of light in a vacuum) impossible. |
|||
::::::Alas, this has an unfortunate implication. ''Anyone'' describing what they hope Flow will do must have at least some vague idea of how it will work. If I asked them to explain auto-signing, they would be able to give me a broad outline of how they plan on accomplishing this. Something like "user clicks on save button. Flow looks up the users signature. Flow appends the signature to the post. Flow appends the current time and date to the signature. Flow saves the comment." If you can't do that, you have no business editing the main document that presents Flow to Wikipedia. |
|||
::::::Nobody at the WMF (or anywhere else for that manner) can describe the steps that they hoped will get us "No edit conflicts ever" because no such sequence of steps exists or can exist. So unless you think that someone at WMF is a liar (which they are not) or stupid (which they are not), the only reasonable conclusion is that, in their zeal to market Flow to us, they wrote "''Current plans indicate that there will be no edit conflicts, ever''", which is impossible, without having any idea how to do that. And asked about this, they claimed that they do know how to do this impossible thing. That is a '''COMMUNICATIONS''' problem. And when I asked WMF to please address the communication problem, I was accused of claiming that they are here to "destroy everything you love" and "here to build something in a vacuum for the sake of riches and power". Then they accused ''me'' of violating [[WP:AGF]]! --[[User:Guy Macon|Guy Macon]] ([[User talk:Guy Macon|talk]]) 13:26, 28 September 2013 (UTC) |
|||
== Brewer’s Conjecture == |
|||
I am going to try to explain why "No edit conflicts" is theoretically impossible. |
|||
The CAP Theorem, otherwise known as Brewer’s Conjecture, was [[formal proof|formally proven]] to be true in 2002[http://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.pdf] |
|||
Wikipedia is a distributed system. If you try to edit a Wikipedia page while I try to edit the same page, our two computers are a distributed system. If there was one computer somewhere watching what keys we each hit and constantly updating our screens, that would be a different story. |
|||
We know that, in any distributed system. you cannot provide '''C'''onsistency, '''A'''vailability. and '''P'''artition tolerance. You have to pick two and lose one. |
|||
We cannot do without partition tolerance. You and I are not using the same computer, nor are our computers in constant communication. |
|||
Right now we do without availability -- the property that a request to edit the data will always complete. When I click the Save Page button after writing this, the write may fail and give me an edit conflict message. |
|||
We could provide guaranteed availability by dropping consistency. If you and I both edited a page at the same time Wikipedia could accept our edits and show each of us a different version. Not a workable idea, but it is possible. |
|||
What we '''cannot''' do, ''no matter how hard we try or how clever we are'', is to provide '''C'''onsistency, '''A'''vailability. and '''P'''artition tolerance at the same time. Consider you and I reading the same Wikipedia page. If we each edit the page, our two versions become inconsistent, thus forfeiting consistency. If we could communicate we could get back consistency, but by doing that we just forfeited partition tolerance. Or we could stop one of us from editing, thus losing availability. |
|||
See http://ksat.me/a-plain-english-introduction-to-cap-theorem/ |
|||
--[[User:Guy Macon|Guy Macon]] ([[User talk:Guy Macon|talk]]) 13:26, 28 September 2013 (UTC) |
|||
== "Test: User messaging 1: Talk page basics" - the methodology == |
== "Test: User messaging 1: Talk page basics" - the methodology == |
Revision as of 13:26, 28 September 2013
This page has archives. Sections older than 30 days may be automatically archived by Lowercase sigmabot III when more than 5 sections are present. |
Smaller and offsite announcements/mentions
Continued from Wikipedia:Flow#Announcements
- Wikipedia:Wikipedia Signpost/2013-03-11/Technology report - Article Feedback tool made opt-in only (brief)
- Wikipedia:Wikipedia Signpost/2013-01-21/Technology report - First Quarterly Review makes for interesting reading (brief)
- Wikipedia:Wikipedia Signpost/2012-12-31/Interview - Interview with Brion Vibber, the WMF's first employee (brief)
- Wikipedia:Wikipedia Signpost/2012-09-10/Technology report - August engineering report published (brief)
- Wikipedia:Requests for comment/Article feedback - January 2013 (numerous brief mentions)
- http://blog.wikimedia.org/2013/05/02/wikimedia-engineering-april-2013-report/#Editor_engagement_features
- http://blog.wikimedia.org/2013/04/12/wikimedia-foundation-report-march-2013/#Editor_engagement
- http://blog.wikimedia.org/2013/03/13/wikimedia-foundation-report-february-2013/#Editor_engagement
- http://blog.wikimedia.org/2013/03/12/engineering-february-2013-report/#Editor_engagement_features
- http://blog.wikimedia.org/2013/02/17/wikimedia-foundation-report-january-2013/#Editor_engagement
- http://blog.wikimedia.org/2013/02/07/engineering-january-2013-report/#Editor_engagement_features
- http://blog.wikimedia.org/2012/12/06/engineering-november-2012-report/#Architecture_.26_Platform_support
- http://blog.wikimedia.org/2012/10/03/engineering-september-2012-report/#MediaWiki_infrastructure
- http://blog.wikimedia.org/2012/09/04/engineering-august-2012-report/#MediaWiki_infrastructure
- WMF Editor Engagement mailing list (most of May 2013)
- Wikimedia tech ambassadors mailing list, 16 May 2013
Sugar and spice and everything WP:CIVIL
I was looking at some of the screenshots higher on this talk page, and I noticed that the "click to reply" links conclude with the exhortation to "Be nice!". Before I go any further, please let me be clear: I am in favor of being nice, and I do not oppose niceness, OK? I know that things are still in the development stages, and that a lot of the wording can be configured specifically for each project. I'd like, therefore, to make a suggestion.
A lot of male users in their teens or twenties are, I think, likely to see "nice" as patronizing, and it could boomerang by tempting them to do the opposite. Also, the English Wikipedia does not really assign a role to the word "nice" in policies or guidelines, instead using the word "civil", as in WP:CIVIL. I also recognize that the developers want to make the interface friendly to new users, so I'm not advocating sending users right to wiki-jargon, either.
I suggest changing "Be nice!" to "Please be polite.", with the word "polite" linked to WP:CIVIL, and the exclamation point changed to a simple period. --Tryptofish (talk) 00:09, 22 August 2013 (UTC)
- It won't be possible to include links within that text, btw. It's an HTML attribute called "placeholder"; once you interact with the element (click into it), the text disappears.
- My first thought is that if someone decides to be uncivil because they hate the word "nice" that they're probably going to quickly be blocked for being uncivil. But that's me.--Jorm (WMF) (talk) 00:13, 22 August 2013 (UTC)
- OK, please disregard what I said about the blue link. I actually agree with you about the behavioral part, but I really do think that we do no one any good by tempting them. The word "nice" can come across as kind of prissy to some eyes, and the word "polite" is more adult-sounding. There's so much youthful testosterone on the Internet that I believe it's worthwhile to pay attention to this. I can easily envision users that I come across every day looking at "Be nice!", and thinking, "Who are you, my mother?". --Tryptofish (talk) 00:25, 22 August 2013 (UTC)
- Dear Tryptofish; be nice. :) --Mom 04:50, 22 August 2013
- OK, please disregard what I said about the blue link. I actually agree with you about the behavioral part, but I really do think that we do no one any good by tempting them. The word "nice" can come across as kind of prissy to some eyes, and the word "polite" is more adult-sounding. There's so much youthful testosterone on the Internet that I believe it's worthwhile to pay attention to this. I can easily envision users that I come across every day looking at "Be nice!", and thinking, "Who are you, my mother?". --Tryptofish (talk) 00:25, 22 August 2013 (UTC)
- I don't really feel all that strongly about which word(s), if any, we should use to encourage civility, but I would like to point out that it's very interesting that you assume we should be catering our copy to "male users in their teens or twenties," or that the worst possible thing is to sound "prissy," Tryptofish. There are some deeply-held assumptions and stereotypes packed into those ideas that I think might be good to challenge, even if just hypothetically, as a thought experiment. Because it's absolutely true that much of the text on Wikipedia was written by men for men, and I wonder how much this one simple fact contributes to the ever-present gender gap... Maryana (WMF) (talk) 03:30, 22 August 2013 (UTC)
- Wait a second here. It can be fairly said that Wikipedia is written by more men than women—that research has been done. But "by men for men"? Male I may be, but when I write here, I'm writing for whoever may read it. I haven't seen a "No girls allowed" template at the top of any articles recently. What do you mean by that, when anyone who writes here has no idea who may read it, nor can control that? Seraphimblade Talk to me 21:47, 22 August 2013 (UTC)
- I was just reacting to this from Tryptofish's original comment: A lot of male users in their teens or twenties are, I think, likely to see "nice" as patronizing, and it could boomerang by tempting them to do the opposite. The assumption here appears to be that since most Wikipedia editors are currently male (which we do know from extensive research), we should be writing all our instructional copy (not content; specifically interface and system messages) in a way that makes men think/feel/behave a certain way. What I'm saying is that just because it's factually true that more men edit Wikipedia, we shouldn't necessarily continue to tailor our instructional copy only to them. Perhaps if we broke away from these assumptions about who our users are or could be (like the idea that the word "nice" is too "prissy" for Wikipedia editors and will cause them to intentionally be jerks), we could actually begin to attract a more diverse set of contributors. Maryana (WMF) (talk) 22:56, 22 August 2013 (UTC)
- Wait a second here. It can be fairly said that Wikipedia is written by more men than women—that research has been done. But "by men for men"? Male I may be, but when I write here, I'm writing for whoever may read it. I haven't seen a "No girls allowed" template at the top of any articles recently. What do you mean by that, when anyone who writes here has no idea who may read it, nor can control that? Seraphimblade Talk to me 21:47, 22 August 2013 (UTC)
- I don't really feel all that strongly about which word(s), if any, we should use to encourage civility, but I would like to point out that it's very interesting that you assume we should be catering our copy to "male users in their teens or twenties," or that the worst possible thing is to sound "prissy," Tryptofish. There are some deeply-held assumptions and stereotypes packed into those ideas that I think might be good to challenge, even if just hypothetically, as a thought experiment. Because it's absolutely true that much of the text on Wikipedia was written by men for men, and I wonder how much this one simple fact contributes to the ever-present gender gap... Maryana (WMF) (talk) 03:30, 22 August 2013 (UTC)
- Or we could lose the contributors we actually have without gaining any new ones... It is hard to tell what would happen.
- Anyway, that is beside the point. The actual string of characters is certainly configurable - at the very least because it would have to be translated for other Wikipedias. It is simply unthinkable that things could be done otherwise. Technically, the string itself would have to be a matter of policy - and policy is still decided by the community. And even if WMF would try to overrule the community, such decision is highly unlikely to be done by someone with job title "Product Manager".
- I do think that "Flow", the process of its development and WMF have many significant flaws, but this string is not one of them. --Martynas Patasius (talk) 00:14, 23 August 2013 (UTC)
- Oh, dear, maybe I should repeat what I said to begin with: I am in favor of being nice, and I do not oppose niceness, OK? (And thanks, IP-mom!) Starting a debate about gender was the farthest thing from my mind. (Indeed, anyone who cares might want to look carefully at the user boxes on my user page.) I never said that typical Wikipedians would react the way that I described, but rather that there are a goodly number who would, and that I see some of them every day that I edit. It's not about catering to them, but about being practical in dealing with the way that things are.
- Actually, I'm very much in favor of making Wikipedia more inclusive. But I rather doubt that this particular wording will accomplish that. In fact, another aspect quite distinct from what I said above is that the wording just tends to make it sound like social media, instead of a serious website where an encyclopedia is created.
- It occurs to me that, instead of discussing which word to use, we ought to discuss whether we need to say it at all. Was there any research that led the developers to add the "Be nice!" part to begin with? There is nothing on the current user interface that says that, so is there a reason for introducing it with Flow? --Tryptofish (talk) 00:30, 23 August 2013 (UTC)
- Hey, no worries, Tryptofish – this is just something I'm particularly sensitive to, so I'm a bit of a gadfly about it :) To answer your last question, the copy in the prototype is all super preliminary, not the real deal just yet. You're right that it may not make sense to include any message there at all in the final product; having the same phrase repeated in every single comment box risks an element of banner blindness. We'll play around with it. Maryana (WMF) (talk) 17:06, 23 August 2013 (UTC)
- That's a good kind of gadfly-ery, thanks. My advice would be to seriously consider leaving it out. If you've got to tell someone to be nice, they probably can't be told. --Tryptofish (talk) 00:44, 24 August 2013 (UTC)
- I cannot help thinking of an old maxim about the difference between good girls and nice girls - that it was the good girls you took home to mother, and the nice girls you took to the back alley. So, no, I'd really rather not be told to be nice. Risker (talk) 22:09, 21 September 2013 (UTC)
- Hey, no worries, Tryptofish – this is just something I'm particularly sensitive to, so I'm a bit of a gadfly about it :) To answer your last question, the copy in the prototype is all super preliminary, not the real deal just yet. You're right that it may not make sense to include any message there at all in the final product; having the same phrase repeated in every single comment box risks an element of banner blindness. We'll play around with it. Maryana (WMF) (talk) 17:06, 23 August 2013 (UTC)
What is Flow?
Having encountered the linked term "Flow" in a Portal article (with no explanation), I came here to find out what Flow is. The lede is of no help, saying it is a proposed change and it is not something else. Only after getting well into the article did I get an idea of what Flow is -- sort of. Can some-one please say what it is in the lede, and not just what it is about. For example, "Flow is a proposed change to the talk pages of Wikipedia that would (attempt to) make them easier for novices to use by ...[include the salient characteristic of the changes or deficits to be corrected]." — Preceding unsigned comment added by Kdammers (talk • contribs) 07:18, September 19, 2013 (UTC)
- @ Kdammers check out the main page now and lemme know if that makes a little more sense :) Maryana (WMF) (talk) 17:40, 20 September 2013 (UTC)
- Um, could we have less pro-WMF propaganda and more description there..? For example, "Talk pages—as a discussion technology—are antiquated and user-hostile." ([1]) is simply wrong: isn't WMF far more "user-hostile"..? The same statement is also shown to be false by many users who do manage to express their views even without full understanding of "wikitext".
- So, please, try to write as if it was an article: obey WP:NPOV and WP:V. Fairly describe all significant views, both "pro-WMF" and "anti-WMF". The difference form real article writing is that (perhaps) in this case you can cite yourself as a source of views of WMF.
- There is another advantage in that: if you will force yourself to state the arguments of your opponents fairly and in the way that they will accept themselves, you will be able to understand their position better and even to argue with it more competently (if, of course, you won't get persuaded). --Martynas Patasius (talk) 19:37, 21 September 2013 (UTC)
- I have removed the phrase "user-hostile", and replaced it with "not user-intuitive". Any technology, including Flow, can be used in a user-hostile manner. In fact, I think it's actually going to be far, far easier with flow to be user-hostile, especially given its core philosophies. Frankly, at this stage it looks like facebook - which is already severely outdated technology itself, and is losing users in droves. Risker (talk) 22:04, 21 September 2013 (UTC)
- I'd say it would still be better to write "Wikimedia Foundation [or "Maryana (WMF)"] thinks that talk pages—as a discussion technology—are antiquated and user-hostile, because they use elements of syntax not used elsewhere [or for some other reasons].". And then - "Opponents of this project argue that it is not true, as evidenced by the users who do communicate successfully in the talk pages without mastering the 'wikitext'." (or some different points).
- Although perhaps actually writing this "article" might be better left to Maryana (WMF) (provided that she tries to follow WP:NPOV etc.)..? After all, if her job has anything to do with gathering requirements and persuading us that the project are not worthless and WMF is not our enemy, she needs to demonstrate that she understands the arguments of "anti-WMF" side anyway... --Martynas Patasius (talk) 13:08, 22 September 2013 (UTC)
- This isn't an "article". It isn't subject to NPOV. We are very well aware of the "anti-WMF" arguments (and I have to say that using that name - "anti-WMF" - is not likely to carry any weight with anyone except people who hate the Foundation). Our job is to follow the mission and vision statement of the Wikimedia Foundation. Part of that is to make knowledge sharing available to everyone - not just people who are able to figure out the arcane rules and syntax of talk pages. Talk pages are anti-mission in that regard - they actively work against what we are trying to do.
- If you are not able to see that, I'm not sure if there's a chance of having a productive conversation. If you start your entire premise with "I am anti-WMF", I am not sure there's a chance of having a productive conversation. And if you base everything around "the WMF staff are idiots and don't understand what we're saying and don't get the community", I'm not sure there's a chance of having a productive conversation.--Jorm (WMF) (talk) 18:13, 22 September 2013 (UTC)
- It's starting to appear that we may be having a change of modus operandi that we are not asking for. The present one seems to be more than fit for purpose.
— | Gareth Griffith-Jones | The Welsh Buzzard | — 18:41, 22 September 2013 (UTC)- Gareth, you might want to go look at the very earliest edits by this user on his talk page. If it's "fit for purpose"—and if that purpose is to make things "available to everyone - not just people who are able to figure out the arcane rules and syntax of talk pages", as Jorm put it, then why did this guy have no idea how to post a message (his first-ever talk page words: "Im a new user. Not at all sure how to talk on talk page?? Have been blocked due to not talking...how is this done then please."), and why did he have so much trouble figuring out how to post that message when he needed to? If you hang out at the help desk or the teahouse, this is not actually an unusual level of difficulty. Unless the purpose is to keep new or less technically savvy people away, I can't see how this is fit for the purpose of having discussions with people who aren't already as experienced as you and I are. WhatamIdoing (talk) 23:50, 22 September 2013 (UTC)
- It's starting to appear that we may be having a change of modus operandi that we are not asking for. The present one seems to be more than fit for purpose.
- Sorry, but I am not impressed by your "counterexample"... The same user has been able to find a way to revert an edit ([2]) very soon - on his 10th edit. And using HotCat ([3]) just after the unblock request ([4])... Now it is good to assume that the user is telling the truth, but maybe we could get an example where it would take a little less effort..? And if it has to be an unblock request, maybe it could be without unfair accusations and demands to block directed at one's opponent who has communicated with the blocked user very nicely..? For I don't see why we should go out of our way to keep such newbies... There are enough newbies who are acting much better.
- Also, if the user doesn't notice the posts addressed to him, isn't it a problem with WP:NOTIFICATIONS (that, may I add, is another novelty of WMF)..? How is "Flow" supposed to affect anything about that..? --Martynas Patasius (talk) 01:57, 23 September 2013 (UTC)
- The value in this counterexample is that anyone familiar with this area knows just how typical it is. About 10% of unblock requests are malformed. There's one sitting in CAT:UNBLOCK right now whose editor forgot the closing }}. WhatamIdoing (talk) 02:07, 23 September 2013 (UTC)
- "The value in this counterexample is that anyone familiar with this area knows just how typical it is." - so, it is not addressed to anyone who is not "familiar with this area"..?
- "About 10% of unblock requests are malformed." - and what sample is this "10%" based on..? Anyway, your counterexample shows that "malformed" unblock requests are not necessarily a problem. The unblock request in [5] is malformed, if we'll look formally, but I am sure that the request was not denied ([6]) because it was "malformed", but because it was, well, a bit impolite and had little indication of contrition. And your new "counterexample" is likely to fail for the same reason: if one can find the request and read the valid reason for unblock, no problems with formatting will matter. Contrary to your claims, there are no "arcane rules". It is just that competence (in the sense of being able to communicate in English reasonably and politely) together with humility and obedience are required for all Wikipedians - and they are much harder to learn than "wikitext"... --Martynas Patasius (talk) 02:31, 23 September 2013 (UTC)
- The point you just raised is one that has come up repeatedly on this talk page. In part, I think the WMF folks do themselves no favor when they take the bait from the distinct minority of editors who feel as Martynas Patasius does. Many of us have concerns about effects on consensus-building and so forth, but do not see any of this as us-verus-them. I've become quite won-over to such improvements as automatic signing of comments, automatic fixing of what we now do with indentation, the ability to watchlist just one part of a talk page, and so on. I think that we have to be careful about ways in which the user interface might end up getting altered in ways that mislead new users about how Wikipedians come to decisions, and I am cautiously optimistic that the developers do not want to work at cross purposes with us in that regard. I hope that we are all in this together. --Tryptofish (talk) 19:20, 22 September 2013 (UTC)
- Please do not accuse editors making good-faith inquiries of baiting. That is rude. Thanks. — Scott • talk 11:27, 23 September 2013 (UTC)
- That's what you took away from what I said? It most certainly was not my intention! --Tryptofish (talk) 19:23, 23 September 2013 (UTC)
- Please do not accuse editors making good-faith inquiries of baiting. That is rude. Thanks. — Scott • talk 11:27, 23 September 2013 (UTC)
- The point you just raised is one that has come up repeatedly on this talk page. In part, I think the WMF folks do themselves no favor when they take the bait from the distinct minority of editors who feel as Martynas Patasius does. Many of us have concerns about effects on consensus-building and so forth, but do not see any of this as us-verus-them. I've become quite won-over to such improvements as automatic signing of comments, automatic fixing of what we now do with indentation, the ability to watchlist just one part of a talk page, and so on. I think that we have to be careful about ways in which the user interface might end up getting altered in ways that mislead new users about how Wikipedians come to decisions, and I am cautiously optimistic that the developers do not want to work at cross purposes with us in that regard. I hope that we are all in this together. --Tryptofish (talk) 19:20, 22 September 2013 (UTC)
- "This isn't an "article". It isn't subject to NPOV." - yes, I know. I am saying that it might still be a good idea to write as if it was.
- "Talk pages are anti-mission in that regard - they actively work against what we are trying to do." - well, do you have a proof, or are you just begging the question (assuming what still has to be proved)..?
- "If you are not able to see that, I'm not sure if there's a chance of having a productive conversation." - well, it depends on what counts as "productive". If you only count as productive something that assumes that we do need the "product" ("Flow") then no, it will not be "productive". But I don't see why that is a bad thing. And I also do not see why such a conversation could not be productive in any other way. Well, in principle - I see that you are not really interested in it and it takes at least two sides to have a conversation...
- "We are very well aware of the "anti-WMF" arguments" - good. You might wish to start answering them. "([A]nd I have to say that using that name - "anti-WMF" - is not likely to carry any weight with anyone except people who hate the Foundation)." - it can be "anti-Flow", if you wish.
- "If you start your entire premise with "I am anti-WMF", I am not sure there's a chance of having a productive conversation." - are you sure it is not a conclusion..? Also, how did you understand "anti-WMF"..? I even added quotation marks to emphasise that it was meant to denote a position contrary to position of WMF on the matter of "Flow" (and, perhaps, related projects, like "VisualEditor"). I get the impression that you took it to mean something different... Finally, even real enemies are not unknown to have productive conversations. That is how peace treaties come into being.
- "And if you base everything around "the WMF staff are idiots and don't understand what we're saying and don't get the community", I'm not sure there's a chance of having a productive conversation." - sorry, but that is just a caricature of your opponents' position. Who has called you (or anyone else) an "idiot"..? Who has even implied that..? If someone has, I must have missed it. There is an opinion that you (WMF) might not be doing a very good job, but that is a different thing.
- Or "don't understand what we're saying" - you know that I don't like "Flow" and I know that you know that. To that extent you certainly do understand what I am saying (and that is one of the reasons why I think your description is a caricature of a real position). But statements like "Part of that is to make knowledge sharing available to everyone - not just people who are able to figure out the arcane rules and syntax of talk pages. Talk pages are anti-mission in that regard - they actively work against what we are trying to do." asserted without any evidence do give a reason to suspect that you might not understand the position contrary to yours in full detail... And that is what writing a page as if it had to follow WP:NPOV might help with.
- Now just to show why the assertion about "the arcane rules and syntax of talk pages" is not "self evident", try to think how one can write something on a talk page. Yes: in simple plain text (for example, [7]). One does not need a signature. One does not need to answer with correct indentation. If necessary, someone else can do some refactoring (for example, [8]). Or it can be left as-is. What is "arcane" about that? How are you going to create anything less "arcane"? It would probably require speech recognition... And, unless I am mistaken, "Flow" is not going to have that.
- So, is my position clearer now..? --Martynas Patasius (talk) 23:47, 22 September 2013 (UTC)
- I think your position is crystal clear, and that there's no productive conversation to be had with you about this.--Jorm (WMF) (talk) 00:12, 23 September 2013 (UTC)
- Well, you sure do not seem to be close to persuading or befriending anyone who does not agree with you yet... Then again - I guess that is not your goal... --Martynas Patasius (talk) 01:30, 23 September 2013 (UTC)
- Given the shotgun spray of mischaracterizations and argumentative fallacies that have peppered your replies thus far, Jorm, which Martynas has been able to sidestep with the easy grace of a ballet dancer, no, it does not appear that there is. — Scott • talk 11:27, 23 September 2013 (UTC)
- Comment: I added some info on the guiding principles of the Flow project and Core features development in general. I'm also going to work a bit on fixing up the Rationale section and synthesizing some of the background research. What I'm hearing here is that some people are not convinced that talk pages are one of the "barriers that could preclude people from accessing or contributing to our projects." I'm guessing that's partly due to the fact that the citations to back this statement up are scattered over a number of pages and wikis. If you're still unconvinced even with these citations and feel we should not work on this project, you're welcome to continue leaving us feedback; however, it's unlikely that anyone from the development team will respond, since there's not much to say at that point.
- What we will gladly respond to – and not just with words, but with actual design and development of features – is feedback from anyone who believes that discussion and collaboration can be improved on Wikipedia and offers us ideas, suggestions, even scathing critiques that help keep us working toward our guiding principles. You may not realize this, but if you actually care about improving the discussion system on Wikipedia, you have tremendous power and resources at your fingertips right now – use them :) Maryana (WMF) (talk) 21:02, 23 September 2013 (UTC)
- Yes, I am pretty sure you do not want the discussion to end in the cancellation of your project or in the severe decrease of its priority. That is understandable, human. No one likes to do work that is seen as useless. Though, of course, I would like to remind you that if you do not try to persuade your opponents, they are not likely to change their positions... But anyway, this response is at least politely worded - and thank you for that.
- Still, after saying that, the statements you have added to the page ([9]) - "The Wikimedia Foundation works in partnership with a global community of volunteers made up of article writers, [...] and many others. These are the people who build the projects, and they are the Wikimedia Foundation's partners in developing the platform." - do look rather insulting... I do not really feel like your "partner in developing the platform" if you won't even take the trouble to try to persuade me that the platform actually does need the development you have in mind and that you are not just exaggerating the problems with it.
- "I'm guessing that's partly due to the fact that the citations to back this statement up are scattered over a number of pages and wikis." - what citations? I look at the page after you have edited it and I can see no "ref" tags at all. Nor do I see anything like malformed "ref" tags - neither internal links, nor simple plain text external links. That is my point: if you think that the problem with persuasiveness is that the evidence is not given in one place - add links here, as if you had to follow Wikipedia:Verifiability. Act as if that was an article! --Martynas Patasius (talk) 23:09, 23 September 2013 (UTC)
I consider that it would be a formidable task to argue dissent with Martynas Patasius' post immediately above.
— | Gareth Griffith-Jones | The Welsh Buzzard | — 17:24, 24 September 2013 (UTC)
- See..? Don't "ref" tags make everything better ([10])..?
- Finally, now we can "officially" discuss what does the cited evidence actually show - and, by its nature, such discussion might "accidentally" result in some requirements you are calling for.
- So thank you, Maryana (WMF), that was a good change. --Martynas Patasius (talk) 01:26, 24 September 2013 (UTC)
- Just so we get this straight, is there a serious argument being made here that we don't need to replace the present system at all, as opposed to questions about what the replacement should look like? I can't wrap my mind around the concept of anyone thinking that our current system is acceptable. --Guy Macon (talk) 20:01, 24 September 2013 (UTC)
- You would be surprised. Or maybe not. We actually hear that a lot - that talk pages are perfectly normal, and that people who can't figure them out don't deserve to be working on the projects.--Jorm (WMF) (talk) 20:22, 24 September 2013 (UTC)
- Just so we get this straight, is there a serious argument being made here that we don't need to replace the present system at all, as opposed to questions about what the replacement should look like? I can't wrap my mind around the concept of anyone thinking that our current system is acceptable. --Guy Macon (talk) 20:01, 24 September 2013 (UTC)
- It depends on what do you mean by "need". If "need" means literally "need", in the sense close to "Wikipedia will not survive to next Sunday unless we replace the talk page system with just anything else!", then yes, there is a very serious argument that we do not "need" to replace the current system. Wikipedia has used this system for years and survived - there is no reason to think that it would not survive for another week (or month or year or two or perhaps even ten), just because we do not change the talk pages.
- If, on the other hand, by "need" you merely mean that the current system of talk pages is not perfect and could be improved, then yes, I am not going to argue that it is perfect - and I do not think that anyone else is.
- I would say that the flaws of the current system have been exaggerated and the advantages of the current system (for example, flexibility or the unity of interface between articles and talk pages) have not been sufficiently appreciated by the representatives of WMF. Thus I see a danger that they will create something worse than the current system and push it against all disagreement (by then it might become dear to them just because it it "their" - that is understandable and human, but not very desirable). That is why I think that at this moment it is important to emphasise the advantages of the current system and flaws of "Flow". --Martynas Patasius (talk) 21:59, 24 September 2013 (UTC)
- In response to Guy, I should put myself forward as one who does "... think[ing] that our current system is acceptable."
Just two years ago, I began my first of any Talk page correspondance here on Wikipedia, having started editing experimentally only a few weeks earlier. I had no previous computer experience and I taught myself entirely by watching and examining other editors' posts in the edit mode. I was then 69 and delighted to have the opportunity of being a tiny cog in this wonderful project — I still am. I continue to learn new tricks every day. I am grateful for the stimulus/provocation that the editing and subsequent Talk page posting presents. Yes, I believe it is acceptable and, as with everything else, it may be modified in parts because without change it would stagnate.
— | Gareth Griffith-Jones | The Welsh Buzzard | — 08:20, 25 September 2013 (UTC)
- In response to Guy, I should put myself forward as one who does "... think[ing] that our current system is acceptable."
- Just posted on the Project page:
Flow will be released incrementally, as a limited opt-in beta. We want this product to change and grow over time, based on the feedback of the people who use it.
@ Maryana Does this indicate that even if Flow is operative, one may still continue with the existing Talk page method instead?
— | Gareth Griffith-Jones | The Welsh Buzzard | — 21:00, 26 September 2013 (UTC)
- Just posted on the Project page:
- "Release" in the above sentence simply means release to a couple of pages where people have agreed to try Flow out for a set period of time and give us feedback on what needs to be changed/improved. We're aiming for around December for that phase, then some time to fix issues based on that feedback, then figuring out whether we need to go back to the drawing board or release more widely... So, basically, most talk pages will still be talk pages in the next 6 months. At some point in the grand, utopian future, Flow is intended to replace talk pages, but that's pretty far out, and it won't come a surprise to anyone :) Maryana (WMF) (talk) 21:28, 26 September 2013 (UTC)
- And to further make sure that there is absolutely no confusion regarding this: it will not be possible to edit Flow-enabled talk pages like current talk pages. They are either-or, not both. When a page becomes Flow-enabled, the existing talk page is subsumed.--Jorm (WMF) (talk) 21:32, 26 September 2013 (UTC)
- Thank you both for your prompt replies.
— | Gareth Griffith-Jones | The Welsh Buzzard | — 21:49, 26 September 2013 (UTC)
- Thank you both for your prompt replies.
- I was actually quite pleased to see the description of the plans for the incremental roll out. I think that's the right way to go, because it will seek community feedback over time, before implementing it everywhere. --Tryptofish (talk) 22:36, 26 September 2013 (UTC)
- @ Tryptofish, speaking of feedback, a new section arises :) Chime in! Maryana (WMF) (talk) 22:48, 26 September 2013 (UTC)
- Thanks for asking me. I read that section, and my reaction to it is to agree with where you said "yikes!". Old fogie that I am, I've pretty much steered clear of pretty much all of those systems listed, other than Wikipedia of course. So I don't have anything helpful to offer, about structure. What is on my mind is a more cultural issue. It's not about how Flow would be put together, but more about the choice of words at the user interface, and about how to convey to new users the right, well, signals about how to work successfully on Wikipedia. It's not what you asked, in this case. One example would be where you and I previously discussed "nice". A more important instance would be choosing language that helps new users understand how WP:Consensus does and does not work, something I've raised in earlier talk threads about "talk" versus "discussion" versus "boards". I want to be careful not to mislead new users into thinking that Wikipedia is just like (fill in the blank, with whatever other website you wish), only to find subsequently that the community has certain cultural expectations that differentiate constructive editing from disruptive editing. TL;DR: Wikipedia ain't Facebook. --Tryptofish (talk) 23:10, 26 September 2013 (UTC)
- @ Tryptofish, speaking of feedback, a new section arises :) Chime in! Maryana (WMF) (talk) 22:48, 26 September 2013 (UTC)
- @ Tryptofish, this thread is getting pretty unwieldy. Hope you don't mind me splitting this off into a new section and replying to you below... Maryana (WMF) (talk) 23:24, 26 September 2013 (UTC)
- All good. --Tryptofish (talk) 00:27, 27 September 2013 (UTC)
- @ Tryptofish, this thread is getting pretty unwieldy. Hope you don't mind me splitting this off into a new section and replying to you below... Maryana (WMF) (talk) 23:24, 26 September 2013 (UTC)
No edit conflicts?
It has been claimed that Flow will prevent edit conflicts within the conversation space. I am curious as to how this will be accomplished.
We have already established that administrators can edit posts, and there exists more than one administrator, so the following scenario is possible:
User1 posts the following message under Flow:
- You can find info about SftToIPDoAC at http://www.rfc-editor.org/rfc/pdfrfc/rfc149.txt.pdf
Two administrators, AdminA and AdminB both notice an error in the above and each opens up an edit window so as to fix it. They come up with this:
AdminA version:
- You can find info about SftToIPDoAC at http://www.faqs.org/rfcs/rfc1149.html
AdminB version:
- You can find info about SftToIPDoAC at http://tools.ietf.org/html/rfc1149
They both save and then the undefined no edit conflict magic happens.
Which version gets posted? Last one saved? Or does Flow have a checkout / lock system so that one of the admins can't open an edit window? If so, can the first admin prevent editing for 24 hours by not checking in / unlocking?
Whichever version wins, does the winning admin know that he overwrote another admin instead of User1?
To illustrate why this might be a problem, consider the two admins posting followup messages without going over User1's post carefully to make sure some other admin hasn't changed the URL:
AdminA writes:
- If you look at comment number three at the URL in User1's post, you will see a proposal to boost the packet size to over 4 GB.
AdminB writes:
- If you click on the Errata link at the top of User1's URL, you will find a potential problem with Windows.
One of those statements will end up referencing the wrong URL and will be pointing the reader at something that does not exist.
Could we have some detail on what happens when two administrators try to modify the same post at the same time? --Guy Macon (talk) 21:45, 23 September 2013 (UTC)
- There'd be an edit conflict in that case. But the point is that this scenario would be an extremely rare edge-case, instead of an everyday reality when adding anything to an even moderately-trafficked talk page. Maryana (WMF) (talk) 23:07, 23 September 2013 (UTC)
- I don't want to be difficult, but the above highlights the communications problem we have. Until recently, the page that tells us what the plans are for Flow said No edit conflicts, ever.[11] and Jorm confirmed this when asked.[12] Now, when I ask essentially the same question, I get a different answer.
- Can I trust the other statements made in the same document? The same document told me that the plan was that there would be "No unsigned posts in discussions—all posts and comments will be automatically signed and dated." - a feature that had 100% approval among those polled. How do I know that that didn't go away as well? Do I have to keep asking on that one as well? How can we have a constructive conversation about the Flow feature set when I cannot get a straight answer as to what that feature set is? --Guy Macon (talk) 08:31, 25 September 2013 (UTC)
- Revisions are not bad. Changing the story as you learn new things is not bad. Telling us things that you know are not true and then later quietly deleting them is bad. (And before anyone tries to tell me that anyone ever believed the "No edit conflicts, ever" story, no, they did not. If anyone disagrees with me on this, simply tell me on what basis they believed that -- explaining in detail how they were planning on accomplishing it.) --Guy Macon (talk) 06:32, 27 September 2013 (UTC)
- @ Guy Macon, to quote from the almighty and powerful Agile Manifesto, we are a team that values: "Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan." What this means is that we could spend the next 6 months negotiating a contract with you and every other Wikimedian over what Flow will and won't do (in all languages, across all projects – we'd have to hire a lot of translators!). And then in another year, we'd deliver something that looks like Liquidthreads, and you'd shake your head and wonder what went wrong...
- Instead, we're going to spend the next 6 months knocking together a prototype, having people test it and say it's borked for foo and bar reason, fix foo and bar, release to a few pages onwiki, have people tell us that it absolutely needs to have zed, add zed, and release more widely only when all the big issues are fixed and there's consensus to move forward. Letting go of the former way of thinking about this project and embracing the latter is going to take a not-so-radical leap of faith on your part: Assume good faith. We're not here to destroy everything you love. We're not here to build something in a vacuum for the sake of riches and power (ha, like the Wikimedia Foundation is where we'd work if any of us cared about that). We're here to work with anybody who thinks that talk pages could be better, to create a kick-ass discussion system. Anybody! All you have to do is believe in these principles, and your voice carries just as much weight as anyone else on the development team. Really, it's that simple :) Maryana (WMF) (talk) 23:17, 26 September 2013 (UTC)
- So those are our only alternatives? Either have you spend the next 6 months negotiating a contract with me and every other Wikimedian over what Flow will and won't do, in all languages, across all projects or have you tell us things that are not true?
I withdraw all my previous comments about Flow, because I no longer have any confidence that anything we have been told about Flow is true. I will watch this thread for replies for a while (probably without answering) and then I am going to unsubscribe from this page and focus my efforts elsewhere.(On reflection, I cannot in good conscience do that. This hurts Wikipedia.) --Guy Macon (talk) 06:32, 27 September 2013 (UTC)
- It is not a question of development. It is a question of honesty. It is a question of doing your best to find the truth and to avoid telling things that are not true.
- I have given you a link to Wikipedia:Neutral point of view. It indicates many ways of telling something that we are not sure about with qualifications that prevent the whole statement from becoming false. "Current plans indicate that there will be: No edit conflicts, ever." ([13]) is not one of them. Do you not see how that can be interpreted to mean "Now we have reached the point where we know that there will be no edit conflicts, ever."..? Thus it ends up being a promise. And are you willing to say you (WMF - I know it was not added - [14] - by you personally) are not bound by promises? Are you willing to say your word is worthless?
- There is also a point of truth in advertising. You (WMF) are giving misleading statements praising the supposed benefits of your product, but do not tell us anything about its flaws. That is not good.
- And the solution is simple: tell the truth, with all necessary qualifications. Truth, all the truth, and nothing but truth. It truth is simply "The WMF 'Flow' team cannot promise you anything, but we want to make a great communication system to replace the talk pages!" - write so. If the truth is "The current prototype can do X, Y and Z, but cannot do A, B and C." - write so. If the truth is "We hope that the next version of the prototype will be able to do X." - write so. If the truth is "As of Y-M-D, we expect to use this architecture/data structure/algorithm." - write so. Well, do you see the pattern emerging..?
- The part about "All you have to do is believe in these principles, and your voice carries just as much weight as anyone else on the development team." also feels like "false advertising" (even if I am sure you said that sincerely). Really? You have also said ([15]) you are going to disregard the opinion of anyone who considers the current system to be good enough (and, presumably, to be in accordance with "those principles" - they are too vague to rule that out). Do you understand you end up implying that the ones on the development team will have no say too..?
- And some of "these principles" are also unlikely to stand up to much scrutiny. "The Core features team is dedicated to the guiding principle of serving every human being with the ability to contribute to the Wikimedia movement.". Read it. You end up saying that even the illiterate will be able to contribute. I find that hard to believe... And the goals that are both ambiguous and ambitious are the best way to make the project a complete disaster - especially if the team has the best intentions. --Martynas Patasius (talk) 22:15, 27 September 2013 (UTC)
- Guy Macon What really matters is the capacity of Flow to handle mid-air collisions, right? Nowadays there is not even a solid prototype, so none of us can really test. However, it is clear that if/when Flow runs in production it must handle edit conflicts effectively. In Flow users are supposed to edit only their own conversations instead of entire sections or full pages as we do here now. This diminishes radically the risk of edit conflicts.
- But as you say, some users with special permissions might be able to edit somebody else's conversation and there exists a risk of edit conflicts. Well, if you really want to make sure that this risk is not forgotten then an option is to file already an enhancement request in Bugzilla (MediaWiki Extensions >> Flow). Or you can wait until a functional prototype exists, test this use case and if the bug can be reproduced then let's file it in Bugzilla.
- And the same goes for automatically signed posts, or any other feature you care about: test it in the prototype when it's available or stamp it in Bugzilla already now as an enhancement request to make sure it's not overseen.--Qgil (talk) 04:59, 28 September 2013 (UTC)
- If they had said that they think the final product will accomplish something that is at least theoretically possible, then "wait for a functional prototype and test" would be viable. That's not what they did here. The wrote -- in the main document that presents Flow to Wikipedia -- that they think the final product will accomplish something that is not theoretically possible. Not just hard. Impossible. Perpetual motion impossible. Turning lead into gold impossible. Traveling faster than C (speed of light in a vacuum) impossible.
- Alas, this has an unfortunate implication. Anyone describing what they hope Flow will do must have at least some vague idea of how it will work. If I asked them to explain auto-signing, they would be able to give me a broad outline of how they plan on accomplishing this. Something like "user clicks on save button. Flow looks up the users signature. Flow appends the signature to the post. Flow appends the current time and date to the signature. Flow saves the comment." If you can't do that, you have no business editing the main document that presents Flow to Wikipedia.
- Nobody at the WMF (or anywhere else for that manner) can describe the steps that they hoped will get us "No edit conflicts ever" because no such sequence of steps exists or can exist. So unless you think that someone at WMF is a liar (which they are not) or stupid (which they are not), the only reasonable conclusion is that, in their zeal to market Flow to us, they wrote "Current plans indicate that there will be no edit conflicts, ever", which is impossible, without having any idea how to do that. And asked about this, they claimed that they do know how to do this impossible thing. That is a COMMUNICATIONS problem. And when I asked WMF to please address the communication problem, I was accused of claiming that they are here to "destroy everything you love" and "here to build something in a vacuum for the sake of riches and power". Then they accused me of violating WP:AGF! --Guy Macon (talk) 13:26, 28 September 2013 (UTC)
Brewer’s Conjecture
I am going to try to explain why "No edit conflicts" is theoretically impossible.
The CAP Theorem, otherwise known as Brewer’s Conjecture, was formally proven to be true in 2002[16]
Wikipedia is a distributed system. If you try to edit a Wikipedia page while I try to edit the same page, our two computers are a distributed system. If there was one computer somewhere watching what keys we each hit and constantly updating our screens, that would be a different story.
We know that, in any distributed system. you cannot provide Consistency, Availability. and Partition tolerance. You have to pick two and lose one.
We cannot do without partition tolerance. You and I are not using the same computer, nor are our computers in constant communication.
Right now we do without availability -- the property that a request to edit the data will always complete. When I click the Save Page button after writing this, the write may fail and give me an edit conflict message.
We could provide guaranteed availability by dropping consistency. If you and I both edited a page at the same time Wikipedia could accept our edits and show each of us a different version. Not a workable idea, but it is possible.
What we cannot do, no matter how hard we try or how clever we are, is to provide Consistency, Availability. and Partition tolerance at the same time. Consider you and I reading the same Wikipedia page. If we each edit the page, our two versions become inconsistent, thus forfeiting consistency. If we could communicate we could get back consistency, but by doing that we just forfeited partition tolerance. Or we could stop one of us from editing, thus losing availability.
See http://ksat.me/a-plain-english-introduction-to-cap-theorem/
--Guy Macon (talk) 13:26, 28 September 2013 (UTC)
"Test: User messaging 1: Talk page basics" - the methodology
OK, so, now ([17]) we have the statement "Simultaneously, we know that freeform wikitext talk pages present a significant barrier to new users" cited to mw:Flow Portal/Research/User Test Data ([18]). I think we should go through that research and discuss it. It might: 1) show to what extent it does support the statement, 2) show the necessary requirements. Unfortunately, the analysis in mw:Flow_Portal/Research ([19]) is not very detailed, but that means we are almost certain to do better here.
So, I would like to start with the methodology of the first of two tests (with the hope to tackle the first video of that test next).
Thus, first of all, we have to look at the sample. The sample size is 5 (including the "Test 1.1" that is similar to "Test 1"). That is highly unlikely to be useful for more serious analysis, but, well, that is still better than sample size zero. A bigger problem is that there is no indication how the sample was chosen. There is some explanation on the page of the company "UserTesting.com" that seems to have been doing the testing ([20]) - which, by the way, hasn't been mentioned on the research pages -, but it says the "target audience" has to be specified. It means that we do not know what the sample is supposed to represent. It could have been random readers of Wikipedia, random non-readers of Wikipedia... Thus at the moment there is no reason to think that the sample is representative for "new users" to any extent. That part might need to be qualified. Still, it is data that we have and there might be some use for it.
Then we have the scenario. The description given on the page is:
- "This is a test of Wikipedia's user-to-user communication systems. In this scenario, you have recently joined Wikipedia and tried a few first edits. A few days have passed since your initial login and you are now returning to the site, curious if anyone has noticed or objected to your edits."
It should be noted that, contrary to the assertion given with the test results - "The page was a very simple and common scenario." -, the actual scenario is neither simple nor common. The point is that, as it looks, the testers have not really tried editing Wikipedia any time before the test. However, the "normal" user cannot end up in the situation described in the scenario without doing any editing. Such user has to register (I suspect that that is what "joined Wikipedia" is supposed to mean, since all testers had to use the provided accounts) and to, well, "tr[y] a few first edits". Thus it could not have been the first time when the real user has seen "wikitext" or the basic interface of Wikipedia - and yet it looks like it was the first time for the testers. That can be expected to result in underestimation of the "user-friendliness" or "intuitiveness".
Then there are some general instructions:
- "Remember, we're testing the interface, not you. If you're having difficulty with something, the problem is with our design. Please "think out loud" as much as possible; tell us your thought process during each task, and try to explain your general opinions as you arrive at them."
- "If a task takes more than five minutes or so, just move on."
It should be noted that the use of help system or simple open-ended exploration ends up being discouraged (it is likely to take more than five minutes). That is not unreasonable if the testing was done to highlight the parts of the interface that deserve more attention, but once again - that can be expected to result in underestimation of the "user-friendliness" or "intuitiveness".
Then we get to the tasks:
- "1. Log in using the account Silver waffles. Suppose this is the account you previously created."
- "2. See if you can find out if you have new messages regarding your prior edits, including to an article you recall being about redemption. Where would you expect this to be found?"
- "Spend no more than a few minutes on this."
It should be noted that it does not seem to be realistic to expect to get some messages because of some article edits. Also, only recalling some general area about the article doesn't seem realistic in such case (if the user cares about the article, won't he remember a bit more?).
Anyway, it is not really the test for "Flow" as much, as it is a test for Wikipedia:Notifications.
- "3. You should have found your way to this page: http://en.wikipedia.org/wiki/User_talk:Silver_waffles - If not, go there now."
- "What is your impression of the messages? Do they appear to have been left by a human or automatically?"
Of course, it is a trick question - the "good" answer is that it is a "templated" message, filled out with some parameters by a human. Should it count as "left by human" or "left automatically"..? Both, perhaps? This task seems to be pretty useless to me. Especially given that "Flow" is not going to make us write everything by hand (I hope).
- "4. Now see if you can reply to the second message regarding the article you previously edited. Pretend you disagree with it and say so (you can use a reason if you want, but it's not required)."
First of all, "the second message" is unnecessarily confusing. Second, the name of the article hasn't been mentioned again (in the videos it can be seen that only one task is visible at the same time). Third, we should remember that there are many right answers (adding a reply on the same user talk page, on a talk page of the user being replied to; signature is optional, indentation is optional, heading is optional etc.). Fourth, that is one place where the tester is in an unrealistic position: a real user who did edit an article will know how to edit "something". And again - that can be expected to result in underestimation of the "user-friendliness" or "intuitiveness".
- "5. Suppose you're not sure Orchaen solns (the user who left the message) will know that you replied. Does there appear to be anything further you can/would need to do to make sure they get your response?"
- "Try to do this in whatever way makes the most sense to you."
The question is simply leading in the wrong direction (the correct answer is that nothing else is necessary). If the tester thought something like that was required, wouldn't he have done it during the fourth task..? It is not much of a reply if no one can see it. Thus the results of this task are meaningless and - once more - that task can be expected to result in underestimation of the "user-friendliness" or "intuitiveness".
So, in conclusion:
- The methodology of this test can be expected to result in severe underestimation of the "user-friendliness" or "intuitiveness" of the current talk page system.
- Two of five tasks (third and fifth) are worthless for just about any purpose.
- "Takeaways" (from mw:Flow_Portal/Research#Takeaways - [21]) like "None of the tested users were able to intuitively grasp anything about the use of User_talk pages." or "On average, it takes new users around 15 minutes to grasp the basics of user talk messaging." cannot be supported by such test.
- Statement "Simultaneously, we know that freeform wikitext talk pages present a significant barrier to new users" cannot be supported by such test without severe qualification (the "size" of the barrier is going to be greatly overestimated).
- The test might be useful if used correctly - to emphasise the parts of the interface that might need more attention.
So, would anyone disagree with such analysis..? --Martynas Patasius (talk) 00:08, 25 September 2013 (UTC)
Request for your feedback: Let's talk about nesting!
- Background
Talk pages are completely unstructured data; Flow is structured data. Unlike talk pages, which were created before the existence of smartphones, we have to account for how Flow will look on phones and tablets, which are currently ~20% of our readership traffic and swiftly growing. That means we have to make some choices about how we want discussion threads to look – specifically, how to make it clear who's talking to whom without creating an unreadable mess.
Take a look through the list of discussion communities and their nesting levels below (feel free to add more examples to it, too). If you've had discussions on any of these sites (or just browsed through them for a minute as a reader), what are the pros and cons you took away from the experience? (E.g., confusing to follow long conversations? hard to read on a phone? just right?) I'm seeding this with my observations, but you're welcome to add your own. This isn't a vote; I'm just trying to kicking off a conversation :)
Flat, zero levels of nesting
(flat conversations, one reply button, replies go to the bottom of the stack)
Comment
Reply
Reply to reply
Reply
- Examples of products using this pattern
- Pros/cons?
- works great on mobile!
- hard to have nuanced debate in a flat format
- difficult for users to skip content that irrelevant to them
- can be hard to keep track of who's talking to whom Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)
One level of nesting
(initial comment, all replies to that comment are flat)
Comment
- Reply
- Reply to reply
- Reply
- Examples of products using this pattern
- Pros/cons?
- looks good on mobile
- brings focus to the topic, not tangents/flamewars
- doesn't seem to be intended for robust user-to-user debate Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)
Two levels of nesting
(initial comment, answers, and replies to comment/answers that are less prominent)
Comment
- Reply
- Reply to reply
- Reply
- Examples of products using this pattern
- brings focus to question-answer interplay, not off-topic comments
- no confusion about where to respond
- begins to complicate mobile views of content
- by Jeff Atwood's account, intended to actively suppress free-form discussion.. WP:NOTFORUM? Maryana (WMF) (talk) 22:52, 26 September 2013 (UTC)
- It's worth noting that on StackOverflow (and the other StackExchange sites) there are also separate "chat rooms" - essentially a zero level of nesting conversation - where free-form discussion is encouraged to take place. While it's important that we adhere to WP:FORUM (and Flow doesn't encourage too much forumy behaviour) it's also important to remember that one of the primary reasons for a talk page is to build consensus, and you can't do that without relatively free discussion.
- On the subject of the StackExchange UI though, the ability to vote-up and vote-down questions, answers and comments might be an idea we want to borrow. We do a lot of polling and !voting on Wikipedia talk pages and we need a way for Flow to cope with that, including an easy way to count the !votes. WaggersTALK 13:13, 27 September 2013 (UTC)
- @ Waggers, interesting, I didn't know about the StackExchange chat room space... I guess SO's front-page discussion system doesn't quite meet all the needs of its users, if they require an alternate method for backchatting. That's definitely true of Wikipedia, too; some project areas may need more structure in their discussions, and some may need less, so we want to stay open to different configurations. I see you're a member of a couple of WikiProjects – from your experience, do those feel more like StackOverflow-type spaces where people ask questions and want answers, or more like informal chat/forum between members?
- On the consensus front: it seems to me that, in a way, StackExchange is also about building consensus (e.g., "what's the best answer for this question?"), and they've created the two-tiered system to encourage people to focus on the topic at hand, instead of spiralling off into back-and-forth 2-person tangents. You can still tangent in the comments, but those are just displayed in a way that makes it clear they're not part of the main discussion.
- Polls, !votes, upvote/downvoting, and other methods of gathering the pulse of the crowd are really interesting. I don't think we're going to get to exploring those options in Flow the near future, but it's definitely something to think about. I'm not sure how the wider editing community feels about these methods, though. There may be some users who have used StackExchange and other sites (e.g., Slashdot) and like them, but I've heard people express some misgivings about creating those kinds of filtering mechanisms on Wikipedia. Maryana (WMF) (talk) 19:46, 27 September 2013 (UTC)
- About polling, it's helpful to recognize that the consensus at the English Wikipedia is at WP:POLL. --Tryptofish (talk) 23:12, 27 September 2013 (UTC)
Three levels of nesting
(initial comment, reply, replies to replies, replies to replies to replies)
Comment
- Reply
- Reply to reply
- Reply to reply to reply
- Reply to reply
- Reply
- Examples of products using this pattern
- Pros/cons?
- starts to break down on mobile
- following threads gets more difficult – long tangents Maryana (WMF) (talk) 22:52, 26 September 2013 (UTC)
8-12 levels of nesting
(like the above, but even more nested!)
Comment
- Reply
- Reply to reply
- Reply to reply to reply
- Reply to reply
- Reply to reply to reply
- Reply to reply
- Reply to reply to reply
- Reply to reply
Reply
- Reply
- Examples of products using this pattern
- The Verge
- Wikipedia (effectively) after which people use {{outdent}}
- Quora
- Tumblr (3-5 is common, 11 is rare)
- Pros/cons?
- pretty much unreadable on a small screen without a ton of work (clicking, scrolling, zooming, pinching), and all but impossible to add new comments
- where do I respond (to the topic as a whole, to individual comments)? Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)
30+ or more levels of nesting
- Examples of products using this pattern
- Liquidthreads
- Thunderbird email subject lines
- Livejournal
- Pros/cons?
- yikes... Maryana (WMF) (talk) 22:44, 26 September 2013 (UTC)
- Comment Writing as one who has never taken part in any of the above mentioned sites (and has no intention of joining any of them either...), I find it a bit hard to understand what is being talked about. I've seen the mock-ups of 'Flow', and can't see that it's any improvement over the current system. It only takes a moment to explain indenting to a newbie - and if they can't understand that, they're not going to make any sense of anything. If Flow works anything like as well as VE has, we're going to be in a mess. And not able to talk about it unless there is some sort of opt-out provided. That I can't see happening. It's going to be all or nothing. I get the feeling sometimes that there's a similarity to the highways departments that have to ban parking on a road to speed the traffic flow up, and then put speed humps in to slow the traffic down again. They have to be seen to be doing something in order to justify their existence. Peridon (talk) 07:45, 27 September 2013 (UTC)
Copy on interface elements
From Tryptofish (copied from above): "What is on my mind is a more cultural issue. It's not about how Flow would be put together, but more about the choice of words at the user interface, and about how to convey to new users the right, well, signals about how to work successfully on Wikipedia. It's not what you asked, in this case. One example would be where you and I previously discussed "nice". A more important instance would be choosing language that helps new users understand how WP:Consensus does and does not work, something I've raised in earlier talk threads about "talk" versus "discussion" versus "boards". I want to be careful not to mislead new users into thinking that Wikipedia is just like (fill in the blank, with whatever other website you wish), only to find subsequently that the community has certain cultural expectations that differentiate constructive editing from disruptive editing. TL;DR: Wikipedia ain't Facebook." --Tryptofish (talk) 23:10, 26 September 2013 (UTC)
- Yes, copy is something we'll have to work out (we haven't really settled on a shared lexicon even within the team). However, it's also one of the easiest thing to change, so there's low cost to trying out new stuff and seeing what effect it has :)
- This isn't something I'm too worried about for the first release – simply because brand-new users are very unlikely to stumble into a WikiProject discussion space (non-article namespaces are pretty well hidden; usually, newbies who join WikiProjects have been explicitly invited by someone because it looks like they're already doing good work), but it'll definitely be something to consider extremely carefully by the time we start tackling user and article talk.
- To be fair, though, the terminology is already really muddled and confusing on Wikipedia – some things say talk, some things say discussion, and some discussion pages have giant "this is not a discussion!!!" disclaimers prominently tacked to the top... I like this quote from the Usability Initiative user studies: "when viewing discussion pages participants felt quite confident about what type of content and discussion was appropriate, until they encountered the most noticeable text on the page stating "this is not a forum," after which the doubts started to roll in." Maryana (WMF) (talk) 23:39, 26 September 2013 (UTC)
- Yes, I agree with you about all of that. It's something that should be pretty easy to deal with later on, and it has to be done language-by-language anyway. That's another good reason to roll it out incrementally. --Tryptofish (talk) 00:31, 27 September 2013 (UTC)