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

Brion Vibber brion at pobox.com
Tue Dec 28 17:27:41 UTC 2010

On Tue, Dec 28, 2010 at 8:43 AM, David Gerard <dgerard at gmail.com> wrote:

> e.g. Wikia has WYSIWYG editing and templates. They have a sort of
> solution to template editing in WYSIWYG. It's not great, but people
> sort of cope. How did they get there? What can be done to make it
> better, *conceptually*?
> What I'm saying there is that we don't start from the assumption that
> we know nothing and have to start from scratch, forming our answers
> only from pure application of personal brilliance; we should start
> from the assumption that we know actually quite a bit, if we only know
> who to ask and where. Does it require throwing out all previous work?
> etc., etc. And this is the sort of question that requires actual
> expense on resources to answer.
> Given that considerable work has gone on already, what would we do
> with resources to apply to the problem?

My primary interest at the moment in this area is to reframe the question a
bit; rather than "how do we make good WYSIWYG that works on the way
Wikipedia pages' markup and templates are structured now" -- which we know
has been extremely hard to get going -- to instead consider "how do we make
good WYSIWYG that does the sorts of things we currently use markup and
templates for, plus the things we wish we could do that we can't?"

We have indeed learned a *huge* amount from the last decade of Wikipedia and
friends, among them:

* authors and readers crave advanced systems for data & format-sharing (eg
putting structured info into infoboxes) and interactive features (even just
sticking a marker on a map!)
* most authors prefer simplicity of editing (keep the complicated stuff out
of the way until you need it)
* some authors will happily dive into hardcore coding to create the tools
they need (templates, user/site JS, gadgets)
* many other authors will very happily use those tools once they're created
* the less the guts of those tools are exposed, the easier it is for other
people to reuse them

The incredible creativity of Wikimedians in extending the frontend
capabilities of MediaWiki through custom JavaScript, and the markup system
through templates, has been blowing my mind for years. I want to find a way
to point that creativity straight forward, as it were, and use it to kick
some ass. :)

Within the Wikimedia ecosystem, we can roughly divide the world into
"Wikipedia" and "all the other projects". MediaWiki was created for
Wikipedia, based on previous software that had been adapted to the needs of
Wikipedia; and while the editing and template systems are sometimes awkward,
they work.

Our other projects like Commons, Wiktionary, Wikibooks, Wikiversity, and
Wikinews have *never* been as well served. The freeform markup model --
which works very well for body text on Wikipedia even if it's icky for
creating tables, diagrams and information sets -- has been a poorer fit, and
little effort has been spent on actually creating ways to support them well.

Commons needs better tools for annotating and grouping media resources.

Wiktionary needs structured data with editing and search tools geared
towards it.

Wikibooks needs a structure model that's based on groups of pages and media
resources, instead of just standalone freetext articles which may happen to
link to each other.

Wikiversity needs all those, and more interactive features and the ability
for users to group themselves socially and work together.

Getting anything done that would work on the huge, well-developed,
wildly-popular Wikipedia has always been a non-starter because it has to
deal with 10 years of backwards-compatibility from the get-go. I think it's
going to be a *lot* easier to get things going on those smaller projects
which are now so poorly served that most people don't even know they exist.

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".

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.

-- brion vibber (brion @ pobox.com)

More information about the wikimedia-l mailing list