Re: [Foundation-l] Feedback tab on the English Wikipedia

[Howie Fung]

A couple quick comments:

For folks that are interested in this topic, please consider attending
Oliver's Office Hours on the topic.  Oliver hosts an IRC Office Hours
approximately every week to discuss the project.  Some are about specific
topics (e.g.., today's is about oversight of comments and is thus limited
to oversighters), but most are general purpose discussion where we discuss
stuff like design direction, general workflows, and DATA.  Here's a link to
the WMF office hours schedule (Oliver's Office Hours are always listed
here): http://meta.wikimedia.org/wiki/IRC_office_hours

One of the goals of this project is, as David states, increasing reader
engagement.  Ultimately, we hope that a percentage of the readers that
leave constructive comments will become editors.  We need to add feedback
loops where if someone leaves a great comment that's acted on by the
editors, that reader gets notified.  Hopefully that loop will work to draw
in readers by piquing their curiosity (and also providing some positive
feedback of "Hey look!  They took my suggestion -- and by the way, what are
they doing on this talk page thing. . ."  We need to get through a few more
baseline features before we start thinking more closely about the feedback
loop, but I at least wanted to put it out there.

Also, there will be some readers that simply will not become editors, and I
think that's okay.  Having them provide constructive feedback about what
their information needs are as readers, I think, is better than having them
not involved at all.  There is, of course, the signal to noise ratio, which
is one of the things that Oliver, Aaron Halfaker, and Dario have spent
quite a bit of time researching.  Having said that, we do need to be
careful about creating a "someone else's problem" dynamic.  One way to do
this is to keep making sure these readers know that they can make the
change themselves.

Howie

On Thu, Feb 9, 2012 at 5:00 AM, Oliver Keyes  wrote:

> That's the plan. Neil, this is a concern we've taken into account; we'll be
> testing whether (for example) the presence of the feedback page adds 2,000
> comments, but kills half of our anonymous edits, or whatever. If the harm
> outweighs the benefits, we'll go back to the drawing board.
>
> On 9 February 2012 10:38, David Gerard  wrote:
>
> > On 9 February 2012 09:04,   wrote:
> >
> > > I guess my concern is that it may encourage readers to type in
> > suggestions and take it no further rather than take the next step and
> begin
> > editing themselves.
> >
> >
> > At present, the average reader doesn't even fix typos.
> >
> >
> > > Definitely important to watch for any changes in the rate of new
> editors
> > contributing. It also implicitly makes it "someone else's problem" to fix
> > things compared to our current stock response of "if you see things that
> > could be better, fix it yourself. " I'm not saying this is intended but
> it
> > runs the risk of making projects look they have people exercising
> editorial
> > control.
> >
> >
> > If it's getting any increased reader participation in any way at all,
> > that's a big improvement over the present. Let's see how it works out.
> > (With numbers.)
> >
> >
> > - d.
> >
> > ___
> > foundation-l mailing list
> > foundation-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
> >
>
>
>
> --
> Oliver Keyes
> Community Liaison, Product Development
> Wikimedia Foundation
> ___
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] Fw: Strike against the collection of personal data through edit links

[Howie Fung]

We would be able to look at just the edit summaries, but that would only
provide us with analysis on edits that were successfully completed.  By
including the actual clicks in the tracking, we can do analysis on the
edit/save ratio (% of total edit attempts that were successfully saved).

Howie

On Sat, Feb 4, 2012 at 6:09 PM, Brandon Harris wrote:

>
>I'm not sure why this couldn't be done if that were all that is
> being measured.  I suspect there's other behaviors being tracked.
>
>As I said, I'm not the person who knows most about this, so you
> have to take what I am saying with a grain of salt.
>
>
>
> On 2/4/12 5:21 PM, WereSpielChequers wrote:
>
>> Hi Brandon, thanks for the explanation, but wouldn't it be easier to just
>> analyse edit summaries? If you edit by section the edit summary defaults
>> to
>> start with the section heading...
>>
>> Were SpielChequers
>>
>> Message: 7
>>
>>> Date: Sat, 04 Feb 2012 14:51:49 -0800
>>> From: Brandon Harris
>>> To: foundation-l@lists.wikimedia.**org
>>> Subject: Re: [Foundation-l] Fw: Strike against the collection of
>>>personal data through edit links
>>> Message-ID:<4F2DB685.7@**wikimedia.org<4f2db685.70...@wikimedia.org>
>>> >
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>
>>>
>>>(This may not be 100% accurate; the person who knows most about
>>> this is
>>> on vacation, but I'll try to explain to the best of my understanding.)
>>>
>>>Those weird URLs are part of a clicktracking process.  It's a test
>>> to
>>> see how people go about editing the page *most often* (by section, or by
>>> edit tab) and further to see how effective various calls-to-action (such
>>> as those given by Article Feedback) are.
>>>
>>>The longevity of the data isn't something I can comment to but I'd
>>> be
>>> surprised if it lasted even 3 months.  I do not know if there are
>>> identity markers connected to them but I wouldn't be surprised.
>>>
>>>To that end, the data is only useful in roll-ups, and wouldn't be
>>> something published anywhere except in aggregate.
>>>
>>>
>>>
>>> On 2/4/12 2:27 PM, Philippe Beaudette wrote:
>>>
 MZ is correct:  3 months is the purge for Checkuser data.

 As to the rest of it, Diederick van Liere, our resident guru of data,

>>> will
>>>
 be checking into this, and will confirm back when we know exactly wht is
 intended by the devs for that data.  I will say that generally speaking,
 the Foundation prefers to maintain the minimum data possible for the
 shortest period of time.

 Thanks,
 pb
 ___
 Philippe Beaudette
 Head of Reader Relations
 Wikimedia Foundation, Inc.

 415-839-6885, x 6643

 phili...@wikimedia.org

 To check my email volume (and thus know approx how long it will take me

>>> to
>>>
 respond), go to http://courteous.ly/hpQmqy



 On Sat, Feb 4, 2012 at 2:19 PM, MZMcBride   wrote:

  Fred Bauder wrote:
>
>> David Gerard wrote:
>>
>>> 3 months I can live with :-) Can someone from WMF just confirm what
>>>
>> data
>>>
  is kept for how long?
