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.
Wikipedia needs an IDE, not a WYSIWYG editor
41–50 of 75 posts
Re: Wikipedia needs an IDE, not a WYSIWYG editor
#42> 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/ [2] https://news.ycombinator.com/item?id=8507310
Re: Wikipedia needs an IDE, not a WYSIWYG editor
#43Earlier quoted context omitted.
I was also somewhat skeptical of the author's claim that the barrier to entry for Wikipedia editors was the editor itself. I've read a few papers concluding that Wikipedia contributions are declining because of the community pushing out people who don't understand the many rules that have been developed[1], or in other cases because editors have gotten into turf wars over articles they feel some sense of ownership ov…
> editors have gotten into turf wars over articles they feel some sense of ownership over That's exactly what killed my one and only attempt to substantially improve an article (not just typo-fixing and stuff): The two guys with a lot of edits on that page couldn't stand someone else editing "their" article. Sure, they tried to bring up superficial disagreements about the content, but that could have been resolved tr…
You fix it by social engineering.
If you go in and blam an entire page, no doubt the original authors will cry foul; it probably took them a fair amount of time, even if what they wrote wasn't particularly good. It's also fairly rude without at least giving them a chance to improve sections.
Incremental editing will also give you a far stronger case when they get arsey, particularly if your inclusions are better than what was there already.
The key is trying to work with the grumpy people and reassure them that you're not trying to take their article away from them.
Re: Wikipedia needs an IDE, not a WYSIWYG editor
#44Earlier quoted context omitted.
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 pr…
> 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 ." rel="nofollow">https://www.mediawiki.org/wiki/Extension:Scribunto>.)
Re: Wikipedia needs an IDE, not a WYSIWYG editor
#45I 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.
Re: Wikipedia needs an IDE, not a WYSIWYG editor
#46Earlier quoted context omitted.
The basic reason that Wikipedia editing is down is that most of the job is done. The goal was to produce a reasonably comprehensive encyclopedia. Mission accomplished. Most of the important articles were written years ago. Take a look at new articles being created. They are mostly about very minor subjects. This was typical of the paper encyclopedias. The initial creation of the Encyclopedia Brittanica was a huge job…
> Mission accomplished. Most of the important articles were written years ago. I would contend that should be leading to more edits. Few people have the depth of knowledge of expertise to contribute to 'US Foreign Policy' article, but masses can contribute to an article about their home town. For example, the article on my town doesn't even explain its unusal name. At least half of its residents could make that parti…
> At least half of its residents could make that particular edit
What proportion could/would actually cite a source for the edit, though? It's likely not that hard to find a source: the local library probably has some local-history books that explain the source of the name. But in my experience the proportion of people willing to open a book before making an edit is smallish. There are some local "edit-a-thons" trying to improve that, though. I've never been to one myself, but from what I can tell they tend to be organized at libraries or universities, and the organizers have already pulled out some relevant reference materials, so people can more easily start making cited improvements to articles about their local area.
Re: Wikipedia needs an IDE, not a WYSIWYG editor
#47I 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…
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.
Re: Wikipedia needs an IDE, not a WYSIWYG editor
#48"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.
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...
Re: Wikipedia needs an IDE, not a WYSIWYG editor
#49> 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.
Re: Wikipedia needs an IDE, not a WYSIWYG editor
#50Take 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.
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.
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