If you press the "page down" key, all posts are marked read (red?), I'm
not sure that's what you want. I'm aware of at list one website[1] that
maintain two "post attribute" for each post, and let user navigate
previous/next element in this list through a dedicated navbox. The first
list is a chronological one, so one may click next to follow posts has
they were submited in time. The second one is a list of unred item,
where clicking next will lead you to the next element in the page that
you didn't read yet. This list is defined on a "since last download"
base, which mean that if you download the page for the first time, all
posts are marqued unread, but on your next download of the same page,
only news posts will be marked unread.
[1]
* 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
_______________________________________________
Design mailing list
Design(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design