Hi Brion,
Thanks for laying out the problem so clearly! I agree wholeheartedly
that we need to avoid thinking about this problem too narrowly as a
user interface issue on top of existing markup+templates. More
inline:
On Tue, Dec 28, 2010 at 9:27 AM, Brion Vibber <brion(a)pobox.com> wrote:
This isn't a problem specific to Wikimedia;
established organizations of all
sorts have a very difficult time getting new ideas over that hump from "not
good enough for our core needs" to "*bam* slap it everywhere". By
concentrating on the areas that aren't served at all well by the current
system, we can make much greater headway in the early stages of development;
Clayton Christensen's "The Innovator's Dilemma" calls this
"competing
against non-consumption".
Thankfully, we at least we're not trying to defend a business model
and cost structure that's fundamentally incompatible with making a
change here. However, I know that's not the part that you're
highlighting, and I agree that Christensen's "competing against
non-consumption" concept is well worth learning about in this
context[1], as well as the concepts of "disruptive innovation" vs
"continuous innovation"[2]. As you've said, we've learned a lot in
the past decade of Wikipedia about how people use our the technology.
A new editing model that incorporates that learning will almost
certainly take a while to reach full parity in flexibility, power, and
performance. The current editor base of English Wikipedia probably
won't be patient with any changes that result in a loss of
flexibility, power and performance. Furthermore, many (perhaps even
most) things we'd be inclined to try would *not* have a measurable and
traceable impact on new editor acquisition and retention, which will
further diminish patience. A mature project like Wikipedia is a hard
place to hunt for willing guinea pigs.
For the Wikipedia case, we need to incubate the next
generation of
templating up to the point that they can actually undercut and replace
today's wikitext templates, or I worry we're just going to be sitting around
going "gosh I wish we could replace these templates and have markup that
works cleanly in wysiwyg" forever.
My current thoughts are to concentrate on a few areas:
1) create a widget/gadget/template/extension/plugin model built around
embedding blocks of information within a larger context...
2) ...where the data and rendering can be reasonably separate... (eg, not
having to pull tricks where you manually mix different levels of table
templates to make the infobox work right)
3) ...and the rendering can be as simple, or as fancy as complex, as your
imagination and HTML5 allow.
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.
There's already technically a kludgy model for that now: wrap the
whole thing in a tag, and put the parser for the new syntax in a tag
extension. That said, it would probably exacerbate our problems if we
allowed intermixing of old syntax and new syntax in a single revision.
The goal should be to move articles irreversibly toward a new model,
and I don't think it'd be possible to do this without the tools to
prevent us from backsliding (for example, tools that allow editors to
convert an article from old syntax to new syntax, and also tools that
allow administrators to lock down the syntax choice for an article
without locking down the article).
Still, it's pretty alluring to think about the upgrade of syntax as an
incremental problem within an article. We could figure out how to
solve one little corner of the data/rendering separation problem and
then move on to the next. For example, we could start with citations
and make sure it's possible to insert citations easily and cleanly,
and to extract citations from an article without relying on scraping
the HTML to get them. Or maybe we do that certain types of infoboxes
instead, and then gradually get more general. We can take advantage
of the fact that we've got millions of articles to help us choose
which particular types of data will benefit from a targeted approach,
and tailor extensions to very specific data problems, and then
generalize after we sort out what works/doesn't work with a few
specific cases.
So, which problem first?
Rob
[1] Those with an aversion to business-speak will require steely
fortitude to even click on the url, let alone actually read the
article, but it's still worth extracting the non-business points from
this article:
http://businessinnovationfactory.com/weblog/christensen_worldinnovationforum
[2] While there is a Wikipedia article describing this[3], a better
description of the important bits is here:
http://www.mail-archive.com/haskell@haskell.org/msg18498.html
[3] Whee, footnote to a footnote!
http://en.wikipedia.org/wiki/Disruptive_technology