Big problem to solve: good WYSIWYG on WMF wikis

classic Classic list List threaded Threaded
153 messages Options
123456 ... 8
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Joe Corneli-3
"In dotCommunist Ew Ork, Aris, and Ome, Wikipedia disrupts you!"

Suggestion: Set the sights a little higher, and I'd say start by
ditching the "disruption" metaphor, which is fine and good for firms,
but less sensible in a landscape that's already massively and
"organically" distributed (I'm thinking of the free culture movement
as a whole).  If the rhetorical question is "how to build a better
encyclopedia?" or "how to further the WMF's mission?" -- here's
something: how about some specific and well-thought out proposals and
a way to discuss them that doesn't devolve to some sort of punditry
pissing contest?  Like, a UserVoice-style feedback system (instead of
this: http://www.mediawiki.org/wiki/Bugzilla#Requesting_a_feature) and
clear way to keep track of project and subproject progress (Redmine?),
including a way to make sense of the priorities and other trends that
govern progress on the current set of open bugs
(https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=status%3Aopen).

In real simple terms, know thyself!

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Foundation-l] Big problem to solve: good WYSIWYG on WMF wikis

Brion Vibber
In reply to this post by Rob Lanphier-4
On Tue, Dec 28, 2010 at 5:28 PM, Rob Lanphier <[hidden email]> wrote:

> Let me riff on what you're saying here (partly just to confirm that I
> understand fully what you're saying).  It'd be very cool to have the
> ability to declare a single article, or probably more helpfully, a
> single revision of an article to use a completely different syntax.
>

Yes, though I'd recommend jettisoning the word "syntax" entirely from the
discussion at this stage, as I worry it distracts towards bikeshedding about
unimportant details.

Rather, it could be more useful to primarily think of data resources having
"features" or "structure". With images for instance, we don't make people
pay too much attention about whether something's in JPEG, PNG, GIF, or SVG
format.

At the level of actual people working with the system, the file's *format*
is completely unimportant -- only its features and metadata are relevant.
Set a size, give a caption, specify a page if it's a paged format, or a time
if it's a video format. Is it TIFF or PDF? Ogg Theora or WebM? Don't know,
don't care, and any time a user has to worry about it we've let them down.

We need to think about similarly concentrating on document structure rather
than markup syntax for text pages.


I definitely agree that the idea of progressively moving bits and pieces in
that direction is a wise one. If we can devise a *document structure* that
lets us embed magic templatey _things_ into a paragraph-oriented-text
document and maintain their structural identity all the way to browser-ready
HTML and back, then we can have a useful migration path:

* identify possibly unsafe uses of templates, extensions, and
parserfunctions (machines are great at this!)
* clean them up bit by bit (bots are often good at many common cases)
* once a page can be confirmed as not using Weird Template Magic, but only
using templates/images/plugins that fit within the structure, it's golden.
* depending on which flavor of overlords we have, we might have various ways
of enforcing that a page will always *remain* well-structured from then on.

That might not even involve changing syntax per se -- we shouldn't care too
much about whether italic is <i> or ''. But knowing where a table or a div
block starts and ends reliably is extremely important to being able to tell
which part of your document is which.


And heck, even if not everything gets fixed along that kind of path, just
being able to *have* pages and other resource types that *are*
well-structured mixed into the system is going to be hugely useful for the
non-Wikipedia projects.

-- brion vibber (brion @ pobox.com)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Tim Starling-2
In reply to this post by Neil Kandalgaonkar
On 29/12/10 18:31, Neil Kandalgaonkar wrote:

> I've been inspired by the discussion David Gerard and Brion Vibber
> kicked off, and I think they are headed in the right direction.
>
> But I just want to ask a separate, but related question.
>
> Let's imagine you wanted to start a rival to Wikipedia. Assume that you
> are motivated by money, and that venture capitalists promise you can be
> paid gazillions of dollars if you can do one, or many, of the following:
>
> 1 - Become a more attractive home to the WP editors. Get them to work on
> your content.
>
> 2 - Take the free content from WP, and use it in this new system. But
> make it much better, in a way Wikipedia can't match.

This has been done before: Wikinfo, Citizendium, etc.

> 3 - Attract even more readers, or perhaps a niche group of
> super-passionate readers that you can use to build a new community.

This is basically Wikia's business model. I think you need to think
outside the box.

