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

[Mono mium]

How about attacking the problem by using something that already exists...


   - The Wikimedia Foundation gets a lot of support from Google,
   financially. How about we ask for some technology support as well? Google
   has a completely plugin-independant JS-based editor in Google Docs, as well
   as plenty of coders.
   - The simplest solution seems to be to translate WYS output into
   wikicode, so using the Google Docs editor, we simply have to translate the
   bold-looking text into wikicode.

Timeline of editing:
[WYSIWYG editor view:]
*Albert Einstein *was a popular

[Save page]

[One moment please]
<HIDDEN>
(translation)

(wikicode output):
*'''Albert Einstein''' *was a popular
</HIDDEN>

[Article re-appears]
*Albert Einstein *was a popular

What do you think?

On Tue, Dec 28, 2010 at 10:27 AM, Brion Vibber <brion at pobox.com> wrote:

> 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)
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>