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, a major property of a document-centric architecture that is lost in a structured one is that it's open-ended, which means that end users can build new features and flows on top of it, without the need to request the platform developers to build support for them (sometimes even without writing new software at all; new workflows can be designed and maintained purely through social convention).
That's not something that's easy to do when the basic raw material for communication is split into comments and compartmentalized as table records with different owners. Such change means that a community that now can handle their own growth is made to utterly depend on the developers as gatekeepers for its expansion. In a project where the development team is understaffed, that's not a healthy proposition.
Sure, you have proposed a Workflow management system in the works, but with all respect that's pie in the sky. That possibility is under-specified, would require a lot of research and development with unclear goals and requirements, and there's no guarantee that it would ever be fit for the purpose. Please understand why we are wary of such proposal as the solution for all the flexibility requirements.
Sincerely, it looks like you have this grand vision on how a comment platform should work, and there's this blind spot to it. Despite repeated attempts by several experienced editors trying to explain to you how this architectural change would affect the essence of the project smooth operation and well-being, you dismiss them by focusing on a single feature at a time and missing the forest for the trees.
The point is not how we could replicate this or that feature on Flow, it's how we allow support for all future workflows that we don't know about yet, without requiring that software changes are made to the platform for each new need. We know that Wiki systems are valid platforms to support such expansion requirements, because we have seen them working; but we don't know how the structured architecture will behave, and there's no reason to believe it would work - no other structured system have achieved anything similar. You ask "how important are these needs"? I tell you they are *essential* to the community; the existing encyclopedia couldn't have been built without this openness.
You asked Todd to make requirements that are testable against the architecture. Well, I have one: how well does it allow end-users to build new unforeseen workflows without requiring development of ad-hoc software and changes to the platform?
I hope you give consideration to this argument before dismissing it as inconsequential. So far it seems that the decision has already been made and that your question ("Do we want discussions to occur in document mode, or in a structured comment mode?") is rhetorical. I hope that this happens not to be true, and the decision is still open to debate from the community.
Hoi, As it is the current talk pages are horrible. You gloss over this fact because you are so fired up about the potential of "end users can build new features and flows on top of it, without the need to request the platform developers to build support for them". Then you attack flow because some specifications are not there yet. In a previous mail it was said that much of the UI is very much under development, any discussion is to be taken with a table spoon of salt.
REALLY the current talk system is horrible on desktops, it is atrocious on mobiles. Your suggestion is to be dismissed with prejudice because it is so obviously wrong in so many ways.. I do not care about a possible potential of a broken system at all I may want to think about features that are actively used in this broken system. Thanks, GerardM
On 7 September 2014 07:57, Diego Moya dialmove@gmail.com wrote:
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, a major property of a document-centric architecture that is lost in a structured one is that it's open-ended, which means that end users can build new features and flows on top of it, without the need to request the platform developers to build support for them (sometimes even without writing new software at all; new workflows can be designed and maintained purely through social convention).
That's not something that's easy to do when the basic raw material for communication is split into comments and compartmentalized as table records with different owners. Such change means that a community that now can handle their own growth is made to utterly depend on the developers as gatekeepers for its expansion. In a project where the development team is understaffed, that's not a healthy proposition.
Sure, you have proposed a Workflow management system in the works, but with all respect that's pie in the sky. That possibility is under-specified, would require a lot of research and development with unclear goals and requirements, and there's no guarantee that it would ever be fit for the purpose. Please understand why we are wary of such proposal as the solution for all the flexibility requirements.
Sincerely, it looks like you have this grand vision on how a comment platform should work, and there's this blind spot to it. Despite repeated attempts by several experienced editors trying to explain to you how this architectural change would affect the essence of the project smooth operation and well-being, you dismiss them by focusing on a single feature at a time and missing the forest for the trees.
The point is not how we could replicate this or that feature on Flow, it's how we allow support for all future workflows that we don't know about yet, without requiring that software changes are made to the platform for each new need. We know that Wiki systems are valid platforms to support such expansion requirements, because we have seen them working; but we don't know how the structured architecture will behave, and there's no reason to believe it would work - no other structured system have achieved anything similar. You ask "how important are these needs"? I tell you they are *essential* to the community; the existing encyclopedia couldn't have been built without this openness.
You asked Todd to make requirements that are testable against the architecture. Well, I have one: how well does it allow end-users to build new unforeseen workflows without requiring development of ad-hoc software and changes to the platform?
I hope you give consideration to this argument before dismissing it as inconsequential. So far it seems that the decision has already been made and that your question ("Do we want discussions to occur in document mode, or in a structured comment mode?") is rhetorical. I hope that this happens not to be true, and the decision is still open to debate from the community. _______________________________________________ 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
Your suggestion is to be dismissed with prejudice because it is so obviously wrong in so many ways.. I do not care about a possible potential of a broken system at all I may want to think about features that are actively used in this broken system. Thanks, GerardM
I won't be dismissing it, because Diego makes some very good points and articulates the concerns that many in the community have expressed well.
Dismissing his ideas won't make them go away. I just hope that dismissing them with that prejudice you mentioned doesn't make him go away.
,Wil
Hoi, The central point Diego made starts from is that the current broken system has a POTENTIAL for unstructured, unaccountable changes by whomever.
You do not build on a fundament that is collapsing as it is. A system that is manifestly broken particularly on the one platform where our new users are; mobile.
If we are to take arguments seriously, please explain why we should in this instance. If dismissing such ideas makes him go away AFTER it has been explained why the arguments do not wash.. Well, the best that can be said is that it makes the conversation easier, it does not change the quality of the arguments at all. Thanks, GerardM
On 7 September 2014 09:55, Wil Sinclair wllm@wllm.com wrote:
Your suggestion is to be dismissed with prejudice because it is so obviously wrong in so many ways.. I do not care about a possible
potential
of a broken system at all I may want to think about features that are actively used in this broken system. Thanks, GerardM
I won't be dismissing it, because Diego makes some very good points and articulates the concerns that many in the community have expressed well.
Dismissing his ideas won't make them go away. I just hope that dismissing them with that prejudice you mentioned doesn't make him go away.
,Wil
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
Let me begin with this: my preferences lie far closer to yours, Gerard, than Diego's. I believe that we have a document oriented system that works well for stuff like encyclopedic content. But I think that we should be conducting our discussions in a discussion oriented system. That doesn't necessarily mean more structure- after all, Wikipedia pages are almost always highly structured documents- but it certainly requires '''different''' structure that might be enforced by software as opposed to editorial convention.
The central point Diego made starts from is that the current broken system has a POTENTIAL for unstructured, unaccountable changes by whomever.
You do not build on a fundament that is collapsing as it is. A system that is manifestly broken particularly on the one platform where our new users are; mobile.
I think Diego has a great point. By relying on software to enforce structure in our discussions, we will rely more on the developers. Let's take something that we all have a stake in as an example. In the beginning, there will be inevitably be bugs as the system is rolled out, and we will rely on the developers to fix them. Without the flexibility of our document oriented system, there may be no workarounds. That is something that may be mitigated with more flexibility built in to the system.
Diego touches on the need for flexibility within the discussion for many use cases, and I don't consider any of his requirements mutually exclusive with a discussion oriented system, as such. He seems to believe that we haven't held sufficient discussion on critical issues like the right tradeoff between flexibility for editors and structure for discussions. This sentiment has been expressed by several Wikipedians in this forum.
Without broad consensus that this discussion has been held, and the WMF has turned legitimate and sensible community needs and desires in to Flow requirements, Flow will not succeed. If Diego's sentiment is shared by a significant contingent of Wikipedians, we need to back up and do this right. No biggies. It's far more important to have the community invested in the success of Flow than to work towards deadlines. If we're concerned about getting this done soon for use cases such as those for mobile, we can accelerate the schedule as a community by helping the WMF. There is no shortage of opportunities to help at all levels of technical expertise.
If we are to take arguments seriously, please explain why we should in this instance. If dismissing such ideas makes him go away AFTER it has been explained why the arguments do not wash.. Well, the best that can be said is that it makes the conversation easier, it does not change the quality of the arguments at all.
Even if I were to disagree with Diego on certain issues, I won't be dismissing his ideas. Not because I want to recruit him as some sort of ally for the next battle. And not because dismissing them will not make these ideas go away, tho that is a very good reason not to dismiss them. I won't be dismissing them because Diego is a thoughtful Wikipedian, and all Wikipedians deserve respect and a chance to be heard out.
As a post script, I see that Diego wrote a thorough and de-escalating response. Huge +1 from me on that score. And then he did something that only the strongest of souls seem to be able to do: he apologized publicly for something he felt he could have done better. Diego, you have my deepest respect, and please keep on keeping on in this forum and elsewhere.
,Wil
On 09/07/2014 01:57 AM, Diego Moya wrote:
a major property of a document-centric architecture that is lost in a structured one is that it's open-ended, which means that end users can build new features and flows on top of it, without the need to request the platform developers to build support for them (sometimes even without writing new software at all; new workflows can be designed and maintained purely through social convention).
And yet, after over a decade of open-ended design through social convention, the end result is... our current talk pages. Perhaps another decade or two will be needed before that document-centric architecture gives us a half-decent discussion system?
Sorry if that sound snarky, but I have difficulty buying an argument that the current system has the potential to suffice when it has demonstrably already failed. It does no good to have the hypothetical capacity for a good system if, in practice, it's unusable.
-- Marc
On 7 September 2014 23:54, Marc A. Pelletier marc@uberbox.org wrote:
On 09/07/2014 01:57 AM, Diego Moya wrote:
a major property of a document-centric architecture that is lost in a structured one is that it's open-ended, which means that end users can build new features and flows on top of it, without the need to request
the
platform developers to build support for them (sometimes even without writing new software at all; new workflows can be designed and maintained purely through social convention).
And yet, after over a decade of open-ended design through social convention, the end result is... our current talk pages. Perhaps another decade or two will be needed before that document-centric architecture gives us a half-decent discussion system?
Sorry if that sound snarky, but I have difficulty buying an argument that the current system has the potential to suffice when it has demonstrably already failed. It does no good to have the hypothetical capacity for a good system if, in practice, it's unusable.
-- Marc
I suppose the question really is, has it failed? On what basis are we saying that our current discussion system is unusable?
Simply put, I'd suggest that the problem isn't the system, it's the discussion process itself that has points of failure. The replacement of actual discussion with templates is a point of failure, and that will not be improved by a change in the platform if all that happens is we use basically the same templates to have the same non-discussions. Nothing in the technology, either document-based or open-ended, will change the nature of the discourse itself; rude people will still be rude, erudite people will still be erudite, and none of will change the snark on Jimbo Wales's talk page. A significant percentage of Wikimedians rarely use talk pages at all (and a goodly number of those identify as exopedians), but no evidence that the percentage of Wikimedians who eschew social interaction has changed significantly, or that those with a low level of contribution to discussion space are doing so because they find the *technology* unappealing.
Risker/Anne
Hoi, There are two ways to look at the talk systems. It served us so far to some extend. It has been considered in need of replacement for a long time and consequently we have systems like Liquid Threads that are arguably at least as good in many use cases and fail in others.
The other way to look at tit is to see it fail on what is becoming increasingly the platform of our readers and our new editors; the mobile and the tablet. On those platforms talk pages are a disaster, an utter failure. This realisation that these types of devices are our future make it imperative to move away from our talk pages as soon as possible.
We do not have the time to procrastinate and we do not have time for continued deliberations of how nice it would be if we could do it all over again. As it is, we have a team of developers working on Flow. They are committed to consider the many use cases that exist in our community but in the end, fixing those will increasingly become an exercise in diminishing returns given the need to support our readers and editors on mobiles and tablets. The cost is not in the time of the development team, it is not in functionality we really want it is in supporting the growing percentage of people that do NOT use computers.
The question to ask is: who do we do it for, Thanks, GerardM
On 8 September 2014 06:13, Risker risker.wp@gmail.com wrote:
On 7 September 2014 23:54, Marc A. Pelletier marc@uberbox.org wrote:
On 09/07/2014 01:57 AM, Diego Moya wrote:
a major property of a document-centric architecture that is lost in a structured one is that it's open-ended, which means that end users can build new features and flows on top of it, without the need to request
the
platform developers to build support for them (sometimes even without writing new software at all; new workflows can be designed and
maintained
purely through social convention).
And yet, after over a decade of open-ended design through social convention, the end result is... our current talk pages. Perhaps another decade or two will be needed before that document-centric architecture gives us a half-decent discussion system?
Sorry if that sound snarky, but I have difficulty buying an argument that the current system has the potential to suffice when it has demonstrably already failed. It does no good to have the hypothetical capacity for a good system if, in practice, it's unusable.
-- Marc
I suppose the question really is, has it failed? On what basis are we saying that our current discussion system is unusable?
Simply put, I'd suggest that the problem isn't the system, it's the discussion process itself that has points of failure. The replacement of actual discussion with templates is a point of failure, and that will not be improved by a change in the platform if all that happens is we use basically the same templates to have the same non-discussions. Nothing in the technology, either document-based or open-ended, will change the nature of the discourse itself; rude people will still be rude, erudite people will still be erudite, and none of will change the snark on Jimbo Wales's talk page. A significant percentage of Wikimedians rarely use talk pages at all (and a goodly number of those identify as exopedians), but no evidence that the percentage of Wikimedians who eschew social interaction has changed significantly, or that those with a low level of contribution to discussion space are doing so because they find the *technology* unappealing.
Risker/Anne _______________________________________________ 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 Sun, Sep 7, 2014 at 9:54 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 09/07/2014 01:57 AM, Diego Moya wrote:
a major property of a document-centric architecture that is lost in a structured one is that it's open-ended, which means that end users can build new features and flows on top of it, without the need to request
the
platform developers to build support for them (sometimes even without writing new software at all; new workflows can be designed and maintained purely through social convention).
And yet, after over a decade of open-ended design through social convention, the end result is... our current talk pages. Perhaps another decade or two will be needed before that document-centric architecture gives us a half-decent discussion system?
I don't see talk pages as not being a half-decent discussion system. They support a lot more functionality than simple threaded discussion, so forum-style or social media-style software won't work for them. They provide a flexible system that allows them to serve the purpose of hosting discussions as well as a significant number of other functions.
Sorry if that sound snarky, but I have difficulty buying an argument that the current system has the potential to suffice when it has demonstrably already failed.
You said demonstrably, so I'm going to ask you to demonstrate it. What basis do you have for saying it's failed?
It does no good to have the hypothetical capacity for a good system if, in practice, it's unusable.
Sure, that statement is true, but it's irrelevant here given that a system used thousands upon thousands of times a day can hardly be called unusable.
Todd
On Mon, Sep 8, 2014 at 1:54 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 09/07/2014 01:57 AM, Diego Moya wrote:
a major property of a document-centric architecture that is lost in a structured one is that it's open-ended, which means that end users can build new features and flows on top of it, without the need to request the platform developers to build support for them (sometimes even without writing new software at all; new workflows can be designed and maintained purely through social convention).
And yet, after over a decade of open-ended design through social convention, the end result is... our current talk pages. Perhaps another decade or two will be needed before that document-centric architecture gives us a half-decent discussion system?
Or maybe it will take a decade to deliver a discussion-centric system that meets the needs of our community to replace the document-centric discussion system we currently have.
Sorry if that sound snarky, but I have difficulty buying an argument that the current system has the potential to suffice when it has demonstrably already failed. It does no good to have the hypothetical capacity for a good system if, in practice, it's unusable.
While it may not be everybody's dream system, talk pages are quite usable, as demonstrated by a lot of people using them every single day.
I am all for the addition of a discussion system, effectively the next iteration of Liquid Threads, but it worries me to see the *deployment* objectives are already articulated in annual plans to be complete replacement of all talk pages in 2015.
This potential problematic deploy could be very easily de-escalated by a WMF decision that Flow will not be forcibly deployed onto an unwilling project, and can be deployed per-page. If it is good software, the projects will *ask* for it to be deployed, like they did with LiquidThreads, and users will want to use it on their user talk even if the wider community isnt ready to migrate. e.g. once it is beta quality, I am sure Jimmy Wales will want it enabled on his user talk page, which would increase exposure to, and acceptance of, Flow.
On 8 September 2014 00:46, John Mark Vandenberg jayvdb@gmail.com wrote:
<snip>
. e.g. once it is beta quality, I am sure Jimmy Wales will want it enabled on his user talk page, which would increase exposure to, and acceptance of, Flow.
...or possibly far less complaining on his page. :-)
Risker/Anne
On 8 September 2014 05:46, John Mark Vandenberg jayvdb@gmail.com wrote:
If it is good software, the projects will *ask* for it to be deployed, like they did with LiquidThreads, and users will want to use it on their user talk even if the wider community isnt ready to migrate.
This is the key point.
Those of us who presently use talk pages to get the work done. What is going to make us *love* Flow, for all its imperfections, and demand to have it for ourselves? What's Flow's killer feature for us?
(I asked this before.)
- d.
A problem that I would like Flow to solve is the high amount of labor needed to read over a dozen pages across four wikis in order for the reader to access most of the MediaViewer discussions.
Pine On Sep 8, 2014 12:22 AM, "David Gerard" dgerard@gmail.com wrote:
On 8 September 2014 05:46, John Mark Vandenberg jayvdb@gmail.com wrote:
If it is good software, the projects will *ask* for it to be deployed, like they did with LiquidThreads, and users will want to use it on their user talk even if the wider community isnt ready to migrate.
This is the key point.
Those of us who presently use talk pages to get the work done. What is going to make us *love* Flow, for all its imperfections, and demand to have it for ourselves? What's Flow's killer feature for us?
(I asked this before.)
- d.
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, Pine, I would like so many things.. I expect that SUL and more goodliness from this will be a requirement. For me there is urgency in having a discussion system that works for mobiles and templates...
Once we have that we either have other priorities or it is a really good idea to be implemented while developers know Flow intimately well.. Thanks, GerardM
On 8 September 2014 09:46, Pine W wiki.pine@gmail.com wrote:
A problem that I would like Flow to solve is the high amount of labor needed to read over a dozen pages across four wikis in order for the reader to access most of the MediaViewer discussions.
Pine On Sep 8, 2014 12:22 AM, "David Gerard" dgerard@gmail.com wrote:
On 8 September 2014 05:46, John Mark Vandenberg jayvdb@gmail.com
wrote:
If it is good software, the projects will *ask* for it to be deployed, like they did with LiquidThreads, and users will want to use it on their user talk even if the wider community isnt ready to migrate.
This is the key point.
Those of us who presently use talk pages to get the work done. What is going to make us *love* Flow, for all its imperfections, and demand to have it for ourselves? What's Flow's killer feature for us?
(I asked this before.)
- d.
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
On Mon, Sep 8, 2014 at 12:22 AM, David Gerard dgerard@gmail.com wrote:
On 8 September 2014 05:46, John Mark Vandenberg jayvdb@gmail.com wrote: Those of us who presently use talk pages to get the work done. What is going to make us *love* Flow, for all its imperfections, and demand to have it for ourselves? What's Flow's killer feature for us?
First, on the subject of "kiler features", generally - we can make educated guesses, but with software that's used by communities, you really need to experiment and iterate. I'm sure we'll try stuff in Flow that doesn't make sense (and we've already talked here about aspects of the current design that may have to be changed, like the limited threading display), and I'm sure things we think are minor will become more popular than we expect.
Generally, I'm not a big fan of maintaining illusions of certainty. I've argued against detailed year-long plans to Sue and the Board, as I'm sure they will attest, until we got the flexibility to set more malleable goals in engineering. Lila immediately came in with the expectation in mind that we'd have precision a quarter out, and broad high level ideas a year out, and need flexibility to change our mind as we learn. In tech work, you need to be able to double down on success when you hit it (make that killer feature _the_ feature), and kill the cruft that you thought was smart but that just doesn't work.
With Echo, we included a bunch of notification types and didn't really know which ones people would love. We guessed that mentions would become popular, but their use has exceeded our wildest expectations. Go to any high traffic talk page and you'll see Echo pings all over the place. A feature that didn't exist before 2013 and that nobody, as far as I know, ever asked for (!) before we built it. And yet it's become indispensable.
When we experimented with mobile contributions, our first hypothesis was that uploads would be a good start, because mobile isn't well-suited for long form edit contributions. In fact, mobile editing became wildly popular very quickly and has generally been embraced by the community (to the point where people ask us to enable IP editing on mobile, which we consciously did not do initially to lessen crappy edits), while the signal to noise ratio on uploads has been so poor that we're about to retire most upload features until we really can spend cycles on mitigating those risks.
So, educated guesses and hypotheses.
Flow makes lots of things possible that are otherwise hard/impossible (much better search, tracking of comments, etc.) but my hypothesis is that there are three primary killer features that Flow can provide:
1) Fast interactions. The process of responding on a talk page is ridiculously slow (edit section, find place, indent comment, write comment, sign comment, preview, save, worry about edit conflict ..).
In my view, the reason people don't value this in Flow such-as-it-is already is primarily [[loss aversion]]. There's a large set of concerns that Flow makes existing things impossible (and yes, I'll respond a bit more to Diego) or harder. Losses are psychologically far more powerful than gains -- so any cool comment features that Flow _already has_ (fast and easy replies, no edit conflicts, etc) will not be perceived to be "killer features" unless/until the balance of perceived losses shrinks dramatically from what it is now. And it'll keep shrinking as we go.
As pointed out, we can _try_ to make this work with sticks, spit and duct tape on top of wikitext, even in the odd cases of mixed markup for indentation, comments interrupted in the middle, outdent templates, etc. -- but it'll almost certainly just have to bail in some cases, and misidentify comment demarcations in others. I'd like to test those boundaries a bit more before making confident statements about how much of "fast interactions" we can deliver without Flow, however. Either way, it is IMO a clear killer feature that's badly needed.
2) Centralized conversation spaces. Flow's architecture is already cross-wiki; its UI is not. As pointed out, there are multiple cross-wiki discussions as well as mailing list discussions about this very topic. Wil suggested "Pick a conversation space and stick to it!". Well, wouldn't that be nice - if it worked in our universe. Except that we know it rarely does. People want to have discussions in their "home wiki", and we use mailing list threads like this for good reasons as well.
You could participate in the same Flow conversation from en.wp, mediawiki.org and meta, without caring one way or another (SUL finalization being the main blocker to avoid account wonkiness). When/where that's desirable is something to negotiate -- but for example, feedback on features that are deployed across wikis is a perfect case for wanting to have local pages that feed into a single stream of comments.
If you want to go nuts, you could build a Flow<->mailing list or Flow<->NNTP (oldschool!) gateway. If we do our API homework, I mean literally "you" because we're sure as hell not going to do it anytime soon ;-)
Flow -theoretically- even could have language awareness of individual posts, enabling a single multilingual discussion space, easy translation of individual comments, etc. A team of Japanese researchers built something like this on top of LQT a few years ago, as a prototype: http://langrid.org/mwikidev/ (Guess why they didn't build it on old-school talk pages?) For a truly multilingual community, I think that could be a killer feature -- as opposed to just splitting the conversation spaces, as we do now.
3) Tags. The team hasn't decided if/how to implement tags yet. My own bet is that they could be a killer feature. Let people add/edit those right below the thread title with one click and see if they start using them.
Say you want an article to be deleted. Start a thread with #afd tag, explain your rationale, you're done. Other users can pull up the recent #afd threads, sort by date, etc. Discussion can happen at the article level or from the tag page.
Say you want to welcome new users. Leave a welcome note with #welcome tag. Other users can join in on the welcome and give tips/hints.
Say you're a new user and you want to get help. Start a thread with #help tag and it'll show up on that board. Other users can provide help. (Yes, I know the {{helpme}} template which is sort of a very poor person's version of this.)
Say you like a picture and you want to nominate it for FP status. Leave a note with #fpc and it'll get added to that feed. (Tags that are invoked from File talk: pages could dynamically include a thumb, so no need for extra logic to do that.)
If people misuse tags, others will remove them. (And no, it doesn't have to be the hashtag syntax. It could work like categories, where tags could have pages describing them and their purpose -- I wouldn't recommend using actual categories, because the hierarchy is overkill.)
You'd probably need a tiny bit more pixie dust for rich workflows, but I'm not quite sold on the idea of a workflow domain language or anything like that. I'd look for simple rules: Flow already has "closure" as a discussion property, so closed threads could be easily filtered. Setting a tag could generate a configurable notice on the subject page. Etc.
Workflows built in wikitext are cool (I've built a few myself, and I only hate myself a little bit for it in the morning), but they're not the only way to build workflows. Tags, dynamic searches, pings, and similar mechanisms can help build and improve workflows, as well, potentially in a much more straightforward fashion.
Flow can help us expand our toolset, and it's for us (the WMF-us) to prove that the balance of losses won't be too large in comparison to our (the Wikimedia-us) gains. But we (Wikimedia-we) need to do that cost accounting rationally, gently allowing reason, time, habit and adoption to act as a counter to the normal over-accouting of losses vs. gains.
Erik
On 9 September 2014 10:45, Erik Moeller erik@wikimedia.org wrote:
On Mon, Sep 8, 2014 at 12:22 AM, David Gerard dgerard@gmail.com wrote:
Those of us who presently use talk pages to get the work done. What is going to make us *love* Flow, for all its imperfections, and demand to have it for ourselves? What's Flow's killer feature for us?
First, on the subject of "kiler features", generally - we can make educated guesses, but with software that's used by communities, you really need to experiment and iterate. We guessed that mentions would become popular, but their use has exceeded our wildest expectations. Go to any high traffic talk page and you'll see Echo pings all over the place. A feature that didn't exist before 2013 and that nobody, as far as I know, ever asked for (!) before we built it. And yet it's become indispensable.
Yes, I see what you mean.
If you want to go nuts, you could build a Flow<->mailing list or Flow<->NNTP (oldschool!) gateway. If we do our API homework, I mean literally "you" because we're sure as hell not going to do it anytime soon ;-)
This is tangential, but caught my eye. I've rambled before about how (I think) the unit of a forum is the thread, but the unit of email/NNTP is the individual message; and gateways between the two suffer from this fundamental difference: http://reddragdiva.dreamwidth.org/566555.html
So do you expect the unit (in this sense) of Flow will be the message or the thread? Or both, or either?
(Wiki talk pages don't have a unit really, which is their blessing for flexibility and curse for usability.)
- d.
Thanks Erik for your mindful comment. Such high level technical, social and strategic vision is rare to find. It deserves being placed in a prominent position for increased visibility, and it helps in building bridges with the community.
Inter-wiki conversation sounds indeed like a killer feature in reference to discussion, and you're right that tags would increase the flexibility for definition of conversation-based workflows by increasing its granularity.
On 9 September 2014 11:55, David Gerard dgerard@gmail.com wrote:
(Wiki talk pages don't have a unit really, which is their blessing for flexibility and curse for usability.)
So much this. Though it doesn't need to be that way; that's not an essential property of wiki systems, although it may be for Mediawiki.
I've mentioned MS OneNote because it's an example of a full wiki-like environment where the unit of content is the multimedia element, and pages work as whiteboards - collages of such media items, that may include collaborative text and individualized comments, both attributable to their authors. The tool keeps track of each independent part an allows them to be merged or split by simple copy/paste operations, through a clever UI trick that highlights which part is currently being edited at any time.
Erik, would it be viable to use the Flow architecture to use topic threads as media elements?, in such way that: - topics or individual comments can be embedded as items within wiki blackboards - changes to comments are shown in the history of the blackboard container (with full diff support for the blackboard as a whole)
If those functions are viable, it would solve most or all of my "loss-aversion" "spider sense", as it would show a clear path to grow the platform into a truly flexible tool for collaborative creation, not just a conversation and community-building system as it seems to be planned from the information which is available so far.
On 9 September 2014 11:45, Erik Moeller erik@wikimedia.org wrote:
On Mon, Sep 8, 2014 at 12:22 AM, David Gerard dgerard@gmail.com wrote:
On 8 September 2014 05:46, John Mark Vandenberg jayvdb@gmail.com wrote: Those of us who presently use talk pages to get the work done. What is going to make us *love* Flow, for all its imperfections, and demand to have it for ourselves? What's Flow's killer feature for us?
First, on the subject of "kiler features", generally - we can make educated guesses, but with software that's used by communities, you really need to experiment and iterate. I'm sure we'll try stuff in Flow that doesn't make sense (and we've already talked here about aspects of the current design that may have to be changed, like the limited threading display), and I'm sure things we think are minor will become more popular than we expect.
Generally, I'm not a big fan of maintaining illusions of certainty. I've argued against detailed year-long plans to Sue and the Board, as I'm sure they will attest, until we got the flexibility to set more malleable goals in engineering. Lila immediately came in with the expectation in mind that we'd have precision a quarter out, and broad high level ideas a year out, and need flexibility to change our mind as we learn. In tech work, you need to be able to double down on success when you hit it (make that killer feature _the_ feature), and kill the cruft that you thought was smart but that just doesn't work.
With Echo, we included a bunch of notification types and didn't really know which ones people would love. We guessed that mentions would become popular, but their use has exceeded our wildest expectations. Go to any high traffic talk page and you'll see Echo pings all over the place. A feature that didn't exist before 2013 and that nobody, as far as I know, ever asked for (!) before we built it. And yet it's become indispensable.
When we experimented with mobile contributions, our first hypothesis was that uploads would be a good start, because mobile isn't well-suited for long form edit contributions. In fact, mobile editing became wildly popular very quickly and has generally been embraced by the community (to the point where people ask us to enable IP editing on mobile, which we consciously did not do initially to lessen crappy edits), while the signal to noise ratio on uploads has been so poor that we're about to retire most upload features until we really can spend cycles on mitigating those risks.
So, educated guesses and hypotheses.
Flow makes lots of things possible that are otherwise hard/impossible (much better search, tracking of comments, etc.) but my hypothesis is that there are three primary killer features that Flow can provide:
- Fast interactions. The process of responding on a talk page is
ridiculously slow (edit section, find place, indent comment, write comment, sign comment, preview, save, worry about edit conflict ..).
In my view, the reason people don't value this in Flow such-as-it-is already is primarily [[loss aversion]]. There's a large set of concerns that Flow makes existing things impossible (and yes, I'll respond a bit more to Diego) or harder. Losses are psychologically far more powerful than gains -- so any cool comment features that Flow _already has_ (fast and easy replies, no edit conflicts, etc) will not be perceived to be "killer features" unless/until the balance of perceived losses shrinks dramatically from what it is now. And it'll keep shrinking as we go.
As pointed out, we can _try_ to make this work with sticks, spit and duct tape on top of wikitext, even in the odd cases of mixed markup for indentation, comments interrupted in the middle, outdent templates, etc. -- but it'll almost certainly just have to bail in some cases, and misidentify comment demarcations in others. I'd like to test those boundaries a bit more before making confident statements about how much of "fast interactions" we can deliver without Flow, however. Either way, it is IMO a clear killer feature that's badly needed.
- Centralized conversation spaces. Flow's architecture is already
cross-wiki; its UI is not. As pointed out, there are multiple cross-wiki discussions as well as mailing list discussions about this very topic. Wil suggested "Pick a conversation space and stick to it!". Well, wouldn't that be nice - if it worked in our universe. Except that we know it rarely does. People want to have discussions in their "home wiki", and we use mailing list threads like this for good reasons as well.
You could participate in the same Flow conversation from en.wp, mediawiki.org and meta, without caring one way or another (SUL finalization being the main blocker to avoid account wonkiness). When/where that's desirable is something to negotiate -- but for example, feedback on features that are deployed across wikis is a perfect case for wanting to have local pages that feed into a single stream of comments.
If you want to go nuts, you could build a Flow<->mailing list or Flow<->NNTP (oldschool!) gateway. If we do our API homework, I mean literally "you" because we're sure as hell not going to do it anytime soon ;-)
Flow -theoretically- even could have language awareness of individual posts, enabling a single multilingual discussion space, easy translation of individual comments, etc. A team of Japanese researchers built something like this on top of LQT a few years ago, as a prototype: http://langrid.org/mwikidev/ (Guess why they didn't build it on old-school talk pages?) For a truly multilingual community, I think that could be a killer feature -- as opposed to just splitting the conversation spaces, as we do now.
- Tags. The team hasn't decided if/how to implement tags yet. My own
bet is that they could be a killer feature. Let people add/edit those right below the thread title with one click and see if they start using them.
Say you want an article to be deleted. Start a thread with #afd tag, explain your rationale, you're done. Other users can pull up the recent #afd threads, sort by date, etc. Discussion can happen at the article level or from the tag page.
Say you want to welcome new users. Leave a welcome note with #welcome tag. Other users can join in on the welcome and give tips/hints.
Say you're a new user and you want to get help. Start a thread with #help tag and it'll show up on that board. Other users can provide help. (Yes, I know the {{helpme}} template which is sort of a very poor person's version of this.)
Say you like a picture and you want to nominate it for FP status. Leave a note with #fpc and it'll get added to that feed. (Tags that are invoked from File talk: pages could dynamically include a thumb, so no need for extra logic to do that.)
If people misuse tags, others will remove them. (And no, it doesn't have to be the hashtag syntax. It could work like categories, where tags could have pages describing them and their purpose -- I wouldn't recommend using actual categories, because the hierarchy is overkill.)
You'd probably need a tiny bit more pixie dust for rich workflows, but I'm not quite sold on the idea of a workflow domain language or anything like that. I'd look for simple rules: Flow already has "closure" as a discussion property, so closed threads could be easily filtered. Setting a tag could generate a configurable notice on the subject page. Etc.
Workflows built in wikitext are cool (I've built a few myself, and I only hate myself a little bit for it in the morning), but they're not the only way to build workflows. Tags, dynamic searches, pings, and similar mechanisms can help build and improve workflows, as well, potentially in a much more straightforward fashion.
Flow can help us expand our toolset, and it's for us (the WMF-us) to prove that the balance of losses won't be too large in comparison to our (the Wikimedia-us) gains. But we (Wikimedia-we) need to do that cost accounting rationally, gently allowing reason, time, habit and adoption to act as a counter to the normal over-accouting of losses vs. gains.
Erik
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 8 September 2014 08:22, David Gerard dgerard@gmail.com wrote:
On 8 September 2014 05:46, John Mark Vandenberg jayvdb@gmail.com wrote:
If it is good software, the projects will *ask* for it to be deployed, like they did with LiquidThreads, and users will want to use it on their user talk even if the wider community isnt ready to migrate.
This is the key point.
Those of us who presently use talk pages to get the work done. What is going to make us *love* Flow, for all its imperfections, and demand to have it for ourselves? What's Flow's killer feature for us?
(I asked this before.)
When I sat in on a talk about Flow at Wikimania a year or so ago, the two that made me sit bolt upright as things we can't easily do with wikitext:
* potential to work with Notifications ("tell me when anyone replies to this discussion") without needing individual pings or relying on spotting one talkpage edit in a busy watchlist - especially since on some pages a comment may come two years later.
* inter-wiki or intra-wiki integration of multiple-venue discussions rather than several parallel pages and potentially parallel discussions (not a very frequent issue, but a messy one when needed; Pine notes this below)
The more nebulous one that has great promise is using Flow for workflows/processes (which falls out naturally from the integration of discussions) - this is what Erik describes below as tags, though I think that terminology is new to me.
On 10 September 2014 12:54, Andrew Gray andrew.gray@dunelm.org.uk wrote:
- inter-wiki or intra-wiki integration of multiple-venue discussions
rather than several parallel pages and potentially parallel discussions (not a very frequent issue, but a messy one when needed; Pine notes this below)
Yeah, that's getting into the "solves a problem I have" area I was thinking of.
A few more of these and experienced users will be demanding Flow.
- d.
On 10 September 2014 04:58, David Gerard dgerard@gmail.com wrote:
On 10 September 2014 12:54, Andrew Gray andrew.gray@dunelm.org.uk wrote:
- inter-wiki or intra-wiki integration of multiple-venue discussions
rather than several parallel pages and potentially parallel discussions (not a very frequent issue, but a messy one when needed; Pine notes this below)
Yeah, that's getting into the "solves a problem I have" area I was thinking of.
A few more of these and experienced users will be demanding Flow.
[Talking well into the future, and free-lancing a little in Danny's area; please do not expect this soon.]
One of the pain points about our treatment of content vs. discussion right now is how to expose to casual editors of a page that discussion is on-going about a particular aspect of an article, or that there has been a lot of argument about an aspect of the page and that this is now 'settled' – not that it can't be changed, but that editors may wish to consider before blindly changing something.
These discussions can range from the very specific (what exact term / wording should we use here?) to the very general (we should take care to use photos of the concept from all 'sides' of the debate). Most often they're about a small chunk of content and proposals to alter, expand or remove it. Indeed, the need to comment on these is flagged quite often when talking about Flow – generally in terms of "we need to copy content into the discussion and back out again", which I think is a solution rather than the core problem we're trying to address, framed by our current way of treating discussions.
Normally these discussions, and their total lack of visibility to all but a handful of editors who read the talk page and all its archives before they make each edit, aren't a problem. It's rare that a page has issues, after all, and very often "common sense" gets you most of the way there, so even without knowing about prior discussion your edits can be uncontroversial.
Sometimes we make edits against these agreed points, and someone previously involved in the discussion notices and undoes the change (or "fixes" it or whatever), and might drop a note on their talk page to that effect. This is effective for very highly-watched pages, but adds a lot of burden to people to monitor their watchlists' articles for changes against their hazy memories of what has and hasn't been discussed. Certainly, editor working on recent changes patrolling won't know the particulars of each article and the local discussions that have been had.
Occasionally, we use HTML comments to shout at potential editors ("Do NOT change his race!" on Barack Obama's article on the English Wikipedia, for instance). These are confusing to newbies (it's a magic fragile syntax that's uncommon), don't always 'work' (lots of people tune out whacky syntax they don't know), and very rarely give an indication as to /why/ some user posted that instruction, when this dates from and whether it's still current, or if it actually has consensus.
To make it easier for editors, we could provide a way to attach discussions not just to an article (Talk:Foo is stuff about "Foo") but as well to a particular item inside Foo – a section, a paragraph, a template, a reference, an image. When you edit, we could show somehow discussions attached to that item.
There have been proposals to use a right-hand bar to show information relevant to the content in view ("see related Wikidata item"; "articles on this subject in other languages use these images"; etc.); that could be a neat place to put relevant discussions' subjects/titles (or even the whole discussion). Alternatively, we could put little markers in a tray/gutter that users can click on to see more of, or put a highlighted ring around content subject to recent discussion when editors change it. There are lots of ways we could consider making a more powerful, more visible way to discuss content.
Making these kind of tool available through VisualEditor would be pretty easy (though getting the design right for all our workflows would need some care, and as always the challenges of getting a reasonable, consistent design for phone, tablet and desktop platforms will need some thought). Doing it in the wikitext editor in a way that makes sense for users might be harder. However, "hard" is not a good enough excuse for us not tackling these kinds of big issues around making editing a simpler, more obvious experience that doesn't need people to have read the talk page and all its archives before making an edit.
Does that sound like a useful change for experience editors? :-)
J.
On 10 September 2014 18:37, James Forrester jforrester@wikimedia.org wrote:
There have been proposals to use a right-hand bar to show information relevant to the content in view ("see related Wikidata item"; "articles on this subject in other languages use these images"; etc.); that could be a neat place to put relevant discussions' subjects/titles (or even the whole discussion). Alternatively, we could put little markers in a tray/gutter that users can click on to see more of, or put a highlighted ring around content subject to recent discussion when editors change it. There are lots of ways we could consider making a more powerful, more visible way to discuss content. Making these kind of tool available through VisualEditor would be pretty easy (though getting the design right for all our workflows would need some care, and as always the challenges of getting a reasonable, consistent design for phone, tablet and desktop platforms will need some thought). Doing it in the wikitext editor in a way that makes sense for users might be harder. However, "hard" is not a good enough excuse for us not tackling these kinds of big issues around making editing a simpler, more obvious experience that doesn't need people to have read the talk page and all its archives before making an edit. Does that sound like a useful change for experience editors? :-)
Yes, I like that a lot - the idea of "well, you hit edit. There's a discussion about *this* point *here* that you should probably read and argue in."
- d.
I think that would be very helpful indeed. "This part of the article was most recently discussed under subject "Stop changing the genre". Click here to review or participate in the discussion." On Sep 10, 2014 11:38 AM, "James Forrester" jforrester@wikimedia.org wrote:
On 10 September 2014 04:58, David Gerard dgerard@gmail.com wrote:
On 10 September 2014 12:54, Andrew Gray andrew.gray@dunelm.org.uk
wrote:
- inter-wiki or intra-wiki integration of multiple-venue discussions
rather than several parallel pages and potentially parallel discussions (not a very frequent issue, but a messy one when needed; Pine notes this below)
Yeah, that's getting into the "solves a problem I have" area I was thinking of.
A few more of these and experienced users will be demanding Flow.
[Talking well into the future, and free-lancing a little in Danny's area; please do not expect this soon.]
One of the pain points about our treatment of content vs. discussion right now is how to expose to casual editors of a page that discussion is on-going about a particular aspect of an article, or that there has been a lot of argument about an aspect of the page and that this is now 'settled' – not that it can't be changed, but that editors may wish to consider before blindly changing something.
These discussions can range from the very specific (what exact term / wording should we use here?) to the very general (we should take care to use photos of the concept from all 'sides' of the debate). Most often they're about a small chunk of content and proposals to alter, expand or remove it. Indeed, the need to comment on these is flagged quite often when talking about Flow – generally in terms of "we need to copy content into the discussion and back out again", which I think is a solution rather than the core problem we're trying to address, framed by our current way of treating discussions.
Normally these discussions, and their total lack of visibility to all but a handful of editors who read the talk page and all its archives before they make each edit, aren't a problem. It's rare that a page has issues, after all, and very often "common sense" gets you most of the way there, so even without knowing about prior discussion your edits can be uncontroversial.
Sometimes we make edits against these agreed points, and someone previously involved in the discussion notices and undoes the change (or "fixes" it or whatever), and might drop a note on their talk page to that effect. This is effective for very highly-watched pages, but adds a lot of burden to people to monitor their watchlists' articles for changes against their hazy memories of what has and hasn't been discussed. Certainly, editor working on recent changes patrolling won't know the particulars of each article and the local discussions that have been had.
Occasionally, we use HTML comments to shout at potential editors ("Do NOT change his race!" on Barack Obama's article on the English Wikipedia, for instance). These are confusing to newbies (it's a magic fragile syntax that's uncommon), don't always 'work' (lots of people tune out whacky syntax they don't know), and very rarely give an indication as to /why/ some user posted that instruction, when this dates from and whether it's still current, or if it actually has consensus.
To make it easier for editors, we could provide a way to attach discussions not just to an article (Talk:Foo is stuff about "Foo") but as well to a particular item inside Foo – a section, a paragraph, a template, a reference, an image. When you edit, we could show somehow discussions attached to that item.
There have been proposals to use a right-hand bar to show information relevant to the content in view ("see related Wikidata item"; "articles on this subject in other languages use these images"; etc.); that could be a neat place to put relevant discussions' subjects/titles (or even the whole discussion). Alternatively, we could put little markers in a tray/gutter that users can click on to see more of, or put a highlighted ring around content subject to recent discussion when editors change it. There are lots of ways we could consider making a more powerful, more visible way to discuss content.
Making these kind of tool available through VisualEditor would be pretty easy (though getting the design right for all our workflows would need some care, and as always the challenges of getting a reasonable, consistent design for phone, tablet and desktop platforms will need some thought). Doing it in the wikitext editor in a way that makes sense for users might be harder. However, "hard" is not a good enough excuse for us not tackling these kinds of big issues around making editing a simpler, more obvious experience that doesn't need people to have read the talk page and all its archives before making an edit.
Does that sound like a useful change for experience editors? :-)
J.
James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ 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 10 September 2014 18:48, Todd Allen toddmallen@gmail.com wrote:
I think that would be very helpful indeed. "This part of the article was most recently discussed under subject "Stop changing the genre". Click here to review or participate in the discussion."
This being Wikipedia, we need to think about when someone well-meaningly takes this new process way, way too far. And how to mitigate that ahead of time. But, yeah, this is what appeals to me about it.
James, this sort of thing will make experienced editors clamour for VE ;-) You should be able to do this with the present talk pages - annotate VE pages with a link to the discussion.
- d.
On 10 September 2014 10:52, David Gerard dgerard@gmail.com wrote:
On 10 September 2014 18:48, Todd Allen toddmallen@gmail.com wrote:
I think that would be very helpful indeed. "This part of the article was most recently discussed under subject "Stop changing the genre". Click
here
to review or participate in the discussion."
This being Wikipedia, we need to think about when someone well-meaningly takes this new process way, way too far. And how to mitigate that ahead of time. But, yeah, this is what appeals to me about it.
James, this sort of thing will make experienced editors clamour for VE ;-) You should be able to do this with the present talk pages - annotate VE pages with a link to the discussion.
Eh. I'm not particularly interested in building features that only work in VE and not wikitext, and particularly not in ones that would require changing both the wikitext used to write talk pages for the benefit of VE users and disrupting wikitext. We can, and we must, do better than that.
(But yes, I imagine the additional ease of VE here would be significant.)
J.
On 10 September 2014 18:59, James Forrester jforrester@wikimedia.org wrote:
Eh. I'm not particularly interested in building features that only work in VE and not wikitext, and particularly not in ones that would require changing both the wikitext used to write talk pages for the benefit of VE users and disrupting wikitext. We can, and we must, do better than that. (But yes, I imagine the additional ease of VE here would be significant.)
Yeah, special markup in this case is an annoyance. I'm picturing n00bs using the VE (newbies I throw at the VE *love* it *so much* ... I need to try them on adding a reference) and going "... ah. There's discussion on this point."
- d.
On 10 September 2014 11:01, David Gerard dgerard@gmail.com wrote:
On 10 September 2014 18:59, James Forrester jforrester@wikimedia.org wrote:
Eh. I'm not particularly interested in building features that only work
in
VE and not wikitext, and particularly not in ones that would require changing both the wikitext used to write talk pages for the benefit of VE users and disrupting wikitext. We can, and we must, do better than that. (But yes, I imagine the additional ease of VE here would be significant.)
Yeah, special markup in this case is an annoyance. I'm picturing n00bs using the VE (newbies I throw at the VE *love* it *so much* ... I need to try them on adding a reference) and going "... ah. There's discussion on this point."
Indeed, one of the uses of this model of content-centred-discussion combined with real-time collaborative editing that we're going to add to VisualEditor eventually, could be letting newbies call out for help mid-edit and admins/helpers/etc. could swoop in and show them how to add a reference; at the end of the edit, these discussions could get archived or just thrown away, depending on what works.
But now I'm just selling products we haven't built yet, which is a bit unfair. :-)
J.
On 10 September 2014 19:52, David Gerard dgerard@gmail.com wrote:
On 10 September 2014 18:48, Todd Allen toddmallen@gmail.com wrote:
I think that would be very helpful indeed. "This part of the article was most recently discussed under subject "Stop changing the genre". Click here to review or participate in the discussion."
James, this sort of thing will make experienced editors clamour for VE ;-) You should be able to do this with the present talk pages - annotate VE pages with a link to the discussion.
+1. Yup, that would be a welcome and useful enhancement. Something similar was suggested at en:Talk:Flow this week, so it may be a great idea for a future use case in the medium term - having some feature that both sides of the fence can agree it's a good thing :-)
On 10 September 2014 07:54, Andrew Gray andrew.gray@dunelm.org.uk wrote:
On 8 September 2014 08:22, David Gerard dgerard@gmail.com wrote:
<snip>
- potential to work with Notifications ("tell me when anyone replies
to this discussion") without needing individual pings or relying on spotting one talkpage edit in a busy watchlist - especially since on some pages a comment may come two years later.
You know, Andrew, this was always something that I thought would be one of the real features of Flow, one of the things that could pull people over to supporting the transition. Until it got turned it on.
I have 'watch-listed' the Flow-specific pages on Mediawikiwiki (MWW) and English Wikipedia for a very long time. When they turned on notifications at MWW about a week ago, my mailbox and notifications were flooded - I'm not talking just a little bit, I mean I got so many notifications that I couldn't sort out the ones that weren't related to that one specific Flow page - and that was with a single Flow stream being watched. I suppose I expected it to be like the email notices we get when a watched page gets edited on non-Wikipedia projects (e.g., Meta, MWW) - that is, the first change would generate an email/notification and nothing more until I went to the "page" itself. From what I've been told, this isn't something that Echo/notifications does or was meant to do.
I know the Flow team is scrambling to try to reduce the overwhelming nature of the notifications. But it occurs to me that there was a reason why "email notification" was never turned on for Wikipedia projects - the sheer volume of messages that would be generated for users with hundreds or thousands of pages on their watchlists - and that's going to be just as much an issue for Flow as it would be if we just turned on those email messages today. Looks brilliant on paper, but reality is a different thing.
Risker/Anne
On Wed, Sep 10, 2014 at 2:42 PM, Risker risker.wp@gmail.com wrote:
On 10 September 2014 07:54, Andrew Gray andrew.gray@dunelm.org.uk wrote:
On 8 September 2014 08:22, David Gerard dgerard@gmail.com wrote:
<snip>
- potential to work with Notifications ("tell me when anyone replies
to this discussion") without needing individual pings or relying on spotting one talkpage edit in a busy watchlist - especially since on some pages a comment may come two years later.
You know, Andrew, this was always something that I thought would be one of the real features of Flow, one of the things that could pull people over to supporting the transition. Until it got turned it on.
I have 'watch-listed' the Flow-specific pages on Mediawikiwiki (MWW) and English Wikipedia for a very long time. When they turned on notifications at MWW about a week ago, my mailbox and notifications were flooded - I'm not talking just a little bit, I mean I got so many notifications that I couldn't sort out the ones that weren't related to that one specific Flow page - and that was with a single Flow stream being watched. I suppose I expected it to be like the email notices we get when a watched page gets edited on non-Wikipedia projects (e.g., Meta, MWW) - that is, the first change would generate an email/notification and nothing more until I went to the "page" itself. From what I've been told, this isn't something that Echo/notifications does or was meant to do.
I know the Flow team is scrambling to try to reduce the overwhelming nature of the notifications. But it occurs to me that there was a reason why "email notification" was never turned on for Wikipedia projects - the sheer volume of messages that would be generated for users with hundreds or thousands of pages on their watchlists - and that's going to be just as much an issue for Flow as it would be if we just turned on those email messages today. Looks brilliant on paper, but reality is a different thing.
Risker/Anne
I think this is something of an oops, and not really something we should judge the product on. Currently the broken mess is "notify on all posts on all threads on the page", which should be "notify on all posts on the subscribed thread, and possible on new threads on the watched page." Everybody acknowledges the former is a mistake and stuff like that can happen in testing.
--Martijn
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 10 September 2014 17:47, Martijn Hoekstra
I think this is something of an oops, and not really something we should judge the product on. Currently the broken mess is "notify on all posts on all threads on the page", which should be "notify on all posts on the subscribed thread, and possible on new threads on the watched page."
The feature shouldn't be "notify on all posts on the subscribed thread" either. I don't want to be notified every time a new thread appears at any one of my watched pages. I have about 3000 pages in my watchlist, and receive around 400 updates daily only from talk pages, which 50 or so come from unique pages; getting all those as notifications would render Echo useless to me. Apparently this volume of data was not taken into account when designing the notification feature that was rolled out this week, and it is still ignored in the redesign proposals that I've seen at the various forums.
We have suggested a couple of times at en:Talk:Flow that notifications should come only from pages/topics/boards where the user has subscribed to, AND has explicitly enabled notifications, so that only a subset of preferred pages will alert the user - the rest of low-importance ones should be actively looked for at the Watchlist.
However, it's hard to tell whether such suggestions ever reach the development team; it's clear that this one need didn't arrive in time to be taken into account before the release.
Everybody acknowledges the former is a mistake and stuff like that can happen in testing.
This is not testing, this was rolled out to the production environment. The release has been interfering with the work of those editors who happen to have participated in any Flow page. This is more than an "oops", it's affecting the mission. Why is experimentation still being released to all editors, instead of limiting it to those willing to participate in it?
On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya dialmove@gmail.com wrote:
On 10 September 2014 17:47, Martijn Hoekstra
I think this is something of an oops, and not really something we should judge the product on. Currently the broken mess is "notify on all posts
on
all threads on the page", which should be "notify on all posts on the subscribed thread, and possible on new threads on the watched page."
The feature shouldn't be "notify on all posts on the subscribed thread" either. I don't want to be notified every time a new thread appears at any one of my watched pages.
Hence the "on the subscribed thread" not "on any thread on the board/watched page"
However, it's hard to tell whether such suggestions ever reach the development team; it's clear that this one need didn't arrive in time to be taken into account before the release.
Says who? What do you consider a release exactly?
Everybody acknowledges the former is a mistake and stuff like that can happen in testing.
This is not testing, this was rolled out to the production environment.
I'm confused. Where? Did I miss something? (please don't hesitate to say "yes" if the answer is yes)
The release has been interfering with the work of those editors who happen to have participated in any Flow page. This is more than an "oops", it's affecting the mission. Why is experimentation still being released to all editors, instead of limiting it to those willing to participate in it?
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 10 September 2014 19:49, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya dialmove@gmail.com wrote:
The feature shouldn't be "notify on all posts on the subscribed thread" either. I don't want to be notified every time a new thread appears at any one of my watched pages.
Hence the "on the subscribed thread" not "on any thread on the board/watched page"
That doesn't make any difference, Martijn. I ''want'' to be subscribed to all the topics at my 3000 pages, I just don't want to get a notification for all them; I want to actively seek most of those at the watchlist in an opportunistic way.
Notifications from a few selected subset of pages would be a godsend; however, if it was deployed to all talk pages with the current design, I'd have to disable the category of notifications from conversations - it's simply too distracting. The "howler" notification widget (is that its name? I first heard it this week) draws all attention when it's activated, in particular with that bright red color; I want it to be activated only for things I deem important, so that I only have to evaluate it for things that require my immediate evaluation. If it gets triggered too often, it disrupts the attention I pay to my other main tasks. This distinction between actively seeking updates in the Watchlist and passive notification from Echo seems missing from the design, at least for events that are not alerts.
However, it's hard to tell whether such suggestions ever reach the development team; it's clear that this one need didn't arrive in time to be taken into account before the release.
Says who? What do you consider a release exactly?
Anything that can affect what an editor can see at en.wiki or any other community site without activating it at Preferences>Beta (that's the official channel for opting in to experimental features, right?)
Everybody acknowledges the former is a mistake and stuff like that can happen in testing.
This is not testing, this was rolled out to the production environment.
I'm confused. Where? Did I miss something? (please don't hesitate to say "yes" if the answer is yes)
Yes, editors who subscribed to Wikiproject Breakfast and Wikiproject Hampshire have been receiving some strange, months-old notifications this week from those Flow pages. Danny had to step in at en:Talk:Flow and recommend that users disabled notifications from Flow to avoid problems.
On Wed, Sep 10, 2014 at 10:42 PM, Diego Moya dialmove@gmail.com wrote:
On 10 September 2014 19:49, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya dialmove@gmail.com wrote:
The feature shouldn't be "notify on all posts on the subscribed thread" either. I don't want to be notified every time a new thread appears at any one of my watched pages.
Hence the "on the subscribed thread" not "on any thread on the board/watched page"
That doesn't make any difference, Martijn. I ''want'' to be subscribed to all the topics at my 3000 pages, I just don't want to get a notification for all them; I want to actively seek most of those at the watchlist in an opportunistic way.
A single thread is a single topic.
Notifications from a few selected subset of pages would be a godsend; however, if it was deployed to all talk pages with the current design, I'd have to disable the category of notifications from conversations - it's simply too distracting. The "howler" notification widget (is that its name? I first heard it this week) draws all attention when it's activated, in particular with that bright red color; I want it to be activated only for things I deem important, so that I only have to evaluate it for things that require my immediate evaluation. If it gets triggered too often, it disrupts the attention I pay to my other main tasks. This distinction between actively seeking updates in the Watchlist and passive notification from Echo seems missing from the design, at least for events that are not alerts.
However, it's hard to tell whether such suggestions ever reach the development team; it's clear that this one need didn't arrive in time to be taken into account before the release.
Says who? What do you consider a release exactly?
Anything that can affect what an editor can see at en.wiki or any other community site without activating it at Preferences>Beta (that's the official channel for opting in to experimental features, right?)
Everybody acknowledges the former is a mistake and stuff like that can happen in testing.
This is not testing, this was rolled out to the production environment.
I'm confused. Where? Did I miss something? (please don't hesitate to say "yes" if the answer is yes)
Yes, editors who subscribed to Wikiproject Breakfast and Wikiproject Hampshire have been receiving some strange, months-old notifications this week from those Flow pages. Danny had to step in at en:Talk:Flow and recommend that users disabled notifications from Flow to avoid problems.
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 10 September 2014 22:49, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
That doesn't make any difference, Martijn. I ''want'' to be subscribed to all the topics at my 3000 pages, I just don't want to get a notification for all them; I want to actively seek most of those at the watchlist in an opportunistic way.
A single thread is a single topic.
Sorry, I was referring to an encyclopedic topic (i.e. what's covered by an article), not a conversation topic. In this context, we editors call "the topic" or "the article's topic" to what's discussed about the article, which is covered by all the conversations at an article's Talk page, that corresponds to a Flow Board. And a Board (i.e. what I called a page above) can contain hundreds of threads.
In short, I want to see updates to all threads that happen at all my subscribed articles, but I only want to be notified from updates to talk pages at those articles that I really care for.
(...I've just realized this overloading of the word "topic" may be a problem. Something to take into account in future conversations between the community and development team).
<this represents my personal opinion and in no way is anything official>
On Wed, Sep 10, 2014 at 1:17 PM, Diego Moya dialmove@gmail.com wrote:
The feature shouldn't be "notify on all posts on the subscribed thread" either. I don't want to be notified every time a new thread appears at any one of my watched pages. I have about 3000 pages in my watchlist, and receive around 400 updates daily only from talk pages, which 50 or so come from unique pages; getting all those as notifications would render Echo useless to me. Apparently this volume of data was not taken into account when designing the notification feature that was rolled out this week, and it is still ignored in the redesign proposals that I've seen at the various forums.
I wouldn't want that either. But maybe newbies would; that should probably be studied, if notifying newbies of new conversations on their watched talk pages is beneficial or not.
As for people like us, it seems there's already an opt-out in the form of going to Special:Preferences and turning off "flow" notifications. That could be made clearer that that's what it does, though.
I agree that the ability to select specific threads or boards for notification without doing it for every watchlisted board/thread would be even better. But that seems like a lower priority, since watchlists still work.
On 10 September 2014 22:28, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Wed, Sep 10, 2014 at 1:17 PM, Diego Moya dialmove@gmail.com wrote:
I have about 3000 pages in my watchlist, and receive around 400 updates daily only from talk pages, which 50 or so come from unique pages; getting all those as notifications would render Echo useless to me.
I wouldn't want that either. But maybe newbies would; that should probably be studied, if notifying newbies of new conversations on their watched talk pages is beneficial or not.
Sure, as they don't have 3000 pages watchlisted. :-)
As for people like us, it seems there's already an opt-out in the form of going to Special:Preferences and turning off "flow" notifications. That could be made clearer that that's what it does, though.
I agree that the ability to select specific threads or boards for notification without doing it for every watchlisted board/thread would be even better. But that seems like a lower priority, since watchlists still work.
My point was that, with relatively little more effort, the feature could be made useful to both newbies and veterans. If the best selling point that new Flow features can offer to us old editors is that they can be disabled, that's not going to make us love the project.
I don't mean that old users should be given priority over newcomers, nor even equal treatment (I know the newbie experience can be dreadful, and veterans are more resourceful), but our needs should be heard at least for those workflows that are being replaced or modified - and a couple of candies thrown here and there would help a lot too to create good will (see the example of {{Ping}} for a successful case).
On 8 Sep 2014, at 08:22, David Gerard dgerard@gmail.com wrote:
On 8 September 2014 05:46, John Mark Vandenberg jayvdb@gmail.com wrote:
If it is good software, the projects will *ask* for it to be deployed, like they did with LiquidThreads, and users will want to use it on their user talk even if the wider community isnt ready to migrate.
This is the key point.
Those of us who presently use talk pages to get the work done. What is going to make us *love* Flow, for all its imperfections, and demand to have it for ourselves? What's Flow's killer feature for us?
This really is the critical point.
If the WMF is developing new software that the community gets behind and explicitly asks to be deployed, then it’s doing the right thing.
If it’s having to force new software on the community against its objections, then it’s shooting itself in the foot.
Thanks, Mike
On 09/08/2014 12:46 AM, John Mark Vandenberg wrote:
While it may not be everybody's dream system, talk pages are quite usable, as demonstrated by a lot of people using them every single day.
That's... not a demonstration of usability. Like many people, I found myself using some random blunt object not designed for purpose to hammer in a nail at least once; that speaks to the importance of getting the nail in, not the lack of need for a proper hammer. :-)
Let's be honest here; I'm /highly/ computer-literate, and I've been using Mediawiki for some 11 years and I *still* find talk pages an annoyance at the best of times and they can be downright painful if there's anything like a large discussion in progress you are attempting to track/participate in. Between edit conflicts, increasingly confusing indentation, signatures that may or may not make separation between commenters clear... It's no surprise that newbies are scared away. Editing articles is already hard enough, anything that provides an extra barrier to participation hurts - especially when that barrier lies in the way of getting /help/.
Talk pages, as a mechanism, are lacking every affordance that users expect of a communication medium. And no, that X thousand people have gotten used to their failings does not make them any better for the Y billion people that have not.
But don't take my word for it! Find random newbies, and ask them to try the simple task of commenting on a discussion in progress without giving them guidance. They they flail around, or simply give up, remember that it's not /them/ who have failed -- I'm pretty sure they've participated in plenty of other online discussions before.
-- Marc
That's not a reasonable task, Marc. Newbies have an equally hard time editing content, too, and even when they succeed, on many projects they're very likely to be reverted and deluged with templated messages in response to a good faith attempt. There is no evidentiary basis to demonstrate that new users have a harder time participating in discussion than they do in content contribution. Independent studies seem to identify the nature of the discussions as being significantly more problematic than the technical means of participating.
Nobody is saying that it is easy for newbies to participate on many of the larger Wikimedia projects. There are lots of ways that we can make it easier. The most obvious one is automatic signing of comments, and it is something that we have technically been able to impose for years; sinebot didn't come into existence in a vacuum.
Risker/Anne
On 8 September 2014 09:58, Marc A. Pelletier marc@uberbox.org wrote:
On 09/08/2014 12:46 AM, John Mark Vandenberg wrote:
While it may not be everybody's dream system, talk pages are quite usable, as demonstrated by a lot of people using them every single day.
That's... not a demonstration of usability. Like many people, I found myself using some random blunt object not designed for purpose to hammer in a nail at least once; that speaks to the importance of getting the nail in, not the lack of need for a proper hammer. :-)
Let's be honest here; I'm /highly/ computer-literate, and I've been using Mediawiki for some 11 years and I *still* find talk pages an annoyance at the best of times and they can be downright painful if there's anything like a large discussion in progress you are attempting to track/participate in. Between edit conflicts, increasingly confusing indentation, signatures that may or may not make separation between commenters clear... It's no surprise that newbies are scared away. Editing articles is already hard enough, anything that provides an extra barrier to participation hurts - especially when that barrier lies in the way of getting /help/.
Talk pages, as a mechanism, are lacking every affordance that users expect of a communication medium. And no, that X thousand people have gotten used to their failings does not make them any better for the Y billion people that have not.
But don't take my word for it! Find random newbies, and ask them to try the simple task of commenting on a discussion in progress without giving them guidance. They they flail around, or simply give up, remember that it's not /them/ who have failed -- I'm pretty sure they've participated in plenty of other online discussions before.
-- Marc
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 09/08/2014 10:18 AM, Risker wrote:
The most obvious one is automatic signing of comments, and it is something that we have technically been able to impose for years; sinebot didn't come into existence in a vacuum.
I suppose that's a philosophical divergence between us then - that sinebot even needs to exist to me is demonstration that the system is broken.
You say that discussion isn't all that much harder than editing content. Even if I agreed with that (and I do not, edit conflicts in articles are much rarer than on talk pages - and usually easier to sort out), that's not a *good* thing!
Participating in discussion should be much, *much* easier than editing articles: encouraging newbies to seek help and participate in the community *before* diving in anything but trivial article edits would be an immensely powerful retention tool!
(Which isn't to say that editing articles doesn't *also* need a lot of help - but that's a different project).
-- Marc
Well, I think that the "article editing" project (i.e., VE) has a huge potential for also resolving a lot of discussion space issues. I don't see tacking on yet another UI as being a positive for new editor introduction or retention, and cannot think of another significant site that has two such wildly divergent interfaces (one very flexible and the other very rigid in structure), except perhaps in the mobile vs. desktop situation.
I dunno, Marc. There are different expectations about signature, depending on the target group. We still have people being freaked out that article histories contain their username or IP (a form of automatic signature), so I'm not convinced that there's an expectation on the part of new users that anything they write anywhere will automatically be signed.
Risker/Anne
On 8 September 2014 10:24, Marc A. Pelletier marc@uberbox.org wrote:
On 09/08/2014 10:18 AM, Risker wrote:
The most obvious one is automatic signing of comments, and it is something that we have technically been able to impose for years; sinebot didn't come into existence in a vacuum.
I suppose that's a philosophical divergence between us then - that sinebot even needs to exist to me is demonstration that the system is broken.
You say that discussion isn't all that much harder than editing content. Even if I agreed with that (and I do not, edit conflicts in articles are much rarer than on talk pages - and usually easier to sort out), that's not a *good* thing!
Participating in discussion should be much, *much* easier than editing articles: encouraging newbies to seek help and participate in the community *before* diving in anything but trivial article edits would be an immensely powerful retention tool!
(Which isn't to say that editing articles doesn't *also* need a lot of help - but that's a different project).
-- Marc
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hello,
a) This discussion actually belongs to a talk page on Meta or Mediawiki.org, for example :-)
b) All my experience in teaching Wikipedia tells me that the talk page system is absolutely outdated and inappropriate. It is, sorry to use this word, *ridiculous* that you have to teach people how to communicate technically in Wikipedia. I never had to explain to someone how to do that on Facebook...
As other people have pointed it out already, if you are already accustomed to the Wikipedia user interface for a longer time, you might find it difficult to fully understand what is the problem for newbies. And how big this is a problem, and how important it is to solve this problem.
Kind regards Ziko
Am Montag, 8. September 2014 schrieb Risker :
Well, I think that the "article editing" project (i.e., VE) has a huge potential for also resolving a lot of discussion space issues. I don't see tacking on yet another UI as being a positive for new editor introduction or retention, and cannot think of another significant site that has two such wildly divergent interfaces (one very flexible and the other very rigid in structure), except perhaps in the mobile vs. desktop situation.
I dunno, Marc. There are different expectations about signature, depending on the target group. We still have people being freaked out that article histories contain their username or IP (a form of automatic signature), so I'm not convinced that there's an expectation on the part of new users that anything they write anywhere will automatically be signed.
Risker/Anne
On 8 September 2014 10:24, Marc A. Pelletier <marc@uberbox.org javascript:;> wrote:
On 09/08/2014 10:18 AM, Risker wrote:
The most obvious one is automatic signing of comments, and it is something that we have technically been able to impose for years;
sinebot
didn't come into existence in a vacuum.
I suppose that's a philosophical divergence between us then - that sinebot even needs to exist to me is demonstration that the system is broken.
You say that discussion isn't all that much harder than editing content. Even if I agreed with that (and I do not, edit conflicts in articles are much rarer than on talk pages - and usually easier to sort out), that's not a *good* thing!
Participating in discussion should be much, *much* easier than editing articles: encouraging newbies to seek help and participate in the community *before* diving in anything but trivial article edits would be an immensely powerful retention tool!
(Which isn't to say that editing articles doesn't *also* need a lot of help - but that's a different project).
-- Marc
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org javascript:; <
https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wi...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org javascript:;
?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 javascript:; ?subject=unsubscribe>
+1
On 8 September 2014 16:43, Ziko van Dijk zvandijk@gmail.com wrote:
Hello,
a) This discussion actually belongs to a talk page on Meta or Mediawiki.org, for example :-)
b) All my experience in teaching Wikipedia tells me that the talk page system is absolutely outdated and inappropriate. It is, sorry to use this word, *ridiculous* that you have to teach people how to communicate technically in Wikipedia. I never had to explain to someone how to do that on Facebook...
As other people have pointed it out already, if you are already accustomed to the Wikipedia user interface for a longer time, you might find it difficult to fully understand what is the problem for newbies. And how big this is a problem, and how important it is to solve this problem.
Kind regards Ziko
Am Montag, 8. September 2014 schrieb Risker :
Well, I think that the "article editing" project (i.e., VE) has a huge potential for also resolving a lot of discussion space issues. I don't
see
tacking on yet another UI as being a positive for new editor introduction or retention, and cannot think of another significant site that has two such wildly divergent interfaces (one very flexible and the other very rigid in structure), except perhaps in the mobile vs. desktop situation.
I dunno, Marc. There are different expectations about signature,
depending
on the target group. We still have people being freaked out that article histories contain their username or IP (a form of automatic signature),
so
I'm not convinced that there's an expectation on the part of new users
that
anything they write anywhere will automatically be signed.
Risker/Anne
On 8 September 2014 10:24, Marc A. Pelletier <marc@uberbox.org javascript:;> wrote:
On 09/08/2014 10:18 AM, Risker wrote:
The most obvious one is automatic signing of comments, and it is something that we have technically been able to impose for years;
sinebot
didn't come into existence in a vacuum.
I suppose that's a philosophical divergence between us then - that sinebot even needs to exist to me is demonstration that the system is broken.
You say that discussion isn't all that much harder than editing
content.
Even if I agreed with that (and I do not, edit conflicts in articles are much rarer than on talk pages - and usually easier to sort out), that's not a *good* thing!
Participating in discussion should be much, *much* easier than editing articles: encouraging newbies to seek help and participate in the community *before* diving in anything but trivial article edits would
be
an immensely powerful retention tool!
(Which isn't to say that editing articles doesn't *also* need a lot of help - but that's a different project).
-- Marc
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org javascript:; <
https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wi...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org javascript:;
?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 javascript:; ?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
Facebook?
So tell me, how do you explain to new Facebook users about the different levels of "privacy"? Seems to me that I'm constantly hearing about people having a lot of problems with that, especially since it's supposed to be a key site feature.
I'm with you about indenting, it's always been something strange. But signing posts is very natural for a lot of people, and many, many online sites encourage the development of "canned signature lines" - just as we do with preferences, although we put more constraints on them generally.
Indeed, the majority of people in this thread have signed their posts. Indeed, Jon Davies' "+1" in response to this post had a 588-character signature line, presumably added to his mail client preferences.
Risker/Anne
On 8 September 2014 11:43, Ziko van Dijk zvandijk@gmail.com wrote:
Hello,
a) This discussion actually belongs to a talk page on Meta or Mediawiki.org, for example :-)
b) All my experience in teaching Wikipedia tells me that the talk page system is absolutely outdated and inappropriate. It is, sorry to use this word, *ridiculous* that you have to teach people how to communicate technically in Wikipedia. I never had to explain to someone how to do that on Facebook...
As other people have pointed it out already, if you are already accustomed to the Wikipedia user interface for a longer time, you might find it difficult to fully understand what is the problem for newbies. And how big this is a problem, and how important it is to solve this problem.
Kind regards Ziko
Am Montag, 8. September 2014 schrieb Risker :
Well, I think that the "article editing" project (i.e., VE) has a huge potential for also resolving a lot of discussion space issues. I don't
see
tacking on yet another UI as being a positive for new editor introduction or retention, and cannot think of another significant site that has two such wildly divergent interfaces (one very flexible and the other very rigid in structure), except perhaps in the mobile vs. desktop situation.
I dunno, Marc. There are different expectations about signature,
depending
on the target group. We still have people being freaked out that article histories contain their username or IP (a form of automatic signature),
so
I'm not convinced that there's an expectation on the part of new users
that
anything they write anywhere will automatically be signed.
Risker/Anne
On 8 September 2014 10:24, Marc A. Pelletier <marc@uberbox.org javascript:;> wrote:
On 09/08/2014 10:18 AM, Risker wrote:
The most obvious one is automatic signing of comments, and it is something that we have technically been able to impose for years;
sinebot
didn't come into existence in a vacuum.
I suppose that's a philosophical divergence between us then - that sinebot even needs to exist to me is demonstration that the system is broken.
You say that discussion isn't all that much harder than editing
content.
Even if I agreed with that (and I do not, edit conflicts in articles are much rarer than on talk pages - and usually easier to sort out), that's not a *good* thing!
Participating in discussion should be much, *much* easier than editing articles: encouraging newbies to seek help and participate in the community *before* diving in anything but trivial article edits would
be
an immensely powerful retention tool!
(Which isn't to say that editing articles doesn't *also* need a lot of help - but that's a different project).
-- Marc
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org javascript:; <
https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wi...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org javascript:;
?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 javascript:; ?subject=unsubscribe>
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
I don't know how many people here remember their first discussion on WP, but I do. Probably because it was less than 6 months ago. :)
My first impression was "you have got to be kidding me". I was annoyed I had to learn a new markup dialect, but that didn't deter me. Since I had some experience with wiki software when it was still cool about a decade ago, I chalked it up to the Weltanschauung that a wiki can do almost anything. I've always thought that there is a clause missing from this mindset: "and 99% of that it does poorly". I think that discussions easily find themselves in that 99%. But I wonder if there is a way that Flow can sit on top of wiki markup; many document oriented databases back discussion software, so why can't we reuse all the work done in formatting, version, and handling conflicts for discussions? Is it possible that discussions can be implemented without changing the data layer at all?
FWIW, I signed my first comment by hand. I missed the comments about sigs in the wikitext editor interface. If it weren't for my family situation, I'm pretty sure I would have bailed. In any case, it was much easier to engage at WO, and that was partly- but not mostly- due to the fact that they run discussion software over there.
,Wil
On Mon, Sep 8, 2014 at 7:24 AM, Marc A. Pelletier marc@uberbox.org wrote:
On 09/08/2014 10:18 AM, Risker wrote:
The most obvious one is automatic signing of comments, and it is something that we have technically been able to impose for years; sinebot didn't come into existence in a vacuum.
I suppose that's a philosophical divergence between us then - that sinebot even needs to exist to me is demonstration that the system is broken.
You say that discussion isn't all that much harder than editing content. Even if I agreed with that (and I do not, edit conflicts in articles are much rarer than on talk pages - and usually easier to sort out), that's not a *good* thing!
Participating in discussion should be much, *much* easier than editing articles: encouraging newbies to seek help and participate in the community *before* diving in anything but trivial article edits would be an immensely powerful retention tool!
(Which isn't to say that editing articles doesn't *also* need a lot of help - but that's a different project).
-- Marc
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 Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair wllm@wllm.com wrote:
FWIW, I signed my first comment by hand. I missed the comments about sigs in the wikitext editor interface. If it weren't for my family situation, I'm pretty sure I would have bailed. In any case, it was much easier to engage at WO, and that was partly- but not mostly- due to the fact that they run discussion software over there.
,Wil
This - signing by hand - is pretty much a universal experience for new users, myself included.
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=p...
On Sep 10, 2014 5:11 AM, "Keegan Peterzell" keegan.wiki@gmail.com wrote:
On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair wllm@wllm.com wrote:
FWIW, I signed my first comment by hand. I missed the comments about sigs in the wikitext editor interface. If it weren't for my family situation, I'm pretty sure I would have bailed. In any case, it was much easier to engage at WO, and that was partly- but not mostly- due to the fact that they run discussion software over there.
,Wil
This - signing by hand - is pretty much a universal experience for new users, myself included.
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=p...
-- ~Keegan
I'm not saying that isn't crap and unwelcoming: it is, and it deters new users. But it's hardly the end of the world either. By signing the wrong way no real harm is done, if someone just tells you about the option to use ~~~~
It's crap and archaic and should be fixed, but it's also an example of the idea that there are no mistakes on a wiki. So you did something not right? Great, that means you contributed. So we fix it (collaboratively) and improve your contribution, no harm done.
That said, auto sign and a reply button would be a *whole* lot friendlier than what we have now, and would be great improvements over the current situation.
Flow definitely has a reply button, and automatic signing as well, but I can't help but think that just those features in isolation would be better then completely overhauling talk pages.
--Martijn
This is my personal email address. Everything sent from this email address is in a personal capacity. _______________________________________________ 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. When you look at talk pages in isolation, you look at them on a computer screen. A mobile or tablet screen is increasingly not used in isolation. It is where we find our new users and editors. We cannot afford to ignore them; they are our future. This is why tinkering with talk pages is not an option. Moving away from talk pages because of mobiles and tablets is the killer reason why we need to move away from talk pages.
It is a killer reason because it makes all arguments to the contrary pale away. Thanks, GerardM
On 10 September 2014 09:20, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sep 10, 2014 5:11 AM, "Keegan Peterzell" keegan.wiki@gmail.com wrote:
On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair wllm@wllm.com wrote:
FWIW, I signed my first comment by hand. I missed the comments about sigs in the wikitext editor interface. If it weren't for my family situation, I'm pretty sure I would have bailed. In any case, it was much easier to engage at WO, and that was partly- but not mostly- due to the fact that they run discussion software over there.
,Wil
This - signing by hand - is pretty much a universal experience for new users, myself included.
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=p...
-- ~Keegan
I'm not saying that isn't crap and unwelcoming: it is, and it deters new users. But it's hardly the end of the world either. By signing the wrong way no real harm is done, if someone just tells you about the option to use
It's crap and archaic and should be fixed, but it's also an example of the idea that there are no mistakes on a wiki. So you did something not right? Great, that means you contributed. So we fix it (collaboratively) and improve your contribution, no harm done. That said, auto sign and a reply button would be a *whole* lot friendlier than what we have now, and would be great improvements over the current situation. Flow definitely has a reply button, and automatic signing as well, but I can't help but think that just those features in isolation would be better then completely overhauling talk pages. --Martijn > > This is my personal email address. Everything sent from this email address > is in a personal capacity. > _______________________________________________ > 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>
On Sep 10, 2014 9:35 AM, "Gerard Meijssen" gerard.meijssen@gmail.com wrote:
Hoi. When you look at talk pages in isolation, you look at them on a computer screen. A mobile or tablet screen is increasingly not used in isolation.
I'm not sure what you mean by this.
It
is where we find our new users and editors. We cannot afford to ignore them; they are our future. This is why tinkering with talk pages is not an option. Moving away from talk pages because of mobiles and tablets is the killer reason why we need to move away from talk pages.
It is a killer reason because it makes all arguments to the contrary pale away. Thanks, GerardM
What I find most painful about talk pages on mobile (on the desktop skin, because so far I've been too impatient to find talk pages and edit functionality on mobile) have been that editing huge text areas really sucks (the scrolling and positioning the cursor is a huge pain). This is not limited to talk pages by the way, but is identical for mainspace pages.
A reply button that inserts an isolated comment at the correct indentation level would fix that. Am I overlooking stuff?
On 10 September 2014 09:20, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sep 10, 2014 5:11 AM, "Keegan Peterzell" keegan.wiki@gmail.com
wrote:
On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair wllm@wllm.com wrote:
FWIW, I signed my first comment by hand. I missed the comments about sigs in the wikitext editor interface. If it weren't for my family situation, I'm pretty sure I would have bailed. In any case, it was much easier to engage at WO, and that was partly- but not mostly-
due
to the fact that they run discussion software over there.
,Wil
This - signing by hand - is pretty much a universal experience for
new
users, myself included.
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=p...
-- ~Keegan
I'm not saying that isn't crap and unwelcoming: it is, and it deters new users. But it's hardly the end of the world either. By signing the wrong way no real harm is done, if someone just tells you about the option to
use
It's crap and archaic and should be fixed, but it's also an example of
the
idea that there are no mistakes on a wiki. So you did something not
right?
Great, that means you contributed. So we fix it (collaboratively) and improve your contribution, no harm done.
That said, auto sign and a reply button would be a *whole* lot
friendlier
than what we have now, and would be great improvements over the current situation.
Flow definitely has a reply button, and automatic signing as well, but I can't help but think that just those features in isolation would be
better
then completely overhauling talk pages.
--Martijn
This is my personal email address. Everything sent from this email
address
is in a personal capacity. _______________________________________________ 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
Hoi, I expected that it was obvious... Arguments that are based on desktop experiences are futile because the desktop experience is the lesser of two evils. The desktop experience is already bad, the experience on mobiles and tablets is much worse it is intolerably unusable,
Yes, you are overlooking stuff when you only consider inserting an isolated comment that may help. That is not the only problem and not even the main problem. Reading and analysing talk pages is already next to impossible in this environment therefore inserting an isolated comment does not help enough to make the experience at least bearable. Thanks, GerardM
On 10 September 2014 09:47, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sep 10, 2014 9:35 AM, "Gerard Meijssen" gerard.meijssen@gmail.com wrote:
Hoi. When you look at talk pages in isolation, you look at them on a computer screen. A mobile or tablet screen is increasingly not used in isolation.
I'm not sure what you mean by this.
It
is where we find our new users and editors. We cannot afford to ignore them; they are our future. This is why tinkering with talk pages is not
an
option. Moving away from talk pages because of mobiles and tablets is the killer reason why we need to move away from talk pages.
It is a killer reason because it makes all arguments to the contrary pale away. Thanks, GerardM
What I find most painful about talk pages on mobile (on the desktop skin, because so far I've been too impatient to find talk pages and edit functionality on mobile) have been that editing huge text areas really sucks (the scrolling and positioning the cursor is a huge pain). This is not limited to talk pages by the way, but is identical for mainspace pages.
A reply button that inserts an isolated comment at the correct indentation level would fix that. Am I overlooking stuff?
On 10 September 2014 09:20, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sep 10, 2014 5:11 AM, "Keegan Peterzell" keegan.wiki@gmail.com
wrote:
On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair wllm@wllm.com wrote:
FWIW, I signed my first comment by hand. I missed the comments
about
sigs in the wikitext editor interface. If it weren't for my family situation, I'm pretty sure I would have bailed. In any case, it was much easier to engage at WO, and that was partly- but not mostly-
due
to the fact that they run discussion software over there.
,Wil
This - signing by hand - is pretty much a universal experience for
new
users, myself included.
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=p...
-- ~Keegan
I'm not saying that isn't crap and unwelcoming: it is, and it deters
new
users. But it's hardly the end of the world either. By signing the
wrong
way no real harm is done, if someone just tells you about the option to
use
It's crap and archaic and should be fixed, but it's also an example ofthe
idea that there are no mistakes on a wiki. So you did something not
right?
Great, that means you contributed. So we fix it (collaboratively) and improve your contribution, no harm done.
That said, auto sign and a reply button would be a *whole* lot
friendlier
than what we have now, and would be great improvements over the current situation.
Flow definitely has a reply button, and automatic signing as well, but
I
can't help but think that just those features in isolation would be
better
then completely overhauling talk pages.
--Martijn
This is my personal email address. Everything sent from this email
address
is in a personal capacity. _______________________________________________ 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 _______________________________________________ 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 Wed, Sep 10, 2014 at 9:55 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, I expected that it was obvious... Arguments that are based on desktop experiences are futile because the desktop experience is the lesser of two evils. The desktop experience is already bad, the experience on mobiles and tablets is much worse it is intolerably unusable,
I meant I didn't understand what you meant by "A mobile or tablet screen is increasingly not used in isolation."
Yes, you are overlooking stuff when you only consider inserting an isolated comment that may help. That is not the only problem and not even the main problem. Reading and analysing talk pages is already next to impossible in this environment therefore inserting an isolated comment does not help enough to make the experience at least bearable. Thanks, GerardM
Yeah, reading long intricate discussion on mobile sucks, but I'm not sure how Flow will help combat that - I'm very open to being shown a wider perspective. I'm still convinced that the primary difficulty in reading and analyzing long, intricate, branching discussions on mobile is caused by them being long, branching and intricate, not due to any software or rendering issues.
On 10 September 2014 09:47, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sep 10, 2014 9:35 AM, "Gerard Meijssen" gerard.meijssen@gmail.com wrote:
Hoi. When you look at talk pages in isolation, you look at them on a
computer
screen. A mobile or tablet screen is increasingly not used in
isolation.
I'm not sure what you mean by this.
It
is where we find our new users and editors. We cannot afford to ignore them; they are our future. This is why tinkering with talk pages is not
an
option. Moving away from talk pages because of mobiles and tablets is
the
killer reason why we need to move away from talk pages.
It is a killer reason because it makes all arguments to the contrary
pale
away. Thanks, GerardM
What I find most painful about talk pages on mobile (on the desktop skin, because so far I've been too impatient to find talk pages and edit functionality on mobile) have been that editing huge text areas really sucks (the scrolling and positioning the cursor is a huge pain). This is not limited to talk pages by the way, but is identical for mainspace
pages.
A reply button that inserts an isolated comment at the correct
indentation
level would fix that. Am I overlooking stuff?
On 10 September 2014 09:20, Martijn Hoekstra <
martijnhoekstra@gmail.com>
wrote:
On Sep 10, 2014 5:11 AM, "Keegan Peterzell" keegan.wiki@gmail.com
wrote:
On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair wllm@wllm.com
wrote:
FWIW, I signed my first comment by hand. I missed the comments
about
sigs in the wikitext editor interface. If it weren't for my
family
situation, I'm pretty sure I would have bailed. In any case, it
was
much easier to engage at WO, and that was partly- but not mostly-
due
to the fact that they run discussion software over there.
,Wil
This - signing by hand - is pretty much a universal experience for
new
users, myself included.
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=p...
-- ~Keegan
I'm not saying that isn't crap and unwelcoming: it is, and it deters
new
users. But it's hardly the end of the world either. By signing the
wrong
way no real harm is done, if someone just tells you about the option
to
use
It's crap and archaic and should be fixed, but it's also an exampleof
the
idea that there are no mistakes on a wiki. So you did something not
right?
Great, that means you contributed. So we fix it (collaboratively) and improve your contribution, no harm done.
That said, auto sign and a reply button would be a *whole* lot
friendlier
than what we have now, and would be great improvements over the
current
situation.
Flow definitely has a reply button, and automatic signing as well,
but
I
can't help but think that just those features in isolation would be
better
then completely overhauling talk pages.
--Martijn
Am 10.09.2014 09:56 schrieb "Gerard Meijssen" gerard.meijssen@gmail.com:
Hoi, I expected that it was obvious... Arguments that are based on desktop experiences are futile because the desktop experience is the lesser of
two
evils. The desktop experience is already bad, the experience on mobiles
and
tablets is much worse it is intolerably unusable,
Yes, you are overlooking stuff when you only consider inserting an
isolated
comment that may help. That is not the only problem and not even the main problem. Reading and analysing talk pages is already next to impossible in this environment therefore inserting an isolated comment does not help enough to make the experience at least bearable. Thanks, GerardM
What do you propose to make talk pages easier to read and analyse?
On 10 September 2014 09:47, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sep 10, 2014 9:35 AM, "Gerard Meijssen" gerard.meijssen@gmail.com wrote:
Hoi. When you look at talk pages in isolation, you look at them on a
computer
screen. A mobile or tablet screen is increasingly not used in
isolation.
I'm not sure what you mean by this.
It
is where we find our new users and editors. We cannot afford to ignore them; they are our future. This is why tinkering with talk pages is
not
an
option. Moving away from talk pages because of mobiles and tablets is
the
killer reason why we need to move away from talk pages.
It is a killer reason because it makes all arguments to the contrary
pale
away. Thanks, GerardM
What I find most painful about talk pages on mobile (on the desktop
skin,
because so far I've been too impatient to find talk pages and edit functionality on mobile) have been that editing huge text areas really sucks (the scrolling and positioning the cursor is a huge pain). This is not limited to talk pages by the way, but is identical for mainspace
pages.
A reply button that inserts an isolated comment at the correct
indentation
level would fix that. Am I overlooking stuff?
On 10 September 2014 09:20, Martijn Hoekstra <
martijnhoekstra@gmail.com>
wrote:
On Sep 10, 2014 5:11 AM, "Keegan Peterzell" keegan.wiki@gmail.com
wrote:
On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair wllm@wllm.com
wrote:
FWIW, I signed my first comment by hand. I missed the comments
about
sigs in the wikitext editor interface. If it weren't for my
family
situation, I'm pretty sure I would have bailed. In any case, it
was
much easier to engage at WO, and that was partly- but not
mostly-
due
to the fact that they run discussion software over there.
,Wil
This - signing by hand - is pretty much a universal experience
for
new
users, myself included.
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=p...
-- ~Keegan
I'm not saying that isn't crap and unwelcoming: it is, and it deters
new
users. But it's hardly the end of the world either. By signing the
wrong
way no real harm is done, if someone just tells you about the
option to
use
It's crap and archaic and should be fixed, but it's also an example
of
the
idea that there are no mistakes on a wiki. So you did something not
right?
Great, that means you contributed. So we fix it (collaboratively)
and
improve your contribution, no harm done.
That said, auto sign and a reply button would be a *whole* lot
friendlier
than what we have now, and would be great improvements over the
current
situation.
Flow definitely has a reply button, and automatic signing as well,
but
I
can't help but think that just those features in isolation would be
better
then completely overhauling talk pages.
--Martijn
This is my personal email address. Everything sent from this email
address
is in a personal capacity. _______________________________________________ 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 _______________________________________________ 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
On 09/10/2014 11:45 AM, MF-Warburg wrote:
What do you propose to make talk pages easier to read and analyse?
That's a hard question, and I expect one where a lot of UX experimentation will need to take place before we know.
But one thing /is/ known: it's going to be feasible iff the data is actually structured like a discussion; not a flat document that may or may not be perhaps parsable as something vaguely discussion-like.
-- Marc
On 10 September 2014 16:48, Marc A. Pelletier marc@uberbox.org wrote:
On 09/10/2014 11:45 AM, MF-Warburg wrote:
What do you propose to make talk pages easier to read and analyse?
That's a hard question, and I expect one where a lot of UX experimentation will need to take place before we know. But one thing /is/ known: it's going to be feasible iff the data is actually structured like a discussion; not a flat document that may or may not be perhaps parsable as something vaguely discussion-like.
Making entering text on a phone a process not made entirely of pain will be interesting.
- d.
On 09/10/2014 11:53 AM, David Gerard wrote:
Making entering text on a phone a process not made entirely of pain will be interesting.
I don't think it's the text proper that's the issue so much as the navigation and (often) markup that uses a great deal of punctuation that phone interfaces were really not meant to make easy to use.
Clearly, text discussion with people on phones is a known use case - and arguably the primary use of those things nowadays - so it's not like we're blazing new trails there. Editing /documents/ is a different beast altogether and waiting to solve that to fix discussions is, IMO, putting the cart before the horses.
-- Marc
On 10 September 2014 17:29, Marc A. Pelletier marc@uberbox.org wrote:
Clearly, text discussion with people on phones is a known use case - and arguably the primary use of those things nowadays - so it's not like we're blazing new trails there. Editing /documents/ is a different beast altogether and waiting to solve that to fix discussions is, IMO, putting the cart before the horses.
Big fingers, small phone :-) Yeah, less punctuation will help.
- d.
Hoi, Ditch talk pages asap. In my opinion tinkering is mostly a waste of effort. Thanks, GerardM
On 10 September 2014 17:45, MF-Warburg mfwarburg@googlemail.com wrote:
Am 10.09.2014 09:56 schrieb "Gerard Meijssen" gerard.meijssen@gmail.com:
Hoi, I expected that it was obvious... Arguments that are based on desktop experiences are futile because the desktop experience is the lesser of
two
evils. The desktop experience is already bad, the experience on mobiles
and
tablets is much worse it is intolerably unusable,
Yes, you are overlooking stuff when you only consider inserting an
isolated
comment that may help. That is not the only problem and not even the main problem. Reading and analysing talk pages is already next to impossible
in
this environment therefore inserting an isolated comment does not help enough to make the experience at least bearable. Thanks, GerardM
What do you propose to make talk pages easier to read and analyse?
On 10 September 2014 09:47, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sep 10, 2014 9:35 AM, "Gerard Meijssen" gerard.meijssen@gmail.com wrote:
Hoi. When you look at talk pages in isolation, you look at them on a
computer
screen. A mobile or tablet screen is increasingly not used in
isolation.
I'm not sure what you mean by this.
It
is where we find our new users and editors. We cannot afford to
ignore
them; they are our future. This is why tinkering with talk pages is
not
an
option. Moving away from talk pages because of mobiles and tablets is
the
killer reason why we need to move away from talk pages.
It is a killer reason because it makes all arguments to the contrary
pale
away. Thanks, GerardM
What I find most painful about talk pages on mobile (on the desktop
skin,
because so far I've been too impatient to find talk pages and edit functionality on mobile) have been that editing huge text areas really sucks (the scrolling and positioning the cursor is a huge pain). This
is
not limited to talk pages by the way, but is identical for mainspace
pages.
A reply button that inserts an isolated comment at the correct
indentation
level would fix that. Am I overlooking stuff?
On 10 September 2014 09:20, Martijn Hoekstra <
martijnhoekstra@gmail.com>
wrote:
On Sep 10, 2014 5:11 AM, "Keegan Peterzell" <keegan.wiki@gmail.com
wrote:
On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair wllm@wllm.com
wrote:
> > FWIW, I signed my first comment by hand. I missed the comments
about
> sigs in the wikitext editor interface. If it weren't for my
family
> situation, I'm pretty sure I would have bailed. In any case, it
was
> much easier to engage at WO, and that was partly- but not
mostly-
due
> to the fact that they run discussion software over there. > > ,Wil > > This - signing by hand - is pretty much a universal experience
for
new
users, myself included.
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=p...
-- ~Keegan
I'm not saying that isn't crap and unwelcoming: it is, and it
deters
new
users. But it's hardly the end of the world either. By signing the
wrong
way no real harm is done, if someone just tells you about the
option to
use
It's crap and archaic and should be fixed, but it's also an exampleof
the
idea that there are no mistakes on a wiki. So you did something not
right?
Great, that means you contributed. So we fix it (collaboratively)
and
improve your contribution, no harm done.
That said, auto sign and a reply button would be a *whole* lot
friendlier
than what we have now, and would be great improvements over the
current
situation.
Flow definitely has a reply button, and automatic signing as well,
but
I
can't help but think that just those features in isolation would be
better
then completely overhauling talk pages.
--Martijn
This is my personal email address. Everything sent from this
address
is in a personal capacity. _______________________________________________ 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 _______________________________________________ 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
Gerard, please think of the consequences of what you're proposing. There are features at talk pages (detailed watchlists, incremental diffs, true deletion of content) that allow editors and admins to detect and combat vandalism and remove BLP sensible material and libel; features which are not available in Flow as of today.
Leaving this material unchecked would expose the Foundation to legal risk. Would you allow that possibility so that editors can edit from mobile devices? I hope not, but that's exactly what you've suggested. The "tinkering" is needed so that the core functions are not lost in the process to deploy nice-to-have features (and yes, mobile editing is in the "nice to have" category if you compare it to finding and removing oversightable material of sensible nature).
On 10 September 2014 18:59, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Ditch talk pages asap. In my opinion tinkering is mostly a waste of effort. Thanks, GerardM
On 09/10/2014 01:25 PM, Diego Moya wrote:
[...] that allow editors and admins to detect and combat vandalism and remove BLP sensible material and libel; features which are not available in Flow as of today.
That is simply not true, at last as of the master branch. Topics and replies can be hidden, deleted, or suppressed -- the same things that can be done to talk page revisions at this moment.
Indeed, the Flow equivalent is even superior in at least one aspect: given that the actual comments are isolated and not differences between revision, supressing a comment containing libel that has gone unnoticed for a bit does *not* cause the history of the conversation to be mangled because intermediate diffs have to be suppressed as well.
-- Marc
On 10 September 2014 18:29, Marc A. Pelletier marc@uberbox.org wrote:
Indeed, the Flow equivalent is even superior in at least one aspect: given that the actual comments are isolated and not differences between revision, supressing a comment containing libel that has gone unnoticed for a bit does *not* cause the history of the conversation to be mangled because intermediate diffs have to be suppressed as well.
That's a second "useful to experienced regulars" feature. I recommend keeping a list :-)
- d.
On 10 September 2014 19:29, Marc A. Pelletier marc@uberbox.org wrote:
On 09/10/2014 01:25 PM, Diego Moya wrote:
[...] that allow editors and admins to detect and combat vandalism and remove BLP sensible material and libel; features which are not available in Flow as of today.
That is simply not true, at last as of the master branch. Topics and replies can be hidden, deleted, or suppressed -- the same things that can be done to talk page revisions at this moment.
Take a look at this deleted topic at the test page that was deployed at en.wiki: https://en.wikipedia.org/wiki/Topic:S214uoczkp47cfsx
Can you see its content? I definitely can. Had it contained sensible information, admins couldn't have done anything to remove it from sight. (I know this because they've tried): https://en.wikipedia.org/wiki/Wikipedia_talk:Flow#Deletion_of_Wikipedia:Teah...
Indeed, the Flow equivalent is even superior in at least one aspect:
given that the actual comments are isolated and not differences between revision, supressing a comment containing libel that has gone unnoticed for a bit does *not* cause the history of the conversation to be mangled because intermediate diffs have to be suppressed as well.
-- Marc
That would be a good thing if it worked. That a feature has been implemented doesn't mean that it works as intended.
On 09/10/2014 01:41 PM, Diego Moya wrote:
Take a look at this deleted topic at the test page that was deployed at en.wiki: https://en.wikipedia.org/wiki/Topic:S214uoczkp47cfsx
As far as I can tell, you could see it because it never /was/ deleted. I just deleted it, can you still see it?
I think what you see is the odd interaction with deleting the "page" that a flow board lived at -- which may not even be a supported scenario (or, at the very least, might need work).
-- Marc
Right, it's gone now. However that page survived the attempts of removal from several administrators who positively wanted to get rid of any trace of the "Wikipedia:Teahouse/Questions/Flow test" page, so I don't know what it says about the discoverability of those features :-/
It's disturbing to think what could have happened, had it been deployed at large scale with such undesirable interaction undetected. It may have been a problem of miscommunication and change of the standard procedure (which the admins tried, but didn't have the expected result) rather than a lack of features, but we should make sure that it cannot happen at a wide-scale deployment, and that all users get informed of how to use the features before giving them access to the tool or when they try to achieve the result through the old ways.
On 10 September 2014 19:58, Marc A. Pelletier marc@uberbox.org wrote:
On 09/10/2014 01:41 PM, Diego Moya wrote:
Take a look at this deleted topic at the test page that was deployed at en.wiki: https://en.wikipedia.org/wiki/Topic:S214uoczkp47cfsx
As far as I can tell, you could see it because it never /was/ deleted. I just deleted it, can you still see it?
I think what you see is the odd interaction with deleting the "page" that a flow board lived at -- which may not even be a supported scenario (or, at the very least, might need work).
-- Marc
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, Asap stands for "as soon as possible". It is obvious that there I do not like the talk pages at all. That does not mean that it makes sense to replace them tomorrow.
I want us to cut the crap. Absolutely get rid of talk pages and understand what it is EXACTLY what the cost benefit is of such a change. When you talk about "detailed watchlists" in the context of Talk pages I have no clue what you are on about. It does not make sense to me at all.
When a specific way of working insists on talk pages, it means that the associated workflow has to be revisited and changed with urgency. It cannot be permitted that special interests take the whole of the much needed change hostage. "Leaving this material unchecked ..." is FUD. It is not an argument that prevents change, at most it means that a different mechanism has to be designed for that special interest. Thanks, GerardM
On 10 September 2014 19:25, Diego Moya dialmove@gmail.com wrote:
Gerard, please think of the consequences of what you're proposing. There are features at talk pages (detailed watchlists, incremental diffs, true deletion of content) that allow editors and admins to detect and combat vandalism and remove BLP sensible material and libel; features which are not available in Flow as of today.
Leaving this material unchecked would expose the Foundation to legal risk. Would you allow that possibility so that editors can edit from mobile devices? I hope not, but that's exactly what you've suggested. The "tinkering" is needed so that the core functions are not lost in the process to deploy nice-to-have features (and yes, mobile editing is in the "nice to have" category if you compare it to finding and removing oversightable material of sensible nature).
On 10 September 2014 18:59, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Ditch talk pages asap. In my opinion tinkering is mostly a waste of
effort.
Thanks, GerardM
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 10 September 2014 18:54, Gerard Meijssen gerard.meijssen@gmail.com wrote:
When a specific way of working insists on talk pages, it means that the associated workflow has to be revisited and changed with urgency. It cannot be permitted that special interests take the whole of the much needed change hostage. "Leaving this material unchecked ..." is FUD. It is not an argument that prevents change, at most it means that a different mechanism has to be designed for that special interest.
You are entirely correct. Nevertheless, the change still needs to be accepted by the crusty old editors who are used to the old ways. So we're now at the stage of: "how do we make experienced editors want and demand this?"
- d.
David's really on to something here. What is the "killer app" of the platform? If we think through requirements some, we might identify just one or two features of Flow that almost all editors would find compelling. This may be enough to shift lots of criticism from "I don't want Flow because of this use case" to "I want Flow because of this killer feature, but what can we do about this use case I'm concerned about?"
It may not be apparent on first glance. Candidates for me would include well structured threaded discussions and no edit conflicts, but these don't seem to be enough for a lot of editors- particularly if they have to give up some other features that current talk pages have to offer that they find more compelling.
For those of you who are holding out on support for Flow because there isn't anything that you feel provides enough value to tip the scales in favor of Flow vs. current talk pages, can you think of any one feature- or maybe a small collection of features- that would?
,Wil
On Wed, Sep 10, 2014 at 11:00 AM, David Gerard dgerard@gmail.com wrote:
On 10 September 2014 18:54, Gerard Meijssen gerard.meijssen@gmail.com wrote:
When a specific way of working insists on talk pages, it means that the associated workflow has to be revisited and changed with urgency. It cannot be permitted that special interests take the whole of the much needed change hostage. "Leaving this material unchecked ..." is FUD. It is not an argument that prevents change, at most it means that a different mechanism has to be designed for that special interest.
You are entirely correct. Nevertheless, the change still needs to be accepted by the crusty old editors who are used to the old ways. So we're now at the stage of: "how do we make experienced editors want and demand this?"
- d.
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
In my case, improvements should come from the side of collaborative editing, not conversation. The possibility that Tim introduced to have long-term embedded comments and real-time collaboration at articles and talk-page scratchboards would be - almost a killer app, as those are clearly impossible with plain mediawiki.
Structured conversations is not particularly appealing to us because we already have those in the current platform, and have mastered them; and having the software forcing the structure is actually limiting to us, not really something that we would crave for. The end of edit conflicts would be nice to have, but I've seen suggestions that could it make reasonably viable at mediawiki for most situations, so it's not a huge advantage either.
On 10 September 2014 22:40, Wil Sinclair wllm@wllm.com wrote:
David's really on to something here. What is the "killer app" of the platform? If we think through requirements some, we might identify just one or two features of Flow that almost all editors would find compelling. This may be enough to shift lots of criticism from "I don't want Flow because of this use case" to "I want Flow because of this killer feature, but what can we do about this use case I'm concerned about?"
It may not be apparent on first glance. Candidates for me would include well structured threaded discussions and no edit conflicts, but these don't seem to be enough for a lot of editors- particularly if they have to give up some other features that current talk pages have to offer that they find more compelling.
For those of you who are holding out on support for Flow because there isn't anything that you feel provides enough value to tip the scales in favor of Flow vs. current talk pages, can you think of any one feature- or maybe a small collection of features- that would?
,Wil
On Wed, Sep 10, 2014 at 11:00 AM, David Gerard dgerard@gmail.com wrote:
On 10 September 2014 18:54, Gerard Meijssen gerard.meijssen@gmail.com wrote:
When a specific way of working insists on talk pages, it means that the associated workflow has to be revisited and changed with urgency. It cannot be permitted that special interests take the whole of the much needed change hostage. "Leaving this material unchecked ..." is FUD. It is not an argument that prevents change, at most it means that a different mechanism has to be designed for that special interest.
You are entirely correct. Nevertheless, the change still needs to be accepted by the crusty old editors who are used to the old ways. So we're now at the stage of: "how do we make experienced editors want and demand this?"
- d.
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
On Wed, Sep 10, 2014 at 7:54 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Asap stands for "as soon as possible". It is obvious that there I do not like the talk pages at all. That does not mean that it makes sense to replace them tomorrow.
I want us to cut the crap. Absolutely get rid of talk pages and understand what it is EXACTLY what the cost benefit is of such a change. When you talk about "detailed watchlists" in the context of Talk pages I have no clue what you are on about. It does not make sense to me at all.
When a specific way of working insists on talk pages, it means that the associated workflow has to be revisited and changed with urgency. It cannot be permitted that special interests take the whole of the much needed change hostage. "Leaving this material unchecked ..." is FUD. It is not an argument that prevents change, at most it means that a different mechanism has to be designed for that special interest. Thanks, GerardM
Gerard,
It would really help me if you would go a little lower on the hyperbole. As soon as possible is indeed not tomorrow. It's today. Only we both agree that would be a very bad idea. What you probably mean is "As soon as a reasonable replacement for processes and talk pages can be found" - but when I phrase it like that, it becomes open for discussion what that reasonable replacement could be. It makes it very hard to keep taking your posts seriously if you keep speaking in such hyperbole.
--Martijn
On 10 September 2014 19:25, Diego Moya dialmove@gmail.com wrote:
Gerard, please think of the consequences of what you're proposing. There are features at talk pages (detailed watchlists, incremental diffs, true deletion of content) that allow editors and admins to detect and combat vandalism and remove BLP sensible material and libel; features which are not available in Flow as of today.
Leaving this material unchecked would expose the Foundation to legal risk. Would you allow that possibility so that editors can edit from mobile devices? I hope not, but that's exactly what you've suggested. The "tinkering" is needed so that the core functions are not lost in the process to deploy nice-to-have features (and yes, mobile editing is in the "nice to have" category if you compare it to finding and removing oversightable material of sensible nature).
On 10 September 2014 18:59, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Ditch talk pages asap. In my opinion tinkering is mostly a waste of
effort.
Thanks, GerardM
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
On Wed, Sep 10, 2014 at 7:54 PM, Gerard Meijssen gerard.meijssen@gmail.com
wrote:
Hoi, Asap stands for "as soon as possible". It is obvious that there I do not like the talk pages at all. That does not mean that it makes sense to replace them tomorrow.
I want us to cut the crap. Absolutely get rid of talk pages and understand what it is EXACTLY what the cost benefit is of such a change. When you talk about "detailed watchlists" in the context of Talk pages I have no clue what you are on about. It does not make sense to me at all.
When a specific way of working insists on talk pages, it means that the associated workflow has to be revisited and changed with urgency. It cannot be permitted that special interests take the whole of the much needed change hostage. "Leaving this material unchecked ..." is FUD. It is not an argument that prevents change, at most it means that a different mechanism has to be designed for that special interest. Thanks, GerardM
Gerard,
It would really help me if you would go a little lower on the hyperbole. As soon as possible is indeed not tomorrow. It's today. Only we both agree that would be a very bad idea. What you probably mean is "As soon as a reasonable replacement for processes and talk pages can be found" - but when I phrase it like that, it becomes open for discussion what that reasonable replacement could be. It makes it very hard to keep taking your posts seriously if you keep speaking in such hyperbole.
--Martijn
I've got to +1 Martijn on this one. But I'm a little more concerned with "cut the crap," because "the crap" could easily be interpreted as other people's ideas. While this kind of language is rather mild compared to some other posts I've seen to this list, I think that it is imperative that we all stay constructive and open to each other's ideas when we talk about Flow. Flow needs a deep and broad community consensus to what would probably amount to the biggest single change in the history of the project for the day-to-day collaboration amongst editors that is so vital to our success. Let's face it, the kind of challenge ahead is something this community hasn't surmounted in the last few years, and so far people on this list has done a great job staying constructive in the discussion.
I want discussion oriented software to happen. Gerard, your messages have great substance that can get us closer to our goal. Please don't push it out of reach because of something as easy to change as style. Thanks in advance for considering the rest of us who'd like to see this happen in your posts.
And thanks for the forbearance of everyone else. The sooner meta-discussions about the nature of our discourse are unnecessary, the happier I'll be, as I'll feel like I can afford to spend all of my post allowance on the actual substance of the issues.
,Wil
On 10 September 2014 19:54, Gerard Meijssen gerard.meijssen@gmail.com wrote:
I want us to cut the crap. Absolutely get rid of talk pages and understand what it is EXACTLY what the cost benefit is of such a change.
That should be known in advance, before removing the old mechanisms, not as a consequence of removing the tools that editors use. Those tools are in active use for a reason - if you remove the previous tools without a replacement in place, the tasks that depend upon them would cease to be performed.
When you talk about "detailed watchlists" in the context of Talk pages I have no clue what you are on about. It does not make sense to me at all.
If you don't understand what you're trying to get rid of, please don't be so eager to remove it. Detailed diffs at watchlists and wiki history are what allow experienced editors to keep track of changes to a huge volume of talk pages. They include: * edit summaries for each change that users make to the page * a quick link to the exact content of one edit (that can be set up to be read with a mouse hover, without having to navigate away from the list of changes) * summary of changes from the last visit, showing the exact changes that happened between two revisions - and nothing else.
Finding out quickly what exactly has been changed since the last time you visited a thread was a nightmare with LiquidThreads, and outright impossible with the current Flow design, yet it's an essential feature for reviewers and patrollers that have a huge number of watched pages - i.e. those editors that perform upkeep tasks and keep it reasonably clean of vandals and trolls. If we pulled the rug out and removed the tools they need to keep an eye upon destructive changes, those vital tasks to the project would be severely hurt.
When a specific way of working insists on talk pages, it means that the associated workflow has to be revisited and changed with urgency. It cannot be permitted that special interests take the whole of the much needed change hostage. "Leaving this material unchecked ..." is FUD. It is not an argument that prevents change, at most it means that a different mechanism has to be designed for that special interest.
For the record, I don't oppose replacing the old ways of working with some other mechanism to achieve the same goal that would require retraining the users. I'm opposed to replacing those *before* the new software is able to support them, as it would disrupt the project in the meantime, and there's a very real possibility that the new software could happen to not be up to the task, and that we would find it out only after the fact. "There's a chance the project may be destroyed" is not a threat that old-time editors make, it's a natural consequence of what would happen if you restrict their ability to keep the project afloat.
Hoi, What should be known in advance are the features that are important and how those features function in a workflow. During the development of software we work towards implementing such features and corresponding functionality. We may allow for partial implementation when it fulfills a need that is well isolated, in this way familiarity is developed in the community.
Ultimately the point when the whole is assessed for usability is when the software is considered ready. At that time a history for instance should be available that allows for understanding a conversation in a step by step way. It should allow admins to do their admin thing by removing/hiding/protecting content where applicable.
It should be obvious that when we do nothing the project is destroyed by its own inaction It is equally obvious that when the change process is not carefully managed, we may lose some people. Ultimately this is the lesser of two evils. The challenge is to move deliberately, be clear that not moving forward is no option and continuously invite comments from all our communities, particularly our communities where English is not well understood.
In this way we find show stoppers where they occur and work towards fixing them or circumventing the negative impact. Personally I find the challenge of moving the "other" languages the greatest risc. For many languages there will be no localisation of this functionality when the software is deemed ready. It is imho why the conversion script for LQT is vitally important; it will enable the use of Flow in translatewiki.net. Thanks, GerardM
On 11 September 2014 00:45, Diego Moya dialmove@gmail.com wrote:
On 10 September 2014 19:54, Gerard Meijssen gerard.meijssen@gmail.com wrote:
I want us to cut the crap. Absolutely get rid of talk pages and
understand
what it is EXACTLY what the cost benefit is of such a change.
That should be known in advance, before removing the old mechanisms, not as a consequence of removing the tools that editors use. Those tools are in active use for a reason - if you remove the previous tools without a replacement in place, the tasks that depend upon them would cease to be performed.
When you talk about "detailed watchlists" in the context of Talk pages I have no clue what you are on about. It does not make sense to me at all.
If you don't understand what you're trying to get rid of, please don't be so eager to remove it. Detailed diffs at watchlists and wiki history are what allow experienced editors to keep track of changes to a huge volume of talk pages. They include:
- edit summaries for each change that users make to the page
- a quick link to the exact content of one edit (that can be set up to
be read with a mouse hover, without having to navigate away from the list of changes)
- summary of changes from the last visit, showing the exact changes
that happened between two revisions - and nothing else.
Finding out quickly what exactly has been changed since the last time you visited a thread was a nightmare with LiquidThreads, and outright impossible with the current Flow design, yet it's an essential feature for reviewers and patrollers that have a huge number of watched pages
- i.e. those editors that perform upkeep tasks and keep it reasonably
clean of vandals and trolls. If we pulled the rug out and removed the tools they need to keep an eye upon destructive changes, those vital tasks to the project would be severely hurt.
When a specific way of working insists on talk pages, it means that the associated workflow has to be revisited and changed with urgency. It
cannot
be permitted that special interests take the whole of the much needed change hostage. "Leaving this material unchecked ..." is FUD. It is not
an
argument that prevents change, at most it means that a different
mechanism
has to be designed for that special interest.
For the record, I don't oppose replacing the old ways of working with some other mechanism to achieve the same goal that would require retraining the users. I'm opposed to replacing those *before* the new software is able to support them, as it would disrupt the project in the meantime, and there's a very real possibility that the new software could happen to not be up to the task, and that we would find it out only after the fact. "There's a chance the project may be destroyed" is not a threat that old-time editors make, it's a natural consequence of what would happen if you restrict their ability to keep the project afloat.
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
In case it's not clear enough in my sig, this is my personal opinion:
On Wed, Sep 10, 2014 at 12:20 AM, Martijn Hoekstra < martijnhoekstra@gmail.com> wrote:
On Sep 10, 2014 5:11 AM, "Keegan Peterzell" keegan.wiki@gmail.com wrote:
On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair wllm@wllm.com wrote:
FWIW, I signed my first comment by hand. I missed the comments about sigs in the wikitext editor interface. If it weren't for my family situation, I'm pretty sure I would have bailed. In any case, it was much easier to engage at WO, and that was partly- but not mostly- due to the fact that they run discussion software over there.
,Wil
This - signing by hand - is pretty much a universal experience for new users, myself included.
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=p...
-- ~Keegan
I'm not saying that isn't crap and unwelcoming: it is, and it deters new users. But it's hardly the end of the world either. By signing the wrong way no real harm is done, if someone just tells you about the option to use
It's crap and archaic and should be fixed, but it's also an example of the idea that there are no mistakes on a wiki. So you did something not right? Great, that means you contributed. So we fix it (collaboratively) and improve your contribution, no harm done.
I agree with you, Martjin. If you follow the cookie crumbs you'd see that I registered an account on the English Wikipedia /solely/ so I could sign a complaint about a resource I used and loved, and I thought it best to give respect back by registering and figuring out how to sign my complaint. I was also incredibly lucky as a n00b to have positive interactions, right from the get-go, which makes it a little more clear to me why I'm still around after all this time. I'm thirty-three years old, to me a nine-year unintentional commitment is a lifetime :)
I'm also aware, through my experiences through the past nine years, that my experience is Golden™, and I desperately wish all new users could have such an experience.
This kind of thing starts with software changes that break my workflow. I hate that. But to be fair, my workflow is ridiculous because the software is.
The steps I have to take to do the things that I do would, IMO, make a rational person cry :). I really don't understand the theory that new users have to go through the same experiences as I did, no matter how pleasant, again IMO, my experiences were. Hazing is an antiquated and unfruitful process. It only breaks people down to rebuild them in the image that you want, and that's contradictory to the individualism that Wikimedia promotes. I enjoy the fact that Wikimedia sites allow flexibility and customization on a personal account and institutional level. On the other hand, the world keeps moving and I stay in the same place unless I choose to go through the process of acceptance of a changing world. I do not consider the world changing to be something shoved down my throat; it's a reality of life.
I'd like to note that the following is my personal opinion, and any resemblance to the opinions of the Wikipedia community or any parts therof, Jimmy Wales, the NSA, the Dutch government, Y-combinator, the national library of Australia, the British Housewives' League, and/or any other opinion of any individual and/or organisation is purely coincidental. (am I doing this right?)
On Wed, Sep 10, 2014 at 10:28 AM, Keegan Peterzell keegan.wiki@gmail.com wrote:
In case it's not clear enough in my sig, this is my personal opinion:
On Wed, Sep 10, 2014 at 12:20 AM, Martijn Hoekstra < martijnhoekstra@gmail.com> wrote:
On Sep 10, 2014 5:11 AM, "Keegan Peterzell" keegan.wiki@gmail.com
wrote:
On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair wllm@wllm.com wrote:
FWIW, I signed my first comment by hand. I missed the comments about sigs in the wikitext editor interface. If it weren't for my family situation, I'm pretty sure I would have bailed. In any case, it was much easier to engage at WO, and that was partly- but not mostly- due to the fact that they run discussion software over there.
,Wil
This - signing by hand - is pretty much a universal experience for new users, myself included.
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=p...
-- ~Keegan
I'm not saying that isn't crap and unwelcoming: it is, and it deters new users. But it's hardly the end of the world either. By signing the wrong way no real harm is done, if someone just tells you about the option to
use
It's crap and archaic and should be fixed, but it's also an example ofthe
idea that there are no mistakes on a wiki. So you did something not
right?
Great, that means you contributed. So we fix it (collaboratively) and improve your contribution, no harm done.
I agree with you, Martjin. If you follow the cookie crumbs you'd see that I registered an account on the English Wikipedia /solely/ so I could sign a complaint about a resource I used and loved, and I thought it best to give respect back by registering and figuring out how to sign my complaint. I was also incredibly lucky as a n00b to have positive interactions, right from the get-go, which makes it a little more clear to me why I'm still around after all this time. I'm thirty-three years old, to me a nine-year unintentional commitment is a lifetime :)
I'm also aware, through my experiences through the past nine years, that my experience is Golden™, and I desperately wish all new users could have such an experience.
This kind of thing starts with software changes that break my workflow. I hate that. But to be fair, my workflow is ridiculous because the software is.
The steps I have to take to do the things that I do would, IMO, make a rational person cry :). I really don't understand the theory that new users have to go through the same experiences as I did, no matter how pleasant, again IMO, my experiences were.
Neither do I, really - which is why I support auto signing and a quick-reply button added to the current interface
Hazing is an antiquated and
unfruitful process. It only breaks people down to rebuild them in the image that you want, and that's contradictory to the individualism that Wikimedia promotes.
I think you're attacking a straw man. I certainly want new users to have a positive experience, and not, in your words haze them.
I enjoy the fact that Wikimedia sites allow flexibility and customization on a personal account and institutional level. On the other hand, the world keeps moving and I stay in the same place unless I choose to go through the process of acceptance of a changing world. I do not consider the world changing to be something shoved down my throat; it's a reality of life.
-- ~Keegan
https://en.wikipedia.org/wiki/User:Keegan
This is my personal email address. Everything sent from this email address is in a personal capacity. _______________________________________________ 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 8 September 2014 05:54, Marc A. Pelletier marc@uberbox.org wrote:
And yet, after over a decade of open-ended design through social convention, the end result is... our current talk pages. Perhaps another decade or two will be needed before that document-centric architecture gives us a half-decent discussion system?
Marc, I'm not arguing against having a discussion system. In fact I think having threaded comments happen by default is a great idea that will make the conversation interface far more usable, both on desktop and mobile (I agree with Gerard that the mobile editing experience is dreadful).
The problem I see is with having that discussion system as the 'only' option, making refactoring of conversations limited and difficult, and removing the open-ended and flexible platform we currently rely upon, when several important workflows and goals such as accountability and building new workflows for projects are based on the well understood capabilities of a wiki system.
The system I envision as a suitable, modern replacement would be based on proven enterprise collaboration platforms like Microsoft OneNote or Atlassian Confluence, which include discussion systems as modules integrated within the platform. I simply can't see the benefit of losing the collaboration capabilities of wiki software in favor of enforced structured discussion, when we can have both.
Now if Erik vision for the deeper than I give him credit for, and he is able to build a OneNote-like application on top of the suggested architecture for Flow, I will eat my words with an apology :-) However, that capability of the system should be better explained so that we can understand it and discuss its ramifications.
On 7 September 2014 23:53, Diego Moya dialmove@gmail.com wrote:
On 09/06/2014 17:06 PM, Marc A. Pelletier wrote:
On 09/06/2014 12:34 PM, Isarra Yos wrote:
if the designers do not even understand the basic principles behind a wiki, how can what is developed possibly suit our needs?
You're starting from the presumption that, for some unexplained reason, collaborative discussion benefits from being a wiki (as opposed to, you know, the actual content).
Wikipedia has been built using that platform. I'd say that's a very good reason to trust that the model is at least capable. :-)
Very many people, myself included, believe that a wiki page is an *atrocious* medium for discussion.
Sure, and I agree there are many way to improve how users are engaged into discussion and to keep it manageable. But what is missing from this conversation is the point that Wikipedia talk space is not *merely* a medium for discussion: there are other vital roles that may be hindered by a radical focus on conversation:
tl;dr version: there are times and places that Wikipedia discussion system needs to be a Microsoft OneNote, and Flow is building us a Twitter (minus the 140 characters limit).
- The talk space has a strong expectation that it serves as an
archive of all decisions taken in building the articles, i.e. to show how the sausages are made. The disembodied nature of Flow topics, which may be shown out of order and distributed to many boards, makes it hard to recover a sequential view of the conversations in order as they happened.
- Same thing for keeping user's behavior in check - policy
enforcement often requires that the reviewers can see exactly what the users saw when they performed some particular disruptive action, to assess whether it was made in good faith from incomplete information or a misunderstanding.
- Comment-based discussion is not the only way editors collaborate;
nor discussions are limited to users expressing their particular views at ordered, pre-defined processes. Some fellow users have already pointed out how the wiki page works as a shared whiteboard where semi-structured or free-form content can be worked upon by several editors, and improved iteratively in an opportunistic way. Sometimes, that re-shaping of text is made onto the form of the conversation itself, by re-factoring, splitting, merging and re-classifying comments from many editors. This would be hard or impossible to do if the layout of the discussion is fixed in hardware and comments belong to the poster.
- Wikiprojects develop over time new procedures that better suit
the workflow of their members to achieve their goals. Their project pages are free-form collages of all the relevant information they require to do their work, plus discussion processes that may involve just its members or any other external participant. As projects cover all the aspects of human knowledge, it would be difficult to provide a one-size-fits-all interface that may cover all their needs - the flexibility to compose new layouts and compilations of content is core to achieve their goals.
- There's a sense now that the community owns the content of all
pages including talk, and can manage it to their liking. That will disappear if the base model is changed to one based on user-owned comments. There has not been enough discussion of how that will affect all the existing projects and guidelines, or whether such change is acceptable and beneficial to the goal of writing the encyclopedia.
A wiki-like system is very good at achieving those. Some of these needs have surfaced at previous discussion at Talk:Flow, and some have been already addressed or influenced the design, but some others are squarely opposed to the nature of a threaded discussion where the structure is enforced by the platform. It would be sensible that the process to gather feedback from the community includes solid answers to these facets of the tool.
On 8 September 2014 11:44, Diego Moya dialmove@gmail.com wrote:
Now if Erik vision for the deeper than I give him credit for,
... that would be: "Now if Erik vision for the Flow platform is deeper than I give him credit for..."
wikimedia-l@lists.wikimedia.org