I would make it more like World of Warcraft. We should incentivise
people to set up wiki sweatshops in Indonesia, paying local people to
"grind" all day, cleaning up articles, in order to build up a level 10
admin character that can then be sold for thousands of dollars on the
open market. Also it should have cool graphics.

OK, if you want a real answer: I think if you could convince admins to
be nicer to people, then that would make a bigger impact to
Wikipedia's long-term viability than any ease-of-editing feature.
Making editing easier will give you a one-off jump in editing
statistics, it won't address the trend.

We know from interviews and departure messages that the editing
interface creates an initial barrier for entry, but for people who get
past that barrier, various social factors, such as incivility and
bureaucracy, limit the time they spend contributing.

Once you burn someone out, they don't come back for a long time, maybe
not ever. So you introduce a downwards trend which extends over
decades, until the rate at which we burn people out meets the rate at
which new editors are born.

Active, established editors have a battlefront mentality. They feel as
if they are fighting for the survival of Wikipedia against a constant
stream of newbies who don't understand or don't care about our
policies. As the stream of newbies increases, they become more
desperate, and resort to more desperate (and less civil) measures for
controlling the flood.

Making editing easier could actually be counterproductive. If we let
more people past the editing interface barrier before we fix our
social problems, then we could burn out the majority of the Internet
population before we figure out what's going on. Increasing the number
of new editors by a large factor will increase the anxiety level of
admins, and thus accelerate this process.

I think there are things we can do in software to help de-escalate
this conflict between established editors and new editors.

One thing we can do is to reduce the sense of urgency. Further
deployment of FlaggedRevs (pending changes) is the obvious way to do
this. By hiding recent edits, admins can deal with bad edits in their
own time, rather reacting in the heat of the moment.

Another thing we could do is to improve the means of communication.
Better communication often helps to de-escalate a conflict.

We could replace the terrible user talk page interface with an
easy-to-use real-time messaging framework. We could integrate polite
template responses with the UI. And we could provide a centralised
forum-like view of such messages, to encourage mediators to review and
de-escalate emotion-charged conversations.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Dmitriy Sintsov
In reply to this post by Neil Kandalgaonkar
* Neil Kandalgaonkar <[hidden email]> [Wed, 29 Dec 2010 14:40:13
-0800]:
> Thanks... I know this is a provocative question but I meant it just as
> it was stated, nothing more, nothing less. For better or worse my
> history with the foundation is too short to know the answers to these
> questions.
>
> All the assumptions in my question are up for grabs, including the
> assumption that we're even primarily developing MediaWiki for WMF
> projects. Maybe we think it's just a good thing for the world and
that's
> that.
>
> Anyway, I would question that it doesn't take a lot of effort to keep
> the core small -- it seems to me that more and more of the things we
use
> to power the big WMF projects are being pushed into extensions and
> templates and difficult-to-reproduce configuration and even data
entered
> directly into the wiki, commingled indistinguishably with documents.
(As
> you are aware, it takes a lot of knowledge to recreate Wikipedia for a
> testing environment. ;)
>
> Meanwhile, MediaWiki is perhaps too powerful and too complex to
> administer for the small organization. I work with a small group of
> artists that run a MediaWiki instance and whenever online
collaboration
> has to happen, nobody in this group says "Let's make a wiki page!"
That
> used to happen, but nowadays they go straight to Google Docs. And that
> has a lot of downsides; no version history, complex to auth
credentials,
> lack of formatting power, can't easily transition to a doc published
on
> a website, etc.
>
MediaWIki wasn't always so complex. The first version, I've used in 2007
(1.9.3) was reasonably simpler than current 1.17 / 1.18 revisions. And
one might learn it gradually, step by step in many months or even years.
Besides of writing extensions for various clients, I do use it for my
own small memo / blog, where I do put code samples, useful links
(bookmarking) and a lot of various texts (quotations and articles to
read later).

