Talk:GlobalProfile/design

Source code

Looks good, but where is the source code? I couldn't find a link or a directory in SVN. Or is this only an idea that is not yet implemented? SPQRobin 12:46, 30 June 2011 (UTC)

This project is currently in the design phase, so no coding has been done. Jorm (WMF) 15:59, 30 June 2011 (UTC)

Red linked userpages or redlinked talkpages?

This initiative seems predicated on the idea that other editors are targeting editors with redlinked userpages as probably editing in badfaith. An alternative theory is that the truly sure mark of a newbie is a redlinked talkpage, so the best way to protect goodfaith new editors is to welcome them once you've checked their first edit and found it to be in goodfaith. In my understanding Huggle etc divides users into four broad groups:

1. whitelisted editors
2. editors with bluelinked talkpages and no recent warnings
3. editors with redlinked talkpages
4. editors with recent warnings.

Editors with bluelinked userpages and redlinked talkpages are currently an anomalous subset of group 3 that includes spammers and myspacers.

Efficiently moving users more quickly from group 3 to group 2 and group 2 to group 1 would reduce the load for Hugglers and other patrollers, thus making recent changes more efficient, less stressed and hopefully less likely to miscategorise a goodfaith newbie as a vandal.

Possible ways to do this include:

A user preference for those who have hotcat installed to "welcome unwelcomed new editors with a personalised welcome based on the category I've just added to their new article". This would require a bit of code using the wikiproject or more likely category to tailor the welcome to include a Wikiproject or Wikiprojects that they might find interesting - we already have w:en:User:DASHBot/Wikiprojects/Templates the table for this, we just need the code. Newpage patrol would I believe be transformed if there was an option to auto welcome newbies whose articles you had patrolled. This could just be done by creating an extra button for patrollers where the article is by a Newbie - so [Mark this page as patrolled and welcome author] would appear as well as [Mark this page as patrolled]. T

Linking Huggle and the other vandalism reversion tools and manual vandalfighters so that white lists can be generated more efficiently would speed up the transition from the second group to the first. I revert vandalism manually and welcome good faith users using Twinkle, but I'm pretty sure that when I check an edit and do nothing that does not currently contribute to getting that editor whitelisted. WereSpielChequers 14:50, 22 June 2011 (UTC)

I believe that there are currently a couple other experiments being run by the Account Creation Project team that involve automatically creating User and User_talk pages - specifically with the goal of avoiding the "redlink" problem described above. In some ways, the impetus for this project is driven from that - if we remove the redlink notifications, then page patroller difficulty increases radically so we need to look into ways to avoid that.

I am currently of the mind that providing default User and User_talk pages for new users is a good idea, if only so that we can show them that these things exist at all. The sooner new users understand that discussion pages exist is better, in my opinion.

As far as templates are concerned, I am very leery of them. We have some research that tells us that "manually saying mean things" to new users is far, far preferable to "dropping a template on their talk page". Templates are rather forbidding, generally, and overall poorly designed. Most are blocks of text which instantly cause users to drop into "scan" mode.

It might be better to connect this with WikiLove to help show appreciation. --Jorm (WMF) 19:05, 22 June 2011 (UTC)

That's really interesting re dropping a template on the talkpage. The only research I've seen so far shows that welcomed users are more likely to stay, despite a high proportion of welcomed users getting a "welcome I've tagged your article for deletion" welcome, and as we know those users rarely stay, so the logical assumption is that welcoming really works. If there has been other research on this I'd love to see it (I know there been some focus group sort of stuff as to what people say they like, and templated welcomes do badly there. But if the actuality contradicts the focus group I'd be inclined to go with what works in practice even if it shouldn't work in theory). WereSpielChequers 14:27, 23 June 2011 (UTC)

SUL

Many of our goodfaith editors are actually visitors from other wikis, some of our badfaith editors are also. If we are coding something like this it would be cool to have an option that automatically replicated your userpage or at least a link to it when you first edited on a project. WereSpielChequers 15:06, 22 June 2011 (UTC)

