Talk:Flow

Jump to: navigation, search

The Core Features team has enabled Flow on this talk page.

Previous feedback is on Talk:Flow Portal/Archive2 (using old Liquid Threads), and on our labs server.

 
Newest topics

Does it has to be so hideously ugly? Or is it just a bonus?

Reply • 2 comments •
2
Felis domesticatalk contribs

Apologies if the question was posed before, but after 15 minutes or so, this modern page is <<still>> loading, so I can't check.

I did manage to guess that this tiny three-line icon near the humongous topic header A) is not just a blob B) may actually show the list of topics (which in the "old" and "user unfriendly" discussions were simply and clearly listed, allowing easy navigation). Note: I wanted to mark the word "still" by adding bold, but is seems that it is not allowed / I can't find the proper tool/icon for it (so much for user-friendliness).

Back to the original question: huge headers, small icons, no list of topics, no easily accessible editing/formatting tools. These are my impression of the "improved" system. Call me grumpy, but - at the first sight - can't see any improvement.

Quiddity (WMF)talk contribs

There is still a lot of work to do, with many missing fundamental features, and some needed design changes, which is why the dev team are not calling out for massive quantities of feedback, yet. (But the constant slow&steady stream of editors discovering it, is good)

Much of the documentation also needs to be re-organized and/or updated, but you can see some of the planned features at Flow/Release_planning, and that, along with the other main Flow pages, should be massively updated by the end of January.

Specifically:

  • The WikiEditor toolbar is coming. (phab:T78346)
  • They're working on a custom Table of Contents, which should be live in early January. There's a version with a few bugs, at http://flow-tests.wmflabs.org/wiki/Talk:Sandbox
  • They're also working on a built-in powerful search system. See design proposal notes at File:Flow-search-details.pdf, and detailed discussion at this mailing list thread. (People discuss things anywhere they're announced... Herding cats editors to a single discussion location is nigh impossible. :-/ )
  • The headers probably need to be re-examined again. I've re-opened phab:T61636.
  • Examining the performance (particularly on older computers) is on the regular-priorities list.

Thanks for the feedback, and I hope that helps.

Reply to "Does it has to be so hideously ugly? Or is it just a bonus?"

We don't want to be bothered with improving Wikitext, that's not sexy enough.

Reply • 4 comments •
4
Sänger S.Gtalk contribs

I included this paragraph in the Mission part of the Flow page here, as it seems to be one of the main reasons for it:

;We don't want to be bothered with improving Wikitext, that's not sexy enough.

Most of the things we pretend to be possible only with Flow could as well be done with regular discussion pages, but we had to listen to the communities if we did that, and we had to make improvements to an existing and very productive system, that's simply not sexy enough for all of us programmers here at the WMF. Developing something new from scratch, and ditch the communities, is much more fun.

It was reversed as being an insult and an impersonation. OK, it was kind of an impersonation, as the devs didn't state it explicitly, it's just emanating from most discussions about Flow. Whether this for people outside the ivory tower of SF seemingly accurate observation is an insult, I can't say, I think it definitely looks like it's true.

Halibutttalk contribs

IMHO extensions such as this one (as limited as it currently is) are a great way to fix what is wrong with the communities you speak of. And the most important problem is that they are shrinking. Some faster, some at a slightly slower pace, but still.

If we don't do something about how sexy Wiki editing is, we'll end up in the same club of 1000 nerds from all around the world who don't mind learning the HTML-inspired wiki markup and who bark at newbies just because they expect something easier to use. The same was true to visual editor: most Wikipedians out there criticised it because they do not need it - completely missing the point that we need new people in the project.

But perhaps it's just me.

Eirikrtalk contribs

Can you articulate "what is wrong with the communities" discussed here? Personally, I haven't run into anything particularly "wrong" with the EN WIKT community. It isn't huge, sure, but then it never has been, at least for the years I've been involved (some activity in the first half of 2006, then a hiatus until end-2010, participating off-and-on since then).

