Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wikipedia needs an IDE, not a WYSIWYG editor

medium.com

Post reply on HN
Print view View original

21–30 of 75 posts

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#21

Post by tatterdemalion »

tottenhm wrote: post #6

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

The comments on that article in MIT Technology Review seem to be a golden example of the problem with Wikipedia. A bunch of people with axes to grind saying "the problem with Wikipedia is that I didn't prevail in this or that dispute, and my brilliance isn't recognized there."

There just aren't incentives to contribute to Wikipedia aside from ego; its too hard to do it out of a sense of communitarian sharing. And its that same ego that makes the bureaucracy so awful.

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#24

Post by jamesfisher »

tottenhm wrote: post #6

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

I didn't mean to say it was the sole reason; just the reason relevant to my post. There certainly are other reasons and they are larger problems than the editor.

However, Wikipedia feels that the editor is a big enough problem that they have spent a lot of time and money on their Visual Editor. That time and money could have been better spent.

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#25

Post by ErrantX »

bjelkeman-again wrote: post #7
tottenhm wrote: post #6

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

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.

Link? I can probably help :)

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#27

Post by jamesfisher »

gwicke wrote: post #4
tree_of_item wrote: post #2

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

Nothing beats being told that what you just did is in fact not feasible ;) Check out this page: 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. Th…

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

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#28

Post by davidgerard »

gwicke wrote: post #4
tree_of_item wrote: post #2

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

Nothing beats being told that what you just did is in fact not feasible ;) Check out this page: 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. Th…

You and I know that it was just barely feasible, and if only MW had started with a parser rather than a series of regular expressions, we'd have had a visual editor in 2005 ...

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#29

Post by bobcostas55 »

tottenhm wrote: post #6

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

"Cultural issues" is the understatement of the year. Cultural catastrophe is what it is.

Wikipedia would be greatly improved if they just issued a lifetime ban to anyone with more than 100 edits. They are all small-minded despots whose only intention is carving out a little fiefdom of pages and "protecting"/manipulating them by any means possible. Usually with a political agenda in mind.

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#30

Post by philipn »

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.o... and 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.

Post reply on HN