Talk:Flow Portal/Archives of merged subpages

From Talk:Flow Portal/Use cases

"Drafting" use case

I've boldly added a use case to the list, that seems to have slipped through the cracks of your task analysis (it could loosely be assimilated to the 'discuss' case, but it's not really the same thing and the working prototype design doesn't support it).

I hope someone is still using this page for reference. If not, where's the best place to discuss this use case? Diego Moya (talk) 11:14, 17 July 2013 (UTC)

I've (at least partially) answered this, in the thread at Talk:Flow Portal/User Stories#Drafting and collaboration.

A lot of these pages were written months ago, but I believe they are all still actively watched. However, so that additional editors might see the questions (and reply in turn, or read any replies), it's probably ideal to give general feedback at Talk:Flow Portal (or at w:Wikipedia talk:Flow). HTH. Quiddity (talk) 18:07, 17 July 2013 (UTC)

Templates in discussion and drafting

Talk page uses 4 and 5: It seems to have been ignored that "discussion" and "drafting" require the accessibility of templates, and possibly complex Wikicode, which are/is or would be used in the article. I'm not going to edit the text, itself, but this is, in my opinion, one of the few absolutely required components of Flow for it to be at all usable on article talk pages, and sometimes on user talk pages. Arthur Rubin ^en.Wiki (talk^en.Wiki) 19:03, 15 August 2013 (UTC)

From Talk:Flow Portal/User stories

"As a user, I want to be able to edit my own comments."

• completely freeform and perpetual editing of my own comments (say after someone has replied and I change the fundamental meaning of the post) then we have to worry about showing previous versions, and all the UI that comes along with that (something a new user is not likely to understand) JZimmerman (WMF) (talk) 07:19, 12 May 2013 (UTC)

  We get revision history for free with mediawiki. I think we can bury this into a "more actions" panel on the post (which is where the "edit" action and administrative actions would go anyway). The standard MW history list is definitely overkill; I suspect we can pare away a lot of it.--Jorm (WMF) (talk) 19:59, 12 May 2013 (UTC)

Epic

I can deduce the definition as used here, from the terminology it's a header for (a story/narrative description of use-cases), but what is the origin of the way you're using the word 'epic'?

