10 ms·

Wikipedia needs an IDE, not a WYSIWYG editor

196 points by jamesfisher 12y ago

tree_of_item 12y ago
This isn't really feasible, as Mediawiki's markup is far too hard to parse[0]. You can't just write an IDE for wikitext in a nice language, you'd need to instrument Mediawiki itself somehow to give fine grained information. [0] http://www.cs.rmit.edu.au/adcs2010/proceedings/pdf/paper%204.pdf http://www.cs.rmit.edu.au/adcs2010/proceedings/pdf/paper%204...
- atdt 12y ago
  There exists a bidirectional parser that converts between wikitext and HTML/XML DOM with RDFa. It's called Parsoid[0], and it powers VisualEditor, as well as a number of other applications. [0] https://www.mediawiki.org/wiki/Parsoid https://www.mediawiki.org/wiki/Parsoid
- gwicke 12y ago
  Nothing beats being told that what you just did is in fact not feasible ;) Check out this page: https://www.mediawiki.org/wiki/Parsoid https://www.mediawiki.org/wiki/Parsoid This is the bidirectional conversion engine between wikitext and HTML+RDFa that powers VisualEditor and several other tools. It tracks source range to DOM structure correspondence as proposed in the post. At this point, the IDE is basically a user interface and performance problem. The conversion is readily available through a REST interface, but on the largest articles parsing from modified wikitext to HTML can take around 10 seconds. Most of that time is spent in the expansion of the myriad of citation templates that we like people to add. It is possible to speed this up to something more usable for an IDE, but it's not trivial. You might also be interested in this blog post about some of the challenges we encountered while building Parsoid: http://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-catches-up-with-the-web/ http://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-c...
  - jamesfisher 12y ago
    Hello! OP here. I'm totally ignorant of Parsoid but I respectfully suggest that bidirectional lossless conversion is not possible in general. First, it relies on the function Wikitext->HTML being injective. But isn't it trivial to create two different Wikitexts that compile to the same HTML? Whitespace is just the start of this story. Second, apparently the template language is Turing-complete. Let's say I write a prime sieve in order to generate a page that lists the first 100 prime numbers. What would it then mean to edit "31" to change it to "30"? (With apologies for not yet having read the things you kindly linked to.)
    - EdiX 12y ago
      >Second, apparently the template language is Turing-complete. Let's say I write a prime sieve in order to generate a page that lists the first 100 prime numbers You can't. Using recursion (even primitive) is discouraged, there are even automated safeguards that make it hard (but I don't remember what they are exactly). But I agree with you in general, I think making a visual editor that deals with templates correctly is not an easy task.
    - MatmaRex 12y ago
      > First, it relies on the function Wikitext->HTML being injective. But isn't it trivial to create two different Wikitexts that compile to the same HTML? Whitespace is just the start of this story. Yes, and Parsoid works around this by preserving some metadata about wikitext in HTML (such as information about whitespace around syntax elements) and, since this preservation isn't perfect, only reserializing HTML→wikitext where the content was changed during editing. > Second, apparently the template language is Turing-complete. Let's say I write a prime sieve in order to generate a page that lists the first 100 prime numbers. What would it then mean to edit "31" to change it to "30"? Assuming we're talking about VisualEditor, you currently just can't do that (you can only delete the entire template inclusion and replace it with normal text, or edit template parameters). (As a nitpick, wikitext is not Turing-complete (there is no loop or recursion construct, recursion is explicitly checked for and causes an error), you can only write complicated algorithms by manually unrolling enough loops. However, for some time now you can also write templates in Lua, which is a proper Turing-complete programming language, see <https://www.mediawiki.org/wiki/Extension:Scribunto>. https://www.mediawiki.org/wiki/Extension:Scribunto>.)
Dorian-Marie 12y ago
Talk is still cheap. I think a prototype would be far more convincing than a blog post.
tottenhm 12y ago
"Users apparently dislike this workflow so much that they don’t bother contributing at all: significantly less people are editing Wikipedia than did a few years ago." To be fair, I think this exaggerates the role of the editing UI -- if the editing UI was that bad, then people wouldn't have contributed in the first place. The more common narrative for reduced participation is the growth of cultural issues which make it less rewarding to participate (e.g. http://www.technologyreview.com/featuredstory/520446/the-decline-of-wikipedia/ http://www.technologyreview.com/featuredstory/520446/the-dec... ). (Edit: Not trying to be negative -- the suggestions in the article sound cool anyway.)
- bjelkeman-again 12y ago
  As you say, dealing with the UI is fine. Dealing with the bureaucrats isn't. Having your account banned and your new article marked for spam by a very abrasive person, when trying to add legitimate content, rather than being supported through the maze of rules, as happened to a colleague the other day. That is a problem which stops meaningful content being added.
  - ErrantX 12y ago
    Link? I can probably help :)
    - bjelkeman-again 12y ago
      Thanks. I am sitting down with Wikimedia Sweden next week to take a serious look at how we can add some of our rather good content without tripping all the wrong triggers. If it doesn't work I'll ping you. No need to agonise over it until this doesn't work, but appreciate the offer.
  - _delirium 12y ago
    I think false positives on spam are a significant problem for Wikipedia, but false negatives are also a significant problem (maybe a bigger one), which is part of what makes it tough. If you hit "random article" a bunch of times, look for biographies on currently living people of relatively low levels of importance. I would estimate about 20% of those are clearly puff pieces, either written by a PR agency, a university/company publicity department, the person themselves, someone they know well, etc. It's not the end of the world since those articles also tend to be not that frequently read (articles on high-profile people are much harder for a PR agency to control the content of), but it does make me take Wikipedia somewhat less seriously when such a large proportion of random pages I land on are obviously written by a PR hack, using the kind of diction you expect to find in a press release or an official university bio, rather than language you would expect to find in a respectable encyclopedia. While bios are the biggest area, there's a bunch of other areas where I've learned not to pay attention to Wikipedia because it's too spammy: anything to do with tourism (full of booster and hotel spam), any company except very high-profile ones, many non-profit organizations, etc. It's good when writing about people/things that no longer exist, though; the articles about 19th-century French companies don't read like they were written by a PR agency.
nl 12y ago
Take a look at the Wikidata project - it's designed for editing structured data. Unfortunately I wouldn't say it is very easy to use - the Wikipedia editor is much easier. It's also completely unclear which parts of Wikidata data are used in Wikipedia, and where. That means the Wikidata data is usually much worse than the Wikipedia data, even if it theoretically easier for machines to use.
- hobofan 12y ago
  At the moment Wikidata isn't used/usable in Wikipedia at all, apart from coordinating the site links across languages. I'm not sure what you mean when you say that the editor of Wikidata isn't easy to use, I think its interface is pretty straightforward.
  - MatmaRex 12y ago
    You can embed statements from a Wikidata item in the corresponding article on Wikipedia using the {{#property:…}} parser function. This is largely unused on the English Wikipedia, but some language versions already use this for their infoboxes – for example the infobox on this page is partially generated from Wikidata: https://pl.wikipedia.org/wiki/Ankara https://pl.wikipedia.org/wiki/Ankara
    - nl 12y ago
      Do you know why the English Wikipedia doesn't use it? It is simply because the English Wikipedia information is generally better than the corresponding Wikidata information?
      - MatmaRex 12y ago
        I believe it's simply because no one has yet put in the effort necessary to start using it. It might be a conscious decision, but if it was discussed anywhere, I completely missed that. (English Wikipedians in general are very "territorial" in my experience, so to speak, and rarely appreciate efforts that put some piece of "their" articles beyond their "jurisdiction", like Wikidata does. Editors from other language versions are a lot more welcoming.)
dynjo 12y ago
They should implement an editor like http://medium.com http://medium.com or http://slimwiki.com http://slimwiki.com
- samdroid 12y ago
  I would vote for something like StackEdit beta [1]. It is really nice in the way it keeps the syntax (markdown) in a WYSIWYG-style editor. [1] http://stackedit-beta.herokuapp.com/ http://stackedit-beta.herokuapp.com/
louhike 12y ago
An IDE looks like a solution for developers by developers. I'm not sure it will appeal to most people. I consider the Visual Editor to be a good solution for non-techie newcomers. They are more used to visually similar tools.
hlfcoding 12y ago
Don't you mean CMS?
deleted 12y ago
[deleted]
discreteevent 12y ago
So he goes from: " Thing is, editors hated its bugginess so much that the roll-out was reverted shortly afterwards." to: " Their solution to this was a WYSIWYG editor, which failed for the basic reason that it denies the fact that Wikipedia is a program. " Something tells me he might be making it up as he goes along! I wonder how successful Microsoft Word would have been with markdown editor.
- 83457 12y ago
  Reminds me of when Word came out and had various WYSIWIG bugs so many stayed with WordPerfect for reveal codes.
nma83 12y ago
mediawiki-mode in emacs seems like a good solution, and emacs has proven to be a good enough IDE for other programming languages.
- _delirium 12y ago
  Interesting, I didn't know about mediawiki-mode. Something like that does sound like the right way to go for a certain class of "power users" who want an IDE: build on top of an existing IDE, with interaction to Wikipedia itself done via the MediaWiki API.
throwmeawaypg 12y ago
They should also have mechanisms in place to stop events like these from happening: http://www.foxnews.com/tech/2013/09/06/wikistorming-colleges-offer-credit-to-corrupt-wikipedia/ http://www.foxnews.com/tech/2013/09/06/wikistorming-colleges...
dmolony 12y ago
If that blog was a wiki, we could correct the typos.
return0 12y ago
"Users apparently dislike this workflow so much that they don’t bother contributing at all: significantly less people are editing Wikipedia than did a few years ago." Oh, the arbitrary causation!
- Aardwolf 12y ago
  Yeah, I also don't get it, a few years ago it was the same method of editing so why would they leave now?
philipn 12y ago
I sympathize with the sentiment expressed by the OP here, but his conclusions -- especially that the VisualEditor project is not worth undertaking -- are, I believe, very much off base. The Wikimedia Foundation did a great deal of research, including professional usability testing, and reached the (I believe fairly self-evident!) conclusion that a visual editing environment was sorely needed. You can go look up videos of regular people attempting to contribute to Wikipedia if you don't believe me[1]. The difficulty of the task, the particularities of hardcore Wikipedia editors, and the importance of preserving the record that Wikipedia's edits represent makes the project have a very real amount of essential complexity. If you think this is easy then you have not done much work with complex rich text editing on the web[2]. People in this thread suggesting Wikipedia use an off-the-shelf OSS rich text editor don't understand the requirements of the problem. The team at the Wikimedia Foundation has done an exceptional job given the task at hand, especially given their relatively small amount of funding (relative to other sites Wikipedia's size). The reasons the VisualEditor isn't enabled by default have to do with getting from a 97% solution to a 99.9% solution[3], and based on the work I've seen out of the Wikimedia engineering team, I'm sure they will get there. 1. http://commons.wikimedia.org/wiki/File:Wiki_feel_stupid_v2.ogv http://commons.wikimedia.org/wiki/File:Wiki_feel_stupid_v2.o... and http://usability.wikimedia.org/wiki/Usability_and_Experience_Study http://usability.wikimedia.org/wiki/Usability_and_Experience... 1. Or really any kind of rich text editing. 2. In terms of never, ever causing a problem with the underlying wikitext.
giancarlostoro 12y ago
I love the subtle inclusion of the Operation Northwoods page as an example.
Double_Cast 12y ago
gwern had a thing or two to say about wikipedia. As I remember, he said its biggest issues were cultural and that technology issues were a red herring. I'm interested if he has anything to add. [0] http://www.gwern.net/In%20Defense%20Of%20Inclusionism http://www.gwern.net/In%20Defense%20Of%20Inclusionism
n0nick 12y ago
> The one unconventional suggestion is the idea of a correspondence between the characters of the source text and the HTML text. Did you get a chance to check out fellow HN homepage link Paperman [1][2]? It offers exactly what you propose: Double-clicking on the results frame highlights the relevant line in the source, and vice versa. This could easily be adapted to match your suggestion. [1] http://paperman.patricklorio.com/ http://paperman.patricklorio.com/ [2] https://news.ycombinator.com/item?id=8507310 https://news.ycombinator.com/item?id=8507310
fidotron 12y ago
I would echo the suspicion that the problems here are cultural and not technical, however, I think the solution is kind of technical. Basically, in future why assume we have one definitive repository of objective fact? The notion is ridiculous. What I believe will happen is a git-ification of Wikipedia, so you can fork the whole thing, run your own when you disagree with the direction, and pull in changes from those you trust. If you're going to attempt to fix this class of problems this is the only way forward.
- DanBC 12y ago
  People want to force their version of truth into Wikipedia. They dont care that their version of truth is already available on some other website.
MatmaRex 12y ago
> Visual Editor was rolled out in 2013. Thing is, editors hated its bugginess so much that the roll-out was reverted shortly afterwards. (…) Why did the Visual Editor fail? Because it tries to deny the basic fact that Wikipedia is a program, not a word document. Eh, I can't really agree with this. VisualEditor rollout was indeed premature (critical features like template editing were developed literally days before it), but a year has passed and it's gone a long way since then. Haters still hate it, but personally I find it more pleasant to use than wikitext for many tasks. This was a really interesting read, though. I still this there's value in the WYSIWYG paradigm, even if we have to fall back to "IDE mode" for infoboxes and such (right now if you double-click a template, you're shown a key-value table to fill in; there's no live preview…). After all, most of the content of Wikipedia is text with some light formatting.
Jerry_li 12y ago
Maybe something like an enhanced LaTeX.
sparkzilla 12y ago
The main problem with Wikipedia is not the editor, but the wiki. Because wiki pages are structured as pages it lets real or imagined experts have control of the entire page. This leads to groupthink, censorship, bullying, gender bias, harassment, excessive rules, vandalism, edit-warring, unsortable page content, inability to cross-reference data across pages. At Newslines, we solve all of these problem for news and biography pages (the most popular pages on Wikipedia) by using the news event as the core content of the page, as well as a number of other features that allow users to write without harassment. As a result, unlike Wikipedia, which has 90% young male contributors, we have 80% women and minority contributors. http://newslines.org http://newslines.org
d23 12y ago
> This tension is irresolvable: the terms “WYSIWYG” and “abstraction” are literally antonyms. Except they aren't. WYSIWYG is an abstraction over the code layer that works in the terms of "bold", "italics" and "underline".
contingencies 12y ago
I must say that Wikipedia community has become very effective at giving partisan editors tools to target undesirable editors - a Byzantine collection of policies which admins overzealously enforce without a second thought, and without thinking of a big picture. Admins in fact are incentivized not to involve themselves, which basically gives the enforcement gun to POV-pushers which are intimately acquainted with all the glorious details of the relevant wikilese. I urge admins to think outside the policy-enforcing request-observing mode. https://en.wikipedia.org/wiki/User:Ivan_%C5%A0tambuk https://en.wikipedia.org/wiki/User:Ivan_%C5%A0tambuk
aaron695 12y ago
My understanding is they don't want more idiots editing, it's a 'feature' that it's tricky to edit. I also considered the decline is that it's kinda 'complete' it's not like the old days where it was easy to contribute something important and meaningful.

196 points by jamesfisher 12y ago

This isn't really feasible, as Mediawiki's markup is far too hard to parse[0]. You can't just write an IDE for wikitext in a nice language, you'd need to instrument Mediawiki itself somehow to give fine grained information. [0] http://www.cs.rmit.edu.au/adcs2010/proceedings/pdf/paper%204.pdf http://www.cs.rmit.edu.au/adcs2010/proceedings/pdf/paper%204...

atdt 12y ago
There exists a bidirectional parser that converts between wikitext and HTML/XML DOM with RDFa. It's called Parsoid[0], and it powers VisualEditor, as well as a number of other applications. [0] https://www.mediawiki.org/wiki/Parsoid https://www.mediawiki.org/wiki/Parsoid
gwicke 12y ago
Nothing beats being told that what you just did is in fact not feasible ;) Check out this page: https://www.mediawiki.org/wiki/Parsoid https://www.mediawiki.org/wiki/Parsoid This is the bidirectional conversion engine between wikitext and HTML+RDFa that powers VisualEditor and several other tools. It tracks source range to DOM structure correspondence as proposed in the post. At this point, the IDE is basically a user interface and performance problem. The conversion is readily available through a REST interface, but on the largest articles parsing from modified wikitext to HTML can take around 10 seconds. Most of that time is spent in the expansion of the myriad of citation templates that we like people to add. It is possible to speed this up to something more usable for an IDE, but it's not trivial. You might also be interested in this blog post about some of the challenges we encountered while building Parsoid: http://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-catches-up-with-the-web/ http://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-c...
- jamesfisher 12y ago
  Hello! OP here. I'm totally ignorant of Parsoid but I respectfully suggest that bidirectional lossless conversion is not possible in general. First, it relies on the function Wikitext->HTML being injective. But isn't it trivial to create two different Wikitexts that compile to the same HTML? Whitespace is just the start of this story. Second, apparently the template language is Turing-complete. Let's say I write a prime sieve in order to generate a page that lists the first 100 prime numbers. What would it then mean to edit "31" to change it to "30"? (With apologies for not yet having read the things you kindly linked to.)
  - EdiX 12y ago
    >Second, apparently the template language is Turing-complete. Let's say I write a prime sieve in order to generate a page that lists the first 100 prime numbers You can't. Using recursion (even primitive) is discouraged, there are even automated safeguards that make it hard (but I don't remember what they are exactly). But I agree with you in general, I think making a visual editor that deals with templates correctly is not an easy task.
  - MatmaRex 12y ago
    > First, it relies on the function Wikitext->HTML being injective. But isn't it trivial to create two different Wikitexts that compile to the same HTML? Whitespace is just the start of this story. Yes, and Parsoid works around this by preserving some metadata about wikitext in HTML (such as information about whitespace around syntax elements) and, since this preservation isn't perfect, only reserializing HTML→wikitext where the content was changed during editing. > Second, apparently the template language is Turing-complete. Let's say I write a prime sieve in order to generate a page that lists the first 100 prime numbers. What would it then mean to edit "31" to change it to "30"? Assuming we're talking about VisualEditor, you currently just can't do that (you can only delete the entire template inclusion and replace it with normal text, or edit template parameters). (As a nitpick, wikitext is not Turing-complete (there is no loop or recursion construct, recursion is explicitly checked for and causes an error), you can only write complicated algorithms by manually unrolling enough loops. However, for some time now you can also write templates in Lua, which is a proper Turing-complete programming language, see <https://www.mediawiki.org/wiki/Extension:Scribunto>. https://www.mediawiki.org/wiki/Extension:Scribunto>.)

Dorian-Marie 12y ago

Talk is still cheap. I think a prototype would be far more convincing than a blog post.

tottenhm 12y ago

"Users apparently dislike this workflow so much that they don’t bother contributing at all: significantly less people are editing Wikipedia than did a few years ago." To be fair, I think this exaggerates the role of the editing UI -- if the editing UI was that bad, then people wouldn't have contributed in the first place. The more common narrative for reduced participation is the growth of cultural issues which make it less rewarding to participate (e.g. http://www.technologyreview.com/featuredstory/520446/the-decline-of-wikipedia/ http://www.technologyreview.com/featuredstory/520446/the-dec... ). (Edit: Not trying to be negative -- the suggestions in the article sound cool anyway.)

bjelkeman-again 12y ago
As you say, dealing with the UI is fine. Dealing with the bureaucrats isn't. Having your account banned and your new article marked for spam by a very abrasive person, when trying to add legitimate content, rather than being supported through the maze of rules, as happened to a colleague the other day. That is a problem which stops meaningful content being added.
- ErrantX 12y ago
  Link? I can probably help :)
  - bjelkeman-again 12y ago
    Thanks. I am sitting down with Wikimedia Sweden next week to take a serious look at how we can add some of our rather good content without tripping all the wrong triggers. If it doesn't work I'll ping you. No need to agonise over it until this doesn't work, but appreciate the offer.