I think my ideal implementation for this would be to have all the data stored centrally on a cross-wiki server (data.mediawiki.org, maybe) so that your profile will be accessible on every wiki that you have unified. This will help alleviate the problem you're describing. --Jorm (WMF) 18:57, 22 June 2011 (UTC)

That risks increasing the amount of foreign language userpages on wikis. Better I would suggest to have a userpage per language - this would be more easily be done if Wikinews, wikiquote wiktionary etc etc were all views of one wiki and we moved towards one wiki per language.

Multilingual Wikimedians tend to have their different userpages in the appropriate languages, and they are most likely to be active cross wiki WereSpielChequers 12:05, 23 September 2011 (UTC)

If the user has a central user page, he can use

{{#switch:{{CONTENTLANGUAGE}}
 |fr = User page in French
 |pt = User page in Portuguese
 |en|#default = User page in English
 }}

to get it displayed differently depending on the wiki's language code. Helder 11:28, 26 September 2011 (UTC)

Private Sandboxes

My understanding of the reasons why we are concerned as to the contents of users sandboxes and other userpages is that they are published on the Internet and available for all to see. If we created an option for editors to have a private page that only they could see then presumably we wouldn't need to police it, and that could be used by editors as a sandbox, or for any other lawful purpose. We'd presumably want to limit the space of that to avoid misuse, but I think it would be a logical extension of the userpage work. WereSpielChequers 15:06, 22 June 2011 (UTC)

See also Extension:Drafts, which was nominated to the Environment Survey during the usability initiative. Helder 12:26, 4 July 2011 (UTC)

Retooling

I think I'm going to retool this after watching several user tests that show me that the concepts we were thinking to do regarding profile pages were not radical enough. --Jorm (WMF) 23:16, 23 June 2011 (UTC)

There is definitely potential for a major change to the way we handle userpages, and user information. Two of the ideas you might want to consider are keeping private drafts and sandboxes that only the editor can see. If the system autosaved drafts privately in userspace the way that gmail does then editors with flakey PCs or who edit from multiple locations would have a much better editing experience. I've lost several updates due to PC crashes and I can't be alone in this. Equally if people could choose to designate a sandbox in their userspace as private and only viewable by them then we wouldn't need to wonder what was in it. There are also two high priority things that members of the community have long been begging for - cross wiki watchlists and cross wiki userpages. Either of those would be a major upgrade for those wikimedians who operate across multiple projects. WereSpielChequers 18:12, 24 June 2011 (UTC)

I'm thinking much more along the lines of cross-wiki user pages right now, which would require technology that would enable cross-wiki watchlists in the future. More information coming soon. --Jorm (WMF) 18:49, 24 June 2011 (UTC)

Cross-wiki userpages sounds like it would be largely unhelpful across sister projects (information relevant to one project is not that likely to be relevant to another), and pretty much impossible across languages (how would translation be done?), imo. --Yair rand 01:11, 30 June 2011 (UTC)

(Also pointing out that StructuredProfile would probably need some changes to work on certain projects. On Wiktionary, for example, "Interests" and "Languages" overlap enormously.) --Yair rand 01:13, 30 June 2011 (UTC)

Leaving the question of relevance of certain data for varying project wikis aside - having structured data makes translation a manageable task. Volunteers at translatewiki.net will be translating all prompts and all selecteable answers. Rendering software will be using these translations as appropriate. That's all. --Purodha Blissenbach 23:27, 3 July 2011 (UTC)

• Note that Extension:Draft and Extension:SocialProfile and Extension:ConfirmAccount respectively already do much to some of the suggested tasks. --Purodha Blissenbach 23:27, 3 July 2011 (UTC)

Rehman suggested on bug 4547 (Support crosswiki template inclusion (transclusion => interwiki templates, etc.)):

(...)maybe (upon enabling cross-wiki transclusion from Commons), we could also create an option in Special:Preferences where checking it would transclude the Commons userpage to all other wikis. For example, checking it would simply replace the userpage with a function like {{User:Rehman}} (or {{Commons:User:Rehman}}) on all other userpages...

Helder 12:38, 4 July 2011 (UTC)

Public Versus Private Data

If we want to learn from other social networks, we may want to add a feature of degrees of semi-privateness, which allows to share personal data with some peer-group, or all logged-in users, but not the general public.

For instance, I know several users of one or another regular local editors meetup who share considerably more personal info with each other in real life than they would be willing to publish on their user pages.

In a non-WMF context, I have been in contact with project contributors who could not make their contributions to the project in ways that their employers would recognize, though their employers interests were not touched. While the project communication was otherwise through public mailing lists, these specific persons had to use non public channels when their expertise, skills, and knowledge could be identifying them. --Purodha Blissenbach 23:26, 29 June 2011 (UTC)

I think that personal data people might want not to share shouldn't be included at all. The creation of a "social network" of users who can see more or less would produce a privacy concern and raise opposition to this on the basis that "we're not Facebook!", and for once I would agree: are we going to fight on Wikipedia about being added or not to the list of friends who can see the entire profile?

Moreover.

• The current page says "Real Name - entirely optional [...] may be discouraged": better to remove it entirely. We already have a way to manage real names in MediaWiki for the sake of attribution and it's better if users add real names in the usual way when they know the wiki better and they're ready. The structured profile should include only information which is relevant to wiki activity and can be used to aid it.
• "Associations" seems useless as well: WikiProjects should be under Interests, and sysop know how to describe their status (not to say that this is also included in public metadata mentioned above); it could be used for things like "inclusionist", "deletionist" etc. but I don't know if this needs encouragement.
• Avatar: I don't see the usefulness of this and it would be an hassle (see also feedback about LQT). Most active users don't add any avatar, hence it's clearly irrelevant. It should be removed entirely (at least on WMF wikis) or should be encouraged in any way (i.e. no "blank avatars" to make you feel different and ruin your userpage until you put one, please).
• Wikimatrix: this is currently missing, but it's quite common in userspages. A complete wikimatrix is not needed thanks to Special:CentralAuth, but users often still want to specify the other wikis which they're most active in or they like more. Nemo 06:45, 4 July 2011 (UTC)

Alternative username rendering

Brion made the point that if we port the profile across languages, this would also be a good place to keep alternative renderings of a username in different character sets (e.g. Japanese vs. romanized). Eloquence 02:15, 7 July 2011 (UTC)

Agreed.

Although I bet, only few users would be able to use it supplying their own transcriptions. Purodha Blissenbach 10:01, 16 July 2011 (UTC)

Use in account selection

There was an interesting article recently about how some sites handle the problem of forgotten / wrongly remembered user names by showing personal data on the login form. GlobalProfile seems to be ideally suited for such a function. Tgr 19:54, 23 August 2011 (UTC)

Heh! I read the exact same article the other day and started cogitating on it.

That article discusses login screen usability but it does not discuss log in security. I'm uncertain how many of the suggestions there we would want to implement. Nominally, all of the user names on a wiki are available, so there's no real harm in exposing that, however.

This will require thinking. Jorm (WMF) 00:08, 24 August 2011 (UTC)

Disappearing compliment?

I wrote a rather flowery compliment about GlobalProfile that just got deleted, why I'm uncertain. I just hope everyone realizes it was a sincere compliment, however unorthodox. My apologies if it should not have been place here. --HectorMoffet (talk) 07:16, 10 March 2012 (UTC)

Languages

Good points! Good to finally have languages as structured data. Few confirmations and suggestions:

• Do distinguish between reading and writing skills as suggested.
• So as not to reinvent the wheel and be compatible with the rest of the world, use the [:en:Common European Framework of Reference for Languages CEFR] codes for skill levels. Old Babel system codes can be mapped.
• Allow users to specify their languages even when not in predefined lists. There are thousands of languages and variants not yet in current directories of languages. We should not miss them. Purodha Blissenbach (talk) 18:23, 21 May 2013 (UTC)

Collected Data - Future elements - suggestions

Re: GlobalProfile/design#Collected Data and the "future elements" list. This is a thread to gather other suggestions. –Quiddity (talk) 21:33, 28 November 2013 (UTC)

