
Wikipedia needs an IDE, not a WYSIWYG editor - jamesfisher
https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8
======
tottenhm
"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-
dec...](http://www.technologyreview.com/featuredstory/520446/the-decline-of-
wikipedia/) ).

(Edit: Not trying to be negative -- the suggestions in the article sound cool
anyway.)

~~~
bjelkeman-again
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.

~~~
mxfh
Editing is smallest issue with Wikipedia.

For anybody who does an occasional 5-10 edits per year. The admins leave no
moment unused to point out that you're doing something wrong (most likely
based on Guideline CA 13, where CA stands for cryptic abbreviation₁) and in a
lot of cases you're left to the god will of a single person.

The whole appeal system needs to be streamlined, it can't be that there a
multiple entry point's for a deleted article, solely because it was deleted
for different reasons.

It's the bureaucrats that drive people away, compared to Wikipedia the German
tax forms/appeals are outright user friendly by now.

₁ I see no good reasons why abbreviations should not be expanded by default in
discussion pages, makes it look way less intimidating to the casual user.

[For Wiki-Admin Eyes Only] If there any admins reading here: can someone
please undelete GitLab?
[https://en.wikipedia.org/wiki/Wikipedia:Requests_for_undelet...](https://en.wikipedia.org/wiki/Wikipedia:Requests_for_undeletion#GitLab)

~~~
tim333
I put up another GitLab article for you - the previous was deleted for lack of
links indication notability. I linked a couple of TheNextWeb articles that
will hopefully do. It's kind of hard work this stuff finding references and
the like. (I'm not an admin, just an occasional contributor).

Thinking about those kind of issues I think they could improve the
friendliness of the process by sending helpful / apologetic emails along the
lines of "Dear Mr X, Sorry we had to take down your article because we need
... blah blah... If you can find the references just click this and do this.
Best, Wikipedia team." Rather than the current situation where the article
just disappears and there are somewhat cryptic comments under the talk tab. I
don't think it would be terribly hard to implement.

~~~
mxfh
Thanks for your efforts (though you might have violated some policy, don't ask
me), I (User:Diskurs), I already added external sources for review here:

[https://en.wikipedia.org/wiki/User_talk:Mark_Arsten#GitLab_....](https://en.wikipedia.org/wiki/User_talk:Mark_Arsten#GitLab_.5BRequest_for_Undeletion.5D)

feel free to add them.

I don't understand were wikipedia's fixation (other than the name and origin)
comes from to handle everything as a wiki page, were any kind of ticketing
system might be way more transparent.

~~~
tim333
I stuck in the Chicago Trib reference.

>I don't understand were wikipedia's fixation (other than the name and origin)
comes from to handle everything as a wiki page

I think that's where a lot of problems come from and I think it's a tech issue
that they built a wiki system and used it for everything and it's hard to
change now it's ingrained. My guess with your appeal and the links is no one
looked at it because it's not like an email system where someone gets it in
their inbox, it's more that some one has to check on that page and maybe Bob
thinks Joe is doing it or visa versa, perhaps.

------
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...](http://commons.wikimedia.org/wiki/File:Wiki_feel_stupid_v2.ogv)
and
[http://usability.wikimedia.org/wiki/Usability_and_Experience...](http://usability.wikimedia.org/wiki/Usability_and_Experience_Study)

1\. Or really any kind of rich text editing.

2\. In terms of never, ever causing a problem with the underlying wikitext.

------
return0
"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
Yeah, I also don't get it, a few years ago it was the same method of editing
so why would they leave _now_?

------
discreteevent
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
Reminds me of when Word came out and had various WYSIWIG bugs so many stayed
with WordPerfect for reveal codes.

------
tree_of_item
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...](http://www.cs.rmit.edu.au/adcs2010/proceedings/pdf/paper%204.pdf)

~~~
gwicke
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-c...](http://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-
catches-up-with-the-web/)

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

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

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

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

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

------
contingencies
_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)

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

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

------
dynjo
They should implement an editor like [http://medium.com](http://medium.com) or
[http://slimwiki.com](http://slimwiki.com)

~~~
samdroid
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/)

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

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

~~~
_delirium
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
They should also have mechanisms in place to stop events like these from
happening:

[http://www.foxnews.com/tech/2013/09/06/wikistorming-
colleges...](http://www.foxnews.com/tech/2013/09/06/wikistorming-colleges-
offer-credit-to-corrupt-wikipedia/)

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

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

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

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

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

------
hlfcoding
Don't you mean CMS?

------
Jerry_li
Maybe something like an enhanced LaTeX.

