On 28 December 2010 16:06, Victor Vasiliev vasilvv@gmail.com wrote:
I have thought about WYSIWYG editor for Wikipedia and found it technically impossible. The main and key problem of WYSIWIG are templates. You have to understand that templates are not single element of Wikipedia syntax, they are integral part of page markup. You do not insert "infobox template", you insert infobox *itself*, and from what I heard the templates were the main concern of many editors who were scared of wikitext. Now think of how many templates are there in Wikipedia, how frequently they are changed and how much time it would take to implement their editing.
Yes. So how do we sensibly - usably - deal with templates in a word-processor-like layout? Is there a way that passes usability muster for non-geeks? How do others do it? Do their methods actually work?
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?
- d.
On Tue, Dec 28, 2010 at 8:43 AM, David Gerard dgerard@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)
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@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:
- 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
On Tue, Dec 28, 2010 at 5:28 PM, Rob Lanphier robla@wikimedia.org 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)
(Lying on the ground in the foetal position sobbing gently ... poor poor Wiksource, forgotten again.)
Wikisource - we have tried to get the source and structure by regulating the spaces that we can, however, formalising template fields to forms would be great ...
* extension for DynamicPageList (previously rejected) * search engines that work with transcluded text * extension for music notation (Lilypond?) * pdf text extraction tool to be implemented * good metadata & tools * bibliographic tools, especially tools that allow sister cross-references * book-making tools that work with transcluded text * tools that allow "What links here" across all of WMF ...
Hell, I could even see that text from WS references could be framed and transcluded to WP, and provide a ready link back to the works at the sites. Same for WQ to transclude quotes from a WS reference text, ready links from Wiktionary to usage in WS books. That should be the value of a wiki and sister sites.
Regards, Andrew
On 28 Dec 2010 at 9:27, Brion Vibber wrote:
On Tue, Dec 28, 2010 at 8:43 AM, David Gerard dgerard@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:
- 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) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org