Wikipedia talk:Flow/Design FAQ

What do you like about Flow's current design

Signature

I like that the signature gets a line on its own, instead of being next to the text as in current talk pages. The vertical space generated by that isolated line, and the contrast from its blue color, would be all that is needed to separate one post from the next in the same thread; the extra space introduced by the time stamp and reply buttons is too much. The separation between long paragraphs in the same post is perfect for readability. Between different posts, it should be only slightly longer.

Of all the example styles that are listed, The Verge and Quora are the ones closer to the ideal vertical space - although The Verge still dedicate too much space to identify the poster, time stamp and interaction buttons; and Quora chrome is too noisy (and their auto-collapse drive me nuts).

Wikipedia talk is a different use case than the one found at blogs, with their drive-by, one-time post-and-forget style of comment; our talk pages should be optimized to present each conversation as a single stream of text, not as a chain of isolated posts. Think of a novel with paragraphs and dialog between characters, not a bulletin board. Diego (talk) 12:31, 11 October 2013 (UTC)

I read that the Flow will not allow the use of custom, visually-distinct signatures? I am just learning about these things like the Flow but was very disappointed that my custom signature, which I am just now developing, will eventually be denied to me, as I envision it as a fundamental component of my future online Wikipedia presence. I don't know why the Flow will not still gush smoothly with a harmless custom signature... JDanek007^Talk 00:03, 22 January 2014 (UTC)

I don't agree with a standard signature used in Flow discussion pages. I still prefer the old style signature-placed-in-the-end. As per JDanek007, allowing the use of custom signatures shall still be used; Wikipedia should provide leeway in placing these on Flow discussion pages. It allows messages to be more easily identified to a user. Japanese Rail Fan 15:30, 12 May 2014 (UTC)

Current (old) option to handcraft a signature is a horror to the eye (talking about tiring eyes), and I cannot even use the true name by copy-paste. -DePiep (talk) 11:49, 9 September 2014 (UTC)

Column width and line spacing

I'm glad that you're looking at best practices and referencing studies about online readability, not just following websites trends. The text density of paragraphs inside each long comment is quite readable in the desktop. Diego (talk) 22:30, 11 October 2013 (UTC)

What would you change about Flow?

The default style needs _way_ too much space.

The above is a comment by an IP at the Flow sandbox on Labs, and I can only agree. I can currently see six (6!) short lines of text there, all the rest is whitespace, user names, and time stamps. The current talk pages may be too densely packed, but this is the extreme opposite. Fram (talk) 11:38, 11 October 2013 (UTC)

@Fram as mentioned before, spacing and padding are still in flux, however I for one only tend to read 1 line of text at a time, I'm relatively young, and have good eyesight, but current talk pages are almost unreadable to me, its mostly a symptom of the small type size, extremely long line measure (I usually have to make my browser half screen width if i plan on reading lots of talk pages) and the leading being a bit tight. Thankfully quite a bit of research has gone into readability, and we're doing our best to leverage as much of this learning as possible to arrive at a place that balances readability and information density.—

Jared Zimmerman (talk) 21:06, 12 October 2013 (UTC)

Line length/measure

While I understand that there may be some default appearance, why force it onto everyone? Some people prefer to use the complete page, not only half of it. Is there is a reason that, even if the default width is normally the best for people, you can't allow people to choose something else? Is there a technical reason that you have to use fixed width? If not, why not give people some more freedom? By the way, "Best practice is 13 words per line, 50% of total screen width"; 13 words per line may be 50% of screen width for some screens and resolutions, but not for all obviously. Note that the source doesn't discuss screen width, and discusses characters per line, not words per line, since characters is a more fixed measure (depending on the font of course). Fram (talk) 11:12, 11 October 2013 (UTC)

I can totally see this being a preference later on down the line, much like Gmail's display preferences.

But building the ability to allow users to select that preference isn't trivial; I'm sure Google spent a lot of time researching different screen sizes, doing usability testing to establish various benchmarks, coding those into a drop-down preference selection modal, and then engineering a UI that responsively adjusted to checking each pref. I'm not saying it's a Herculean challenge or anything, but it is user experience/design/development work that does take time away from us working on other (arguably more important) features, like the ability to see Flow events in your watchlist :) Keep in mind that right now, we're designing for a Minimum Viable Product, which is just that – the minimum set of features for this to go live anywhere on Wikipedia. The MVP is just the skeleton onto which more features and functionality will be added, and figuring out preferences is something that seems like it will be much easier when we all have a baseline out in production to work from. Maryana (WMF) (talk) 17:15, 11 October 2013 (UTC)

@Fram I would add to what @Maryana said, that when we say "fixed-width", our goal is to assure that the text is laying out in an expected way that is in line with best practices. This may mean that the measure of the text changes with point size, browser width, browser zoom, etc. I would say that what it does not mean is that we will specify an exact pixel width for the paragraphs.—

JZimmerman (WMF) (talk) 17:53, 11 October 2013 (UTC)

A long time ago, when science fiction magazines were still on paper (say, 1930ish to 1980ish), many of the paperback-sized magazines had two columns for fiction and one for non-fiction. Is this "13 words" optimized for fiction, gossip, or non-fiction? IMO, it need to be optimized for non-fiction, rather than gossip, which is almost entirely the model from which you've extracted the numbers. — Arthur Rubin (talk) 21:42, 6 December 2013 (UTC)

@Arthur Rubin: Just to clarify, the references they've cited are this study (which used SAT and ACT questions as source material), and this research (see "7. How Many Characters Per Line?" - which used various journalism/reportage sites as analysis material).

The list I suspect you're referring to, further down in the design FAQ, is entirely unrelated, and is simply a list of example discussion sites that people may have suggested "Flow looks like aesthetically" (or functionally). Many of them were also pulled directly out of the WT:Flow discussion thread about threading, which was simply brainstorming by staff and community (see the reddit link for example - it's a sample thread I created just for the threading discussion, and I dug out that stackoverflow link for it, too).

HTH. –Quiddity (WMF) (talk) 06:07, 9 December 2013 (UTC)

@Maryana and Quiddity (WMF): The assertion "Best practice is 13 words per line, 50% of total screen width" is still present on the Design FAQ page and, as already mentioned by Fram in October, still with that same reference which doesn't mention anything about an optimal number of words per line nor of an optimal text width relative to screen width. Please share the real references behind this assertion. Or better, announce that there is work going on to have a non-fixed width version of Flow, as it's really unpleasant to have to scroll down so much all the time! Klipe (talk) 23:10, 28 January 2014 (UTC)

Klipe: The references I've seen onwiki and in email include: [1] (as given in the FAQ), [2], [3], [4], [5], [6], which do indeed all use a characters per line (CPL) measurement (not words per line). I'm not sure why the FAQ was originally written to use that, I'll ping Jaredzimmerman to ask (iirc he or May wrote that part).

You may also be interested in giving feedback at mw:Talk:Typography refresh about the current iteration of the Beta Feature. Note that Flow currently works out to about 95CPL and the Typography refresh to about 112CPL (on my linux system/setup). HTH. Quiddity (WMF) (talk) 07:06, 29 January 2014 (UTC)

Whitespace & padding

See tyhe above on "fixed width". It is good that you design the default look around such issues, but don't force it on editors. People aren't statistics, what is good for most people may be extremely annoying for others, for whatever reason. Oh, and it would help if the user name and timestamp were on the same line, that's one line won, which means a bit more content on my screen. Scrolling is stressful... Fram (talk) 11:12, 11 October 2013 (UTC)

Shared opinion. I fear for my RSI - scrolling hurts, in a very literal and physical way. Different posts should be separated about the height of a paragraph interval plus signature. Long paragraphs are better read when the text is not broken every few lines by huge white blocks; remember that each thread is a single conversation, not separate entries in a reference manual. The layout for quick one-liners in succession is specially troublesome. Diego (talk) 12:01, 11 October 2013 (UTC)

I actually agree that we haven't gotten the whitespace/padding down yet (I think everybody on the team does) :) We'll be making some tweaks to it in the next couple of weeks.

Also, see my comment above to Fram re: MVP stuff. I think this is another area where we're going to work on figuring out a good baseline for the first release, but it's not going to be perfect for everyone right away. It will help a great deal to test this in a real environment, with real (often long, complex) conversations between users. We'll probably have to continue making adjustments over time if we see that it's still a huge PITA to scroll through long threads, but more context and user feedback are required in figuring out precisely what those adjustments should be. Maryana (WMF) (talk) 17:28, 11 October 2013 (UTC)

Take a look at the Gmail whitespace display options at https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow/Design_FAQ&action=edit&section=7. The default is comfortable, with lots of whitespace, but peope who grew up with text-based browser interactions and a general lack of whitespace (like me) can choose to remove whitespace if they'd like. Design is CSS based. It should be simple to put in a CSS name in the padding whitespace sections, so users can modify their personal CSS at their common.css page with nodisplay tags, or whatever. Basically, however you set up the display, drop in enough CSS that users can rerig it how they want and then everyone can presumably be happy. Sure, artists want their work on display, but not everyone likes the same kind of art, and we want people to have pages that they like using. Banaticus (talk) 05:58, 17 October 2013 (UTC)

People are still complaining about this. A while ago I did a test replicating a modest-size community discussion in Flow. It had a 40% density, compared to the identical wikitext discussion. In other words it took up a a painful two and a half times the space. Alsee (talk) 03:30, 26 December 2015 (UTC)

Table of Contents & sort order

Again, why not let people have the choice~? Fram (talk) 11:12, 11 October 2013 (UTC)

I've talked about this at the other forum for available functions. Diego (talk) 11:54, 11 October 2013 (UTC)

In the interest of keeping our discussions organized/centralized, I'm adding Diego Moya's comment from Wikipedia talk:Flow below :)

"I read with dismay at the design FAQ that you've decided in your initial design to pass without the table of contents, open only to experimentation if "the search system is insufficient"; this is what I feared the most since the very first moment that Flow was announced. I can tell you right now that lazy loading of content through scrolling breaks most of my reading habits for talk pages.

I use the page index to get an overview of all the available topics, performing a quick scanning of the titles, deciding which ones to read and which ones to skip. "Infinite history" scrolling is a design that prevents this scanning, as there's no way to get an overview of the titles available. It's not true that "the concept of a table of contents doesn't scale" - you can easily paginate the TOC, or even lazy load it; the key differences that make it useful and are not available in Flow (but might be) are: 1) that topics are shown in a compact table format, and 2) that only the titles are loaded - the topic contents are loaded upon request for only the particular topics selected from the table (thus not polluting the page with any topic that I skipped). My usual workflow is to enter a talk page, scan the TOC and open the topics I see interesting in new browser tabs, to read later in random order and jumping back and forth between them. The current Flow design makes this workflow impossible; even if all topics were collapsed and only loaded upon unfolding them, I'd still need to keep scrolling the page up and down to find the next topic I want to read. Having a TOC ordered by creation date also provides a sense of temporal and spatial relation between topics (i.e. an earlier/later ordering), which is essential to track which topics I have already processed (either by reading them or by deciding that I don't want to read them); the "flowing text" paradigm where topics are reordered every time someone updates them makes it very difficult for me to track what I've already processed and what I didn't. Every HCI textbook shows that searching and browsing have complementary strengths (related to the recognition vs recall abilities of the brain), and you can't wholly substitute one for the other except for the most trivial tasks. When Aza Raskin popularized the infinite scrolling, it was designed as a solution for search results. It may also be a reasonable technique to apply to blogs, with usually have a separate column organized by date (i.e. a TOC), but it only works well when items in the list are unrelated and you may be potentially interested in seeing all them, in order, without skipping chunks; therefore I believe it is a bad general solution for the kind of content available at Wikipedia talk pages in my experience, where each topic is usually related to other topics above and below. The main problem with infinite history is that it prevents scanning of titles - my experience is that it forces you to load all the intermediate content by manually scrolling before showing the titles of later posts, which is a slooow process (Wikipedia long talk pages are essentially paginated by the archive tools, so it's easy to skip to certain dates and pre-load selected reasonable sized chunks of content -in the 30Kb to 200Kb range - for quick scanning', without manually scrolling through them all while waiting for new topics to load). So please, PLEASE make sure when iterating the software design that the final solution can build indexes for all the topic titles in a range of dates (ordered by topic creation) and that one can jump to any topic in random order.

I hope this text is enough to explain the reasons for why a solution providing the functions of a TOC is needed; if you need clarification of some point, please ask for it, and I'll gladly elaborate."

My gut response is simply that infinite scroll makes it hard to define what "an overview of all the available topics" means. On a talk page with 500+ topics and growing, does that mean all of them? That's a pretty huge ToC, and it's not clear how providing it would make it any easier to scan new topics than simply scrolling through the page (which provides you not only with topics, but with context). That's one of the major usability issues of Liquidthreads, imho.

But we'll definitely keep thinking/talking about the problem of quickly scanning through content and jumping to particular points in time... If you have any ideas about how this could be done (or examples of other sites that do this well), let us know! Maryana (WMF) (talk) 18:59, 11 October 2013 (UTC)

Actually, defining what is a table of contents is so simple it's scary. It's the collection of all the topic titles, without the contents. The way to navigate the 500+ topics is the same way as you navigate the full contents, as they share the same structure: through lazy loading, pagination, search, and filters between dates (ordered by creation date and/or last update, depending on the scenario). As I explain above, the good thing about not showing the threads content is that you don't need to skip the threads content, nor wait for their load times.

I don't know what you didn't like of Liquidthreads' TOC; it's the one feature that allowed me (thanks to its "Sorting order: newest threads first") to make sense of its weird structure, otherwise full of automatic reorderings, topics opened at separate windows without context, and random hiding of comments. Sure its style was ugly and it didn't show page numbers, but otherwise it was fully functional as a TOC (something that couldn't be said of its threaded discussion).

In fact, I liked one proposal that emerged in the original discussion pages to have an option to load all topics folded at the start (and in compact form - no big section headers). That would be a valid way to implement the functions of a table of contents - provided each topic is fully loaded on demand, when unfolding its thread (and preferably, having the possibility to launch it in another browser tab). Diego (talk) 22:05, 11 October 2013 (UTC)

