Talk:Flow Portal
 |
NOTE: the discussion system in use on this talk page is not Flow. It is LiquidThreads, an older threaded-discussion system that happens to be used on this MediaWiki wiki. LiquidThreads has nothing whatsoever to do with the new Flow system. |
- [History↑]
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Flow is too tall | 0 | 08:14, 21 May 2013 |
| Avatars | 9 | 03:58, 21 May 2013 |
| Auto-archiving | 23 | 00:26, 21 May 2013 |
| Accessibility: JavaScript, screen readers, slow connections, etc. | 11 | 23:24, 20 May 2013 |
| Discussion about Flow on EN Wikipedia | 0 | 22:54, 20 May 2013 |
| IP editors | 5 | 19:54, 19 May 2013 |
| Strengths of existing system | 10 | 19:46, 19 May 2013 |
| Ugh, change | 4 | 19:36, 19 May 2013 |
| The whole concept seems to be based on wrong assumptions | 3 | 00:57, 16 May 2013 |
| Numbered lists | 5 | 18:47, 15 May 2013 |
| EN.Wikipedia's use of talk pages and this new FLOW | 3 | 18:45, 15 May 2013 |
| LiquidThreads? | 17 | 18:37, 15 May 2013 |
| Some feedback | 2 | 18:36, 15 May 2013 |
| Bot messages | 2 | 18:36, 15 May 2013 |
| Badges, barnstars... | 1 | 18:36, 15 May 2013 |
| Discussion vs. thread and post vs. comment | 2 | 18:36, 15 May 2013 |
| The problem of threads' homes? | 2 | 18:36, 15 May 2013 |
| "Stale watchlist entries" | 2 | 18:36, 15 May 2013 |
| Will Flow be for user talk pages ''only''? | 3 | 18:36, 15 May 2013 |
| Comments protection | 5 | 18:36, 15 May 2013 |
 First page |
 Previous page |
 Next page |
 Last page |