If what is wrong is not clearly defined, we have no objective measurement for discussing how effective Flow is at "fixing" anything. All we have is our subjective reactions to our experiences using Flow.

About "shrinking" communities, I myself have participated much less in the EN Wikipedia over the years, in large part because it's mostly done -- any of the articles that I might think of to write, have already been written. Maintenance is much less interesting, and requires fewer people. A shrinking editor base at this point is not a problem to solve, and is instead both expected and inevitable. This is part of the natural progression of any encyclopedia project: once the articles are written, you don't need lots of editors anymore, beyond a relatively smaller group to maintain and update existing material. This latter group also often requires a different set of skills and interests than the group who writes the articles initially.

I fear that Flow is a response to the latter issue (i.e. developers have grown bored with maintenance and are coming up with solutions in search of problems).

Back on topic, your post suggests that one of the things you think is "wrong" is that we have a shrinking editor base, and that "we need new people in the project". Can you explain why? And can you explain any other issues that are "wrong", that Flow might somehow fix?

Sänger S.Gtalk contribs

Can you somehow show how the behavioural problem of the communities could be resolved with some new gadget, that's extreme restricted, not flexible at all, absolutely unconnected to the rest of the pages, just a useless, popped-on forum-thingy?

The problems of the shrinking editor numbers have nothing to do with the quite easy to fathom behaviour of the software, but with the quite hard to fathom behaviour of the community using this software. If you want to improve the numbers of editors, the last thing you you should look at is the software, that's next to completely irrelevant.

Of course that's nothing the hordes of programmers living from our donations can do that good, more professional community relation management should be employed, and the programmers should first of all maintain and improve the existing, really well working, infrastructure. But as I said: It doesn't seem to be sexy enough for those living from our donations to do such menial tasks like maintenance and evolutionatry improvement.

Reply to "We don't want to be bothered with improving Wikitext, that's not sexy enough."

Previews

Reply • 3 comments •
3
Hhhippotalk contribs

I see it's now possible to see the edit box and the preview at the same time, which is great. However, in this state the "Preview" !button is called "Keep editing" and its function is to hide the preview. That label doesn't make sense any more, since I can now keep editing without pressing the !button. The function is not too useful either, what I'm more likely to want to do is to update the preview after some editing, not to hide it, but that requires two clicks of this !button (and moving the mouse to find its new position in between).

Also: what's the rationale for hiding the "Cancel" !button while in preview mode? I now have to klick "Keep editing" to reach "Cancel", that's a bit like clicking "Start" to shut down the computer...

Is "Add topic" a good label for the submit button? That could be interpreted as "start yet another topic". The corresponding button on wikipages is called "Save page" (and looks like a button, yes we can!), so to be consistent I would suggest "Save" here.

Jay8gtalk contribs

Yeah, the button setup doesn't really work any more. The keep editing button is unnecessary now, but, as the preview doesn't live-update, a preview button is still needed and it is silly to not have the cancel button. The buttons now shouldn't change from editing to preview, as they do in the standard wikitext editor.

Quiddity (WMF)talk contribs

Sadly, this was accidental. But I've encouraged them to keep going, rather than 'fix' it! ;-) phab:T69258

Re: button labels, I've filed phab:T78580. Thanks.

Reply to "Previews"

Timestamps

Reply • 2 comments •
2
Hhhippotalk contribs

Both here and on enwiki, the absolute timestamps I see on mouseover are in my local timezone (UTC+1) and in 12 hour format. My preferences on both wikis are set to show server time (UTC), and all other timestamps (including the example given in the preferences) are in 24 h format, so I'd much like Flow to behave the same.

Quiddity (WMF)talk contribs

I've re-opened phab:T61919

Reply to "Timestamps"

Too slow to use

Reply • 4 comments •
4
31.50.70.172talk contribs