@Diego to your point about being able to open each conversation in its own browser tab, I just wanted to make sure you were aware that this functionality will be preserved (and is already in the prototype) for each topic header there is an icon in the right rail "action menu" that looks like two pieces of linked chain, this is the permalink to that conversation, which you can use to open it in a new tab, without the noise of the other conversations on the board.—

Jared Zimmerman (talk) 20:43, 12 October 2013 (UTC)

I tried permalinks at LiquidThreads, and I found that model disorienting; maybe I could get accustomed to it, but I prefer the way it's done in current mediawiki Talk pages, where all threads in the same page are shown in sequence, and I can jump back and forth freely, or keep reading in sequence when the conversation keeps flowing from one topic to the next. An index or TOC in Wikipedia should be either a separate area at the top of the page with links to anchors below, or a visualization mode where the content of threads is hidden and shown on demand; it should not be a collection of links to other pages. Diego (talk) 23:11, 12 October 2013 (UTC)

@Diego, I'm not really familiar with LiquidThreads (Although I'm sure my designers are) so I'm not sure how it handles permalinks. The permalinks in flow will go to distinct pages for topics or comments, that are aggregated onto a flow board. I think that @Maryana touched on it before but one of the issues with TOCs are that they would either be constantly changing or constantly out of date. Since the topics on a flow board are being resorted by frequency of interaction by conversation participants. You mentioned at one point that you'd want to see the TOC chronologically arranged I assume you were implying it would be reverse chronologically so the newest ones are at the top. Would you want the order to always reflect the order of the topics on the board which could change at any time? Even while you're reading the board? or would you want it ordered based on topic creation date, which means you could be going through many closed or resolved conversation before reaching one that is active and "recent" in the sense of it being a vibrant ongoing conversation, or something else? You don't have to have an answer, but I wanted to point out some of the many options we thought about before arriving at the decision (for now) to not include TOCs in the design for flow. What this does not mean is that we've not given thought and design to a way to of viewing the flow board in a way that is a glance-able topic oriented view. We just haven't gotten there…yet.—

Jared Zimmerman (talk) 07:10, 13 October 2013 (UTC)

Just copy the LiquidThreads "Contents" function, default order as "new threads first", and I'll be fine; note that if you use either direct or reverse chronological order of creation, it does not change, it's a stable structure (it only grows). (And even when using "last modified" reordering, it's exactly the same as the Watchlist - and people seem to manage that one quite well). Please remember that being glance-able is not enough - it's also essential for Talk pages that "ordered by creation date, not last modification date" is an available option.

LiquidThreads' layout and functionality provides all what I asked about (though the pagination would benefit from some improvement). For some reason Maryana doesn't like it, but she didn't tell and it's not explained in your design documents why you excluded TOC-like functions. You could make them optional if you don't want it to alter your default experience, but I'm sure other power users will want it. You can name it something like "index" or "summary view" - it's true that "Table of contents" is not a good name if it doesn't show all contents; what I care about is the functions it provides that are not available in the Flow prototype. Diego (talk) 07:55, 13 October 2013 (UTC)

@Diego, as a designer, I think one of the hardest things to learn is when to borrow and steal design patterns you see elsewhere, and when to learn from them and invent a new solution to a problem. In the case of default ordering I firmly believe that what the team has come up with, resorting the board by last modified will be a great way to engage new participants in active conversations on boards. However this, like many other big questions we've come across thus far would be a great thing for us to test, and see how sort order affects participation and engagement.

As far as the TOC as I said I think we'll have a solution that solves for what you're asking for, if maybe not in the format you're used to. Can't wait for your feedback when we get there.—

Jared Zimmerman (talk) 06:30, 14 October 2013 (UTC)

I suggested default order by creation date assuming there is a separate page or area for the index; it's logical to have the main content area ordered by update as the default mode, given the Flow design and its focus on keeping users informed on recent updates; I wasn't questioning that decision (one that I agree with), but asking for a separate mode and/or interface for a different use case, i.e. a different problem to solve. If you somehow integrate the index within the same main area, I'll wait to see your solution to the cases where a chronological index is required. I wouldn't mind having to activate explicitly the chronological ordering for the particular use cases where I need it. Diego (talk) 08:29, 14 October 2013 (UTC)

P.S. - As a direct answer to you question: would you want it ordered based on topic creation date, which means you could be going through many closed or resolved conversation before reaching one that is active and "recent" in the sense of it being a vibrant ongoing conversation, or something else? This is exactly what I want for the use case of reviewing closed and resolved conversations (or closed but unresolved!), which is fairly common. In those cases, being distracted by "vibrant ongoing conversations" is the last thing I want. (Of course, this is the case where having only the index instead of the full content really helps to skip those closed conversations that are not interesting, while accessing the old but interesting ones).

Remember that Wikipedia talk pages are not just discussion tools, they are also archives for the decisions that were discussed and taken while constructing an article or coordinating with other users at their user pages. For consultation of those archives, an always changing and reordering board is madness; what we need is a stable record of all the past discussions in the exact order in which they took place. I'm eager to see your design for this "browsing the archives" use case (shall we call it "un-archiving"?). Diego (talk) 09:17, 14 October 2013 (UTC)

I know that many people have grown up with Facebook and Twitter and expect to see new posts right up at the top, with older posts underneath. But many people (like me) grew up reading these things called "books" where what we read before is always "above" what we are about to read. It's the same way that internet bulletin boards have mainly worked for the last couple decades since I first started creating websites back in '93. It's the way Wikipedia works now (except for the Teahouse). Sure, some of the young tweens have a hard time imagining a system where older content is "above" newer content, but let's not tear the carpet out from under ancient 30-somethings like me. The beauty of computers and programming is that design doesn't have to be intimately tied to function -- just give people the possibility of options and theoretically everyone will be happy. Banaticus (talk) 06:05, 17 October 2013 (UTC)

@Dougweller: Hi. Re: your comments here ("I've just seen someone start a new topic, and unlike normal talk pages it's at the top of the page. I wouldn't look for it there. I'm getting concerned that this experiment may impede the work of the project and may confuse the new user who posted the new topic. [...]), I just want to point towards the FAQ entry about "Topic order" in the table at Wikipedia:Flow/FAQ#Components of the discussion system, and the Design FAQ entry at Wikipedia:Flow/Design FAQ#Why are we using this Topic and Post order.3F, and the prior discussion above. (TL;DR (But please do read!) It's definitely a change, but it might be a good change, considering all the confused newcomers we've collectively had to direct to the bottom of the page, over the years!). HTH. Quiddity (WMF) (talk) 23:36, 4 February 2014 (UTC)

Re 'Wikipedia:Flow#Components of the discussion system|topic order' 10:10, 21 November 2014 (UTC), clicked 'discuss': this entry is a data point in a thread stretching over 13 months. Top ordering (or perhaps it is referred to as 'infinite history scrolling' - see how even the name of the topic is easily broken) works in a high-interest situation, such as a current event involving a disaster (with thousands of contributors (This is what user:wnt calls a high Gini coefficient situation)), but top ordering fails to serve low urgency threads which have committed contributors. In other words, top ordering works (to detect interest in a topic) if you scale up in numbers of views, but fails if you 'scale down' by zeroing in (to detect relevant, committed contributors to the specific topic (This is what user:wnt calls a low Gini coefficient situation)). Somehow you need to associate a time-stamped token for the thread with each contribution, in order to assess the contributor/contribution. --Ancheta Wis   (talk | contribs) 10:10, 21 November 2014‎ (UTC)

The last time I asked the team about this, they explained that the plan is to get the (currently in active development) Table of Contents and Search working, and then re-evaluate the infinite scroll paradigm and sort-order defaults. The various Filters that Hhhippo has nicely explored in User:Hhhippo/Flow/TOC and filters might also add new reasons to consider this change. I'm cautiously optimistic (on my good days) but I do also understand the benefits of the current limited page size and inactivity-based 'archival' system. Only time and testing will tell, whether this particular experimental aspect can be more useful than our current standard(s) for ordering and mainpage inclusion. HTH. Quiddity (WMF) (talk) 01:39, 22 November 2014 (UTC)

Hide closed topics

Closed topics are cluttering the table of contents. What about a checkbox 'hide closed topics'? Tamriel (talk) 23:18, 25 August 2014 (UTC)

@Tamriel: There's a really good compilation of ideas about various Filters (including this one) in User:Hhhippo/Flow/TOC and filters. I think that's the definitive wish-list, at the moment. (Sorry for the late reply). Quiddity (WMF) (talk) 01:02, 22 November 2014 (UTC)

Selecting which unloaded topics to load?

This may be too complicated, but it might be good if you could see a list of un-loaded topics and select which ones you want to open. That way if there are several topics on a similar subject you can read through them all without other topics getting in the way. There are downsides to that of course...

1. the topic titles might not always be indicative of what's being discussed within them
2. it could lead to important discussions on other topics being missed/ignored

but possibly worth considering? WaggersTALK 09:50, 5 December 2013 (UTC)

Text color

See all the above. These kind of things belong in Preferences. If people want green text on a yellow background, let them (can't see the appeal of that pzrticular combination though). Fram (talk) 11:12, 11 October 2013 (UTC)

According to their design rationale, the optimum is #030303 (almost black, but not quite). The current text is about #6E6E6E, much lighter. I suppose they're experimenting with color and will default to the recommended darker grey in the next version. Diego (talk) 12:20, 11 October 2013 (UTC)

@Fram I'm not sure if you meant allow customization in a way that is visible to all users or just customization that is visible to you. But I'll try to answer both questions, the reason we don't want font customization that is visible to other users is that we want an experience that is consistent and familiar no matter who's board your talking on. While we will have a customizable header area above each board our hope is that people will keep it rather minimal so as to make sure the the conversations are still visible and prominent on their board and not "below the fold." There is no way we could prevent users from customizing the look of type on their board for themselves, though custom CSS, gadgets, userscripts, etc. nor do we have any intention to try to prohibit this. However it is not our priority or desire to add this type of customization into the system itself.—

Jared Zimmerman (talk) 20:51, 12 October 2013 (UTC)

@Diego, I think the color mismatch between the spec & FAQ and the actual prototype may be a bug, good catch.—

Jared Zimmerman (talk) 20:51, 12 October 2013 (UTC)

Paragraph reflowing

Fixed width and zooming don't get along with each other. If I zoom in to make the text size more readable, particularly on the mobile phone, the lines of text overflow to the right, and I need to scroll left and right for each line. Instead, the text should reflow so that every line is always shown in its entirety. Diego (talk) 12:16, 11 October 2013 (UTC)

@Diego, Thanks for your comment, this is a great point, and certainly on our radar, accessibility features such as supporting browser text zoom, and mobile implementation are in a later sprint. But glad to hear these features are important to you.—

JZimmerman (WMF) (talk) 17:38, 11 October 2013 (UTC)

Take a look at http://www.javascriptkit.com/dhtmltutors/cssmediaqueries4.shtml, it's not rocket science. :D If the width of the screen or display device is smaller than the fixed size of the page, use a smaller fixed size (or just remove the fixed size and let things sort themselves out the way the CSS tells them to sort themselves out). It's great that you all have a vision of how things should look, but when that vision breaks it should degrade gracefully and fit as best as it can (and I think we can all agree that sideways scrolling to read something is seriously annoying). Banaticus (talk) 06:15, 17 October 2013 (UTC)

@Banaticus, thankfully we have rocket scientists on our team, just in case. Thank you for the code samples. Our team is aware of how to achieve this, it just wasn't the priority for the first few sprints. but rest assure it is part of our first release.—

Jared Zimmerman (talk) 17:45, 17 October 2013 (UTC)

Cross your heart and hope to die? ;) I've seen mention of "minimum" and "maximum" display widths since and it doesn't look like they're going away any time soon. The minimum display size in Flow would seem to be quite a bit larger than it currently is. 03:29, 2 November 2013 (UTC)

Nesting & thread depth

You know, I think the current design might just work as an equivalent to current talk pages, provided that:

• The level-1 nested comments get also a "Reply" button, that automatically includes @Username. The new reply is posted at the bottom of the subthread, just like now.
• The new reply includes a link to the comment it's replying to.
• Each nested comment keeps track of how many people has replied directly to it, and can unfold a list of links to the replies.

This way you get potentially unlimited nesting levels, but keep the flat look. This is approximately how Twitter does it, BTW. Diego (talk) 08:38, 12 October 2013 (UTC)

@Diego, very interesting, its almost as if you read our minds, or our design docs :) if you take a look at this markup you'll see that per tangent reply actions are already planned, while you don't see it in the design, I think we're on the same page about including @Username as a prefix to messages that are initiated that way. Your last two points are interesting ones, although they bring up their own complexities. e.g. if you "expand" a reply chain on the page, do you see multiple instances of some messages? that could be confusing. Another option would be to only show this detail level threading on the permalinks to individual comments, but this has its own issues in that without the context of the other messages you might not be able to follow the conversation if someone didn't explicitly @reply someone. Design challenges aside, its an interesting idea that we'll put some additional serious thought into.—

Jared Zimmerman (talk) 20:33, 12 October 2013 (UTC)

if you "expand" a reply chain on the page, do you see multiple instances of some messages? Use the power of the hyperlinks. Instead of expanding the comments in place, provide an internal anchor to jump to the place where the other comment is located.

only show this detail level threading on the permalinks to individual comments I've experienced following a permalink to find only one comment in Liquidthreads, and it's totally disorienting. It's best to always show all comments of the shown thread. I also prefer it when all threads of the same board are shown in sequence, rather than a filter where a single thread is singled out. The most natural model for web content has always been the static page. Diego (talk) 23:06, 12 October 2013 (UTC)

@Diego, I think we're on the same page here, although I'm not sure exactly how the expanding would work, but I understand what you're asking for and I think we can get there.—

Jared Zimmerman (talk) 07:19, 13 October 2013 (UTC)

@Diego, also forgot to mention, we have plans to make it very easy to mention other users in your conversations as well, which should also help alleviate the problem of "who were you directing that comment at"—

Jared Zimmerman (talk) 20:37, 12 October 2013 (UTC)

I'm glad to hear that, it sounds like a great feature to have :-) Diego (talk) 09:37, 14 October 2013 (UTC)

Mouseover behavior

You may already have noticed this. The behavior of the hover event for user names is wrong. Currently, the (Talk | contrib) links only appear when pointing directly to the user name, which forces the user to make a strange L-shaped movement to reach those links; therefore duplicating the time to reach the target. The right behavior is to show those links when the mouse is placed on the white space that the hidden links occupy. You get it right for the buttons to the right of the topic titles; it should behave the same for consistency.

This is the same mistake that was made on the Visual Editor for the first version of the [Edit | Edit source] links, that were not static as they're now. You may want to write down its solution in your internal guidelines, so that your developers always have this detail in mind when creating this kind of hidden, small targets. Diego (talk) 08:10, 13 October 2013 (UTC)

@Diego, This part of the prototype is not finished, however your point about about reusing the blank space in an interesting one, from the design documents, sorry I can't find the one that shows the design, its similar to the flag actions menu. Since user names can appear in the middle of the text when people mention others, there won't always be blank area to the right of the name. As the prototype evolves I'd love to hear your feedback on how this particular feature works when you see it further along. As far as reusing patterns across products as you suggest, we firmly believe that is a great way to do things, when the pattern is good. However just because its something you see one feature team doesn't necessarily mean it is something we want to codify into policy or pattern library until its been thoroughly validated by other teams and by people using the products.—

Jared Zimmerman (talk) 06:13, 14 October 2013 (UTC)

If the user names appear within text, use the current interaction only for that situation. That's no excuse to extend the difficult-to-use behavior where there's enough white space to contain the hidden elements. The community already provided feedback on this interaction style on a very similar context (the header area of sections and the VE edit link), and it had to be changed; the animation was removed and they are always shown now. Of course you may want to test it again to see if the results are robust. I've found that in the current use it causes the problems I reported above, so that's one data point already for your report.

I've always found that showing hidden menus on hover is problematic. It doesn't work at all in mobile, and it requires this difficult double-aim, praying that the pop-up does not auto-hide while moving the pointer. Reserving the white space, so that the hidden controls don't overlap any content, solves both problems.

I hope the flag prototype you shown in that image will require clicking before showing the "hide, delete, suppress" buttons. Requiring a click makes it a different interaction, as now the pop-up will not hide when moving the mouse around. It still requires aiming two times, but now the second aim is easier and less error-prone. Diego (talk) 08:41, 14 October 2013 (UTC)

@Diego, the one "excuse" is the one you brought up, design consistency, whichever interaction the team goes forward with for now, will likely be used in both contexts, so that its consistent. In both places I think the plan was to use hover interactions rather than click, because clicking may have its own behavior, e.g. in the case of a user name, clicking goes to the user page, hover gives access to talk and contribs for that user. Your point about relying on hover for mobile is one we've thought about, and for now the prototype is not focusing on mobile interactions (although we are designing them in tangent). What action you can do while mobile will be informed by user feedback, so all actions may not be available at first launch on mobile.—

Jared Zimmerman (talk) 00:37, 15 October 2013 (UTC)

If you must use the same behavior at both places and force us to perform the double-aim when it's not needed, at least include a clickable element (maybe a small icon to the right) that prevents the pop-up links from hiding. You may be young and don't have problems aiming with the mouse, but please think of us with unsteady hands. Diego (talk) 05:25, 15 October 2013 (UTC)

I do not wish to miss this opportunity to thank the dev team for the design of this feature in the current version, where the links associated to a user name appear by pointing to the white space reserved to display them. :-) I and my wrist will appreciate that detail in many occasions. Diego (talk) 22:22, 27 November 2013 (UTC)