My biggest concern with the interactive prototype (a concern I share with LQT) is that the individual posts/replies are way too tall. The current colon-based wiki discussion system is well suited to a high volume of short posts, which is what usually occurs on wiki talk pages. Flow looks as if it will be more oriented towards fewer but longer posts, more like an online forum.
Facebook handles this quite well, using a compact style for comments which allows many to be seen at once (although the font size is too small for our purposes).
I am worried there will be a large community backlash if discussions will take twice the screen real estate. It is already hard enough to skim posts on very-high-volume discussion pages like w:WP:ANI, and it would become quite frustrating with the proposed Flow layout.
I know that the topic of avatars has been discussed already, and really, I can't see at all how it could work. We have an enormous amount of users, from a huge amount of cultures. Some users might react to someone's avatar in ways that would damage the community's ability to work together. Throwing in someone's personal identity into every post is asking for trouble. Most users are anonymous, and people like this. And some users are minors. How would we manage if all our younger admins/bureaucrats/developers/editors had their face attached to their comments? I don't even know if it would be legal. Loads of older users would immediately start behaving differently toward them. And what of our many users who don't look, say, respectable, to certain other users? We have enough drama as it is. Please don't add to it by attaching bad first impressions set by whatever prejudices users inherit from the cultures they come from.
Having no significantly visible external identity is kind of important for Wikimedians to work together. In some communities, personal stuff is actively repressed. On the English Wiktionary, userboxes are prohibited. I wouldn't be surprised if some communities banned mentioning one's real name. Anonymity is valuable, and the fact that currently barely anyone knows each other's names or genders is a plus. Avatars would throw all that away, and for what? What's the potential benefit?
I have no issue with avatars. Avatars are graphical representations of how a person feels about themselves. I'm a member on many forums that use them, and I have never seen it as an issue. The Stack Exchange networks are a fairly well known non-social media that uses avatars. All of the social media sites allow this. My concern and proposal on the matter is this: If the avatars for people are hosted remotely, like how the avatars shown on the SE networks use W:Gravatar to host the avatar then that would probably be fine. If the WMF site had to hold them, it opens the door to all kinds of copyrighted images and other legal concerns that I would be opposed to having to have a group of users to "play God" and decide which ones are fair and good and which ones aren't.
If you don't want an avatar, then just upload a blank white square as your "picture".
Ummm... Wouldn't it be more appropriate for it to use a default shadow-head and not upload anything if you don't want an avatar?
Main problems with avatars:
- how much space they take up on a screen (ie. this thread would be a few inches longer, if we all had 200x200px images. The entire page would be vastly longer.)
- knee-jerk / subconscious reaction to image content (as well-expressed by Yair rand, above. Personal photos leads to easier Ageism/Racism/Sexism/etc)
Lesser problems:
- policing content (there are going to be thousands of people choosing borderline-offensive/inappropriate images. Pixelated porn. Photoshopped celebrities. All with plausible deniability and hence lots of arguments. Plus the thousands of national flags, team/company logos, hilarious lolcats, etc.)
- distracting visuals (even if we ban/disable all gifs/apngs, a sea of garish colors is not helpful)
- updates/changes (Will all our saved (old) comments get changed if we update/change/delete our avatar image? Or will we have users who have a folder of avatar images that they choose from (for each post they make) based on mood/context?)
I'm sure there will be an option to "Turn off avatar images", but I'm very worried about leaving "avatars-enabled" as the default. The text-only style of Liquidthreads/reddit/metafilter/etc seems much safer and preferable.
(The same goes for garish colorful signatures... I was hoping to see the end of these. Personal-aesthetics should be confined to one's own userpage, not forced into every discussion thread.)
Lastly, where was the older discussion(s) about Avatars? Thanks
Just going to drop a quick comment here about signatures: Flow will disable "garish" signatures. We'll probably want to have an option for you to display a different "text" name instead of your actual user name (so I could be "Brandon Harris" instead of "Jorm (WMF)") but not allow for wikitext, html, or (especially) templates.
Please explain that better? Flow will disable custom signatures?
Correct.
I'm not sure where this talk of Avatars is, but I want to bring up two points:
1) Commons' incoming image vetting system is overloaded, with far too many things falling through the cracks (both copyvios not being spotted and legitimate images not being properly categorized so they can be found later). English Wikipedia's incoming image vetting system is critically overloaded, as it has only a tiny fraction of the number of image workers Commons does, but the second highest upload rate across WMF all projects. If users are able to upload avatars locally, image workers, already strained, might buckle.
2) The "policing content" and "distracting visuals" comments from Quiddity in this thread are valid points in need of serious consideration. English Wikipedia, at least, already has enough enforcement problems and wannabe dictators to cause tension, and... well... also massive numbers of vandals.
Please take these things into consideration.
Auto-archiving is a horribly unflexible solution which is suitable only for the least active talk pages; please elaborate on what methods of archiving will be available. Cf. bugzilla:24815.[1]
I think we have different understanding of "archiving".
In this case, by "auto archiving", we mean "it gets old and falls off the front page". There is no real explicit "archive" action that will cause something to disappear; all the content remains you just have to keep paging (or scrolling) through the timeline to get to it. Or search for it. Or one of several ways to find it.
"Manual Archiving" in this case is going to be like "hatting" a thread: you close it to new replies, drop in a summary as to why, and that's that.
Yes, that's the auto-archiving that I was referring to, and it makes the system unusable.
I'm. . . totally confused. How does this make it unusable?
Have you ever used feeds before? My twitter stream auto-archives. You get to the archives by scrolling. They're there. They're not really archived; they are just lazy loaded.
Yes and I hate it, but I don't have to work on it, it's just chatter. What you're proposing is the same in LQT, so I'm not going to repeat what was already said for LQT; just see the tracking bug above. This loss of functioning may be ok for user talk pages, but if you think this flow system might ever be used elsewhere I suggest you to put more thought in this or it will bite hard later.
I don't see any problem in an inactive discussion getting off the main page automatically. What really bothers me is when someone "lock" a topic to new comments just because it has being inactive for N days. Actually, usually I don't see a reason to close a topic to future comments. This just forces people to create a duplicated topic to discuss the same thing (instead of just adding a comment which would make the topic to be moved to the beginning of the list again)
Would a more intelligent way to link to the previous discussion (or even just pull it back into the new one) help with that? Things are archived, but it doesn't necessarily mean they aren't still worth discussing, indeed.
I agree. A feature that automatically suggests possible duplicate topics would be ideal to solve this problem.
I agree with you Helder, topics/discussions should not be locked for inactivity or because immediate consensus is one way or another (I've seen some that are closed in less than a few of hours which prevents people in other timezones from contributing and effectively excluding them).
On the contrary, auto-archiving is arguably unnecessary on less-active talkpages... it's the more active ones that could sometimes not even function without it. Currently the solution is bots and they work fine, but they needn't be necessary...
But this would be just like with bots, far as I can figure. Falls off the page, goes away, call it what you will, but it will still be accessible... Whatever the case it was not being edited or nothing added, so the discussion is clearly done, even if it is just because everyone was ignoring it. But not archiving it wouldn't make them not ignore it, unfortunately.
Might need to consider something to make some threads sticky, but that will be a later consideration.
No, that's not how it works. Bots archival is often incorrect, so such bots are sometimes reverted and need templates to ask archival or prevent it. Still, they're waaaay more flexible and efficient than the "auto-archival" as commonly meant and as implemented in LQT.
I'm not going to repeat everything: don't be lazy, read the bugs against LQT, I've triaged and organised them and it was enough of a waste of time. I've no idea who's responsible for designing Flow but it would be a suicide to ignore the experience we've got with the LQT attempt to replace wiki pages.
I honestly think we're talking past one another.
Exactly, that's why you should look at more opinions by using bugzilla. :)
On the contrary, bots are, by the large, just fine, and some projects at least (Commons and enwp come to mind, mostly because they're the only ones I really use) would be kind of horribly massively screwed without them. Like... they wouldn't function. At all. Now sometimes bots do mess up, but that's what overrides are for, and no viable system would be without the ability to override the automatic or specify different archival periods/rates for different pages. MediaWiki is all about overrides; the key is to figure out which overrides are actually practical without overwhelming the users and all that jazz.
Flow is not going to be LQT. It may share some features in common, but there are many more mistakes to be learned from and avoided.
I'm not sure I like where this is going... There are some cool features and improvements over the current system, I agree. I have an apparently "unusual" method of archiving discussions on my talk page on Wikipedia. I have a set of tabs, and on my "talk" tab, I've created a ToC that will allow you to quickly and easily navigate to conversations by year. My actual "talk" page is really a re-direct to the current year's discussions (User_talk:Technical_13/2013 for this year for example). How will this new system get along with the archival system I use? Will I be able to opt out of using this system on my talk page if they don't get along?
I'm sorry to say but no, your set up will no longer work. It may be possible to transclude your Flow board into a page (and this is expected to happen) but at the end of the day the purpose of this project is to help standardize communication and collaboration mechanisms, not allow them to become further fragmented.
Your archival system, as described, will be obsoleted and not required.
As far as opting out, the roll-out plan has not been finalized but you should expect that this system - or one like it - will eventually become mandatory. When that will be I do not know.
I have a couple of accessibility concerns.
First: Users, for myriad reasons, such as ancient hardware or non first-world connections, often disable JavaScript. (Looking at the discussion at en:Wikipedia_talk:Notifications/New_message_indicator#The_bigger_issue_here:_Javascript, I can count at least six frequent editors whom this will affect.) I can say that, while this page is not impossible to use with JavaScript disabled, it is nearly unreadable. Every section displays as one undifferentiated blob of text. Nevermind, this is LiquidThreads, not Flow.
Furthermore, I worry about blind users with screen readers; from what I've seen, they have had challenges using some of the recently rolled-out changes, and it would be depressing if Flow didn't work properly for them.
Lastly, I worry that this will affect users with slow connections. Wikipedia is used throughout the world, but it is my understanding that broadband connections are only generally available in non-rural parts of North America, Europe, and Asia.
By "this page" do you mean this talk page, Talk:Flow Portal? This page is using Extension:LiquidThreads, not Flow. (I don't think a deployable version of Flow exists yet.) Your concerns are good ones, though – I too worry about how usable Flow will be without JS.
I had some fun a while back putting together CSS to make LiquidThreads look nice without the use of JavaScript; see w:User:PartTimeGnome/lqt.css. The format is of my own design – it doesn't look anything like the format you get with JavaScript enabled. This is only for people who keep JavaScript disabled; if JS is enabled my formatting will conflict with the normal formatting added by JavaScript and look thoroughly wrong.
Standard disclaimer: I've only tested this CSS in single browser; it might not work for you. I'm pretty sure some bits will look different in Internet Explorer, though I hope the appearance would still be better than it would be without it.
I tried out that CSS; it looks great! ( Using en:Iceweasel under en:Debian, if you're curious.) Suddenly, I can read everything without straining! :D
Hi everyone, I have some questions :)
- will there be a fallback skin for users who do not have Javascript enabled? I know a lot of them who complained about new features because they are more and more depending on scripts - and I loved Wikipedia for the utmost waiver of Javascript.
- I did not understand the project pages exactly - is there the possibility to subscribe only a user's board without receiving his contributions on other pages? I just want to follow the activities on his board (= talk page) just as watching it at present.
- A big problem will be the rights management. I'm sure there will be massive protest because users can not edit posts of other users. It is possible that an user only wants to do a spelling correction in another post, or an user wants to remove a personal attack. Also, there is a problem with "work lists" started in discussions, for example if somebody wants to mark a task another one started as done.
Please excuse my English :)
1) There will almost certainly be a fallback (though it probably won't be a skin - in mediawiki parlance, a "skin" is a very specific kind of thing). I cannot promise that the experience of interacting with the system will not be painful if you don't have javascript enabled - and it may very well be that you will not be able to edit or add comments without it (given our dependance on the VisualEditor). However, the best effort will be made.
2) That is the "minimal" case for subscribing to a user, perhaps. If we look at the maximal case of subscribing to a user, the following things could be important:
- New topics started on their board
- New topics that they start on other boards
- Topics they respond to in other boards
- Edits they make to articles
- Workflow discussions they start or get involved in (AFD, RFA, etc.)
As we go forward, we'll probably have to create a system whereby you, as a user, can have more fine-grained control over your subscriptions like this.
3) Rights management is an on-going discussion. We knew that restricting comment edit would be a Thing. But there are several routes to achieving solutions that are acceptable to the use cases we've identified.
One thing I can tell you is that we are planning for the idea of a "collaborative" post flag, which would allow for multiple people to edit it.
That is the most terrifying thing I have heard this week. Being unable to "edit or add comments" is tantamount to being forcibly en:WP:retired. I don't want to leave the project, but that would force me to, since I'd be unable to participate in the community at large.
I hope no one minds that I merged these two threads. They seemed to belong together, but I couldn’t find any documented etiquette for merging.
Yeah. I wish I could comment more about the non-javascript comment-adding part. This is really tied up in our VisualEditor functionality (which is Javascript only). I can see a case where we allow some commenting in "standard" edit modes but with a significantly restricted list of available wikitext (this is also dependent upon the parse). Honestly, it is too early for me to make realistic predictions about this.
(As far as merging threads goes, this is MediaWiki.org. It's like the wild west up in here, and BOLDness is appreciated.)
I still don't get why your're clinging to the VisualEditor when it's clear it comes with a huge amount of compatibility problems on it's back.
Why not sticking to the "good old" Wikitext or something compatible as a base and fix the Visual Editor to support all features? Then one could always offer both: The nice-and-shiny VisualEditor for all people with JavaScript and/or a reluctance towards source code; the lightweight WikiEditor for people without JavaScript and/or a preference towards markup.
Thanks for your answers. If the system is customizable, it it much better than a rigid one and will perhaps receive more recognition.
I think there are some really good approaches in this new software. For newer editors there are some nice new features like the "Welcome" mode. But I am sure that there will be massive discussions about the things Geitost mentioned above. I can imagine, and that's partially also my optinion, that users will refuse the new system because it is to "Facebook-like".
For minor fixes in articles, I can imagine using the VisualEditor, but I can't imagine writing long articles with this tool. Sometimes, I want to save a written text offline for finishing it later, and sometimes I do the same with discussion posts. The VE will probably not support that. And there are some other points mentioned in the discussions already, so please keep normal wikitext for everyone. Editors who ever used wikitext will be faster and better in using it instead of the VE. I can understand your technical concerns, I know how difficult backward compatibility can be. But wikitext is a feature that is essential for Wikipedia, you will offend everyone if you are removing it.
Regards,
Copied from [1] and placed here for notification.
From Flow Portal:
"At first glance, Flow is a next generation discussion system - but that is only one part of it. Flow is actually a rethinking of how we do collaborative work in the projects."
This whole thing worries me. Granted: The current talkpages with complex wiki-markup are very different from many other such systems on the web. However it is also something that I think is a deep-rooted part of Wikipedia culture. Yes, it has it's flaws, but editors in most cases find ways to work around those flaws. I fear that this change will alter the Wikipedia experience completely. I can only hope that the ultimate goal isn't to turn Wikipedia into Facebook. But, well, maybe that's just me and I already got too used to it and imagine an all too dark scenario....
Will this be enabled for "anonymous" users? (I just don't want a repeat of the disaster that happened with Echo when no one even thought about IPs.)
Yes, absolutely. They probably will not get feeds, however - just local boards.
I'm curious, how will notifying suspected IP vandals work? Will it remain the same, or will there be some changes needed? If there are changes that will need to be made, I figure we should discuss them now, rather than later.
The same as it works now. A warning is given to the IP user (on their board), they get an Echo notification, and can then go to the board and see it. It is not far removed from the current workflow with User Talk pages.
Okay, that's good! (I assume you mean "orange bar notification", since IPs don't have Echo.)
I didn't want to say "Orange Bar" because I'm not sure what the Echo team has planned for a long-term solution. Re-inserting the orange bar for IP users was (as far as I know) a temporary fix.
I would like to see a section on the main page outlining the strengths of the existing system, and what will be done to preserve them, build on them; or if they will be abandoned, why that is necessary or valuable. (I of course do not deny the major drawbacks, as described.)
One thing that comes to mind is the "talk page stalker" dynamic that so often leads to unexpected spontaneous collaboration. I'm sure there are others, but this one especially comes to mind. Under Flow, will there be an easy way to eavesdrop on, and jump into, conversations involving the people with whom you work closely, admire, etc.? If not, is there a solid reason for thinking that will be OK?
Every discussion that someone else is involved in would be tagged with their username, as I see it (just as logs are, if you want to search logs by user). So yes, you could visit the stream of just those interactions. Right now, you can in theory search an individual user's contribs by namespace and see all of their edits to [user talk] pages. In this setup, as I understand it, you would be able to search for all interactions between users involving that user. (effectively the same thing).
Yes but what's not totally clear is whether you can "subscribe" to the conversations of a user (messages to/from) i.e. "watch the user" (using the bugzilla term): this should be clarified. In theory it would be even easier with this proposed system, because – as you said – they're all tracked and they wouldn't rely on the fact that they happen on the user talk you're watching.
A requirement for this is that no such a thing as private messages/"notifications" exist. This is very important, and another thing that should be highlighted in the document. Kaldari said that only non-persistent messages are going to be private notifications, for instance "page A has been linked from page B" which adds nothing to page B's history; but this is not very clear/well defined in the document.
I'd like to clarify the things I'm interested in here. The order of these is significant, it goes from most general to most specific:
- The people undertaking a project to replace/upgrade a major software feature should carefully think through (among other things) the strengths of the existing feature, and whether or not they can be preserved.
- The people undertaking the project should put that analysis on display in a clear way (i.e., it should not be necessary for the reader/community member to dig through various wiki pages to learn about the fundamental design goals and the fundamental design challenges).
- Talk page stalking: probably too specific for this discussion; it was meant only as an example. (However, it may be worth noting that even after these explanations, I'm having a hard time picturing how, as an end user, information about my friends' edits and notes left for my friends would be presented to me.)
Pete, the monthly status says «Mid-month saw Kim Schoonover begin user research regarding how user-to-user talk pages are handled», so maybe by digging wikis, google docs, etherpads and mailing lists enough you may find the "strengths of existing system" documented somewhere.
Yes, you will be able to "talk page stalk" as it were. Even better, actually.
And I'd argue that there are no strengths of the existing system, only interesting work arounds for its flaws.
What is interesting or valuable about the workarounds? What do they reveal about how people prefer to collaborate? Knowing the way you work, I am sure you've asked questions like this, but I think your thinking on this needs to be on prominent display if community buy-in is desired. I'm not looking for answers here in discussion -- my point is that the description of the project needs to put this stuff on display, or nobody outside the core group working on the feature will understand or fully buy into its value, nobody outside a core group will be in a position to offer useful input along the way. I am pretty sure this kind of communication is the key to getting genuine community buy-in in the long run.
An example of the kind of overview/conversation-starter that works: http://lists.wikimedia.org/pipermail/wikimediaannounce-l/2011-September/000238.html and a helpful evaluation of what came before: meta:Talk:Terms_of_use#Reasons_for_the_New_Terms_of_Use
One of the things from the bare-wiki discussion method that I miss in LQT is the ability to fully edit other's posts, specifically signatures* and dates. I do this quite a bit when organizing old talk pages, with threads in incorrect pages, incorrect order, unsigned, unmerged, etc. Forgery needs not be a concern since the whole edit history is available, and small marks can be added to make it clear the date or signature have been edited, just like LQT currently marks that the content of a post has been edited.
* In LQT, a user can edit their own signature if they edit the post after it's first saved, but editing others' sigs would be a potentially useful feature, as described above. Dates can't be edited by anyone, apparently.
Talk page are used for other purposes in addition to sending messages to a person, or joining in a discussion.
In my own work in WP, I normally go to a user talk page when there is a problem with their contributions; what I will say there can depend very much on what else I find, first there, and then in their contribution history. The present system works extremely well for this., except when they delete things from their talk p., and if I suspect this, I need to check also their talk p. history.
There are also some people whose talk p. is watched by a very large number of people--sometimes several hundred , most of whom do not really plan on posting there, but want to see what is being discussed there, under the assumption that some of what they find out about may be interesting.
I'm concerned that the emphasis on specific information flow may be damaging to general project-wide awareness.
Absolutely valid point. With the current system I leave a message on someones talk page and add it to my watchlist to see if he responds. Often the initial question is solved but a very similar follow-up question by another editor is posted (but in a new section). If I had not watched the whole talk page (and I probably won't do this with the possibilities of the new system) I'd never know about this new question, which may be enlightening for me or easy for me to answer.
"Talk page are used for other purposes in addition to sending messages to a person, or joining in a discussion."
This first point is my primary reason for arguing that the "Board" remain distinct from the "Feed". The fact that Boards will be used as "quick glances" into the life of an editor is super-important to me. We have been discussing what other things might need to appear on the board in addition to discussions. Block noticies? If they are an administrator, should we indicate that they have performed administrative actions (e.g., "Bob blocked Vandal23342")? What about main space contributions?
These are the kinds of questions that we're wanting answers to.
(And, by the way, it is currently planned that deleted posts and topics will remain on the board, just noting that the topic was deleted and by whom. So you won't have to check the history to see that this has happened.)
"There are also some people whose talk p. is watched by a very large number of people--sometimes several hundred , most of whom do not really plan on posting there, but want to see what is being discussed there, under the assumption that some of what they find out about may be interesting."
This is exact and precise use-case for being able to subscribe to other users' boards. The Feed/Subscription model will actually make doing this easier, not harder.
The end vision of Flow is not to restrict information flow - far from it. And, in fact, the entire point of the project (from my mind) is to actually increase project-wide awareness.
Right now, if you want to see what's going on with the seven WikiProjects you're a member of, you have to go to seven different pages and see if they've been updated (or view diffs from your watchlist, which is painful). Think about a future point where new posts and new requests on those seven boards automatically flow into your feed. This increases collaboration power.
It looks like this more replaces existing talk pages than building on them, which I don't like. It seems as though it ought to be simple enough to build the GUI into a wikitext-based page that we experienced users could edit more comfortably, but evidently it is not.
Will wikitext still work in replies, or will we have to learn a completely different markup to use on talk pages? Is this still italic? TortoiseWrath (talk) 00:42, 5 May 2013 (UTC)
Oh crap, it's not necessary to sign my post with four tildes, it says. *hyperventilating*
...reverse chronological order? Why? I took to Echo from the first minute; this will take a while.
It's reverse chronological order by "last update" time. So the "hot" conversations float to the top. This is actually more natural than having to scroll to the bottom to see a conversation that you're involved in.
There's another reason why this is so: Flow boards and feeds are infinite scrolling. There is no pagination. So if we do a "most recent at the bottom", you'll never see it.
They use infinite scrolling? That is an interesting design decision. What was the basis?
Auto-archiving of topics and the ability to localize searches within the corpus of a single board, plus the expected behavior of re-structuring the topic stack based on last-modified timestamps. These things lend themselves to infinite scrolling architectures.
This is actually a very old decision.
When I came to Flow Portal I wondered. When reading the first two of the eye-catching headlines I was literally shaking my head and was just thinking "No! What's going wrong here?".
- "Users expect a modern and intuitive discussion interface."
No they don't! I (as a user) always loved Wikipedias concept of talk pages which is unique and unbeatable in it's simplicity. You write what you mean and it just works. No need for a blown-up messaging interface, just pure Wikitext. For their purpose the ucrrent talk pages are a perfect match.
- "Users are surprised by the cultural norms of the community."
Oh yes, they are! And it might be even a bit confusing in the beginning. But the longer one is contributing to Wikipedia the more one appreciates them. The "cultural norms" are a fundamental aspect of the Community. The fact that you can call it cultural norms should be enough to know that we have something great going. Who else ("normal" discussion forums, etc.) can claim to have an own subculture?
Talk pages made Wikipedia what it is today. The whole threaded mess you're planning will ruin it for everybody.
So, in order:
- "No they don't! I (as a user) always loved Wikipedias concept of talk pages which is unique and unbeatable in it's simplicity. You write what you mean and it just works. No need for a blown-up messaging interface, just pure Wikitext. For their purpose the ucrrent talk pages are a perfect match."
- I totally appreciate this; I enjoy the customisable elements of wikimarkup, and of talkpages as they stand at the moment. But it's worth appreciating that what a single user needs, be it me or you, is not a good predictor for what is needed overall: this is particularly the case when we're having the conversation in quasi-wikimarkup, on a wiki, between community members. By definition, we've limited the conversation to people who can handle and enjoy handling wikimarkup (or enjoy the things that come with it, anyway). For a look at how non-Wikimedians handle and approach wikimarkup and talkpages as they stand at the moment, check out the user tests we ran.
- "The "cultural norms" are a fundamental aspect of the Community. The fact that you can call it cultural norms should be enough to know that we have something great going. Who else ("normal" discussion forums, etc.) can claim to have an own subculture?"
- Also agreed, on the first point; cultural norms are a fundamental aspect. And they're fantastic, most of the time - but as you say, they're confusing at the beginning. It's challenging to get to grips with a site that has 10+ years worth of rules, norms and conventions. What we should be doing is going "okay, this is something people need to get to grips with" and helping them do so, not by reducing the complexity of the community, necessarily, but by reducing the number of other things they have to care about. Complexities around messaging - a communications mechanism for getting help with cultural norms, and understanding them - is an "other thing". It's something else that they have to handle while also getting to grips with policy, our internal slang or conventions, etc, etc. I don't think anyone is saying our culture needs correction: we're saying that we can help people best get to grips with that culture by reducing complexity elsewhere. Less complexity means less time spent figuring out messaging means more time to dedicate to culture, and having conversations about it, and understanding your way around the projects.
- As an aside, actually a lot of discussion venues and communities on the internet have a distinct subculture. Culture is, largely, a distinct way of representing and classifying experiences and elements through symbols, be those symbols slang, internal terminology, or attitudes. A lot of places on the net have this; just from the ones I'm involved in I can point you to b3ta and reddit, for example, which definitely demonstrate features of subcultures. It's not something specific to Wikipedia - and it's not something our talkpages have enabled. Our talkpages and their limitations have just been a vector for some elements of it to develop.
I don't know if you are right. Our talk pages are not necessary for a subculture to emerge – but I'm quite sure that they were an important factor in how our subculture actually looks.
Assume threaded discussion like they are on this page: They are boring. Only text, hard to read in my opinion, absolutely impersonal. Is this what you want a discussion on your talk page to be? Impersonal? It might be efficient for pure discussion (however I'm not even sure about that) but besides that it's even worse than classical forums where you have smileys and avatars to add something personal to your posts (but I don't thing this would be suitable to Wikipedia either).
If you're talking about user tests: Did you run tests on the new system you want to implement? I'd volunteer as a test candidate ;). To already share some of my frustration on threaded discussion (this is basically the first time I get in touch with LiquidThreads):
- I feel like a dumb beginner that is surfing the internet for the first time right now. I don't find the new posts (they are always hidden because they are too deeply nested).
- After reading new posts via the "you have new messages" link I still seem to have new messages, which I don't find though. Actually I forgot to click "mark read" so it probably still were the old messages (although I read them already twice: once on the new messages tab and once in the thread after somehow finding the correct thread again andclicking the "show N messages" link a few times).
- At the same time I'm not quite sure on which thread I'm actually replying (the new messages tab is just too confusing). Where is the direct link with the content just plain in front of me? Right now I'm missing my watchlist sadly.
- Just a few seconds ago I did a very bad error: I scrolled the page. I needed propaply 30 seconds to find the edit field again. It was somewhere "arbitrarily" hidden between a flood of posts.
Edit: It's ridiculous – I'm adding a reply but I don't see it. The replied message is still marked as new however. Where is this anywhere near user friendly? I'm considering myself very skilled regarding anything technical but I'm totally struggling with this LiquidThreads-thing.
Extension:LiquidThreads version 2.0 is a circa 2010 extension, which has ben discontinued. Its usage on the talkpage here (Talk:Flow Portal), is painful, and confusing, and you should pay no attention to it. Flow is a completely different code-base/project, that takes into account the lessons learned whilst creating LiquidThreads.
See Flow Portal/Interactive Prototype (IMPORTANT: Read the first introductory sentences, before clicking the "Open ..." link) for a demonstration of the rough draft of how Flow might work. Note that there's a specific subpage for feedback about that prototype, so don't just append your feedback to this thread ;)
Often, ad hoc polls are constructed when each user types # Support - ~~~~ or # Oppose - ~~~~ in the appropriate sections, resulting in numbered lists of all the supporters and opposers. Would this (or something similar) be possible in Flow?
Agreed. I think this is covered under Flow/Use cases.
See all the references to "voting" in that use case page. I know that we don't officially use the v-word for support/oppose discussion, but that's what it's referring to.
Yeah. I use the term "!vote" pretty often. The word "vote" is easier to understand than "enumerated option comment", which is the technical term for what we're talking about.
This doesn't seem compatible with the way that En.Wiki uses talk pages. I noticed this from something posted at enwiki's WhatamIdoing's user talk page.
How does this affect how WikiProjects are tagged onto talk pages, and how history attribution is also tagged onto talk pages? These wouldn't be discussions, but metadata for the article itself (like previous deletion nominations). If this were implemented, then it seems that each page should also have a metadata page for containing such information.
-- 65.94.76.126 22:21, 7 May 2013 (UTC)
Or talk page notices (circular discussion notices, off topic warnings, etc)
The demo seems to have a place for an introduction, which can hold this kind of stuff.
Yes, there will be a "header" section that will be editable and allow for tags and categories.
No. LiquidThreads will live or die on its own. The lesson learned from LQT is that it was too aggressive in what it supported and was supposed to do.
Unlike LQT, this is only targeted at User:Talk, not Talk pages and discussions in general, and addresses modalities that hurt user interaction (especially new users). Current wiki conventions to, for instance, replying to a talk message are quite unlike any other web affordance currently in use for user-user/user-group communications. Flow wants to address that while following the core values of a wiki (if you want private talk, take it to e-mail. That would not change).
It's not necessarily a complete replacement to User:Talk. The two might coexist indefinitely and that is not addressed yet in the Echo spec (currently its mostly a design spec with mostly high level engineering). Though the hope is that it will supersede it—at least in usefulness. And some "upgrade path" for those who want to move a user talk discussion to flow or "upgrade" their user talk should be provided.
Note: "upgrade" in quotes because on one hand while you gain some features esp. Echo integration, you do lose things like the free form format of Talk pages.
I hope this clarifies things.
Still, does it consider all the wishlists and problems with LQT (filed in bugzilla)? I don't see most of them here but they'd seem to apply, I hope I don't have to re-file/list all of them on this page. Cheers,
It does not consider all the wishlists/problems. However the lessons learned does apply.
There is no need to re-file/list those bugs because LQT is not killed off (just unsupported at the moment due to resource issues). Flow is a separate project from LQT/LQT3.
My fear is, and I believe it is a lot of other peoples fear, that one day LQT will be incompatible with some future version of MW. This would be an end of story for the wikis utilizing LQT.
However, my impression is that there are quite a lot them around and still counting. This is due to the fact that even the current life supported version of LQT is far better for talk pages than any other solution around (including plain talk pages with no thrills). Besides, LQT was and still is one of the coolest things that came out of development during the past five years.
Basically the problem is, and this is the major cause of emotions here, that all these wikis do not know what to expect with regard to LQT and are being left alone for quite some time now. They are stuck in the darkest uncertainty regarding their wikis.
LQT is beyond the point of no return. We know it, WMF knows it and this is the very big dilemma.
I won't go so far as to say that it is "beyond the point of no return," but I understand your fears and it's reasonable to have them.
I don't think the goals of messaging can replace LQT. In determining editor engagement and features goals, it was clearly obvious that user-user messaging is broken so a project was put in 2012-13 goals to address that. This has been named "Flow" and according to planning will not be worked on directly until early 2013 (all work beforehand is infrastructural, and UI/UX resources are prioritized around notifications).
I want to emphasize that improving User Talk (user:user messaging and discussion) is a fundamentally simpler structure of interaction and requirements than Page Talk or LQT which is many things to many wikis (from a Talk replacement to a full blown forum and discussion system). At some point, things move beyond user-user to discussions, and I (personally) think that LQT rework to incorporate the core architectural and feature changes (Echo/Flow/Global Profile) is closer to a solution here than upgrading/changing a user-user messaging system like Flow.
There are no formal resources for LQT development in this year's planning (there are no formal resources on Flow for half the fiscal year). However, the same people involved with Flow are the ones who have worked on LQT which means that there might be some design guidance and bug prioritization for what needs to be done here and it can be kept up-to-date. (I've tried to give the developer the freedom to update LQT code under the auspices of working on Echo and Flow.)
Be aware mediawiki.org currently uses LQT without any plans on that changing. So while it doesn't mean you'll see LQT on English Wikipedia any time soon, this should keep LQT tracking some of the new features being developed (notifications, at least). Finally, probably the best bang for the buck on LQT improvements would be after the new Visual Editor is integrated in MediaWiki. That won't happen until sometime in 2013 anyway.
As for the WMF resources and the mediawiki community at large. This is part of a large discussion on what is and isn't working with respect to integrating changes coming from the developer community, which is broken far worse with more extensions than LQT. I'll follow whatever comes up from that.
It's my hope that by placing the same people on both Flow and LQT, the developer of LQT will get some guidance on the the LQT bugs/features that should be dealt with.
The LQT developer is left alone without any support from community feedback, infrastructure/ops, and product design and development when it comes to LQT and LQT3 (which was a deferred project before I even joined the WMF). In the past, we've found that when left without support, projects have a tendency to runaway and/or never see the light of day. The WMF plans to not repeat these past mistakes in features (PendingChanges, LQT, LQT3) by providing that support on formal features going forward (AFTv5, Page_Triage, Article_Creation_Workflow, and the VisualEditor being examples of this new approach which will be applied to Flow and Echo this fiscal year).
My understanding is many mediawiki installs like LQT and would love to see some movement here. I have to squeeze this in with the reality of the resourcing here and other priorities. This is the best I can offer. (In terms of developers who know LQT, we are talking about a single part-time student developer.)
meh perhaps we should make a (maintinance) script allowing people to deconvert from LQT (dump all the LQT threads on talk pages), I imagine that would help stop the lock-in fears people have (which from what I can tell seems to be where most of the frustration is coming from). Even if people don't use it, its nice to know one has the option to disable LQT if need be.
"There is no need to re-file/list those bugs because LQT is not killed off". This is not a very satisfactory answer, bugs and feature requests have to be considered now for Flow, not just postponed to a mysterious future, or no, Flow won't incorporate the "lessons learned" at all. LQT has so far 121 "enhancement" bugs besides 141 bugs and many others nobody bothered to file. Please don't waste the time people spent on filing them hoping in the future. Thanks,
Yes, it's frustrating. :-(
But in addition to the bugs, LQT was built without considering the fact that as it is, it can't scale to the size/traffic to a major Wikipedia (for instance, English). That, among other reasons, is the reason that Flow is what it is.
The same people who worked on LQT and LQT3 will be working on Flow, so there is no reason they can't revisit LQT and back port those changes and give LQT some love.
…
One point of clarification. Messaging was determined as a "must have" by Product's 3-year plan to deal with Editor Engagement. Flow came out from that, not a determination to keep or abandon LQT. For the 2012-13 planning/goals, we added Flow at the last minute which is much more aggressive planning that normal (I felt we can safely do Notifications & Global Profile. The latter was pushed out and Flow was added.)
The worry is to continue or repurpose LQT to solve messaging goal would jeopardize actually accomplish that goal to within the aggressive timeline. I felt that it was more likely to accomplish some sort of messaging this fiscal year with the option of backporting to LQT or gradual improvement of Flow would be better than to try to shoehorn LQT and its baggage into the messaging problem.
Perhaps I was wrong, but scalability issues in LQT means that there's a lot more going on there that isn't as simple as addressing reported bugs.
…
Concerning your specific needs. Given that LQT has no official support this fiscal year, we should loop back into discussion concerning some way where community dev contributions on LQT can be incorporated without requiring oversight from the WMF. Theoretically the WMF could freeze on the current version of LQT.
Of course, since it's now all in Git, you can easily fork LQT or LQT3 and know that we can merge those changes back in when the WMF revisits LQT.
>Concerning your specific needs. Given that LQT has no official support this fiscal year, we should loop back into discussion concerning some way where community dev contributions on LQT can be incorporated without requiring oversight from the WMF. Theoretically the WMF could freeze on the current version of LQT.
Last time I checked, LQT was scary, and hence had essentially no volunteers working on it. (Or perhaps that's an artifact of the mysterious LQT3 that will in theory replace LQT which everyone is waiting for, and thus people don't want to work on the "old" version)
That's the point. One day Wikimedia announced LQT3 so everbody thought they will finally make it really great. And after over a year Wikimedia is cancelig the project and what is left is a non-working git-branch and nobody left for maintaining LQT2. That's a bit like walking half the way and then turning back to take the car and drive somewhere else. And we are standing here and no chance to get away. Somehow it's Wikimedia's fault that there is no further development. They took it and killed it.
I don't think its Wikimedia's fault neccesarily. They do not have a responsibility to develop every extension in existence. (I do think they have a responsibility (with in reason) to support volunteers doing LQT development (or more generally any development aimed at Wikimedia wikis)), but the fact of the matter is, with exception of a commit to make LQT work on postgress, nobody in the broader community is developing LiquidThreads whatsoever.
Well, here is some feedback. In short, I Oppose the Flow idea.
From the description, it sound too much like it will be exactly like a Google+ stream, mixing everything together.
- Neither indentation with colons nor signature requirements are opaque. They are different from other sites, but it is not at all difficult to grasp and get a handle on. There is plenty of documentation on how to do it, and it is easy to pick up from how other editors do it.
- I agree it is not 100% clear where to hold conversations. Most editors specify in their talk page where they want the conversation to take place. This shouldn't be an issue. Talkback templates do the job just fine.
- Knowing what a watchlist is is not as big a deal as it is made sound. Any editor wishing to seriously edit will find the outline of the star on the top of the page and realize it is for their watchlist.
Why the pictures? Are we a social network now? Will we be forced to add a profile picture?
This sounds a lot like it will take away some of our abilities to manage/moderate/deal with our talk pages. Definitely not good.
I would suggest the focus of flow be more along the lines of additional features, such as private messages, instead of increased user-friendliness. If flow is just for user talk pages, new editors will still have to learn how to use the current system for article talk.
I'm not advocating "if it ain't broke, don't fix it." Focus the features development on helping active, experienced users, not limiting them. The biggest problem with editor retention is not the difficulty of the interface, it is policy and the bureaucracy of WP that make it so unwelcoming. The steepest learning curve are all the rules, not the UI. Don't make it harder for experienced editors.
You've got to be kidding, right? "Talkback templates do the job just fine." No, they don't. They're garish and dumb, and you have to remember to clear them out manually or leave them cluttering your talk page. (By "dumb", I mean they're kludgy; they're a hacker's solution to a software problem.)
Everything else you mention resolves to "users will pick it up eventually". Sure, a lot do -- you and I are evidence of that. But how many give up in frustration before figuring it out? That's what we don't know. There are so many people with the knowledge and desire to help WMF projects, but they get intimidated by overly-complicated technical obstacles, of which there are many... and user-to-user communication is one of them.
"The biggest problem with editor retention is not the difficulty of the interface, it is policy and the bureaucracy of WP that make it so unwelcoming. The steepest learning curve are all the rules, not the UI."
You're only saying that because you picked up the UI easily. Not everyone is as adept as you or I. Besides, there's nothing WMF can do about rules; that's up to the individual editing communities.
Sorry for the late reply. Don't come to MediaWiki all that often.
No, no kidding. They do the job just fine. Now, that's not to say they could not be improved. I would like to see it so that something equivalent to TB templates is automatically inserted in a user's talk page when anyone comments or replies to that user anywhere on the wiki. They are very easy to use if you use Twinkle.
My biggest concern about this proposal is that usually, in software, when user-friendliness is increased, abilities are taken away from power users. Take a look at Ubuntu's switch to Unity. CCP's obsession in EVE with the captain's quarters. There are many, many examples. CCP had a bucket of cold water thrown on them when they realized how pissed off their users were. Canonical has yet to realize their mistake. The bulk of WP editing being done by experienced users, I think the focus should be on helping them. By no means am I advocating to leave things as currently are and forget the newcomers.
I did not pick up the UI easily. Take a look at my WP editing history on toolserver. See all that time I didn't edit? Discouraged by the UI and the policies.
WMF can and will do what they want. But they will loose experienced editors if they take away some of the tools they are used to.
Bots edits to "Flow" boards are mentioned a couple of times in passing. Have you given any thought to the sheer volume of messages some of these bots generate? For example, enwiki's OrphanBot has made more than a quarter-million edits to user talkpages, and some of the anti-vandal bots can generate upwards of a thousand messages per day. If a "Flow" board shows all of a user's recent messages, attempts to contact such a bot's operator will get lost in the noise.
(Sorry for the late reply)
I'm not sure how this is any different than the problem with existing talk pages, actually. Or maybe I'm not understanding your question correctly.
The question is if received and sent messages of a user will be shown in the same place, and if that place is the same where one adds a message to the user (as the talk page currently is, but showing only incoming messages).
There is a mention to "Banner messages/pinned messages" in the page, but can you elaborate further? This feature is interesting in the context of badges, barnstars and reflections of other merits acquired by the user over time e.g. the planned MediaWiki reps. Can Flow accommodate this? The ideal requirements would be:
- Notification sent by an identified bot or user with special permissions (e.g. User:BarnstarGiver).
- Non-editable, non-commentable notification pinned in a specific area of the Talk page.
- Only the publisher or the own user can remove it.
The size of those badges could be significant smaller than many barnstars these days. A small banner or even an icon with a link to the page with more info could be enough.
I'm not sure that this is entirely within the scope of the project, and it feels to me more to be part of Global Profile.
(And no "message".) I guess it's safe to assume that none of these jargonish thin terminological distinctions will be user-facing? They're impossible to translate.
I believe that the first sentence in the "nomenclature" section indicates that none of this is user-facing:
"Nomenclature in this document (e.g., "Flow board") is product design facing and not user facing. User facing terms will very likely be different than those included herein."
Thanks! (Better safe than sorry.)
«Flow seeks to solve this problem by removing the concept of a "home" for a given Thread» where the problem is «users don't necessarily know where to look for the conversation threads that they are engaged in». I've never heard of this problem, could you elaborate? Thanks.
It's the "talkback" template problem.
You're a new user. I leave a message for you on your talk page. Now you have to figure out if you reply to me on your talk page or you go to my talk page and respond there. If you choose to reply on your own talk page, I have to now go to your page to see any responses. If you reply on my talk page, now the conversation is fragmented and takes place over two homes instead of just one.
Thank you for clarifying. I didn't understand this particular section was only about user talks.
That's not a problem of home for a thread: if I'm talking with a user, the text of our discussion will of course be either of my or on their userpage, I can't miss it (it can get a bit more complicated if it's a user talk discussion among three or more users). The problem is how to get notifications for all messages directed to me personally.
Hence I don't understand the mention of tabs, currently you "only" have to check the watchlist as for every other discussion. There's of course the mostly theoretical problem of who "owns" a discussion («on "my" talk I can remove the messages I don't want», etc.), but that's a social problem and it's discussed on "Comments protection".
In conclusion, I don't know if this "dropping the concept of home" has any practical effect, but it seems a bit misleading, and possibly complicating stuff, if all you want to say is "they will appear in all feeds" aka "I'll see all messages directed to me in the same place" (obviously good).
«By their very nature, watchlist entries go "stale" after a certain point». I've never heard this term before, could you please explain it to us newbies? Thanks. (The only thing I know is that when a revision is older tha RCMaxAge it goes out of the watchlist; and that edits you don't need to look at, because you've already seen them, are not in bold.)
This is more conceptual than actual. Essentially, the problem here is this:
If I'm paging through a list of chronological events - in the feed - I don't need a line for every time someone edits a specific page. Every entry except the first one is "stale", conceptually - I've already been notified that there's been changes (and they'll have been collated together, in the first visible entry anyway).
So it's just what's currently called a non-top edit/revision, right?
The point of watchlist is not necessarily only to tell you there's been changes but also to show them all so that you can act upon them. I don't see why this should be any different for messages, which will probably appear in watchlists more or less like log actions do, I guess: it should just follow what the user chose in the preference "Expand watchlist to show all changes, not just the most recent" (disclaimer: I personally always set it to true).
Will Flow be replacing only user talk pages, or will it replace other talk pages as well? And if it's user talk only, will LiquidThreads ever be revived? Or is something completely different going to happen? And while I'm asking questions—will regular user talk pages continue to exist?
(Sorry for the late reply)
Initially, we are focusing on user-to-user discussions because they are . . ."simpler". Article and policy discussions are a different kind of beast.
LiquidThreads is probably dead, I'm sorry to say. This is an attempt at an easier alternative. We will likely visit article and policy discussions in the future, but only after we have seen how Flow discussions work with users. We'll want to take what we learn from that and apply it forward.
As far as regular user talk pages remaining: probably not. We are investigating scenarios for this, but my current thinking is that retaining them alongside Flow Boards will be an extremely confusing user experience.
So you will be implementing Flow on user talk pages only at first, then adopting Flow for other discussions later?
Possibly, if the model works and is beneficial. Other types of discussions have different dynamics and we need to make sure we are meeting their needs.
It's a very, very bad idea to put all comments in forced full protection (very unclearly called "privacy" in the document), this will make management of most talk pages a nightmare. See also bugzilla:29711.
Yeah; it should be called "Ownership" and I even changed one other section so that I could use the term there (the word "ownership" was being overloaded).
I disagree that it's a bad idea to put comments in forced full protection. I also do not agree that user-to-user conversations should really need refactoring. I suppose my big thing with that falls along the lines of "we are doing it wrong if our conversations need to be continually refactored." That's just broken.
Thank you. Again, I was mostly confused by this point not being stated as related to user talks only. (Is this only a temporary confusing state of the document or is there the risk that design decisions taken by having in mind only user talks will affect also completely different situations in later stages of the project?)
Back to the point: it's not broken, it's a wiki. Everything can always be improved, including talks, and I'm not aware of this ever causing any problem, it's just an unjustified assumption. Long threads become completely useless if you can't refactor them: think of the heated bugzilla discussions where it's impossible to distinguish noise, sub-threads, simple corrections, plain off-topic etc. from the meat. Mere chronological listing of posts as is is a completely dead concept which belongs to super old forum systems only, nowadays all discussion/comment systems allow a big degree of what we call refactoring and wikis are very modern in this; if you remove refactoring, you need to invent a shole new system to make discussions manageable and I'm not sure it's worth it.
Breaking refactoring might be a necessary evil at some point, but it mustn't be an aim.
I think the refactoring thing is going to be a longer term discussion but it is one that I'm thinking about heavily.
And yes, the document is in a state of flux. I've actually got a (much) larger version of it but it's a mess and this is the best that I could pull together. I'm going to be focusing on making some mockups to help explain the concepts better; I fear that much of this may make sense only with visuals (for example, how watchlist entries might work).
I agree that comments shouldn't be forced into full protection. On a wiki, everything is editable except for things specifically in need of protection from vandalism and such. We don't even protect user pages. Why should talk page posts by protected? Nobody "owns" anything on the wiki, in my opinion.
I agree as well. While it's generally bad practice to edit others' comments, sometimes there is good reason to do so, and preventing it won't help any when it is indeed needed, such as when include updating links to important pages that may have been moved; fixing misleading but obvious typos; removing personal attacks, links to disruptive sites, and other such material; and so on...
First page |
Previous page |
Next page |
Last page |
