Slashdot Mirror
How Can Wikipedia's Visual Editor Top Other Word Processors?
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?"
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.
And don't do what they did. It's the most frustrating wiki editor on the planet.
Many wiki pages have large amounts of structured information, and the Confluence editor is spectacularly bad at managing that. It's the most aggravating thing to use.
And don't get rid of plain text markup for when the rich editor fails.
..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.
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.
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.
That's the long name for vi. Why don't they consider emacs?
It should have built in warnings so you know not to waste time on an article that belongs to one of the regulars. It might be possible to calculate this on the fly for each article by seeing how long an average edit lasts before being reverted by one of a small number of players.
Really, works fine for most websites. Add a few scripts for references and such, automate some of the layout and done.
Incidentally can we get a CSS switch that makes links the same colour as the rest of the text, user preferences kind of thing? The multicoloured text is really hard to read.
Their lack of coherent coding and / or a WYSIWYG editor is the LEAST of WikiMedia / WikiPedia's issues.
Number one issue keeping new blood away: Asshat editors-for-life with "ownership" issues, who park their fat asses on various pages / subjects / media classes, and shit diarrhea on any "newbe" who dares add / change / question so much as punctuation...
If you want news from today, you have to come back tomorrow.
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. (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.
TeX is an unsatisfactory half-measure between a visual formatting free-for-all and truly semantic markup. Even within the TeX community, it's now common to see publishers maintaining manuscripts in e.g. DocBook XML, only converting the data to TeX via XSLT when they want to produce final print output.
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.
Proper format use includes italics and the like in certain circumstances, and other formatting tools like <em> in others.
I don't see the end-result-difference between having a "bold" button, an "italic" button, and an "emphasize" button over the traditional way of using hand-typed wiki-markup to achieve the same results. I do agree that if the edited document is being displayed in a WYSIWYG or pseudo-WYSIWYG manner as it is being edited, there will need to be some special way to highlight text that is being emphasized to distinguish it from italic text. If it is being displayed as marked-up-plain-text then there is no problem, as the markup characters for emphasis are different than for italics.
In any case, the page will be saved in marked-up-plain-text form, so any future Wikipedia editor who chooses to use the classical text-markup editor won't know or care which editing tool the last editor used.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
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.
The problem isn't using buttons for physical styles vs. using tags for physical styles attached directly to content, its using physical styles directly attached to content rather than semantic "styles" (whether entered as semantic markup or "applied" with an editor that presents thing in a form other than markup) with separate specification of physical presentation. That Wikipedia's existing standards use physical styles for some uses and semantic markup for others is problematic, a visual editor is just going to make things worse.
Nonsense. You can never have enough options.
"I bless every day that I continue to live, for every day is pure profit."
My biggest complaint with most word processors is their default behaviour to change e-mail addresses and web addresses into blue, underlined hyperlinks.
I actually use word processors to create stuff that gets printed on paper. Hyperlinking, blueifying, and underlining words is useless to me, and wastes my time. I can think of no good reason why MS or anyone else should assume that every user of their word processor is creating web pages.
And while I'm at it, I can't think of a single time when I wanted the formatting from a web page to be carried into a printed document when I copied and pasted a block of text. Surely the sensible default should be to paste in plain text and pick up formatting from the destination document? At the very least this should be an optional default.
Three Squirrels
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.
From their site:
"The decline in new contributor growth is the single most serious challenge facing the Wikimedia movement in the year 2011. Removing the avoidable technical impediments associated with Wikimedia's editing interface is a necessary pre-condition for increasing the number of Wikimedia contributors."
I'm not sure that the editing is the main problem with dropping contributors. The problem is that most of what you write will be deleted, any image you upload will be deleted, and nearly edit you make will be undone.
My god those are hideous tag suggestions. Do you work for Microsoft? (Just kidding. But seriously, that looks dangerously like Office HTML.)
Anyway, we have these cool things called CSS classes. A simple <span class="wiki-species">Homo sapiens slashdottus</span> should do it. Maybe an HTML5 data-date parameter if you really want to go the extra mile.
But, anyway, this approach quickly runs into a branching factor issue. How do you present an interface that lets you pick between all possible semantic uses of a given typeface style? Species, court case, book/magazine/story/movie, poem, ship name, emphasis, foreign word, mathematical symbol, character's internal thought process, literal representation of a word, introduction of jargon... I'm probably missing a few thousand, although that's all Wikipedia lists.
This is more or less how we ended up with bold and italics in the first place, with bold replacing an earlier practice of small caps. HTML 2.0 had special tags for a variety of occasions, and a lot of them were deprecated and ignored in the HTML 4 era, and are replaced with makeshift classes in later usage. Even if you had a nice, clean, structured menu to select from, I expect that most contributors would just use the default "emphasis" style instead of finding the actual semantic tag they should be using.
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
Why bother making a fancy editor when the bigger problem is the cliques of editors driving away new volunteers?
I've always found it funny that any supposedly modern system of organization can't even handle spaces in names.
#DeleteChrome
I know. Just replace the dam underscore (_) with spaces (' ') and vice versa.
Or the stupid WikiCamelCase