Hello all,
I did a couple if simple tests on MediaWiki on Flow pages with often occurring edits. The tests failed.
I am an admin on Commons, and I regularly have to remove an image on a talk page because it is for example a violation of copyright. I see no way to remove the copyright violation from the message.
Another thing I tried is the removal of a personal attack or a privacy issue. It is common on nl-wiki to remove a personal attack out of a message and replacing it by a template which says what happened. This is impossible to do.
If a template is changed, its parameters on the various places where the template is added need to be changed as well. This is done by hand or with a bot (like AWB), both ways seems impossible with flow.
If someone added a message to the wrong page, it is relocated to another talk page. Seems impossible to do here. If a message is considered to be inappropriate for a certain page, it is relocated, seems impossible with Flow.
Another thing I noticed is that I can't get a complete overview of all messages added to a certain talk page. After 10 messages, everything is hidden. A quick ctrl + F is impossible. When I know there was a discussion about a specific thing, I want to check the talk page easily by searching it completely, not possible. It is very annoying that I can't get a complete overview of all messages on a talk page, this is a basic need!
As I read on mw:Flow: "to make the wiki discussion system more efficient for experienced users" (as goal of Flow) I get it! By making normal things impossible to do, the experienced users have indeed less work...
For the rest I have seen no way why this method is more efficient for experienced users, as it is not.
So, there is flow, and instead of the community can work with it as it needs to work with, it does not flow but got stuck...
To answer the question, To Flow or not to Flow, it does not flow. I am not able to do simple edits which are done every day.
Romaine
2014-09-06 6:49 GMT+02:00 Erik Moeller erik@wikimedia.org:
Hi all,
I'm breaking out this discussion about Flow/talk pages (apologies for repeatedly breaking the megathread, but this is a well-scoped subject which deserves its own thread).
Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there (pun intended).
== Document mode ==
There are not many examples of document mode discussion systems beyond wikis. You sometimes see people use collaborative realtime editors as such, because people want to talk in the same space where they work, but Google Docs provided alternatives (a pretty powerful comments/margin system and built-in chat) early on, for example.
The current talk page system is a document mode system. Individual comments have unclear boundaries (a single transaction can result in multiple comments, signed or unsigned; indentation levels are unpredictable and often inconsistent). All the joys and pain points of working on the same document are present (a heavily trafficked talk page will see many edit conflicts). You can't easily show comments in multiple contexts (cross-wiki, via email, as a notification, etc.) because of the boundary problem.
You could try to make a document mode system work better. On the basis of wikitext, you can do some very basic things, like the "new section" link I added to MediaWiki back in July 2003 [1], when I wrote: "This feature could also be the first stage of a more sophisticated discussion system, where the next stage would be auto-appending signatures and providing a 'Reply to this' link after each comment."
But due to the aforementioned unpredictability, even making a "reply" link work consistently (and do the right thing) is non-trivial. You can get some of the way there, and the Wikipedia Teahouse actually has a gadget, written by Andrew Garrett (more on him below) that does precisely that.
https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
Note the "Join this discussion" link. It does give you a pop-up, and posts the comment for you in the right place, with indentation (it does not auto-sign, but instead tries to teach users the signature habit which they'll need to use on other talk pages).
It may be worth doing more research and development on this, to see just how far we can get without changing the fundamentals, since a wholly new system may still be years out for wide use. However, there are inherent limitations due to the lack of a predictable and consistent structure.
You could go further down the road of a document mode or hybrid system, but IMO not without introducing fully predictable comment markers (think <comment id="234234">Bla ~~~</comment>) -- which would pollute the wikitext, be fragile (e.g. accidental or deliberate corruption of identifiers), and probably be considered unacceptable in a system that still supports unlimited wikitext editing for those reasons.
== Structured ==
I personally gave up on patchwork on top of talk pages about 10 years ago. The advantages of having comments clearly identified as such are many:
- Display comments in arbitrary order, arbitrary threading style
- Search comments across date ranges
- Search comments by author
- Track comments as comments, not as diffs
- Monitor changes at any part of a comment thread
- Display comments independent of a given document (e.g. email,
cross-wiki, etc.)
- Display comment metadata in different formats easily (e.g. timestamps)
- Update author names after a username change without having to update
documents
- Enables third parties to build new UIs (think Wikiwand for comments)
more easily
- Ability to tag/categorize individual comments/threads
- and more.
I identified some of these reasons when I wrote the proposal for LiquidThreads in October 2004 [2]. At that point, the Wikimedia Foundation had 0 employees, and this was too large an effort to likely get traction just from ad hoc volunteering. So after some time, I managed to persuade third parties to fund development, including Wikicities and WikiEducator, and found a developer to do the initial work, David McCabe. David did a good initial job but the system had many known issues and was only deployed at a small scale.
At the same time, I think there were many things about even the original design that were good (and aren't found in most other forum systems):
- It preserved "headers" on top of the threaded conversation as
community-editable wiki-like spaces
- It had a full history model for the thread itself, not just comments
- It preserved comments essentially as individual wiki pages, with
their own history
- It had a built-in notion of thread summaries, collaboratively
written, for closing comments
As WMF started to grow, it took on development of LiquidThreads -- with one developer, Andrew Garrett, who did an amazing job cleaning up the codebase and rethinking many of the assumptions David had made. LQT got to a point where some Wikimedia wikis actually requested for it to be enabled and traction started to build in favor of it. To this date, it is still found in some nooks and crannies in the Wikimedia universe.
translatewiki.net still uses it for its support page, and MediaWiki.org for its support desk, which are probably the highest profile uses left, and both get a fair bit of comment traffic.
Andrew did a ton of work on the project, but he himself recognized many architectural issues he wanted to address, and there are also UI assumptions we wanted to revisit. The project didn't have a team behind it at that time -- just one very talented part-time developer who was still at university! This was when WMF was barely growing to do development work, picking up some stuff (like LQT and FlaggedRevs) that had been simmering at a smaller scale before then.
In 2011, Brandon Harris, the first person at WMF ever to be tasked exclusively with design responsibilities, took a crack at some initial redesign drafts [5][6], which still contain many ideas worth looking at. But we pulled the plug at that time, because we recognized that we simply didn't have the personpower to put the resources behind the project to actually get it anywhere near completion -- and that a major architectural overhaul was required to do so.
A new effort was launched about a year ago, now resourcing a full team including design, development, product management, community support. (We're still pretty short staffed on UX research, QA, and data analyst support, but we make do.) As the team (including Andrew with his LQT experience under his belt) thought through the architectural needs of a modern discussion system, they decided that the LQT architecture was not salvageable. A migration script [7] is in development by Andrew himself.
The Flow architecture [8] differs in some important ways from LQT, including:
- Flow doesn't pretend that comments are "pages", instead using its
own separate tables to manage them. This is architecturally important to give us more flexibility on how to store, version, query, search, and describe comments.
- Flow is built from the start to store comments in a central
datastore, to make it easier to display comments and relevant notifications cross-wiki.
- Flow users Parsoid's HTML underneath, to prepare it for VisualEditor.
I don't think the architecture is perfect, but it should be a reasonable foundation to build on and iterate from.
The Flow UI, similarly, represents a first pass at this point. A lot of basic functionality is still missing. Things we know will make users happy (like cross-wiki features) are still ways out. It doesn't support VisualEditor yet, and yet its wikitext input suffers from any issues Parsoid does -- decisions made to future-proof the architecture have negative short term impact.
And like any brand-new UI, it could use lots of micro-optimization -- glitches here and there, which you may not even consciously notice, but which give you the feeling that you're using not-quite-ready software. Which you are.
At the same time, we know from user studies that talk pages are incredibly hard for new users to figure out. The semantics are just extremely different from anything else on the web. So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them. This parallels the long adoption of LQT for support desk type forums.
In this context, we also want to do some systematic measurement: How does such a system affect the # of comments posted, and the quality of the discussion?
We expect that we'd need to focus in on this use case in production for quite some time to get it right and really get people to fall in love with the system as it improves. At the same time, there may be other use cases that are less contentious and could serve as additional trials -- like talk pages in Wikidata.
We're not pushing an aggressive schedule on Flow -- we understand it needs to happen at the pace of the communities, since you can't build an "opt-out" for this kind of system (unlike VisualEditor). So the schedule is going to have to give as needed.
And as above, I'm open to us putting some short term effort into talk page improvements that can be made without Flow -- knowing it's still some time out. But based on the above long term functional and architectural considerations, I think a system that treats comments/threads as structured information, rather than as documents, is ultimately necessary, so I'd argue against procrastinating. It's going to be hard enough as it is to get this done without putting it on the backburner once more.
Finally, any comment that is about specific Flow UI aspects should be treated with a massive block of salt. The UI will evolve dramatically as we learn what works for new and experienced users alike.
Sincerely, Erik
[1] https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html [2] https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760 [3] https://translatewiki.net/wiki/Support [4] https://www.mediawiki.org/wiki/Project:Support_desk [5] https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design [7] https://gerrit.wikimedia.org/r/#/c/119243/ [8] https://www.mediawiki.org/wiki/Flow/Architecture -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 06.09.2014 23:14, Romaine Wiki wrote:
Hello all,
I did a couple if simple tests on MediaWiki on Flow pages with often occurring edits. The tests failed.
...
So, there is flow, and instead of the community can work with it as it needs to work with, it does not flow but got stuck...
To answer the question, To Flow or not to Flow, it does not flow. I am not able to do simple edits which are done every day.
Romaine
Hi Romaine
thanks for the great post.
May be indeed a good starting point would be to invite the community (not only en.wp and large projects, but also non-wikipedia and small projects) to list all functionalities of the talk pages they need and then discuss whether they are absolutely needed or we can survive without them. I am not aware of this discussion ever taken place (at least I am fairly active in several Wikimedia projects for a pretty long time and I have never heard about it).
Cheers Yaroslav
Hi,
I forgot to mention that we use a lot of template messages on talk pages to inform users about something. In a part of these templates we automatically add categories because we want to track the users who have problematic behaviour. Testing this by adding a category to a message in Flow gives no result.
Another issue I think of are deleted files and templates. They show up in categories and special pages to be fixed.
Also often messages are copied to another page, including all the wikisyntax. I haven't found any way to do that. Going from a Flow page to a non-Flow page. This is a basic thing.
Also, so far I have seen, it is not possible to create a page with all the discussions about a certain topic. This is currently possible to keep an overview.
The option Permanent link is not working as I would expect. It is good that there is a way to link to an individual topic (that is what Permanent link currently does), but we also like and need the possibility to link to a certain revision of a message. (This also would mean that if I post a message, someone else reacts on it, I have to change my message and the other person does it as well in his, that the permanent link to an earlier version should show the topic as it was on that certain moment in time.)
I also found a bug, the links of the history page do not work in Dutch: https://www.mediawiki.org/w/index.php?title=Topic:S1uggs1vsnq6d8g8&actio...
One last thing I somehow notice that Flow gives me some feeling of clumsiness. I can't qualify it yet somehow. Some buttons are not on intuitive places. But what concerns me is that it is no longer a wiki way of editing/responding. The community loses control over their pages and messages as it is all fixed in the software. Flow takes away the ability to organize and I do not think that is good development. I can understand and imagine that Flow can be handy to reply on each other, but the thing that Wikipedia (and MediaWiki) makes great is the ability to re-organize. The community loses with the current state of Flow to much their control over the content of talk pages.
Greetings, Romaine
2014-09-06 23:23 GMT+02:00 Yaroslav M. Blanter putevod@mccme.ru:
On 06.09.2014 23:14, Romaine Wiki wrote:
Hello all,
I did a couple if simple tests on MediaWiki on Flow pages with often occurring edits. The tests failed.
...
So, there is flow, and instead of the community can work with it as it
needs to work with, it does not flow but got stuck...
To answer the question, To Flow or not to Flow, it does not flow. I am not able to do simple edits which are done every day.
Romaine
Hi Romaine
thanks for the great post.
May be indeed a good starting point would be to invite the community (not only en.wp and large projects, but also non-wikipedia and small projects) to list all functionalities of the talk pages they need and then discuss whether they are absolutely needed or we can survive without them. I am not aware of this discussion ever taken place (at least I am fairly active in several Wikimedia projects for a pretty long time and I have never heard about it).
Cheers Yaroslav
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Sat, Sep 6, 2014 at 2:14 PM, Romaine Wiki romaine.wiki@gmail.com wrote:
I am an admin on Commons, and I regularly have to remove an image on a talk page because it is for example a violation of copyright. I see no way to remove the copyright violation from the message.
Another thing I tried is the removal of a personal attack or a privacy issue. It is common on nl-wiki to remove a personal attack out of a message and replacing it by a template which says what happened. This is impossible to do.
Please see my response to Todd here explaining the current permissioning: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-September/074358.html
If a template is changed, its parameters on the various places where the template is added need to be changed as well. This is done by hand or with a bot (like AWB), both ways seems impossible with flow.
Flow doesn't automatically update template output -- it retains the output as it was when the user posted the comment. We can argue whether that's good or bad behavior, but it's worth doing so in the context of real examples. When would this cause problems?
Contrary to some descriptions, it's not quite the same as {{subst}}ing the template. You can still get back to the wikitext used produce the output, and change it, and potentially re-parse it. It just doesn't do so automatically (which is also not an inherent limitation).
If someone added a message to the wrong page, it is relocated to another talk page. Seems impossible to do here. If a message is considered to be inappropriate for a certain page, it is relocated, seems impossible with Flow.
It doesn't support any kind of moving yet, that's still (like many features) to be developed, but unlike talk pages, it's architecturally viable to move a whole thread and its history, rather than copying and pasting content around, losing history, as we currently do routinely.
Another thing I noticed is that I can't get a complete overview of all messages added to a certain talk page. After 10 messages, everything is hidden. A quick ctrl + F is impossible. When I know there was a discussion about a specific thing, I want to check the talk page easily by searching it completely, not possible. It is very annoying that I can't get a complete overview of all messages on a talk page, this is a basic need!
Of course, which is why it's a high priority feature.
To answer the question, To Flow or not to Flow, it does not flow. I am not able to do simple edits which are done every day.
It's a system in early development, and has never been advertised as anything else. To draw conclusions about what it can and cannot do is, by definition, premature. A much more useful discussion is whether a system like it (provided some of its properties are clarified and improved) is desirable, and if not, what alternative ways there are to make talk pages more user-friendly, and what the limitations of those methods are. Also, to the extent that there are aspects of the Flow architecture that really are dealbreakers, we should fix them now.
As I wrote to Risker, I think it's worth considering spending some development time on turning something like the Teahouse gadget (which allows one click insertion of replies on the Teahouse Q/A page) into a Beta Feature after some further improvement, to see just how useful it could be for the common case. If there's an 80/20 rule and in 20% of cases it just gives up and edits the section, that might still be a time-saver and convenience. There might even be other relevant gadgets already in some languages/projects -- worth a closer look, for sure.
Flow is a long term bet that an architecture of tructured comments will ultimately have fewer hard and fast limitations on how collaboration in wikis can work, and will accrue usability benefits very quickly (as it already has done, like faster posting and replies) due to its architecture. So far we've only invested in the long term bet -- some rebalancing of effort towards the short term may be valuable, and may lead to interim milestones that impact users today rather than years from now. I can't answer when you'd hit the boundaries of what you can do with the free form text on talk pages today, but I don't think anyone's really tried yet. (Magnus, I am sending brain waves in your direction! ;-)
Erik
On 6 September 2014 15:33, Erik Moeller erik@wikimedia.org wrote:
Flow doesn't automatically update template output -- it retains the output as it was when the user posted the comment. We can argue whether that's good or bad behavior, but it's worth doing so in the context of real examples. When would this cause problems?
I noticed this a few months ago and I think that in almost every case it's not actually a problem. Many common talk pages templates are meant to be substituted – in fact, some even spit out an error if you don't substitute them! – so in most cases there's no substantial difference between substitution and the way Flow currently does it; in both systems, using a template generates a snapshot of the template at the time the post was made.
There is one notable exception to the above, which is talk page header templates. One expects updates to a template used as a talk page header to update every page the template is currently transcluded on, which is not happening presently. {{talk header}} is currently transcluded on over 250,000 pages, so were these all Flow pages it would be excessively laborious to edit all of those headers to force a reparsing of the template were it updated. So this functionality, or something similar, should probably be included in the Flow MVP [1] if it's deployed on a larger scale. I think it's fine for now.
I expect that the reason most people find this so frustrating is not because it results in any problems in and of itself, but because it represents an inconsistency in the way that templates are handled in Flow compared to how they're handled everywhere else, and therefore results in Flow not behaving as an experienced user would expect. As I talked about above though, the actual severity of that inconsistency is minor bordering on trivial [2] in most cases.
Dan
[1]: https://en.wikipedia.org/wiki/Minimum_viable_product [2]: https://www.mediawiki.org/wiki/Bugzilla/Fields#Severity
On Sat, Sep 6, 2014 at 4:15 PM, Dan Garry dgarry@wikimedia.org wrote:
There is one notable exception to the above, which is talk page header templates. One expects updates to a template used as a talk page header to update every page the template is currently transcluded on, which is not happening presently. {{talk header}} is currently transcluded on over 250,000 pages, so were these all Flow pages it would be excessively laborious to edit all of those headers to force a reparsing of the template were it updated. So this functionality, or something similar, should probably be included in the Flow MVP [1] if it's deployed on a larger scale. I think it's fine for now.
That makes perfect sense -- thanks for pointing it out. Stale headers would suck indeed.
And now I'm taking a break from wikimedia-l til Monday. The weather's nice, and the monthly posting limit is starting to loom into view. ;-) Hope everyone has a nice weekend.
Erik
rik, I appreciate your engaging with this *early* enough for design decisions to be adjusted before Flow gets to major rollouts.
Romaine, if the Dutch uses of features like templates are not being taken into account in how features are designed, I suggest contacting the Engineering community liaisons to make your needs known. I'm also sending this email to Rachel so she can consider having one of her employees reach out to you and the Dutch Wikipedia community.
Pine
On Sat, Sep 6, 2014 at 5:01 PM, Erik Moeller erik@wikimedia.org wrote:
On Sat, Sep 6, 2014 at 4:15 PM, Dan Garry dgarry@wikimedia.org wrote:
There is one notable exception to the above, which is talk page header templates. One expects updates to a template used as a talk page header
to
update every page the template is currently transcluded on, which is not happening presently. {{talk header}} is currently transcluded on over 250,000 pages, so were these all Flow pages it would be excessively laborious to edit all of those headers to force a reparsing of the
template
were it updated. So this functionality, or something similar, should probably be included in the Flow MVP [1] if it's deployed on a larger scale. I think it's fine for now.
That makes perfect sense -- thanks for pointing it out. Stale headers would suck indeed.
And now I'm taking a break from wikimedia-l til Monday. The weather's nice, and the monthly posting limit is starting to loom into view. ;-) Hope everyone has a nice weekend.
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 Sat, Sep 6, 2014 at 10:03 PM, Pine W wiki.pine@gmail.com wrote:
rik, I appreciate your engaging with this *early* enough for design decisions to be adjusted before Flow gets to major rollouts.
Romaine, if the Dutch uses of features like templates are not being taken into account in how features are designed, I suggest contacting the Engineering community liaisons to make your needs known. I'm also sending this email to Rachel so she can consider having one of her employees reach out to you and the Dutch Wikipedia community.
Pine
Thanks for the initiative Pine. Romaine and I know each other and spent a great deal of last July talking about template usage on the Dutch Wikipedia in the context of VisualEditor :) . I'm not on the Flow team (I don't work with VE anymore either) so I can't speak for experience there, but I do know that thanks to Romaine's advocacy within the community and to me that VisualEditor was never enabled by default on the Dutch Wikipedia. This occurred because of consideration of the special-use case that community has built with templates. It was intense time for sure, but the right decision was certainly made as far as the Dutch Wikipedia goes.
On Sat, Sep 6, 2014 at 10:27 PM, Keegan Peterzell kpeterzell@wikimedia.org wrote:
..last July...
July 2013, for clarity.
2014-09-07 0:33 GMT+02:00 Erik Moeller erik@wikimedia.org:
On Sat, Sep 6, 2014 at 2:14 PM, Romaine Wiki romaine.wiki@gmail.com wrote:
I am an admin on Commons, and I regularly have to remove an image on a
talk
page because it is for example a violation of copyright. I see no way to remove the copyright violation from the message.
Another thing I tried is the removal of a personal attack or a privacy issue. It is common on nl-wiki to remove a personal attack out of a
message
and replacing it by a template which says what happened. This is
impossible
to do.
Please see my response to Todd here explaining the current permissioning:
https://lists.wikimedia.org/pipermail/wikimedia-l/2014-September/074358.html
Okay. One point I miss there, which I tried to mention in the post I typed before I saw this one, is that there is a fundamental question to be answered. The question is: who is in control of the content of pages. Should the software be in control of pages or the local community? Maybe this sounds strange, but the community has now the ability to rearrange a talk page to reflect better the needs.
I know examples of people who added a new header about the same topic which was discussed above, and then the two headers were merged into one. Or the order of the messages being changed. To split up a topic into two topics to keep the subject on topic. Rearranging large topics by adding 3rd and 4th degree headers in what messages are grouped. These changes are now used to keep the overview over an topic.
But hiding a complete message while only a very small part, usually one or two words, is requested to be hidden, is unbalanced.
If a template is changed, its parameters on the various places where the template is added need to be changed as well. This is done by hand or
with
a bot (like AWB), both ways seems impossible with flow.
Flow doesn't automatically update template output -- it retains the output as it was when the user posted the comment. We can argue whether that's good or bad behavior, but it's worth doing so in the context of real examples. When would this cause problems?
Contrary to some descriptions, it's not quite the same as {{subst}}ing the template. You can still get back to the wikitext used produce the output, and change it, and potentially re-parse it. It just doesn't do so automatically (which is also not an inherent limitation).
Interesting way of handling templates. I need to think of what consequences that would have, how it influences the way of using talk pages.
One question that already comes in my mind is what happens when in one message a template is added, the template got deleted and later the user who posted the original message wants to change the text. Will the template stay look the same as the original post or will it be updated with saving the change? (Sorry, I have not tested this yet.)
If someone added a message to the wrong page, it is relocated to another talk page. Seems impossible to do here. If a message is considered to be inappropriate for a certain page, it is relocated, seems impossible with Flow.
It doesn't support any kind of moving yet, that's still (like many features) to be developed, but unlike talk pages, it's architecturally viable to move a whole thread and its history, rather than copying and pasting content around, losing history, as we currently do routinely.
Good to read that it is something which is already thought of. I think it is considered more important to have the possibility to move a text (with a link to the source page for the history) than having the history with it. But I think it can be an improvement if moving is possible with history.
Another thing I noticed is that I can't get a complete overview of all messages added to a certain talk page. After 10 messages, everything is hidden. A quick ctrl + F is impossible. When I know there was a
discussion
about a specific thing, I want to check the talk page easily by searching it completely, not possible. It is very annoying that I can't get a complete overview of all messages on a talk page, this is a basic need!
Of course, which is why it's a high priority feature.
Good to know.
To answer the question, To Flow or not to Flow, it does not flow. I am
not
able to do simple edits which are done every day.
It's a system in early development, and has never been advertised as anything else. To draw conclusions about what it can and cannot do is, by definition, premature. A much more useful discussion is whether a system like it (provided some of its properties are clarified and improved) is desirable, and if not, what alternative ways there are to make talk pages more user-friendly, and what the limitations of those methods are. Also, to the extent that there are aspects of the Flow architecture that really are dealbreakers, we should fix them now.
Someone (a user) gave me today another impression, it is good you tell me this so I can correct that.
As I wrote to Risker, I think it's worth considering spending some development time on turning something like the Teahouse gadget (which allows one click insertion of replies on the Teahouse Q/A page) into a Beta Feature after some further improvement, to see just how useful it could be for the common case. If there's an 80/20 rule and in 20% of cases it just gives up and edits the section, that might still be a time-saver and convenience. There might even be other relevant gadgets already in some languages/projects -- worth a closer look, for sure.
Flow is a long term bet that an architecture of tructured comments will ultimately have fewer hard and fast limitations on how collaboration in wikis can work, and will accrue usability benefits very quickly (as it already has done, like faster posting and replies) due to its architecture. So far we've only invested in the long term bet -- some rebalancing of effort towards the short term may be valuable, and may lead to interim milestones that impact users today rather than years from now. I can't answer when you'd hit the boundaries of what you can do with the free form text on talk pages today, but I don't think anyone's really tried yet. (Magnus, I am sending brain waves in your direction! ;-)
I do hope that the performance for end users will be kept taken care of and that it stays very quickly.
I think I have a good change to use the maximum of talk pages. As my talk page is often used as some sort of help desk and to-do list in one, I archive parts of it after checking if I have completed the subject, done the request, solved the issue, etc. I do not automatically archive but do archive manual after checking if the message is no longer needed.
In Flow I miss the option to copy the source code, even if it was only a part, to quote someone including the wikisyntax that user added.
I must say, I like the the situation of the VisualEditor. It is there very easy to edit, but if you need you can still access and edit the source code. I can understand that viewing a complete talk page in source code modus is not possible, but for topics such should be possible I think.
Thanks for the answers and explanations.
Romaine
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 Sat, Sep 6, 2014 at 3:33 PM, Erik Moeller erik@wikimedia.org wrote:
As I wrote to Risker, I think it's worth considering spending some development time on turning something like the Teahouse gadget (which allows one click insertion of replies on the Teahouse Q/A page) into a Beta Feature after some further improvement, to see just how useful it could be for the common case. If there's an 80/20 rule and in 20% of cases it just gives up and edits the section, that might still be a time-saver and convenience. There might even be other relevant gadgets already in some languages/projects -- worth a closer look, for sure.
I'm talking about this with the Flow team, but I also want to be conscious of their focus and energy. One possibility is to contract this out to an individual dev to test out the boundaries of what can be done in JavaScript alone -- and make recommendations for any mediawiki/core changes that could help. Since a JS opt-in script can be quickly developed by anyone with talent and motivation there's really no barrier to trying this.
If anyone's reading feels they're qualified to take this on and would be interested doing it on a contract, drop me a line offlist. Obviously it's also a great opportunity for volunteer experimentation, as well. I think at this stage we should consider this a research effort.
There is some pre-existing work on this, beyond the Teahouse gadget.
- Mobile web has a very experimental "reply" feature on talk pages right now. It doesn't handle the indentation levels, as far as I can tell - it just inserts a new top-level comment. You can turn this on by 1) enabling beta, 2) enabling alpha, 3) logging in, 4) going to a talk page, 5) going to a section. That's a lot of steps, but since it's so experimental that's probably for the best :-)
- Gabriel Wicke has done some experimentation with this as well, and is looking if he can dig up the old code for me.
If others are aware of relevant hacks/gadgets/user srcipts, please let me know.
Erik
On Mon, Sep 8, 2014 at 6:47 PM, Erik Moeller erik@wikimedia.org wrote:
- Gabriel Wicke has done some experimentation with this as well, and
is looking if he can dig up the old code for me.
Very old indeed, but if anyone wants to take a look: https://github.com/gwicke/wikiforum
On Sat, Sep 6, 2014 at 6:33 PM, Erik Moeller erik@wikimedia.org wrote:
< Flow is a long term bet that an architecture of structured comments
will ultimately have fewer hard and fast limitations on how collaboration in wikis can work, and will accrue usability benefits very quickly (as it already has done, like faster posting and replies)
< due to its architecture ... some rebalancing of effort towards the short
term may be valuable, and may lead to interim milestones that impact users today rather than years from now.
Testing this by irreversibly replacing existing unstructured talk pages seems likely to be a hard transition and hard to evaluate, since it breaks workflows as it enables new ones.
Two less dramatic ways to test such a bet:
1. Experiment with annotation and inline comments
This is one of the oldest forms of curation; a rapidly growing area of knowledge production online; e.g.: one of the early and beloved features of G!Docs, and the central feature of Genius which has its own communities curating interleaved and overlaid knowledge.
MW currently has little capacity for annotation, beyond inline footnotes. An improvement in that area would be welcome. The annotation use case is also a bit better-defined – more universa!ly a thread of individual thoughts – than the broad range of uses for talk pages.
Over time I could see many current uses of talk pages, including the simplest and most common ones, shifting to inline comments.
2. Experiment with UI overlays on top of current talk pages where possible.
For instance: the way talk pages and their tables of contents and section headings are displayed, where links to "reply" are displayed, how signatures are generated, the way a textarea is presented for adding a new comment.
Similarly, font / whitespace / layout changes are general UI shifts, and could be tested now without changing the function and data models of talk pages.
wikimedia-l@lists.wikimedia.org