Jump to content

Wikipedia talk:Flow/Archive 8

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:Flow
This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 02:01, 18 February 2014 (Archiving 7 discussion(s) from Wikipedia talk:Flow) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
Archive 5Archive 6Archive 7Archive 8Archive 9Archive 10→Archive 15

Flow + Echo = Error?

Tracked in Phabricator
Task T62906

I experimented with transcluding another page to the Flow test page, [1].

One thing I didn't expect was that such a move would trigger Echo notifications for people listed on that page. But I'm glad it did, since it looks like the notification they got doesn't work... Here an editor describes how this notification gave a Could not find the requested workflow error. Fram (talk) 12:57, 5 February 2014 (UTC)

The editor has added more problems with this, [2], with Echo refusing to un-echo the edit I made. No idea whether the problem is Echo, Flow, or interaction, but it certainly is a problem! Fram (talk) 13:00, 5 February 2014 (UTC)

Clarification: The page Special:Notifications is completely broken. This is what the page looks like for me. I can't read any notifications on that page (but I have switched on e-mail notifications and still get the e-mails correctly) and I can't change the number 5 into 0. --Stefan2 (talk) 14:22, 5 February 2014 (UTC)
Broken for me too. (I was directed here from closed discussion at WP:VPT which implies the problem is with Wikipedia talk:WikiProject Comics, though my name is not linked on that page, and I don't recall ever posting there, certainly not recently.) Optimist on the run (talk) 14:45, 5 February 2014 (UTC)
You removed the WP:PROD templates from Back to the Klondike, and for that reason your user name appears on Wikipedia:WikiProject Comics/Article alerts which happens to be transcluded by Wikipedia talk:WikiProject Comics. This is why Echo is broken for you. Echo broke because User:Fram transcluded the page Wikipedia talk:WikiProject Comics at Wikipedia talk:Flow/Developer test page. --Stefan2 (talk) 14:55, 5 February 2014 (UTC)
I've delinked my username from that page, but it hasn't solved the problem. Optimist on the run (talk) 15:09, 5 February 2014 (UTC)
That won't help. Echo is broken for you because your username appeared on the page Wikipedia:WikiProject Comics/Article alerts when User:Fram transcluded Wikipedia talk:WikiProject Comics at Wikipedia talk:Flow/Developer test page. Only a MediaWiki developer can fix this, I'd guess. --Stefan2 (talk) 15:20, 5 February 2014 (UTC)
I'm missing what is special abut the transclusion in Flow. Wouldn't this have happened is Fram had transcluded the page anywhere? I occasional get some odd Echo notes, but usually realize it was due to a transclusions. What makes this one different? (I gather than some are unable to clear the notification, but not sure why)--S Philbrick(Talk) 18:14, 5 February 2014 (UTC)
The only difference is that Flow revisions are larger than most wikitext revisions. So, for a full explanation of the bug; when you mention someone, Echo stores the text revision they were mentioned in (for use in, for example, the little quotes from the revision that you get in notifications). The problem is that Flow revisions are pretty large, and this one with all the transcluded content was larger than the database field we store them in, which led to it getting truncated and excluding essential information - hence the bug. As you say, this would've happened with or without Flow eventually; the breakpoint is "a revision > [certain size]", and it's definitely possible to get that just with a normal wikitext page. We've got a deployment later today to fix the issue. Okeyes (WMF) (talk) 18:49, 5 February 2014 (UTC)
I didn't totally follow all that, but that's OK. I'm happy to hear that it will be fixed soon.--S Philbrick(Talk) 20:02, 5 February 2014 (UTC)

I don't think Okeyes explanation is correct (or complete). The difference, as far as I see it, is that normal talk pages allow transclusion of a page: Flow automatically substitutes the page though (and all subpages), so that people get notifications and so on. Not something that would have happened on other pages. Yes, you can do that with a normal Wikitext page, if you deliberately substitute the page: but you get it in Flow even without susbstitution... Fram (talk) 20:21, 5 February 2014 (UTC)

So, I did some tests (would be nice if WMF people did the same before replying sometimes). Transcluding a page onto another page does not (I repeat: not) trigger notifications. Unless you do it in Flow, of course, since that can't handle transclusion and changes it into some strange form of substitution, which means that

  • Everyone on that page, and on every page transcluded on that page, and so on, gets notifications
  • The page size gets a lot bigger
  • The code gets a lot uglier
  • Changes to the transcluded page do not transfer to the Flow page (defeating the main purpose of transclusion)

I will not test whether substituting the page I tried to transclude somewhere else will cause the same errors as we had on Flow (though that test will need to be done as well some day), but what was claimed, that transclusion of this anywhere would have caused the same problems, is completely false. Transclusion only causes these problems in Flow, so my original complaint remains. EngFram (talk) 20:55, 5 February 2014 (UTC) (EngFram is my testaccount for non-admin actions, getting confused here with constant logging in and out from one to the other to test notifications to myself :-) I normally restrict myself to the Fram account!)