- _delirium 12y ago
  I think false positives on spam are a significant problem for Wikipedia, but false negatives are also a significant problem (maybe a bigger one), which is part of what makes it tough. If you hit "random article" a bunch of times, look for biographies on currently living people of relatively low levels of importance. I would estimate about 20% of those are clearly puff pieces, either written by a PR agency, a university/company publicity department, the person themselves, someone they know well, etc. It's not the end of the world since those articles also tend to be not that frequently read (articles on high-profile people are much harder for a PR agency to control the content of), but it does make me take Wikipedia somewhat less seriously when such a large proportion of random pages I land on are obviously written by a PR hack, using the kind of diction you expect to find in a press release or an official university bio, rather than language you would expect to find in a respectable encyclopedia. While bios are the biggest area, there's a bunch of other areas where I've learned not to pay attention to Wikipedia because it's too spammy: anything to do with tourism (full of booster and hotel spam), any company except very high-profile ones, many non-profit organizations, etc. It's good when writing about people/things that no longer exist, though; the articles about 19th-century French companies don't read like they were written by a PR agency.

nl 12y ago

Take a look at the Wikidata project - it's designed for editing structured data. Unfortunately I wouldn't say it is very easy to use - the Wikipedia editor is much easier. It's also completely unclear which parts of Wikidata data are used in Wikipedia, and where. That means the Wikidata data is usually much worse than the Wikipedia data, even if it theoretically easier for machines to use.

hobofan 12y ago
At the moment Wikidata isn't used/usable in Wikipedia at all, apart from coordinating the site links across languages. I'm not sure what you mean when you say that the editor of Wikidata isn't easy to use, I think its interface is pretty straightforward.
- MatmaRex 12y ago
  You can embed statements from a Wikidata item in the corresponding article on Wikipedia using the {{#property:…}} parser function. This is largely unused on the English Wikipedia, but some language versions already use this for their infoboxes – for example the infobox on this page is partially generated from Wikidata: https://pl.wikipedia.org/wiki/Ankara https://pl.wikipedia.org/wiki/Ankara
  - nl 12y ago
    Do you know why the English Wikipedia doesn't use it? It is simply because the English Wikipedia information is generally better than the corresponding Wikidata information?
    - MatmaRex 12y ago
      I believe it's simply because no one has yet put in the effort necessary to start using it. It might be a conscious decision, but if it was discussed anywhere, I completely missed that. (English Wikipedians in general are very "territorial" in my experience, so to speak, and rarely appreciate efforts that put some piece of "their" articles beyond their "jurisdiction", like Wikidata does. Editors from other language versions are a lot more welcoming.)

dynjo 12y ago

They should implement an editor like http://medium.com http://medium.com or http://slimwiki.com http://slimwiki.com

samdroid 12y ago
I would vote for something like StackEdit beta [1]. It is really nice in the way it keeps the syntax (markdown) in a WYSIWYG-style editor. [1] http://stackedit-beta.herokuapp.com/ http://stackedit-beta.herokuapp.com/

louhike 12y ago

An IDE looks like a solution for developers by developers. I'm not sure it will appeal to most people. I consider the Visual Editor to be a good solution for non-techie newcomers. They are more used to visually similar tools.

hlfcoding 12y ago

Don't you mean CMS?

deleted 12y ago

[deleted]

discreteevent 12y ago

So he goes from: " Thing is, editors hated its bugginess so much that the roll-out was reverted shortly afterwards." to: " Their solution to this was a WYSIWYG editor, which failed for the basic reason that it denies the fact that Wikipedia is a program. " Something tells me he might be making it up as he goes along! I wonder how successful Microsoft Word would have been with markdown editor.

83457 12y ago
Reminds me of when Word came out and had various WYSIWIG bugs so many stayed with WordPerfect for reveal codes.

nma83 12y ago

mediawiki-mode in emacs seems like a good solution, and emacs has proven to be a good enough IDE for other programming languages.

_delirium 12y ago
Interesting, I didn't know about mediawiki-mode. Something like that does sound like the right way to go for a certain class of "power users" who want an IDE: build on top of an existing IDE, with interaction to Wikipedia itself done via the MediaWiki API.

throwmeawaypg 12y ago

They should also have mechanisms in place to stop events like these from happening: http://www.foxnews.com/tech/2013/09/06/wikistorming-colleges-offer-credit-to-corrupt-wikipedia/ http://www.foxnews.com/tech/2013/09/06/wikistorming-colleges...

dmolony 12y ago

If that blog was a wiki, we could correct the typos.

return0 12y ago

"Users apparently dislike this workflow so much that they don’t bother contributing at all: significantly less people are editing Wikipedia than did a few years ago." Oh, the arbitrary causation!

Aardwolf 12y ago
Yeah, I also don't get it, a few years ago it was the same method of editing so why would they leave now?

philipn 12y ago

I sympathize with the sentiment expressed by the OP here, but his conclusions -- especially that the VisualEditor project is not worth undertaking -- are, I believe, very much off base. The Wikimedia Foundation did a great deal of research, including professional usability testing, and reached the (I believe fairly self-evident!) conclusion that a visual editing environment was sorely needed. You can go look up videos of regular people attempting to contribute to Wikipedia if you don't believe me[1]. The difficulty of the task, the particularities of hardcore Wikipedia editors, and the importance of preserving the record that Wikipedia's edits represent makes the project have a very real amount of essential complexity. If you think this is easy then you have not done much work with complex rich text editing on the web[2]. People in this thread suggesting Wikipedia use an off-the-shelf OSS rich text editor don't understand the requirements of the problem. The team at the Wikimedia Foundation has done an exceptional job given the task at hand, especially given their relatively small amount of funding (relative to other sites Wikipedia's size). The reasons the VisualEditor isn't enabled by default have to do with getting from a 97% solution to a 99.9% solution[3], and based on the work I've seen out of the Wikimedia engineering team, I'm sure they will get there. 1. http://commons.wikimedia.org/wiki/File:Wiki_feel_stupid_v2.ogv http://commons.wikimedia.org/wiki/File:Wiki_feel_stupid_v2.o... and http://usability.wikimedia.org/wiki/Usability_and_Experience_Study http://usability.wikimedia.org/wiki/Usability_and_Experience... 1. Or really any kind of rich text editing. 2. In terms of never, ever causing a problem with the underlying wikitext.

giancarlostoro 12y ago

I love the subtle inclusion of the Operation Northwoods page as an example.

Double_Cast 12y ago

gwern had a thing or two to say about wikipedia. As I remember, he said its biggest issues were cultural and that technology issues were a red herring. I'm interested if he has anything to add. [0] http://www.gwern.net/In%20Defense%20Of%20Inclusionism http://www.gwern.net/In%20Defense%20Of%20Inclusionism

n0nick 12y ago

> The one unconventional suggestion is the idea of a correspondence between the characters of the source text and the HTML text. Did you get a chance to check out fellow HN homepage link Paperman [1][2]? It offers exactly what you propose: Double-clicking on the results frame highlights the relevant line in the source, and vice versa. This could easily be adapted to match your suggestion. [1] http://paperman.patricklorio.com/ http://paperman.patricklorio.com/ [2] https://news.ycombinator.com/item?id=8507310 https://news.ycombinator.com/item?id=8507310

fidotron 12y ago

I would echo the suspicion that the problems here are cultural and not technical, however, I think the solution is kind of technical. Basically, in future why assume we have one definitive repository of objective fact? The notion is ridiculous. What I believe will happen is a git-ification of Wikipedia, so you can fork the whole thing, run your own when you disagree with the direction, and pull in changes from those you trust. If you're going to attempt to fix this class of problems this is the only way forward.

DanBC 12y ago
People want to force their version of truth into Wikipedia. They dont care that their version of truth is already available on some other website.

MatmaRex 12y ago

> Visual Editor was rolled out in 2013. Thing is, editors hated its bugginess so much that the roll-out was reverted shortly afterwards. (…) Why did the Visual Editor fail? Because it tries to deny the basic fact that Wikipedia is a program, not a word document. Eh, I can't really agree with this. VisualEditor rollout was indeed premature (critical features like template editing were developed literally days before it), but a year has passed and it's gone a long way since then. Haters still hate it, but personally I find it more pleasant to use than wikitext for many tasks. This was a really interesting read, though. I still this there's value in the WYSIWYG paradigm, even if we have to fall back to "IDE mode" for infoboxes and such (right now if you double-click a template, you're shown a key-value table to fill in; there's no live preview…). After all, most of the content of Wikipedia is text with some light formatting.

Jerry_li 12y ago

Maybe something like an enhanced LaTeX.

sparkzilla 12y ago

The main problem with Wikipedia is not the editor, but the wiki. Because wiki pages are structured as pages it lets real or imagined experts have control of the entire page. This leads to groupthink, censorship, bullying, gender bias, harassment, excessive rules, vandalism, edit-warring, unsortable page content, inability to cross-reference data across pages. At Newslines, we solve all of these problem for news and biography pages (the most popular pages on Wikipedia) by using the news event as the core content of the page, as well as a number of other features that allow users to write without harassment. As a result, unlike Wikipedia, which has 90% young male contributors, we have 80% women and minority contributors. http://newslines.org http://newslines.org

d23 12y ago

> This tension is irresolvable: the terms “WYSIWYG” and “abstraction” are literally antonyms. Except they aren't. WYSIWYG is an abstraction over the code layer that works in the terms of "bold", "italics" and "underline".

contingencies 12y ago

I must say that Wikipedia community has become very effective at giving partisan editors tools to target undesirable editors - a Byzantine collection of policies which admins overzealously enforce without a second thought, and without thinking of a big picture. Admins in fact are incentivized not to involve themselves, which basically gives the enforcement gun to POV-pushers which are intimately acquainted with all the glorious details of the relevant wikilese. I urge admins to think outside the policy-enforcing request-observing mode. https://en.wikipedia.org/wiki/User:Ivan_%C5%A0tambuk https://en.wikipedia.org/wiki/User:Ivan_%C5%A0tambuk

aaron695 12y ago

My understanding is they don't want more idiots editing, it's a 'feature' that it's tricky to edit. I also considered the decline is that it's kinda 'complete' it's not like the old days where it was easy to contribute something important and meaningful.