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
On Wed, May 1, 2013 at 12:56 AM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
> I agree that the "find new items" case isn't really handled well at this
> stage; there seems to be no "read/unread" distinction
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).
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
OSM has implemented a feedback tool for its map not unlike
ArticleFeedback (allowing for anonymous submission):
http://blog.openstreetmap.org/2013/04/29/openstreetmap-opens-up-to-more-con…
It's not as prominent which mitigates the noise somewhat, but I'm
seeing a few spammy notes already, as well. ;) To see notes you have
to have the "Browse Notes" checkbox ticked in the Layers icon (top
right corner), and to add notes you have to click the tiny "Add a
note" link in the bottom right.
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Per Howie's prompting (this was cool! You should send it out to the team)
some research I did in my spare time - http://blog.ironholds.org/?p=31
Planning to do a pile of followup work, so any feedback, hypotheses or
requests for info gratefully received.
--
Oliver Keyes
Community Liaison, Product Development
Wikimedia Foundation
I have thrown together an interactive prototype of Flow. It's fairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/
Nothing is saved to disk. You can reply to topics or even add new ones but on refresh everything reverts to state.
Right now, the "you" you are logged into is "Jorm" but I'll be adding functionality to handle that.
In the sidebar are a couple links to various "board examples":
* Fully Chaos (everything is generated randomly.)
* Jimmy Wales
* Maggie Dennis (Moonriddengirl)
* Me
* A single topic (this is what you get to if you get an echo notification)
Speaking of, if you click the echo badge, and then click on the unread notification, you'll get the experience of the user getting a reply and going to the single conversation view.
You can also click the "Feed" link and you'll be brought to your feed. The "feed" view is different from the "Board" view. The feed is private - it's all the conversations that you my be interested in or are subscribed to (have a solid star). You also see activity from the boards of *people* you're subscribed to as well, but it floats away fairly quickly if you don't subscribe to it.
Known bugs:
* The "New Topic" dialog doesn't close when you click the "X" button. No idea why; it worked the other day and now it doesn't.
* Some of the conversations are threaded weird. This is an artifact of the JSON.
* The tab highlights are a bit goofy.
Upcoming:
* The search functionality will work
* You'll be able to add and edit tags
* Stuff like archive/split/whatever
* Edit your own post, etc.
Please share your thoughts.
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Dragonfly6-7 (User:DragonflySixtyseven ) was on IRC trying to get a handle on how to modify skins, due to various flaws s/he has identified in Vector and Monobook. I pressed her/him to gather all the points into a single page, and voila: https://www.mediawiki.org/wiki/User:DragonflySixtyseven/Skin_fussiness
Some of the points seem legitimate to me, but I don't know the domain very well, so I figure I'd e-mail this out to invite some closer scrutiny and to poll for interest.
Hi folks!
I've mocked up the first 4 levels of The Wikipedia Adventure in an
interactive text program called Twine. You can get a pretty good feel for
the content, spirit, and tone of the game.
http://jatspan.org/twa2.html
I'd *love* to hear first impressions, suggestions, feedback about what
works or needs improvement, and any other thoughts you have. I think this
game could be a valuable tool for outreach and onboarding. Help make it
awesome!
Jake (Ocaasi)
Sumana Harihareswara, 22/04/2013 21:02:
> A few people were passing around a paper that "could be potentially very
> useful for EE. tl;dr: just look at figure 8." -Giovanni Luca Ciampaglia
>
> http://cs.stanford.edu/people/jure/pubs/language-www13.pdf
>
> Steven Walling wrote:
>
>> Fascinating. Someone should _definitely_ run a similar study of how it
>> takes editors to pick up markers of in-group Wikipedia jargon, if they
>> haven't already. A lexicon would be fairly easy to develop.
The point however is different: «A way to summarize this finding is to
say that users generally die “linguistically old” (i.e., at a stage when
they have relatively little reaction to linguistic change), no matter if
they contribute relatively few posts to the community, or if they are
heavy contributors».
This means that, by checking if they're getting linguistically old, we
could predict which users (old or new) are dangerously approaching their
wikilifecycle end. What to do with this information would be another
challenge, but it would be interesting to find some project where the
local coaching group would be interested in having such lists/data to
work on. Of course the Germans come to mind, but a smaller wiki may be
more viable to start with.
Nemo
>
> Tilman Bayer added:
>
>> See also this paper:
>> http://www.mpi-sws.org/~cristian/Echoes_of_power.html (reviewed
>> here:
>> https://meta.wikimedia.org/wiki/Research:Newsletter/2012/January#Admins_inf…
>> )
>
> Hope this is useful!
>