On 22 August 2013 03:47, Maryana Pinchuk <mpinchuk(a)wikimedia.org> wrote:
On Wed, Aug 21, 2013 at 5:16 PM, Oliver Keyes
<okeyes(a)wikimedia.org>wrote;wrote:
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".
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.
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" :)
This is an excellent argument. As said, I think this will make a big
difference - but I also think it's going to be new. The reply feature
anointed by the angels will be awesome (can we get a choir of Seraphim in,
singing something by Wagner? It seems apropos) but it'll also be something
new, and unfamiliar. I feel like if we want this to be accepted, we have to
be able to pretty quickly demonstrate the benefit of learning how to use
the new and unfamiliar things. "If you use this, you get a watchlist
prompt" or "if you use this, you get an echo prompt" does that, and is
less
alien than an entirely new UI.
I can think of a couple of things that would do
this, and..probably not
feel conceptually out of place for the wikiproject release:
*Being able to watchlist individual threads, rather than merely see
changes for an entire page;
That might require some pretty elaborate changes to the backend of the
watchlist... but I can investigate.
Yeah, I have zero idea if these are workable, but it'd be good to have.
I'd
argue that it's going to be ultimately necessary *anyway* if we want to be
arguing for threads as a first-class citizen instead of pages.
*Echo integration
We'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?
I can see that being very useful, but I worry it might not have enough use
to
justify its placement overall. For wikiproject talkpages, at least, and
probably in other areas as well (I can see some places where it would be *
awesome*. RfP comes to mind). Things like Echo integration are going to be
more generalisable. Glad to see they're in the MVP; that should be enough
to provide something shiny for the community :).
What we might want to look at is being able to trigger the availability of
functionality via workflows. So, the community tinkers around on some
mw-namespace page, and now a productised {{done}} button appears - but only
in threads that involve {{helpme}} or {{editrequest}} templates, or
something. That sort of thing. A more long-term goal, however.
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
--
Oliver Keyes
Community Liaison, Product Development
Wikimedia Foundation