Greetings,
I've started a draft of the requirements for the first release of Flow to a real live Wikimedia project: http://www.mediawiki.org/wiki/Flow_Portal/MVP. This is still just a draft and very much open to more input, so please have a look and let me know what you think, either here or on the talk page: http://www.mediawiki.org/w/index.php?title=Talk:Flow_Portal/MVP.
As I think some of you know, we've shifted the focus of our first release from user talk to WikiProject talk (yay, pivoting!) to give us some time to figure out how to deal with bots, tools, and user warning/messaging/blocking workflows. Instead of trying to solve all those hairy problems in our first release, I want to be sure we can first and foremost handle the core peer-to-peer discussion/content collaboration that talk pages are meant for, and I think a WikiProject talk page is a good test-bed for making sure we've got those pieces nailed down. The plan is to:
1) Build a fully functional prototype on Labs based on the above requirements, in order to let the community come kick the tires.
2) Specifically invite facilitators and members of some active WikiProjects (on enwiki, but not necessarily enwiki only) to give the Labs prototype a try and see if they'd be willing to trial a beta version on their WikiProject discussion space for some period of time.
3) Release to a few WikiProjects that are game, gather data, bugs, feature requests, and keeping working to make Flow the most kick-ass wiki discussion/collaboration software of all time :)
4) When we're comfortable that we've satisfied the requirements for WikiProject talk, we'll begin working on the next set of requirements for other discussion spaces (probably user talk).
So, that's the short-term roadmap! Right now, Andrew and Erik B. are working on point 1) and will hopefully have something to share publicly in the next couple of weeks. Stay tuned, and if you have any comments/feedback on anything Flow related, don't hesitate to chime in :)
Danke for coming up with this so speedily! I'll drop my thoughts on the mailing list later today/early tomorrow.
On 20 August 2013 23:57, Maryana Pinchuk mpinchuk@wikimedia.org wrote:
Greetings,
I've started a draft of the requirements for the first release of Flow to a real live Wikimedia project: http://www.mediawiki.org/wiki/Flow_Portal/MVP. This is still just a draft and very much open to more input, so please have a look and let me know what you think, either here or on the talk page: http://www.mediawiki.org/w/index.php?title=Talk:Flow_Portal/MVP.
As I think some of you know, we've shifted the focus of our first release from user talk to WikiProject talk (yay, pivoting!) to give us some time to figure out how to deal with bots, tools, and user warning/messaging/blocking workflows. Instead of trying to solve all those hairy problems in our first release, I want to be sure we can first and foremost handle the core peer-to-peer discussion/content collaboration that talk pages are meant for, and I think a WikiProject talk page is a good test-bed for making sure we've got those pieces nailed down. The plan is to:
- Build a fully functional prototype on Labs based on the above
requirements, in order to let the community come kick the tires.
- Specifically invite facilitators and members of some active
WikiProjects (on enwiki, but not necessarily enwiki only) to give the Labs prototype a try and see if they'd be willing to trial a beta version on their WikiProject discussion space for some period of time.
- Release to a few WikiProjects that are game, gather data, bugs, feature
requests, and keeping working to make Flow the most kick-ass wiki discussion/collaboration software of all time :)
- When we're comfortable that we've satisfied the requirements for
WikiProject talk, we'll begin working on the next set of requirements for other discussion spaces (probably user talk).
So, that's the short-term roadmap! Right now, Andrew and Erik B. are working on point 1) and will hopefully have something to share publicly in the next couple of weeks. Stay tuned, and if you have any comments/feedback on anything Flow related, don't hesitate to chime in :)
-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org
E2 mailing list E2@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/e2
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.
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; *Echo integration
No idea which is easier, or if the entire idea is dumb as all hell, but I thought I'd raise it.
(there's another discussion we were having, re oversight: going to surface that in a different thread to avoid having two TL;DR conversations at once).
On 21 August 2013 20:54, Oliver Keyes okeyes@wikimedia.org wrote:
Danke for coming up with this so speedily! I'll drop my thoughts on the mailing list later today/early tomorrow.
On 20 August 2013 23:57, Maryana Pinchuk mpinchuk@wikimedia.org wrote:
Greetings,
I've started a draft of the requirements for the first release of Flow to a real live Wikimedia project: http://www.mediawiki.org/wiki/Flow_Portal/MVP. This is still just a draft and very much open to more input, so please have a look and let me know what you think, either here or on the talk page: http://www.mediawiki.org/w/index.php?title=Talk:Flow_Portal/MVP.
As I think some of you know, we've shifted the focus of our first release from user talk to WikiProject talk (yay, pivoting!) to give us some time to figure out how to deal with bots, tools, and user warning/messaging/blocking workflows. Instead of trying to solve all those hairy problems in our first release, I want to be sure we can first and foremost handle the core peer-to-peer discussion/content collaboration that talk pages are meant for, and I think a WikiProject talk page is a good test-bed for making sure we've got those pieces nailed down. The plan is to:
- Build a fully functional prototype on Labs based on the above
requirements, in order to let the community come kick the tires.
- Specifically invite facilitators and members of some active
WikiProjects (on enwiki, but not necessarily enwiki only) to give the Labs prototype a try and see if they'd be willing to trial a beta version on their WikiProject discussion space for some period of time.
- Release to a few WikiProjects that are game, gather data, bugs,
feature requests, and keeping working to make Flow the most kick-ass wiki discussion/collaboration software of all time :)
- When we're comfortable that we've satisfied the requirements for
WikiProject talk, we'll begin working on the next set of requirements for other discussion spaces (probably user talk).
So, that's the short-term roadmap! Right now, Andrew and Erik B. are working on point 1) and will hopefully have something to share publicly in the next couple of weeks. Stay tuned, and if you have any comments/feedback on anything Flow related, don't hesitate to chime in :)
-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org
E2 mailing list E2@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/e2
-- Oliver "has his pedantry and finnickiness triggered by silent mailing lists" Keyes Community Liaison, Product Development Wikimedia Foundation
On Wed, Aug 21, 2013 at 5:16 PM, Oliver Keyes okeyes@wikimedia.org 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" :)
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.
*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?
On 22 August 2013 03:47, Maryana Pinchuk mpinchuk@wikimedia.org wrote:
On Wed, Aug 21, 2013 at 5:16 PM, Oliver Keyes okeyes@wikimedia.orgwrote:
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.