To me, a standalone MediaWiki on a flash drive sounds like a good idea.
However, there are many limitations, although SQLite support have become
much better and there is a Nanoweb http server; some computers might
already listen to 127.0.0.1:80. I wish it was possible to run a kind of
web server with system sockets, or even no sockets at all, however
browsers probably do not support this :-( Otherwise, one should pre-run
a port scanner (not a very good thing).
Dmitriy

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Neil Kandalgaonkar
In reply to this post by Tim Starling-2
On 12/29/10 7:26 PM, Tim Starling wrote:

> OK, if you want a real answer: I think if you could convince admins to
> be nicer to people, then that would make a bigger impact to
> Wikipedia's long-term viability than any ease-of-editing feature.
> Making editing easier will give you a one-off jump in editing
> statistics, it won't address the trend.
>
> We know from interviews and departure messages that the editing
> interface creates an initial barrier for entry, but for people who get
> past that barrier, various social factors, such as incivility and
> bureaucracy, limit the time they spend contributing.

For me the usability projects always had the unstated intent of
broadening the pool of good editors. More hands to ease the burdens of
the beleagured admins, and also fresher blood that wasn't quite as
ensconced in wikipolitics.

But overall I agree.


> Making editing easier could actually be counterproductive. If we let
> more people past the editing interface barrier before we fix our
> social problems,  [...]

This is an interesting insight!

I have been thinking along these lines too, although in a more haphazard
way.

At some point, if we believe our community is our greatest asset, we
have to think of Wikipedia as infrastructure not only for creating high
quality articles, but also for generating and sustaining a high quality
editing community. My sense is that the Wiki* communities are down with
goal #1, but goal #2 is not on their radar at all.

So we probably need an employee dedicated to this. (I think? Arguments?)

When the Usability Project closed down, the team was also unhappy with
the narrow focus paid to editing. Research showed the most serious
problems were elsewhere. We then said we were going to address UX issues
in a very broad way, which included social issues. Unfortunately the
person in charge of that left the Foundation soon after and in the
kerfuffle I'm not sure if we now have anybody whose primary job it is to
think about the experience of the user in such broad terms.

--
Neil Kandalgaonkar (   <[hidden email]>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Alex Brollo
2010/12/30 Neil Kandalgaonkar <[hidden email]>

> On 12/29/10 7:26 PM, Tim Starling wrote:
>
> > Making editing easier could actually be counterproductive. If we let
> > more people past the editing interface barrier before we fix our
> > social problems,  [...]
>
> This is an interesting insight!
>

Yes it's really interesting and highlighting!

I'm following another talk about StringFunctions; and I recently got an
account into toolserver (I only hope that my skill is merely sufficient!).
In both cases, there's an issue of "security by obscurity". I hate it at
beginning, but perhaps such an approach is necessary, it's the simplest way
to get a very difficult result.

So, what's important is, the balance between simplicity and complexity,
since this turns out into a "contributor filter". At the beginning, wiki
markup has been designed to be very simple. A very important feature of
markup has been sacrificed: the code is not "well formed". There are lots of
simple, but ambiguous tags (for bold and italic characters, for lists); tags
don't need to be closed; text content and tags/attributes are mixed freely
into the template code. This makes simpler their use but causes terrible
quizzes  for advanced users facing with unusual cases or trying to parse
wikitext by scripts or converting wikitext into a formally well formed
markup. My question is: can we imagine to move a little bit that balance
accepting a little more complexity  and to think to a well formed wiki
markup?

Alex
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Bryan Tong Minh
In reply to this post by Neil Kandalgaonkar
On Wed, Dec 29, 2010 at 9:58 PM, Neil Kandalgaonkar <[hidden email]> wrote:
> Question: assuming that our primary interest is creating software for
> Wikipedia and similar WMF projects, do we actually get anything from the
> Windows PC intranet users that offsets the cost of keeping MediaWiki
> friendly to both environments? In other words, do we get contributions
> from them that help us do Wikipedia et al,?
>
Why would I contribute to software that I can't even run?

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

MZMcBride-2
In reply to this post by Tim Starling-2
Tim Starling wrote:

> OK, if you want a real answer: I think if you could convince admins to
> be nicer to people, then that would make a bigger impact to
> Wikipedia's long-term viability than any ease-of-editing feature.
> Making editing easier will give you a one-off jump in editing
> statistics, it won't address the trend.
>
> We know from interviews and departure messages that the editing
> interface creates an initial barrier for entry, but for people who get
> past that barrier, various social factors, such as incivility and
> bureaucracy, limit the time they spend contributing.

Is there any evidence to support these claims? From what I understand, a lot
of Wikipedia's best new content is added by anonymous users.[1] Thousands
more editors are capable of registering and editing without much interaction
with the broader Wikimedia community at all. If there's evidence that mean
admins are a credible threat to long-term viability, I'd be interested to
see it.

Given that there are about 770 active administrators[2] on the English
Wikipedia and I think you could reasonably say that a good portion are not
mean, is it really quite a few people who are having this far-reaching
impact that you're suggesting exists? That seems unlikely.

> Making editing easier could actually be counterproductive. If we let
> more people past the editing interface barrier before we fix our
> social problems, then we could burn out the majority of the Internet
> population before we figure out what's going on. Increasing the number
> of new editors by a large factor will increase the anxiety level of
> admins, and thus accelerate this process.

I think the growth should be organic. With a better interface in place, a
project has a much higher likelihood of successful, healthy growth.

> One thing we can do is to reduce the sense of urgency. Further
> deployment of FlaggedRevs (pending changes) is the obvious way to do
> this. By hiding recent edits, admins can deal with bad edits in their
> own time, rather reacting in the heat of the moment.

Endless backlogs are going to draw people in? Delayed gratification is going
to keep people contributing? This proposal seems anti-wiki in a literal and
philosophical sense.

MZMcBride

[1] http://www.cs.dartmouth.edu/reports/abstracts/TR2007-606/
[2] http://en.wikipedia.org/wiki/Wikipedia:List_of_administrators



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

David Gerard-2
In reply to this post by Aryeh Gregor
On 30 December 2010 00:27, Aryeh Gregor <[hidden email]> wrote:

>  You could even compete by
> putting up a better editing interface, conceivably, although auth
> would be tricky to work out.


You know, this is something that would be extremely easy to experiment
with right now,


> On Wed, Dec 29, 2010 at 6:59 PM, Brion Vibber <[hidden email]> wrote:

>> I think this isn't as useful a question as it might be; defining a project
>> in terms of competing with something else leads to stagnation, not
>> innovation.

> I agree.  The correct strategy to take down Wikipedia would involve
> overcoming the network effect that locks it into its current position
> of dominance, and that's not something that would be useful for
> Wikipedia itself to do.  To fend off attacks of this sort, what you'd
> want is to make your content harder to reuse, which we explicitly
> *don't* want to do.  Better to ask: how can we enable more people to
> contribute who want to but can't be bothered?


Making Wikipedia easy to mirror and fork is the best protection I can
think of for the content itself. It also keeps the support structures
(Foundation) and community good and honest. Comparison: People keep
giving Red Hat money; Debian continues despite a prominent and
successful fork (Ubuntu), and quite a bit goes back from the fork
(both pull and push).


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

David Gerard-2
In reply to this post by MZMcBride-2
On 30 December 2010 11:06, MZMcBride <[hidden email]> wrote:
> Tim Starling wrote:

>> OK, if you want a real answer: I think if you could convince admins to
>> be nicer to people, then that would make a bigger impact to
>> Wikipedia's long-term viability than any ease-of-editing feature.
>> Making editing easier will give you a one-off jump in editing
>> statistics, it won't address the trend.

> Given that there are about 770 active administrators[2] on the English
> Wikipedia and I think you could reasonably say that a good portion are not
> mean, is it really quite a few people who are having this far-reaching
> impact that you're suggesting exists? That seems unlikely.


There is some discussion of how the community and ArbCom enable
grossly antisocial behaviour on internal-l at present. Admin behaviour
is enforced by the ArbCom, and the AC member on internal-l has mostly
been evasive. It's not clear what approach would work at this stage;
it would probably have to get worse before the Foundation could
reasonably step in.


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Risker
On 30 December 2010 09:07, David Gerard <[hidden email]> wrote:

> On 30 December 2010 11:06, MZMcBride <[hidden email]> wrote:
> > Tim Starling wrote:
>
> >> OK, if you want a real answer: I think if you could convince admins to
> >> be nicer to people, then that would make a bigger impact to
> >> Wikipedia's long-term viability than any ease-of-editing feature.
> >> Making editing easier will give you a one-off jump in editing
> >> statistics, it won't address the trend.
>
> > Given that there are about 770 active administrators[2] on the English
> > Wikipedia and I think you could reasonably say that a good portion are
> not
> > mean, is it really quite a few people who are having this far-reaching
> > impact that you're suggesting exists? That seems unlikely.
>
>
> There is some discussion of how the community and ArbCom enable
> grossly antisocial behaviour on internal-l at present. Admin behaviour
> is enforced by the ArbCom, and the AC member on internal-l has mostly
> been evasive. It's not clear what approach would work at this stage;
> it would probably have to get worse before the Foundation could
> reasonably step in.
>
>

Perhaps if communication actually took place with Arbcom itself, rather than
on a list in which there is no Arbcom representative, there might be a
better understanding of the concerns you have mentioned.  There's no "Arbcom
representative" on internal-L, and in fact this is something of a bone of
contention.

Nonetheless, I think the most useful post in this entire thread has been Tim
Starling's, and I thank him for it.


Risker
(who is coincidentally an enwp Arbitration Committee member but is in no way
an Arbcom representative on this list)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Platonides
In reply to this post by Neil Kandalgaonkar
Neil Kandalgaonkar wrote:

>
> I have been thinking along these lines too, although in a more haphazard
> way.
>
> At some point, if we believe our community is our greatest asset, we
> have to think of Wikipedia as infrastructure not only for creating high
> quality articles, but also for generating and sustaining a high quality
> editing community. My sense is that the Wiki* communities are down with
> goal #1, but goal #2 is not on their radar at all.
>
> So we probably need an employee dedicated to this. (I think? Arguments?)

He would be quite busy (and polyglot!) to keep an eye over the community
of +800 projects.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Platonides
In reply to this post by Ryan Kaldari-2
Ryan Kaldari wrote:

> Actually, I would implement "hot articles" per WikiProject. So, for
> example, you could see the 5 articles under WikiProject Arthropods that
> had been edited the most in the past week. That should scale well. In
> fact, I would probably redesign Wikipedia to be WikiProject-based from
> the ground up, rather than as an afterthought. Like when you first sign
> up for an account it asks you which WikiProjects you want to join, etc.
> and there are cool extensions for earning points and awards within
> WikiProjects (that don't require learning how to use templates).
>
> Ryan Kaldari

Well, that's an interesting point. People ask for things like a "chat
per article" without realising what that would mean.
Grouping communication in bigger "wikiproject" channels could work.
Although some tree-like structure would be needed to manually split /
magically join depending on the amount of people there.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Neil Kandalgaonkar
In reply to this post by Platonides
On 12/30/10 10:24 AM, Platonides wrote:

> Neil Kandalgaonkar wrote:
>> At some point, if we believe our community is our greatest asset, we
>> have to think of Wikipedia as infrastructure not only for creating high
>> quality articles, but also for generating and sustaining a high quality
>> editing community.
>>
>> So we probably need an employee dedicated to this. (I think? Arguments?)
>
> He would be quite busy (and polyglot!) to keep an eye over the community
> of +800 projects.

Why is this a requirement?

If you think about the sum total of user-hours spent on Wikipedia, the
vast majority of them are spent in just three or four interface flows.

But you're right; they can't be everywhere, so maybe there should be a
guidelines page on design principles. We have WP:CIVILITY, do we have
similar guidelines for software developers, on how to make it easy for
the community to be civil?

Frankly I don't think I'm qualified to do this. I know of a few people
are brilliant at this, and who do this sort of thing for a living, but
they are consultants. Fostering community on the web is generally
considered a sort of black art... does anybody know of any less
mystified way of dealing with the problem?

--
Neil Kandalgaonkar (   <[hidden email]>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

David Gerard-2
In reply to this post by Tim Starling-2
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Paul Houle
In reply to this post by Neil Kandalgaonkar
  On 12/29/2010 2:31 AM, Neil Kandalgaonkar wrote:
> Let's imagine you wanted to start a rival to Wikipedia. Assume that you
> are motivated by money, and that venture capitalists promise you can be
> paid gazillions of dollars if you can do one, or many, of the following:
>
     Ok,  first of all you need a pot of gold at the end of the
rainbow.  Let's assume it's a real business model and not that you know
a few folks who have $1B burning a hole in their pocket.  Let's also
assume that it's a business model basic on getting a lot of traffic...

     Secondly,  if you want to go up against 'Wikipedia as a whole',  
that's a very difficult problem.  Wikipedia is one of the strongest
sites on the internet in terms of S.E.O.,  not because of any nasty
stuff,  but because so many people link to Wikipedia articles from all
over the web.  Wikipedia ranks highly for many terms and that's a
situation that Google & Bing don't mind,  since Wikipedia has something
halfway decent to say about most topics...  It makes search engines seem
smart.

     To overturn Wikipedia on the conventional web,  you'd really need
to beat it at S.E.O.  Sneaky-peet tricks won't help you that much when
you're working at this scale,  because if you're able to make enough
phony links to challenge one of the most-linked sites on Earth,  you're
probably going to set off alarm bells up and down the West coast.  
Thus,  the challenge of a two-sided market faces anybody who wants to
'beat' Wikipedia,  and I think it's just too hard a nut to crack,  even
if you've got software that's way better and if you've got a monster
marketing budget.

     I think there are three ways you can 'beat' Wikipedia in a smaller
sense.  (i) in another medium,  (ii) by targeting very specific
verticals,  or (iii) by creating derivative products that add a very
specific kind of value (that is,  targeting a horizontal)

     In (i) I think of companies like Foursquare and Fotopedia that
follow a mobile-first strategy.  If mobile apps got really big and
eclipsed the 'web as we know it',  I can see a space for a Wikipedia
successor.  This could entirely bypass the S.E.O. problem,  but couldn't
Wikipedia fight back with a mobile app of it's own?  On the other hand,  
this might not be so plausible:  the better mobile devices do an O.K.
job with 'HTML 5' and with improvements in hardware,  networking and in
HTML-related specifications,  so there might be no real advantage in
having 'an app for that'.  Already people are complaining that a
collection of apps on your device creates a number of 'walled gardens'
that can't be searched in aggregate,  and these kinds of pressures may
erode the progress of apps.

     For (ii) I think of Wikia,  which hosts things like

http://mario.wikia.com/wiki/MarioWiki

     Stuff like this drives deletionists nuts on Wikipedia,  but having
a place for them to live in Wikia makes everybody happy.  Here's a place
where the Notability policy means that Wikipedia isn't competitive.  
Now,  in general,  Wikia is trying to do this for thousands of subjects
(which might compete with Wikipedia overall) and they've had some
success,  but not an overwhelming amount.

     Speaking of notability,  another direction is to make something
that's more comprehensive than Wikipedia.  Consider Freebase,  which
accepts Person records for any non-fictional person and has detailed
records of millions of TV episodes,  music tracks,  books,  etc.  If
Wikipedia refuses to go someplace,  they create opportunities.

     As for (iii) you're more likely to have a complementary
relationship with Wikipedia.  You can take advantage of Wikipedia's
success and get some income to pay for people and machines.  There
wouldn't be any possibility of 'replacing' Wikipedia except in a crazy
long-term scenario where,  say,  we can convert Wikipedia into a
knowledge base that can grow and update itself with limited human
intervention.  (Personally I think this is 10-25 years off)

      Anyhow,  I could talk your ear off about (iii) but I'd make you
sign an N.D.A. first.  ;-)




_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Tei-2
In reply to this post by David Gerard-2
>With open source software, there are people who think “that’s dumb,” there are people who think “I want to see it >fixed” and there are people who think “I can do something about it.” The people at the intersection of all three  >power open source.


A lot of people in the open source project Y will not see a problem
with X,  being X a huge usability problem that stop a lot of people
from using Y.

So what you have is a lot of people "I don't see the problem with
that"  ( realistically, a lot of people that will talk about a lot of
things, and not about X ),  and maybe some of the people that have
problems with X that don't know how to communicate his problem, or
don't care enough.

Any open source project work like a club.  The club work for the
people that is part of the club, and does the things that the people
of the club enjoy.  If you like chess, you will not join the basket
club, and probably the basket club will never run a chess competition.
Or the chess club a basket competition.

If anything, the "Problem" with open source, is that any change is
incremental, and there's a lot of endogamy.

Also user suggestions are not much better. Users often ask for things
that are too hard, or incremental enhancements that will result on
bloat on the long term.

So really, what you may need is one person that can see the problems
of the newbies, of the devs, of the people with a huge investment on
the project, and make long term decisions, and have a lot of influence
on the people, while working on the shadows towards that goal.


--
--
ℱin del ℳensaje.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Aryeh Gregor
In reply to this post by Tim Starling-2
On Wed, Dec 29, 2010 at 10:26 PM, Tim Starling <[hidden email]> wrote:

> I think there are things we can do in software to help de-escalate
> this conflict between established editors and new editors.
>
> One thing we can do is to reduce the sense of urgency. Further
> deployment of FlaggedRevs (pending changes) is the obvious way to do
> this. By hiding recent edits, admins can deal with bad edits in their
> own time, rather reacting in the heat of the moment.
>
> Another thing we could do is to improve the means of communication.
> Better communication often helps to de-escalate a conflict.
>
> We could replace the terrible user talk page interface with an
> easy-to-use real-time messaging framework. We could integrate polite
> template responses with the UI. And we could provide a centralised
> forum-like view of such messages, to encourage mediators to review and
> de-escalate emotion-charged conversations.

We could also try to work out ways to make adminship less important.
If protection, blocking, and deletion could be made less necessary and
important in day-to-day editing, that would reduce the importance of
admins and reduce the difference between established and new
contributors.  You could often make do with much "softer" versions of
these three things, which could be given out much more liberally.

For instance, to replace blocking, you could have a system whereby any
reasonably established editor (> X edits/Y days) can place another
editor or IP address in moderation, so that their edits have to be
approved before going live, in Flagged Revs style.  As with blocking,
any established editor could also reverse such a block.  Abuse would
thus be easily reversed and fairly harmless (since the edits could go
through automatically when it's lifted, barring conflicts).  Sysops
would only be necessary if people with established accounts abuse
their rights.

Likewise, most deletion doesn't really need to make anything private.
Reasonably established editors could be given the right to soft-delete
a page such that any other such editor could read or undelete it.
This would be fine for the vast majority of deletions, like vanity
pages and spam.  Sysops would only have to get involved for copyright
infringement, privacy issues, and so on.

As for protection, we already have Flagged Revs.  Lower levels of
flagging should be imposable by people other than sysops, and since
those largely supersede semiprotection, sysops would again only be
needed to adjudicate disputes between established editors (like
full-protecting an edit-warred page).  Obviously, all these rights
would be revocable by sysops in the event of abuse.


Unfortunately, I don't think that technical solutions are going to fix
the problem on enwiki.  I think the only thing that will do it is if
Wikimedia adopts more explicit policies about creating a friendly
editing environment, and enforces them in the same vein as it does
copyright policies.  But that's easier said than done for a number of
reasons.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Alex Zaddach
In reply to this post by Tim Starling-2
On 12/29/2010 10:26 PM, Tim Starling wrote:

> On 29/12/10 18:31, Neil Kandalgaonkar wrote:
>> I've been inspired by the discussion David Gerard and Brion Vibber
>> kicked off, and I think they are headed in the right direction.
>>
>> But I just want to ask a separate, but related question.
>>
>> Let's imagine you wanted to start a rival to Wikipedia. Assume that you
>> are motivated by money, and that venture capitalists promise you can be
>> paid gazillions of dollars if you can do one, or many, of the following:
>>
>> 1 - Become a more attractive home to the WP editors. Get them to work on
>> your content.
>>
>> 2 - Take the free content from WP, and use it in this new system. But
>> make it much better, in a way Wikipedia can't match.
>
> This has been done before: Wikinfo, Citizendium, etc.
>
>> 3 - Attract even more readers, or perhaps a niche group of
>> super-passionate readers that you can use to build a new community.
>
> This is basically Wikia's business model. I think you need to think
> outside the box.
>
> I would make it more like World of Warcraft. We should incentivise
> people to set up wiki sweatshops in Indonesia, paying local people to
> "grind" all day, cleaning up articles, in order to build up a level 10
> admin character that can then be sold for thousands of dollars on the
> open market. Also it should have cool graphics.
>
> OK, if you want a real answer: I think if you could convince admins to
> be nicer to people, then that would make a bigger impact to
> Wikipedia's long-term viability than any ease-of-editing feature.
> Making editing easier will give you a one-off jump in editing
> statistics, it won't address the trend.
>
> We know from interviews and departure messages that the editing
> interface creates an initial barrier for entry, but for people who get
> past that barrier, various social factors, such as incivility and
> bureaucracy, limit the time they spend contributing.
>
> Once you burn someone out, they don't come back for a long time, maybe
> not ever. So you introduce a downwards trend which extends over
> decades, until the rate at which we burn people out meets the rate at
> which new editors are born.
>
> Active, established editors have a battlefront mentality. They feel as
> if they are fighting for the survival of Wikipedia against a constant
> stream of newbies who don't understand or don't care about our
> policies. As the stream of newbies increases, they become more
> desperate, and resort to more desperate (and less civil) measures for
> controlling the flood.
>
> Making editing easier could actually be counterproductive. If we let
> more people past the editing interface barrier before we fix our
> social problems, then we could burn out the majority of the Internet
> population before we figure out what's going on. Increasing the number
> of new editors by a large factor will increase the anxiety level of
> admins, and thus accelerate this process.

One thing that I think could help, at least on the English Wikipedia,
would be to further restrict new article creation. Right now, any
registered user can create a new article, and according to some
statistics I gathered a few months ago[1], almost 25% of new users make
their first edit creating an article. 81% of those users had their
article deleted and <0.1% of them were still editing a few (6-7) months
later, compared to 4% for the 19% whose articles were kept, giving a
total retention rate of 1.3%.

However, for the 75% of users who started by editing an existing
article, the overall retention rate was 2.5%. Still a small number, but
almost double the rate for the article creation route.

The English Wikipedia, with 3.5 million articles, has been scraping the
bottom of the notability barrel for a while. Creating a proper new
article is not an especially easy task in terms of editing, yet the
project practically encourages new users to do it. We're dropping new
users into the deep end of the pool, then getting angry at them when
they start to drown. What we should be doing instead is suggesting that
users add their information to an existing article somewhere (with
various tools to help them find it). And if they can't find anything
remotely related in 3.5 million articles, ask themselves whether they
still think its an appropriate topic.

This is an area where the foundation potentially could step in to change
things. Its never going to happen through the community, since there's
too many people (or at least too many loud people) with a "more is
better" mentality. (Part of the reason I gathered the stats was to prove
that most new users don't start by creating an article). They'll scream
and moan for a while about how we're being anti-wiki, but in the end,
most probably won't really care that much.

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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How would you disrupt Wikipedia?

Platonides
In reply to this post by Neil Kandalgaonkar
Neil Kandalgaonkar wrote:

> On 12/30/10 10:24 AM, Platonides wrote:
>> Neil Kandalgaonkar wrote:
>>> At some point, if we believe our community is our greatest asset, we
>>> have to think of Wikipedia as infrastructure not only for creating high
>>> quality articles, but also for generating and sustaining a high quality
>>> editing community.
>>>
>>> So we probably need an employee dedicated to this. (I think? Arguments?)
>>
>> He would be quite busy (and polyglot!) to keep an eye over the community
>> of +800 projects.
>
> Why is this a requirement?

The point is, there's no "one community" to "watch". Most people think
in enwiki, for being the biggest project, and most probably the base
project of those people.

But one must not forget that there are many WMF projects out there. It
doesn't end in enwp. They have similar problems, but cannot be
generalised either.
There's a risk of contracting someone as an injerence on the project
(seems the role for a facilitator, but I'd only place people that were
already in the community -the otrs folks seem a good fishing pool-, if
doing such thing). Plus, there's the view on how it may be perceived
(WMF trying to impose its views over the community, WMF really having
power on the project and thus being liable...).



> If you think about the sum total of user-hours spent on Wikipedia, the
> vast majority of them are spent in just three or four interface flows.

What are you thinking about? Things such as talk page messages. There
are shortcuts for those interfaces. Several gadgets/scripts provide a
tab for adding a template to a page + leave a predefined message to the
author talk page. That's good in a sense as the users *get* messages
(eg. when listing images for deletion), they are also quite full and
translated (relevant just for commons). But it also means that it's a
generic message, so not as appropiate for everyone.

We can make the flow faster, but we lose precision.


> But you're right; they can't be everywhere, so maybe there should be a
> guidelines page on design principles. We have WP:CIVILITY, do we have
> similar guidelines for software developers, on how to make it easy for
> the community to be civil?

I'm lost here. Are you calling uncivil the developer community for this
thread? You mean that WP:CIVILITY should be enforced by mediawiki?
Developers should be more helopful when dealing bug reports? What do you
mean?


> Frankly I don't think I'm qualified to do this. I know of a few people
> are brilliant at this, and who do this sort of thing for a living, but
> they are consultants. Fostering community on the web is generally
> considered a sort of black art... does anybody know of any less
> mystified way of dealing with the problem?



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123456 ... 8