As a user, I'd like quick-links to the foreign/sister projects that I'm active on. Even just a basic link to m:Special:CentralAuth/Quiddity (and a better default sort-order there) would be helpful.

Currently, I make a manual list at w:User:Quiddity#Other project watchlists, which works, but is imperfect. –Quiddity (talk) 21:33, 28 November 2013 (UTC)

See also d:Special:PermaLink/91313584#Watchlists. Helder 11:10, 3 December 2013 (UTC)

As a power-user, I'd like to more easily discover interesting gadgets and scripts, to increase my efficiency and happiness as an editor. I'd like to see which of the Special:Preferences#mw-prefsection-gadgets someone else has enabled (if they select a checkbox to make that info public), and also to get quick links to a user's vector/common/global .css and .js files. - (Every few months, I discover a new script or gadget, that I wish I'd known about long before. Other editors who do the same tasks I do, probably have good tips and tricks, but it's hard to find out.) –Quiddity (talk) 21:34, 28 November 2013 (UTC)

You may want to take a look at b:pt:User:Helder.wiki/Tools/UserPages.js (specifically "getUserTools" and "processUserTools").

(and maybe Gadgets 3.0 too) Helder 11:15, 3 December 2013 (UTC)

Interesting script, thanks! And yes, I'm greatly looking forward to improvements in Gadgets. –Quiddity (talk) 18:26, 3 December 2013 (UTC)

Very interesting question, Quiddity! Why are you asking? Can we expect a reactivation in this area? Just in case it's useful, last Spring I tried to work on something similar to Global Profile, but for the MediaWiki / Wikimedia tech community. The initiative was stopped, after reaching to the conclusion that the best was to be patient and wait for Global Profile etc. See Project:New_contributors/Roadmap#People.

Suggestions:

• Location. All the better if defined by fuzzy coordinates, so it would be possible to check nearby. See Bug 55626 - Relating tech contributors with countries
• Associations also with external organizations e.g. contributors to open knowledge / free software projects. See Bug 53489 - Relating tech contributors with organizations
• Social media usernames, connecting your Wikimedia profile with your other identities out there. Qgil (talk) 00:23, 14 December 2013 (UTC)

There's no re-activation afaik, I was just looking at the page again, and having ideas, and noting them down in case they were useful later on.

The whole concept has pleasant echoes of iGoogle, which I miss. Useful user-selectable modules.

I really like some of the elements in the old mockups, and I think it would be good to

• get more examples (because whilst it looks great with Jorm's details, how would it work for others?)
  • of newcomers - showing what a sparse page would/could look like
  • of power-users - showing how adaptable it could be. (eg. my volunteer userpage is an abundance of bookmarks - things that I use daily (which I try to keep above the 'fold'), or things that I want other people to stumble upon)

Relatedly, Enwiki has the ~7 year old w:WP:User page design center which contains some good ideas, and some ghastly aesthetic-mixing, and an overwhelming proliferation of options. I'm horrified that anyone might send a newcomer there, but it's the best breakdown of 'available modules' that I know of.

(Thanks for the link to Project:New contributors, I've watchlisted those pages, and will absorb on a later day.) –Quiddity (talk) 19:37, 16 December 2013 (UTC)

Actually, I'm going to be cranking this up again very soon. Jorm (WMF) (talk) 19:43, 16 December 2013 (UTC)

OpenBadges

In the following months we are going to experiment a bit with OpenBadges, in the context of the Facebook Open Academy program and under the coordination of Parent5446. Those badges are related to MediaWiki users, therefore they have some relation with this GlobalProfile feature.

Adding a note here just in case. Qgil (talk) 22:48, 7 January 2014 (UTC)

Cool!

Do they plan to build actual integration in terms of Open Badges in the user interface? Or just do the plumbing for a badge backpack etc. in MediaWiki? Steven Walling (WMF) • talk 19:56, 9 January 2014 (UTC)

At this point we don't know yet. Qgil (talk) 20:46, 9 January 2014 (UTC)