Everything

Almost ideal appearance. I would only wrap posts in tight rectangular outlines to separate them from each other. The "reply" button I would put right next to the signature, along with some other options.

• The header looks ugly with the serif font and without the horizontal rule. Please revert it to be consistent with the rest of MediaWiki.
• There is a large empty space to the right of the Flow board. Ugly.
• The fonts are too large. There is too much padding. And yet, at the same time, posts are not clearly separated from each other.
• Fading animations distract from the discussion content. Gratuitous shadows, also needlessly animated.
• I would prefer to see signatures at the end of the post, along with reply buttons and other actions.

I also see no functionality to view the markup for a given post. This is sometimes useful.

Keφr 10:27, 15 December 2013 (UTC)

@Kephir: Hi. In order:

• Typography inconsistency - 1 other person has mentioned this (to me in person). [Sidenote: I think this is related to the mw:Typography Update, which I know is due to be updated based on all the feedback, sometime soon. I know you've commented there already, but others might be interested (however: hold off for a few more days/weeks, until v2 is out).]
• The whitespace - this has been mentioned a few times. I don't think "ugly" is an appropriate word, but it's definitely not pleasing to everyone (however some editors really do like it!). There are many possible options, that all warrant further discussion and experimentation. Let's try to keep that topic discussed up at #Whitespace & padding for non-fragmentation? :)
• Font size - Ditto from the whitespace. I like tiny text, you like tiny text, but other editors appreciate the increased size. We have many options though, and many (all!) demographics to satisfy. There's a possibility of preferences, but they want to get the "defaults" into a better place first. KISS first, complexity after. ;)
• Post separation - Hmmm, good point. Let's re-examine this one in a few days/weeks when the next set of design updates is live.
• Fading animation - They're working on some new designs that remove many of the links-only-appear-on-rollover, eg the "Reply" links. (Note: At least one editor complimented the fade-in effect! Definitely can't please everyone... ;)
• Signature/Username position - previously discussed at Wikipedia talk:Flow/Archive 2#Prototype has a very strong emphasis on author, not on message. It's definitely different from what we use currently, but putting the author's name first does have a strong precedent. [Sidenote: They are going to move the timestamp up, to be on the same horizontal level, which will help.]
• Reply button position - At least one other editor suggested the reply button should be on the right. I'll try to find that comment later.
• View markup - it's on the tasklist [7].

HTH. Quiddity (WMF) (talk) 01:01, 19 December 2013 (UTC)

Sounds arguably-reasonable-to-good, mostly. As for font size, I think it is not unreasonable to set fonts to the same size as they are everywhere else. People preferring larger fonts will probably want to enable larger fonts everywhere (e.g. using browser zoom). Keφr 14:09, 19 December 2013 (UTC)

Quick note to self: this was where two other editors (MarkJ and Klipe) and here (Waggers) suggested that the reply button could go (somewhere) on the right. Quiddity (WMF) (talk) 01:16, 20 December 2013 (UTC)

@Quiddity (WMF): About the "Reply button position": I may be the one you thought about, cf [8]. By the way, it took me a few minutes to find this post back although it was my own... Hopefully at least either "personal subscription" or "topic-level watch" or "seach" is very high on the priorities list! Klipe (talk) 09:31, 23 December 2013 (UTC)

The "Small View" should be the default view

The current default view is "full view". It can be changed to "small view" by clicking one of the three buttons on the top right side of Flow. The "small view" is much more compact, much more aesthetically pleasing, much more organized, and much more forum-like than the default "full view". Softwatt (talk) 08:49, 6 July 2014 (UTC)

We've got a visual design change coming up on Thursday to Wikipedia -- it's on Mediawiki.org right now. I'd be interested in knowing your thoughts about that new design -- does that change your opinion about full view vs small view? -- DannyH (WMF) (talk) 19:23, 6 July 2014 (UTC)

Top posting? Are you kidding?

Did you really write, that you are going to use top-posting as design? Are we going to play jeopardy`or discussing? Wikipedia to a large degree is a-syncrous and time lapse. Most of us do not sit in front of screens bored to death, waiting for something to happen. And we are not involved in just one discussion at at time. If I may speak for myself, I watch some 4000 articles plus a large number of pages "behind the scene" - and their talk pages! I run my watchlist once or twice a day and answer everything relevant that has come up since my last pull. I - and many, many other active contributors - need discussions in their context, not just individual posts. Top posting destroys that. So it is mandatory to use top down discussion threads where I can follow the order if arguments in the natural flow of reading! This is NOT open to discussion but a demand of the active user base to you, the developers . Either you support that in the code or I promise you that Flow will never be operating. rgds --h-stt !? 09:02, 18 November 2013 (UTC)

Looking at the prototype, you don't have to worry about Flow anytime soon, there is little improvement noticeable compared to about a month ago (some changes, but no actual improvements). Considering that apparently changes made in Flow aren't even yet visible in your contributions, I think we (or "they") still have a very long way to go before even the planned limited rollout is coming (it was planned for late 2013, but I don't see it happening so soon). Flow as a general environment for discussion pages won't happen before 2015 at the earliest (assuming it doesn't go the way of the dodo, LiquidThreads, and probably Visual Editor first). Having said that, I share your concern. Fram (talk) 09:25, 18 November 2013 (UTC)

The current design is being optimized to make sense for newcomers. I can see the benefit of top posting to keep inexperienced users informed, so I think it's a good idea to have it as the default. The top posting is done at the thread level with individual posts shown in order within each thread, so it's not as bad as you put it; but the top-post, infinite scrolling format is clearly not a good choice for more complex discussions that involve several threads over months, and more advanced reading formats should be made available. It seems that they have decided that the design must use infinite scroll, whether or not it makes sense (I have not seen any rationale for that decision in the design specs, it's just a given), so I don't hope that this will change; I only hope that an alternative will be provided for the use cases where it makes users miserable.

I've been advocating for a paginated index view and an option to short by date of posting, so that the whole archive of discussions can be accessed and studied in the same order as it was written for any period. The developers have promised that they have though of a way to access older threads (mostly based on searching, it seems, with no signs of spatial navigation in sight), but a.f.a.i.k. they have given no hint in the design documents as to what that solution will look like (though there's an architecture document detailing some planned features for it). Let's wait and see. Diego (talk) 10:20, 18 November 2013 (UTC)

Dear Devs, you still believe, that you are to design a cool new social website and look to Twitter for inspiration. What you don't get, is that Wikipedia's talk pages are not entertainment or drive by, off hand commenting but a place for hard work. Collaborative writing of texts with authoritative quality is something completely different than pushing out 140 chars about your fav restaurant. We need to fine tune every sentence, every word and even the punctuation on controversial and sometimes contested issues. We do so in teams of two or three, sometimes with more than ten active participants, often with newcomers throwing in an idea but not following up, ... Dear Devs, I know you aren't writers at Wikipedia, but please imagine this just once:

Would you want to read a Wikipedia article on [Obamacare|your mother's illness|Scientology], if the article had been discussed on the Flow platform according to the current model?

This is dead serious, you are destroying Wikipedia's ability to discuss complex issues. Stop and rethink! grds --h-stt !? 13:51, 18 November 2013 (UTC)

@H-stt: As Diego says, new Topics are posted at the top (which is different from what we are used to), but new Posts will be in chronological order (new posts get added at the bottom of each Topic, or each reply-tangent). We definitely would not do "newest first" old-youtube-style ordering!

Many of the staff working on Flow (from devs to the product manager) are long-time Wiki[p/m]edians - they are familiar with the nuances and complexities of our numerous projects. But they do need us to continuously help: by voicing concerns and discussing solutions, by testing the developing software, and by suggesting new (even far-future) features that it could have. Flow's best chance of improving our current discussion system, is if we all help it along.

I recently asked the team what specific sites they're using as design- and feature-inspiration (I know Stackoverflow.com is one of them - it has complex questions, detailed answers, with limited subthreading. e.g.), and I'll update this thread when I hear back with more. –Quiddity (WMF) (talk) 23:47, 18 November 2013 (UTC)

Top posting for discussion in depth

If I understand H-stt well ("Did you really write, that you are going to use top-posting as design? Are we going to play jeopardy`or discussing?"above), he sees a danger for the discussion in top posting. I should welcome top posting for the sake of discussion. H-stt is afraid he will miss the context of a new contribution if it is top posted, but if the contributor describes this context in his contribution this is repaired. It will be more work for the contributor, but it will enhance the quality of his contribution. I plead for top posting, even on thread-level. Sidallum (talk) 14:58, 2 September 2015 (UTC)

Flow and whitespace in practice

Since Flow is planned to be rolled out on WikiProject discussion pages before anything else, I decided to take a sample WikiProject talk page discussion and put it into Flow to see what it looked like. Here's the original discussion, from WikiProject Chess: [9]. I put it in Flow here.

On my system, where the browser window is a comfortable 1366x883, the wikitext discussion almost fills the screen. (I can see it plus seven or so lines of the surrounding sections.) See [10]. However, in Flow, the discussion takes up just over two screenfuls ([11]).

I personally find the current iteration of Flow an impediment to good communication, simply because it is so inefficient with screen real estate. That term "screen real estate" seems to have been forgotten to some degree, but I think it's worth keeping in mind how valuable screen space is, even in this age of HD, high-resolution displays. There needs to be some more thought put into how Flow can be optimised to fit more neatly on desktop monitors (reduce font size? less padding? greater width?). While the designers might abhor our current super-dense discussions, they will meet sizeable opposition from established users if they don't reconsider their choice of spacing.

Do you prefer the Flow layout? Do you prefer the existing wikitext style, from an established user's perspective? How about from a new user's perspective? — This, that and the other (talk) 10:21, 27 November 2013 (UTC)

IMHO they're trying too hard to base the design on current trends, and in doing that they are looking at the wrong sites (blogs, forums, Q&A sites) for inspiration. if you look instead at designs used for coordination on applications dedicated to build collaborative documents, you find that they use much more compact layouts.

Here is an example of the style used by the MS office suite in its online comments, and here is the equivalent feature for Google Drive. See how, in both cases, comments by new users are immediately below the previous one with only a small amount of separation, without any huge gaps that impede readability. This is how Flow threads should look. Diego (talk) 11:15, 27 November 2013 (UTC)

