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?"
Styles (Score:2, Insightful)
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.
Re: (Score:3)
I deal with a lot of documents from professional writers, professors, CEOs; educated, sm
Re: (Score:3)
One of the core concepts of wikitext is that stylistic things are handled by the wiki engine. This assures consistency over, say, the million pages of Wikipedia. It also makes it possible to serve out "pages" to special purpose browsers, like audio output, braille printers, cell phones, etc.
The wikitext needs to be limited to semantic mark-up. "This is a headline. This is a paragraph. This is an emphasized phrase in the paragraph. This is table." That kind of thing. Let the wiki engine decide how these sho
Check out Confluence (Score:2, Interesting)
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.
Specifically for Wikipedia.. (Score:3, Insightful)
Re: (Score:2, Insightful)
..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.
Re: (Score:2)
Yikes I thought they were starting over, they're seriously going to try and put another layer on top of that?
Re: (Score:3)
There's several billion words of legacy content generated over ten years. Starting over was considered, but it's not a happener.
document structure, not just dumb formatting. (Score:5, Insightful)
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.
Re: (Score:2)
Well that's a given for Wikipedia since the style is fixed across the whole site.
Re: (Score:3)
yes, plus cross-document paragraph or phrase-level version tracking.
LyX (Score:5, Insightful)
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.
Re: (Score:3)
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.
this, mod parent up.
Re: (Score:2)
Better make it for a real language than for mediawiki which is just a bunch of hacks without specification though
VisualEditor? (Score:5, Funny)
Megabyte units? (Score:2)
For wikipedia (Score:2, Funny)
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.
CKEditor (Score:3)
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.
Re: (Score:2)
not if you are under 13.
Please can we have wysiwyg AND "Reveal Codes" (I am talking to you LibreOffice! )
Re: (Score:2)
Please can we have wysiwyg AND "Reveal Codes" (I am talking to you LibreOffice! )
Oh how I miss WordPerfect for Linux. Best Linux-native word processor ever, no competition. Alas, WP apparently couldn't figure out how to make money on it, and discontinued it. If instead they had open sourced it, it would today likely be the unquestioned leader on the Linux desktop. WP (are they still even in business?) could no doubt run a profitable business providing support to corporate users. Alas...
Re:CKEditor (Score:4, Interesting)
CKEditor is an HTML editor. Wikitext is not HTML. Wikia (my employer) does use a heavily modified CKEditor to round trip wikitext->html->wikitext but it's fragile and the experience lacks polish. The foundation decided to start over from scratch with a new design using an intermediate data representation coupled with a new parser and a simple extensible UI. I think they're going in the right direction, it's just going to take a while.
Poor mediawiki syntax (Score:2)
Just throwing this out there -- two of the major hurdles to doing this right are (a) that Wikipedia's syntax is not formally defined, and (b) that its current implementation is (as defined by the output of the MediaWiki parser) is not a context free grammar. Which means that writing robust, fast parser for it is very hard.
WYSIWYG Least of the problems... (Score:2, Informative)
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...
Re: (Score:2)
Perhaps you "keep reading about these claims" because a significant number of people who have tried to contribute to Wiki and given up?
I'm not getting into a pissing contest with an Anonymous Coward. Perhaps *YOU* are part of the problem? After all, it's not surprising that the source of the problem does not understand the issue.
- Frosty P.
Re:WYSIWYG Least of the problems... (Score:5, Insightful)
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.
Re: (Score:2)
I've written a few articles lately and not run into any troubles. What kinds of articles are people writing? I could imagine if it's on pop culture or Israel-Palestine or something there might be more drama, but in mathematics and archaeology (my two main areas of interest), I haven't had any troubles yet. People seem mostly polite, one person thanked me for improving an article, and some people have improved what I've written.
Re: (Score:2)
I've written a few articles lately and not run into any troubles. What kinds of articles are people writing?
He is mostly railing against deletionists, so what you need to do is look at articles nomiated for deletion on any given day [wikipedia.org] and you'll get an idea. It's mostly stuff that's very obscure or out of place (in that it should probably be merged into a different article instead of having one all to itself). While I have some sympathy for anti-deletionists in that its not like Wikipedia is running out of storage space, mostly I find they are people who want to rule over their own little kingdom of obscure trivia
Re: (Score:2)
I work in software development and I do a lot of open-source coding. It's frequent for changes to be integrated because they do not meet the standards of quality, the maintainer doesn't understand the changes and doesn't want to burden the extra complexity if he sees no need for it, the formatting is not correct, the patch contains too much unrelated crap that should need to be reviewed seperately and the maintainer doesn't want to spend time cleaning it, etc.
All of these are pretty normal, and I assume it'
Re: (Score:2)
You'll find plenty here:
http://www.deepcapture.com/tag/wikipedia/ [deepcapture.com]
Visual editors work poorly (Score:2)
Hell, there's your answer. Just get everybody to write in TeX.
Comment removed (Score:4, Interesting)
Re: (Score:2)
Looks like you're confusing TeX and LaTeX.
Only the latter claims to be semantic markup.
Re: (Score:2)
new, inexperienced editors can get started editing easily with the visual editor.
And make a big unstructured mess that no one else can make sense of, so they just delete it wholesale and start again.
There's nothing wrong with just editing plain text as it is. Paragraphs of text display as paragraphs of text. If you don't know how to use the formatting codes, don't try. The important thing is the text. If someone wants to pretty it up they can learn how to do it.
Re: (Score:2)
They can just as easily mess up the article with the regular editor. At least they can make sense of what is going on with the visual editor.
No, they won't make sense of it. They'll just keep clicking random buttons till they think it looks nice, or they get bored, and won't know or care how it appears to anyone else, who isn't using exactly the same screen and browser they are.
Anyone who is too dumb to work out how to edit Wikipedia is too dumb to do it at all. Thank God for rollback.
Too many options! (Score:2)
Problem with modern user interfaces is that they usually have waay too many buttons/options!
Every user interface is actually two user interfaces, one in the mind, and one on the screen. Every image on the screen first goes trough the "filter" in your brain, and this filter is different for everyone. But if you make a large part of the user interface a part of the "filter" in your mind, you also gain a better understanding of what you're doing. Would you think it would be better if while programming you had
Re: (Score:3)
Nonsense. You can never have enough options [typepad.com].
Editor vs WYSIWYG (Score:2)
WYSIWYG is misunderstood and over hyped. It is only practical for editing presentation but for actual EDITING it is like forcing somebody who can run to use crutches!
Wikipedia in recent times is largely edited by frequent users and not newbs. They would be best served if they catered to their primary demographic's needs for a productive EDITOR and then maybe put a little effort onto a WYSIWYG version for newbs later (they could encourage userscripts.org to get involved in developing newb editors.) They ca
Re: (Score:2)
Sure, but you don't have to incorporate every feature if you're targeting the novice like Wikipedia team is.
Re: (Score:2)
Word is so complex, most users don't even touch most of its features. And making the UI customizable, as a way of dealing with complexity, does not improve matters - it just confuses users even more. That said, it could be (and has been) worse: if you used it in the 80s, when it was a poor competitor to WordPerfect, you are glad you don't have *that* to deal with anymore.
WYSIWYG is already a failure by definition. (Score:5, Insightful)
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.
Re: (Score:2)
mod parent up, for truth.
Re:WYSIWYG is already a failure by definition. (Score:5, Interesting)
First, I just want to say that I agree with you. However, it's a bit arrogant to insist that people do everything your way, instead of giving them the ability to do things the way they prefer. If people want to contribute to Wikipedia using a WYSIWYG editor, then Wikipedia should provide such a feature, even if it runs counter to everything that the web stands for. Getting people to contribute and lowering the barrier to entry is more important than ideological purity.
Ideological purity for its own sake leads to the Reign of Terror.
Re: (Score:2)
Unfortunately, you are falsely assuming that "people" want what they actually would want, if they weren't under the influence of false social conditioning, delusions and willful ignorance.
This is a very arrogant, patriarchal view. Even when you're right and people switch over, they will still resent your attitude. I find such ideologically-driven software to be very annoying, personally. I feel like I'm being forced to join some kind of cult whenever I use certain programs, because you have to agree with the underlying ideology of the programmer/designer in order to get anything done. Firefox seems to be going in this direction, unfortunately. Mozilla has developed a messiah complex, wh
It's not about formatting. (Score:4, Insightful)
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.
Re: (Score:2, Informative)
Wikipedia shares your concerns about structured data being indexed in a completely unstructured manner, and they have launched the WikiData (http://meta.wikimedia.org/wiki/Wikidata) project to correct this. In the foreseeable future, your vision of creating lists and infoboxes through a SELECT-like statement will be realized.
Semantic Wikis have also tried to address this problem (http://semantic-mediawiki.org/) but they have suffered from too-tight coupling between pages and the data lying on them.
BAD idea. (Score:2)
Or at least so I think. Let Wikipedia BE not that easy to edit: someone that wants to edit will have to go through this small extra step.
Those syntax walls are there to keep the ill-determined from jumping right in.
Re: (Score:2)
...and keep the elitist in control, otherwise they would no longer have that one and onlything they dont suck at, and might go do something rash.
Re: (Score:2)
If the ability to use the Mediawiki syntax is the bar for being "elite", you may want to think about raising it a bit.
Maybe we should figure out a way for illiterate people to edit Wikipedia too.
Re: (Score:2)
no, I just think learning a specific syntax for something as simple as a fucking page of text and a picture or two is retarded
Re: (Score:2)
Or at least so I think. Let Wikipedia BE not that easy to edit: someone that wants to edit will have to go through this small extra step.
And the step really is small. My experience is, people whine about not being able to write Mediawiki syntax up until the point they actually *try*. Then it turns out they can use it after all.
It cannot, and should not. (Score:2)
It's better for Wikipedia to remain tool agnostic and support any editor the users wish to use.
Style vs Content (Score:2)
The editor should provide facilities for content markup. Wikipedia should have a stylesheet that applies the proper style to each content class. The biggest headache I've ever encountered in collaborative authoring environments is where one primadonna insists that something absolutely has to be done with his favorite font/color/whatever.
Where it is justified to format some content in a specific way, a process needs to be adopted to submit that requirement as a change request to the 'owners' of the style gu
Drag and drop file/image uploads (Score:2)
Re: (Score:2)
If we can't have drag and drop uploads, a least an easier way to upload and place images into a page.
No. Because there is a necessary rigmarole to verifying the copyright status of any image you want to use on Wikipedia.
Don't lower the bar. (Score:2)
I'd welcome Wikidot-like syntax (Score:2)
Citations, references, templates (Score:2)
All these need to be much easier to use than they presently are. Perhaps have a dialog for the different type of templates used.
A couple of things (Score:2)
A visual editor is essentially a very program with many, many features. No one does the interface particularly well, so consider making an interface that is based on information complexity and brain theory rather than the current model.
The current model has features stuffed into every corner - the edges and corners of everything sprout features, a zillion toolbars stuffed with icons, tooltips are everywhere. It's gotten so complicated that I don't think anyone bothers with customization any more.
Do some dat
I (Not Heart) Hyperlinks! (Score:4, Interesting)
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.
Re: (Score:2)
At least in Word there's an option after you paste to remove the extra formatting. It shows up as a dropdown at the end of your pasted text.
Re: (Score:2)
At least in Word there's an option after you paste to remove the extra formatting. It shows up as a dropdown at the end of your pasted text.
Control-space to remove formatting.
Ctrl+Shift+F9 to remove fields, including hyperlinks.
Ctrl-Q to remove paragraph formatting
I spend more time undoing Word formatting that I never wanted to begin with than actually applying formatting.
Re: (Score:3)
1. It's an auto-correct problem. Turn it off in the options.
2. It's a style problem. Set the "Hyperlink" style to auto-colour and remove the underline. Save this in "normal.doc" or a new template.
76. Write a small macro. Assign it to a shortcut or button. Something like:
Selection.PasteAndFormat (wdFormatPlainText)
49. Most users don't understand why you shouldn't go over the lines when colouring in; I mean, don't paste images in the margins. They think they're writing webpages - let them. It keep
Re: (Score:2)
There's a configuration option for that. I don't have Word on this computer but I recall it being reasonably obvious.
Re: (Score:2)
Wow - that's super intuitive! Why the fuck does it matter if a printed URL is blue and underlined or black and unstyled?
Because professional design matters, and non-functioning formatting doesn't fucking enhance anything.
Rationale (Score:4, Interesting)
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.
Missing: Intelligent placement of figures, etc. (Score:2)
What did my word processor get wrong? I have tried and/or used virtually every word processor currently available for the Macintosh and except for LyX, they all lack the ability to intelligently place stand-alone objects such as graphics, figures, tables, sidebars, etc. Except for LyX, they _all_ treat these objects as giant characters. (Please don't tell me about anchor points etc.—they don't solve the problem.) This was astonishing to me when I discovered this about a year ago as I prepared to do a
Re: (Score:2)
I should have mentioned that the word processor that placed graphics intelligently was Fullwrite Professional.
Why Bother? (Score:5, Insightful)
Why bother making a fancy editor when the bigger problem is the cliques of editors driving away new volunteers?
Re: (Score:2)
Re: (Score:3)
I don't think this is true In any event
Denial does not solve problems.
Re: (Score:2)
Structured editing (Score:2)
typical slashdot arrogance (Score:2)
Re: (Score:2)
I can only agree. There are people claiming Latex is a good example. Or -2. Let's hope they were all being ironical. If not, we're in for another decade of UI set back.
Improve copy/paste (Score:2)
In office I dread every time I do copy/paste since I know it will inevitability do the wrong thing. Please always paste in context. Do not paste with formatting.
Some ideas (Score:2)
idea - suggestions for wikipedia new editor
Caveats:
- As I don't know the current UI for wikipedia editing well maybe it already has some of these things.
- A new UI probably is not in fact the main reason for dwindling contributors, as someone else pointed out. Just saying.
General UI
- Screens are big these days. Consider an interface that keeps everything on one screen.
- At least a rich text editor type thing with buttons for tags and popup input forms for entry of book info, etc.
Editing Together
- Allow simu
Tables, Copy & paste and Sort (Score:2)
Since Wikipedia is an encyclopedia it must handle large datasets in each article. Then the table is one of the most useful tools to give a comprehensive overview of any subject (chemistry, sports, social sciences etc.).
The tables should support copy&paste from other editors, web pages, whether (as Google Docs) only with ctrl-c/ctrl-v. If you can get a table structure in copy&paste working, excellent.
Of course the table should support all kinds of column sorting as is already done today, where _stabl
Wrong question (Score:2)
The correct question is: do you want a document editor or a page layout tool? WYSIWYG is strictly for the latter. If you want to write a document, worrying about layout and format is absolutely not what you should be doing. Finish writing, and then hand it off to a formatting/layout tool.
Re: (Score:2)
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 [wikipedia.org] 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
Re: (Score:3)
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 ma
Re: (Score:3)
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 semant
Re: (Score:2)
Re: (Score:2)
Just go to a binary blob you can only edit visually if you're going to insist on that kind of coding.
Re: (Score:2)
The difference is in semantics.
Re: (Score:2)
Leave the buttons, but make them change the entire style.
That'll learn 'em.
Re: (Score:2)
You are exactly right. They need to think in terms of markup and semantics, not visual layout features. Then you can *still* make those "semantic things" accessible via a nice GUI, while simply displaying them as they would be displayed with the theme the user has selected or that respective page is in. But the semantic structure absolutely has to come first, the layout should follow from there. Not because of ideals (though I wouldn't take accessibility lightly), but because that makes the dependency tree
Re:impossible mission (Score:4, Insightful)
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.
Re: (Score:2)
Wikis still suck at collaborative work.
The only good tool for collaborative work is a versioning system, preferably distributed. But most of the existing ones are designed for plain text in mind, not binaries or even computer-generated XML.
Re: (Score:2)
Wikis still suck at collaborative work. The only good tool for collaborative work is a versioning system, preferably distributed. But most of the existing ones are designed for plain text in mind, not binaries or even computer-generated XML.
Good luck replacing the Mediawiki-based collaboration at my two workplaces with a Git repository containing ... well, *what*, exactly? The computer-generated XML you mentioned?
A wiki does a more than decent job of encouraging N people to update a set of shared information, but that's far from everything it does. Linking and categorizing the information, formatting it, providing search capabilities and so on is just as important.
Re: (Score:2)
Plain text files with wikitext in ithem
Re: (Score:2)
well, *what*, exactly?
Plain text files with wikitext in them
OK, that *is* something I can actually understand. I've cursed the Mediawiki editor and version control stuff too, and longed for my trusty Emacs and Git (or CVS, even) setup.
There are several problems which need to be solved to accomplish that, though. Just to mention two that come to mind: you now need a local preview feature, for example. And you cannot expect every contributor to keep a local copy of e.g. Wikipedia-en so you need to partition it ...
Merging structured text. (Score:2)
The XML approach to text is to wrap stuff in brackets (such as start and end of paragraph). Large-scale brackets are tough on revision merging. The affordable algorithms don't guarantee that brackets remain matched, which can render XML hopelessly invalid. Using separators (like marks between paragraphs) makes it a lot easier to preserve the validity of structure.
Re: (Score:2)
Version control is line-based, and yet many people use it to manage C++ source successfully, despite C++ grammar being much more complicated than XML, rendering your argument moot.
Re: (Score:2)
'Version Control' has developers driving it. I think you will find that the expertise of the average developer outweighs that of the average wiki contributor.
Re: (Score:2)
Indeed. If the merge screws up the curly brackets, a developer can usually fix it up -- because the developer works at the level of abstraction where curly brackets are routinely handled. Not so the average word-processor user, whose word-processor is likely to barf on the input, rendering it useless.
The crucial thing is not that the merge be correct, but that it permit further work, to fix it if necessary.
Re: (Score:2)
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,
My company too. We have half a dozen different proprietary collaboration/knowledge database tools, but our plain Mediawiki beats them all. Easily.
But you miss the point of a workplace wiki somewhat -- it's not just to have a mixed bag of documents, but also to have the relationships between different pieces of information, and between people, and yourself. You get to reflect on the information and discuss it with your peers.
because it's all based on open standards.
Not really. Mediawiki is free software, but not an open standard.
Re: (Score:2)
It'd be good to add something to Wikipedia to let people create bullet points and add references etc without using the code, but I'm sure they won't try and make
Re: (Score:3)
I've always found it funny that any supposedly modern system of organization can't even handle spaces in names.
Re: (Score:3)
I know. Just replace the dam underscore (_) with spaces (' ') and vice versa.
Or the stupid WikiCamelCase
Re: (Score:3, Insightful)
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.