Hi. Have come here from en.wiktionary, where the introduction of Flow is being preliminarily mooted. I tried the Flow sandbox and, while the UI seems okay (certainly better than LiquidThreads), it is appallingly slow and unresponsive for me. I am using Chrome on Win7 64-bit. Computer is a few years old. When I click a button, such as "Post" or "Hide", it takes 20-30 seconds to respond. There is also no visual cue (such as a change in the mouse cursor) to indicate that anything is going to happen at all.

Eirikrtalk contribs

Testing in up-to-date Chrome 39.0.2171.95 on Win 7. Clicking Add topic took around six seconds. This is far too long to leave the user with no indication that anything is happening -- no on-screen progress, no change in the cursor, no indication at all that the website even registered the mouse click.

Eirikrtalk contribs

Clicking Reply in this thread took around 1.5-2 seconds. Better, but still too long with no indication of any change.

Quiddity (WMF)talk contribs

Working on the performance is an ongoing/constant task; but I believe they plan to concentrate on it specifically, in the near future. Thanks for the detailed feedback.

Reply to "Too slow to use"

Where is the discussion of whether Flow is a good idea?

Reply • 10 comments •
10
DCDuringtalk contribs

I have seen lots of discussion about how to implement "Flow" and I have read the rationale. What I haven't seen is any evidence that there is a net benefit to any concrete version of the ideal. Where would I find that? BTW, do I have to drink the kool aid to get notification of any response to my questions? Can I get an e-mail?

Hhhippotalk contribs

Due to causality constraints, evidence that there is a benefit of a software version can only manifest itself after that version came into existence. You can configure your kool aid consumption under Preferences > Notifications.

Eirikrtalk contribs

I hope your rejoinder is in jest? Surely there must be a specification somewhere? Or is Flow being implemented entirely willy-nilly, with no consideration of requirements or usefulness? That does not inspire confidence.

Sänger S.Gtalk contribs

I think the main reason is, there are so many software developers over there, with so little experience as wikipedians, the somehow have to be occupied. And instead of looking for improvements of the good existing software, they are more interested in developing completely new one from scratch, regardless of the usefulness. It seems to be the more interesting way from their perspective, but it's of course absolutely detrimental for the Wikiverse.

They no longer know that they are only the support organisation for the communities, and have to listen to them, definitely not the other way around.

Quiddity (WMF)talk contribs

DCDuring, you can see some recent user testing videos (and notes) at Flow/Moderated Testing, November, 2014: talk pages and Flow. The index of everything, is at Flow/Pages.

The overall idea of a more intuitive, and structured, and powerful discussion system, has been suggested since at least 2004. The overall idea of a less-complicated and more-powerful workflow system is regularly discussed when bots break or fail, or when editors are overwhelmed by the (needlessly) multi-step processes that many wikis use for various tasks, or when smaller wikis try to implement/import the heaps of templates/bots that the larger wikis rely on.

For working examples, the French Wikipedia has been trialling Flow in a secondary fr:Wikipédia:Forum des nouveaux/Flow (newcomers helpdesk) for a few months, and the Catalan Wikipedia has just revived their (dormant for a few years) ca:Viquipèdia:La taverna/Tecnicismes (Village Pump (Technical)).

Flow is not even close to its final state. There are a lot of features to build, and bugs to fix, and design elements to discuss. The more constructive feedback/requests/suggestions that come up over the coming months, the better. The team is starting with the basics/foundations, and building towards the complex.

Eirikrtalk contribs

Could you provide a link to any kind of roadmap or schedule? Flow first appeared on my radar in wikt:Wiktionary:Grease_pit/2014/December#The_process_of_converting_classic_talk_pages_to_Flow this post to the EN Wiktionary Grease Pit, in wording that made it sound as if Flow were soon to be implemented for all Talk pages. Is installation of Flow on all MediaWiki sites an imminent inevitability? Where do we, as community members and not devs, find the roadmap, the requirements, the design specs?