Actually...you can trigger mention notifications via transclusion on normal pages too. See bugzilla:50082. Legoktm (talk) 21:02, 5 February 2014 (UTC)
Ah, if changes are being made after the transclusion is done? Yes, that may be true, I haven't tested that. Not what happened here (and it shouldn't trigger the bug that had to do with diff size according to WMF, FWIW), but still nice to know. Fram (talk) 21:08, 5 February 2014 (UTC)
Again, it's nothing to do with substitution or transclusion, although that is the trigger. So, I guess we're talking about two bugs here: one is notifications through transclusions and substitutions. That is partly a Flow problem, insofar as Flow substitutes by default, although as Legoktm says it can happen outside of Flow as well. The second is mentions breaking Echo. That's not Flow-specific, it's revision size specific. Okeyes (WMF) (talk) 21:56, 5 February 2014 (UTC)

Will we get a developer to fix that? I now have three notifications that I cannot read, and it's a becoming more problematic as the time goes by. I came to rely on ECHO a lot, so it would be nice if we could get confirmation that someone will look into this, I've seen some bugs here go untackled for days if not months. Ok, I see it's being looked into, thanks. --Piotr Konieczny aka Prokonsul Piotrus| reply here 21:56, 5 February 2014 (UTC)

Yes, we have a deployment at 4pm PST today with a patch (read: in about two hours). Okeyes (WMF) (talk) 21:56, 5 February 2014 (UTC)
We deployed fixes for this, those who encountered notification problems can you see whether Special:Notifications works for you? The problematic notification from the large Flow post is still there, we just don't show it. So your Echo notification counter may stick at 1. We're working on that too. If you want your Flow notifications to drop to zero (if you're not involved with Flow on the two project pages, why not?) then disable Flow notifications in Special:Preferences > Notifications. -- S Page (WMF) (talk) 00:54, 6 February 2014 (UTC)
Additional fix options:
To fix it, you can either: 1) Temporarily uncheck the Flow notifications (web) in Special:Preferences#mw-prefsection-echo; or 2) Ignore the [1] for 9 days (a week from Thursday) when we'll get the next version of mediawiki code deployed to Enwiki;
or 3) Copy & paste this code to Special:MyPage/common.js:
importScript('User:Mlitn/MarkAllRead.js');
press 'save', and a dialog will pop-up asking if you want to mark all Notifications as read. Accept that, and it will be fixed. You can then remove the line of code from your common.js again.
Sorry again for the confusion and distraction. Quiddity (WMF) (talk) 01:54, 6 February 2014 (UTC)

Possible improvement to talk page access

Since we are talking about changing the way that talk pages work I have a suggestion. Currently when someone is blocked, its impossible for them to edit at all, even in discussions where their comments are needed or appropriate (such as ANI about them). Currently though they can only comment on their talk pages. If we are making changes to the talk page commenting ability anyway, the ability for an admin to grant a blocked user the ability to edit a page or a group of pages would be a beneficial improvement. Currently its all or none. 108.45.104.158 (talk) 13:09, 7 February 2014 (UTC)

Whitespace

There's too much.

Yes, I've read Wikipedia:Flow/Design FAQ#Why is there so much whitespace/padding?. I don't agree with it at all. Not only is it poorly-phrased ("decreases user unsatisfaction"), it's patronizing, defensive, makes all sorts of dubious assertions (whitespace could prevent harassment? Give me a break) and cites sources that either do not directly support any of the specific implementation of whitespace in this design, or, worse yet, actively contradict it - like the reader expends energy in the wrong place and tires more easily [when] lines... are too widely spaced. Well, I can tell you that the lines are too widely spaced. I've been online for almost 20 years, and in that time I've read vast quantities of text with formatting that would make any competent designer turn to drink - everything from single-spaced error-strewn OCR'ed text in UNIX terminal windows to multi-colored full-browser-width colored Comic Sans-on-wallpaper-GIF GeoCities extravaganzas. You know what? They were ugly as sin, but they were tolerable. This? This makes my eyes hurt. I can actually feel them straining as they jump around between tiny islands of text in a sea of white. The figure is completely lost in the ground.

That FAQ even links to this post on UX Myths. Look at the ratio of whitespace to text size on that page. Then look at mw:Talk:Sandbox. Flip between them a few times. Can you see the difference? Compare the current appearance of Flow to pages on Svbtle or Medium.

If you're unwilling to reduce the font size in this new interface, your options are basically two: either increase it to fix the figure-ground balance - thus making it completely out of scale with the rest of MediaWiki - or reduce the whitespace. You can't leave it like it is. — Scott • talk 18:14, 5 February 2014 (UTC)

