Mailing List Archive

Hoi,
This is great news, this makes me really happy. As I have been arguing
before, the lack of usability prevents many people from contributing to
wikis. Many of our projects are failing and, usability is a major factor in
this. Combine this with a lack of localisation for many languages, a digital
divide that prevents many demographies either by lack of infrastructure
and/or lack of skills. The great thing about usability is, that this is the
one place where it easiest for us to make a difference.

In the announcement it is said, that the experience for new contributors is
to be improved by the usability improvements funded by this grant. UNICEF
has done usability studies, giving newbies tasks to perform like creating
new articles. They have many videos and I understand that they may be
willing to share them with us for this effort. Based on their observations,
developers at UNICEF have developed a set of extensions that have proven
themselves in raising the collaboration of UNICEF wikis. These extensions
are in the WMF SVN, they are being localised in Betawiki and they have been
tested in the ExtensionTesting environment.

Marjon and Magnus have testified that MediaWiki is problematic for newbies
everywhere. Our lack of usability is hurting us and we have a self selecting
group of editors based on the ability in overcomming the problems of our
environment. Many demographics are not well represented and this leads to
bias and to the underrepresentation of the subjects these demographics have
an interest in. In the majority of our projects we are not even able to
raise a sustainable community.

With a significant grant received, it should be possible to create metrics
that measure the success of the work that we are about to do. Just receiving
the money and doing the things that seem to make sense does not cut it. In a
different thread I stated that 80% of our projects are failing. With an
improved usability, it should be possible to notice a difference. The
localisation work at Betawiki has doubled the number of languages that
provide a minimal support. Sadly we do not have any numbers how this has
affected the projects in those languages.

As the WMF has accepted this money for a targeted grant, and as Michael
indicates that the board feels strongly about this issue, I am lead to
understand that usability has been made a priority in the further
development of MediaWiki. Indeed improved usability will benefit more then
100% of the WMF projects, it will have a big impact on all the MediaWiki
projects out there, the projects by educational organisations like
Commonwealth of Learning, Kennisnet, the projects by hosting organisations
like Wikia and Wikiation, the small organisations like my "housing
community".

Given the investments in usability outside of the WMF already made, I do
urge the WMF to learn from what has already been done and to incorporate the
lessons learned, the software developed. I would love to see more
cooperation in the further development of MediaWiki with the other stake
holders in the MediaWiki software.
Thanks,
GerardM


2008/12/3 Michael Snow <wikipedia@verizon.net>

> I'm happy to mention that the board has authorized the foundation to
> accept a significant grant, for which we just recently received the
> funds. This is a restricted grant specifically for use on a project to
> improve the MediaWiki software and the experience for new contributors.
> Not that this is a direct result of recent discussions here, plenty of
> people have mentioned the issue before, including Delphine as Ting
> points out. As you may know, grants take more than a day or two to put
> together, but it's relevant to mention anyway. I understand a press
> release with more details will be going out in the next day or so.
>
> While grants with restrictions should be considered with care (one
> reason for the board to be involved), we've indicated for some time that
> this is an issue the foundation feels strongly about addressing. As a
> result, any hesitation was really more about the challenges involved in
> executing the project. I don't know just how far this will carry us, but
> since it focuses on the underlying software, I hope it will benefit more
> than just "80% of our projects" - even the ones that don't need help, or
> don't think they do. I encourage volunteers to get involved in
> supporting the effort as the project moves forward.
>
> This grant is also from a source that has provided a smaller amount of
> funding before. It's gratifying when donors recognize the impact they
> are having and decide they want to add to it.
>
> --Michael Snow
>
>
> _______________________________________________
> 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

On Wed, Dec 3, 2008 at 2:02 AM, Michael Snow <wikipedia@verizon.net> wrote:
[snip]
> improve the MediaWiki software and the experience for new contributors.
> Not that this is a direct result of recent discussions here, plenty of
> people have mentioned the issue before, including Delphine as Ting
[snip]

Sadly most of the discussions on these lists run on without mention of
the efforts that have come before, in this case see:
http://en.wikipedia.or/wiki/Wikipedia:Article_wizard

When people discuss enhancements it seems that it is taboo to discuss
the question of what happens when the communities reject these
efforts.

Too often we blame technical issues as limiting factors for usability
when with a little creativity a 90% solution is available without
waiting for inflexible technical solutions which never seem to come.
Unfortunately, interest, project politics, and other social factors
are ready to stand in the way of progress even when there are no
technical roadblocks at all.

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

That link should be http://en.wikipedia.org/wiki/Wikipedia:Article_wizard I
presume

Finn R.

2008/12/3 Gregory Maxwell <gmaxwell@gmail.com>