Sänger S.Gtalk contribs

Do you regard it as "constructive feedback" if you're told to stop wasting resources, both money and manpower, on this futile gadget and try instead to do something for the communities, like improving the existing and quite well working wikitext?

Quiddity (WMF)talk contribs

@Eirikr: The short-term roadmap is already outdated, but lives at Flow#Roadmap. Danny is working on updating that, over the Christmas period. The longer term roadmap of planned features is roughed out at Flow/Release planning, and updates for that are also being worked on. The best way to get updates (once I start writing it again) is to add your username or local Villagepump to w:Wikipedia:Flow/Newsletter.

The wording that Gryllida used at the original request was quite a bit too brief, and confused many people - it is not rolling out widely anytime soon.

Quiddity (WMF)talk contribs

@Sänger S.G: That is fairly polite feedback, and comments on the software-options, and doesn't ascribe hypothetical motives to people, all of which I appreciate.

Many other editors (including myself) are cautiously optimistic about the long-term potential of Flow, so I would disagree that the extension could be dismissed based on its current lack of magnificence. I agree that wikitext works quite well, at least for power-editors, and newcomers who are willing to learn about replying to *:::::odd indents, and watchlisting everything, and where to reply to usertalk questions, and etc... But I think it could be massively improved, and not just by adding more band-aids to the existing system; and I think our workflow systems could be massively more powerful, enabling editors to accomplish more, with less manual labor.

Just like small wikis and stub-articles often start out imperfectly; so too does software. Mistakes will be made along the way, but they will be examined/discussed/changed, slowly and steadily. Eventualism got the wiki-contents, and the hundreds of extensions and features in core, to where they are today. Eventualism is what keeps us (and me) going.

197.133.255.227talk contribs

خطهميل

Reply to "Where is the discussion of whether Flow is a good idea?"

Notifications

Reply • 2 comments •
2
Hhhippotalk contribs

Something's fishy with the notifications. I just found my Echo counter at "1", probably trying to notify me about the creation of this topic, but there was/is no message about it.

I got a new watchlist entry for it, but not boldfaced (they never are, probably not using the right css class).

Quiddity (WMF)talk contribs

Filed as phab:T77956. Thanks.

Reply to "Notifications"

Any news about this words from Lila?

Reply • 12 comments •
12
Sänger S.Gtalk contribs

Lila said about a month ago this on her talk page on meta about the development of Flow:

As you know I am holding back planned roll-out of this feature pending internal review. What I am seeing above is that many requirements requested are satisfied by it at the expense of losing features some of you consider critical. I am asking for a full list of use cases that are to be/not covered and clear roadmap of those and will invite you to review. -- LilaTretikov (WMF) (talk) 18:32, 5 November 2014 (UTC)

I fail to see any new green hooks on the other side here lately. Do I get it right, that development has stalled until this is straightened?

This comment was hidden by 2601:B:C700:28:AB9B:ABAB:931C:5A36
Mattflaschen (WMF)talk contribs

Software development is continuing. Wider rollout (to major projects like English Wikipedia) is a different issue with a different timeline.

Sänger S.Gtalk contribs

So if it's continuing, what was the result of those internal review? Flow is still just a rather useless blahblah-thingy, nothing really to brag about. In it's current state it's completely unthinkable to let it be anywhere on real talk pages. It fails to have any plus compared to normal talk pages. It brakes some must-haves completely.

I'm afraid, the WMF gets so deep invested in it, they will deploy it regardless of it's usefulness, just to sanctify the massive expenses in money and/or manpower (which to me seems to have been the main reasoning behind superputsch against the communities with MV).

Edith asks: Why didn't you just edited your first post, instead of hiding and reposting? Ah, I forgot, such simple tasks are beyond this software capabilities.

Mattflaschen (WMF)talk contribs

I accidentally uploaded it while logged out. Neither wikitext talk pages nor Flow allow you to change the author of a previously made edit/post from an anon to a logged in user.