>>>
>>
>> The exact time is confidential.
>>
>
> Err, no, I don't think so. It's not defined in the files at
> >,
> which means it should be using the
> default, as defined at
> <
>
>  http://svn.wikimedia.org/**viewvc/mediawiki/trunk/**
>>> extensions/CheckUser/CheckU
>>>
 ser.php?revision=106556&view=**markup>. From that file:
>
> ---
> # How long to keep CU data?
> $wgCUDMaxAge = 3 * 30 * 24 * 3600; // 3 months
> ---
>
> The last attempt to change this value (without community discussion)
> was
> summarily shot down:
>  revision&revision=40847
>
 .

>
> That's only CheckUser data, though. I'm not sure what David wants
>
 confirmed
>>>
 from the Wikimedia Foundation. Different data has different expiries. A
>
 lot
>>>
 of it is permanent (e.g., revisions aren't going anywhere for the most
> part). I guess the question is specific to the ClickTracking extension:
> 
> >?
>
> MZMcBride
>
>
>
> __**_
> foundation-l mailing list
> foundation-l@lists.wikimedia.**org 
> Unsubscribe: https://lists.wikimedia.org/**
> mailman/listinfo/foundation-l
>
>  __**__

Re: [Foundation-l] [Wikimedia Announcements] Announcing Howie Fung as Director of Product Development

[Howie Fung]

Great question :).  I think the best way to answer is by example.

In addition to our mobile projects (which Erik referred to in his original
email), the Article Feedback Tool 5 project on the English Wikipedia
provides a good example of how the product group works [1].  The goal of
this project is to develop the next version of the feedback tool that is
currently on the bottom of articles on the English Wikipedia.  The basic
approach is to test a number of new feedback forms in order to see which
one is the best at engaging our reader community to help build the
encyclopedia [2].

In this project, Fabrice Florin is the Product Manager, responsible for
setting the overall direction for the project, as well as determining which
features to prioritize into which releases.  He does this in partnership
with a bunch of other folks, both at WMF and in our communities.  Oliver
Keyes, our Community Liaison, is responsible for reaching out to the
editing community and getting their input on key product decisions.  Oliver
has been holding weekly office hours  where we review the progress on the
project and get input from the community.  In this project, input from the
community consists not only of input on the designs, but also an evaluation
of the quality of feedback/comments left by readers.  To get a feel for
what is discussed during these office hours, please see the most recent one
at [3].  Brandon Harris, Senior Designer, provides design direction for the
project.  This includes helping the team understand user needs and how they
are met from a UX standpoint.  Dario Taraborelli, Senior Research Analyst,
provides the much needed analytical support for developing the feature (see
[4] for the dashboards he developed for the project).  The area where this
project differs from the ones WMF typically undertakes is that the actual
software development is done by an external vendor (OmniTi), vs. WMF staff
or volunteer developers.

In short, I would look for this type of general model when it comes to
product development -- a heavy emphasis on collaborating with the community
as well as analysis on how these features are performing.  One more thing
I'll also say is that, as Erik mentioned, we are using agile methodologies
for software development -- rapid iterations with quick feedback.  In many
of our features, we've been doing weekly to bi-weekly sprints.  We intend
to keep rapid cycle of deploy-measure-improve.

Howie

[1] http://www.mediawiki.org/wiki/Article_feedback/Version_5
[2]
http://blog.wikimedia.org/2011/12/20/a-new-way-to-contribute-to-wikipedia/
[3] http://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2012-01-27
[4] http://toolserver.org/~dartar/

On Mon, Jan 30, 2012 at 1:48 PM, Bod Notbod  wrote:

> On Mon, Jan 30, 2012 at 20:03, Howie Fung  wrote:
>
> > If anyone has any questions about the product group (e.g., what to
> expect,
> > how it's organized, how we work with the community and other groups),
> > please drop me a line.
>
> I'm going to do the unforgivable... OK, what can we expect? :O)
>
> Bodnotbod
>
> ___
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] [Wikimedia Announcements] Announcing Howie Fung as Director of Product Development

[Howie Fung]

Thanks everyone!  I'm really looking forward to continuing to work with the
community & Foundation on some cool and important stuff!