(It's understandably difficult to google for "epic interaction design" or "epic user groupings" and similar! Every web-company under the sun believes they are "epic, dude"...) Wiktionary and Onelook weren't much help, either.

I know I've seen it before, somewhere, used like this, but can't find anything here or on meta.. Quiddity (talk) 04:13, 19 June 2013 (UTC)

As is often the case, I found the answer 20 seconds after submitting the question. Epic vs Story, last seen in Atlassian (Repress, Repress, Breathe....). Quiddity (talk) 04:19, 19 June 2013 (UTC)

Drafting and collaboration

I want to my recognition of the hard work that the Flow and VisualEditor development teams are carring out, as well as their conversations with Wikipedia community to explain the projects. I understand what the Wikimedia Foundation is doing with the several projects to improve the experience for new users, and I wholeheartedly agree with the goals.

That said, I've been testing the Flow prototype and reading about the decisions that are shaping it, and I'm concerned that a major function of talk pages as used by the community is missing.

"As a user, I want to"... collaborate with other editors to build a draft version of a Wikipedia article, through refinements to a stable content section (hidden from the view of article readers) that I can reference with wikilinks.

I see a thorough task analysis about one-to-one or one-to-many conversations, as if Talk pages were exclusively to be used as a chat room. But article's talk pages are primarily intended as a tool to support coordination between content creators. Where are all the use cases and stories for collaborative editing and content creation that are core to the wiki platform? Where is the sandbox? Diego Moya (talk) 11:26, 17 July 2013 (UTC)

Drafting content is essentially part of the "Discussion" use-case (the point above the item you added at Flow Portal/Use cases). Check the diff-link that it includes as an example, and see the entire thread that it is a part of: [1]. It's discussing, and contains, a copy of the infobox. - Therefor, we can conclude that the "elements [which] do not need to be elaborated on at length", include a variety of things which probably could be elaborated on quite easily, but to make an exhaustive list would be rather lengthy indeed. The list necessarily includes everything that we do in talk-space, that isn't specifically mentioned in the other points.

Re: sandboxes in particular, I believe that this is what is meant by the section at Flow Portal/User to User Discussions#Collaborative Posts. Again, the section was written a while ago (February - possibly based on notes from even earlier), and could definitely use elaboration, but the current documentation is meant more as an abstract overview and set of notes, rather than a rigid documentation of "how the software will work exactly". Some amount of "reading between the lines" is required, at this point in time. (Developer time is limited, and is prioritized towards writing code, rather than filling in detailed versions of documentation for the as-yet-unwritten-software).

Hope that helps. Quiddity (talk) 18:06, 17 July 2013 (UTC)

Re "(Developer time is limited, and is prioritized towards writing code, rather than filling in detailed versions of documentation for the as-yet-unwritten-software)."; are the requirements for the "as-yet-unwritten-software" written, and are they subject to discussion? Writing code for detailed requirements which cannot not meet overall use requirements should be extremely low priority. Arthur Rubin ^en.Wiki (talk^en.Wiki) 16:12, 19 July 2013 (UTC)

From Talk:Flow Portal/Welcome Module

What content we wish new users would read

I discovered en:WP:42 recently, which I really like. (Some older diffs, were even better).

I tend to throw really short pages like this at newcomers, as much as possible. (Trifecta is the original snarky grandparent. It's teeth are falling out now. Wikipe-tan will gum you to death)

I was loving this Welcome Module overview, and thinking about my ideal shortlist, (which of course varies, depending on the demographics of the person I'm welcoming.) This is what I came up with, as core sets (scales of thinking), with good examples.

How does [x] work?

• The code: en:WP:Cheatsheet
• The articles: en:WP:42
• The project: en:WP:5P

I guess VisualEditor will remove the necessity for knowing the code, so that's one down.

We do need some sort of organised structure, behind the links we select to go in a "welcome message/template". The existing variety, is staggering (en:WP:Welcoming committee/Welcome templates).

[Note: There are an absurd selection of pages to choose from, for "what I wish a newcomer knew". From Tutorials to Introductions to Simplified-Rulesets to Nutshell-policies/guidelines to task-specific help. The most uptodate compilation (afaik) of the core pages is en:Help:Contents/Directory (mostly put together by User:Moxy).]

Ramble ramble. Quiddity (talk) 06:53, 19 June 2013 (UTC)

From Talk:Flow Portal/Workflow Description Module

• Note: «Part of the goals for the Flow project is better management of workflows like AfD», says Erik. —The preceding unsigned comment was added by Nemo bis (talk • contribs) 03:59, 13 May 2013‎

From Talk:Flow Portal/MVP

Sounds promising

I think this is a great way to pilot Flow, and potentially a boon for WikiProjects (which are dear to my heart). A couple of questions/suggestions/crazy ideas:

• will Flow play nicely with archiving bots, like MiszaBot?

Thanks for reminding me that I hadn't covered archiving (yet) :) I've added a note about that and search in the doc. The answer to your specific question is that manual or bot archiving in the current wiki way may not make sense with a discussion feature that has infinite scroll capability – we could always show the most recent discussions on top and lazy-load older ones below, making them accessible via scrolling. That + a robust search feature may be far more useful than creating static, arbitrarily defined archives via a bot. If I'm looking for a particular discussion, being able to search for all discussions that match certain keywords, users, or date ranges would be far more useful than a list of archived discussions 1-23,234.

• this is way out of scope for MVP, but have you considered adding an optional "resolved" button for threads? A lot of project_talk posts are more like bug tickets than conversations.

I actually did consider that feature for the MVP! It would obviously be super useful. What stopped me was the fact that we have two similar and somewhat overlapping feature ideas for this kind of workflow: a "resolved" button, which could be on a per-comment basis, and a "closed" button, which could collapse the entire closed topic and all associated comments and replace it with a brief summary (e.g., "SNOW close of this RfC to change n-dashes to m-dashes in Nickelback articles"). I think it might be good to let users play with the prototype and decide which of these things they want most for WikiProject discussions (whether it's one or both).

• If you're looking for projects to test this out on, I would be happy to suggest coordinators to reach out to.

Yes! Suggestions welcome :)

+1, very happy you guys are starting with Wikiprojects! I've been lobbying Jorm to beta test Flow on Teahouse for ages, and J-Mo has convinced me that TH is a WikiProject, so yippee. But the Q&A forum is not a talk page...possible to still try something out there? Or perhaps host lounge talk page for experienced TH discussion, if Q&A is too much trouble to begin with. Sbouterse (WMF) (talk)

Apologies if any of this is covered elsewhere in the Flow doc. Jmorgan (WMF) (talk) 23:42, 20 August 2013 (UTC)

Thanks for the feedback, J-mo! In-line replies to your queries above ^ Maryana (WMF) (talk) 00:36, 21 August 2013 (UTC)

This is out of scope here, but I don't know the page where it would in scope: Is the en.Wikipedia implementation of succession boxes compatible with Parsoid. My understanding is that it isn't, because the table start is in the "S-start" template and the table end is in the "S-end" template, with other templates in between. Arthur Rubin ^en.Wiki (talk^en.Wiki) 02:25, 22 August 2013 (UTC)

Arthur Rubin, I'm not 100% sure, but after seeing all the amazingly complex things Parsoid handles comfortably already, my gut says those'll probably be fine. Check out this page, which documents the current limitations to Parsoid. Some of this stuff is so little-used that there doesn't seem to be a lot of impetus to fix it, but other things are actively being worked on and will get fixed soon. If S-start/S-end templates fall under any of those unsupported categories, I'd suggest leaving a note on the talk page about them, so the visibility of the issue can be raised to the devs. Maryana (WMF) (talk) 03:12, 22 August 2013 (UTC)

Please react to the discussion on en-WP

Hi, the recent discussions at en:Wikipedia talk:Flow mentioned quite a number of points that must be considered here, as they are minimum viable product specs for Flow to get anything resembling acceptance by the editing community.

To be blunt:

• We will not allow a roll out even for onwiki testing of any tool that does not allow real collaboration on texts! Please read my last sentence again. If you don't understand why this is important, please read it once more. The concept of Flow as individual snippets that are owned by the respective author and can't be edited by anyone else, is not compatible with the idea of a Wiki and therefore not acceptable. We need collaboration in discussions just as we need it in the article name space.
• And we need full rendering of each and every valid Wikicode in discussions. Maybe you don't know about that, but both article talk pages, as user talk pages, both have the primary purpose of discussing improvements to articles. All of Wikipedia is about improving articles. Therefore those talk pages need to be able to render examples and snippets from actual articles. And that includes ugly CSS-hacks and the misappropriation of templates to name only two challenges. Using Parsoid only won't do.

If that means you have to start over and forget everything you did so far, well, better now than in one years time when your code is (almost) finished but we will not allow it on our Wikipedias. rgds --H-stt (talk) 12:06, 9 September 2013 (UTC)

First, I think there may be some confusion as to what software development defines the idiom "Minimum Viable Product" and how people are perceiving it. We are using it in the software engineering sense: the smallest amount of work required to create functional software that works. It's not the complete product (which could possibly take years to finish). It's the smallest group of features possible to make it usable for the first release. And the first release isn't targeted at articles, or user talk. It's got a very specific focus.

Second, I'll point out that Flow will support a great deal of wikitext natively (most, in fact). We've discussed this before and provided examples. Flow posts will be run through Parsoid. This is perhaps not a very popular design decision with several members of the community but we believe it is essential to the mission statement of the Wikimedia Foundation:

The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally. (emphasis mine)

The fact is that talk pages - as they currently exist - do not empower or engage people. In fact, they do the exact opposite, which is why we are working to fix them. We will not be spending resources (money and time) to replicate broken technology. If you disagree that talk pages are broken - if you think they work just fine for empowering and engaging people - then I'm afraid there isn't much use in further conversation along these lines because it won't be productive.

Third, we are planning on integrating "collaborative development" areas into Flow to address the issue of multiple editors working on developing articles. I do not believe that it is currently in the MVP (I think it is slated for release 2), but I may be wrong.

Fourth, whether or not Flow is deployed to an individual wiki is largely outside of the consensus of the local wiki. The development and deployment of Flow has been mandated by the board of trustees. There really isn't a productive conversation to be had with threats about "not allowing us to deploy"; that's a battleground mentality that can quickly turn toxic. If your concern is that we will simply "turn it on everywhere at once" I can assure that will not happen; the rollout is going to be painfully slow.

Fifth, if you have any specific concerns regarding what wikitext may or may not be supported, it would help us to see examples, if you can provide them.

Thanks! --Jorm (WMF) (talk) 20:23, 9 September 2013 (UTC)

Re: the first point - Note that the new/current plan is to make the first release at just a few wikiprojects (See w:Wikipedia:Flow#Timeline). That's it. It's being discussed with the communities and seeing who is willing to host the initial tests. –Quiddity (talk) 20:38, 9 September 2013 (UTC)

This won't do. I hereby declare Flow to be dead. Don't invest further time and money into it. And I doubt you assessment regarding the existing talk pages. They are wikis. They are basic, maybe even primitive. They are very hands on and that makes them incredibly powerful. Sure, with that power there are dangers. If you have a nail gun, you can shoot yourself into the foot. But I prefer a wiki talk page over every forum software, I've ever seen. And I don't know anyone who did not get our talk pages. Maybe they made a few mistakes in their early days but that's OK. rgds --H-stt (talk) 14:45, 10 September 2013 (UTC)

I'm sorry this couldn't be productive. Perhaps you'll change your mind in the future, after having seen the software in action.--Jorm (WMF) (talk) 15:10, 10 September 2013 (UTC)

I'm sorry. Please don't complain, if this project ends like a number of other recent developments by the WMF. rgds --H-stt (talk) 16:50, 11 September 2013 (UTC)

Re: "I don't know anyone who did not get our talk pages" - If I might suggest, watching a couple of the videos and reading the conclusions at Flow_Portal/Research/User_Test_Data#Test_2, and also this Wikimania video (See the 90 second Flow specific part starting at 49:18, but also the VE clip that runs from 57:00 until 60:30), is interesting and insightful.

I've also personally introduced many friends, acquaintances, and colleagues, to editing, and only the computer-savvy people ever became comfortable with our wiki-discussions. There is much to like about the free-form wiki system we use, but there are also a lot of drawbacks, that dissuade a lot of otherwise-intelligent people from ever becoming editors. (Eg. the simple examples in those videos I linked, or more complex workflow examples like the painfully convoluted multistep process that many of our common tasks require, like AfD). The image-upload process has been overhauled to be a lot less painful, over the past few years, but many other tasks are still vastly more complex than they need to be. Food for thought, at least. –Quiddity (talk) 18:12, 11 September 2013 (UTC)

From Talk:Flow Portal/Editing comments

Argument

So the page says: "Using the current talkpage interface, it is possible for users to edit the posts of others, up to and including interleaving. From a user experience point of view, this is irrational (and, frankly, insane): a discussion medium does not work without the certainty that the comment you are replying to is genuine, and that your comment will not itself be tweaked or corrupted by others. Accordingly, the argument is for Flow to not permit modification of posts, with the exception of a user trying to modify their own contribution."

I'm not sure if I understand this argument. There's two things I find strange about it. The first point is that it doesn't matter who changes the comment after the fact, this still affects the genuineness of the comment. In my experience, it is not a third-party changing a comment that undermines the genuineness most commonly, but rather the original editor changing a comment in substantive ways is more common. Example: Editor A posts one thing, Editor B responds with an elenchus, and Editor A goes back and changes her original comment so that B's response no longer makes sense. If the undermining of genuineness is a good enough reason for removing the ability of editors to change others' comments, so too it is a good enough reason for removing the ability of editors to change their own comments.

Second (and this is far more minor): There already is a way to have (relative) certainty that a comment is genuine: Check the diffs. The argument needs the further premise that checking diffs is too burdensome for a well-functioning comment system.

When you combine these two considerations: If the goal of not allowing other editors to change one's comments is to avoid the need of constantly checking diffs, then the goal is simply not met. The fact that the original editors can still change their comments keeps this as a requirement, as this is significant enough such that there will still be a need to check diffs. --Atethnekos (talk) 19:47, 1 October 2013 (UTC)

@Atethnekos: If an initial post is altered, I believe there will be something like an "Edited by x" note attached (just as Liquidthreads currently has, eg Thread:Talk:Flow/Auto-archiving/reply (30)).

The discussion at this point is to determine in what circumstances, and how frequently, we edit each others posts. Quiddity (WMF) (talk) 19:58, 1 October 2013 (UTC)

I still don't see the argument, even with "Edited by x" notes. The same sort of consideration would apply even with such a note: If the note is not sufficient in its contribution to certainty of genuineness when an editor modifies another editor's comment, so too would it not be sufficient when an editor modifies her own comment. --Atethnekos (talk) 20:16, 1 October 2013 (UTC)

So, the argument is: yes, both of those things (editing by the initial author, and editing by other people) generate the same discovery process, but only one of those is expected behaviour for non-wikimedians. People tend to expect they can edit their own submissions, but not that others can - and I'd argue that actually even on Wikipedia, we tend to be pretty surprised when people make substantive changes. If you take a look at the use cases at w:en:WP:TPO, almost all of them are minor fixes (typos, signature misses, etc).

Personally I'm not entirely sure if I'm convinced by this argument - but it shouldn't matter whether I agree with the argument, in the sense that 'this makes things more complex' is self-evident. Editing the comments of others increases complexity. Now, what's important is that we weigh that against whether there are actual, substantive types of editing the comments of others that are important, common and wouldn't be allowed by Flow as it stands at the moment. That we make a decision based on accurate info about both the positives and negatives of each option. This page/discussion is an attempt to gather every plausible example of editing the comments of others, in the hope that we/I can evaluate how much they happen and whether we deal with them. If we find a situation where, actually, it's really important to have comment editing and we can't have discussions without that situation coming up, we can discuss nixing this idea. Ultimately this early development stage is about experimentation, trying to find what works, and what doesn't. If there's evidence this won't work, it won't work :). Okeyes (WMF) (talk) 21:03, 1 October 2013 (UTC)