Editing a post without changing the author is already possible. In fact, you edited the post I'm replying to.

Sänger S.Gtalk contribs

On a normal wikitext page you had simply edited the previous post and made clear that it was you, for example by changing the sig and making some explanatory remark.

Here you had to write it again and hide the old one (that still remains there as a stumbling block). You probably even had the same IP as Mattflaschen (WMF) as in the first post, but still couldn't just edit.

Quiddity (WMF)talk contribs

Someone suggested that we should have a time-limited (perhaps 30-60 seconds) "log in and claim this post as your own" for IP edits, if the IPs match. I'm not sure if that's technically possible, or what drawbacks there might be?

EBernhardson (WMF)talk contribs

The main concern is phones, i would have to check with oliver but he was complaining before about how his analytics data had tons of phones all behind the same ip due to proxying.

Diego Moyatalk contribs

Time-limited anything is terrible from an accessibility standpoint. People with disabilities using special input hardware, or merely accessing from a very low connection may find themselves easily exceeding the timeout.

The ability to claim another post's authorship or reshape it in any way should be always present, for any user, and easy to undo to revert possible abuse. That's the way of the wiki, it has served us well for years.

Sänger S.Gtalk contribs

But the guys at WMF claim, that he wiki-way is far too difficult to handle for all those dumb users out there, and so they want to eliminate it and put something like this there instead.

Everytime the absolutely required minimum requirements are mentioned, and that's at least all and everything the current discussion pages can do, especially the complete flexibility, they evade that requirement and how to implement it in this obviously extreme restricted software experiment called Flow by invoking some distant future when this will al fall into place.

Given the hostility and brutal force they used to force the MediaViewer against the explicit wishes of the community, a lot of people are rightful anxious that the same will happen with this piece of software again. They don't care about the community. If too much money and "Herzblut" was invested in it, they will use force, full stop.

Quiddity (WMF)talk contribs

The internal review is scheduled for this week. I'll ping you when there is more news on that.

Sänger S.Gtalk contribs

Your "this week" was last week, so where is the review?

Reply to "Any news about this words from Lila?"

Changing Titles does not work, or does it?

Reply • 3 comments •
3
194.25.30.10talk contribs

Teststeps: use "..." next to a title, select menu entry change title. Result: None. (Title remains unchanged, no entry in history is made) Expected Result: Title is changed, an entry in the history is made. Completley unexpected result: On rerun of testcase the changed title is shown to user in the edit control to change the title.

Hhhippotalk contribs

I could change the title without problems, but for some reason that change is logged in the board history, but not in the topic history.

Quiddity (WMF)talk contribs

Filed as phab:T77957. Thanks, both.

Reply to "Changing Titles does not work, or does it?"

Community Liaison job openings at WMF

Reply • 4 comments •
4
Quiddity (WMF)talk contribs

There are currently 2 job openings, and I thought someone here might be interested. Specifically:

  • Community Liaison - this position will initially focus on working with the Flow team and also with the Editing (VisualEditor) team, mostly at non-English wikis; however, a lot of smaller or short-term tasks continually come up, so the WMF is particularly looking for someone who is adaptable, and with diverse interests.
  • Community Liaison (Part time contract) - this part-time position will primarily focus on working with the Mobile teams, as the link explains.

If you need further information, feel free to send an email to cep@lists.wikimedia.org (but do not use this address to apply). Please pass it along, if you know someone who might be interested or a good fit for the Community Engagement team. Thanks!

Sänger S.Gtalk contribs

Are they meant to get some input from outside the ivory tower to the WMF, to finally make them do something for the communities and give the communities at least some input, or are they just meant as salesmen for the useless stuff WMF want to push down the throats of the resistive communities?

Gryllidatalk contribs

Both.

Quiddity (WMF)talk contribs

I've answered in depth, at the meta thread.

Reply to "Community Liaison job openings at WMF"