> On Wed, Dec 3, 2008 at 2:02 AM, Michael Snow <wikipedia@verizon.net>
> wrote:
> [snip]
> > improve the MediaWiki software and the experience for new contributors.
> > Not that this is a direct result of recent discussions here, plenty of
> > people have mentioned the issue before, including Delphine as Ting
> [snip]
>
> Sadly most of the discussions on these lists run on without mention of
> the efforts that have come before, in this case see:
> http://en.wikipedia.or/wiki/Wikipedia:Article_wizard
>
> When people discuss enhancements it seems that it is taboo to discuss
> the question of what happens when the communities reject these
> efforts.
>
> Too often we blame technical issues as limiting factors for usability
> when with a little creativity a 90% solution is available without
> waiting for inflexible technical solutions which never seem to come.
> Unfortunately, interest, project politics, and other social factors
> are ready to stand in the way of progress even when there are no
> technical roadblocks at all.
>
> _______________________________________________
> 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

Hoi,
I had a look. It is based on templates. What templates do wonderfully is
create a proof of concept. When you have a look at the UNICEF
implementation, you will learn that the same idea is implemented by them. On
their wikis they do have templates for particular types of content. So I
agree, it is a great idea.

When you mention the "taboo" of rejection by a community, I can tell you
that this is one thing that I talk about quite often. Now rejection should
be based on arguments and it is important to understand the arguments WHY
things are proposed and the arguments WHY proposals are rejected. When
people just vote, there is nothing that helps in understanding the reasons
why, there is no handle on the argument that will help with preventing the
negative effects of a proposal. When one community rejects a proposal, new
functionality does not need to be rejected by other communities. Extensions
do not need to be enabled. However, when Brion in his role as chief
technical officer and architect of MediaWiki decides that somethig should go
in regardless. This would be the case when functionality needs to be part of
the MediaWiki core.

When you are talking about "inflexible" solutions, you have to appreciate
that you are capable of creating the most wonderful templates. These same
templates scare many people away. So where you see a wonderful template I
find projects like the Neapolitan Wikipedia reject them because they scare
people away (it does work for them). So you are completely correct that
social issues play a part in accepting solutions. The solutions that come
with templates are rejected by many just for comming as a template, will
this prevent you from using them? Templates are great for proto typing, they
are however a help and a hinder. If anything we need to find a way to
overcome the problems people have with templates because they do provide
value.
Thanks,
GerardM



2008/12/3 Gregory Maxwell <gmaxwell@gmail.com>

> On Wed, Dec 3, 2008 at 2:02 AM, Michael Snow <wikipedia@verizon.net>
> wrote:
> [snip]
> > improve the MediaWiki software and the experience for new contributors.
> > Not that this is a direct result of recent discussions here, plenty of
> > people have mentioned the issue before, including Delphine as Ting
> [snip]
>
> Sadly most of the discussions on these lists run on without mention of
> the efforts that have come before, in this case see:
> http://en.wikipedia.or/wiki/Wikipedia:Article_wizard
>
> When people discuss enhancements it seems that it is taboo to discuss
> the question of what happens when the communities reject these
> efforts.
>
> Too often we blame technical issues as limiting factors for usability
> when with a little creativity a 90% solution is available without
> waiting for inflexible technical solutions which never seem to come.
> Unfortunately, interest, project politics, and other social factors
> are ready to stand in the way of progress even when there are no
> technical roadblocks at all.
>
> _______________________________________________
> 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

Gregory Maxwell wrote:
> On Wed, Dec 3, 2008 at 2:02 AM, Michael Snow <wikipedia@verizon.net> wrote:
> [snip]
>> improve the MediaWiki software and the experience for new contributors.
>> Not that this is a direct result of recent discussions here, plenty of
>> people have mentioned the issue before, including Delphine as Ting
> [snip]
>
> Sadly most of the discussions on these lists run on without mention of
> the efforts that have come before, in this case see:
> http://en.wikipedia.or/wiki/Wikipedia:Article_wizard
>
> When people discuss enhancements it seems that it is taboo to discuss
> the question of what happens when the communities reject these
> efforts.
>
> Too often we blame technical issues as limiting factors for usability
> when with a little creativity a 90% solution is available without
> waiting for inflexible technical solutions which never seem to come.
> Unfortunately, interest, project politics, and other social factors
> are ready to stand in the way of progress even when there are no
> technical roadblocks at all.

Note also that the Slovenian Wikipedia has an adaptation of this[1] that
they link to from the message shown when creating a new article[2] (the
second line of the message).

[1] <http://sl.wikipedia.org/wiki/Wikipedija:Napi%C5%A1i_%C4%8Dlanek>
[2] <http://sl.wikipedia.org/wiki/MediaWiki:Newarticletext>

--
Alex (wikipedia:en:User:Mr.Z-man)

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

