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(a)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(a)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(a)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(a)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(a)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(a)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