Hadn't run into that before. How patronizing. I find it very hard to read. Maybe if I were a very slow reader I might appreciate it, but I'm not. And it's going to make pages very very long or have a much smaller amount of content on them. I want to be able to scan down a page quickly. Dougweller (talk) 18:54, 5 February 2014 (UTC)
I'd note here that we are discussing having a more expanded view as a preference, which personally I strongly support (it's too narrow for me, too). I'm going to poke the designers to address the problems with the whitespace argument in the DFAQ. Okeyes (WMF) (talk) 18:56, 5 February 2014 (UTC)
See also Wikipedia talk:Flow/Design FAQ#Tighter design where Diego has some interesting personal-CSS tweaks and screenshots thereof. Quiddity (WMF) (talk) 19:00, 5 February 2014 (UTC)
Scott, Dougweller, Oliver, Quiddity:I've made some personal CSS tweaks of my own, to remove a lot of the unused space, for which I'm looking for feedback. Screenshots: new vs. old. The code is in mw:User:Writ Keeper/trickle.css, if y'all want to try it out; as I said, I'm looking for comments/criticisms. (Of course, who knows how long it'll work?) Thanks! Writ Keeper ⚇♔ 21:32, 5 February 2014 (UTC)
Your new version is a lot better, but of course if the developers oppose it... Dougweller (talk) 21:46, 5 February 2014 (UTC)
Like I said, we're looking at a wider view. Okeyes (WMF) (talk) 21:53, 5 February 2014 (UTC)
I think it might be too extreme in the opposite direction… A bit of padding in a few places would help readability. And yet I like it more than what the Flow developers came up with. And I completely agree with User:Scott Martin. Keφr 22:25, 5 February 2014 (UTC)
Probably; I was fairly indiscriminate in the whitespace I cut. Any suggestions for places that could use some more spacing? Writ Keeper ⚇♔ 22:48, 5 February 2014 (UTC)
I'd suggest using some longer posts (multiple full paragraphs) as well as 1-liners, to more clearly demonstrate (in the screenshots) how it would look during realworld usage. Quiddity (WMF) (talk) 00:37, 6 February 2014 (UTC)
  •  Working – the newest code we pushed on Thursday has tighter spacing between posts. We'll be doing a larger frontend UI refactor over the next few weeks. When finished, it should, among other things, widen the board/reduce the right margin and create a more responsive interface that scales for larger/smaller screens. It's all experimental and changing rapidly based on your feedback, folks – if we were "unwilling" to change anything, we wouldn't have put it out there so early for you to test :) Maryana (WMF) (talk) 22:13, 7 February 2014 (UTC)

Preference request

I noticed that new topics go to the top of the page by default. This is a personal preference, but I absolutely despise that order of order of arrangement. It would be most appreciated a user option to have new topics fall to the bottom of the page were available when this ultimately rolls out. Thanks! Resolute 21:19, 5 February 2014 (UTC)

That doesn't seem to make sense with infinite scrolling if you think about the mental model :/. Okeyes (WMF) (talk) 21:54, 5 February 2014 (UTC)
Perhaps it's the infinite scrolling that needs to be rethought. I've yet to see a good argument in favour of it, to be honest; it just seems to be a "choice" that nobody actually asked for. Risker (talk) 23:05, 5 February 2014 (UTC)
Agreed. I find infinite scrolling to be equally annoying. If forced, I would adapt, but I find the combination of the top-down approach with scrolling makes it remarkably difficult to move through histories. Resolute 01:17, 6 February 2014 (UTC)
This seems to be a case where developers are forcing a particular modus operandi that is contrary to typical Wikipedia norms (i.e. new topics go at the bottom). Be prepared for more forced changes. Killiondude (talk) 22:51, 5 February 2014 (UTC)
Developers, and designers, and product managers, yes, in line with how pretty much every other piece of discussion software on the internet works. Can you tell me how asking people to opt-in and not deploying it if they said no is a forced change? Okeyes (WMF) (talk) 23:05, 5 February 2014 (UTC)
Can you point me at an example of a threaded discussion system that runs upside down? I've certainly seen them with the topics being displayed with newest on top, but anything I've used maintains an oldest-on-top model for each individual thread.—Kww(talk) 04:43, 6 February 2014 (UTC)
If by "upside-down," you mean most recent comments above, threaded comments (direct replies) below those comments: the New York Times comments section is one quite popular example. Maryana (WMF) (talk) 22:24, 7 February 2014 (UTC)
In terms of typical discussions, yes. But we do have areas that operate in this top-down format already. Namely, AfD, DYK, etc. It's not unheard of on Wikipedia. Resolute 01:17, 6 February 2014 (UTC)
Like the FAQ says, that and other aspects, are experimental, and feedback is appreciated. The options (for all those many aspects) are A) What us regulars are used to (with known pros and cons), B) What's been suggested so far (with new pros and cons), and C) New ideas. I'd personally love to learn about more in category C - we're not stuck between "keep it as it always was", and "this new design is the only alternative" - we're only limited by what is possible. Quiddity (WMF) (talk) 23:37, 5 February 2014 (UTC)
I think one of the problems here is that Wikipedia discussion pages aren't intended to work "in line with how pretty much every other piece of discussion software on the internet works". Our discussion pages are different because they're actually intended to be discussions; most of those other sites aren't. Most of them are "comment and move on" sites, as opposed to pages where people are working. Making a Wikipedia discussion page look like those sites will encourage that kind of behaviour, instead of teaching the very different processes that are required here.

