On Wed, Aug 21, 2013 at 5:16 PM, Oliver Keyes <okeyes@wikimedia.org> wrote:
The "talk pages" bit of that is actually great, and it's something I think we should all think about when we're building things (be they Flow or...anything else). I'm really happy that Maryana has; hat-tip to you :). When we're building something, whatever we build, there's going to be some community inertia to redirect - and so our job is to build it in the order that best minimises culture shock. So, we start from the principle of "this is talkpages, but different", and then we add in a drip-drip-drip of new functionality, and before you know it they're using flow. The alternative - presenting them with all of the contexts at once - risks having people dislike the whole because of a non-MVP part of it. So it's good to see this tack being taken.So, looking at the current MVP:I think the things on the list are fantabulous. They're all pieces of functionality we need - they're things the current setup provides for. However, I worry that on its own, that means the first look people will get at Flow is..."talkpages, only I need to learn a different way of doing things now".
Having said that; I worry about the "I need to learn a different way of doing things now". Minimising culture shock is great, but it's still going to be there - we're always forcing people to adapt, to some degree, and we need to give them something that makes them feel like it's an adaption worth making. Sticking with existing functionality for the MVP solves for a lot of the culture shock, but only having existing functionality for the MVP exacerbates the remainder. So I'd like us to explore if we can fit something new and shiny in the MVP, that demonstrates why power users should like (or at least tolerate) flow.
A very good point, and something I've been thinking about, as well. You're right that there's a precarious balance to be struck between support for existing functionality and new shiny things you can't currently easily do with wikis.However, while it may seem like the first release as specified is simply replicating talk page functionality, I think you shouldn't underestimate the powerful effect that having truly fast, modern (dare I say, delightful) discussion software may have on users. How much of your life have you wasted figuring out exactly how many colons you need when responding in a long multithreaded talk page discussion? And have you ever felt that little frisson of joy from hitting edit on a talk page – the one you might feel when, say, publishing an especially scathing retort to someone's idiocy on Facebook? :) I'm pretty sure all anyone's ever felt when hitting edit on a long talk page, even power users, is mild irritation at best. These are small, subconscious things we tend to overlook once we're past 1,000 edits, but those many hours a day of slow, clunky, painful interactions do add up.That's a big part of why I want us to focus on the seemingly simple stuff (add new topic, reply to comment) in the first release. I don't want us to just slap together an okay reply feature so we can move on to the "fun shiny stuff" – I want to make the fastest, most intuitive and viscerally satisfying reply we possibly can! Because at the end of the day, it doesn't matter how much fun shiny stuff we have if the simple humdrum act of writing and saving a new comment still kinda sucks...That said, I don't think it's out of the question to work on more things for the first release, as long as they don't distract too much from the aforementioned "reply feature anointed by the angels and soundtracked by golden harps" :)
*Being able to watchlist individual threads, rather than merely see changes for an entire page;
I can think of a couple of things that would do this, and..probably not feel conceptually out of place for the wikiproject release:
That might require some pretty elaborate changes to the backend of the watchlist... but I can investigate.
*Echo integrationWe'll have some form of Echo integration for sure; check out the last subsection of the MVP page (notifications).Another additional fun, shiny thing I'm thinking might be MVP-worthy is some lightweight comment resolved feature – not full-on closing/hatting threads, but just being able to productize those little {{doing}}/{{done}} templates... what do you think?
--