Wikipedia talk:Flow/Design FAQ: Difference between revisions

Content deleted Content added

Inline

Revision as of 09:05, 21 February 2014

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Table of Contents & sort order

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

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

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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...

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

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

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

Everything

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

"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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
- 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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

+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)[reply]

@@ Line 439: / Line 439: @@
 ::* 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... [[User:Wnt|Wnt]] ([[User talk: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 [[User:Wnt|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.  [[User:Klipe|Klipe]] ([[User talk:Klipe|talk]]) 09:05, 21 February 2014 (UTC)
 == Bunkum: easy to read grey text ==

Revision as of 09:05, 21 February 2014

What do you like about Flow's current design

Signature

Column width and line spacing

What would you change about Flow?

The default style needs _way_ too much space.

Line length/measure

Whitespace & padding

Table of Contents & sort order

Selecting which unloaded topics to load?

Text color

Paragraph reflowing

Nesting & thread depth

Mouseover behavior

Everything

Top posting? Are you kidding?

Flow and whitespace in practice

Infinite scrolling vs Table of Contents

Obligatory xkcd

My name attached to all the empty comments

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

How will the limited indenting/threading system help?

Tighter design

Design considerations I want to keep

Bunkum: easy to read grey text

Topic/post and other "contributions" issues