Both good examples – but I think you're underestimating the importance of the avatar in both of them. Avatars go a long way toward making it extremely clear that these are people talking to other people, as well as drawing distinct authorship boundaries around individual comments for scanning purposes. In our communities, where there's no concept of an avatar, it's easy for long rows of text to bleed together and cause confusion, especially when you have links in comments. If you take a look at these comments and imagine that there's no whitespace between them, it would be very easy to confuse who started the comment with who's being mentioned (esp. if you're scanning the page quickly). Maryana (WMF) (talk) 20:03, 27 November 2013 (UTC)

Well, and I think you're overestimating the importance of the avatar. :-) There are many ways to distinguish the author of each post using secondary

notation like weight, color and texture; in the post by Fram (Fram: under the hat), it's easy to distinguish the author (bold, in red) from the mention right below (regular font, blue). In your example, the amount of whitespace is just ridiculous - the separation provided by the header of each post, displaying the

editor's name, would be all that's needed. (Of course, indenting each reply one level also helps a lot, although the current version of Flow has abandoned that model). See, the problem with white space is that it creates this huge bars of negative space that interrupt the reading flow (if there's a pun in there, it's intended).

This makes it quite uncomfortable to follow the conversation. Discussions at Wikipedia Talk pages are made of long arguments, where each comment logically follows from the posts above them made by other editors, and that read like a book, with paragraphs; not by self-contained comments isolated one from another, where each post holds a full independent idea, which would read like Twitter streams. The huge gaps between comments produce

stumbling blocks that stop the eye dead in its tracks and prevent from reading as a single conversation, and more like a machine that stutters and gets clogged up. Diego (talk) 21:49, 27 November 2013 (UTC)

@This, that and the other and Diego Moya: See also Wikipedia_talk:WikiProject_Hampshire and Talk:River_source which I copied across a few weeks/days ago. I copied them across diff-by-diff by going through the history, and used a variety of accounts, so hopefully that's a fairly accurate representation of how it might look (except for the clustered times). (And thanks for the feedback thus far :) –Quiddity (WMF) (talk) 18:52, 27 November 2013 (UTC)

I have a suggestion to alleviate the problem that Maryana comments about distinguishing post's authors from user mentions. Currently, every time you press Reply, the answer box gets pre-populated with a mention of the user you're replying to. This is not needed when the Reply button is pressed at the last comment in a sub-thread, as it's clear than the comment is a direct reply to the text above it. In fact, I'd say it's counterproductive to include it always: it gets distracting to see it in every comment, and it creates a kind of "banner blindness". (See this longer, more nested example thread and see if you can spot the one comment that was made out of sequence in the original discussion).

If the automatic mention is added only when pressing Reply to one of the intermediate comments, that would signal a comment that is made out of sequence and it's not a reply to the comment immediately above it; this would make those out-of-sequence comments more rare, and easier to spot. Diego (talk) 23:13, 27 November 2013 (UTC)

Diego Moya: That makes a lot of sense... though how could we tell if someone was replying generically to the bottom of the thread or replying directly to the last comment in the thread? Maryana (WMF) (talk) 00:53, 28 November 2013 (UTC)

@Maryana (WMF): I see where you're coming from, but I still find the layout of Flow hard to swallow.

• On a busy wiki like enwiki, there is lots of information that needs to be exchanged quickly. Contributors are not around all the time, so when they come back to the wiki from sleep, work, etc, they might want to scan the day's discussions. By spreading out the discussion so widely, it makes it difficult to take in large volumes of information.
• Flow is really going out on a limb when it comes to whitespace and font size. You could hardly call YouTube comments, etc. "high-volume" discussion platforms, yet even they have 10-point font sizes with reasonable spacing. I still don't understand why Flow is going against the norm here by using immense 12-point font and large amounts of whitespace: even if there is research to back it up, it is simply not suited to the long comments that people like to post around here.
• I always found LiquidThreads very unattractive because of the large areas of gray space surrounding the comments. It felt like a half-finished, partly broken software project. While Flow obviously still is a half-finished project, to me it still has a feeling of brokenness/FOUC about it, and the white, "snowed-in" interface is very cold and uninviting.

I hope you can use these comments, combined with those of other experienced users, to help make Flow a better experience for established users. — This, that and the other (talk) 00:03, 28 November 2013 (UTC)

This, that and the other, re: Flow is really going out on a limb when it comes to whitespace and font size – yes, I agree :) There was definitely never any danger of getting clamorous shouts for more whitespace and bigger fonts from Wikipedians, so the design started off maximally big and open. We'll work on tightening it up to make it more appropriate for the kinds of long, dense conversations that tend to happen on Wikipedia.

But I also think this first iteration of Flow looks a lot like where the Internet as a whole is moving. If you look at sites like Medium, which are lauded in the industry for their clean, friendly UI, and compare it to the Facebooks and Twitters of the 2006-ish era, it's pretty clear that standards for font size and whitespace have changed dramatically in the past couple of years, and will probably change even more in years to come. That's not to say that we have to slavishly anticipate/follow those standards, but that there's some degree of future-proofing that we need to build in, so we don't end up having to revamp everything 5-10 years from now because it looks completely different from what everyone online is used to seeing on a website.

Anyway, thanks for your comments, and I hope you'll stick around and keep us honest as we continue to build on & improve this thing ;) Maryana (WMF) (talk) 01:13, 28 November 2013 (UTC)

As for the "standards" of white space usage, they don't necessarily have to change, and they definitely shouldn't change if its for the worse. See this other example - a dialog from a book.

You don't need avatars, colors nor huge interrupting gaps. The space is ample but kept to sane levels, and its easy to follow the conversation between the four participants. Of course that requires reading it in order, which is the use case for which it's optimized. That design has been validated through literally hundreds of years and millions of readers, so before you deviate from that standard you should be really sure to have a better reason than merely following the fashion of the day. You're instead copying designs optimized for writting, and it shows in its current poor reading experience. It could be greatly improved, but you need to recognize that talk pages main usage is reading long threads and follow that purpose, even if it makes first time use slightly more inconvenient. I'm all for helping newcomers, but they'll also be reading existing discussions long before participating in them, so that's no excuse. Diego (talk) 07:31, 28 November 2013 (UTC)

Maryana (WMF) how could we tell if someone was replying generically to the bottom of the thread or replying directly to the last comment in the thread? Uh? Is that a trick question? The Flow prototype solves that problem pretty nicely, having both a "reply" button where the comment is shown indented and a generic "comment" text field that is shown at the base level. Surely that question was a hook to get some praise from me? ;-) Well, I give praise were praise is due. The current iteration of the design has lots of improved details, and I can see it becoming a robust and pleasant to use experience (at some point in future). Diego (talk) 07:10, 28 November 2013 (UTC)

Heh, I meant how could you tell within an indented block of replies? If you, Ironholds, and Quiddity have responded to a question I've posted, which looks like so:

Topic title

Comment from me

Comment by Diego Moya

Comment by Ironholds

Comment by Quiddity

Reply box

... and I reply to Quiddity using the direct reply link under his post, am I replying directly to Quiddity, or to everyone in that indented thread? It's a bit ambiguous. Maryana (WMF) (talk) 00:28, 3 December 2013 (UTC)

@User talk:Maryana (WMF), sorry for the late reply. That ambiguity has never supposed a problem in talk pages so far, with users adding indented comments to the thread either when their post is a direct reply or when it's a general continuation to the thread; in any case the current version of Flow doesn't solve it - it will include the @User mention even if the reply was targeted to the whole thread.

The natural way to unfold the conversation is by directly posting below the last comment; the ambiguity is almost always made clear by context. By adding the @User mention only to out-of-order comments, it's much easier to follow the general conversation and to spot those replies to an earlier comment:

Topic title

Comment from Maryana

Comment by Diego Moya

Comment by Ironholds

Comment by Quiddity

@Diego Moya: Comment by Maryana

Reply box

And, if the poster really wants to solve the ambiguity you mentioned, they can always manually add the @User mention (or you could have a "quote this user" button to add it):

Topic title

Comment from Maryana

Comment by Diego Moya

Comment by Ironholds

Comment by Quiddity

@Quiddity: Comment by Maryana

Reply box

Diego (talk) 17:16, 5 December 2013 (UTC)

@Diego: Is it so unusual to reply on a post immediately below that post? I see this quite frequently. I also see posts being broken into parts with replies on individual sentences or ideas. For this, I guess some quotation mechanism is foreseen at a later stage, so I let it aside for now. In the first of your latest examples above, I would have expected "@Diego Moya: Comment by Maryana" to be posted as a reply to "Comment by Diego Moya", hence appearing immediately under that post (since it was said that "Comment by Ironholds" is a reply to "Comment from Maryana"). Without further levels of indent and without the @User mention, this introduces confusion. Since "Comment by Ironholds" already existed and doesn't include @User, we don't know where it fits in the hierarchy. The @User mention could still be added when needed, but... how could we (Ironholds in this example) know in advance that it will eventually be needed when Maryana will have replied to Diego Moya's comment later on?

Moreover, I guess that the @User code triggers Echo notification to that user.

However, maybe this could be made less intrusive for those who dislike it. What about a preference to have the @User indications collapsed into just the @ sign (or an @ icon to distinguish it from text)? With the info still available as tooltip or on-click pop-up.

@Maryana (WMF): You mentioned earlier above that "it's easy for long rows of text to bleed together and cause confusion, especially when you have links in comments.". I agree with you, as I experienced this several times already on WP:en talk pages. However, I also fully agree with the need Diego and others expressed to have much more information available at once on the screen. Did you consider alternatives to the huge vertical white spaces? For instance, WP:fr helps discriminating between consecutive posts on talk pages thanks to alternating colours and light lines (e.g. fr:Discussion Projet:Échecs#Palettes ouvertures). Klipe (talk) 00:20, 14 December 2013 (UTC)

Infinite scrolling vs Table of Contents

I read here that they'll add a "collapse all threads" feature to serve as a (kind of) table of contents. So I ask: Quiddity, will scrolling collapsed threads load only thread titles, for increased speed? Or will it load the whole content of comments for each thread even if it's collapsed? The main problem with infinite scrolling has always been that it takes ages to arrive to the part of the conversation that you're interested in, as you're forced to load everything above it even if it's only to be discarded and never read. Diego (talk) 11:24, 27 November 2013 (UTC)

Hmm, interesting thought. The closest I've seen to that idea in-action, is Gmail's collapsed-thread-view, where it only loads the messages when I click-to-expand.

In the current (and upcoming buttons) version of Flow, it will not work like that. However, I've asked the devs, and from a technical standpoint it is definitely an option that we can consider. Further brainstorming on this (pros/cons, defaults, etc) would be appreciated. –Quiddity (WMF) (talk) 19:04, 27 November 2013 (UTC)

It's funny how the example you use uses pagination for the element with more items and a long history (the Inbox), not infinite scrolling. In as system like that, where the design is geared towards archiving content in one long stream for easy retrieval, random access that allows the user to jump to any point in the stream is of utter importance.

It looks more and more that your team's take at a minimal viable product has been geared exclusively towards short term collaboration and getting old content out of sight quickly; and that in the current design there's lack of in-depth though of features and ways for retrieving and analyzing arbitrary content from the archives (with all hopes placed on an yet-to-be-determined search mechanism). Am I wrong? Diego (talk) 22:03, 27 November 2013 (UTC)

P.S.- I've talked extensively about the requirements for accessing archived content at this thread of the Design FAQ talk. Diego (talk) 22:15, 27 November 2013 (UTC)

Studying the Gmail threads in more detail, I like how for longer threads (with >15 posts) only the first and last comment headers are shown, with the intermediate elements hidden under a collapsed strip representing "X older messages", that expands to show all headers when clicked.

I don't like that there is only one strip; I think the concept could be expanded if there were several similar folded strips, one for each period of time (weeks, months) with a high posts count. That could scale to provide an alternative, or at least a complement, to pagination in many cases. Diego (talk) 22:31, 27 November 2013 (UTC)

I'm not sure I entirely agree with your assessment of how pagination is used in email. Most people I know who get a lot of email, self included, just use keyword search to find older content – once you have hundreds of pages worth of messages, pagination becomes irrelevant.

But I don't disagree that infinite scroll puts more emphasis on the present/near-past and makes it harder to read in chronological order (earliest to latest). Is this a bad thing in all cases on Wikipedia? Maybe. I'm guessing there are some discussion spaces where being able to read past discussion from start to finish is more important (e.g., an article talk page), and other spaces where that matters less, and where it's more important to be able to search for specific older content (e.g., a WikiProject talk page, where you probably don't care as much about following all of the now-outdated discussions around improving content unless you have a specific decision/debate in mind that matters to you now). In more concrete terms, pagination might help elucidate the intensity of the great Gdansk/Danzig debate, but it probably isn't going to help you find that one time you and User:Foo had a debate about the use of infoboxes, where you decided that in all future cases Infobox:Bar would always be used on new stubs in your project – or at least, it won't help you anywhere near as much as just being able to search for User:Foo and/or Infobox:Bar. Perhaps, though, this dichotomy isn't quite so clear-cut, and WikiProject users will find they miss the ability to replay older discussions – if the need arises, we can certainly add pagination in.

In any case, these are fairly meaty issues, fodder for a PhD thesis in information science. The mental model of Wikipedia discussions isn't exactly like email, or like social media, or really like anything out there on the Internet, so I don't think it's realistic to assume that anyone can figure out a perfect system for it in a vacuum, without a real-world trial of the software. That means having one approach to start with, testing it in the wild, and being perfectly willing to pivot when it proves necessary. Maryana (WMF) (talk) 01:13, 3 December 2013 (UTC)

