EE

ee@lists.wikimedia.org

502 discussions

Re: [EE] Usability interviews for The Wikipedia Adventure
by Jacob Orlowitz 05 Apr '13

05 Apr '13

I'm conducting some usability testing for TWA, as part of an IEG grant and also for a Coursera course on Human-Computer Interaction Design. I thought I'd share the highlights with this list. The second interview has some feedback on the new Getting Started flow. --Jake (Ocaasi) INTERVIEW ONE Thoughts on vandalism in articles: "You know it's going to be fixed eventually." If you edit: "I'm kind of old, using Wikipedia for a long time, not like I can interact with it...It's like an encyclopedia for me. I know I can edit it, but..." What you'd fix: Wouldn't fix a joke (vandalism) but would fix an error Sign-up: "Creating an account annoys me" Userpage: "Creating a userpage is confusing" First impression: "I could totally get obsessed with this. This could definitely suck me in. This could be bad." Reliability: "If you look it up [the citation] you find out--it's real. My little sister and brother can use Wikipedia [in school] Likelihood you'd edit in the next week knowing what you know now (1-10): 8 Could you figure it out on your own: "I'm not that tech savvy. I'm not a computer person. I'm not that confident...I feel like I'm smart enough to edit it. Unsure what would happen if I clicked edit...uncertainty." -25 year old male from Philadelphia suburbs INTERVIEW TWO How you knew you could edit: "Because it's Wikipedia" Would you edit: "A huge amount of motivation would be needed to edit it" Not a typo, not an incomplete section, not an incorrect fact, not bias about a subject or about a topic of interest. "Only an article that impacted me personally, my company or product...something I'm personally invested in. "I'm generally a lurker." Expectations: "I would hope that it's easy to edit." Register an account: "I wouldn't read the sign-up instructions. I'd read as little as necessary." Username was already taken but no warning was given. "Captcha is annoying. I've seen better login flows." Getting started tour: It doesn't mention the word edit, or 'here's how you can help'. Doesn't feel like an invitation to edit or participate. Creating a userpage: Clicked the [start userpage link]. "Legal jargon" at the top, looks like "nothing vulgar or obscene and anything you put on Wikipedia is up for grabs for anyone". Notice the 'html' tags when bolding a word. Would prefer a WYSIWY editor. "It feels like it could reassure me a little bit along the way. I'm not confused but I'm more engaged than I want to be. It's forcing me to pay attention and to read directions. I'm mildly disappointed in the interface. It's not the worst thing in the world. It's eh, meh. It's not like I'm going to break up with you, but... I'm not sure how long this is going to last." Searching for a user's talk page: Search for username leads to articles not userpages. Forced to explore the navigation options. "At this point I'm lost in the abyss. This is stupid." Leaving a message on a user talk page: "Again I'm becoming confused. I expect a "message button or a send button or a compose button." Tried the [edit] link leading to the full page markup: "I don't feel welcome here. This feels insane." Went back to talk page. "I would like to redesign this thing. 'New section' is not working for me. Put a 'send' button near the username, or at the bottom. I'm comparing this to an email model but I want this to operate like a blog comments section." Signing a post: "In a million years would never have found the [~~~~] instructions. Tried to sign using markup format with ~~~~ on both sides of the text. Previewed to see that it led to a double signature and removed one. "Having to sign your own posts is ne more thing that you'd say, 'Why hasn't [Wikipedia] figured that out yet." Article talk pages: "The talk page header makes me feel like something went wrong....I see that this is not a discussion about content but about *improving* the content. But getting that out of this was like pulling teeth". "I have no idea what 'no original research means'... oh, it's giving me instructions, guidelines." On NPOV policy page: "I would go for the nutshell... 'objectivity' should be the goal. How feasible would it be to do this without a guide: "Someone would have to pay me to get as far as I did. Makes me thing this is some sort of non-profit thing that doesn't have resources to dive deeply into their UX. On lack of advertisements: Prefer banner donations to "super annoying ads watching me and tracking me. Non-profit makes it a more "trustworthy 'brand'". -20 to 30 year old male from New York

5 6

Today's deployed changes to GettingStarted
by Steven Walling 04 Apr '13

04 Apr '13

Hey all, For those of you following the "Getting Started" project we're working on in E3,[1] we made the following updates today... 1. We disabled the A/B split test, so all new users on English Wikipedia will see the latest version of Special:GettingStarted after registration. Dario and I are working on quantitative analysis about the success of this new version, and I have some qualitative analysis of the kinds of edits being made via the new version nearly ready to post. 2. Echo, the notifications feature, isn't yet deployed to English Wikipedia, but we have finished up building notifications for welcoming newly-registered people, and invite them to either make their first edit or keep going, by visiting the task list at GettingStarted. (You can't yet test these on MediaWiki.org, since GettingStarted is not deployed there. Let me know if you're interested in hearing more about these or want to try them out.) -- Steven Walling https://wikimediafoundation.org/ 1. https://www.mediawiki.org/wiki/Onboarding_new_Wikipedians

1 0

Apologies
by Isarra Yos 02 Apr '13

02 Apr '13

Hey all. It seems I have made a bit of a mess here, for which I can only apologise - things were said and certain words and feelings were exchanged that were not exactly productive. In particular I feel I should apologise to Vibha - I was feeling frustrated and unheard, but even so I realise should not have made that comment about the time it takes to make an icon, so I'm sorry. I appreciate that we are all swamped presently, and had no intention of downplaying that. Even in general, however, this has added considerable unnecessary stress, and I would like to apologise for derailing the thread like that. Much of this could have been taken to more appropriate venues or kept private, but unfortunately I acted with little forethought. Sorry about all this. I genuinely want to be helpful, but it can be difficult at times to figure out how to do that. Can we all just pretend I didn't say anything? Thanks, Kim -- -— Isarra

2 1

Echo Dismiss Feature Question
by Fabrice Florin 31 Mar '13

31 Mar '13

Hi folks, We would appreciate your views on the current version of the Dismiss feature, as described here: http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Dis… This 'Dismiss' tool enables users to turn off notifications categories they don't want to see in the flyout or the all-notifications page, so they don't have to go to the preferences page if they don't want to. If you haven't already, you can test this feature here on MediaWiki: http://www.mediawiki.org/wiki/Special:Notifications Krinkle and a couple other folks have raised concerns about this feature here on Bugzilla: https://bugzilla.wikimedia.org/show_bug.cgi?id=46587 What do you think? Is this feature useful to you in its current form? Note that currently it only lets you turn off an entire notification category (instead of just removing individual notifications). In that sense, it is similar to Facebook's 'User Opt-Out' feature, which lets you turn off notifications from an application or group, as described here: https://developers.facebook.com/docs/concepts/notifications/ Would you prefer to have the 'X' button simply close that individual notification? (without the option to turn off all notifications from that category?) Or would you prefer this compromise solution which lets you do both, as proposed earlier by Brandon: Hover over the notification and there's an "(x)" that appears on the right side. Click that and it dismisses the notification but also asks "Do you want to hide all notifications of this kind?" [y/n control] - if "n/cancel", dismiss/hide current element, do nothing else. - if "y" set "hide this type" preference for the user. show message about "you can set your preferences [[here]]" We are debating whether to change the current version of Dismiss before we deploy to en-wiki, or remove it entirely, or try it out in its current form to get more community feedback. Look forward to your recommendations! I have also attached below earlier email threads on this topic. All the best, Fabrice _____________________________________ On Mar 6, 2013, at 9:25 AM, Fabrice Florin wrote: > Thanks for all your good insights about this proposed feature, which we had planned to tackle after the first release. > > I find Facebook's approach to be pretty intuitive. It seems to be working well for people I know, and I have never heard anyone complain about it. > > With Echo, we also limit the number of notifications shown in the flyout based on your screen size, and support limited scrolling up to about 10 notifications. After that, you are encouraged to go to the 'All notifications' page, where you can find at least a week's worth of notifications (we currently support an infinite number of notifications on that archive page, but may have to cut back to a month's worth or so). > > Currently, we highlight new notifications in the flyout, so it's easy to tell them apart from old notifications, which seems effective. We then un-hilight them after you have viewed the flyout, which is also consistent with Facebook's approach. An argument could be made that perhaps we should only un-hilight that notification if you have actually clicked on it, but I believe we can wait on this until we have done a usability study. > > Since we are already using an 'X' button to dismiss notification types which you don't want to see anymore, it would be awkward to add on additional functionality to that button for dismissing just that particular notification, because it would clutter the user interface. > > So a 'Mark all as read' button might be a more effective way to address requests like Antoine's, as described in this proposed feature: > http://www.mediawiki.org/wiki/Echo/Feature_requirements#Mark_all_as_read > > Though I would argue that the current UI provides a practical solution by automatically un-highlighting notifications you have seen in the flyout, as well as limiting the number of notifications in that flyout. > > Either way, I recommend that we wait on this feature until after the first release on Enwiki, which will generate a lot of user feedback which may provide more insights from our community. > > I do not support the second suggestion to enable viewing all notifications in the flyout, which would seem highly impractical to me. That's what the "All-notification" page is for, and it's only a click away. > > My 2 cents, > > > Fabrice > > > On Mar 6, 2013, at 8:47 AM, Luke Welling WMF wrote: > >> The Facebook approach is nice. The number they show initially varies with screen resolution and their scrolling and lazy loading work well. >> >> Most of it would be relatively easy to copy, although I suspect a lot of testing (or a lot of bug reports) have gone into correctly guessing the number of elements to show based on screen size. >> >> The best thing imho about their approach is that they react to all page visits, and very clearly show a bold notification for a notification sent after you visited that page and a more subtle version for a notification that you have already seen the triggering change for. >> >> That's how they solve the feeling of being overwhelmed by notifications. It keeps the new number down and means that a new notification should only refer to a change you have not seen. >> >> Sadly most people (including us) compromise and show notifications as "new" if you have not seen the notification before, and clear their new status before you click through rather than maintaining the relationship between trigger and notification to give a more accurate version of "new". >> >> The Quora compromise on the same UI feature is different but silly. They keep notifications marked new until you manually clear them. I rarely use Quora and have a completely useless readout that tells me I have 200 new notifications. >> >> Unfortunately I think adding "untriggers" alongside all the notification triggers is significant work, so it should remain a potential future enhancement. >> >> Luke Welling >> >> >> On Tue, Mar 5, 2013 at 9:13 PM, Erik Moeller <erik(a)wikimedia.org> wrote: >> On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote: >> > Both Antoine (hashar) and Reedy have mentioned that they want the ability to >> > remove individual notices after they are read (or clear all read >> > notifications) from the flyout. >> >> One thing I'm wondering about is whether the high number of notifs >> that are immediately displayed when you click may be contributing to >> that - the feeling of being overwhelmed by old notifs + desire to make >> some disappear. FB/web has a pretty sophisticated approach: >> >> 1) On first click you have a smaller window of notifications (4-5). >> 2) Once you attempt to scroll the notifs list expands vertically to >> accommodate a longer list. >> 3) Scrolling supports dynamic loading of additional notifs for roughly >> a week's of backlog (which seems to be identical to what's available >> in "See all"). >> >> -- >> Erik Möller >> VP of Engineering and Product Development, Wikimedia Foundation >> >> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate >> >> _______________________________________________ >> > On Mar 5, 2013, at 5:51 PM, Steven Walling wrote: > >> >> On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote: >> Both Antoine (hashar) and Reedy have mentioned that they want the ability to remove individual notices after they are read (or clear all read notifications) from the flyout. >> >> This I definitely agree with. You see this pattern in notifications in several contexts (Android ICS has it, Quora, FB I think?). >> >> >> I'm not sure this is a great idea. If someone really wants to focus on viewing and responding to all unread notifications, asking them to go to a queue of it is likely the simplest and best UX choice IMO. >> >> >> -- >> Steven Walling >> https://wikimediafoundation.org/ >> _______________________________________________ > > On Jan 11, 2013, at 11:59 AM, Fabrice Florin wrote: I agree with Kaldari on this point. We need to keep this feature simple - and make it easy for users to turn it on or off. We already have a user preference for it here: http://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-echo Currently, it disables email notifications only. But given that Wikipedians may want more control, a case could be made that these preferences could apply to both onsite and email. Or we could have separate checkboxes for these options, for even more granularity, as Google does (see screenshot). Another option is to provide the dismiss option in the flyout, which we discussed in a separate thread, as Facebook does (see screenshot). This would enable users to completely remove notification types they don' want, both onsite and by email. I propose we discuss this with Vibha during our meeting with her on Monday and reach a resolution then. If the solution is simple, we can push it in our next deployment on Thursday. Until then, please turn off the user preference for this feature if it really bothers you. Thanks, Fabrice On Jan 10, 2013, at 1:50 PM, Brandon Harris wrote: On Jan 10, 2013, at 1:46 PM, Matthew Flaschen <mflaschen(a)wikimedia.org> wrote: I agree. Not just, "dismiss this one", but "Don't show this type of notification again" right on the notification itself (not necessarily those phrasings). Hover over the notification and there's an "(x)" that appears on the right side. Click that and it dismisses the notification but also asks "Do you want to hide all notifications of this kind?" [y/n control] - if "n/cancel", dismiss/hide current element, do nothing else. - if "y" set "hide this type" preference for the user. show message about "you can set your preferences [[here]]" --- Brandon Harris, Senior Designer, Wikimedia Foundation On Thu, Jan 10, 2013 at 1:33 PM, Fabrice Florin <fflorin(a)wikimedia.org> wrote: I agree with Matt and Oliver as well. I don't think we can avoid giving people individual control of which notifications they receive. But I definitely think that adding a dismiss option in the flyout is an effective way to give people that control, so they don't have to go to the preferences page if they don't want to. I also think that bundling can help in a number of ways, as outlined in my feature list below (I am including the entire thread, to make sure nobody feels left out from that discussion) I will create a feature requirement stub for both options (and a few more) in coming days, and we can prioritize them as a team in next week's planning session. But this discussion is touching upon the central challenge for this product: how to make sure that we inform people without spamming them. It will take us a while to completely solve this challenge, but we should not ship anything that doesn't have some good solutions to this difficult problem, IMHO. Cheers, Fabrice On Tue, Jan 8, 2013 at 10:35 PM, Erik Moeller <erik(a)wikimedia.org> wrote: On the "easy to disable" front, I'm not sure if this is on the roadmap already, but having an inline way to dismiss notifications of a certain type would IMO be nice, e.g. a simple "Disable this type of alert" link within the actual notification itself. On 9 January 2013 11:35, Oliver Keyes <okeyes(a)wikimedia.org> wrote: On 9 January 2013 06:47, Steven Walling <swalling(a)wikimedia.org> wrote: Great idea! Giving people an immediate touch point means they feel like they have control, like swatting a fly.

12 40

Re: [EE] The Wikipedia Adventure as a GuidedTour
by Thehelpfulone 31 Mar '13

31 Mar '13

Forwarding this to the list because Jake was having some problems with Mailman. - THO ---------- Forwarded message ---------- From: Jacob Orlowitz <jorlowitz(a)gmail.com> Date: 29 March 2013 23:43 Subject: Re: [EE] The Wikipedia Adventure as a GuidedTour To: ee-owner(a)lists.wikimedia.org Hey folks :) I'm super excited about this project. I think you've created a great tool in guided tours and I'm looking forward to utilizing it to its full potential and in some new and perhaps unexpected ways. I'm going to pop into IRC next week to introduce the concept a bit more fully and look forward to sharing ideas. Just for clarity, I'm well aware that this project has to happen independent of EE involvement... That said, I know you're a great resource of experience and knowledge about attracting new editors, and I hope to pick up some tricks and guidance as I move forward. Best, Jake Orlowitz (Ocaasi) > > On Fri, Mar 29, 2013 at 6:51 PM, Matthew Flaschen <mflaschen(a)wikimedia.org > > wrote: > >> On 03/07/2013 07:23 PM, Siko Bouterse wrote: >> > This newest grant proposal is actually to use the existing functionality >> > of Guided Tours and add a narrative and gamification elements on top of >> > it using simple on-wiki tools in order to build The Wikipedia Adventure >> > on-wiki (eliminating the need for separate dev or hosting). >> >> Ocaasi's proposal was just approved as an Individual Engagement Grant. >> https://meta.wikimedia.org/wiki/Grants:IEG/The_Wikipedia_Adventure >> >> Congratulations! :) >> >> Matt Flaschen >> > > > -- Jake Orlowitz Wikipedia: Ocaasi <http://enwp.org/User:Ocaasi> Facebook: Jake Orlowitz <http://www.facebook.com/jorlowitz> Twitter: JakeOrlowitz <https://twitter.com/JakeOrlowitz> LinkedIn: Jake Orlowitz<http://www.linkedin.com/profile/view?id=197604531> Email: jorlowitz(a)yahoo.com Skype: jorlowitz Cell: (484) 684-2104 Home: (484) 380-3940 -- Thehelpfulone https://meta.wikimedia.org/wiki/User:Thehelpfulone

1 0

The Wikipedia Adventure as a GuidedTour
by Matthew Flaschen 31 Mar '13

31 Mar '13

Ori pointed me to https://en.wikipedia.org/wiki/Wikipedia:The_Wikipedia_Adventure (prototype at http://en.wikipediaadventure.org/). It's basically a game that walks you through becoming a Wikipedia editor. It has its own rough tour library, but it seems like they could use GuidedTour to great effect. The code (http://en.wikipediaadventure.org/w/skins/common/tutorial.js) is under the public domain, so we might be able to use some snippets as well. The script is pretty elaborate (https://en.wikipedia.org/wiki/Wikipedia:The_Wikipedia_Adventure/Script) Matt Flaschen

4 6

Today's feature updates from Editor Engagement Experiments
by Steven Walling 28 Mar '13

28 Mar '13

Hi all, This week the "Getting Started" feature by the Editor Engagement Experiments team has been on hold while we work on future designs, data analysis, and Echo notifications to go with it, but we did deploy a few significant updates today... *Account creation and login redesign: *We turned off the experimental implementation of the new account creation interface on English Wikipedia. S Page, Munaf, and the rest of the team have been hard at work prepping a version of both the account creation and login redesign for MediaWiki core, and we need to turn off the previous version to make way. Commits for this are undergoing review, and after they're merged and the next biweekly MediaWiki release happens, you'll be able to test it out and give us feedback on an opt-in basis locally, before it's made the default everywhere. Look for another announcement about that in the coming weeks. :) *Guided tours: *We added GuidedTour to Portuguese Wikipedia, bringing it to a total of about 15 communities where you can build and use tours. *Last but not least: *We removed Extension:LastModified (the experiment with adding a timestamp of the last change, linking to the history). This was an experiment that we decided not to make a permanent feature since it didn't really lead to any gains in active contributors to articles. Some community members have expressed interest in the feature, so if you're looking for a side project that needs some love and care, this extension is ripe for cleanup and redeployment. -- Steven Walling https://wikimediafoundation.org/

1 0

HTTP protocol (Re: Newbie99 thanked you for your edit on MediaWiki)
by Terry Chay 28 Mar '13

28 Mar '13

> On 26 March 2013 18:37, Steven Walling <swalling(a)wikimedia.org> wrote: > > On Tue, Mar 26, 2013 at 11:34 AM, Oliver Keyes <okeyes(a)wikimedia.org> wrote: > I got one too. My question (asked on IRC, but throwing out here for wider discussion): what's the rationale with directing people to the non-secure site? Did Ops object to https? > > For reference: our current emails direct to vanilla HTTP, e.g. non-Echo stuff. It might be a more general request to make of Ops. > > On Tue, Mar 26, 2013 at 9:00 PM, Fabrice Florin <fflorin(a)wikimedia.org> wrote: > > On Mar 26, 2013, at 5:43 PM, Oliver Keyes wrote: > >> >> >> On 27 March 2013 00:37, Fabrice Florin <fflorin(a)wikimedia.org> wrote: >> Thanks, Oliver. >> >> I would give the 'HTTPS' feature a lower priority than getting Echo deployed on time. This is something we can revisit after we are deployed, I don't view it as a blocker for now. >> >> Sure, I don't think it's a blocker at all. But it's not a particularly big change, either ;p. > > Cool. I just want us focused on the most important features first, so we can ship on time ;o) On Mar 26, 2013, at 7:49 PM, Luke Welling WMF <lwelling(a)wikimedia.org> wrote: > The easy way of changing to https looks to be adding a single character to the definition of $wgServer in LocalSettings.php. $wgServer is used everywhere, I believe even for reader access, so I vote strongly against this change. ;-) Normally the correct way of handling this is WebRequest::detectServer() which uses the protocol of the user's browsing state (if https, then https). I take this is a problem because the messages are decoupled between the event trigger and the recipient? BTW, this sort of mediawiki discussion should probably be on a lis where much more experienced mediawiki devs can answer, so I'm moving it there. > > That would change it in a few other places though, so sounds like 1 second of editing and 1 day of testing. > > We could hack it in just for Echo, but that would either be hacky and specific to targeted installations or break on installs that don't have identical http and https urls. BTW, my opinion is I'm okay with using http://... ($wgServer) right now for release and just capturing this request as a bug in bugzilla or in Trello for now.

2 1

Opting out of individual Echo notifications
by Thehelpfulone 27 Mar '13

27 Mar '13

Hi all, I've been playing around with Echo on MediaWiki.org and noticed that in my preferences I can configure a number of different notifications. (See https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-echo) I've also tested the User Right notifications that were just deployed and whilst you receive an email when you have a user right *added *to your account, you don't currently get one when a user right is *removed *from your account. That's probably an oversight, but from what I've been told the option to opt out from any email notifications intentionally isn't available so as to reduce the number of preferences for users to configure. Another justification is that a user is unlikely to have their user rights changed too often, so email traffic should be minimal. This seems reasonable, but for future notifications, how are we going to decide whether something is worth a preference or not? I'm thinking that anything that technically affects your editing, e.g. a notification that you've been blocked or renamed (if Echo supports that in the future) would be something that probably shouldn't be opt-out-able. Can anyone think of any other notifications that should not be opt-out-able (or does anyone think that all notifications should be individually opt-out-able?) -- Thehelpfulone https://meta.wikimedia.org/wiki/User:Thehelpfulone

6 11

Echo Update | New version on MediaWiki.org
by Fabrice Florin 27 Mar '13

27 Mar '13

Hello everyone, We'd like to give you a quick update on Echo and let you know about today's deployment on MediaWiki.org. The project is coming along nicely, and we keep adding new features every week. Here are some highlights. 1. Today's deployment Benny and Kaldari just deployed a couple new features on MediaWiki.org today: • Dismiss (turn off notification types from the flyout or all-notifications page) • Web Preferences (control which notification types to include on your flyout or all-notifications page) These features are not in their final form yet, but already provide a lot more control over which notifications you receive on the web or via email. Stay tuned for more … If you experience any issues, please file a bug here on Bugzilla, or post a note on this talk page. For detailed instructions on how to test the current version of Echo, check out this updated testing page: https://www.mediawiki.org/wiki/Echo_(Notifications)/Testing 2. Next features Our next Echo deployment is now scheduled for the week of March 4th. The team is now working on these features for that deployment: • Bundling • JobQueue • Metrics • HTML Email Learn more on our feature requirements page: https://www.mediawiki.org/wiki/Echo/Feature_requirements#Metrics 3. Next notifications We aim to develop these notifications for our first release: • User Mention • Welcome (in collaboration with E3) • How to use your watchlist (in collaboration with E3) • Thank you (positive notification) • User rights (power user request) Here's a short list of notifications planned for our first release: https://www.mediawiki.org/wiki/Echo/Feature_requirements#First_Notifications 4. Project Goals We are on track for a first limited deployment on the English Wikipedia in late March/early April, if all goes according to plan. Here are our goals for this quarter (January-March 2013): • focus on new users (but make it usable by experienced editors) • complete core features (flyout, "archive", prefs, job queue, bundling, metrics, HTML email) • add a few more notifications ("happy path" for new users, useful notices for power users) • deploy limited release on en-wiki (different defaults for new and experienced users) • fix bugs + critical feature tweaks (as needed, prioritized by urgency) • provide in-house developer support (through hooks, i18n and dev guidelines) • estimate maintenance + i18n support (for 2013-2014 plan) Find out more in this short-term timeline and longer-term roadmap, as well as these project slides. Enjoy! Fabrice and the Echo team _______________________________ Fabrice Florin Product Manager, Editor Engagement Wikimedia Foundation http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF) Donate to keep Wikipedia free: https://donate.wikimedia.org/

3 4

← Newer
1
...
41
42
43
44
45
46
47
...
51
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

EE