Greetings,
This is probably my first time to post on wikitech-l. I am Moushira, a new community liaison for mobile projects, I would like to share an update for a new feature that is ready for deployment. This January, Jon Katz announced a new feature in development https://lists.wikimedia.org/pipermail/wikitech-l/2015-January/080168.html, and after nearly two months, Extension:Gather https://www.mediawiki.org/wiki/Extension:Gather is now ready for beta launch scheduled for Monday. The feature will be enabled for logged in users on the English Wikipedia mobile website, who have their mobile beta features activated [1]. There is a list of FAQ https://www.mediawiki.org/wiki/Extension:Gather/FAQ which includes information on usability and moderation, and you are welcome to add more questions to it :).
The Extension will keep the name Gather and internally the team was more inclined to name the feature "Stacks". However, a survey study has been carried out by the design research team and Collections, as a name for a feature, scored far better than the other suggested alternatives. Full survey information and results are documented here https://www.mediawiki.org/wiki/Extension%CB%90Gather/renaming_survey.
There are different scenarios for how this feature can be used, either for subjective personal collections, or for broader use. This Beta test will help us discover what resonates. One idea we hope to explore is engaging editors via themed competitions using collections of articles one has edited on a particular topic (such as medicine). We are also interested to see how this tool can be used by WikiProjects, WLM, or the education program. We encourage you to play around with the feature and let us know how you're using it!
This is a new experiment in content curation, which hopefully helps with learning new users behavior on mobile web. We are looking forward to learning awesome lessons from this beta launch.
All the best, Moushira
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Extensi...
Hi.
Moushira Elamrawy wrote:
The Extension will keep the name Gather and internally the team was more inclined to name the feature "Stacks". However, a survey study has been carried out by the design research team and Collections, as a name for a feature, scored far better than the other suggested alternatives. Full survey information and results are documented here https://www.mediawiki.org/wiki/Extension%CB%90Gather/renaming_survey.
Right... in the January 2015 thread you linked, it was quickly pointed out that Extension:Collection already exists. The mobile team, in typical form, decided to ignore any previous work and instead make its own project. At least we were able to shout loudly enough to stop this functionality from being part of the MobileFrontend extension.
This is a new experiment in content curation, which hopefully helps with learning new users behavior on mobile web. We are looking forward to learning awesome lessons from this beta launch.
As was also previously pointed out, we've had curation support for a long time in the form of categories (another feature that could have been improved rather than making a new extension). Or making a list of pages using wikilinks. Or tagging pages with templates, which auto-generates an index. Perhaps you can explain why this new feature is limited to mobile?
MZMcBride
On Mar 26, 2015 9:58 AM, "MZMcBride" z@mzmcbride.com wrote:
Hi.
Moushira Elamrawy wrote:
The Extension will keep the name Gather and internally the team was more inclined to name the feature "Stacks". However, a survey study has been carried out by the design research team and Collections, as a name for a feature, scored far better than the other suggested alternatives. Full survey information and results are documented here https://www.mediawiki.org/wiki/Extension%CB%90Gather/renaming_survey.
Right... in the January 2015 thread you linked, it was quickly pointed out that Extension:Collection already exists. The mobile team, in typical form, decided to ignore any previous work and instead make its own project. At least we were able to shout loudly enough to stop this functionality from being part of the MobileFrontend extension.
Hey, count your blessings its not called "collections" with just an s at the end to distinguish it...
This is a new experiment in content curation, which hopefully helps with learning new users behavior on mobile web. We are looking forward to learning awesome lessons from this beta launch.
As was also previously pointed out, we've had curation support for a long time in the form of categories (another feature that could have been improved rather than making a new extension). Or making a list of pages using wikilinks. Or tagging pages with templates, which auto-generates an index. Perhaps you can explain why this new feature is limited to mobile?
I dont know if this criticism is fair. Many users have been asking for multiple watchlist type functionality for years despite the option of creating a subpage or category and throwing special:recentchangeslinked. Categories dont really have per user namespace, and i think its important to have interfaces that encourage users to do this sort of thing rather then making them figure out that they are physically able to and allowed to.
I do agree that its odd that this isnt developed in core for all users. The faq entry is unconvincing.
--bawolff
On Mar 26, 2015 11:04 AM, "Brian Wolff" bawolff@gmail.com wrote:
On Mar 26, 2015 9:58 AM, "MZMcBride" z@mzmcbride.com wrote:
Hi.
Moushira Elamrawy wrote:
The Extension will keep the name Gather and internally the team was
more
inclined to name the feature "Stacks". However, a survey study has been carried out by the design research team and Collections, as a name for
a
feature, scored far better than the other suggested alternatives. Full survey information and results are documented here https://www.mediawiki.org/wiki/Extension%CB%90Gather/renaming_survey.
Right... in the January 2015 thread you linked, it was quickly pointed
out
that Extension:Collection already exists. The mobile team, in typical form, decided to ignore any previous work and instead make its own project. At least we were able to shout loudly enough to stop this functionality from being part of the MobileFrontend extension.
Hey, count your blessings its not called "collections" with just an s at
the end to distinguish it...
This is a new experiment in content curation, which hopefully helps
with
learning new users behavior on mobile web. We are looking forward to learning awesome lessons from this beta launch.
As was also previously pointed out, we've had curation support for a
long
time in the form of categories (another feature that could have been improved rather than making a new extension). Or making a list of pages using wikilinks. Or tagging pages with templates, which auto-generates
an
index. Perhaps you can explain why this new feature is limited to
mobile?
I dont know if this criticism is fair. Many users have been asking for
multiple watchlist type functionality for years despite the option of creating a subpage or category and throwing special:recentchangeslinked. Categories dont really have per user namespace, and i think its important to have interfaces that encourage users to do this sort of thing rather then making them figure out that they are physically able to and allowed to.
I do agree that its odd that this isnt developed in core for all users.
The faq entry is unconvincing.
--bawolff
Actually after reading the extension page, I'm a little confused. If the goal is to create private personal lists why are the lists public? I can understand the use case for private lists (watchlist). I understand the use case for public lists (categories). What is the use case for pseudo-private lists?
Maybe it will make more sense to me when the extension is deployed and I see it in action.
On 26 mrt. 2015, at 15:19, Brian Wolff bawolff@gmail.com wrote:
Actually after reading the extension page, I'm a little confused. If the goal is to create private personal lists why are the lists public? I can understand the use case for private lists (watchlist). I understand the use case for public lists (categories). What is the use case for pseudo-private lists?
Maybe it will make more sense to me when the extension is deployed and I see it in action.
Yeah when I was looking at it, my first thought was: Why not decouple those usecases ? - a method to make personal lists (private by default) - a method to share a list publicly I was thinking something similar to how cloud services share documents and or directories.
DJ
A few notes: * lists are public in the first version but there is APIs to make them private. Public lists is something that will have moderation problems and interesting to explore. * the feature is _launching_ on mobile. It's built to work on desktop and with a tiny bit of work I can turn it on as a beta feature on desktop (the issue is how to replace the existing watchstar on desktop). * We considered doing it straight in core based on the watchlist code but we figured it would be more responsible to experiment in an extension, fine tune it against a completely different use case to watchlist and then make a proposal to move the good parts/all parts into core. I'm still personally dedicated to resolving the RFC [1]. We have worked hard so that the api to gather is backwards compatible with watchlist methods. * you can play with it on betalabs: ** http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Gather/by/Jdlrobson ** http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Gather * I'm personally excited to make multiple watchlists a reality using this extension at Lyon if anyone is keen to help me there. The infrastructure required is all in Gather.
[1] https://m.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specific_... On 26 Mar 2015 7:20 am, "Brian Wolff" bawolff@gmail.com wrote:
On Mar 26, 2015 11:04 AM, "Brian Wolff" bawolff@gmail.com wrote:
On Mar 26, 2015 9:58 AM, "MZMcBride" z@mzmcbride.com wrote:
Hi.
Moushira Elamrawy wrote:
The Extension will keep the name Gather and internally the team was
more
inclined to name the feature "Stacks". However, a survey study has
been
carried out by the design research team and Collections, as a name for
a
feature, scored far better than the other suggested alternatives.
Full
survey information and results are documented here <https://www.mediawiki.org/wiki/Extension%CB%90Gather/renaming_survey
.
Right... in the January 2015 thread you linked, it was quickly pointed
out
that Extension:Collection already exists. The mobile team, in typical form, decided to ignore any previous work and instead make its own project. At least we were able to shout loudly enough to stop this functionality from being part of the MobileFrontend extension.
Hey, count your blessings its not called "collections" with just an s at
the end to distinguish it...
This is a new experiment in content curation, which hopefully helps
with
learning new users behavior on mobile web. We are looking forward to learning awesome lessons from this beta launch.
As was also previously pointed out, we've had curation support for a
long
time in the form of categories (another feature that could have been improved rather than making a new extension). Or making a list of pages using wikilinks. Or tagging pages with templates, which auto-generates
an
index. Perhaps you can explain why this new feature is limited to
mobile?
I dont know if this criticism is fair. Many users have been asking for
multiple watchlist type functionality for years despite the option of creating a subpage or category and throwing special:recentchangeslinked. Categories dont really have per user namespace, and i think its important to have interfaces that encourage users to do this sort of thing rather then making them figure out that they are physically able to and allowed to.
I do agree that its odd that this isnt developed in core for all users.
The faq entry is unconvincing.
--bawolff
Actually after reading the extension page, I'm a little confused. If the goal is to create private personal lists why are the lists public? I can understand the use case for private lists (watchlist). I understand the use case for public lists (categories). What is the use case for pseudo-private lists?
Maybe it will make more sense to me when the extension is deployed and I see it in action. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I should add you can opt into mobile beta using this link: http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileOptions
The design still has kinks and the extension still needs work before. Releasing to mobile beta will get us an audience to identify those issues and fix them. I'd be keen to get this as a desktop beta feature too if anyone is willing to help me. On 26 Mar 2015 7:41 am, "Jon Robson" jrobson@wikimedia.org wrote:
A few notes:
- lists are public in the first version but there is APIs to make them
private. Public lists is something that will have moderation problems and interesting to explore.
- the feature is _launching_ on mobile. It's built to work on desktop and
with a tiny bit of work I can turn it on as a beta feature on desktop (the issue is how to replace the existing watchstar on desktop).
- We considered doing it straight in core based on the watchlist code but
we figured it would be more responsible to experiment in an extension, fine tune it against a completely different use case to watchlist and then make a proposal to move the good parts/all parts into core. I'm still personally dedicated to resolving the RFC [1]. We have worked hard so that the api to gather is backwards compatible with watchlist methods.
- you can play with it on betalabs:
** http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Gather/by/Jdlrobson ** http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Gather
- I'm personally excited to make multiple watchlists a reality using this
extension at Lyon if anyone is keen to help me there. The infrastructure required is all in Gather.
[1] https://m.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specific_... On 26 Mar 2015 7:20 am, "Brian Wolff" bawolff@gmail.com wrote:
On Mar 26, 2015 11:04 AM, "Brian Wolff" bawolff@gmail.com wrote:
On Mar 26, 2015 9:58 AM, "MZMcBride" z@mzmcbride.com wrote:
Hi.
Moushira Elamrawy wrote:
The Extension will keep the name Gather and internally the team was
more
inclined to name the feature "Stacks". However, a survey study has
been
carried out by the design research team and Collections, as a name
for a
feature, scored far better than the other suggested alternatives.
Full
survey information and results are documented here <
https://www.mediawiki.org/wiki/Extension%CB%90Gather/renaming_survey%3E.
Right... in the January 2015 thread you linked, it was quickly pointed
out
that Extension:Collection already exists. The mobile team, in typical form, decided to ignore any previous work and instead make its own project. At least we were able to shout loudly enough to stop this functionality from being part of the MobileFrontend extension.
Hey, count your blessings its not called "collections" with just an s at
the end to distinguish it...
This is a new experiment in content curation, which hopefully helps
with
learning new users behavior on mobile web. We are looking forward to learning awesome lessons from this beta launch.
As was also previously pointed out, we've had curation support for a
long
time in the form of categories (another feature that could have been improved rather than making a new extension). Or making a list of
pages
using wikilinks. Or tagging pages with templates, which auto-generates
an
index. Perhaps you can explain why this new feature is limited to
mobile?
I dont know if this criticism is fair. Many users have been asking for
multiple watchlist type functionality for years despite the option of creating a subpage or category and throwing special:recentchangeslinked. Categories dont really have per user namespace, and i think its important to have interfaces that encourage users to do this sort of thing rather then making them figure out that they are physically able to and allowed to.
I do agree that its odd that this isnt developed in core for all users.
The faq entry is unconvincing.
--bawolff
Actually after reading the extension page, I'm a little confused. If the goal is to create private personal lists why are the lists public? I can understand the use case for private lists (watchlist). I understand the use case for public lists (categories). What is the use case for pseudo-private lists?
Maybe it will make more sense to me when the extension is deployed and I see it in action. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks for the link Jon.
It seems only fair that people actually try the feature before ripping it to shreds. Right? We've had extensions to create alternative content curation features in the past, such as books, and this is hardly the first time an experimental feature was launched on mobile first. So hardly seems like time to grab the pitchforks before you even give it a fair shot.
On Thu, Mar 26, 2015 at 8:00 AM Jon Robson jrobson@wikimedia.org wrote:
I should add you can opt into mobile beta using this link: http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileOptions
The design still has kinks and the extension still needs work before. Releasing to mobile beta will get us an audience to identify those issues and fix them. I'd be keen to get this as a desktop beta feature too if anyone is willing to help me. On 26 Mar 2015 7:41 am, "Jon Robson" jrobson@wikimedia.org wrote:
A few notes:
- lists are public in the first version but there is APIs to make them
private. Public lists is something that will have moderation problems and interesting to explore.
- the feature is _launching_ on mobile. It's built to work on desktop and
with a tiny bit of work I can turn it on as a beta feature on desktop
(the
issue is how to replace the existing watchstar on desktop).
- We considered doing it straight in core based on the watchlist code but
we figured it would be more responsible to experiment in an extension,
fine
tune it against a completely different use case to watchlist and then
make
a proposal to move the good parts/all parts into core. I'm still
personally
dedicated to resolving the RFC [1]. We have worked hard so that the api
to
gather is backwards compatible with watchlist methods.
- you can play with it on betalabs:
Gather/by/Jdlrobson
** http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Gather
- I'm personally excited to make multiple watchlists a reality using this
extension at Lyon if anyone is keen to help me there. The infrastructure required is all in Gather.
[1] https://m.mediawiki.org/wiki/Requests_for_comment/Support_
for_user-specific_page_lists_in_core
On 26 Mar 2015 7:20 am, "Brian Wolff" bawolff@gmail.com wrote:
On Mar 26, 2015 11:04 AM, "Brian Wolff" bawolff@gmail.com wrote:
On Mar 26, 2015 9:58 AM, "MZMcBride" z@mzmcbride.com wrote:
Hi.
Moushira Elamrawy wrote:
The Extension will keep the name Gather and internally the team was
more
inclined to name the feature "Stacks". However, a survey study has
been
carried out by the design research team and Collections, as a name
for a
feature, scored far better than the other suggested alternatives.
Full
survey information and results are documented here <
https://www.mediawiki.org/wiki/Extension%CB%90Gather/renaming_survey%3E.
Right... in the January 2015 thread you linked, it was quickly
pointed
out
that Extension:Collection already exists. The mobile team, in
typical
form, decided to ignore any previous work and instead make its own project. At least we were able to shout loudly enough to stop this functionality from being part of the MobileFrontend extension.
Hey, count your blessings its not called "collections" with just an s
at
the end to distinguish it...
This is a new experiment in content curation, which hopefully helps
with
learning new users behavior on mobile web. We are looking forward
to
learning awesome lessons from this beta launch.
As was also previously pointed out, we've had curation support for a
long
time in the form of categories (another feature that could have been improved rather than making a new extension). Or making a list of
pages
using wikilinks. Or tagging pages with templates, which
auto-generates
an
index. Perhaps you can explain why this new feature is limited to
mobile?
I dont know if this criticism is fair. Many users have been asking for
multiple watchlist type functionality for years despite the option of creating a subpage or category and throwing special:recentchangeslinked. Categories dont really have per user namespace, and i think its
important
to have interfaces that encourage users to do this sort of thing rather then making them figure out that they are physically able to and allowed to.
I do agree that its odd that this isnt developed in core for all
users.
The faq entry is unconvincing.
--bawolff
Actually after reading the extension page, I'm a little confused. If the goal is to create private personal lists why are the lists public? I can understand the use case for private lists (watchlist). I understand the use case for public lists (categories). What is the use case for pseudo-private lists?
Maybe it will make more sense to me when the extension is deployed and I see it in action. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
It seems only fair that people actually try the feature before ripping it to shreds. Right?
In principle, no. People should rip things to shred early and often. After extension is done is the worst time to fix errors in the requirements phase. (Although if you mean this particular case, where demo exists, then im more inclined to agree, but the demo link was posted after the more rip to shed emails)
We've had extensions to create alternative content
curation features in the past, such as books, and this is hardly the first time an experimental feature was launched on mobile first. So hardly seems like time to grab the pitchforks before you even give it a fair shot.
Just because we have done it before, doesnt neccesarily imply we should do it again. Wikimedia has done lots of things that were bad ideas, especially in retrospect.
That said, given the existence of an iteration, i agree we should all try it before engaging in strong criticism.
--bawolff
On Thu, Mar 26, 2015 at 8:00 AM Jon Robson jrobson@wikimedia.org wrote:
I should add you can opt into mobile beta using this link: http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileOptions
The design still has kinks and the extension still needs work before. Releasing to mobile beta will get us an audience to identify those
issues
and fix them. I'd be keen to get this as a desktop beta feature too if anyone is willing to help me. On 26 Mar 2015 7:41 am, "Jon Robson" jrobson@wikimedia.org wrote:
A few notes:
- lists are public in the first version but there is APIs to make them
private. Public lists is something that will have moderation problems
and
interesting to explore.
- the feature is _launching_ on mobile. It's built to work on desktop
and
with a tiny bit of work I can turn it on as a beta feature on desktop
(the
issue is how to replace the existing watchstar on desktop).
- We considered doing it straight in core based on the watchlist code
but
we figured it would be more responsible to experiment in an extension,
fine
tune it against a completely different use case to watchlist and then
make
a proposal to move the good parts/all parts into core. I'm still
personally
dedicated to resolving the RFC [1]. We have worked hard so that the
api
to
gather is backwards compatible with watchlist methods.
- you can play with it on betalabs:
Gather/by/Jdlrobson
** http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Gather
- I'm personally excited to make multiple watchlists a reality using
this
extension at Lyon if anyone is keen to help me there. The
infrastructure
required is all in Gather.
[1] https://m.mediawiki.org/wiki/Requests_for_comment/Support_
for_user-specific_page_lists_in_core
On 26 Mar 2015 7:20 am, "Brian Wolff" bawolff@gmail.com wrote:
On Mar 26, 2015 11:04 AM, "Brian Wolff" bawolff@gmail.com wrote:
On Mar 26, 2015 9:58 AM, "MZMcBride" z@mzmcbride.com wrote:
Hi.
Moushira Elamrawy wrote: >The Extension will keep the name Gather and internally the team
was
more
>inclined to name the feature "Stacks". However, a survey study
has
been
>carried out by the design research team and Collections, as a
name
for a
>feature, scored far better than the other suggested
alternatives.
Full
>survey information and results are documented here ><
https://www.mediawiki.org/wiki/Extension%CB%90Gather/renaming_survey
.
Right... in the January 2015 thread you linked, it was quickly
pointed
out
that Extension:Collection already exists. The mobile team, in
typical
form, decided to ignore any previous work and instead make its
own
project. At least we were able to shout loudly enough to stop
this
functionality from being part of the MobileFrontend extension.
Hey, count your blessings its not called "collections" with just
an s
at
the end to distinguish it...
>This is a new experiment in content curation, which hopefully
helps
with
>learning new users behavior on mobile web. We are looking
forward
to
>learning awesome lessons from this beta launch.
As was also previously pointed out, we've had curation support
for a
long
time in the form of categories (another feature that could have
been
improved rather than making a new extension). Or making a list of
pages
using wikilinks. Or tagging pages with templates, which
auto-generates
an
index. Perhaps you can explain why this new feature is limited to
mobile?
I dont know if this criticism is fair. Many users have been asking
for
multiple watchlist type functionality for years despite the option of creating a subpage or category and throwing
special:recentchangeslinked.
Categories dont really have per user namespace, and i think its
important
to have interfaces that encourage users to do this sort of thing
rather
then making them figure out that they are physically able to and
allowed
to.
I do agree that its odd that this isnt developed in core for all
users.
The faq entry is unconvincing.
--bawolff
Actually after reading the extension page, I'm a little confused. If
the
goal is to create private personal lists why are the lists public? I
can
understand the use case for private lists (watchlist). I understand
the
use case for public lists (categories). What is the use case for pseudo-private lists?
Maybe it will make more sense to me when the extension is deployed
and I
see it in action. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Mar 26, 2015 at 10:04 AM, Brian Wolff bawolff@gmail.com wrote:
I do agree that its odd that this isnt developed in core for all users. The faq entry is unconvincing.
+1.
Last I had heard the extension was just a UI prototype. Now it's suddenly being deployed to production. The current claim is that it's for mobile only, but I'm wary of the implication that it will eventually be abandoned in favor of a more comprehensive solution in core (versus becoming "the" solution for multiple watchlists with whatever shortcomings it might have, not least that it's an extension and not core).
wikitech-l@lists.wikimedia.org