I agree with your points here Maryana - it's clear that you have a good feel for how things work around here. But I just want to point out that being able to access talk page discussions by date is quite important. ClueBot can be set up to use monthly archives, which I often find very helpful on moderately busy user talk pages. For example, when looking at an article history, you may come across an edit someone made in December 2011, and you might want to see if this was discussed with them on their user talk page at the time. Or alternatively, you might recall that an issue was brought up on your user talk page in about June 2010 (or was it May or July?) and you might want to go back and look at the discussion. Admittedly, I see this as being more important for user talk pages than for WikiProject talk, but even so, I think it could be very useful on all talk pages (what if I wanted to look at the great debate that occurred on WikiProject Abc's talk page in month X of year Y? Can't remember the exact topic, but I certainly remember when it took place...) — This, that and the other (talk) 05:50, 3 December 2013 (UTC)

I have exactly the same use case in mind as you, This, that and the other, and the way I solve it in current lengthy talk pages is of course by looking at the concise table of content first, possibly complemented with a search on the page thanks to browser features (e.g. Ctrl-F). With Flow, I would hope to get both a ToC and a "search within this flow" feature. And, if Flow wants to bring in a new, more efficient way of finding back useful conversations, I would actually imagine a combination of these two features where a "search within this flow" would highlight in the table of content all the topics containing the searched string and provide an option to expand the content of all those topics while leaving the other ones collapsed. Klipe (talk) 09:32, 5 December 2013 (UTC)

As Klipe and TTO point out, there are cases where you'll want to search for a specific old thread, but also there will always be cases where you couldn't possibly know what to search for. I don't think pagination is the be all and end all solution, but it has certain advantages over a search system that makes it more adequate for those cases. The best approach I've found so far to this problem is the histogram of the number of updated at archive.org (at the top of the page, as seen here); that design combines the best of both worlds.

Wikipedia differs from a personal information management tool in that you don't have a previous idea of all the content that has been archived - you'll want to look for threads that you've never seen before, and even threads that could possibly not exist (e.g. "did people leave any comment at the talk page three years ago when they added this content?"). Therefore it's important to support several alternative tools for content recovery and made them as general as possible, instead of tweaking them for the two or three use cases that you happen to study during the development phase. I'm eager to see the next version, which will contain the first approach to something resembling a TOC; and I'm glad that the possibility to pivot the design in new directions is open. Diego (talk) 17:32, 5 December 2013 (UTC)

Obligatory xkcd

This xkcd strip is relevant here. As always, Randall explains it better than I ever could. Diego (talk) 13:18, 28 December 2013 (UTC)

Hehe, yup, I linked to that strip in IRC on Friday, as I'd run into exactly that problem the night before on tumblr. As I said there: ("No! I wanted middle-click, not left-click! Aagh! Click-back-and-pray-it-all-reloads...? Nope, top of page 1.")

However, I think it is possible to do it right, because some infinite scroll sites work correctly, eg http://boingboing.net/ - I can scroll down till it loads more, leftclick a link, then the backbutton - it even works for the more complicated: click a link, and then keep clicking further and further away, then click the backbutton multiple times, and if necessary boingboing will automagically reload all the content and scroll the page down to the correct location. (at least in Firefox. I'm not sure if it works consistently cross-browser/OS?).

But yah, the main thread above still covers the gist of it all. (And anything XKCD doesn't explain, Calvin&Hobbes does ;) Quiddity (WMF) (talk) 21:02, 30 December 2013 (UTC)

My name attached to all the empty comments

Tracked in Phabricator
Task T60413

Could you please remove the instance of the own user name that's attached above each "Comment on <thread>" box?

I find it quite distracting. Each time I arrive to the end of a thread, I get this instinctive "wtf? I didn't comment on this thread yet!" feeling, right before noticing "oh yeah, it's that fricking 'your comment here' call to action". It's been there for weeks and I still get it wrong every time I scroll down.

Plus, it makes much more difficult to find the real instances where I actually 'have written a comment in a thread. Diego (talk) 16:36, 23 December 2013 (UTC)

There's a bug for that! :) (As Oliver says there, "I think this will be fixed as part of wider changes to the replying/commenting UI.") Quiddity (WMF) (talk) 18:22, 23 December 2013 (UTC)

Why are we using colored-buttons, instead of plain-text-link buttons?

"Not that they are less important, they are, however, not as important" Care to explain the difference between "less important" and "not as important"? Fram (talk) 14:57, 14 January 2014 (UTC)

From the same section: "The blue-colored button signifies a progressive action that requires more steps ahead, while a green-colored button signifies the final progressive action." I have no idea where there are blue buttons for the moment (I notice a green "reply" and a green "change title", that's it), but anyway, this is completely obscured from the users, and unimportant anyway, so pleae don't use different colours to convey such meanings, and please try to explain them more clearly anyway (a "progressive" action? Wouldn't simply "an action" do?) Fram (talk) 15:03, 14 January 2014 (UTC)

@Fram: This is part of the UX standardization, a subset of the Agora design project. There are further details, still being worked on and updated, at mw:Wikimedia Foundation Design/Agora Control Library, and mw:Wikimedia Foundation Design/Patterns and components#Buttons/Actions, and mw:UX standardization. See also the recent/ongoing design mailing list thread. The ongoing nature of the project is why live updates/changes/tests/tweaks are being seen (or not seen ;).

I will nudge the relevant people, to give us an update/ETA on any upcoming changes, to both the Agora spec, and Flow's implementation(s) (and the Design FAQ entry about it). Quiddity (WMF) (talk) 21:42, 16 January 2014 (UTC)

Thanks. Not happy with either the colors and size or with the difference between the documents and the actual Flow look (I mean, the UX standardization page claims "The styles used in Flow are currently the most up-to-date per the design team", but this is clearly not true, only the green style has been implemented somewhat, at the moment we have a green "add topic" or "reply", a white "preview", and a non-bordered (!) white "cancel", so that last one doesn't even look like a button now... Before I have typed anything in Flow, the "cancel" and "preview" look the same as afterwards, but the "save" has been greyed out (OK, but not how it is described in the style guid, and why not the other two?). "Reply" is a small grey non-button, "# comments" is underlined text, "Hide" (once you've found it) is grey, in a strangely shaped box, with some yellow line next to it; "Show" looks completely different though, no box but square brackets, a grey line in front, ...

At the moment, the interface of Flow is a complete cock-up, without any discernable style, general idea, ... I have no idea why anyone genuinely would claim that "The styles used in Flow are currently the most up-to-date per the design team" (at least I hope that no one believes this, or you probably would need a new design team). Fram (talk) 08:07, 17 January 2014 (UTC)

How will the limited indenting/threading system help?

"Mobile readership is growing dramatically (currently, representing almost 1/4th of total pageviews to Wikipedia),[9] so we need to build for a future where we have users who are purely mobile-only. Multiple indentations will have problems displaying on a small screen."

Readership is mainly restricted to the mainspace, which is not relevant for Flow. Any figures on either percentage of readers of talk pages per device, or percentage of editors per device? That would be a lot more relevant for this FAQ. I can imagine that the percentage of mobile editors is still lower than 25%, but that's a hunch only. Fram (talk) 15:09, 14 January 2014 (UTC)

Pinging @Okeyes (WMF): as the man with the browser stats... :) Quiddity (WMF) (talk) 21:53, 16 January 2014 (UTC)

I'm gathering this sort of data as we speak :). Percentage of editors is hard (they're so rare, comparatively, that picking up on them is...an issue) but we should have data on that as soon as we get the hadoop instance fully running. Okeyes (WMF) (talk) 17:13, 22 January 2014 (UTC)

@Okeyes (WMF): Any new on this, or a timeline? Fram (talk) 13:20, 7 February 2014 (UTC)

"A few months" as I understand it. So, we've got the mobile data streaming into the request logs, and so if you want me to break down where mobile users are going I can totally do that, but the desktop data is much vaster and will have to be prepped for. I'll try to dig out a more precise timeline when the analytics people are around. Okeyes (WMF) (talk) 23:31, 7 February 2014 (UTC)

Thanks. Fram (talk) 13:17, 8 February 2014 (UTC)

Why is it that nearly every time one asks for data from the WMF, they either are not available at all, or promised but never delivered? We are now 10 months since this was asked, and 9 months since it was "a few months" and "a more precise timeline" was promised for "when the analytics people are around". @Okeyes (WMF) and Quiddity (WMF):. Fram (talk) 10:49, 21 November 2014 (UTC)

I don't know. When was the last time you asked for data? If it was 10 months ago...I wouldn't base your assessment off that outdated a set. You could try directly emailing me or leaving a message on my talkpage, of course. In terms of this specific request, I'm on the hook to get a pageviews definition out by December. I'm probably not going to get to it. If someone wants it added to the task backlog, sure, but...see "probably not going to get to it". Okeyes (WMF) (talk) 20:25, 24 November 2014 (UTC)

It's hard enough to get a straight answer from some people at the WMF when doing things out in the open, never mind when dealing with email. I have too many bad experiences (some from this month) from WMF people refusing to answer even the simplest questions about their actual job and edits. If my "set" is outdated, you only have yourself and people like Jdforrester and Whatamidoing to blame. One tends to give up asking for actual data when it never materializes or when people like Whatamidoing start making it up (at least Jorm seems to have left the WMF, so there is progress). Anyway, in January, you were "gathering this sort of data as we speak". So, anything?

If this kind of data is still not available, then you are basing the development of Flow (and the focus on mobile for it) totally on thin air and fundamentally flawed positions. Not the first time, but still disappointing. Fram (talk) 07:39, 25 November 2014 (UTC)

I also offered my talk page as a possibility, so the rant about various staffers you don't like was most definitely unnecessary. And I'm not basing the development of Flow on anything; I work in R&D and have since late January. Okeyes (WMF) (talk) 23:54, 26 November 2014 (UTC)

Thanks for that completely besides the point answer. Nice job of reconfirming all notions of WMF staffers. Why would using your talk or email help one bit? Would you miraculously have the answers then? Or do you have them but are you only willing to provide them if I ask on your talk page? Or what? Please enlighten me as to what difference it would have made if I had used those options instead of asking here? As for your final sentence, again, no idea what the relevance is. You are working in "Research and Development", but you are not responsible for the development, and can't provide the data needed for any research. Conclusion: you are not researching, not developing, and not willing to discuss things out in the open. It seems that the rant of various staffers I don't like is most definitely necessary, as this whole discussion is exemplary of one of the many things that are wrong at and with the WMF. Fram (talk) 08:17, 27 November 2014 (UTC)

No, because you're complaining that I don't respond to pings, and messages on my talkpage send me emails ;p. The point of my last sentence was to indicate I no longer work for the Flow team, or on Flow. I deal with reader traffic data, yes - but that involves kind of a lot of work at the moment which is not related to Flow (coming up with a decent definition for 'pageviews', for example). Again, if you want it added to the task backlog, I can do that, but I think it unlikely that people will find the time to work on it: we have five researchers to support everything from Fundraising to Mobile to random requests from the board. Okeyes (WMF) (talk) 15:51, 29 November 2014 (UTC)

Please say such things in clearer language from the very start next time. I can't be supposed to know any of these things offhand. And I haven't complained that you don't respond to pings, please don't read things in my posts that aren't there. I was complaining that you repeatedly promised to gather these data, but that that always was the last I heard of it. Anyway, the situation remains that tsome of the most fundamental data the Flow team (at least originally) used to define their strategy and priorities, is lacking or largely irrelevant (readers vs. editors). That's nothing new but still worrying. But if there is no one available to change this, then so be it. I just hope that the people responsible for this (or similar things) won't hide behind surveys, data, and so on, when those are in reality not available. We'll see, I guess... Fram (talk) 08:14, 1 December 2014 (UTC)

Tighter design

I've been experimenting with CSS at the new version of the design, and I have arrived to a tighter design that works much better for me than the current layout. I'll post some examples here, to inspire the designers to create an alternate layout that editors may want to activate on their accounts.

• 
  Example 1 - current layout
• 
  Example 1 - tight layout

By comparison, the first impression is that of a more cramped design, but there's still enough separation between one post and the next. As you can see, by removing the space reserved for the Reply links and time stamps, the resulting style has a more tight layout, with all the content "flowing" as a single stream of text. I find this layout much more easy to read as a whole, because each new line jump places you right into the useful content - thus improving the action of reading content, which is not interrupted by interaction elements that get in the way. With the old layout, each time I finish a post, my eyes had to: 1) jump to the Reply link on the next line, 2) jump again to read the name of the poster, 3) jump a third time to actually start reading the next post.

(I've moved the Reply links to the left area, but I should probably find a place for them to the right of the posts).

• 
  Example 2 - current layout
• 
  Example 2 - tight
• 
  Example 2 - cleaner, slightly less tight

• 
  Example 3 - current layout
• 
  Example 3 - tight

I've also tweaked the "small view" layout, to make it look more like a table of contents. Previously I had to zoom out about 50% of the original size to achieve this readable format:

• 
  TOC view - collapsed
• 
  TOC view - one expanded topic

If someone else is interested I can share my CSS changes, although they are somehow a quick hack; I would appreciate if someone could tell me how to reposition the Reply link so that it's anchored to the right side of the comments, instead of the current left side. I plan to use these changes on my own commons.css, so I will keep them updated in the foreseeable future. Diego (talk) 18:39, 4 February 2014 (UTC)

Big +1 to this. Especially in example 2, the whitespace is annoying (whatever the new ergonomists think) with such short messages. These CSS changes make Flow look more appropriately like Wikipedia, IMHO, while keeping the functional enhancements of Flow. Chris857 (talk) 22:18, 5 February 2014 (UTC)

See a related thread at Wikipedia talk:Flow#Whitespace. Quiddity (WMF) (talk) 22:39, 5 February 2014 (UTC)

• I've also made some CSS tweaks of my own:

• 
  before
• 
  after

Any comments/criticisms/suggestions welcome; the code can be found at mw:User:Writ Keeper/trickle.css. Writ Keeper ⚇♔ 22:54, 5 February 2014 (UTC)

Writ Keeper, thanks for thinking about & playing around with the design! The direction you're suggesting on some of these screenshots – e.g., making the small view even more compact – is in line with our thinking for the next design iteration, too. I'm not so sure about the full-width board view, though... imho, it actually increases the feeling of emptiness and whitespace on the right-hand side, because the long topic headers stretch out and point that way even when there's no content for me to look at over there. It also doesn't pass the squint test, which your thumbnails illustrate nicely: I can get a much better general idea of what's going on in the thumbnail to the left (current Flow width) and see all the important functionality coupled with the content, whereas the thumb to the left (your proposed max width) looks messier and more chaotic, and it takes more time for me to process which pieces of functionality/metadata are associated with what.

I do think the current width we have could be increased, but we'll need to play with it so that it works for a mix of long and short comments, which is more realistic on actual WP talk pages (as opposed to the short "test test" comments we're seeing on Flow boards now). Maryana (WMF) (talk) 20:20, 10 February 2014 (UTC)

Well, never let it be said that I'm a design person. :) I was just messing around with things. I do agree that, if we're going to have interface elements on the right side, then having it be full-width isn't a great idea, it was pretty distracting to have to look at the entire other side of the page to see the timestamp, for example. It is a bit more chaotic, too, I'll admit; that's why I added the underline between each post, to make it easier to distinguish between them. Writ Keeper ⚇♔ 20:52, 10 February 2014 (UTC)

Design considerations I want to keep

• Raw wikitext. I want to be able to view the entire page as a raw Wikitext I can copy and work with.
• Luability. I want Lua scripts to be able to read and process entire talk pages as they have the potential to now, for example to alert an editor of the titles of sections where keywords of special interest to him are being discussed on the Science Refdesk, or to extract archives.
• History. I want to be able to see the entire discussion, beginning to end, exactly as it was at a certain point in time.
• Diffs. As in, having them. Hopefully you meant to get around to that. An undo button would come next.
• Table of contents. You know, that's actually a useful thing to have in a near "infinitely" long page.
• Contributions. I want my contributions to tell me where I was - not just a "comment" but what page I was editing, and an edit summary or default heading.
• Defined archives. I'm seeing stuff about "infinite scrollability", haven't seen that demoed, but the thing is: I want to be able to tell someone to read X/archives/100#some_topic and he can go there and read it. Also I find on other sites that infinitely scrollable lists bog down and eventually grind to a halt due to memory concerns, etc.; the editor can't be allowed to fail this way no matter HOW busy a forum is.
• SAME wikitext rules. I was getting unknown errors for having an unmatched tag in text. I don't have that in regular wikitext. There should be only one set of rules for how to write wikitext, and those should be what we have.
• Buttons, tabs, or other controls should be visible, i.e. you shouldn't have to mouseover random elements to see if you're allowed to edit them. The controls are a major, important part of the content; it is always an encyclopedia that people can edit. Wnt (talk) 21:35, 18 February 2014 (UTC)
• Threading is a good thing. You shouldn't have to shout out which editor you're responding to with each post, then have others try to figure out which of his posts you're responding to. The endless indentations of current ad hoc wikitext are a bit out of control, sure, because there's no option presently in the software to collapse indents to an even heading when each is followed by another with nothing else on the same level. But there could be. And it is better to have out of control indents than only one level. Wnt (talk) 21:40, 18 February 2014 (UTC)
  • Raw Wikitext. This is going to be added, but on a per-post basis. bugzilla:60465
  • Luability. I'll ask the dev working on the API to comment on this (probably at the main talkpage).
  • History. I'll check if this is possible.
  • Diffs. They are there, just not easily accessible at the moment. E.g. the pencil icon here leads to a diff of the edit. (The icon is being changed though. See mockups of the next iteration). Also, the elements in the watchlist/RC/Contribs/History pages are being worked on at the moment, and will be vastly more informative once that is complete. See notes on the next iteration's layout.
  • Table of contents. The infinite scroll makes this one difficult. The current proposal is to use the 3 "View" icons, at the top-right of each Board, eg Wikipedia talk:Flow/Developer test page. Collapsing the view provides a makeshift ToC. There's a planned feature to enable "sorting" of topics, so that most recent activity is at the top, for example. Similarly, a feature to enable highlighting of "new posts since last visit". These and other options could be combined to potentially "uncollapse only topics which have new activity", and similar setups.
  • Defined archives. Permalinks are really permanent. A link to a topic will always go there, no matter whether it's moved to a different page, or "archived" through inactivity/age, or if someone changes the topic/thread title.
    Making it work as smoothly as possible with dozens of topics loaded (per highly active noticeboards such as ANI and the VPs), is definitely the target. bugzilla:57908. This is known problem area at the moment.
  • SAME wikitext rules. I tried to reproduce this error, but cannot (I tried in firefox, and in chrome-without-js). What browser/OS, and what string were you trying to save that resulted in the error? Thanks.
  • Buttons, tabs, or other controls. The UI itself is being regularly iterated upon, based on our specific feedback/suggestions, and as new features are added. You also touch upon the topic of editing other people's comments, for which I'll link to the FAQ.
  • Threading. The maximum indent level in Flow is due to be increased soon (initially just by one more level). I personally agree that this is a very drastic and perhaps even disconcerting change, but the arguments presented for it are interesting and worth investigating a little, at least. As the main FAQ says, this and other aspects are definitely experimental, and will change based on whether or not they work in-practice.

  HTH. Quiddity (WMF) (talk) 06:23, 19 February 2014 (UTC)

  As I've posted elsewhere, "post since last visit" is nearly useless, and "highlight posts" is the worst possible way to do it. Collapse/uncollapse is too coarse-grained to allow editors to find out what has changed exactly in a period of time, and only that, like the current diff allows us to do. Losing that would be the hugest drawback in functionality so far.

  As for the TOC thing, Maryiana keeps telling us that no design decision is final, but infinite scrolling seems to be an irrevocable choice despite its numerous drawbacks and it not being a metaphor suited for the kind of content it hosts, and there's no sign that you are planning how to introduce the benefits of pagination. Diego (talk) 07:44, 19 February 2014 (UTC)

• This was actually quite a good reply to my complaints above. I am definitely relieved to see the diff above, though I don't understand why I only see the one pencil icon. I don't care what the icon is, but it needs to be a lot clearer what it does. The ability to edit and view history really is an integral part of our content; for example, when reading an article, looking at the history for vandalism or unexplained removals is a major part of its credibility, and the same is often true of talk page discussion.
• I think it would be worth trying to invent some other way to indicate deep threading than indentation. Indentation has worked very well from the earliest days of the internet, but can we do it with some sort of arrows or color coding?
• As for editing others' comments, we see two clear priorities: first, existing policy is that it shouldn't be done lightly, but second ... there are lots of reasons to do it. I think it's much better to provide due notice that these edits are happening than to prevent them from happening. In the end, versatility has to be the top priority, and that includes allowing untoward behavior. We have always balanced versatility against extensive logging. Wnt (talk) 04:11, 20 February 2014 (UTC)

Basically, I feel like the Flow design you have has thrown out good well-tested rules of Wikipedia design for very little benefit. With a robust, flexible system like Wikitext, you can produce mobile versions easily enough if that's what you want; you can auto-sign posts (there's no reason the bot couldn't be faster, and definitely none why it can't be less obtrusive by simply adding the missing signature without comment); you can greatly reduce edit conflicts with some very limited improvements to coding to automatically merge versions and resubmit where the intent is clear; you can automatically tag posts where editors change someone else's comments. You don't need this. What you're proposing is a whole new site, basically, one which is much less versatile. It puts you guys in charge of everything, exactly how our postings appear and interact, probably will make it a lot easier for you to conceal specific conversations like they never even happened, so I can see its appeal, but I'm just saying ... no way. This needs such major fixing that the best way to proceed may be to scrap the project and have someone else start over from scratch. Wnt (talk) 21:28, 18 February 2014 (UTC)

• Thank you for the bulletpoint feedback further above. That's very useful and detailed information.
• I'd like to reply to the notion of anything being "conceal"[ed], by pointing out Flow makes any after-the-fact edits more noticeable, not less. Currently, we have to go diff-by-diff through a page's history, or rely on other people noticing, in order to know if content was changed in a discussion. I hope you might reconsider your comment about that. There's nothing to gain by impugning the motives of the developers specifically, or WMF in general, whichever you intended.
• Unrelatedly, I recently discovered this, which you might find interesting:

The Danish Village Pump uses as interesting transclusion hack, to get this string of 4 links, to appear at the bottom of each topic:

Redigér · Overvåg · Se kun underside · Historik

(Edit · Watchlist · See only subpage · History)

eg: https://da.wikipedia.org/wiki/Wikipedia:Landsbybr%C3%B8nden#Overv.C3.A6ldende_flertal

They have bilingual instructions for the workflow, at the bottom of the editing-textarea, "The Danish village pump has been changed to a more editable format. [...]"

This is the kind of thing that Flow will improve upon, if we help it along. Watchlisting single topics; Per-topic history; Per-topic transclusion to multiple locations; complex workflows made less arcane, without every single editor having to become familiar with complex templates, in order to do simple tasks.

Flow is in the very early stages still, with much to add, and much to re-examine over time. The team knows this, and hopes the community will (continue to) help advise them on what we, and all the other current and potential editors, need and dream of having. Not just bandaids on the existing system, but an all-singing all-dancing improvement.

[Addendum Edit: I see from your userpage that you're very familiar with code. You might find these pages interesting: mw:Flow/Workflow Description Module, mw:Requests for comment/Workflow, mw:Flow/Block Module, and more linked from here. That's part of the large but distant goal.]

(This is a very multi-dimensional thread, and reply! I've re-written parts of my reply a few times, and I hope it comes out somewhat clearly, and is taken as a whole. :) Quiddity (WMF) (talk) 06:23, 19 February 2014 (UTC)

I should apologize for giving the impression it was a conspiratorial move - that's not really what I meant, but it's just that as users of Wikipedia we expect to have a lot of power over how the text is processed, and moving toward any other model familiar to the developers can very easily be confining. I understand that tracking down edits on a larger page can be a pain, but it's possible, not even really all that difficult, because the edit summary usually tells which edits affected which topic, and you can simply hunt around in the history for when things changed, or resort to WP:WikiBlame as a power tool. So my feeling is that there's nothing wrong with how we handle the history, just with the tools that search it. I think we should have tighter integration of functions that have in the past been handled by an obscure external server, so that they are readily accessible and fully up to date (or at least purgeable) right here. I think there's a better choice far between having some ad hoc method with templates or Lua modules to work with subthreads and abandoning the standard concepts I listed above. Wnt (talk) 03:58, 20 February 2014 (UTC)

I haven't looked over the Danish carefully enough, but I'm assuming this is just a split of one page into threads by transcluding multiple subpages? Because that's something I'd think can be done with the most superficial alterations to regular Wikitext. We just need a way that when you edit the page as a whole, you can put in some syntax that changes what the "edit this section" link points to, i.e. to make it point at editing the subpage; and the page to edit should have some GET parameter like "&return=ParentPage" so that when you save your edit you get sent back to a display of the parent page again. (And needless to say, the parent page would need to be purged when the subpage is edited, something which seems to have become unreliable recently, but I digress) Instead of just == == and {{ }}, maybe {{==/Section==}} would create this other kind of strip marker for the section edit links. The 'new section' would need some other "&append=ParentPage" so that when you create a new subpage, it adds a transclusion of it to the end of the parent page, So I'm still not thinking like something this radical is needed. Wnt (talk) 04:26, 20 February 2014 (UTC)

I should note that, having said that, I wouldn't actually want to split most talk pages into sub-templates because of the problem of not being able to get a top down view of the entire conversation on the page via a single shared history. The only page I can think of where people do this is T:TDYK, because every DYK is its own little world. Even there, if you get some controversy about the process that is more general, the discussions quickly becomes fragmentary and unsatisfactory. For most pages with a lot of shared content by a group of regulars who view it often, they'll want to be able to view the history of the page to see where the "action" has been of late, or put it on their watch lists. The result is that even for pages that are split there are compromises like WP:Reference desk/Science that have used a hybrid system where threads are archived and included as templates once they are not watched much, and eventually the transclusions are removed.

However, for those willing to invest a lot of time and effort into a fundamental redesign, this doesn't have to be an absolute barrier. The key issue is page history, and what could be done with it. We have to keep the history we have now, but we could add new options:

• Truly historical versions. Presently the history version of a page is transcluded with modern templates. At times these can look very strange. It also can be transcluded with modern versions of images, which may differ from the old ones. The most extreme case of this was a bitter Wikipedia dispute in which an editor was blocked and then right afterward one of the images from his userpage was altered to show an old historical photo of a naked child, so that people looking at Web Archive versions of his user page from two years before thought this was how his page was meant to look all that time. Regardless: it would be useful to have a better history version available that expands every template, every file with the historical versions that existed at the time being looked at. For our immediate purposes, this would mean you could split a page into topics or templates but still see what the discussion looked like as a whole at some point in history.
• Comprehensive history. The flip side of the above is that there should be a way to go through all the revisions of every one of the things included in a page and dump them all into a comprehensive history of "anything affecting this page" (essentially, everything which ought to cause a reparse, if we were keeping up...). So you would get a chronological list of tweaks to utility templates and modules, edits in particular topics, edits in the main page, etc., all in a list sortable by date (and preferably also by page at which the edit took place)
• The cherry on top is when any change to the comprehensive history, optionally passed through a user-controllable filter e.g. only the immediate subpages, can trigger a watchlist.

If that is too fundamental, the other option I can picture is integrating the functions currently handled by the Refdesk bot into the page itself - a tab an editor can use to archive a subheading to a subpage or vice versa, a magic word to do this automatically, and so forth. This seems ugly in my imagination... Wnt (talk) 13:25, 20 February 2014 (UTC)

I agree, these history-related improvements would be great. Of course not just on talk pages / Flow boards. The lack of truly historical versions and comprehensive history (as labeled and described by Wnt above) is the #1 reason why many people on WP:fr are not at all ready to accept WikiData info be transcluded into WP articles. If only the WMF could work on such content-related matters instead of focusing so much on the layout (in Flow, Typography refresh, Winter and Athena).

I see great potential in some ideas brought by Flow such as workflows, multi-board topics, trans-wiki boards, topics sorting and filtering, topic and comment permalinks... It's a real pity that the current implementation lacks almost all of them in addition to a bunch of good functionality available in the current system. Flow should have been started with exactly those valuable new functionality brought forward instead of whatever layout changes gathering most of our attention (and anger) right now. After all, font size, colors, text width and table of contents (availability, indentation, numbering...) are mostly non-issues : these should be settings, easily configurable per wiki and per user instead of forced upon users at the underlying software layer. Klipe (talk) 09:05, 21 February 2014 (UTC)

Quick note of apology, that I haven't replied here yet. Each time I re-read it, I end up going off on a tangentially inspired task. I'll be back, when I can form a coherent reply. :) Quiddity (WMF) (talk) 01:25, 6 March 2014 (UTC)

Bunkum: easy to read grey text

Your argument that it's easier to read #333 text than black text is not supported by the first two citations given -- in fact the Lighthouse citation says "Text should be printed with the highest possible contrast. There is good evidence that for many readers who are older or partially sighted, light (white or light yellow) letters on a dark (black) background are more readable than dark letters on a light background. However, the traditional dark on light may be aesthetically preferable." Highest possible contrast means black, not #333. Where does the #333 come from? From one of the hardest-to-read blogs on the Internet! ( http://ia.net/blog/100e2r/ ) The text here is so close to what's written there that there may be close-paraphrasing concerns... provided the same person didn't write them both, that is. Just scrap this pseudo science - stop trying to impress us with how you know that everything we've ever done on the Internet is all wrong. Wnt (talk) 21:50, 18 February 2014 (UTC)

Topic/post and other "contributions" issues

I don't believe anything in the history/watchlist/contributions has been really given any thoughts before being developed and implemented, looking at the available evidence. It is utterly and completely useless. Take e.g. a "contributions list:

In my contributions, I get entries like

• 07:32, 19 February 2014 (topic | post) . . (+12)‎ . . Fram (talk | contribs | block) created the topic Board header.

Sadly, both the "topic" and "post" after the timestamp give the exact same result. The URL they generate is different, but they go to the same page, same location (top), ... which is rather logical as well, since the post is always the first in the topic. Anything I'm missing here?

Of course, on those edits where the double link could be useful, it is missing;

• 09:15, 17 February 2014 (topic) . . (+267)‎ . . Fram (talk | contribs | block) added a comment.

But it is there when you edit a post:

• 09:26, 13 February 2014 (topic | post) . . (0)‎ . . Fram (talk | contribs | block) edited a comment.

But then using "post" doesn't indicate which comment was actually edited, again making the "post" link useless. The timestamp is clckable, but doesn't give a diff or the version as it was at that time, but the current result only. The same effect comes from clicking "a comment". This is not a useful history entry, where you don't know where the change was made until you follow the link, and you don't know what the change was at all.

I also have

• 07:33, 19 February 2014 . . (+92)‎ . . Fram (talk | contribs | block) edited the board header.

Apart from my username (talk, contribs, ...), nothing in this entry is clickable or points to what I did. So, like I said, utterly and completely useless.

There are numerous posts in the Flow test page highlighting other missing, poorly working or badly designed issues with the whole "history" and traceability. Please rethink and redesign this thoroughly. Fram (talk) 09:15, 19 February 2014 (UTC)

+5 to this. This is likely an artifact from the implementation of Flow. They are relying on the history functions from Mediawiki. But as they have completely changed the structure of a Flow stream with respect to how a Mediawiki page works, the messages and links provided by the old system are useless. They will need to rewrite the whole history notification to make it achieve the usefulness of the old system. I hope they're taking notes :-) (do developers and designers read this forum and the other two, or is everything compiled and filtered by Quiddity and Okeyes)? Diego (talk) 17:36, 19 February 2014 (UTC)

The first batch of tweaks to the RC/Watchlist/Contribs feeds, are now live/visible on mediawikiwiki, with more to come as code gets completed. So, topic titles are included in each entry, and some of the links now aim at better targets. (This is the part that I'm really looking forward to getting to try out. Tweaks will undoubtedly be necessary, but it's a very interesting possibility). Thanks to both of you, for this additional nudge.

As for who is reading what: There are way more than 3 pages filled with feedback! People use everything from the sandboxes, to my usertalkpage, to give feedback. I read everything (and try to reply when helpful, but not too much or too soon - partially because I don't want to overwhelm discussions with my presence; partially because even I have trouble keeping up with some of the large activity/feedback bursts); Maryana reads everything but at erratic times; Okeyes is in the process of transferring to the Analytics dept. but still keeps an eye on things; the devs and designers read the pages regularly but not comprehensively because they're busy coding and working on other aspects or projects. Everyone on the team reads specific threads, that various of us bring up on the team's mailing list, or in bugzilla tickets or the 2 trello boards. TL;DR: Yes, copious notes. So many notes! HTH. Quiddity (WMF) (talk) 23:55, 28 February 2014 (UTC)

Erratic is right! :) It would help me, personally, and probably others on the team to have fewer pages/wikis to check – how about we merge design FAQ talk & general feature discussion talk and move to mw.org? Maryana (WMF) (talk) 18:25, 12 March 2014 (UTC)

I wonder if any of you had a chance to build an opinion on this (probably archived in a few hours from now). Remember that effective feedback must go both ways ;-)

Re: merging this talk with WT:Flow: good idea! The distinction is not so easy to define anyway.

Re: moving all discussion to mw.org: not so sure. How many people who are contributing to the discussion are usually only checking enwiki? And how many only mw.org? That is, where should we move to create the least need for additional crosswiki-checking?

I'm looking forward to Flow being matured enough to host this discussion and feed watchlists at both wikis... — HHHIPPO 19:48, 12 March 2014 (UTC)

More thoughts on infinite scrolling

A few additional thoughts about infinite scrolling (a design decision that seems based on emotion rather than a rational analysis of benefits - or drawbacks!):

• It can be made to work, just not in its current form.
• As the stream advances, the URL should change to point to the current topic - so that navigating away from the page doesn't loose your relative position.
• Infinite scrolling and pagination are not incompatible, you can do them at the same time to reap the benefits of both. You can have separate chunks of content (call them "articles", "pages", "topics", or "weeks") and put one section below the other, without end.
• Infinite scrolling is only as good as your ordering criteria. The biggest drawback of IS is that it doesn't allow random access, so if the user knows better than you where in the stream is the content they'r looking for, they're stuck - they cannot go from here to there quickly. That's what pages and tables of content are good for - giving users choice. Getting rid of them takes away power from the hands of readers, unnecessary when it should be simple to provide both.

I could see an infinite scrolling page having a table of contents, either a paginated one (like Liquid Threads did) or an TOC with infinite horizontal scrolling like the one in archive.org time machine. Diego (talk) 07:34, 28 February 2014 (UTC)

Interesting thoughts. I added the idea of URL updating to my suggestion for an even more versatile system for navigating Flow boards. — HHHIPPO 14:11, 1 March 2014 (UTC)

@Diego Moya: Re: Other infinite scroll ideas: I've always liked the http://ffffound.com/ version: If you place your mousecursor over the "next" link in the top-right, and then use the scrollwheel, it A) jumps from post to post, and B) for the last post on a page, it loads the next page.

Re: a ToC: there's a rough mockup of one new idea they're looking at, here: http://area51.yar.gs/wmf/flow1/

Re: Pagination: There already have a paginated view as part of Flow - it's what the non-js users get, eg this is page2 (the second batch of 10 topics). Definitely needs more research and experimentation.

Re: Those links: Those are good reads; thanks for the pointers. Quiddity (WMF) (talk) 23:52, 5 March 2014 (UTC)

Diego (talk) 11:34, 6 March 2014 (UTC)

• @User:Quiddity - Re ToC mockup: I very much like the design - it reminds me of link bars at blogs, which has worked great for years. Unfortunately the floating divs don't work well on mobile, they have a problem that's way too common in modern web design with floats: either they overlap the main content when zooming, making it unreadable (Dolphin browser), or they don't show at all (mobile Firefox and Chrome). Is it too hard to make the ToC fixed? Scrolling to the top to reach the index may not be as convenient, but it works.
• Re pagination: Great! Can we have those "More recent topics" and "Older topics" always visible, even when Javascript is activated? It would solve the problem of missing context when following permalinks.
• Re ffffound.com: I like that behavior, it's really efficiente - but it's utterly non-discoverable. How did you find about it in the first place? Some visual cue when hovering the links would make it a great design for power users.
• Re: the nesting level of this reply: yes, I'm emulating the post layout of Flow here at the talk page (double space, sign upfront), which breaks current conventions. I'm trying it as an experiment of how multi-level nested comments would work with this layout. I think we could try it at this active page before building a prototype for arbitrary nested levels at Flow. Want to follow up with it?

Hhhippo (talk · contribs)

Diego Moya: Re: mockup: I'd say this is a step in the right direction, definitely much better than the Flow boards live here. And good to see what's possible and that a ToC is being worked on at all. But as you know I'm looking for more.

Re: context with permalinks: the current permalinks point at the topic, not at the board, so the context might not be well-defined since a topic might be attached to one, several or no boards. The feature could work for topics attached to exactly one board though (probably a vast majority), and for those attached to several boards it could be just one click away, the user could select the context from the list of subscribing boards.

Re: ffffound.com: sounds interesting, but I'm not going to buy a mouse just to try it.

Re: Flow emulation: couldn't resist trying that. There's a lot to be said about nesting and signing, but I'm too tired now.

Reply · Posted 18:44, 6 March 2014 (UTC)

Quiddity (WMF) (talk)

@Diego Moya and Hhhippo: Re: Pagination and context with permalinks: See comment 2 and 3 at bugzilla:58251 for the latest suggestion.

Re: ffffound.com: I think I found that functionality by accident. I know there's a plan to add keyboard shortcuts to Flow, but I'm not sure how that functionality will be called out - I'll point the front-end designer at ffffound, to see if it inspires anything.

Re: ToC mockup: I'll point the dev to your comments about floating div problems. In firefox, the design adapts to different screen sizes, so if you shrink the window down to <980px it adapts the font-sizes a bit, and at <700px it adapts even more to remove the floating ToC completely. Possibly he can comment more, and any of the problems are possibly due to the mockup-nature of that page. HTH.

Reply · Posted 23:24, 11 March 2014 (UTC)

Maryana (WMF) (talk)

Wheee, this is fun :)

@Diego Moya: Re: ToC on mobile, we're thinking about moving to something a bit more like the fixed header in Winter so that the affordance to access the ToC persists as you scroll, but it doesn't appear until you click/tap on it.

Reply · Posted 18:06, 12 March 2014 (UTC)

Hhhippo (talk · contribs)

@Maryana (WMF): Yes, it's fun, but it doesn't generate notifications since we don't sign properly. Plus, this thread is not complicated enough to really learn much about nesting requirements. Maybe we should let the experiment run out. We can always find some existing threads as examples for thinking about the best way to display them. — HHHIPPO 19:48, 12 March 2014 (UTC)

Some references on web design and dyslexia

• this - "we found no guidelines about gray scales and readability for dyslexics apart from the suggestion of using a light gray as background [39]. Most of our participants said that grey actually did not help them. For the font (using pure white in the background) 16 users (72.73%) preferred a pure black font instead of the three options of gray scale for the font."
• this - "What visual dyslexic readers need to do is to configure the computer environment so that they can see comfortably what is on the screen".
• "Avoid pure white as the background color, because the white can obfuscate the text for people with dyslexia. A close alternative is the light gray with the following hexadecimal code #FFFFE5. A significant fraction of people with dyslexia is sensitive to the brightness of white background (i.e., scotopic sensitivity) and the text can appear as if it was moving or blurred. Instead of white background use pastel colors in background. For example, dark blue on beige background."[12], and "The website should be easily customizable by users. Provide features so that users can configure color scheme (background color, text color, and printing colors), font type, and text size. These may improve reading speed. In addition, people have different abilities and different preferences regarding colors, types, and sizes".

Diego (talk) 07:34, 4 March 2014 (UTC)

Flow and avatars

the pictures near the text are avatars. Is there a better illustration than this?

An avatar is a picture next to text which identifies the person communicating. If anyone knows other names used to describe this concept then please share so that all previous discussion can be tracked. Blue Rasberry (talk) 14:50, 4 March 2014 (UTC)

Links to other discussions

If anyone has links to previous discussions about Flow and avatars, then please share here.

• Wikipedia_talk:Flow/Design_FAQ#Flow_and_whitespace_in_practice
• Wikipedia_talk:Flow/Archive_7#Avatars
• Wikipedia_talk:Flow/Archive_8#Custom_signature
• Wikipedia_talk:Flow/Archive_2#Haven.27t_read_the_details_of_this_program_so_apologies.2C_this_is_high_level
• Wikipedia_talk:Flow/Archive_1#.22Board.22_versus_.22Talk.22
• Wikipedia_talk:Flow/Interactive_prototype#Anonymous_users_with_only_IP_addresses_will_get_confusing

Blue Rasberry (talk) 14:50, 4 March 2014 (UTC)

Precedent for avatars

All major communication platforms use avatars to identify speakers in communication, including Twitter, Google, Facebook, most forums, and many other things. The practice of using avatars has been standard since the early 1990s and as a design choice it is unsurprising, to be expected, and orthodox to include avatars, and it would be the opposite of those things to not include avatars.

Does anyone disagree with any of the above? Blue Rasberry (talk) 14:50, 4 March 2014 (UTC)

I disagree with some of it! It's a topic that is very divisive, and has large repercussions.

The best compendium of problems that avatars have (afaik), is at mw:User:Isarra/Avatars, but there's probably more details to add. I won't say anymore, in the hopes that you (all) read and add to that list. (Note: this comment is from my volunteer account) –Quiddity (talk) 01:19, 6 March 2014 (UTC)

Is Flow expected to incorporate avatars?

Is Flow planning to incorporate avatars? How prioritized is this? I appreciate that Flow is using signature customizations but I still have trouble tracking who is saying what in this system, and it occurred to me that I was expecting to see avatars as I have seen in other similar systems. Blue Rasberry (talk) 14:50, 4 March 2014 (UTC)

Flow is Not currently planning anything involving avatars. If they ever become a thing, it will be introduced via a different project. Quiddity (WMF) (talk) 00:30, 6 March 2014 (UTC)

Topic sorting and the Gini coefficient of forums

I have become convinced that the "Gini coefficient" of a web forum is one of its most important attributes, yet is has been largely ignored. I think Wikipedia has a distinctively low value and that proposed changes in Flow would alter that to our detriment.

By comparison with the economic index, I would define the Gini coefficient of a forum by taking the number of times each post has been viewed, or as a surrogate answered, in the place of "income" for the economic model. A mailing list that all readers go through comprehensively thus has a coefficient of 0 (complete equality) whereas a list from which a moderator selects a top entry and discards the others would have coefficient 1 (complete inequality). Examples of low-Gini forums would be Usenet, perhaps IRC, and standard last posting sorted web boards when traffic is low. High-Gini forums are last-posting sorted forums with high traffic (4chan), Twitter, Reddit, and many of the political petition sites.

A low Gini has a consequence we know all too well reading this forum: trolls, loonies, and people just saying hello tend to have a high visibility. On the other hand, people are thrilled that yes, they can be heard here. A low Gini tends to encourage dull policy discussions, while a high Gini promotes cool news and memes. A low Gini encourages every tom dick and harry to speak up, while a high Gini favors those with hard-won networks of backers and followers to retweet their postings and promote them throughout social media. A low Gini is Web 1.0, and a high Gini is Web 2.0, otherwise known as a Web You Probably Don't Have Much Of A Say In Any More. My feeling is that the "middle class" of the web, the people who had little personal sites each with a page of links to other fun little sites that you could follow all day and night, has been adversely affected in favor of a PR astroturf of pages made with ambition and artifice.

To make a direct comparison, consider how science questions are handled on http://www.reddit.com/r/askscience/ versus on WP:RD/S. When you simply look at the Reddit index, it looks great - lots of people getting answer after answer to even the most technical questions. However, if you ask a question on Reddit, it may well sit there with one thumb-up, zero comments until you forget it existed. While RD/S is not perfect, we try to field a pretty high percentage.

With the WP:Flow/Design FAQ it appears that topic sorted discussions will be common, and perhaps predominate. This will mean that threads that don't get answers start dropping out of visibility while those which are answered will be first viewed. I think this will increase the Gini coefficient here. Also, unfortunately, for us the most contentious topics seem to be the most discussed, which could mean that our "winners" look anything but deserving of the honor.

I would like to see Wikipedia begin to assess Gini coefficients as a metric of the site, and make it a priority to preserve a large fraction of the discussions here with a more egalitarian structure. Wnt (talk) 19:52, 6 May 2014 (UTC)

That's a great comment/point/suggestion, I'm not sure how we'd assess/measure such a thing though? (ping @ Oliver in Research dept. :)

I particularly liked the analogy, because I've been looking at the /r/askscience pages a lot over the last few months, and wondering "can, and do we want, to ever scale WP:RD/S to that size?" - I've been paying attention to the top and hot listings too much though, and forgetting to investigate the new stream...

(Tangentially, I've been thinking that we could try writing up "[topic] guide to Wikipedia" posts at reddit, for potential inclusion in each sub's sidebar. Eg. "Horology on Wikipedia" for /r/WatchHorology/, and a guide to WikiProject Science for /r/askscience, etc. Something to encourage those who are interested, to try editing here... I should throw that at VPI...)

Regarding the concern about topic-sorting - the plan is to implement options for topic-order. The best outline of brainstorm possibilities was put together by Hhhippo at User:Hhhippo/Flow. The plan is to have various possibilities for re-organizing them, and filtering them, by any meta-data - eg. perhaps something like "show only topics without a reply", or "show unsummarized topics", etc. The basic first-option of "show by order of last activity" is getting closer to release-readiness, and that will bring the necessary backend for further additions. More suggestions would be appreciated! HTH. Quiddity (WMF) (talk) 21:44, 9 May 2014 (UTC)

Images and Flow

How are images placed in Flow? That is position, size, margins and more of images (and tables) that I want to add. I understand the measure & whitespace design concepts, even trying to use them. However, once the column and header is setup by this, there still is no design concept on how space (lines, page, screen) should be shared with images. I am getting the impression that the image will be added late in the process, thereby making it secondary to inline text. -DePiep (talk) 11:45, 9 September 2014 (UTC)

Images should work normally, in Flow. See this test post. Quiddity (WMF) (talk) 23:05, 18 September 2014 (UTC)

To me, Images should work normally sounds like "sure, they will show". But Flow changes the whole page layout (whitespace & columns & indents), so my question is: exactly how are the images treated under these new flow/whitespace rules? Your demo link illustrates the same: an image in a (not-indented!) textual response. After all, these rules are set up for simple inline text only (then managing indents & bullets &tc). In short: I have yet to read a designers approach on images-in-inline-text. -DePiep (talk) 16:35, 21 September 2014 (UTC)

Any tagging (classifying topics) considered?

Has it been considered to add tags to a topic? For example, the topic header in a Village Pump is Login problems. For later search & research that topic could be tagged like "login; IE; new user". It is how we are supposed to search the /archive subpages today.

I assume the freedom of topic title (header) is a good user experience. On the other hand, a classification could be helpful. For example, in returning topics, or topical analysis (wiki-wide). A drawback is that it requires some 2nd-editor maintenance, we don't want the 1st posting editor (topic opener) to be obliged to fill this in. A look at wiki's bugzilla shows that it takes very experienced editors to get classification right.

One more example. en:Template:Convert can convert hundreds of measurement units into another one (km into mile). Invariably, on its talkpage topics pop up headed: "A question" (good), that is about "Swedish foot" (good). Tagging it "Swedish foot" helps finding earlier answers (in the future, even a "See: ..." automated - why not). -DePiep (talk) 19:16, 9 September 2014 (UTC)

@DePiep: Yes! I just added the top link at mw:Flow/Prior discussion-thread-roundup#Tags, to a recent mailing list post, that discusses the idea of tags quite a lot in section #3. (And older threads discussing the idea, are linked there too). It will be a while before any deep research/development starts on that idea, but we're planning on setting up some better systems for coordinating the discussion and note-taking, for these long-running and/or future features components. Quiddity (WMF) (talk) 22:40, 18 September 2014 (UTC)

Thanks, good link. Thread closed & topic Redirected. -DePiep (talk) 16:12, 21 September 2014 (UTC)

Wait, wait. So now mobile is gonna dictate the desktop screen?

About, for example, this issue: whitespace and screenwidth.

I understand the design issue of whitespace, measure, column, and its following page design (I even like it, since I can grasp the designer's' arguments). Also, I get that mobile devices require a different page layout (actually, "small-screen" device, right?). But hey, wasn't modern HTML & CSS & all that intended to support all? Is the wikipage gonna be tailored to the 25% mobile users (or 51%, or 75%)? That does not fit the intention.

I fear (i.e., distrust the future) that the wiki base page article, or other, will get limitations to serve it's mobile version. Useless vertical margins that serve no purpose -- on a desktop/laptop wide screen. Those wide screens will get those margins where, in other webpages, you see the advertisements background repeated, but turned whitespace in wiki for the wrong reason. For the purpose only: "but in mobile view this looks good". Because: on a wider / landscape screen those column/measure rules do no apply this way.

I think a true HTML-CSS-&all design then needs could be a two-column wikipage for certain screens. Also, a fullscreen (width) image is the common thing. -DePiep (talk) 20:24, 9 September 2014 (UTC)

With my volunteer hat only: I made a proposal at mw:Talk:Requests for comment/Redesign user preferences#The Appearance menu that you might find interesting. Quiddity (talk) 23:22, 18 September 2014 (UTC)

Thanks for the link. But really, it is still about the text (font-size &tc). I'm sure that will be improved by all this. But now about how my table will look in a Flow topic. A table, where the reader's eye sees different. For example, the eye recognizes patterns from a mile distance (numbers, similarities). -DePiep (talk) 16:58, 21 September 2014 (UTC)

@DePiep: There's already some responsive design in Flow (try reducing the size of your browser window - the font size gets reduced, at window widths under ~795px).

There will probably be some further changes coming, to the default width in Flow. I'm advocating "options" wherever possible (I love options - though I understand the complexity they add to both the development teams' lives, and the users' interfaces, make adding any kind of in-page or in-preference options a difficult decision).

Regarding the whitespace side-area: There have been a few ideas regarding putting supplementary info there; things like topic-metadata, support and tips for newcomers, checklists, etc. What do you think would enrich your participation in a Flow board?

Beyond Flow, you may be interested in this presentation from Wikimania, which touches on things like mw:Winter and other experiments the design team is working with.

HTH Quiddity (WMF) (talk) 23:50, 18 September 2014 (UTC)

ok, I should be Flow specific here (let me note that I have not read any grand wm designer about this my issue). First question: what "options"? What's wrong with "defaults"? We sure both remember old time when you had to even install preferences? (and fonts today). Also, can these "options" differ between my mobile and my desktop? (in other words, must I maintain two sets of options, m and desktop, then?). Something is wrong with this idea, but I can't point it. It has to do with "it should work when I start it". I might get killed for this (the good cause): e.g., women in general don't like technical menus. Nor do our Readers. It must work alright in the first place. -DePiep (talk) 17:12, 21 September 2014 (UTC)

Page design: Seeing and reading text vs. Image

My question is about images & tables in page setup. Flow issues and also higher-up (wiki page layout design) so far are based on inline text: how the Reader reads and perceives text. This seeing and reading text is a very subtle process, and bright rules are established (font, measure, font-size, line-height). That is Great: the pleasure of reading.

Now in the mw wiki developments, the images (including tables) are a leftover, added afterwards to the already perfect text-&-font-&-whitespace page design (measure rule met!, suits mobile screens!).

In this, the mw page design returns to 1975 lead pages. That's when, in lead-written newspapers, they wrote a page in columns first, and had to squeeze photos into that same column pattern. But at least, they made a design for it. -DePiep (talk) 17:41, 21 September 2014 (UTC)

Page design: Text vs. Image, illustration

My point of resistance is from this: the Periodic table (PT), especially template {{Periodic table}}. It demonstrates that whitespace-and-measure is not always a good guideline.

The template {{Periodic table}} has 18+ columns by structure. Years ago, at wp we only did show "Au" for element 79. I and others took great effort to add the word "Gold" to that element. (The article has 5 hits per minute, even when I sleep. I state that many of those Readers are helped seeing the word, more than its symbol). Given the 18-column width (and so 18 names in a row to mention), that requires each & every pixel in width we can get.

From this, I quest no spilling of pixels. -DePiep (talk) 17:57, 21 September 2014 (UTC)

Edit summary

Does the edit summary stay? How is it in the flow concept? (Where I can add sneaky snarky comments - not that I do so, but I'm asking for a friend). -DePiep (talk) 23:01, 9 September 2014 (UTC)

At some point, this'll need to be examined again. mw:Flow/Prior_discussion-thread-roundup#Edit_summaries lists a few of the older discussions, that "Archive 7" discussion being the longest (but a few of the more recent ones still need to be added). They briefly experimented with using an excerpt of the first 100 characters - I thought that was quite good myself, but it's been removed for the moment. Quiddity (WMF) (talk) 22:55, 18 September 2014 (UTC)

Thanks. The link is enough (consider this topic Redirected). (tried a sort of pun). -DePiep (talk) 16:02, 21 September 2014 (UTC)

Observations

I kind-of like the idea of Flow but when i tried it I made these observations:

1. In a test page, I posted the template {{GOCEstartce}}; this was substituted and transcluded by the software, thus the template appears twice;
2. In the template above, one of many which use the {{PAGENAME}} magic word, the page name appears correctly in the preview window but as a randomised, letter-number sequence when changes are saved;
3. The edit window is far too small, and it grows as more text is added. that's really annoying; please make it stand still!
4. When editing a previously-posted comment, the edit windows shows unnecessary HTML code. The editor is supposed to be intuitive.
5. I don't like that the sig appears above the post rather than next to it; it's too "forum-like". And where's the timestamp?

Feel free to move this section if I've posted in the wrong place. Cheers, Baffle gab1978 (talk) 06:55, 28 December 2014 (UTC)

@Baffle gab1978:

1. Hmm, it works ok the first time, but if we edit the post, then it does indeed get duplicated (with the initial transclusion followed by a substitution). Possibly this is related to the substcheck in the template? I shall investigate... [Edit: Interesting. This is related to the {{clear}} that is part of that template.]
2. Filed as phab:T75409
3. Noted, will pass along.
4. I think this is related to the subst problem in #1.
5. Re: username location, this was discussed at Wikipedia talk:Flow/Archive 2#Prototype has a very strong emphasis on author, not on message. The timestamp is at the bottom-right (in LTR languages). I believe they're considering moving some of the elements around.

Thanks for the details, HTH. --Quiddity (WMF) (talk) 21:46, 5 January 2015 (UTC)

Being used to the standard wikipedia environment, I have found that Flow not only takes getting used to in contrast to our standard, but also that Flow offers a different style of commenting which is multiple-machine compatible. I use multiple machines, each 'on / connected' all the time, in a different location, car, etc. I can read, edit, etc., and pick up where I leave off, on multiple sessions, simultaneously. Flow abets this by uploading our edits to the server without a 'Save page' event (I have to admit it feels strange). That said, Flow is not essential for a multi-machine style of operation. It is fairly clear that if multiple editors chose to all work on a common page, they could cooperate on that common page. Julius Caesar wrote his books that way (he used multiple scribes, speaking at normal speed; each scribe would transcribe one sentence; then the written sentences would be assembled/edited to be read as Caesar intended.). But that is not the current configuration for Flow. --Ancheta Wis   (talk | contribs) 01:39, 7 January 2015 (UTC)