Now, why not follow the MoinMoin example, and construct an extension for loading the wiki-page into OpenOffice, benefiting from the fact that the return path is already well-covered? "Order of magnitude" more simple.

Yury

Yury, I couldn't have thought of a better way to illustrate the problems with this conversation if I'd tried. You have my thanks. The problem with the participants here - those attempting to second-guess, particularly - is the repeated attempts to put yourselves into the shoes of new users, in ignorance of the fact that *none of us can adequately impersonate members of the general public*, and that basing how we approach lowering the barrier to participation on the principle that we can is dangerous at best. When you say something like "construct an extension for loading the wiki-page into OpenOffice" as a solution to the problem that one must be (1) relatively tech-savvy and (2) willing to jump through unnecessary hoops if you want to contribute, you highlight this; a custom extension is an awkward way of doing things. and an unnecessary hoop. A custom extension designed to work with a specific piece of software that is largely not used by the general population is similarly going to restrict who can participate, for precisely the same reasons that the existing markup is a restriction.

If your solution to "we need to avoid an overcomplicated interface mostly used by people with a primacy in tech" is to develop an extension that requires potential editors to have a specific piece of software people mostly don't use or install it, you are making a very good argument for why we should work on the research the usability initiative did with actual new editors, and not the ideas of anyone attempting to put themselves into the shoes of new editors. We're not new editors. We can't impersonate them - not adequately, and not for the purpose of somehow divining what it is they want. And we should stop pretending that we can.


--
Oliver Keyes
Community Liaison, Product Development
Wikimedia Foundation