Please reply here to discuss the "In-context questions or chat (1)" idea.
Talk:Growth/Discussing potential Growth ideas/2023
I didn't notice the feedback form on the visuel editor but it's quite powerful because very easy to use and uses Flow (so user is notified when he gets an answer). We could easily imagine a form which will post directly on the newcomers forum (on the French Wikipedia, this forum is very active with numerous contributors).
I don't know if a 1-to-1 chat can be useful for medium size wikis as it may require available 24/7...
Looking forward to discuss this project with you!
@Arthur Crbz, thank you for your feedback. Overall, just a quick note: this is not a vote. For now, we are asking for thoughts and reactions on these ideas from as many communities as possible:
- Could you imagine these ideas working in your wikis?
- Do you know of similar things having been tried before?
- What other ideas do you think would work well to retain new editors?
Makes no sense. At best, a link for help on the editing toolbar, but virtually every wiki has a link to that on the left sidebar. There is the potential for the system to be flooded with queries which can be easily answered with minimal effort.
(project: English Wikibooks, the message delivery went to the wrong part of the site)
(Sorry for the bad target.)
Sounds like a great idea. I would prefer article talk pages for any questions. I think in many wikis wikiprojects are not active, so better to use article talk pages, and for technical, non-article related questions use village pump / help desk. I think currently many new users don't know that they can discuss about subject on talk page.
I wonder if you could work in some type of tooling for giving folks more generic documentation about the things that they ask for based on keywords would be helpful. For example, if folks ask about sourcing, providing a nutshell and link to further documentation about that verifiability or reliable sources would be super useful, for example. I don't think increasing the volume of questions at help forums, will neccessarily get folks in a quick enough window of time, to answers, before they forget about the question: you could have power editors spend all day asking quesitons, with very few positive outcomes as a response of those questions.
Chat is a brilliant idea. Put it in the left sidebar column at the very top. New editors need rapid feedback. People are familiar with chat from many other sites.
We would need a running list of unanswered questions showing up somewhere that anybody could answer. The original poster will have the right to send their thread back to the unanswered page, or to a page "requesting more answers".
Replies would show up in the left sidebar of any page that the questioner has open. Just like Facebook chat follows you around when someone replies.
I think a chat (IRC?) inside Wikipedia is a great idea and would be very useful, especially for languages where the IRC activity is very low (or they died out). I would love to test it in the future.
I like the idea of helping new users to ask questions easily. It should not annoy experienced users though, so maybe it could be an opt-out feature if possible or otherwise not get in the way for those who don't need it. If it would be possible to make multiple options, there could be an option to post the question to the article's talk page or to a general discussion page that the community can choose/create for this purpose.
I don't know how the chat would work so I don't know what to think about it. Would the chat discussion remain visible to everyone so others can learn from the answers and also see that the advice was correct? I don't like the idea of a private chat between two users, everything should be public for many reasons.
I like the chat solution up to a point, but I have to admit that the problem "They have to leave the page to go to the Help Desk, IRC, or some other talk page." is misdiagnosed. New users don't know there is a Help desk, are probably not in the 0.0001% of the planet who happen to use IRC, or what another appropriate page might be. They *may* find out about some of those things from a welcome message (but welcome messages seem somewhat random as to who writes them and what information they provide and whether you get one at all). And even if you get given a link to (say) the Teahouse, when you get there, you need to be able to source edit to even ask your question and it is not obvious how you will receive a reply. So bad luck for the VE users. The important thing to understand about new users is that they don't how how to do the things we take for granted nor use vocabulary that is Wikipedia jargon.
One thing with the chat. I like the idea that the window would stay open as they move to other articles, so an answer could come later. However, let's say I am doing an early edit and I've added some content and I'm trying to figure how to cite it and can't work it out. OK, I see the friendly "Click here to get help via chat" button and click it, write my message, and then what? Should there half-done edit be saved? (Risk is that it be deleted if there is no source) Should they move away leaving the edit session incomplete as they await a reply? (Risk is that they will end up in an edit conflict). Or should they just abandon the work already done while they await a reply. (Risk is they won't come back). Also as someone who does training, I have learned that some users do not know about browser tabs and spend their life in a single browser window (which makes writing Wikipedia fairly challenging for them as they cannot have a webpage source open at the same time as the Wikipedia article), so these people will either save or abandon as moving to another browser tab isn't an option they know about. Like I say above, new users are NOT like us so we need to build tools that work for them rather than work for us.
The chat window might act as temporary storage if they log in. "Log in to chat" and "Send email to get help" should be at the top of every page, or sidebar. No need to sign in to get help by email.
It sounds good. We are facing this problem in arwiki, that most of new users want to ask questions like (how to do...? or what this error mean...? etc) and as @Stryn mentioned that many new users don't know that they can discuss about subject on talk page, in addition I think most of new users didn't know that they can communicate with other users.
I notice this problem every day, for example I found many new users wrote questions in wrong pages, also now I'm helping in offline event (via Facebook) to write articles about nutrition, almost all participants are new users, and they are highly motivated, but when they faced any problem in Wikipedia like (can't to add templates, or abusefilters stop them, fairuser image...etc), so they send all questions directly in the Facebook chat group and I helped them as fast as I can (either by told them how to do that, or do it by myself), but here I talked about a group of new users related to certain event, so I don't think we can apply this thing in all new users.
Also, unfortunately I'm the only one who online in arwiki IRC channel, so I faced every week two or three new users enter arwiki IRC and asked questions about problem they faced, then I decided that I should encouraged other experienced users to enter and stay on arwiki channel, but no one interested due to weak technical documentation of IRC and who to have a m:Cloak ..etc.
I think if we can develop the IRC channels, make very well technical documentation, provide experienced users who can help if there's any technical problem, recommend apps/programs for IRC (the old IRC interface not good and repellent for users).
The IRC channels well be very helpful, so after develop it, we can put link at the page header (beside talk/Preferences ..etc), or make a prominent small banner. (I don't know if it a good idea, but I think why not to make one IRC channel for all new users, because any experienced user in Wikipedia can almost answer any question, so one IRC channel and asked experienced users from different languages to stay in it. For example, if a user from dewiki asked me how to add interwikilink for his/her article, or who to add template ..etc, although I do not understand the German language but as experienced user I can help him, because it's almost the same in all wikis).
umm I wrote a lot, so I should stop now 
At Republic Wireless help they have a quick question system that works very well, and very fast. You do not have to log in. At the bottom of that help page click on "Message Now".
"Member Advice. Have a quick question? Message an expert member (another customer with proven expertise) in real time for answers you can trust! Response time: typically under 3 minutes, may vary overnight."
No need to log in. That is the best part. Instant gratification, or near instant. A popup form asks for your question and email address. Send it. The popup box stays up and it says "We're notifying our top experts. If you leave, we’ll notify you as soon as you get an answer." So if the page stays up you get a message there. And you get an email answer too. I got an email in a few minutes. Relevant part said:
wvfisher is typing an answer right now for your question "This is a test of the form.". Feel free to visit your conversation with wvfisher at any time by opening the link below. wvfisher said: "thanks..."
View Answer
The "View Answer" link takes one back to the page, and reopens the popup form with the question and answer. When someone does show up, they stick around and ask if you have further questions.
As much as I'd like to have live help via chat, there are three significant challenges that I foresee.
First, if we make chat more widely available, there will likely be more spamming, forum shopping of requests that go against policies, and hostility those channels, so moderation of these channels will be important.
Second, I don't know that the existing population of volunteers who provide help with editing and who moderate IRC channels have adequate capacity to handle a flood of new requests for individualized help, so I suggest that the availability of chat be increased gradually and in proportion to the demonstrated willingness of knowledgeable volunteers to support and moderate the chat communications.
Third, I am concerned that we are in a zero-sum game with knowledgeable volunteers in the sense that there are already too few of us and if we get pulled into help newbies then we are not doing other potentially valuable activities. If WMF wants to move forward with live online chat help, then I would encourage WMF and the affiliates to consider spending grant money on live online support staff, which I strongly believe should be employed by the affiliates rather than by WMF.
I wish that I could be more supportive of this proposal, but the human resource considerations are important and I think that they would need to be addressed as a part of the otherwise good idea to offer more easily accessible live chat support.
This is a valueble idea. The only pitfall (and a big one) is getting the experienced editors to participate. As it is we are spread too thin trying to get all the bases covered. I could do the support when I am online but at the expense of other projects. I dare say that many times the chatbox would be empty of support staff. The IRC mentioned above worked mostly as a space for already experienced users to talk rather than for newbies. I have not used it for quite some time since it requires another log-in, more multitasking etc. Another possible venue is Facebook but I would discourage its use since it is, for me, mostly a time-waster and another multitasking tool. So an interface on actual Wikipedia does seem like the best solution save for the staffing requirements.
Integrating an IRC 'client' would be a possible way.
I think people are making this way too complicated. If I see a lit button in the sidebar I know there are unanswered questions in the chat roll of unanswered questions.
In my preferences I have the box checked to have that lit button in my sidebar. Problem solved.
Thank you all for weighing in on this "In-context questions or chat" idea. Our team discussed all the feedback, and I've summarized here what we heard on this page and in other venues. The team is now figuring out whether to pursue this idea, and we'll be back to discuss more if we decide to work on it (please sign up for our newsletter to get updates on our plans).
The biggest takeaway for our team from this conversation is that whatever sort of help we build, whether it's chat or lessons or something else, it needs to be prominent and easy for new editors to find while they edit. We'll keep that in mind. Also, @Bencemac's idea of integrating an IRC client to try this out in a minimal is definitely interesting.
One question I have for the group is about what kinds of activity you see in IRC channels around helping new editors. Do they ask good questions? Get good answers? Have trouble using IRC? Pinging @علاء, @Bencemac, @Jetam2, and anyone else who has spent time in IRC.
I have good experiences with English channels even thought I am not a new editor, which means if I ask help, my problem is always more complicated than the others. There are always active editors (+administrators) and they are helpful as well. My only fear is that some languages do not have the enough IRC community for this, although an integrated client probably could encourage old editors to join as well.
Barely any activity on IRC (as of now). The number of conversations on IRC can be counted with the fingers of a hand.
Please reply here to discuss the "New editors suggest edits (3)" idea.
The only initial difference between these two approaches is in the wording of how is implemented. If it is Suggest vs. Publish, they are editing. If it is Suggest an Edit or Suggest a Change, they are commenting. I don't know which of these would be better, but something to consider.
Asking an user to 'propose' changes will simply make things scary; the user may think "what if it is refused...?" and hesitate to make the edit. Conversely, Wikibooks' approach makes this transparent to the user, who'll edit as if this 'verification' never existed.
I think we need to tease this problem apart into two separate pieces. The first part addresses the new user who doesnt know HOW to edit, so giving them a free text (just type) window to ask for a change to the article and funnelling that onto the article's Talk page seems an OK solution to that problem. Anything that involves them knowing anything about HOW to edit (or where to find the Talk page etc) must not be required as part of the solution. The problem with the first piece is whether there is anyone willing and able who is watching that article who will take any action on the proposed change. The second part of the problem is whether the proposed change is accceptable in the opinion of the person who is considering implementing it. And my watchlist shows me that many first edits are vandalism (both obvious and subtle), change facts without adding/changing citation, and add inappropriate content (opinions, chatty, spammy) or delete cited information (often whitewashing) and most won't have an edit summary or else it's an unhelpful one ("I changed some details"). And then there is copyvio, need for citation, etc. Now it is easy to deal with new user edits that are obviously bad faith (undo!) but harder to deal with the ones that may (assuming good faith) be genuine. In the absence of a citation, I have to search to see if I can find a source. If I can't find a source, I have to go back and ask them (via the Talk page that I know that they probably aren't reading) if they can tell me what the source is. Or why they think that information should be deleted? So either we use the same chat mechanism (already described for getting help) to allow for suggestions to be made and discussed.Or we make the suggested change more of a wizard that starts with "What do you want to suggest?"
- Fix a simple presentation mistake like spelling, grammar
- Change some information that is wrong or misleading
- Add some new information not already in the article
- Delete some information from the article
- Etc
and then leads to a series of different forms. The simple fix could be 3 boxes (existing words, proposed words, rationale). The rational could be optional here as it may be obvious "Theer" -> "There". The other forms would need more rationale and in some cases a separate box for a source (which mightl ead to a cite-manual option and interrogate for the minimal details for a web citation, book citation, etc so that the implementing user can be presented with a ready-to-go-citation to ease their implementation effort.). Now you might think "surely this is more work for the new user than just editing it in the first place" and, indeed for an experienced user, it is more work, but for the new user, it's not, partly because they don't know how to edit (or lack confidence) i and partly because this dialogue starts with their *intention* which the normal editor tool bars do not and gathers the necessary information relating to their intentions which is often needed to understand the appropriateness of the proposed edit (and is normally lacking with post-edit watchlist reviewing). An in-between step is to make edit summaries mandatory and structured into a dialogue.
In arwiki any edit should reviewed by editor before published (Pending changes system) + flagged revisions system.
It's very good and encouraged users to publish there edits without any afraid, but the problem that we have, there's a huge accumulation in pending changes log, and few editors working in it.
And "we try" to send notes in user page if we refused her/his edit(s), and in the same time, to send a notification if we accept the user edit (like here). Note that the notification system in Wikipedia, send a notification for you if your edit refused/rollbacked, but not send if it accepted.
I think if we send a notification that "Thank you. Your edit(s) accepted! We look forward to reviewing your next edit" will encouraged users to make more and more edits without any afraid, and we should work to make this users know that if they did any wrong thing we can fix it.
The idea is interesting but a lot depends on how it is implemented. Suggestions in the form of a discussion text create unnecessary work for the reviewer and editor-to-be. An extra page would have to be checked and the original one actually saved. It could work better if the suggestions are real edits that are somehow temporary until reviewed and deemed worthy and permanent. But this is not that different from the present reality: edits are real and visible unless someone watching recent changes corrects/reverts them. In either case, optionality is a good step.
Thank you all for weighing in on this "New editors suggest edits" idea. Our team discussed all the feedback, and I've summarized it here. We're now figuring out whether to pursue this idea, and we'll be back to discuss more if we decide to work on it (please sign up for our newsletter to get updates on our plans).
Our team really liked @Kerry Raymond's idea of a structured workflow or form that a new editor could use to suggest an edit productively, especially because it could strongly encourage them to add a source. Such a workflow could be a good way for experienced editors to find good-faith contributors who just need help with the technology.
I wanted to ask a follow-up question to @Kerry Raymond and to whomever else has an opinion: do you find many new editors who are afraid to be bold and edit? In other words, in your experience, how much does the problem here actually exist?
I see new users in real-life in two different situations, one is edit training, the other is edit-a-thon events. The behaviour tends to be different.
People who go to edit training seem to fall into 2 groups, the tried-but-failed and the not-bold. The tried-but-failed have tried to edit in the past on their own and failed (for technological reasons, got reverted, got a nasty message) and gave up and now think that with some training they might be able to have another go at it. These people are clearly keen to edit. The not-bold are people who think they might like to edit Wikipedia and would never reach out and click that Edit button on their own; they lack confidence in some aspect of the task whether it be not confident with IT, not confident that they are an "authority/expert", not really sure that "people like me" are allowed to contribute. I note that the main page may say "the encyclopedia that anyone can edit" but these folks either haven't seen it or have seen it but misunderstood it. The problem is that many people think of "edit" as like the "editor of a newspaper", not as a contributor/reporter (to use the newspaper analogy). For this reason, when I run edit training, I try to get it advertised as "learn to *contribute* to Wikipedia" because the "edit" word is misunderstood and then in the edit training session, I try to explain the nonemclature so they know what we mean by "edit" and "editor". So yes there are a lot who are not bold or or have been bold and failed and are not bold anymore. So these folks are generally wanting to contribute but feel they need to be shown how first.
The majority of people who attend my edit training sesions are either librarians (who tend to take to Wikipedia editing fairly easily -- being IT literate and understand citation) or the general public. Both groups are predominantly female. General public groups are typically older people, often retired. A few of the older people may have low IT skills although they self-assess as competent (they tend to be able to handle email, Facebook, web browsing, uploading photos from their camera or phone, but lack experience in producing content which would give them skills like copy-and-paste, having multiple tabs open in a browser at one time, knowing what a URL is and where to find it on your screen). A problem with some older people relates to the more limited education they would have had in the time they grew up, and they tend to regard "what an expert once told them" as authoritative rather than grasp the need for citations. "My grandfather was a pioneer in the Great Dry Plains district and he said that ..." is a "fact" for them, so we get some reliable source problems with this deference to "experts talking" over published sources.
At edit-a-thons, you see a much more confident group. Most edit-a-thons I experience are about the gender gap, and mostly women (and some men) who come along are motivated to close the gender gap rather than to become regular contributors to Wikipedia. They tend to be younger or middle-aged, university-educated professional women (often academics, university students, scientists as universities often run such events). They are confident with IT and mostly comfortable with writing and citing. They have been told they will be briefly taught how to edit as part of the event and they assume they will pick it up rather easily (and indeed they do). Many will jump in and be bold at the event even without any training. So this group tends towards boldness but motivated by the gender gap and probably do not intend to contribute after the event ("too busy"). Their main problem is that they will violate copyright on university websites because "the university won't mind" (which is probably true, but not a reason Wikipedia accepts without some OTRS process) .
So the not-bold are definitely out there. As are the not-aware and those who don't realise that clicking the "Edit" button allows you to change Wikipedia. Also Visual Editor is not the default so I suspect many who do click Edit, get shown the markup, and don't proceed because it looks like incomprehensible to them. I believe someone has some stats on what proportion of the clicks on Edit but never result in a Save. One assumes a fair number of these aborted edits by new users are "OMG it's all too hard" reactions, so fall into my bold-but-failed category.
Illiterate editors are excluded from the wikis, a major systemic bias. Illiterate people can listen to wiki content through voice synthesis, and find it with voice commands, but editing is harder. Suggested-edits which consisted of sound recordings or voice-recognition-generated text (for smaller data transfers and storage space) could let them contribute; a literate contributor could then polish their edit, source, and insert it. As a halfway step, a user interface for voice-input edits to talk pages might be helpful. The interface could also be used to let people using Wikipedia through voice assistant chatbots (Mycroft, Alexa, OK Google) contribute. HLHJ (talk) 20:25, 11 November 2018 (UTC)
Thanks, @HLHJ. We hadn't thought about illiterate editors before. We'll keep that in mind as we continue our work.
Please reply here for general discussion about these ideas, or create new topics as needed!
Here are some new ideas that you may consider:
- Reminder email: sometimes user registers and do only 1, 2 or 3 modifications on Wikipedia. Then, they left the website and never come back... What if we send a reminder email stating "You haven't edited Wikipedia since 1 month, here is a list of things to do... (...) If you have any question, do not hesitate to contact us...". We can also imagine proposing tasks based on the user interests (= has made several contributions about a movie, encourage to edit articles about cinema)
- Central notice for newcomers or IPs. Top of the website is the best place to advertise on Wikipedia and encourage people to start editing, to correct pages when they see a mistake...
Dear Growth team
I am wikipedian with 13 years experience.
I see you all are members of Wikimedia Foundation staff. So probably you have no any or may be a little experience whit middle sized Wikipedias. Yours significant point of view is that the most important barrier for new users are technical issue.
But the most important barrier is in my opinion the human factor. In the most middle sized Wikis today are a interverate bureaucracy (in the Hungarian wiki 24 admin from 29 are most as 7 year in office!) There are every thing hunted. One newcomer has no any chance make an edit fully adequate and will have some tick of (not rarely rude). The [[:en:Wikipedia:Be bold]] principle are long forgotten.
This is in Hungarian Wiki and probably the most middle sized wikis one cultural phenomena with historical roots. This countries are very susceptible for authoritarian leading. For one admin or bureaucrat every diverse meaning or diverse editing style should bee sanctioned. The most new editor after firs rude tick or sanction won’t edit more.
I know that the Foundation has no possibility take an effect how the local wikis are organized, but your effort with merely technical issues are a dead deal an [:en:White elephant]].
. ~~~~
Hello @Texaner, and thank you for sharing your thoughts.
Only people with a "(WMF)" suffix on their usernames are staff in our conversations.
As a volunteer, I'm a 10-years experienced Wikimedian, mostly active on French Wikipedia. I know, it is less time than you and my wiki is a bit bigger than the one where you're active on, but I can definitely say that I know your feeling. It was like that back in 2011, when the French Wikipedia community decided to change that and help newcomers through technical changes. The technical changes, through new pages and processes, have changed the bureaucracy.
We will indeed work on technical changes but I hope that would also promote social changes. Have you explored all 8 projects with your perspective? Have you read comments for each of them?
Hi Trizek
I have read all 8 projects but this projects are for me irrelevant. I have made in the last 10 years in high schools, association a lot of presentation and workshops about the Wikipedia editing. Also I have 4 years long a course about the Wikipedia for linguistic student at the Eötvös Loránd University. Naturally there was enough time to introduce the technical knowledge, because today the use some text editor is part of schoolwork. On the far side get to know the limitless, mostly stupid and void of sense editing rules in this short time was impossible therefor for new users my rule of thumb was: take a good article and use his buildup.
My experience was: that about 90 percent of participant have written his/her first article and no more. About 10 percent have written about 3-4 article and then have left the Wikipedia. Longtime wikipedian are today very few of them. I am reviewer on the Hungarian Wiki, I have ask the new editors gave a signal about her/his new edits so I have the opportunity follow they edits. I have got really no any complaint about technical problems, but even more about rude tick of’s.
With editors “from street” unfortunately I have no experience.
Thanks for the suggestions, @Arthur Crbz. It's a good point about the "reminder emails". The way our team has been thinking about it lately is as an expansion of the "Email new editors their impact" idea. Only a minority of new editors even make an edit, so we can only email a minority about their impact. But there is still an opportunity to email some encouragement, suggestions, or reminders to the rest of them.
And we think that using CentralNotice is potentially a great idea! It could definitely be good for directing new editors to the help desk or informing them about off-wiki events.
New editors need rapid feedback in one place. A global watchlist. Many new editors are multi-lingual, and will try their native language wikipedia, and often English Wikipedia since it covers far more topics of interest to them in many cases.
But once they see that they will have to check multiple watchlists, then many soon lose all interest. A global cross-wiki watchlist is a perennial top 5 request.
If you truly want feedback from more new editors, then create another project page like this on English Wikipedia if you haven't done so already. New editors will not stay here on MediaWiki.org long since there is little of interest here for new editors. At least on Wikipedia they are often already there trying it out.
New editors who try to edit with older computers will find Visual Editor to be too slow to load on longer articles.
+1. Even experienced editors find the lack of global watchlist to be an obstacle, and Timeshifter has a good point about non-English people being more likely to edit beyond a single language wiki.
Despite my best efforts to set my preferences, I can't get meta alerts to my main "en" account so I would love it too :-)
But the problem with new editors is more complicated than that. My experience from training is that the new editor is are so intently focussed on watching the edit window that they do not see notice or do not react to the presence of Talk message and other Alerts. Or when they do, they don't understand what it means or what to do in response. I hand out business cards with my email address when I do training and I know that I get a lot more follow up questions on email than on-wiki. Also it is a lot easier to email a screenshot of a problem in email than they can via Talk. Oh, and the new VE editor can easily write on Talk page.
So yes new editors need rapid feedback in one place, but I don't think our regular Talk/Alert system is necessarily the "one place" I would choose.
It is important to understand the Talk messages and alerts rely on the user being logged in. How do you communicate with the new user who isn't yet in the habit of being logged in all the time? We need to send an email as well (if their email address was provided) to get their attention.
The next problem the new user encounters is that, having seen a message on their UserTalk page, they may write a response there. Unfortunately the person who sent the original feedback (which may have been a bot) may not be watching for a reply. Seehttps://commons.wikimedia.org/wiki/User_talk:Rachwray this as an example, which resulted in the deletion of about 10 files, because the experienced user who believed it was a copyright violation wasn't watching for a reply (I had to sort it out and get the images restored, a conversation which was initiated via email). This also illustrates another problem new users face -- in this case, it was assumed a new user would "of course" be infringing copyright and did not bother to chck that material was indeed CC-BY as had been stated in the original upload (which indeed it was). A common assumption is "new user = bad user". And of course statistically this is often true, but if we want to retain the good faith ones, we have to stop that assumption.
@Kerry Raymond, have you set your cross-wiki notifications? If yes, please contact me on one of my talk pages.
Good idea. "Get help by email" should be at the top of every page on Wikipedia. That way new users can get help even if they are not logged in. Top of the page, or top of the sidebar.
I disagree, because private emails do not scale and do not help others.
The questions and replies should all be made public. Email notification is already done for other things.
Interesting idea about global watchlist's benefit for new editors, @Timeshifter. Right now, the team is thinking about how to help a new editor right after they register, and with their very first edits -- so I don't think their watchlist necessarily comes into play right away. But I could imagine this being important when our team turns attention to farther-along parts of the new editor's journey. Regarding the multi-lingual aspect, I'm wondering if you have any data or anecdotes about new editors trying to work across wikis. How common do you think it is?
This idea is making me think about a "new editor dashboard" concept -- all the things you need to be seeing if you're new, whether that is help documentation, watchlist-type content, or information about the impact of your edits.
And with respect to getting feedback on these ideas from new editors, I'm glad to say that we did this in Czech and Korean Wikipedias! Our ambassadors in those wikis sent emails to new editors to ask for their feedback, which I've incorporated into the summaries on this page. Many of the new editors responded with thoughts or questions unrelated to the ideas in the list, but in general we got some valuable info from them.
New editors, once logged in, automatically start putting things on their Wikipedia watchlist as they make edits. If I am remembering correctly, this is the default setting. "Watchlist" is at the top of the page, and so it is intuitive that many new editors check it out right away or soon because they want to get back to articles they were editing earlier.
If they do any experimenting with other wikimedia projects they are immediately discouraged (I was) by all the many watchlists. And finding the other projects again is not always easy. They are not on the sidebar of this page for example. So it is easy to give up (as most people do) with the other wikimedia projects. Except for maybe the Commons for those editors bold enough to try to put images in articles. It is easy to find the Commons by clicking on any image in a Wikipedia article. The other wikimedia projects are occasionally listed on the sidebar of some pages. No consistency, and easy to miss.
This is all GUI stuff, ease-of-use stuff. Neither one of my main watchlists (English Wikpedia and the Commons) links to other wikimedia projects.
A global cross-wiki watchlist would solve all these problems. Including getting more feedback here.
We plan to check if edited pages are automatically watchlisted for new users. It may be different from one wiki to another. (Plus the notion of a watchlist is not always well understood.)
Please reply here to discuss the "Email Notification Replies (8)" idea.
Strong
Just to remind you that queue permissions-commons has currently a 125 days backlog meaning you have to wait 4 months before to get an answer and files may be deleted during this period.
Absolutely agree with Arthur - OTRS is completely inappropriate. If a community wants to implement something like this [it would be a good idea, first, to get a count of the number of emails that actually do get sent to users; is this at all common?], they should get volunteers who would respond to the emails. Even if there are only a couple of volunteers, that would still mean that users would at least sometimes get responses to their emails, and it would help the community (and WMF) identify how the emails might be modified to encourage users not to respond directly to them, but perhaps to respond to a help email address.
What is appropriate place? I think info-* addresses are for questions, not for permissions or something else.
Agents answering permissions queues are the same that people answering info queues...
That still doesn't answer my question. If info-* queues are not appropriate place for questions, what IS the appropriate place? And BTW, not in all cases, I know about at least one agent who had access to info but did not have access to permissions.
Info- may be the appropriate place but only if we have sufficient ressources to handle these emails. If questions are posted directly on Wikipedia (on a newcomers forum for instance), it allows every Wikipedian to answer.
From my personal experience, info queue (at least info-fr) handles few requests from newbies. It's mainly about verifying identity, correcting information, legal threats...
And yes, some agents have access to only info or only permissions.
It would be more efficient to have an informative automated reply telling how to answer.
OTRS agent here. I think we could try this with small languages without huge backlog. I know and understand that big languages' agents (e.g. English, German, etc.) do not want more work, so I would suggest that firstly test this function with smaller ones; for example, Hungarian could be a possible tester.
@Bencemac, the scope of Growth team is on mid-sized wikis.
@Trizek (WMF)That is good, because Hungarian is one of them. :)
I worry a lot about OTRS -- in that it has become a barrier to participation for uploads to commons, because the permissions queue is constantly under backlog -- I would hate to see this system sucking power contributors out of communities, and creating yet another backlog for giving feedback, without radically improving the environment for doing it.
Well, let's agree OTRS isn't the right place. And get back to the idea itself.
Firstly, I am not at all sure why new users would be receiving their notifications by email. I do myself and it took my many years to find out how (maybe it wasn't always an option). From my experience of training new users, I don't think wandering around their Preferences and fiddling is typical new user behaviour, but maybe organic new users are different in their behaviour.
Having said that, I am absolutely 100% in favour of new users receiving their notifications via email (where email address was provided). It is by far the easiest way for them to ask questions, and get answers, as it is familiar to them and it is so much easier to include screen shots. For Visual Editor users, not having Talk enabled for VE is a barrier. But you can do your bit to solving the problem. On English Wikipedia, add the template VEFriendly to the top of your User Talk page to help VE users talk to you. Is there any way to add that template automatically to new user's User Talk pages if they are using VE? It seems ridiculous that they are restricted in writing on their own User Talk page.
In cs.wiki, all new users automatically have all pages they edited in their watchlist (well, they can disable it in their preferences or one by one while saving page, but that's not typical, as you said). Therefore, they receive watchlist notifications.
Also, IIRC notifications like "new message on your talkpage" are being sent by email by default. Yes, you can disable it, but again, that's not typical.
VE is not supposed to help with editing discussions. It have not that purpose and I don't think it would be enabled on any talk page namespace. It seems it is possible right now (by inserting the template) but it can stop working at any time without notice, but it is using wrong tool for accomplishing that purpose.
BTW, why isn't OTRS the right place? Yeah, I agree the permissions-commons queue has big backlog and that we should not _create_ other backlog. But info queues already exists and should be reviewed. And althrough it might not be typical for queues, but info-cs/permission-cs queues reply to most emails within 24 hours.
I like this idea, and for mid-size wikis almost the OTRS log is not very heavy.
(I'm OTRS member for several queues.)
I do not think adding to the email duties of experienced users would be a good idea. It shifts communication to more channels and who would respond? Do we have the people-hours? I doubt it. Perhaps the emails could just indicate where the new users should respond on-wiki?
Thank you all for weighing in on this "Email Notification Replies" idea. Our team discussed all the feedback, and I've summarized it here. We're now figuring out whether to pursue this idea, and we'll be back to discuss more if we decide to work on it (please sign up for our newsletter to get updates on our plans).
Our team really liked the idea discussed by many of you (@John Broughton, @Pere prlpz, @Jetam2) of simply improving the emails themselves to make it more clear to the recipient how they can respond on wiki. That's certainly a lighter-weight solution to the problem.
This conversation brought up the question of whether new editors should have more email notifications on by default. Thanks to @Kerry Raymond and @Martin Urbanec for bringing this up. What do you all think? Should new editors have default settings that send them more email, in the hopes that it engages them further in the wiki, especially while on-wiki notification systems might be harder for them to understand?
Just in terms of the summary, I think there is an unquestioned assumption that new uses *are* receiving email notifications. I don't think it is on en.WP; I think you have to choose it in your Preferences. And I have no idea what happens on other language Wikipedias. I note that one of the problems I have as a trainer is that I cannot see exactly what new users experience. I do have a separate "vanilla" account for preparing presentation so my screenshots aren't full of my normal gadgets and preferences, but that's not a *new* user account to experience what happens to new users. The only way I can get that experience is by constantly creating a new user account before each session (which almost certainly is not a desirable thing for me as I can see people might see it as setting up a sockpuppet army). Things are always popping up on the screen of my trainees that I am not expecting as a consequence of my inability to anticipate the new user experience. Certainly I cannot be certain on any current default preference settings.
By default, when you have email enabled, you get emails for these kinds of events and these. (Tested from Revi (WMF) account which I didn't change from the default value) We are talking about emails sent here.
The ratio of new users who setup email address during signup/after signup - is the question we've got to question (but this is already noted as "We are not sure how often this occurs").
We will check the default settings for the different wikis we plan to work on.
Due to lack of mechanisms for true collaboration growth is incredibly hard for even third party wikis. Below are some encountered issues.
Concrete problems:
- Assumption 1 -> anyone can create an article on their first try. This is a very core wiki principle and flaw. Nobody can produce a good page in whatever medium (be it a book or letter or whatever) on their very first try. Yet the interface persuades a user to do this, relying on the principle that it will be improved overtime. Except that sometimes before one even gets that chance the article may be deleted. Wasted work...
- Assumption 2 - Just because a non-existent page is reached it should be created - page creation workflow is non-existent as far as default mediawiki is concerned. Consider this, the link to improve or create pages is called ?action=edit. The only way to reach said link is either by knowing it, or reaching it accidentally.
- Assumption 3 - As long as it has content , anything created in the main namespace is deemed a page. One can create a page with a single character, a word, gibberish ("aszxdcareqweqdas"). No sensible restrictions on what can be saved as a page.
- Before the advent of internet, an application would be basically awful and poor quality if it didn't have built-in documentation. Nowadays, interfaces are designed to assume that users are mind-readers. They simply choose the lazy way of sending the user to a separate internet page that may contain help. For wikis, this is worse, one can reach a "documentation" page that has been vandalized and be even more confused.
- There is much duplication of effort - the simple fact of the matter is that volunteers are inherently unreliable. This means that they can work in haphazard ways, and can individually (un)knowingly disrupt each others work, or agree to do something but not do it. This is made worse by the fact that there is no way to get an overview of what processes, pages, or places need most help. In some cases this leads to decline rather than growth.
Some possible solutions:
- Basic tutorial - it would be easy to either guide the user through a compulsory basic tutorial, and perhaps a sort of micro-quiz before starting to edit. While this could discourage many, the ones that remain may actually produce better content. An alternative is a personal draft ( created with the help of the tutorial) invisible to others until the user publishes it. The draft would be automatically deleted if not published within a week or so, maybe after a copy is emailed to the author.
- Entry point for creating a page - One possibility is that redlinks on search pages only appear after considerable users search for the same keyword. The most important issue to solve here is the creation of a sensible entry point for creating a page (not search or 404). See how wikia for instance created it : community.wikia.com . A more wikimedia-centric approach was discussed here Article Creation Workflow/Design , https://phabricator.wikimedia.org/T29311).
- Definition of a content page - Some basic mechanisms or restrictions for creating a page should be introduced, e.g. minimum character count, minimum number or links, a reference or a heading or whatever. Content consisting of one character or word is not a page, it is a scribble. Mediawiki even allow(ed?) pages with no content.
- Online help / in-context help - Help for most frequently used dialogs, and even a general description of the interface itself, along with a glossary and definitions of terms used by it. Visualeditor has some basic help. Wikitext editor focuses on wikitext, and doesn't provide any help for many of its dialogs or even describe what some terms mean.
- General Queue -This will not likely be achieved by this team. It simply requires a general Queue, e.g. What articles are reasonable, what articles need more work, which have low coverage, which could benefit from simple fixes and are good for beginners, etc. The reliance on categories for this kind of thing is purely misguided. Currently, editors fly blind, randomly improving things without a sense of progress and sometimes duplicating work or reverting someone else's efforts. See https://phabricator.wikimedia.org/T120742, https://phabricator.wikimedia.org/T91655.
Thank you for posting these thoughts. "Assumption 1" is a good point about how many new editors struggle when creating new articles right away, and end up being demoralized. Our team talked about this last week when we discussed some of our most important long-term questions. One of them is: "How do we help new editors find a place in the wiki that fits their interests, fits their skillset, and fits the wiki's needs?"
With respect to the "Basic tutorial" idea, I think many wikis have something like this, such as the Wikipedia Adventure in English Wikipedia. There is a lot of thinking and improvement that could go into tutorials like those.
And with respect to the "General Queue" idea, task recommendations is definitely on our team's radar. We will probably revisit thinking about that in a few months.
The wikipedia adventure isn't really a good tutorial because it separates the user from normal editing and isn't integrated into editors. Consider this, many applications have tutorials, but the best ones are so well integrated that some users never realize they even went through a tutorial.
> "How do we help new editors find a place in the wiki that fits their interests, fits their skillset, and fits the wiki's needs?"
This question reminds me of old computer games that would not let the user play unless they answered specific questions to ensure they were "old" enough. That's unfortunately the only way to really assess editing competency and interest, but it is an answer that editors will not like. Generally speaking that question can't be answered due to how incredibly disorganized wikis are.
A book written by 1000 volunteer authors is very likely to become very incoherent, just like wikis are. The best solution to that is doing some research with professionals and coming up with a sensible list of topics (probably less than 2000 pages) that MUST be covered in every wiki, along with a dashboard to see how well a wiki fares. This wouldn't be applicable to places like wikinews and wikisource that might need different approaches. Consider this, wikimedia's wikis have existed for more than a decade, but can anyone really answer how well and accurately topics related to basic needs and survival are covered (e.g. water, hygiene, food and shelter)?
Old printed encyclopedias had their flaws, but the need to have a limited amount of books meant that they at least attempted to properly cover what they deemed to be the most important topics ( and / or the most lucrative).
doing some research with professionals and coming up with a sensible list of topics (probably less than 2000 pages) that MUST be covered in every wiki
We already have lists resembling that.
- One list is tailored to the English-language Wikipedia, see EN:WP:Vital articles. It contains a most important 10 topics, top 100 topics, top 1,000 topics, top 10,000 topics, and the entire list extends to 50,000 topics.
- At Meta we have M:List of articles every Wikipedia should have. This list contains 1,000 entries. It is intended to be global in scope.
Note: I'm not claiming either of those lists are perfect. I'm just pointing out that we already have them, and they're probably in the ballpark of 'reasonable' or 'useful' considering the inherent difficulties of such a list.
This is potentially high-impact and low-effort.
Visual Editor was built with the intent to make editing easier for new users, to bring in more people as contributors, and to increase new user retention. Single Edit Tab has been developed and deployed to some wikis, providing a configurable option for which editor is given as the default first-editor when new users click the one-and-only edit link. Some wikis are configured to provide Visual Editor as the initial default, and some wikis are configured to provide wikitext as the initial default. Progress on this has stalled, due to controversy and lack of hard data on which editing environment produces the best outcomes.
I propose gathering the required data. A sample population should be divided in to two equal groups, with the only difference being the initial default value for primary editor. When they first click the EDIT link, half will initially load Visual Editor and half will initially load the wikitext editor. After that point, new users might or might not discover and use the opposite editor on their own. I propose compiling at least three metrics, preferably over a period of at least six months to evaluate long term outcomes.
- A graph of total number edits from each group over time.
- A graph of user retention for each group. If a user creates an account at time T, how many of them are retained and make at least one edit at time > T+x?
- A graph of users actively switching away from the assigned default editor. For each group, consider all edits up to time x. What percentage of edits up to time x are made with the non-default editor?
- When we talk about "new users", how do we intend to identify them? I am pretty diligent with my watchlist, and so I see a lot of edits from "new" user accounts and new IPs that exhibit a level of editing skill and knowledge of policies etc that suggests to me they are not in fact "new" (I run training classes so I see genuine new user edits all the time). So you need to distinguish between new account and new to Wikipedia editing as these are not the same thing. Existing users with a new account are likely to be already skilled in one editor (probably the source editor) and they are therefore likely to switch to their preferred editor if given the other. So gathering statistics from such folk will not give you good data. You really want "truly new" users for this experiment.
- As for the metrics, what evidence is there that number of edits in VE should be the same as the number of edits in source editor to do the same task. In VE you always edit the whole article but in source editor, you can edit individual sections, so if someone is making a couple of changes to an article, they might do it in one edit in VE and two edits in source. Also in source editing, it is easy for the newbie to break the syntax in ways not really possible in the VE, so a newbie who saves a breaking-syntax edit may then come back for a 2nd edit to fix it (and a 3rd and a 4th if they don't how to fix it) which doesn't occur in the VE. ALso in the VE, if you do something wrong, you will see the error in front of you most of the time and so you will fix it before Saving. Different tools lead to different user behaviours and hence different numbers of edits.
Also, you might want to talk to @Halfak (WMF) as he has done a similar experiment as he may have some useful advice. ~~~~
@Alsee -- thanks for weighing in and thinking about this. I think it's always good to get more data, and your comments made me go back and review what we know about Visual Editor. In addition to the study that @Kerry Raymond mentioned, I also found a presentation from the monthly activities meeting from March of this year discussing edit success rates with different editors. While that doesn't answer all questions, I wanted to make sure you had seen it.
Though the editing experience itself probably has an important impact on newcomer retention, our team is focusing on helping newcomers learn what they need to know to be successful, regardless of which editor they are using. We learned from the New Editors Experiences research that newcomers struggle with many things: technology, wiki concepts, and wiki culture. Our team's mission is to help newcomers to be productive no matter what technology is in place in the wikis now or in the future. They will always have questions or confusion, and we want them to have avenues to get answers. That's why we'll be focusing on features that allow them to ask questions, discover how the wiki works, and learn as they go along. I hope this makes sense in terms of our team's mission.
I've watched the presentation, and it only confirms how badly we need this research to be done.
To quote the rigorous controlled study May 2015 study#Edit completion rates: the rate at which editors attempted and successfully saved edits was significantly lower when VE was enabled. Look at how much lower all the figures are for VE:
| users | intra-edit sessions | "visualeditor" (prop) | attempted save (prop) | successful save (prop) | |
|---|---|---|---|---|---|
| control
(Wikitext as the only available editor) |
3421 | 4677 | 51 (0.011) | 3204 (0.685) | 2977 (0.637) |
| experimental
(Primary Edit link set to VE, wikitext offered on second link) |
3471 | 4245 | 2396 (0.564) | 2669 (0.629) | 2449 (0.577) |
The biggest problem here is the presentation is selectively citing irrelevant figures. Our goal is to help more people to contribute, and for them to stay and contribute more. It doesn't actually matter what the 'successful save rate' is, we care if people are actually staying to make edits.
The second problem is that the presentation is claiming the opposite as the controlled study. The presentation is citing junk data. We know why it's junk data. It is a common part of learning and workflow in wikitext to open additional tabs to view or copy wikitext. That presentation is improperly counting wikitext-viewing and wikitext-copying as if it were an editing failure. That's clearly wrong.
The mission of the growth team is: Growth. To quote the objective: engaging new contributors in Wikimedia projects... The Growth Team's objective is to address this problem through software changes that help retain new contributors." While the team had certain projects in mind, there's an explicit call here for additional ideas. And the the various software changes relating to the editor(s) clearly has an important and direct impact on new contributors. This research is in-scope for the team, if management decides that it is in-scope.
I'd would say that while the technology can be an initial barrier to entry, but I know from doing training that you can get people over that hurdle with the VE (some people never reach competency using source editing). However, once the basic technology skill is acquired, the next thing that happens to a new user is that they fall foul of one of our many policies including the Manual of Style, encounter an "owner'/"gatekeeper" who implements their own" I-don't-like-it " policy, or any of the zillion rules of the encyclopedia whose 5th pillar is "no firm rules" (talk about misleading advertiing!). Their edit gets reverted, the explanation is often done by a tool (like Twinkle) so is quite non-specific, or if hand-written contains mention of (or links to) one of our vast army of policies which are probably not written with the new user as the target readership. The new user really needs more specific and more explanatory help.
Now, as someone who is diligent with my watchlist, I feel this tension myself in dealing with problematic but probably good faith edits by new users. I do try to help by being more fullsome in my explanation of the revert or by trying to modify their edit to make it conformant, but sometimes I just don't have the time to do that due to other demands on me from either other Wikimedia activities or the demands of real life. The other constraint on doing a better job of helping newbies is technological. When I am away from home, I usually am on a mobile device from which I can process my watchlist, but the only actions I can easily take are the click-the-button actions like "revert, tick box for reason" or "thanks" or "welcome". I don't have the ability to edit on a mobile device which providing good assistance to a newbie requires. When real life causes me to be away from home for days or weeks on end, I just have to do revert the more problematic edits and move on. So even as someone who tries to reach out and help new people, I just can't always do what I think needs to be done, and of course a lot of people just don't even try to help in the first place. Many editors will revert an edit without explanation or if they do write something on the User Talk page (with a tool or manually), many don't appear to watch that page for a reply. So a combination of our strict rules and abrasive culture loses us a lot of new contributors at this point
I think the revert of a new contributor needs to be drawn to the attention of someone other than the reverting editor as this is obviously a point at which we are likely to lose the new contributor if they are not helped over this hurdle. (I am not referring here to outright vandalism but anything that appears may be good faith). Having observed new contributors in training and events, I know they do not always notice notifications/messages from the tool bar; their attention is very focussed on the article text area of the screen. So, if they make an edit, it's get very quickly reverted, they often don't realise what has happened. What happens is that they don't see their change in their article and so they assume that they didn't make their change correctly (from a technological perspective) so go back into edit mode and repeat their edit (or a minor variation of it) and save it again. And they will do it again and again, and they are quickly at 3RR without even realising anyone was objecting to their edit. Of course the reverting editors don't see the situation like that, they see the persistent repetition of an edit that has been explained is unacceptable one, twice or thrice as defiance and are happy to see them blocked. New user behaviour is easily misinterpreted because most people never get to observe new users in real life to see how they misunderstand/misinterpret the whole experience.
Please reply here to discuss the "In-context lessons (2)" idea.
Can we get data about existing boxes on the Visual Editor ?
See Talk:In-context help and onboarding for a wide-ranging discussion of in-context help. I remain firmly convinced that pop-up boxes (summoned by the user, say by clicking on an circled "i" [information] icon next to a menu choice is the best way to go, here (that, of course, doesn't have to be the only way), with the pop-up box having links that lead the user - if he/she wants to follow them - to more detailed help pages.
As someone who has worked extensively on the VisualEditor user guide, I'd be happy to help create a couple of "model" pop-ups, which might include modifying the existing dialogs that are already in VE (these were added by a programmer, without any community input, so the language is not optimal for beginners; more importantly, they lack links).
This is a really important solution, and I think developing these kinds of "hands off" lessons will be much more scalable for small wikis, than trying to feed more folks into conversation spaces.
For what it's worth, the project for which I am currently requesting funding may be of significant help here. The in-context help could refer users to the videos and other materials that I am planning to create and curate. Although my first audience will be English Wikipedia, I am strongly hoping for there to be translations of the video subtitles. I could translate some of the subtitles myself into Spanish. I would welcome collaboration with translators and the WMF Growth Team to maximize the impact of this project.
I am definitely in favour of this. I particulary agree with John Broughton's suggestion on clicking on the i-icon in a menu choice to create a pop-up. It would be nice if the pop-up could be postioned (or moveable by the user) so the user can see both the pop-up and whatever they are working on at the same time, rather than having to close the pop-up forcing you to remember what it told you to do. I think short pop-up help with a link to a more fullsome help is a good balance.
It sound good, but we should not forget that also some new users not favor (visual editing) and like to use (source editing) -I know many new users when I directing them to the source editing, they like it more than the visual one-.
Probably we can make videos like (How to write an article?, How to edit Wikipedia?, How to put a picture in article?) and share it under CC in youtube channel (and/or in page for new editors in Wikipedia, "page only include videos"), and we can make small/medium/long videos for every thing in wikipedia editing even "how to make word bold in wikipedia?", and if we use simple generic titles for this videos it'll help very much.
I talked from my experience in creating videos about new tools in arwiki. Almost for every new tool in arwiki, we make documentation page contains words and video (Usually one me make it) how to use this tool. For example, Rater tool page in arwiki.
As we now, that all new editors if they faced any problem or can't do anything, they try to search about it via search engines and if they found video that help them, they will open it immediately.
The most important thing that who to select attractive titles and use the keywords.
If we take a look here (for example), we'll found many videos with more than 100K views, or here videos with more than 50K about who to delete Wikipedia article, or [how to add photo on wikipedia article here] videos with more than 50K about about how to add photos on Wikipeda articles.
The new worlds like to see not to read, and to learn by videos is very popular now.
Thanks for the comments, User:علاء. I hope to offer help for the Wikitext 2017 editor in my video project. I would appreciate your comments on Meta:Grants:Project/Rapid/Pine/Continuation_of_educational_video_and_website_project, if you have the time to provide any on the talk page. Thank you very much.
Not a bad idea, imho as long as the amount of pop-ups is limited to a good number and frequency.
Thank you all for weighing in on this "In-context lessons" idea. Our team discussed all the feedback, and I've summarized it here. We're now figuring out whether to pursue this idea, and we'll be back to discuss more if we decide to work on it (please sign up for our newsletter to get updates on our plans).
One big open question with this idea is how to anticipate what a new editor needs to know, and present them that information. In other words, having content that explains citations is helpful once the new editor has clicked "Cite". But what about those new editors who need to do a citation, but don't even know that yet, and therefore won't be clicking "Cite"? How can the software know when it's time to tell them about citations? I'm interested in hearing everyone's opinions on this.
@John Broughton, thank you for the offer to help with content. We'll definitely take you up on that once our team gets to that point. In your experience, do you find that your Visual Editor guide needs to explain the technology more (e.g. how to do a citation), or the concepts more (e.g. when is it important to have citations)?
@علاء, have you found it challenging to keep videos up-to-date as the technology changes? I know that it can take a long time to make a video, and also could be difficult to keep track of what version of the software a video is showing.
Tooltips. There can never be too many tooltips. Its popup info is initiated by the user, and so it is not intrusive.
Pushing citations is an intimidating area for new users. Just suggesting they leave a URL is enough for now. Plus a popup link: "For further info on references".
Please reply here to discuss the "Personalized first day (6)" idea.
An alternative to interrupting the editing flow is, after registration is complete, showing a pop-up that shows something like "Congratulations - you're now registered! We've posted a link on your Talk page where you can - if you want - tell us more about what type of editing you're interested in doing in Wikipedia, or why else you've registered." [Then just an "okay" to close the box.]
On the user talk page would be a postingthat explains what is trying to be done (help the user), and a link to go to the actual questions.
Advantages, besides minimal interruption: introduces the user talk page; link for questions is there permanently (more or less), so user can click on it later if not inclined/able to do so immediately,
”When new editors create accounts, they are simply redirected back to the page where they were before.” – not true. Several Wikipedias (all?) use a feature named ”Guided Tours”, which makes the screen go black and suggests articles for editing instead of letting the user continue what s/he was up to. Also, s/he gets various automatic notifications and talk page messages.
I think less distraction rather than more would be appreciated. And when implementing a new feature like this, it must be done in a way such that already existing automatic greeting functions are taken into account (some of them should then probably be deactivated). Otherwise, the result will rather be confusion of new users.
I would really suggest experienced users try creating a new account to see how it works from the perspective of a new editor.
I think trying to identify what the intentions of folks is, should help a lot more in developing content correctly calibrated for onboarding. Especially around what kinds of edits that we can suggest to folks.
There's a definite tension here between "here's a chance to educate them a little" and "get out of my way, I have a change to make". The biggest change I would make would be to the sign-up screen in relation to the email address (optional). Could we provide a bit more motivation to provide an email address? There are two reasons I would offer: password recovery and "enables us to help you better as a new user" (obviously, there can also be a link to go into the precise list of things we would use the email for, which could include "impact" reporting, and what we would not use it for, to allay certains about selling to third parties etc and that they can always remove their email address by going to ... etc). If we had a familiar means of communication with new users, which could support screen shots etc, onboarding would be a lot easier for those who try to support new users (Talk sucks). I think the new users get things sent by email until such time as they click the link at the bottom of the email saying "Stop these emails, I'll read it on my User Talk" (would also be in Preferences). So to return to the tension of teach-vs-backoff, give them the "teach" option, if they don't take it, send the info through via email (where possible) and also write it on their Talk page. Most of our welcomes are very verbose. Just tell them the minimum to get started (and that's doesn't mean every policy and the MoS), which is probably "where can I go to learn how", "where can I go to ask a question".
It sound good, but I don't like to make any addition to the registration process.
I would make this a pop-up or part of the welcome message rather than to interrupt the work flow.
Asking people about their goals might be premature. I dont think I would have been able to answer that question so early on. Even now, after some 9 years it would not be much easier. Letting them know about other projects of our family sounds good but a questionnaire is too much, imho.
Thank you all for weighing in on this "Personalized first day" idea. Our team discussed all the feedback, and I've summarized it here. We're now figuring out whether to pursue this idea, and we'll be back to discuss more if we decide to work on it (please sign up for our newsletter to get updates on our plans).
I want to ask about something brought up by @Kerry Raymond: why do many new editors decline to sign up with email addresses? It's easy to think of a few reasons, such as privacy, or not wanting to get more emails in their inbox. What are probably the most important/common reasons?
This is somewhat unanswerable because most of the people signing up for an account do so unobserved by any of us. Those who sign up at events (where I get to observe them) are strongly encouraged by me to provide an email address. I explain they need to do so for password recovery and I stress it is not used to spam them or passed on to third parties, as these seem to be the concerns. Since no information on the use of the email address (apart from it being option) is provided on the sign-up page, I would presume the typical unobserved new user thinks to themselves "well, it is optional (so I can save the time/effort particularly as I am on my mobile device), and I don't know of any benefit I get from providing it, but I can imagine drawbacks to providing it, so I guess I will skip the email address for the moment, I can probably add it later if I need to (which is true)". So I think the signup page should tell them how their email address will (and will not) be used, or at least have a link to page that does. I think that might increase the likelihood of providing their email address.
Please reply here to discuss the "Focus on help desk (4)" idea.
I think this has to be paired with any work on #1
I think the Help Desk has to be a highly visible clickable link on the page being read or edited or on a banner (could be different help desks whether in read/edit mode) taking the person to a really-simple text/chat box to ask their question or to email. Forget about Talk, etc as the new user doesn't know about it. Even the Teahouse (despite all its good intentions) is hard to use becaue it relies on the very technology the new user is already struggling with. For example, it requires source editor and does not offer a VE interface which it could trivially do (see https://en.wikipedia.org/wiki/User_talk:Kerry_Raymond for an example of how to offer VE on a talk page -- it really is that easy!). It does not provide a way to provide a screenshot (yeah, well, it's possible, but it is not as easy as pasting a photo into a FaceBook post). It is not clear how the user realises there is an answer waiting for them. After they have added their problem, they don't get any message telling them how the reply will appear. Will they get an email, will they have to come back and check, etc.
In arwiki, we send welcome message to all new accounts (It's annoying to some users but helpful with many other users).
We include in it this sentence:
"أخيرًا، لا تتردد في طلب المساعدة إذا ما واجهتك أي مشكلة، وذلك بطرح سؤالك على فريق المساعدة. بالتوفيق."
= "Finally, do not hesitate to ask for help if you have any problems by asking our help team. Good luck."
Then when the user open the help team page, will face a large button of "Click here to ask for help", after click in it, the user will move to this page. Note that we received several messages (questions ..etc) in this page every day, and we try to answer it as fast as we can.
Hope if we can develop what I wrote about idea 1, because it's strongly linked.
Sonds good. On sk.wiki the policy is to wait for people to make a few edits and only then post a welcome message. The rationale is that recent changes would otherwise be flooded with changes of discussion pages of users who registered automatically and will never be heard from again. Perhaps the system could be set up to send an automated welcome message after 1 edit. The other issue is, again, the availabilty of experienced editors (e.e.) to help. If the message contains links to a help page e.e. might not be flooded.
An easy way to thank IP editors might be worth a consideration.
Another point to consider is that sometimes there is too much discussion as e.e. edit and criticize the new edit(or) and the editor becomes overwhelmed at best and leaves (at worst). Who has the time to argue with e.e.?
Thank you all for weighing in on this "Focus on help desk" idea. Our team discussed all the feedback, and I've summarized it here. We're now figuring out whether to pursue this idea, and we'll be back to discuss more if we decide to work on it (please sign up for our newsletter to get updates on our plans).
A question for @Jetam2 -- do you mean that Recent Changes would be flooded because of a bot posting messages to all newbies? Is it not easy to exclude bot edits from Recent Changes?