Last modified: 2014-09-13 17:28:16 UTC
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. :)
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).
(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.
(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.
deferring to Steven on this.
(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.
(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.