If anyone has any questions about the product group (e.g., what to expect,
how it's organized, how we work with the community and other groups),
please drop me a line.

Howie

On Mon, Jan 30, 2012 at 10:32 AM, Thehelpfulone  wrote:

> On 30 January 2012 18:26, Patricia Pena  wrote:
>
> > Congrats, Howie!
> >
> > On Mon, Jan 30, 2012 at 10:07 AM, Erik Moeller 
> wrote:
> >
> > > Hello all,
> > >
> > > It’s with great pleasure that I announce the promotion of Howie Fung
> > > to the position of Director of Product Development at the Wikimedia
> > > Foundation, effective February 1.
> > >
> > > Howie joined us in October 2009 as a consultant for usability
> > > projects, and became a permanent staff member in May 2010. Prior to
> > > Wikimedia, Howie was Senior Product Manager at Rhapsody, where he
> > > helped grow the music site's traffic five-fold within the the first
> > > year on the basis of extensive customer research, including web
> > > analytics, focus groups, user testing, and customer surveys. Prior to
> > > that, Howie was Product Manager at eBay, prioritizing features based
> > > on business objectives, usability studies, and economic impact.  He
> > > has an MBA from The Anderson School at UCLA and a Bachelor of Science
> > > in Chemical Engineering from Stanford University.
> > >
> > > I’m really proud of all the work Howie’s done for Wikimedia since he’s
> > > joined, calmly and rationally introducing method where there was
> > > madness, always challenging us to increase our understanding of our
> > > communities and to use our limited resources for the projects that are
> > > likely to have the highest impact. In addition to the work he’s done
> > > on the Usability Initiative, he’s worked on a variety of projects,
> > > including the Editor Trends Study, the Former Contributors Survey, the
> > > Article Feedback Tool, Moodbar, and the Feedback Dashboard.  We’re
> > > very lucky to have him in this new role.
> > >
> > > This announcement also means that we’re formally establishing a
> > > Product Development department at Wikimedia, which is part of the
> > > larger Engineering department. Product, in our context, means really
> > > digging into what we want our projects to look like in a year, in two
> > > years, in three years, and working together with software developers
> > > and architects, as well as across Wikimedia, to make that vision a
> > > reality.  Our work will be organized along the following product
> > > areas: Editor Engagement, Mobile, Analytics, and
> > > Internationalization/Localization.
> > >
> > > The following staff and contractors will be part of the Product group,
> > > going forward: Phil Chang, Brandon Harris, Fabrice Florin, Diederik
> > > van Liere, Siebrand Mazeland, Dario Taraborelli, Oliver Keyes, and the
> > > new Interaction Designer, when hired.
> > >
> > > The Mobile team, which works on both mobile apps (such as the
> > > Wikipedia Android app) and the mobile web experience, is a good
> > > example of how this works in practice. It has Phil as a product owner
> > > (reporting to Howie), Tomasz as a scrum master and engineering
> > > director, and Patrick, Arthur, Max, and Yuvi as engineers (reporting
> > > to Tomasz). The team itself is the most important unit here: it drives
> > > the success of any given initiative. The connection into the Product
> > > Development group helps to ensure we follow a consistent strategy and
> > > coordinate efforts across the board. [1]
> > >
> > > This is an important step in our organizational development and will
> > > help us parallelize and coordinate product and engineering work more
> > > effectively.
> > >
> > > Please join me in congratulating Howie, and WMF. :-)
> > >
> > > All best,
> > >
> > > Erik
> > >
> > > [1]  In case you’d like to learn more about agile product development
> > > and software engineering, this presentation is a good intro to scrum,
> > > a specific methodology we've started to use on a couple of teams:
> > >
> >
> http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum
> > >
> > >
> > > --
> > > Erik Möller
> > > 

[Foundation-l] Feedback Dashboard launched today

[Howie Fung]

Hey Everyone,

I wanted to let everyone know that earlier today, we launched the Feedback
Dashboard:

http://en.wikipedia.org/wiki/Special:FeedbackDashboard

This dashboard is a running list of comments that new editors submitted via
Moodbar (http://www.mediawiki.org/wiki/MoodBar).   The idea behind this
feature is to capture, in a lightweight fashion, the editing experience of
folks that are just starting out.  After either attempting or submitting an
edit, new editors get an invitation in the upper left hand corner inviting
them to provide feedback on their editing experience.  The Feedback
Dashboard provides a feed of these comments.

This feature is still experimental, so please excuse any wonkiness and let
us know of any bugs you find.

Take a look to find out what makes new editors Happy, Sad, or Confused!
Also, if you'd like to either comment on the feature or participate in its
further development, please leave a message here [1] or here [2].

Howie

[1] http://www.mediawiki.org/wiki/Talk:Feedback_Dashboard
[2] http://en.wikipedia.org/wiki/Wikipedia_talk:New_editor_feedback
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Announcing Fabrice Florin and Oliver Keyes

[Howie Fung]

Everyone,

I am pleased to announce that we have two contractors joining the Technology
team.  Fabrice Florin will be joining us for the next six months as Product
Consultant, leading the development of the next version of the Article
Feedback Tool.  Oliver Keyes (User: Ironholds on enwp) will be joining us as
a community liaison for the next three months.  His role is to help ensure
that the community input is better incorporated into WMF’s product
development process.

Fabrice has extensive background in the fields of education and journalism.
 He is founder and executive director of NewsTrust, a nonprofit social news
site devoted to good journalism -- as well as Truthsquad, a network
dedicated to fact-checking the political claims made during election
campaigns.  His previous ventures include: Handtap, a wireless content
service for mobile phones; shockwave.com, a web entertainment site at
Macromedia; Apple Computer's Multimedia Lab, a new media R&D group; and a
variety of other roles in media and technology.  Fabrice earned four patents
for his interactive TV work at Apple and was recently elected an Ashoka
Fellow for his work as social entrepreneur [1]. Read more in his online bio[2].

Oliver has been an editor since 2006 and is both an administrator and an
OTRS volunteer on the English Wikipedia. With strong experience in content
creation as well as administrative tasks, he has a broad base of knowledge
that will undoubtedly be helpful in coordinating community feedback,
organizing discussions, and making sure more voices are heard as part of the
product development process.

As many of you know, the Tech department continues to look for ways to
gather input from our experienced editors when designing new features.
 Oliver’s job will be to act as a conduit between WMF’s development team and
members of the community, helping editors make suggestions on feature
development and helping ensure that the Foundation incorporates this input.

Fabrice may be reached at fflorin at wikimedia dot org, as well as his
userpages on the English Wikipedia and Mediawiki ([[User:Fabrice Florin]]).
 Oliver will be on the projects as [[User:Ironholds]] and [[User:Okeyes
(WMF)]]; he can also be contacted directly via
http://en.wikipedia.org/wiki/Special:EmailUser/Okeyes_%28WMF%29.

We’re very excited to be working with Fabrice and Oliver.  Please join me in
welcoming them!

Howie Fung
Senior Product Manager
Wikimedia Foundation

[1] http://www.ashoka.org/fellow/fabrice-florin
[2] http://newstrust.net/about/bio_florin
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] [Wikimedia Announcements] [Wikimedia Foundation Blog] Article feedback pilot goes live

[Howie Fung]

  Bence from the hu.wp community was kind enough to reach out via the 
Communications Committee about the hu.wp experience with the feature.  
The implementation on hu.wp actually merges article feedback with their 
implementation of flagged revs.  But according to Bence, the number of 
ratings per article is on the low end, so it may be difficult to draw 
useful conclusions for en.wp.  Still, it would be good for everyone to 
keep each other updated on how the feature is being used, what's working 
vs. what's not, etc.

Howie

On 9/24/10 10:10 PM, Amir E. Aharoni wrote:
> 2010/9/22 Guillaume Paumier:
>> Link to the original article:
>>
>> http://blog.wikimedia.org/blog/2010/09/22/article-feedback-pilot-goes-live/
>>
>> As recently announced on the tech blog and in the Signpost, we're
>> launching an experimental new tool today to capture article feedback
>> from readers as part of the Public Policy Initiative. We're also
>> inviting the user community to help determine its future by joining a
>> workgroup tasked with evaluating it.
> If i understand correctly, a very similar tool is enabled in all
> articles on the Hungarian Wikipedia for quite a long time. Just go to
> http://hu.wikipedia.org/wiki/Special:Random and look at the bottom.
> (If you can't read Hungarian, go to
> http://hu.wikipedia.org/wiki/Special:Preferences and change your
> language; English and French work.)
>
> Did anyone try to contact the hu.wp community and ask them about their
> experiences with this tool?
>
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] [Wikimedia Foundation Blog] Article feedback pilot goes live

[Howie Fung]

  Yes, that's a good idea -- we should have something that lets users 
know why the ratings tool exists.

I've created the following page on the project wiki to capture feature 
ideas:

http://www.mediawiki.org/wiki/Article_feedback/Public_Policy_Pilot/Workgroup/Feature_Ideas

Please post any ideas you may have on improving the feature here.  And 
please sign up for the workgroup [1] if you'd like to be more involved 
with the feature!

Howie

[1] 
http://www.mediawiki.org/wiki/Article_feedback/Public_Policy_Pilot/Workgroup

On 9/22/10 11:55 AM, aude wrote:
> On Wed, Sep 22, 2010 at 2:24 PM, Guillaume Paumier
> wrote:
>
>> Link to the original article:
>>
>> http://blog.wikimedia.org/blog/2010/09/22/article-feedback-pilot-goes-live/
>>
>> As recently announced on the tech blog and in the Signpost, we're
>> launching an experimental new tool today to capture article feedback
>> from readers as part of the Public Policy Initiative. We're also
>> inviting the user community to help determine its future by joining a
>> workgroup tasked with evaluating it.
>>
>>
> The "Article Feedback Tool" allows any reader to quickly and easily
>> assess the sourcing, completeness, neutrality, and readability of a
>> Wikipedia article on a five-point scale. It will be one of several tools
>> used by the Public Policy Initiative to assess the quality of articles.
>> We also hope it will be a way to increase reader engagement by seeking
>> feedback from them on how they view the article, and where it needs
>> improvement.
>>
>> The tool is currently enabled on about 400 articles related to US public
>> policy. You can see it in action at the bottom of articles such
>> as /United States Constitution/, /Don't ask, don't tell/ or /Brown v.
>> Board of Education/.
>>
> Why does the feedback tool have no reference to the public policy
> initiative?
>
> Casual users and readers will not know why they are seeing this tool in some
> articles, and may be curious.
>
> @aude
>
>
>> Another goal of this pilot is to try and find a way to collaborate with
>> the community to build tools and features. As main users of the
>> software, Wikimedians are in a unique position to evaluate how a feature
>> performs, and what its strengths and limitations are. The Article
>> Feedback Tool is still very much in a prototype state; we're hoping the
>> user community can help us determine whether resources should be
>> allocated to improve it (and if so, how), or if it doesn't meet the
>> users' needs and should be shelved or completely rethought.
>>
>> More information about the tool is available on our Questions&  Answers
>> page [1].
>>
>> If you want to try the tool to assess an article, pick a subject you're
>> familiar with from the full list [2] and rate it! If you'd like to
>> participate in the evaluation of the tool itself and what becomes of it,
>> please join the workgroup [3]. If you're interested in article
>> assessment in general, please also join the Public Policy Initiative's
>> Assessment Team [4].
>>
>> Thank you,
>>
>> Guillaume Paumier,
>> on behalf of the Features Engineering team
>>
>> [1]
>> http://www.mediawiki.org/wiki/Article_feedback/Public_Policy_Pilot/FAQs
>> [2] http://en.wikipedia.org/wiki/Category:Article_Feedback_Pilot
>> [3]
>>
>> http://www.mediawiki.org/wiki/Article_feedback/Public_Policy_Pilot/Workgroup
>> [4]
>>
>> http://en.wikipedia.org/wiki/Wikipedia:WikiProject_United_States_Public_Policy/Assessment#Project_Evaluation
>>
>> --
>> Guillaume Paumier
>> Product Manager, Multimedia Usability
>> Wikimedia Foundation
>> Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
>>
>>
>>
>> ___
>> foundation-l mailing list
>> foundation-l@lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>>
> ___
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] clicktracking

[Howie Fung]

John,

We'll get the clicktracking data up over the next several days.  The 
team has been focused preparing for the next phase of usability rollout 
tomorrow, but we'll get something up by the end of the week at the latest.

I'll have Nimish, the developer of the click-tracking tool, answer your 
questions about segmentation and anonymization as he is more intimately 
familiar with how the tracking works.  But to my knowledge, the data 
represent all users, though we may possibly be able to segment out 
certain classes of users.  You're absolutely right -- the correct point 
of comparison for this feature should be anons.  Also, the data are 
anonymized and Nimish can describe this in more detail.

As far as I know, clicktracking is not being used on English Wikipedia.  
The UX team has been using it to gain insight into very specific 
behavior patterns and then turning it off.

Howie

On 6/8/10 7:15 PM, John Vandenberg wrote:
> subject was: hiding interlanguage links by default is a Bad Idea, part 2
>
> On Sat, Jun 5, 2010 at 10:03 AM, Howie Fung  wrote:
>
>> The Usability team discussed this issue at length this afternoon.  ...
>>
>> Regarding the data behind the decision.  First, let me apologize for the
>> tardiness.  The engineer who implemented the clicktracking of the left
>> nav recently returned from vacation, so you can probably imagine how
>> things might be a little difficult to find after being away for a
>> while.   Please see [1] for more details, but a quick summary is that we
>> measured the click behavior for two groups of English Wikipedia users,
>> Monobook and Vector (Vector users are primarily those who participated
>> in the beta).  Of Monobook and Vector users, 0.95% and 0.28% clicked on
>> the language links (out of 126,180 and 180,873 total clicks),
>> respectively.  We felt that fewer than 1% of Monobook clicks was a
>> reasonable threshold for hiding the Language links, especially when
>> taken in the context of the above design principle and the
>> implementation (state persists after expanding).
>> 
>>
>> Thank you for your input.
>>
>> Howie, on behalf of the User Experience Team at WMF
>>
>> [1] http://usability.wikimedia.org/wiki/Left_Nav_Click_Data
>> [2]..
>>  
> When can we expect the clicktracking data to be available?  You
> mention "users"; do you mean registered users?  Were anonymous IP's
> considered to be a separate class of users, or were they lumped into
> the "monobook skin" numbers?  It should be obvious that hiding
> interwikis for users who are not logged in should be based on data of
> users who are not logged in and thus do not have a preference they can
> toggle.
>
> Also, I am interested in what clicktracking is occurring, whether the
> data is being anonymised before being put into the hands of the
> usability team, whether appropriately anonymised data will be
> available to other researchers, etc.
>
> This was mentioned briefly on wiki-research-l.
>
> http://lists.wikimedia.org/pipermail/wiki-research-l/2010-April/000975.html
>
> I recall similar functionality being _explicitly_ deactivated on
> English Wikipedia as soon as Matt Bisanz brought it to the attention
> of the English Wikipedia Arbitration Committee, yet the above says
> that the data was taken from English Wikipedia!
>
> http://en.wikipedia.org/wiki/Wikipedia_talk:Arbitration_Committee/Audit_Subcommittee/Archive_1#New_privacy_issue.3F
>
> The UsabilityInitiative extension is enabled on most wikis; e.g..
>
> http://en.wikipedia.org/wiki/Special:Version
> http://en.wikisource.org/wiki/Special:Version
> http://es.wikipedia.org/wiki/Especial:Versi%C3%B3n
>
> Is clicktracking now occurring on all WMF projects?
>
> --
> John Vandenberg
>
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Re: [Foundation-l] hiding interlanguage links by default is a Bad Idea, part 2

[Howie Fung]

I agree that the User Experience Team and the community are still 
learning how to most effectively work together to do product 
development.  Things aren't perfect, and it make take some time before 
we get to a comfortable point.  I think the best thing we can do is to 
continue learning from each experience, and hopefully we'll come to a 
better process as we do more and more projects.  We'll make mistakes 
from time to time and that's just part of the learning process.   The 
important point is to acknowledge where we can do better and learn from 
those experiences.

Based on this feature, I think there are a number of areas where we 
could improve.  First, I do agree with the various statements that the 
tone of the revert was overly harsh and authoritarian.  I can assure you 
that that was not the intent of the revert -- we've always endeavored to 
be open in our collaboration, even in (and hopefully especially in) 
times of disagreement.  We've also been iterative in our approach, and 
decisions are rarely, if ever, considered final as the web affords us 
the luxury of continual improvement.  Nevertheless, words are important, 
and the ones used in the revert should have conveyed more openness to 
discussion, which they did not.  We'll make sure that these intentions 
are clear in the future.  We also recognize that the compromise solution 
that we proposed may not have met the needs of some within the 
community.  But I hope people understand that the shortcomings of this 
proposal did not arise from a failure to listen.  There have been many, 
many insightful and helpful comments which we took into consideration 
when developing the proposal.

Another area in which we can improve is data.  The debate on the data, 
especially what path of action the data would suggest, is a very 
legitimate debate (incidentally, I think the data may have been partly 
misinterpreted [1], but the debate is nonetheless valid).  This is a 
case where, because the data is imperfect, we will require additional 
perspectives to make a reasoned decision (someone used the phrase “life 
isn’t so simple”).  And as several posters have pointed out, the members 
on this mailing list represent a small, self-selecting sample of users, 
as do the members of the User Experience Team.  We carry our own biases 
into these decisions.  One way to overcome the inherent biases, as 
Eugene mentioned, is to be more data driven.  In this particular case, I 
am an advocate of using A/B testing as a way to better understand the 
impacts of a change in the user interface.  In general, I am very much 
in favor of having better analytics so that the balance of 
decision-making tilts even more towards data.

So in terms of a path forward, here is a proposal:
1.  Immediate revert so that all languages are exposed by default.
2.  We will continue work on a compromise solution.  The current 
interface is probably not perfect, so we’ll be continuing to look for 
ways to improve it.  We welcome your ideas -- please direct them to [2] 
so we can keep track.
3.  We will A/B-test proposed solutions against the default.  We'll 
involve the community to design the A/B test (e.g., what % of traffic, 
what threshold we use for decisions, etc).  In response to the comments 
about the data being only on enwp, we should be open to the fact that 
different Wikipedias may require different implementations.

In fairness, I should say clearly that while #1 will happen immediately, 
#2 and #3 will probably not be immediate.  Our team will need to balance 
this feature against other commitments (e.g., the next phase of the 
default rollout later this week, which will roll out with the inter-wiki 
links expanded).

 From a broader standpoint, I think there needs to be a direct 
discussion around how to involve the community in these types of 
decisions.  I’ve created a page on the usability wiki to discuss ideas 
[3] and look forward to the discussion.

Please let us know what you think of the proposed path forward.

Howie

[1] Based on the replies to the post, it seemed as though some people 
might have thought that the ~1% figure for Monobook referred to all 
clicks.  To be clear, the ~1% refers to ~1% of total left-nav clicks, 
not clicks overall.  But better data is still needed to inform this 
decision.
[2] http://usability.wikimedia.org/wiki/Interwiki_Link_Proposals
[3] http://usability.wikimedia.org/wiki/Product_Development_Process_Ideas

On 6/7/10 1:21 PM, Mark Williamson wrote:
> One major problem I have with this entire initiative, at least as I
> understand it, is that data was only collected from en.wp and mostly
> from native English speakers. Wikipedia is not monolingual, although
> many of our users are... and it's important to remember that many of
> these people are monolingual in languages other than English. Without
> further study, we have no way of knowing how many of the conclusions
> we may have drawn from the data will still hold true for
> non

Re: [Foundation-l] hiding interlanguage links by default is a Bad Idea, part 2

[Howie Fung]

The Usability team discussed this issue at length this afternoon.  We 
listened closely to the feedback and have come up with solution which we 
hope will work for everyone.  It's not a perfect solution, but we think 
it's a reasonable compromise.

First, some background on the problem we're addressing and the design 
principle that we used.  Every situation is unique, but in the case of 
the interwikilinks, we believe the sheer number of language links, 
especially within the context of an information-heavy page, makes users 
"numb" to the list.  When people see large collections of things, they 
tend to group them all together as one object and not identify the 
individual parts that make the whole. As the number of items in the list 
decreases the likelihood of a person identifying the individual items 
increases. This is similar to how viewing a traffic jam appears as a 
long line of generic vehicles, while seeing just a few cars driving down 
the road might be comprehended in more granular detail (a motorcycle, a 
truck and a sports car).  While we did not explicitly test for this 
during our usability studies (e.g., it wasn't included as a major design 
question), we did exercise judgement in identifying this as a problem, 
based partly on the applying the above design principle to the site, 
partly on the data.

Regarding the data behind the decision.  First, let me apologize for the 
tardiness.  The engineer who implemented the clicktracking of the left 
nav recently returned from vacation, so you can probably imagine how 
things might be a little difficult to find after being away for a 
while.   Please see [1] for more details, but a quick summary is that we 
measured the click behavior for two groups of English Wikipedia users, 
Monobook and Vector (Vector users are primarily those who participated 
in the beta).  Of Monobook and Vector users, 0.95% and 0.28% clicked on 
the language links (out of 126,180 and 180,873 total clicks), 
respectively.  We felt that fewer than 1% of Monobook clicks was a 
reasonable threshold for hiding the Language links, especially when 
taken in the context of the above design principle and the 
implementation (state persists after expanding).

We do, however, recognize the concern that was voiced by a number of our 
community members.  When the language links are in a collapsed state 
however, there is not enough information to explain what the list will 
be if you were to expand it.  In all likelihood, we won't be able to get 
the verbiage to the point where it's sufficiently descriptive of the 
inter-language links.  A list of languages is probably more effective as 
it *shows* the user that there are other languages available (rather 
than *telling* the user via a "Language", "In other languages" etc. 
link).  However, exposing all of the languages can potentially be just 
as ineffectual as showing none of them.

A more effective approach would be to balance the two, by showing just 
enough links to clearly illustrate the meaning of the list.  So our 
proposal is to show a list of, say, 5 languages with a "more" link.  We 
think that a list of 5 languages should be sufficient to communicate to 
the user that there are other language versions available.  If the 
language they want is not on the list, they may click "more" to see the 
full list.

There are numerous ways we can populate the list of 5.  The simplest way 
is to populate based on the current order, but we can also do it based 
on size of the wiki, browser language, geo IP, etc.   Our proposal is to 
go with something simple for now, and then continue to explore options 
for greater customization.

We hope this compromise addresses the most pressing concerns that have 
been raised.  I will update the page on the usability wiki with the 
above information [2].  Please direct discussion/feedback to that page.

Thank you for your input.

Howie, on behalf of the User Experience Team at WMF

[1] http://usability.wikimedia.org/wiki/Left_Nav_Click_Data
[2] http://usability.wikimedia.org/wiki/Opinion:_Language_Links

On 6/4/10 3:21 PM, Platonides wrote:
> Aryeh Gregor wrote:
>
>> Now, mind you, I don't necessary support getting rid of the
>> interlanguage links.  I'm mostly objecting to the reasoning being
>> brought forward for that point, which seems to be mostly:
>>
>> * Some unknown number of users might somehow end up at a wiki they
>> don't understand and not be able to find the wiki they really want.
>> Maybe.  Except we have no data to suggest that this happens with
>> non-negligible frequency.  The evidence apparently indicates that few
>> people use the interlanguage links.
>> * Lots of people have complained, therefore it must be a bad change.
>> * Interface clutter isn't important anyway.
>>
>> The last two arguments are completely wrongheaded.  The first might or
>> might not have merit -- but no one has even attempted to propose what
>> evidence we could gather to check it (I think).  Most o

Re: [Foundation-l] hiding interlanguage links by default is a Bad Idea, part 2

[Howie Fung]

Per Erik M.'s previous post, we're working on a compromise solution 
whereby we show a list based on user's most likely language(s), probably 
based on browser, and then a "see other languages" link which would 
expand to give all the other langauages.  We're also looking at changing 
the word "Languages" into something that's more descriptive of what the 
links actually do.

I've created the following page for more discussion/proposals on the topic:

http://usability.wikimedia.org/wiki/Opinion:_Language_Links

Howie

On 6/3/10 4:41 PM, David Goodman wrote:
> It would be nice to actually have a place at the usability wiki to
> discuss this.
>
> My own view is that the actual list of languages was the ideal
> interface object in   fulfilling many purposes (as discussed in the
> posts above) and implying multiple levels of understanding without the
> need for explanation or discussion. For example, that it   varied
> authomatically from article to article   showed the overall level of
> progress on the multiple projects.
>
> In showing Wikipedia to new users this list was always noticed and
> proved a very expressive statement.
>
> The attitude shown by Trevor's reply speaks for itself in terms of the
> relationship between the "internal" experts and  the community. I
> think that it was his wording that induced me to finally post on the
> issue.
>
>
>> I fixed it (it's a one-line change), but Trevor reverted it:
>>  
>>> This goes against an intentional design
>>> decision. To discuss that decision further and submit proposals to change 
>>> this
>>> design please contact Howie Fung  or visit
>>> http://usability.wikimedia.org
>>>
>
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] Upcoming Changes to the User Interface

[Howie Fung]

Everyone,

As many of you already know, the Wikimedia Foundation's User Experience 
team has been running a beta program focused on improving the user 
interface for over six months now. More details may be found here 
 
[a], but our main goal has been to reduce the barriers to participation 
in Wikipedia by making it easier for new contributors to edit.

Since the start of the program, over 635,000 users across all Wikimedia 
projects have participated in this beta program - testing and providing 
feedback on the new interface. Roughly 80% of the test users who tried 
the beta are still using it (view details 
 [b]). On the 
English Wikipedia, almost 270,000 users have tried the test interface 
and about 84% of those users continue to use it. On April 5, the beta 
features became the default experience for users of Wikimedia Commons, a 
wiki similar to Wikipedia that hosts the millions of free image and 
media files within our projects. The summary of feedback from Commons 
users may be found here 

 
[c]. The WMF blog 

 
[d] and the tech blog 
 
[e] also provide more information on this project.

This new user interface will become the default for users of the English 
Wikipedia during the second week of May. We are currently scheduled to 
make the switch at 5:00am UTC on May 13. Once we make the switch, all 
users will begin to see the new features [1]. These features include an 
enhanced toolbar, a new skin (which we named 'Vector'), and a number of 
other features we're very excited about (FAQs may be found here 
 [f]). 
If you prefer not to make the change, there will be 'Take me back' link 
to restore the original features. Those who would like to experience the 
new interface sooner may do so via the 'Try Beta' link at the top of the 
page.

We understand that the English Wikipedia relies heavily on custom user 
scripts and site-specific JavaScript. Information on how to test gadgets 
is included in the FAQs 
 page. 
If you encounter issues using the new skin, please share your feedback 
<[http://usability.wikimedia.org/wiki/Talk:What%27s_new,_questions_and_answers> 
[g].

We're looking forward to rolling out the new features next week. In the 
meantime, if you have any questions/comments, please share them here 
 [h] -- 
we're trying to consolidate feedback as much as we can.

Howie

Wikimedia Usability Experience Team

[1] Users that have opted out of the beta will still get the new 
features.  We apologize in advance for this inconvenience, but these 
users may restore their features via the "Take Me Back" link.
[a] http://usability.wikimedia.org/wiki/Wikipedia_Usability_Initiative
[b] http://usability.wikimedia.org/wiki/Beta_Feedback_Survey
[c] 
http://blog.wikimedia.org/2010/04/16/a-quick-update-on-vector-acceptance-by-commons-users/
[d] 
http://blog.wikimedia.org/2010/03/25/wikimedia-gets-ready-for-some-big-changes/
[e] http://techblog.wikimedia.org/2010/03/the-change-in-interface-is-coming/
[f] http://usability.wikimedia.org/wiki/What%27s_new,_questions_and_answers
[g] 
[http://usability.wikimedia.org/wiki/Talk:What%27s_new,_questions_and_answers
[h] http://en.wikipedia.org/wiki/Wikipedia:User_experience_feedback
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Foundation-l] [Wikimedia Announcements] English Wikipedia: Upcoming Changes to the User Interface

[Howie Fung]

Everyone,

As many of you already know, the Wikimedia Foundation's User Experience 
team has been running a beta program focused on improving the user 
interface for over six months now. More details may be found here 
 
[a], but our main goal has been to reduce the barriers to participation 
in Wikipedia by making it easier for new contributors to edit.


Since the start of the program, over 635,000 users across all Wikimedia 
projects have participated in this beta program - testing and providing 
feedback on the new interface. Roughly 80% of the test users who tried 
the beta are still using it (view details 
 [b]). On the 
English Wikipedia, almost 270,000 users have tried the test interface 
and about 84% of those users continue to use it. On April 5, the beta 
features became the default experience for users of Wikimedia Commons, a 
wiki similar to Wikipedia that hosts the millions of free image and 
media files within our projects. The summary of feedback from Commons 
users may be found here 
 
[c]. The WMF blog 
 
[d] and the tech blog 
 
[e] also provide more information on this project.


This new user interface will become the default for users of the English 
Wikipedia during the second week of May. We are currently scheduled to 
make the switch at 5:00am UTC on May 13. Once we make the switch, all 
users will begin to see the new features [1]. These features include an 
enhanced toolbar, a new skin (which we named 'Vector'), and a number of 
other features we're very excited about (FAQs may be found here 
 [f]). 
If you prefer not to make the change, there will be 'Take me back' link 
to restore the original features. Those who would like to experience the 
new interface sooner may do so via the 'Try Beta' link at the top of the 
page.


We understand that the English Wikipedia relies heavily on custom user 
scripts and site-specific JavaScript. Information on how to test gadgets 
is included in the FAQs 
 page. 
If you encounter issues using the new skin, please share your feedback 
<[http://usability.wikimedia.org/wiki/Talk:What%27s_new,_questions_and_answers> 
[g].


We're looking forward to rolling out the new features next week. In the 
meantime, if you have any questions/comments, please share them here 
 [h] -- 
we're trying to consolidate feedback as much as we can.


Howie

Wikimedia Usability Experience Team

[1] Users that have opted out of the beta will still get the new 
features.  We apologize in advance for this inconvenience, but these 
users may restore their features via the "Take Me Back" link.

[a] http://usability.wikimedia.org/wiki/Wikipedia_Usability_Initiative
[b] http://usability.wikimedia.org/wiki/Beta_Feedback_Survey
[c] 
http://blog.wikimedia.org/2010/04/16/a-quick-update-on-vector-acceptance-by-commons-users/
[d] 
http://blog.wikimedia.org/2010/03/25/wikimedia-gets-ready-for-some-big-changes/

[e] http://techblog.wikimedia.org/2010/03/the-change-in-interface-is-coming/
[f] http://usability.wikimedia.org/wiki/What%27s_new,_questions_and_answers
[g] 
[http://usability.wikimedia.org/wiki/Talk:What%27s_new,_questions_and_answers

[h] http://en.wikipedia.org/wiki/Wikipedia:User_experience_feedback
___
Please note: all replies sent to this mailing list will be immediately directed 
to Foundation-L, the public mailing list about the Wikimedia Foundation and its 
projects. For more information about Foundation-L:
https://lists.wikimedia.org/mailman/listinfo/foundation-l
___
WikimediaAnnounce-l mailing list
wikimediaannounc...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l