On Wed, Dec 3, 2008 at 4:58 AM, Gerard Meijssen
<gerard.meijssen@gmail.com> wrote:
> Hoi,
> I had a look. It is based on templates. What templates do wonderfully is
> create a proof of concept.

I agree. My concern is that we should not jump first into writing
software unless a proof of concept is not possible. We will not get
the software right the first time, fewer people have the skills needed
to change the software, etc. The first priority is obtaining a good
understanding of what works through prototyping, but we fail at that.
The possibility of future software is used as an argument against any
prototyping.

> When you mention the "taboo" of rejection by a community, I can tell you
> that this is one thing that I talk about quite often. Now rejection should
> be based on arguments and it is important to understand the arguments WHY
> things are proposed and the arguments WHY proposals are rejected. When
> people just vote, there is nothing that helps in understanding the reasons
> why, there is no handle on the argument that will help with preventing the
> negative effects of a proposal.

English Wikipedia, as a high profile example, simply does not want to
encourage new users to create articles. In fact, over time they have
intentionally increased the barrier to create new articles: You now
must have an account for 4 days and make 10 edits before you can
create an article on EnWP. If you've made it that far without being
blocked you probably do not need the wizard.

Arguments made include positions backed by solid fact such as "The
overwhelming majority of contributions by inexperienced people are
very low quality" as well as less factual but hard to argue against
positions such as "We do not know what effect this may have, but it
could be very bad, and we may never be able to turn it off".

I would like to think this class of problems is unique to English
Wikipedia, but I've seen it to varying degrees in other communities
which use super-majority as the decision criteria, and I suspect that
it may be the fate of many projects as they mature.

> When one community rejects a proposal, new
> functionality does not need to be rejected by other communities. Extensions
> do not need to be enabled.

This is true. But it's poor use of resources to churn out feature
after feature that many communities will reject.

[snip]
> When you are talking about "inflexible" solutions, you have to appreciate
> that you are capable of creating the most wonderful templates.
[snip]

I'm not wed to the concept of templates, and certainly not to their
implementation today. If you search the lists you'll find cases of me
ranting about "edit this page" bringing up two screens of
template-gunk on many articles.

What I am strongly opposed to is our practice of inventing
functionality in a near-vacuum and throwing it out as faite accomplis.
Not only do I believe that you, me, and the other kind residents of
this list are unqualified to produce perfect solutions to complex
social-technical issue in a single pass, I believe no one is.

The questions for any new non-trivial functionality should be:
(1) Can you prototype it or study it without software changes and
learn more about what we really need?
(2) Have you tried alternative solutions?
(3) From your prototyping what evidence do you have for and against
the proposed changes?
(4) Is there a more minimal software change which would address this
need in a generic manner and facilitate more learning and prototyping?

We ask none of these today. Instead, temporary solutions are widely
rejected because some undefined software solution will be available
"any day now", which either never comes, or when it does come is not
activated because people believe that it fails to meet the
requirements because no one took the effort to really understand and
define the requirements.

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Gregory Maxwell wrote:
> On Wed, Dec 3, 2008 at 4:58 AM, Gerard Meijssen
> <gerard.meijssen@gmail.com> wrote:
>
>> Hoi,
>> I had a look. It is based on templates. What templates do wonderfully is
>> create a proof of concept.
>>
> I agree. My concern is that we should not jump first into writing
> software unless a proof of concept is not possible. We will not get
> the software right the first time, fewer people have the skills needed
> to change the software, etc.
>
I expect we all recognize that software is not the solution to every
problem. As far as improving the learning experience for new
contributors, I certainly hope this doesn't cause anyone to give up
working on other avenues and tackling any cultural challenges that
should be addressed.

The purpose of this grant, however, goes beyond just simplifying a
particular process, so from that perspective it's not a question of
whether software is the best way to do that. Rather, we're treating the
MediaWiki software as a critical aspect of the overall environment for
our projects, and one that can and should be improved. "Best-of-breed"
it may be, but I think it's apparent that sometimes it hinders efforts
that need help, so I consider it worthwhile to reduce the obstacles it
introduces to our environment. Indeed we have not gotten it right the
first time, which is why we have accepted this grant, as we keep trying
to get it right.
> The first priority is obtaining a good
> understanding of what works through prototyping, but we fail at that.
> The possibility of future software is used as an argument against any
> prototyping.
I believe that's the logical fallacy known as "argument from vaporware".
Just because software might change how things work in the future doesn't
mean we should avoid working on other improvements in the meantime.
Unless we know that a specific feature is in the works and will conflict
with the proposed solution, there's no reason to forbid experiments.
Otherwise, I think I'd happily start nuking unsightly infobox markup on
the theory that some future software can be counted on to automatically
generate the information from article prose. It is just prototyping for
the Semantic Web, after all.

--Michael Snow


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l