I think it would have been extremely simple to come up with the top-5 ways to improve Wikipedia discussion pages (making indents easier would be at the top of almost everyone's list), but the core design principles being illustrated with this are not well-suited to the fundamental purpose of discussion pages. One of Wikipedia's strengths is the willingness to be different, to be focused on function rather than form. I think perhaps some of the core values and principles of the project are being overlooked here. Risker (talk) 05:06, 6 February 2014 (UTC)

Thank you Risker. I agree entirely. I wish that developers would do surveys before starting work. Unless there are major changes I can't see this as anything but detrimental. I certainly would not want to try and have a serious discussion on a page that looks like and works like Wikipedia talk:WikiProject Breakfast. On the other hand, I'd love it if someone would make indenting easier. Dougweller (talk) 12:22, 6 February 2014 (UTC)
Yes, and Risker's point, about how discussions here are not intended to work like "comment and move on", and about how the wrong kind of interface will send the wrong message to new users finding their way around here, is very, very important. It bears repeating and reinforcement. --Tryptofish (talk) 14:19, 6 February 2014 (UTC)

Breakfast page

The density of information is significantly lower than the existing style. It's like turning The NY Times or Wall Street Journal into USA Today (colors! bad graphics! lots whitespace!). In other words, to review the content I have to do way more scrolling to get the same amount of information.

And the history needs a diff capability. NE Ent 15:30, 5 February 2014 (UTC)

I think the permalink option is intended to be the diff capability, but that is obviously grossly limited given it can only link one post rather than a range of them. Oddly, I can still permalink to a post that I deleted: [3]. Can anyone else see it? Resolute 15:38, 5 February 2014 (UTC)
Anything that's been edited will have a small pencil icon next to it, e.g. this topic title, which takes you to the diff of the changes. Anything that hasn't been edited doesn't have a diff, hence no pencil icon :) Maryana (WMF) (talk) 21:56, 7 February 2014 (UTC)
I can without taking any action, but I'm an admin here. Can non-admins see it? Fram (talk) 15:41, 5 February 2014 (UTC)
I'm not an admin. I can't see that a post has been deleted. Either it's shown there as "not deleted", or it's comletely missing without any log message or other information. --Stefan2 (talk) 15:48, 5 February 2014 (UTC)
Oh, cool. So as a bonus, admins can potentially see a flood of deleted junk. There are definitely some (minor) stylistic issues to be worked out still - though I think this and NE Ent's concerns can be addressed fairly simply if the Flow team is willing. Thanks for checking! Resolute 16:24, 5 February 2014 (UTC)
I don't whether the permalink isn't working for me or it's just I don't understand the interface. I'm not finding a way to see anything that looks like a diff. NE Ent 16:39, 5 February 2014 (UTC)
Permalinks don't show diff changes - the popup for the pencil icon of an edited post has an option "show changes" that opens the diff page. Diego (talk) 22:49, 7 February 2014 (UTC)

Needs a UX person to redesign it

I've had a look through Flow and it's nice to see an attempt at improving talk pages. This product is obviously a very long way off, but it's got some good features that will be interesting to see deployed. However, I think you need someone to properly spec the project in advance because it seems... a little mish-mash. Some examples of problems...

  • Infinite Scrolling
    • That's going to get incredibly confusing on very long pages.
    • Infinite scrolling in discussion/topic is a very infrequently used format, for very valid reasons! I recommend bringing a UX expert onboard to spec a really good discussion/topic-list UI
    • I recommend implementing a usable and robust archiving system (so, say, editors can configure archive strategies per page). I'd consider an archive system a blocker to any release.
  • Top Posting
    • This is going to confuse and put off regulars. Although it's a common pattern it's not the *only* way to do things. Is there a firm use case for changing the status quo? Whoever the produce manager is (??) they should be able to justify design choices like this in detail - so I'd be interested to hear that justification.
  • Layout
    • On mobile the buttons are massive, mostly all I see is ErrantX everywhere and then the big blue buttons. Then some other smaller text links. Actually reading anything is cumbersome
    • On browser view the layout doesn't scale. The vast majority of the screen estate that you do use is also taken up with interface - which for a system intended to facilitate discussion is somewhate counter-intuitive

In summary, I think the whole UI needs speccing properly, by a UX person, with plenty of user testing (UAT). I'm guessing that the current interface was put together by the developers, which for such a massive change is not the best solution and unfair to place on their plate :) --Errant (chat!) 11:56, 6 February 2014 (UTC)

Oh, for an absolutely amazingly well designed (if simplistic) discussion system see Hacker News. This should be your base IMO. --Errant (chat!) 11:58, 6 February 2014 (UTC)
I see that the whitespace and fixed-width are intentional choices. This is a bad decision; what you say about whitespace is somewhat true. However this problem is actually introduced by the amount of user chrome added with Flow. You should focus on reducing that chrome as much as possible (because it is a distraction). Fixed-width is not a good choice as it forces a particular choice on the user. Instead the recommended approach is to have a simple and obvious way to increase font-size, which achieves a similar affect but with more versatility. Also, your default font-size is not the Wikipedia standard font-size. It's basic UX 101 not to do that :S --Errant (chat!) 12:09, 6 February 2014 (UTC)
For me, the size of margins and padding is not really the main problem, but their decision to insert friking interaction elements in the middle of the conversation. I've been testing some changes to the CSS layout, and when moving out of the way the Reply and Timestamp, the resulting page is quite readable even for moderate and large amounts of white space between the posts. Diego (talk) 14:06, 6 February 2014 (UTC)
  • So, just to reply; this was put together by UX people. FWIW, I share your concerns about fixed-width (we're going to be working on that - it's far too narrow, and it shouldn't be fixed anyway, imo), and several other points; I'm poking Maryana to reply to those I don't have an opinion on ;). Okeyes (WMF) (talk) 17:07, 6 February 2014 (UTC)
    • I put this up on the screen this afternoon and our creative team had a play around with some improvements/suggestions - so if you want some detailed feedback and perhaps a rough mockup I could jot something down. --Errant (chat!) 21:33, 6 February 2014 (UTC)
  • Comment from that elusive Product Manager :)
ErrantX, it sounds like you're One of Us,tm in the sense that you work in software design and development. As such, you probably know that design is not an exact science – there are some quantitative measurements and data you can get to inform design decisions, of course, and they're extremely important. But at the end of the day, there's a large portion of qualitative data/subjectivity/art. Who can objectively, neutrally say why one icon is better than another icon? Or why one website's navigation feels intuitive and another's feels weird/clunky? That element of subjectivity is why you can take two extremely talented designers, ask them to work on the same problem, and come out with two completely different results. Or why designers are so fond of redesigning each others' redesigns all the time ;)
So, to your point that the decisions around whitespace, top-posting, and infinite scrolling that our designers made are things you don't agree with or personally don't like... fair enough. We're putting it all out there early for people to play around with as a whole (and, yes, doing lots and lots of user testing; remote and in-person, there have been 3 rounds so far, comprising around 20-30 users). If there are aspects that are confusing or make discussion more difficult for end-users, obviously they'll need to change. But the key here is end-users, and it bears remembering that the intended users of Flow are not just the few hundred extremely active English Wikipedia users currently editing today – who, we all know, overwhelmingly tend to skew to the young, white, male, US and EU demographic that also tends to be the average reader/user of Reddit, StackOverflow, and, yes, Hacker News ;) There are millions of other great, smart people in the world who find all those aforementioned discussion systems – not to mention Wikipedia talk pages – scary, confusing, and alienating. If we build something that works perfectly for you and me and other Wikipedians, but that 99% of other humans simply can't use, we've failed.
That's the stretch we all have to make with this project, and why it's not quite so simple as "well, just get an expert UX person to design it" or "just let me tell you what I (and by proxy) all Wikipedia users need!" No matter who we are (designers, experienced Wikipedians, newbies), we have to think about the people outside our homogeneous circle who are also going to be using this software. I'm not saying what we've got now is perfect – I'm saying all of us have a lot of testing and talking to do to get there. Luckily, I think the tension between different people's ideas of a good discussion system is actually quite a productive one that will ultimately help us find the right ways to solve these extremely complex UI/UX problems. I'd much rather have a thousand strong opinions and redesigns than design by fiat/user complacency and silence (but that's probably why I work for Wikimedia and not, say Google) :) Maryana (WMF) (talk) 01:05, 8 February 2014 (UTC)

Huggle

Is it possible to fight spam with tools like Huggle? I have tried to find answers to this question but it seems nobody cares? Christian75 (talk) 11:50, 7 February 2014 (UTC)

We certainly do care :) In the next couple of weeks, we're going to start reaching out to bot operators and writers of vandal-fighting scripts to help us test and build out our API so that it integrates with community-developed tools. This is something we're hoping to do a dedicated sprint on during the Wikimedia hackathon next month. Maryana (WMF) (talk) 01:11, 8 February 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow/Archive_8&oldid=595965569"