Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×
Software Wikipedia

How Can Wikipedia's Visual Editor Top Other Word Processors? 196

First time accepted submitter azadnama writes "Wikimedia Foundation, the organization behind Wikipedia, is aware of the fact the MediaWiki formatting syntax is a major obstacle for people's participation in writing on the site. To address this problem, the Foundation is developing VisualEditor—a web-based WYSIWYG interface for editing articles. It's supposed to be similar to a word processor, like LibreOffice, Microsoft Word, Pages, Google Docs, and others. And this is the time to ask: What did your word processor get wrong and how can Wikipedia's VisualEditor get it right?"
This discussion has been archived. No new comments can be posted.

How Can Wikipedia's Visual Editor Top Other Word Processors?

Comments Filter:
  • Styles (Score:2, Insightful)

    by Anonymous Coward on Saturday November 17, 2012 @03:32PM (#42013773)

    I use them all the time and abhor when they do not behave consistently.

    Funny thing, styles work better in OO.o than in MS Office.

  • by Anonymous Coward on Saturday November 17, 2012 @03:33PM (#42013783)
    Get rid of buttons for italic, bold, underlined and other manual ways of editing. Using these instead of proper format use hinders good documents and makes later reformatting a pain in the ass.
  • by caferace ( 442 ) on Saturday November 17, 2012 @03:35PM (#42013805) Homepage
    ..they need to make something that imports the current format in a WYSIWYG fashion, renders and exports it properly. Dealing with the table structure there is a nightmare for low-intermediate experience editors.
  • by Anonymous Coward on Saturday November 17, 2012 @03:36PM (#42013813)

    It should place structure above formatting.

    i.e., sectioning and lists rather than screwing around with fonts, colours and line spacing.

    LaTeX gets this right. a UI where users have to specify sectioning and such would be good.

  • LyX (Score:5, Insightful)

    by Anonymous Coward on Saturday November 17, 2012 @03:44PM (#42013871)

    Recreate LyX, or clean up LyX specifically for wiki editing and make it HTML 5. What You See Is What You Mean is what wiki writing needs.

  • by Anonymous Coward on Saturday November 17, 2012 @03:53PM (#42013937)

    ..they need to make something that imports the current format in a WYSIWYG fashion, renders and exports it properly. Dealing with the table structure there is a nightmare for low-intermediate experience editors.

    Christ, no. They need to start over with something done right from the start. Trying to make anything out of the existing mess is doomed to failure.

  • by Anonymous Coward on Saturday November 17, 2012 @04:04PM (#42014011)

    And so is MediaWiki syntax.

    The whole damn point of HTML is "what you see is what you *mean*. If you write hypertext, and think about looks, you already fail, and have to change your thought patterns.
    There is a very specific reason HTML is not about looks. Unfortunately apparently its usefulness and elegance is only obvious to programmers. But then again, only programmers have the competence to decide it, so all is fine. Until the idiots come, and listen to the even more uninformed idiots, and fuck everything up. (Examples: Clippy, Windows 8, iOS/Google autocorrect, Ubuntu Unity, Gnome 3, KDE Plasmids, and even ShowView [if you remember that one].)

    And MediaWiki is one of the well-known textbook examples of the inner-platform effect anti-pattern [wikipedia.org]. (TypoScript is another big one.)
    It tries to imitate the feature set of HTML, but dumbs it down under a false pretense, and ends up with a just as (or in many cases even more) complicated yet very limited system, that is vastly inferior to the original. It would have made more sense to just use HTML in the first place, and be done with it.

    There is no saving the whole thing. The foundation is rotten to the core. The philosophy is deeply, utterly wrong. Nuke it from orbit, and replace it by a nice XHTML subset and a WYSIWYM(ean) model. Done. End of story. End of problems.

    Also, if we see Ethiopian kids that never saw a computer before and could not read or write being able to use Android tablets to go to the web, play games and even modify ("hack") it after a few weeks, then nobody can tell me that learning something as ridiculously simple as HTML would be "hard". There is no excuse. If you are a human, and have no extreme mental disability, you can learn HTML! In a DAY.

  • by Animats ( 122034 ) on Saturday November 17, 2012 @04:06PM (#42014031) Homepage

    Wikipedia editing is not about formatting. It's not about font or size. The markup language includes links and many macros with specific parameters. Those are where users require assistance. {{cite book}}, for example, requires many parameters which could be filled in automatically, such as author, title, ISBN, publisher, and date of publication.

    Wikipedia's big structure problem, though, is that it is a wiki only. Some kinds of information belong in a different kind of structure. Items like "State Route 92" belong in a spatial database tied to maps. Music and bands belong in databases where songs and performers are automatically indexed. Wikipedia is full of manually maintained popular culture related list items which should be generated with a SELECT statement.

  • by afgam28 ( 48611 ) on Saturday November 17, 2012 @04:14PM (#42014079)

    And that's why MediaWiki is so great. It's not just a Word clone with a strict subset of Word's features; the two applications have feature sets that overlap but neither can do everything that the other can. What's important is that MediaWiki is significantly better than Word at collaborative document editing.

    In many teams at many companies, including the last two that I've worked at, internal wikis have replaced Word as the standard way of sharing documents. It's just so much easier than creating a Word doc, putting it up on some network share and then hoping that no one moves (or worse, copies!) the document. Everyone, regardless of whether they're using Windows, Mac OS X, Linux or their smartphone, can access it, because it's all based on open standards. People still use Word, but it's no longer as absolutely vital as it once was.

    MediaWiki needs to play to its strengths. The question isn't so much "what do other word processors do wrong?", but rather "what do other wikis do wrong?" My answer to that would be the simplistic page locking system that can't do a simple three-way merge. Ideally, a Google-Docs-style real-time collaborative editing feature would be in place.

  • by dotHectate ( 975458 ) on Saturday November 17, 2012 @05:01PM (#42014431) Journal
    I have to agree with Frosty here. The page that is linked in the summary clearly identifies the problem in the section entitled Rationale; "The decline in new contributor growth is the single most serious challenge facing the Wikimedia movement in the year 2011." Unfortunately they come to the wrong conclusion as to how to address the issue with the very next sentence; "Removing the avoidable technical impediments associated with Wikimedia's editing interface is a necessary pre-condition for increasing the number of Wikimedia contributors."
    Quite frankly, it's obvious that the "technical impediments" of the editing interface are not to blame or else there would not currently be 4,099,684 pages of content (which excludes an additional 24,635,011 "other" pages - source: http://en.wikipedia.org/wiki/Special:Statistics [wikipedia.org] ) as I type this. No, as Frosty P. states the problem is with the drama that comes with attempting to edit or create articles on Wikipedia. Rampant deletionism (which wasn't a thing before Wikipedia, hah!) abounds and new users are driven away in frustration. In short, they need to work on getting their current volunteers to operate in a more welcoming manner.
    No doubt a majority of the problem is caused by a minority of the editors, but like everything else the vocal minority will out-influence a silent majority. This is the problem.
  • by Anonymous Coward on Saturday November 17, 2012 @05:04PM (#42014455)

    Actually, for some of us who think differently, but have education in subjects not related to whatever the heck it is the rude editors on wikipeda have an education is, a visual editor would be helpful. I suspect I would consider you a moron in my particular field, and have a lot more to contribute to it (a subset of medicine) than you could ever dream of even understanding.

    Attitudes like yours, however, are a bigger problem than the ridiculous editor they currently have.

  • Why Bother? (Score:5, Insightful)

    by Kagato ( 116051 ) on Saturday November 17, 2012 @06:39PM (#42015173)

    Why bother making a fancy editor when the bigger problem is the cliques of editors driving away new volunteers?

Prototype designs always work. -- Don Vonada

Working...
https://ask.slashdot.org/story/12/11/17/1923238/how-can-wikipedias-visual-editor-top-other-word-processors/insightful-comments
ask.slashdot.org
crawl=CC-MAIN-2017-13
115545
application/http; msgtype=response
sha1:SVT3W4QM6GQCQB3H6NMIYV3DT7EAUI4L
<urn:uuid:93aa2759-c766-41cc-a467-885912a575fd>
2017-03-30T00:43:01Z
216.34.181.48
sha1:F76NG6CRIRVVNT3XPQMX6XK6XS6I37BM
<urn:uuid:84ba2874-971a-4ee9-8b72-9ebf0d16e0b8>
https://ask.slashdot.org/story/12/11/17/1923238/how-can-wikipedias-visual-editor-top-other-word-processors/insightful-comments
response
<urn:uuid:f5163533-369d-4180-a159-a9de54cada64>
robots: classic
hostname: ip-10-233-31-227.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2017-13
operator: CommonCrawl Admin
description: Wide crawl of the web for March 2017
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf