I'm responding to everybody in this single mail, but first:

There is a new version at http://elohim.gaijin.com/flow/

This is what's changed:

* Posts are automatically marked read as you scroll through them. * Unread posts are significantly called out (green headers, experimental - this is fairly obnoxious but you are warned) * Topic titles are now hot * Rudimentary search functionality - Loading throbber - case insensitive - DOES NOT tokenize - searches titles, authornames, tags, postcontent * Clicking the gear icon now brings up a menu * Clicking the subscribe/unsubscribe stars now do things * Clicking the tag icon now opens a small dialog (that doesn't work yet); * Reply form auto-focuses to the textarea now.

On Apr 30, 2013, at 4:05 PM, Trevor Parscal tparscal@wikimedia.org wrote:

First off, it's really awesome to have mockups and prototypes being done in HTML/CSS/JavaScript. This prototype is really cool and fun to play with. I know there are bugs and whatnot, but you've done a great job putting this together and I look forward to seeing more prototyping like this in the future.

A couple of things jumped out at me while I used it, hopefully some of this stuff is useful and new feedback. • The affordance for expand and collapse (a chevron symbol pointing right or down) didn't look like a control to me. I think that using symbols as buttons without outlining them is a great way to make the design lightweight, but if you make the symbol too big it looks more like a decoration and less like a control.

I agree; I went with chevrons because they are used in mobile for section expansion and I thought that having a similar theme would be useful. The first ones I used were . . . "fatter". . . but they felt clunky and blocky so we've got this.

Right now, I've made the entire title "hot" as well so as to increase the affordance size. They should also probably have a hover state to indicate that something is going to happen.

I'm absolutely open for better ideas.

• I think it's a good idea to be conservative about how many buttons to show, and I'm doubtful that an icon will convey "expand" or "collapse" very well, but the combined expand/collapse all button gets users into limbo states and can be a little confusing. Since items can be manually expand and collapsed, users can end up in a state where everything is expanded yet the button says "expand all". GMail uses an intermediate state for their select all button to show that you are in a partial selection state. Other interfaces often have both buttons always available. My impression is actually that this is a symptom of a larger problem (see next point).

The "Collapse all" button is actually there for ease-of-use in the prototype. I'm not really thinking it should make it into the final product because, as you said, the concept of "all" doesn't make a lot of sense in the context of a lazy-loaded, infinitely scrolling discussion system.

On Apr 30, 2013, at 4:56 PM, Brion Vibber bvibber@wikimedia.org wrote:

A few more notes:

• the collapse/expand is only available at the top level, which can make it hard to really navigate through deeply nested long conversations -- especially if you were only interested in new content

So, this is what LiquidThreads does, and maybe we should revisit it. I worry, though, that having *too* many controls will be difficult to handle.

One possible solution to this (which I will prototype up) is to:

a) Automatically collapse read "branches" b) Only provide a control to *expand* those posts (and it would expand all posts in the branch (so you don't have to do the horrible Quora style "click to open each comment)

• the appears-on-hover "(board * contributions)" links are hard to discover and use on a touchscreen (for instance an iPad or other tablet that gets the desktop interface by default)

Jah. Erik asked that I provide minimal information and only do selective reveal, which isn't mobile-first but we're trying to illustrate concepts here rather than final functionality.

• I really want the entire thread title to be clickable as expand/collapse, not just the little arrow. Much easier on touch, but I also tried to click on the title portion with my mouse on my laptop. :)

Done.

• The input box should probably expand to fit longer input paragraphs, if possible (at least up to some reasonable size). Right now it's hard to edit a long response.

I'm doing some experiments with auto-sizing textareas but I'm not happy with anything I've gotten so far.

• Paging or infinite scroll need to be planned for for really long talk pages.

Infinite scroll is the Plan™.

I agree that the "find new items" case isn't really handled well at this stage; there seems to be no "read/unread" distinction and scrolling through an entire thread to look for new things is very labor-intensive, especially on touch.

See above comment about collapsing.

Right now, I'm using a very obnoxious green header for each unread post. I do not expect this to last, but you DEFINITELY know if it's read or not.

On Apr 30, 2013, at 5:06 PM, Erik Moeller erik@wikimedia.org wrote:

My understanding from talking to Brandon earlier is that unread parts of the thread have a green vertical border right now, like the comments in the first example thread in http://elohim.gaijin.com/flow/ , and the idea is to make that fade out as you scroll over them (not yet implemented).

This is now implemented, but I'm not sure of the "action" yet. I'm using a library called "waypoints" and it works but there are lots of variables we can tweak.

On Apr 30, 2013, at 10:02 PM, Maryana Pinchuk mpinchuk@wikimedia.org wrote:

On a more general note, I'm still not sure I grok the board/feed distinction – I was thinking that new stuff would appear in your feed, and all stuff you follow would appear in your board, but that doesn't look to be the case.

More like the opposite:

Feed: Stuff you follow Board: Stuff about you and your activity

This is also a big problem I have with the concept behind LiquidThreads – if I'm already following pages on my watchlist, which is kind of my de facto feed, I really don't want to visit a separate "new messages" page unless it actually shows me a roll-up of all new messages related to those pages (as opposed to basically the full threads of three-year-old discussions, with one or two new messages buried somewhere in the middle). I'm also not sure how the watchlist is going to interact with Flow, given that, in essence, it's serving many of the user needs that Flow is trying to solve for (albeit in a weird, suboptimal way) at the moment. Have you done any thinking about how to delineate these features more clearly?

Lastly, the feed/board distinction (if I'm understanding it correctly) seems much more useful for when all discussions (village pumps, articles, the glorious future when messaging goes cross-project...) are Flow-enabled, not just user talk. Then there's an obvious need for seeing the stuff I may be semi-passively following from various scattered discussions on one view, and having a separate view for really important stuff directed specifically at me. Having two different views for just user-to-user messaging, though, feels too heavy to me. Why not just one for now?

Actually, the feed solves for two very distinct use cases that are not addressed by the board:

1) Conversations occurring across multiple talk pages 2) Tracking conversations that you are involved in on other people's talk pages

While I had originally spent a lot of thought on the "single board, two viewpoints" solution, in the end having a board/feed model made more sense to me because:

1) User talk pages already *kind of* match the "board" model (and mapping contributions into it isn't that much of a leap) 2) Most people are used to the concept of "my stuff" versus "the stuff I'm following", even if there are many ways this is done: Facebook has a "Profile" and a "Feed" Twitter has a "Profile" and a "Stream" LiveJournal has a "Journal" and a "Friends Page" etc. 3) We can probably roll out easier. We give *all* users a Feed, but then users can selectively "upgrade" their talk pages to "Boards". This gives users flexibility as to when they move into the Bright Future.

On May 1, 2013, at 12:53 AM, Jon Robson jrobson@wikimedia.org wrote:

When clicking save the text under is very wordy. I wonder if this could be collapsed somehow

This is a requirement from legal. There's no real way around it.

pps. the be nice placeholder is a lovely touch. A subtle reminder of the community we want/ need to foster.

Kind-of-not-quite "accidental". :)

On May 1, 2013, at 4:01 AM, Mathieu Stumpf psychoslave@culture-libre.org wrote:

When you click reply, you should directly have the textfield focused. Also within the textfield pressing tab should let you switch to the save button, then the cancel button, with a highlight which let user know which element is focused.

I've got the textarea focusing but there's some goofiness I ran into with handling tabindex on the other elements. I'll see what I can do about it but at the end of the day this is only about half as powerful as it will be when it is truly backed by a server-side system.

Always reducing the box with a bigger left margin is not great for very deap threads. I have no perfect solution to give instead those said. Maybe having a "box-min-size" test that will change the comportement when reached, for example you may go back to a bigger box but with a right margin and using right box borders to let users follow the flow.

Right now, I'm not applying any logic to how deep the branches can go. I've got an exhaustive analysis of branch depths located at mw:Flow Portal someplace; I think the final layout is going to be "branch in for 4 levels, and then go 'flat'" but I wanted to get it out in an easy state first.

Applying this kind of functionality WILL have an effect on the conversation style and norms but I don't think that's a bad thing.

I think tags/subscribe/other icons should be more spaced.

This should be easy to do.

--- Brandon Harris, Senior Designer, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate