Page MenuHomePhabricator

Show the watch star icon also to anonymous desktop users
Open, LowestPublicFeature

Description

I still have to meet someone that hasn't registered to Wikipedia but knows that you can watch (subscribe to) pages and receive notifications of its changes. And I believe a nice % would just register if they knew, in order to follow some page(s) they are interested about.

What about having the same UI with star icon or "Watch"link also for anonymous users? When they click (curious or confused) a dialog would pop up saying:

"Sign in to receive notifications about changes in this page. Not a {{SITENAME}} user yet? Register!"

This is no final copy. :)


Version: 1.23.0
Severity: enhancement

Details

Reference
bz54730

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:23 AM
bzimport set Reference to bz54730.
bzimport added a subscriber: Unknown Object (MLST).

Quim,

great idea, I believe the Growth team is investigating additional places to display login/signup call to actions (CTAs) this certainly *could* be one of them, however we should always try to keep a balance of showing relevant UI vs teasers.

I think with any CTA for signup we really have to "sell" the value. is watchlisting an article a selling point for a new user? maybe… but I'm guessing not, for many users this might seem like a very odd behavior "Add an article to a list of articles for which i am interested in waiting for changes to happen to them" Sure it will appeal to some people, but I'm not sure its our biggest selling point for creating an account.

For any login/signup CTA a mixture of why the thing you clicked on become better when you have an account PLUS the benefits of an account in general might be a good way to approach it.

MobileFrontend does show the star icon to anonymous users. When you tap a dialog appears:

"Please login or sign up to watch this page." + the 2 buttons.

The string can be improved but I personally think itś a good start (and maybe there is somewhere a possibility to retrieve data about how many anonymous users click that star and what do they do with it).

I'm not saying it's our biggest selling point for creating an account, but I believe the little icon star teaser for anonymous desktop users is worth a try.

(In reply to comment #2)

MobileFrontend does show the star icon to anonymous users.

MobileFrontend has been making a lot of ... questionable design choices lately. Some call it being experimental. Others are less sure. Either way, it's probably not a great model to emulate.

This request is essentially asking for MediaWiki to intentionally expose a non-functioning control. The general design principle in MediaWiki is to only show functional user interface elements (for example, unprivileged users are not shown a delete tab or a protect tab), though perhaps there's a reasonable case to make an exception here.

I remember for sure that it's proved the watch star attracts a significant number of new registrations, though they have a lower conversion to active users (they're mostly passive).

«On the mobile version, the star symbol for the watchlist is shown to all users, to encourage them to log in or create an account.»
[[m:Wikimedia Foundation Report, February 2013]]

«Readers show interest in saving articles offline, bookmarking and ‘watching’ articles, and rating articles/contributions/contributors.»
[[m:Research:Wikipedia Mobile User Research]]

Well, these are not really the quotations I was looking for but anyway I think it's proved this bug is a good idea, though it's not going to be the silver bullet for editor recruitment. The star is also quite unobtrusive, unlike a new tab.

[Mid-air collision.]

