On Mon, Sep 8, 2014 at 12:22 AM, David Gerard <dger...@gmail.com> wrote: > On 8 September 2014 05:46, John Mark Vandenberg <jay...@gmail.com> wrote: > Those of us who presently use talk pages to get the work done. What is > going to make us *love* Flow, for all its imperfections, and demand to > have it for ourselves? What's Flow's killer feature for us?
First, on the subject of "kiler features", generally - we can make educated guesses, but with software that's used by communities, you really need to experiment and iterate. I'm sure we'll try stuff in Flow that doesn't make sense (and we've already talked here about aspects of the current design that may have to be changed, like the limited threading display), and I'm sure things we think are minor will become more popular than we expect. Generally, I'm not a big fan of maintaining illusions of certainty. I've argued against detailed year-long plans to Sue and the Board, as I'm sure they will attest, until we got the flexibility to set more malleable goals in engineering. Lila immediately came in with the expectation in mind that we'd have precision a quarter out, and broad high level ideas a year out, and need flexibility to change our mind as we learn. In tech work, you need to be able to double down on success when you hit it (make that killer feature _the_ feature), and kill the cruft that you thought was smart but that just doesn't work. With Echo, we included a bunch of notification types and didn't really know which ones people would love. We guessed that mentions would become popular, but their use has exceeded our wildest expectations. Go to any high traffic talk page and you'll see Echo pings all over the place. A feature that didn't exist before 2013 and that nobody, as far as I know, ever asked for (!) before we built it. And yet it's become indispensable. When we experimented with mobile contributions, our first hypothesis was that uploads would be a good start, because mobile isn't well-suited for long form edit contributions. In fact, mobile editing became wildly popular very quickly and has generally been embraced by the community (to the point where people ask us to enable IP editing on mobile, which we consciously did not do initially to lessen crappy edits), while the signal to noise ratio on uploads has been so poor that we're about to retire most upload features until we really can spend cycles on mitigating those risks. So, educated guesses and hypotheses. Flow makes lots of things possible that are otherwise hard/impossible (much better search, tracking of comments, etc.) but my hypothesis is that there are three primary killer features that Flow can provide: 1) Fast interactions. The process of responding on a talk page is ridiculously slow (edit section, find place, indent comment, write comment, sign comment, preview, save, worry about edit conflict ..). In my view, the reason people don't value this in Flow such-as-it-is already is primarily [[loss aversion]]. There's a large set of concerns that Flow makes existing things impossible (and yes, I'll respond a bit more to Diego) or harder. Losses are psychologically far more powerful than gains -- so any cool comment features that Flow _already has_ (fast and easy replies, no edit conflicts, etc) will not be perceived to be "killer features" unless/until the balance of perceived losses shrinks dramatically from what it is now. And it'll keep shrinking as we go. As pointed out, we can _try_ to make this work with sticks, spit and duct tape on top of wikitext, even in the odd cases of mixed markup for indentation, comments interrupted in the middle, outdent templates, etc. -- but it'll almost certainly just have to bail in some cases, and misidentify comment demarcations in others. I'd like to test those boundaries a bit more before making confident statements about how much of "fast interactions" we can deliver without Flow, however. Either way, it is IMO a clear killer feature that's badly needed. 2) Centralized conversation spaces. Flow's architecture is already cross-wiki; its UI is not. As pointed out, there are multiple cross-wiki discussions as well as mailing list discussions about this very topic. Wil suggested "Pick a conversation space and stick to it!". Well, wouldn't that be nice - if it worked in our universe. Except that we know it rarely does. People want to have discussions in their "home wiki", and we use mailing list threads like this for good reasons as well. You could participate in the same Flow conversation from en.wp, mediawiki.org and meta, without caring one way or another (SUL finalization being the main blocker to avoid account wonkiness). When/where that's desirable is something to negotiate -- but for example, feedback on features that are deployed across wikis is a perfect case for wanting to have local pages that feed into a single stream of comments. If you want to go nuts, you could build a Flow<->mailing list or Flow<->NNTP (oldschool!) gateway. If we do our API homework, I mean literally "you" because we're sure as hell not going to do it anytime soon ;-) Flow -theoretically- even could have language awareness of individual posts, enabling a single multilingual discussion space, easy translation of individual comments, etc. A team of Japanese researchers built something like this on top of LQT a few years ago, as a prototype: http://langrid.org/mwikidev/ (Guess why they didn't build it on old-school talk pages?) For a truly multilingual community, I think that could be a killer feature -- as opposed to just splitting the conversation spaces, as we do now. 3) Tags. The team hasn't decided if/how to implement tags yet. My own bet is that they could be a killer feature. Let people add/edit those right below the thread title with one click and see if they start using them. Say you want an article to be deleted. Start a thread with #afd tag, explain your rationale, you're done. Other users can pull up the recent #afd threads, sort by date, etc. Discussion can happen at the article level or from the tag page. Say you want to welcome new users. Leave a welcome note with #welcome tag. Other users can join in on the welcome and give tips/hints. Say you're a new user and you want to get help. Start a thread with #help tag and it'll show up on that board. Other users can provide help. (Yes, I know the {{helpme}} template which is sort of a very poor person's version of this.) Say you like a picture and you want to nominate it for FP status. Leave a note with #fpc and it'll get added to that feed. (Tags that are invoked from File talk: pages could dynamically include a thumb, so no need for extra logic to do that.) If people misuse tags, others will remove them. (And no, it doesn't have to be the hashtag syntax. It could work like categories, where tags could have pages describing them and their purpose -- I wouldn't recommend using actual categories, because the hierarchy is overkill.) You'd probably need a tiny bit more pixie dust for rich workflows, but I'm not quite sold on the idea of a workflow domain language or anything like that. I'd look for simple rules: Flow already has "closure" as a discussion property, so closed threads could be easily filtered. Setting a tag could generate a configurable notice on the subject page. Etc. Workflows built in wikitext are cool (I've built a few myself, and I only hate myself a little bit for it in the morning), but they're not the only way to build workflows. Tags, dynamic searches, pings, and similar mechanisms can help build and improve workflows, as well, potentially in a much more straightforward fashion. Flow can help us expand our toolset, and it's for us (the WMF-us) to prove that the balance of losses won't be too large in comparison to our (the Wikimedia-us) gains. But we (Wikimedia-we) need to do that cost accounting rationally, gently allowing reason, time, habit and adoption to act as a counter to the normal over-accouting of losses vs. gains. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
