@MMiller (WMF)@Quiddity@Trizek (WMF) As the new user reports , in MediaWiki:Growthexperiments-tour-welcome-description-d, he did not understand what phrase "see your impact" at the end was about when he saw the message in the interface. He asked to make this phrase more understandable for someone who sees it for the first time. Perhaps it is worth making the original en-text a little more descriptive, otherwise mentioning only the name of the module weakly represents its real function.
About this board
Please read over the project page, and comment here with any ideas, questions, or concerns. Do you think this is a good idea? Where could we go wrong?
Just so I'm clear: this feedback is about the "Your impact" language on the newcomer homepage, correct? Do you think it's definitely the English copy that makes this confusing, or is "impact" a term that doesn't have a great equivalent translation in Russian? Please let me know if you have a specific suggestion for improved language.
We just ran several user tests with newcomers that included the Impact Module, so I'll also follow up with our lead researcher to see if this also came up in user testing. Thanks again for the feedback!
@KStoller-WMF As for the feedback, it refers to the text MediaWiki:Growthexperiments-tour-welcome-description-d in the pop-up message. When you open the home page for the first time, this pop-up message appears. When a participant (who does not know anything about the module yet and has not seen it) reads this message for the first time, he does not understand what is being said here. If you look at the home page, there is an explanation "Views since you edited" under the module header and this allows you to correctly understand the meaning of the word. But the message seems to cut off the phrase. For example, if it were written "and you can see your power", then the question arises what type of power it says here. The participant read this message as "your actions", probably as a shorter but beautiful representation of the "Special:Contributions" (there is even a link to it at the bottom of the module). It would be clearer if the phrase were continued and concretized. For example, "and see your impact on pageviews", "your impact on the popularity of articles", "your impact on the frequency of article reads".
As for your question about translation - yes, it's also not very good here. In translation, we have two variants "wiktionary:влияние" and "wiktionary:воздействие". They are understandable in the context of a phrase or paragraph. But in a short phrase or seeing one word, the situation is such that this word is associated with a more common meaning - as if there is "influence", for example, "your influence in a group of people". (If you look at the translation in the opposite direction , then the main (first value) is also shown "influence". And auto-translators will translate it in the first place that way.) The module shows an improvement in metrics. This word does not represent the reference to metrics and pageviews improvements very well. I have no idea which module name would be better. (Maybe using the forward and then the reverse direction of translation in auto-translators will give you a fairly good idea of what meaning for words people understand first when they read some title.)
By the way, it would be useful to have a link to the help on the mediawiki page mw:Growth/Personalized first day/Newcomer homepage#Modules, which describes the functionality of all modules. Your understanding of the homepage when you read the descriptions on the help page (or forgot, but you can easily find this page again and read it again) and understand the purpose of the modules is quite different from the understanding of the participant who saw only the final interface without those descriptions.
@Sunpriat thank you for the detailed explanation! Yes, I can see how a newcomer might be confused by that language. I'll chat with our designer to consider if alternate copy is needed.
Even if the English copy doesn't change, would it be possible to just add slightly more context to the translation? So rather than a direct translation of "see your impact", the translation could be for "see the impact of your edits" or something along those lines?
And I'll also chat with our team about your suggestion about linking to the help page from the homepage. I think ideally the homepage is clear enough that linked documentation isn't needed, but that's an interesting idea.
Thanks again for passing along info, and for being a great advocate for new editors!
There is an article w:Impact factor - this title (which already has translations into other languages) could be taken as a basis and called the metric "wiki impact factor".
How does the mentor thing works?
So I frequently update my preferences and also browse around it to see any new changes/features on English Wikipedia, I happened to came upon this "Display Newcomer homepage" checkbox so being curious I ticked it, and going to my homepage (via the link displayed left of userpage), I noticed there is a mentor thing so I read around about it and it is designed obviously for newly registered user since it's called newcomer homepage and the mentor are assigned randomly ... but I'm certainly not a new user since joining 8+ years ago and has accumulated approx. 30,000+ edits so why do I even have mentor?
For practical reasons, we have assigned a mentor to everyone. We plan to work on a feature to opt-out mentoring.
Public impact list?
I've been translating the Homepage feature on Translatewiki, and I noticed that there is an option for the user to view the impact module of another user. Does this mean that anyone can see another user's "impact article list", and is it possible already now or only in the future, and does the user have any control over who can see their list? And what's the thought process behind a public impact module?
Hello @Kyykaarme -- thank you for working on translations for the Growth features! I know there's a lot of text in them (because there's a lot to teach newcomers), and so it's really helpful that you're spending time on it. Good question about the "Special:Impact" page. We originally created this page because it helped us QA and troubleshoot issues with the Impact module, by allowing us to validate that the module looked right for many different users. We've kept it on because it continue to be useful for troubleshooting, and it doesn't display any information that's not already public. Here's a Phab task where we considered turning it off, but ended up not doing so.
It sounds like you think users may not want other people to be able to see their module so that they and their work can remain more private. Is that right? What are your thoughts?
The Homepage contains information that surely is private (email address) and I wouldn't think that anyone should see what my topic interests or preferred difficulty levels are. It's then natural for me to think that everything on the page is visible only to me. If some parts of the page are not private, I would like to at least know about it. And I especially would think that if I were a new user.
I don't know what the effects of the impact module are on new editors, maybe they really like it, but I could see also some negative sides, such as seeing very low views for your articles or having had unpleasant editing experiences (getting reverted and/or admonished) and then seeing those articles every time you go to the Homepage. Maybe there could be an option to hide the list, so that one can look at it once in a while but not have it there at the top constantly.
I would actually like a Homepage where you can pick and choose the modules you want to see and remove/hide the ones you don't have use for. The suggested edits "carousel" is a cool tool, and I could see it used by experienced users as well (without the editing tips). It's a lot easier and more fun to click the carousel than to browse categories when you're trying to find interesting articles to edit.
Userpage as Homepage
[A tangent from the other topic, "Engagement" page, which I don't want to distract from...] [Preface: I love some of the ideas in the Newcomer homepage project. These are supplementary thoughts.]
Someone asked me recently:
> Whilst I was just a volunteer, what could Wikimedia (movement/foundation) have done better to make me feel I could grow?
I replied: "In a word, userpages.
The way that some editors use their userpages is fascinating. They use them:
- to track their to-do lists,
- to store notes and wikitext/snippets/citations they're using a lot (for easy copy&pasting),
- to list their accomplishments and accolades,
- to organize (and share) their bookmarks,
- to disclose their COIs,
- to write short autobiographies,
- to list their passions or affiliations (often in the form of those small 'userboxes'),
- to write essays and rambles,
- and more.
My Enwiki userpage has always been the first destination of the day for most of my volunteer activities - it loads faster than the watchlist, it contains my links to watchlists on other projects, and it contains my most frequently used bookmarks/snippets. I typically leave it open in a tab whilst I do anything else on the sites.
- I've only had a few designs myself. For a long time it looked like this: c.2007 version or like this c.2013 version
- but I have an (outdated) bookmark folder with a few dozen interesting variants, e.g.
I've long-thought that there are some good ideas that could be extracted from the previous WMF research into userpages, to help both simplify & power-up the default experience (which is fairly-to-extremely complicated for non-technical people - and the English help docs (stuck circa 2007) are frankly terrifying).
I.e. The previous research included ideas such as automated boxes of statistics about the editor - I think many existing users would really love this. If we could provide that kind of thing but in the form of normal wiki Templates that would fit into the classic freeform pages (thus making most existing users happy), then we could potentially also offer an easy "create your own userpage from these few predefined skeletons" wizard system, which editors could then use normal page-editing to re-arrange and personalize, and thus make everyone happy. [!!]
Here are the 2 old WMF research projects (which never made it past the mockup or notes stage)
- In 2011, there was
- In 2013, there was
TL;DR: We should help newcomers to use their actual userpages in ways that work for them (diverse ways for diverse people). Not a one-size-fits-all-solution (I think the GlobalProfile mockup idea was inherently flawed by its standardization approach), but give them help in finding the possibilities.
Because: Having a good userpage - especially one that is actively used, and can become their first browser destination for daily editing - can give editors a sense of personal connection to the sites, and also provide a space for an individualized (and sometimes 'humanized') element that can help people to relate to each other.
The User pages look like GEOCITIES on a bad day :-) They are multipurpose - Who, What, achievements, likes, and the categories don't actually lead to any community interaction. I think boardgamegeek does this best, especially as some of the achievements are assigned externally.
I am having similar thoughts though about the home and main page, except that I think the Main page should be personalised for non anonymous new editors as a reward.; anonymous editors should see a a registered editor only block and a warning that anonymous is not as safe as registered :-)
Non-active editors need prods to return, visibility of a cohort, main projects , and their mentor contact .The emphasis should be things that build a healthy community - giving and receiving thanks, taking part in topics that are marked for archive that have not been marked as conflict by more than one person etc
The focus on Number of edits is unhealthy, and is gamed by BOTs. and older editors who do the 20 % of typing that generate 80 % od edits
We also owe a duty to editor to show much time they have spent on wiki this week - burn out is very bad/unsafe for wikipedians as others don't know it has occured as they just don't login. I have no doubt that others behaviour contributes to mental health, because some editors just see others as NPCs :-(
VISIBIILITY - Have a personalised main page for non anonymous editors to reward editors.
ViSIBILITY - CURRENT MAIN PAGE
- Far more than 5 to 7 items on the pages, so most of the main page is just skimmed as there is too much information.
- The left pane takes up a huge amount of real estate. is used by the minority, and should be move to an info tab
- A single featured article is ok, but you have to page for the featured picture,
- News is OK, but there should only be one item showing.
- The sister projects etc are irrelevant, and should be collapsed or just a feature project with a few lines.
- The Adverts for projects shouldn't list the articles that work has to be done on (scary) It should give what people enjoy about
VISIBILITY - PROPOSED - The top right , have a welcome with Number of edits, Which of your edits has the most views, number of edits, thanks given, received, tasks closed that did not involve conflict , number of hours editing this week - changing colour to help mental health, blah blah and mentor contact if gets too high
Similar for the thanks received by your cohort , Your mentors name, Achievements of your projects today The featured picture next to your name. I think the resistance to having an avatar is generational
NUDGES are Personalisation, pride in a community, community spirit, support, incentives for good behaviour
Overall, Wikipedia is unwelcoming in part because experienced editors assume that the heroic days are over as we have all the pages we need. They see no need for new admins, or changes in policies, or in systems, or for new editors The decision by consensus often ends up being rule by the loudest or by experienced editors
But the Experienced editors are wrong.
fI you add up unanswered talk, maintenance tags, article tags, dead projects, lack of references, categories, and article quality then we probably have 30 years to go.
What retains editors
We need new editors because there are huge backlogs in many areas. We also need them to focus sometimes on those edits we need fixed
I think users retention could be increased by Excitement ,Community, Available Support, Clear procedures, Safe Spaces, and Visibility of achievements .
I have split the areas into sections to avoid wall of text and to allow people to comment on eacg
- - When you do your first edit, you are greeted with a plain page asking you to choose between anonymous ( but not advising that being an Editor gives better anonymity) , or becoming an Editor. (Are there statistics on how many possible editors stop here??). Instead maybe - A featured picture associated with the project the article is in, And the mentor for that months reasons they like wikipedia - A welcome message advising that they will be asked to join New Users of November 2021 and asked to join a project community. B - Options to join an active groups that you share a trait or int with maybe are an ally women, trans, nationality, profession, same age group .
- Scary large Article and stubs (which i think default as hidden) also have an encouragement to become an editor . These are high friction because of size, colour, no mention of rewards, position, and imply self sacrifice and accepting a fault. Instead It would reduce friction, if non-readers could become an editor before hand. prompted by a single line hopefully occasionally humorous or appealing to diversity. Let the messages decided by different A/B messages, only appears for non-editors.
- These are all good nudges as they split friction, reduce friction, have a clear call to action, recognise, external group memberships, eye candy, clear focus, inspiration,and short term reward. A long term group intangible reward (A template saying they have x active more editors than the average or they have more happy editors etc, or least open talk issues ...)
COMMUNITY - I think the core to retention is community,
After a New Editor publishes their first edit, have a congratulations screen that gives them a choice of active communities to join based on their edit or via a wizard, and also automatically assign them to say "Novermber 2021" and ask them to post about their interests. A month should be small enough at 5 % active to make a community.
- November 2021
- Assign mentors, and automate a monthly group talk topic
- Criticism messages (Reverts and speedy deletions) are also sent to November 2021 (Have you any advice/support/help to fix for... ) with the critics name as a link, so peers can learn. and Mentors can say whether it is fair and discourage edit wars..
- Editing Topics
- Unpleasant interactions destroy communities. Most is unreported Experienced editors with high edits have support communities, so are forgiven because they are busy. We need junior editors as they mostly create content, while many experienced editors however use automated tools to fix minor issues Workaholics also reduce output because of hogging glory or resistance to change ; with wikipedia they can reduce active editors.
- I suggest that talk topics have option to escalate, or create an FAQ , or mark for archive and that the talk tab have a number of open tasks and change colour based on the number of editors escalating. Editors showing number of escalations caused and thanks world be cool as a rollover There also has to be a better way of getting hellp for people rather than tagging WP:NOTTHERAPY.
- New Editors
New editors are supposed to be treated nicely, but finding out whether they are new is a multi-step process. A tag next to their name would nice.
- Create an Article
- You allowed to make your first page after a few weeks/edits. You will fail :-)
- There is a new page wizard , but it isn't major category specific (so precise notability criteria can't be checked or whether enough allowed sources are used. A classic example is IMDB is disallowed as a reference: IMDB important categories are maintained by the industry using IMDBPro, it is used on Box Office Mojo which is allowed, and it is used by reporters, Ideally there would be automation to check and give a percentage complete - but the automation is all on the NPR side.
- Monitoring new articles
- This is very low friction for tNPR, but as a genuine new editor it took me about 4ish hours to create my first article,
- NPR can mark an article for deletion and assign a big yellow tag of New Editor failure in 1 minute. If it goes to AfD it takes about 5 to 10 minutes of NPR editors discussion time to delete a page. | The AfD discussions are legalistic and cold and the New Genuine Editor often rage quits. AfD need to be like this because of scammers and notability issues, but some of the notability requirements are rusted. If enough people are searching for an article that fails our criteria we should consider changing.
Nudges are small community within large, available support, peer support, Mentor support, group learning,protections organisational renewal through strong peer links in Junior Editors, and clear procedures..
HELP - They get peer support above, but also get told who there mentor(s) are with a template with a nice image and a summary of who their mentior from a template on the mentor page. As soon as they get autoconfirmed, they get a message from their mentor saying contact them to discuss if they are thinking about creating a new article.
PROCEDURES and TAGS - They are frankly overwhelming. On your first day you come across them in 3 ways.
PROCEDURE - ARTICLE - At the top of Article are on scary anonymous judgmental un-collapsed uninformative tags, maintenance tags are in the body, and stubs are at the bottom (although hidden for new I think) Mostly they should be on Talk rather than Articles (but people don't check Talk, and tools don’t update it.
· Reader View- Complicated Tags with very old dates reduce trust, even if the issue is minor. The real estate also emphasises that editing is more important than content, criticism is more important than creation.
· New Editor- First day and they are going to edit. They go to a page covered with tags. They are overwhelmed with the procedures, and they decide to do their first edit to fix the tag.
- The New Editor reads they should try and get consensus, so they add a Talk topic. No one ever responds as no one is watching the articles (and they don't know the article is unwatched), and no one looks at the talk tab, The New Editor expect a quick response, and they stop when they don't get one. They decide to wait till they get a response.
- The New Editor can’t find the issue, so they feel shame. The reason they can't find it is another Editor has fixed the issue, and not updated the tag or looked at Talk. They get worried about their ability. They quit.
- Full of excitement they decide to edit and be brave. Their edit is re-verted. The Editor reverting does not know the person is a new editor, adds WP:Shortcodes, is unpleasant, leave a cryptic comment, or complain they should have looked at Talk or even Talk Archive. The New Editor rage quits.
- Template header is BIG, has many warnings relevant to the article, or experienced editors (be nice and don't bite newbies), but only one action. It's not clear what to do and the links to large, complex procedures. New Editor quits as there seems to be lots of rules.
- \Project headers -are Freudian in their size, are Pseudo-Article categories or projects recruitment ads, are relevant only to projects, and not editors. Projects don't monitor open topics in their projects, and there is no indication you should ask them for help. Experienced editors ignore them, but it still increases friction as they have to page down.
- The Sanctions tag is just scary, un-collapsed, not differentiated in colour or position, links to procedures that even more complex and scarier, appears as a Notice as well, and is mostly relevant to the Article. With all the warnings, Wikipedia just got scary. New Editor Quits
PROCEDURE - TALK POST
- a New Editor creates a topic, but it's as the bottom. They assume (often correctly) that no one will ever look at it. Even if an Article is highly viewed, about 20 % of topics never get checked and it is archived. When a New Editor as soon as 10 days , their topic is archived, but they think it has been deleted. Their first day as an editor was wasted. The New Editor quit.
- Someone does look at it. The replying editor does not know it is a New Editor,. The new-Editor receives a reply full of short codes WP:NPOV or WP:NOTTHERAPY . These procedures have a low readability .Tooltips showing the Nutshell might help. But Nutshell is a workaround on procedure readability, and the main procedures have lots of things that it is all about consensus. Unfortunately consensus can sometimes means that more experienced Editors can override the New Editor, based on precedents that are not recorded. The New Editor quit.
- Normalisation of screens - Article Tab has only Article information, Task Tab only has task information, Page information has page.
- Tags should be on talk, but as posts with the Editor who added them.
- Tasks can be marked as important and Escalation needed/conflict. This should change the colour of the the topic heading if more than open person clicks it
- The Talk tab should show the number of non-archived tasks, half of it should change colour for conflict and the other for importance
- Make tags appear on Talk. They can still show as a single line of codes on Article, but controlled by Talk not editable.,
- Change article publish to show as list of open tasks. Editors can select one or more tasks, and choose to update with their publishing comments or mark the topic for archive It would also stop New Editors from not knowing about tasks TA
- We have a ranking system for pages already, so if we used that and maintained NPR/Twinkle created comments/tags on Talk it might work better.
- There is no incentive to mark Talk Topics for archive. New Editors would find the process of using HTML at front and back confusing, The measure of success on Wiki is edits. Measures should be in place for editors on thanks given or received, RfD, Tasks taken part in an archived, Number of mentor posts. This should be an info tab that all editors can see
- Number of watchers should be visible to all non anonymous editors, The rationale was that vandals would attack unwatched screens. But they attack watched screens
Nudges are lower friction, minimisation of keystrokes, clear instructions, remove focus from # of edits as status, normalisation of screen purpose, warning colours, Visibility of open work, feedback loop on cohesive behaviour, Reduce perceived issues, Visibility of inexperience,
"Your impact" module thoughts
Hi Growth Team! Having glanced at the impact module a bunch since activating the homepage, I just wanted to offer some thoughts on it.
First, if new editors feel at all similarly to how I do, this module definitely seems to be succeeding at the goal of helping editors feel satisfaction about their impact. The main way you normally find out that others have seen your edits is when they get reverted, and this is a lot more pleasant than that haha.
Second, this is probably something that's a lot more acute for me as an experienced editor who edits tons of different pages than it would be for a newcomer who hasn't edited that many, but the selection of pages still seems off. It feels very heavily weighted toward pages I've edited recently (which have less views since I edited them by virtue of being recent), and sometimes pages I've only made quite small edits to show up. Adjusting the algorithm that picks which pages to show to favor ones where I've made large or many edits and place less weight on ones I've edited most recently might help.
Third, I think a likely impact of this module to consider is that it pushes editors toward editing more popular pages. When I see that 100 people have viewed my contributions to one page and 5000 people have viewed my edit contributions to another, that's a strong push toward editing the second page. If that's the case, the upside is that it'll allow their contributions to benefit more readers, and that it'll increase their odds of coming into contact with experienced editors who can help them if needed. However, the downside is that many more popular pages are already in much better shape, so they may have a harder time finding positive contributions to make, and the editors they encounter may be as likely to revert or bite them as to help them out.
I also had similar concerns about pushing new editors towards popular articles. The upside of that is that there would be more oversight of these new edits. If the algorithm were to be slewed so that it reflected the ‘’proportion’’ of the article that was altered, then a change to a stub article would look better than a similar edit to a large, popular one.
Hi @Sdkb and @Nick Moyes -- I'm sorry I missed this thread when you created it, but I'm glad you posted your thoughts. It's true that we the rules for displaying the articles in the impact module are geared toward brand-new users seeing the most impactful of their recent edits. We wanted them to have the moment of, "Wow, people are actually seeing what I've done!" If you're interested, you can see the actual rules it's using in the original task (which also contains a brainstorm of possible improvements).
"Among the set of 10 most recent pages that the user has edited, choose the 5 pages that have the most pageviews since the user first edited them (or in the last 60 days, if their first edit was more than 60 days ago -- because of constraints of the API). If a user has edited a page multiple times, their most recent edit of that page is what is counted for deciding whether it is part of the 10 most recent pages. For this sort, "null' sorts below 0 pageviews. If the user has edited fewer than 5 pages, show them all. Display those 5 pages in descending order of pageviews."
We have improvements planned for the module this year, and this is our nascent project page related to the work. I think an approach that would get at what you're saying is to add options and filters to the module, e.g. letting users select "most views" or "most recent" or "largest changes by bytes" or "exclude minor edits", and let those selections be sticky. What do you think of that idea?
Ah, thanks for the explanation of the algorithm! I think the thing that's making the selection feel off for more experienced users is the "set of 10 pages" part. I'm not sure how costly this would be in terms of API, but an improvement would be to look at the set of 50-100 most recent pages to which the user has made non-minor edits.
More filtering options (for suggested edits)
Currently the filtering options only add new groups of articles, and don't find articles that meet certain criteria. It would be valuable to have the ability to filter to only Transportation articles in Asia for example.
Hi @JackFromWisconsin -- thanks for bringing this up. We've heard from many newcomers that they would be interested in more specific topics (especially country-level, as opposed to continent-level). Your comment has spurred an internal conversation on the Growth team about how we might accomplish this idea. One interesting thing is that it's already possible to do this through Search. For instance, check out this link using topic keywords: https://en.wikipedia.org/w/index.php?search=articletopic%3Atransportation+articletopic%3Aasia&title=Special:Search&profile=advanced&fulltext=1&ns0=1
By entering both topics, I get articles that have high scores for both transportation and Asia (Indian Railways, Toyota, etc.). We're thinking about whether it might be easiest to add a free-form search bar so people could use Boolean logic to make specific lists, or if there are user interface elements that could make this simple.
Is there a specific topic combination that you yourself would want to select?
I did not know that was already available through search! A search bar could definitely be an easy way to implement this, but I think having a selector to change between adding the topics together, and only taking articles that are in both topics would be great. Asking a question such as "How would you like your articles selected?" "From any topics" or "Only in all topics". I'm not a UX designer so my wording choices suck, but this is asking between whether all topics, or just the intersection of topics.
Messing around with the topic search, it works exactly as I would want (by bringing up articles that are rated high in both categories). If I was interested in video games based on war, https://en.wikipedia.org/w/index.php?search=articletopic%3Avideo-games+articletopic%3Amilitary-and-warfare&title=Special:Search&profile=advanced&fulltext=1&ns0=1 would be more useful to me.
Okay, I'm glad to see that the underlying technology is already there. Thanks for your input, and we'll continue to consider when/how to make this improvement.
Homepage for WikiProjects
It would be amazing to bring the homepage over to WikiProject pages. Relatively few things would need to be changed, for example "your mentor" should be changed to "helpful editors", and have it be composed of knowledgeable editors in the WikiProject. Making it customizable would allow WikiProjects to provide specific links and advice for its volunteers. I'm imagining the Article Alert bot system gets replicated as a tile. The possibilities are endless
Hi @JackFromWisconsin -- thank you for checking out the Growth projects! I agree that there is a lot of potential for the newcomer homepage when it comes to WikiProjects. The way we're thinking about the homepage is that each person has their own personal page, as opposed to it being like a common page that many people visit. It sounds like you're talking about an idea in which it would be possible for each WikiProject to set up a structured front page that shows the most important people and tasks in their project, sort of like how highly-developed projects like WikiProject Medicine have done with templates. Is that how you're thinking about it?
In terms of the homepage in the way we designed, there are several ideas we've had that relate to WikiProjects:
- The task list could allow users to select tasks that are under the auspices of certain WikiProjects, like "Medicine" tasks or "Women in Red" tasks.
- After users select topics of interest, it could recommend WikiProjects that they could watch or join.
- We could assign mentors to newcomers based on which WikiProjects the mentors are active in matching the interests of the newcomer.
What are your thoughts? Are there particular projects in which you're active?
chat functionality to get real-time support
In order to help newcomers as best as possible, I suggest that the "ask for help" button should open a chat window and connect the newcomer to an experienced user who provides help in real time and on the spot. This is not meant as an introduction of chat for all users, but only as a tool for which experienced users who want to help could sign up for. I believe that is is often difficult for newbies to write down what their problem or question actually entails and even more difficult to understand the answers written down by wikipedians. Real-time chat would help to come to the point since both participants could ask further questions to identify the specific problem the newcomer is facing. Ideally, this would be combined with a kind of back-end view, showing the experienced user the page which the newcomer is looking at (similar to a remote support functionality, but read-only).--~~~~
This is the best statement of the problem that I have seen!
often difficult for newbies to write down what their problem or question actually entails and even more difficult to understand the answers written down by wikipedians
As someone who very occasionally visits en-wp Teahouse and Helpdesk, and was recently looking at VE-feedback, I’ll say it’s quite common to see a post that make me go “huh? what?”. Another big issue is not knowing whether the newbie has come back and read the responses, as they rarely post an acknowledgement. It can be discouraging writing answers that will just get archived after a few days. Perhaps live help could be (sometimes) rewarding for the helper as well as the helpee?
Hi @Pelagic -- thanks for checking out these materials. I agree that newcomers have trouble formulating strong questions. This is definitely something we've struggled with in the help panel project. We've tried a couple ways to frame the prompt to ask questions, but we continue to get plenty of newcomers whose question is simply something like, "Hello" (which, I suspect, is because they expect someone to chat them back a "hello" right away).
And it is definitely also a problem that newcomers frequently don't see the responses. Our data from the help panel makes us think it is less than half of users who return to view the responses they get to their questions. To address this, we've encouraged newcomers to add email addresses to their accounts (via the newcomer homepage) and told them to expect a notification on wiki (via the help panel). We haven't yet revisited whether we increased how many newcomers read responses.
I agree that live chat help could be rewarding for the helper, and this has been an ongoing topic of conversation on our team: how to make the helping of newcomers feel rewarding and productive. One idea we have is the mentor dashboard, which would allow mentors to monitor how their mentees are doing, and to track the kind of impact they may have had through helping those newcomers succeed. Please feel free to add any of your ideas to that talk page!
But overall, the team has not yet prioritized to digging in how we could make live chat work -- we have been prioritizing the "newcomer tasks" features that you commented on separately. I do hope we can return to this idea.
Hi @Poupou l'quourouce -- thanks for reading about our team's work and proposing this idea. The idea of "chat" has come up a lot in our team's work, especially around the help panel feature. Newcomers frequently expect the help panel to have live chat, and experienced community members have expressed interest in supporting it. And at Wikimedia Hackathon 2019, we actually built a small prototype. But there are a couple of really big challenges around it that have kept us from working on it too much, and I'm wondering whether you have ideas around these:
- Resourcing: how could we make sure that enough experienced editors are available at all times to respond to chats?
- Patrolling: live chat could potentially be a vector for abuse, and we would want to make sure that it is a safe place for all users.
I'm CCing @Trizek (WMF) so he can follow along.
Resources and potential abuse are indeed relevant issues. I do not think that there will be enough editors available at all times for live-support. But in that situation there could just be a note saying "sorry, no live chat available at the moment, please try again later or leave your questions at XYZ, where they will be answered within the next days".
For abuse reasons there should be an easy way for the newcomer to end the conversation any time. And, possibly more important, the tool should (from a back-edn perspective) not be available to anyone, but only to experiecned users that have been approved by others, for example users who have mentor status (in de Wikipedia they are elected similar to admins, I do not know about other versions). Those users who engange would need to have some sturdy attitude, so they do not bother too much, in case they receive abuse messages from fake newcomers. Regards,--~~~~
Thanks, @Poupou l'quourouce. These sound lke sensible ideas. We'll keep them in mind if/when we decide to work on live chat for the help panel.
Hi folks, on top of Poupou's idea I would like to suggest: Do add a) some function for appointments / individual "office hours" and b) videochat. Since 2020/21 produced an enormous leap towards videocalls e-v-e-r-y-w-h-e-r-e: Some newcomers would greatly appreciate an instant or appointed face-to-face-talk. I would prefer some function as in moodle: one click opens a zoom-session.
To be honest, the Wikimedia Foundation will probably never built a video conferencing software. :)
Have you considered to have office hours announced on wiki (could be on the Homepage we provide), and use Jitsi or another FLOSS software?
Mechanical headers on talk pages from newscomers
I got the idea that the same type of mechanical headlines can negatively affect the mood of both mentors and newcomers.
Often times, mentor talk pages are composed of only such headings. People suggested to me that it seems that bots are writing to you (regardless of the content of the question). This can have a negative effect in the long term, since bots are less interested in responding than humans.
I think to ask a question about this topic to the Russian mentors, but I am writing here, as maybe someone will also be interested in this possible problem.
@Trizek (WMF), what do you think about it? :)
Perhaps, by the way, this is why many mentors want to move questions to another page.
I can understand the effect on mentors, but I'm less sure about the effect on mentees. I won't say that mentees will notice a difference. They are only looking for an answer.
We tried to ask mentees to add a title, and it was not really a success: imagine a page with only headers all the same: "Question". :D
In you opinion, what would be the alternative? We can't pass on the username, since it is the only way to make a difference between two comments. Have something like "Question (26)" may be as boring as the current state.
Mentors want ot move questions to other pages? I don't remember you mentioning it - but I may be wrong!
> I won't say that mentees will notice a difference. They are only looking for an answer.
It seems to me that mentees still look at the mentor's talk page, and such topics kill the appearance of live communication. 1. One gets the impression that this is how the topics should be named. 2. It seems that the mentor is only answering questions from newcomers. These are just my guesses.
> We tried to ask mentees to add a title, and it was not really a success: imagine a page with only headers all the same: "Question". :D
Oh, was there such an experiment? I didn't know about this, and thought to offer this idea in this capacity :) So let's forget about this idea :)
> In you opinion, what would be the alternative?
I thought about it, and could not come up with anything good. Maybe take time out of the header?
> Mentors want ot move questions to other pages? I don't remember you mentioning it - but I may be wrong!
Yes, I didn’t tell you about it because I don’t like this idea and I decided to deal with it later. I mentioned this to Olga in our interview.
In general, a month or two ago, one mentor left the project, because she really did not like that questions from newcomers cluttered the page. She asked if they could be moved to another place, I said not yet.
Two reasons why I don't like this idea: 1. Communicating on the talk pages, the mentees immediately gets used to our discussion system: that all questions should be on the talk page 2. It will be very difficult for other mentors to follow other people's pages if they are all in different places.
Well, some mentors are only replying to mentees, since most of their interactions with the reste of the community is done on community pages. I can understand the feeling you describe though.
Taking the timestamp out of the header would be a solution. I have to ask if it is possible, since we use this header to identify the comment as being unique and we use it to display the link to this comment on the mentee's Homepage (If I remember correctly).
> Taking the timestamp out of the header would be a solution. I have to ask if it is possible, since we use this header to identify the comment as being unique and we use it to display the link to this comment on the mentee's Homepage (If I remember correctly).
Yes, this can be a problem :( But we can use a Anchor template for this purpose: https://ru.wikipedia.org/wiki/Шаблон:Якорь. Or simple tag with special ID.
Hi @Iniquity -- the reason we included the timestamp is because sometimes mentees ask multiple questions to their mentors, and we thought that mentors would want a way to distinguish between them from the table of contents. We thought timestamps would be most helpful, more than ID numbers.
Hi, @MMiller (WMF) :) Thanks for the explanation, timestamps most helpful, more than ID numbers, you are right.
What would be the risk of someone removing these anchors by accident?
I think the risk is exactly the same as if someone wants to rename the topic :)
I asked other mentors, and they are not perceiving it as a problem.
Could you provide links to direct feedback from users, so that I can get the context?
It is a big page. :)
I created a task to track the issue. But as of now, this not something I have seen elsewhere.
Thank! This is not a priority, but let it be written somewhere :)