(In reply to comment #3)

This request is essentially asking for MediaWiki to intentionally expose a
non-functioning control. The general design principle in MediaWiki is to only
show functional user interface elements (for example, unprivileged users are
not shown a delete tab or a protect tab), though perhaps there's a reasonable
case to make an exception here.

This is a good point to make, but I don't think action=delete is a fair comparison.
A fair comparison are IMHO red links: they are established practice because they expose the nature of the wiki, though they are not super-intuitive and they've had their problems (bug 13058, bug 17288, bug 32052 + I think their title said "create page" at some point), not to mention that on en.wiki you have to become autoconfirmed in order to actually do something with them.
I also see "upload" links in the sidebar on en.wiki and it.wiki but those are arguably bugs of those local customisations.

What the red link teaches us is that we must not send users to a place where they are going to be confused. If I try action=delete as unregistered users I only get a nasty permission error; if I try action=watch, I get a link to login, then I have to click "Join {{SITENAME}}" and register, then go back and watch my article, which is not ideal but is doable (I feared a token error, now that watchlisting requires a token).
Possible improvements (before or after adding the watchlist button) are:

  1. add a returnto so that I can more easily get back where I started, generate a token in some way;
  2. reduce the number of clicks or otherwise improve the location where the unregistered user is sent (maybe a page linking also the atom feed? or something else not requiring registration which the user could be expecting there).

swalling wrote:

(In reply to comment #4)

I remember for sure that it's proved the watch star attracts a significant
number of new registrations, though they have a lower conversion to active
users (they're mostly passive).

«On the mobile version, the star symbol for the watchlist is shown to all
users, to encourage them to log in or create an account.»
[[m:Wikimedia Foundation Report, February 2013]]

«Readers show interest in saving articles offline, bookmarking and ‘watching’
articles, and rating articles/contributions/contributors.»
[[m:Research:Wikipedia Mobile User Research]]

Well, these are not really the quotations I was looking for but anyway I
think
it's proved this bug is a good idea, though it's not going to be the silver
bullet for editor recruitment. The star is also quite unobtrusive, unlike a
new
tab.

Nemo is correct here, I think.

Mobile used this CTA, and it got a lot of new people to sign up and use the watchlist. Not many of these people became contributors. Note that they also made the choice to have the default view be the raw list of watched pages, not the list of recent edits, so it looks like a bookmarking tool to many readers. That choice probably had a big part to play in the end result.

Now, this isn't really net negative, if readers repeatedly come back to their watchlist and get value out of it, even if they don't edit. But on the Growth team, our goal is to increase the number of active editors, so I'd like to use this same technique with more high-value calls to action.

TL;DR: sure we should try this at some point, but it's not a priority right now, because so far it looks like the results are that it gets readers to sign up, try the watchlist, and then not do much else.

swalling wrote:

(In reply to comment #6)

Nemo is correct here, I think.

Mobile used this CTA, and it got a lot of new people to sign up and use the
watchlist. Not many of these people became contributors. Note that they also
made the choice to have the default view be the raw list of watched pages,
not
the list of recent edits, so it looks like a bookmarking tool to many
readers.
That choice probably had a big part to play in the end result.

BTW some recently-published data on this at [[m:Research:Mobile editor engagement/Calls to action]]

Watchlist CTA users on mobile have a 2% activation rate (1+ article edits within 24hrs), which is much lower than normal users, who have about an 8% activation rate. Interestingly, users given the edit CTA have a very very activation rate, of 35%+. This is perhaps unsurprising considering anonymous editing is not allowed right now on mobile, but still probably supports the idea that we should try different CTAs before spending time on this bug.

(In reply to comment #4)

I remember for sure that it's proved the watch star attracts a significant
number of new registrations, though they have a lower conversion to active
users (they're mostly passive).

Ok, this argument makes sense and seems to be baked with data. No objections.

Still, MediaWiki admins might still prefer to have real registered users watching certain pages in their wikis as opposed to nothing. More real registered user (not spammers) watching pages eventually lead to more readers, and more readers eventually lead to more page visits (a licit goal for many sites) and perhaps more edits (even if it's only a small percentage, regular sites will do anything to increase legitimate contributions.

Therefore, I agree that this feature is perhaps not a silver bullet for exceptionally popular sites like en.wiki, but it might already be useful for the less popular Wikimedia sites that are craving to increase readership, and it would be definitely useful for many (most?) 3rd party MediaWikis.

(In reply to comment #8)

Therefore, I agree that this feature is perhaps not a silver bullet for
exceptionally popular sites like en.wiki, but it might already be useful for
the less popular Wikimedia sites that are craving to increase readership, and
it would be definitely useful for many (most?) 3rd party MediaWikis.

Indeed. Raising the bar too much also doesn't help seeing some movement. Just showing the star/watch button should be trivial and at worst people will need to use the back button to complete the action after registering (if there's no returnto). If there's any reason/doubt not to do this on WMF wikis, it can be disabled there via configuration.

swalling wrote:

(In reply to comment #9)

(In reply to comment #8)

Therefore, I agree that this feature is perhaps not a silver bullet for
exceptionally popular sites like en.wiki, but it might already be useful for
the less popular Wikimedia sites that are craving to increase readership, and
it would be definitely useful for many (most?) 3rd party MediaWikis.

Indeed. Raising the bar too much also doesn't help seeing some movement. Just
showing the star/watch button should be trivial and at worst people will need
to use the back button to complete the action after registering (if there's
no
returnto). If there's any reason/doubt not to do this on WMF wikis, it can be
disabled there via configuration.

I think it'd be fine if someone wants to do this, ala Quim and Nemo's comments.

My only requirement is that we make sure we track when it gets enabled and where precisely, so we can measure the before/after impact on registrations.

A related enhancement would be to provide a guided tour of the watchlist to users who sign up that route.

This might be the right idea, but it's wrong wrong approach. Just showing a non-functional feature that leads to a signup page is misleading to the users and will annoy them. People don't like that kind of surprise.

We had this problem on some wikis on Wikia because they did just that there (in monobook, anyway; there may have been better handling in the main skin(s)). The response was generally not, 'oh, let's sign up', but 'why is this even here? What the crap?' The relation between the tool and the need to sign up needs to be clearer for it to actually work.

Tumblr has a better example of handling this (though they too do the misleading thing sometimes as well), where they have a distinct interface for logged in and anonymous users - the anonymous see a button to sign up to follow the blog (watch it), and the logged in simply see a button to follow it. This way, when seeing the logged-out interface, those without accounts see an incentive to sign up directly, without any deception, and those who do have an account have a clear indication that oh, right, they're not logged in, they probably should. So this actually helps both groups of users.

On the other hand, while that would work for something like tumblr, tumblr is a blogging platform, and with blogs what you are watching are the feeds, not the individual posts. Would it actually help most wikis any to tell anonymous users that they can watch individual posts - the pages? Why would most anonymous users even WANT to watch a page? What good would this do them, unless they're already editing it? And if they are already editing it, wouldn't an indicator that they should sign up be better placed somewhere in the editing interface?

For what it's worth, before posting comment 9 I checked: you see a message "to watchlist pages you need to be logged in". I agree that setting the returnto parameter would make everyone more confident about such a change.

swalling wrote:

(In reply to comment #12)

This might be the right idea, but it's wrong wrong approach. Just showing a
non-functional feature that leads to a signup page is misleading to the users
and will annoy them. People don't like that kind of surprise.

Yes, you have to tell the user what's going on and why, you can't just redirect them to signup. I think everyone understands that.

(In reply to comment #14)

(In reply to comment #12)

This might be the right idea, but it's wrong wrong approach. Just showing a
non-functional feature that leads to a signup page is misleading to the users
and will annoy them. People don't like that kind of surprise.

Yes, you have to tell the user what's going on and why, you can't just
redirect
them to signup. I think everyone understands that.

Do they? Wikia and tumblr didn't.

Point is, adding a message that only appears on the way to signup, or on the signup page itself, doesn't address that. They need to know what they're clicking on when they click it, not after, and just adding the star doesn't tell them that.

On the other hand, the star itself doesn't even tell people who are logged in what it is unless they hover, which frankly isn't very good for something that's such an important part of the interface... I'd say that's a whole other ball of wax, but on the other hand perhaps that's what would need to be addressed to make it clearer what's going on to anonymous as well?

Isarra, you're adding way too many issues to this report. Can you please file each separately, adding to blockers? Thanks.

Each? What all are they, then? I'm not sure what you're referring to, aside from the star thing being potentially unclear, which as I recall already has a bug (would have linked it, but I couldn't find it).

Bug 23141, currently WONTFIXed.

(In reply to comment #17)

Each? What all are they, then? I'm not sure what you're referring to, aside
from the star thing being potentially unclear, which as I recall already has
a
bug (would have linked it, but I couldn't find it).

You said yourself, your comments belong to another bug: bug 23141 on the general matter; or bug 60594, bug 60595 about the specific issues you pointed to (whether willingly or unwillingly). Hence please stop discussing the merits of the star icon in general on this report.

I don't think bug 60595 or bug 23141 are blockers for this bug, because exposing this feature (and reason to login/register) to the unregistered users who understand it is an improvement, and as necessary as showing red links to users who don't have the permission to create pages, even if the presentation of the feature had to be separately worked on.

I'm sorry I inconvenienced you so much by mentioning potential blockers. I did try to preface the bit that contained my actual point by saying "Point is" at the beginning of that paragraph.

Take it or leave it, that was my point.

It's unclear whether this is desirable, removing "Easy" tag.

I couldn't find a general backlog for the Reading team, so I'm associating this proposal to Reading-Admin for now. I don't have a strong opinion about the proposal itself.

@Qgil, you probably want to put this in Web-Team-Backlog and remove Reading-Admin. In order for it to get a look at morning standup, you may need to put this as needs triage.

Qgil raised the priority of this task from Low to Needs Triage.Nov 23 2015, 10:19 AM
Qgil edited projects, added Web-Team-Backlog; removed Reading-Admin.

Ping @JKatzWMF @Nirzar, product and design should have a look at this!

Setting prio to Low for now.

Jdlrobson lowered the priority of this task from Low to Lowest.Jun 20 2017, 11:29 PM
Jdlrobson subscribed.

Doesnt seem to be a priority..

@ovasileva @alexhollender is this something we want to consider as part of desktop improvements or decline?

Why would most anonymous users even WANT to watch a page? What good would this do them, unless they're already editing it? And if they are already editing it, wouldn't an indicator that they should sign up be better placed somewhere in the editing interface?

I think this is the main point that comes to mind for me when considering this idea. Currently the Watchlist is not designed as an easy to use feature for newcomers. Even if we put the button there for logged-out people to click on, I think they would be confused and/or disappointed after signing up and landing on the watchlist. Until we have a reader-friendly variation of Watchlist that is more like a "Reading list" or "Bookmark" feature I don't think it makes sense to show to logged-out people.

Deferring to the growth team folks for further consideration @RHo @MMiller_WMF

In T56730#6792169, @alexhollender wrote:

Why would most anonymous users even WANT to watch a page? What good would this do them, unless they're already editing it? And if they are already editing it, wouldn't an indicator that they should sign up be better placed somewhere in the editing interface?

I think this is the main point that comes to mind for me when considering this idea. Currently the Watchlist is not designed as an easy to use feature for newcomers. Even if we put the button there for logged-out people to click on, I think they would be confused and/or disappointed after signing up and landing on the watchlist. Until we have a reader-friendly variation of Watchlist that is more like a "Reading list" or "Bookmark" feature I don't think it makes sense to show to logged-out people.

Deferring to the growth team folks for further consideration @RHo @MMiller_WMF

I agree that the current usage of the Watchlist is targeted at editors, so tend to agree that we shouldn't advertise it to logged out users on the read version of the page. Having said that, do we have any information on its usage on mobile that shows it has been used and useful for non-logged in users?

image.png (1×722 px, 115 KB)

Do we know for example if how many folks who tap on the watchlist icon on mobile then go on to log in vs sign up vs dismiss?

Having said that, do we have any information on its usage on mobile that shows it has been used and useful for non-logged in users?

We did, but I'm not sure it's a fair comparison as the feature works very differently on mobile - it defaults to a list view which is useful to use as a reading list (and people were doing exactly that back in 2013).

Do we know for example if how many folks who tap on the watchlist icon on mobile then go on to log in vs sign up vs dismiss?

https://www.mediawiki.org/wiki/Mobile_Beta/Watchlist/Logging is the only thing I'm aware of.

Note takeaway "Overall, the watchlist star hook + account creation has proven to be a very effective new account creation funnel, helping arrest the year-over-year decline of new account creations"

Having said that, do we have any information on its usage on mobile that shows it has been used and useful for non-logged in users?

We did, but I'm not sure it's a fair comparison as the feature works very differently on mobile - it defaults to a list view which is useful to use as a reading list (and people were doing exactly that back in 2013).

Do we know for example if how many folks who tap on the watchlist icon on mobile then go on to log in vs sign up vs dismiss?

https://www.mediawiki.org/wiki/Mobile_Beta/Watchlist/Logging is the only thing I'm aware of.

Note takeaway "Overall, the watchlist star hook + account creation has proven to be a very effective new account creation funnel, helping arrest the year-over-year decline of new account creations"

Thanks for this info @Jdlrobson - very interesting! I think the point about how differently it works on mobile is very relevant here as is whether it is useful in driving engagement beyond account creations, since one of the other takeaways was that: "New users may not understand or value the watchlist star feature as much as existing Wikimedians. The vast majority of one-time watchlist star users were brand-new Wikimedians who had registered via mobile. However, the vast majority of users who tapped the star more than once were existing users who already had a Wikimedia account."
This behaviour speaks to @alexhollender's point about newcomers likely being confused/disappointed by what the watchlist does after their initial sign up.

TL:DR; I agree with @alexhollender's recommendation that this task should be tackled in conjunction with improvements to the Watchlist page. At the very least, there could be minor changes so that:
(i) non-editors understand the purpose and value of the watchlist page; and
(ii) the watchlist can be used as a bookmark/favourites function (for example, by providing clearer affordance/access to the watchlist list view).

adding a stray comment here that came up when we were discussing the Watchlist in the Android App at design review:

I wonder how newcomers make sense of "Watch" as an action? What do they expect it does? And what about the star icon, what associations come with that? I then wonder if there are other, more familiar concepts from websites/apps. The two that come to mind first are "Subscribe" and "Follow". To me they both communicate: as a result of this action you will be getting updates about this thing. Related: "Watch" is an action on GitHub (eye icon), though interestingly they also have a "Star" action (star icon) — the difference between the two being the types of notifications that result (see https://www.wired.com/2012/08/github-changes-make-it-easier-to-track-your-favorite-projects/).

Screen Shot 2021-02-09 at 7.34.16 PM.png (281×783 px, 58 KB)

This is a very interesting discussion. I agree that this idea probably shouldn't be a priority without a broader effort around what experience we're actually trying to deliver to the anonymous users with the idea. But I will add some interesting data points for future reference. According to the Growth team's welcome survey, large numbers of people who create accounts say they do so "to read Wikipedia". I think this is because users mistakenly believe that by creating an account, they'll get access to substantially more functionality. So this gives us a sense of how many people might be interested in enhanced reading features if they have an account.

image.png (260×428 px, 27 KB)

@MMiller_WMF Thanks for sharing, that's very interesting indeed. I wasn't sure what your conclusion was, but it sounds like this implies users are already aware that additional capabilities will be provided to logged-in users thus perhaps not needing another indicator such as through the inert watchstart proposed here. Is that how you view it as well?

As an example of how users might come to have this knowledge/expectation, we tell them on the edit page:

cap.png (420×1 px, 51 KB)

@Krinkle -- I'm actually thinking about it differently. I think that the high percentage of people saying they created an account "to read Wikipedia" means that users suspect that more reading features might be available to them when they create an account (when in reality, little changes about the reading experience when logged-in). So they create an account anyway, hoping to see what will change. I think that if they had learned about the opportunity to create an account via the example you showed, then they wouldn't be answering the question as "to read Wikipedia"; they would be giving an answer about editing.

Taking it all together, I think it means that a substantial portion of users would be interested in enhanced reading features, such as "starring to put on a reading list", if such features were to exist.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:14 AM
Aklapper removed subscribers: JKatzWMF, Nirzar.

This doesn't seem like it's in scope for desktop improvements project at current time.