Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

timothy posted about 2 years ago | from the want-edit-mode-by-default dept.

Software 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?"

cancel ×

196 comments

Sorry! There are no comments related to the filter you selected.

Styles (2, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:Styles (1)

crutchy (1949900) | about 2 years ago | (#42014745)

NO FUCKING RIBBONS.

Check out Confluence (2, Interesting)

Anonymous Coward | about 2 years ago | (#42013781)

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.

No manual formatting (1, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:No manual formatting (2)

davidwr (791652) | about 2 years ago | (#42014025)

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

Re:No manual formatting (2)

DragonWriter (970822) | about 2 years ago | (#42014105)

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.

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.

It could make it better, actually (1)

davidwr (791652) | about 2 years ago | (#42014397)

I haven't played with the particular editor that's being rolled out, but in principle, a visual editor could have buttons for things like "species," "Court case," etc. that translated into either a template that rendered the word or phrase in italics or, if no template were available, something like this:

<!--WikiVisualEditor;type=species;MOSSTYLE=italic;MOSASOFDATE=2012-11-17;timestamp=20121117184703-->''Homo sapiens slashdottus''<!--WikiVisualEditor;type=species-end;timestamp=20121117184703-->

Whether stored in the page as above, as just ''Homo sapiens slashdottus'', or as {{speciesname|Homo sapiens slashdottus}}, it would render on the screen as Homo sapiens slashdottus.

Over time, all uses of italics, bold, etc. could be easily templated.

Except for existing code stored as plain old italics, the visual editor would render such things as italic but with some kind of clue, perhaps a tinted background, that more information was available with a mouse-over or other action and that this wasn't "plain old italic" formatting.

Likewise, signed-in editors could use widgets that recognized these templates and WikiVisualEditor-specific HTML comments and added the color-coded background and mouse-over effects on pages as they were viewing them if they wanted to.

All of this could be done without breaking the wiki, requiring that the Manual of Style be changed, or breaking the ability to edit using a text-only editor.

Re:It could make it better, actually (2)

Samantha Wright (1324923) | about 2 years ago | (#42014627)

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.

Re:It could make it better, actually (1)

davidwr (791652) | about 2 years ago | (#42015245)

In general, Wikis do not use HTML classes in the markup, at least not directly. They use templates to accomplish the same purpose.

Perhaps some style templates like:

{{em|text}} for emphasis where the exact rendering of the emphasis is not important, as long as it's consistent wiki-wide. For now, this would reduce to <em>text</em> but this could be changed later.

{{fmt-latin|text}} for things like species names that are in italics only because they are in Latin. For now, this and other italics-templates would reduce to ''text''.

{{fmt-citation|Supreme Court Case or book title}} for things that are in italics because of citation-related conventions,

Other {{fmt-...|text}} subject-specific italics-emphasis indicators

''text'' for other italicized text

{{fmt-...|text}} subject-specific bold-emphasis indicators. These would reduce to '''text''' for now.

'''text''' for other bold text.

etc. would provide a manageable number of buttons for a pseudo-WYSIWYG editor to insert around text that needed such emphasis.

In any case, if a project-supported editor would take advantage of specific italic- or bold-formatting templates to make editing easier and preserve or improve document structure, then I'm all but certain such templates would garner more support than opposition.

By the way, one good reason to use templates to separate out things like book titles from things like species names is that future wiki-widgets (user-customizable "plug-ins") can spot them and treat them differently. For example, a lawyer doing research work may want a widget that highlights any use of {{fmt-citation}}, while a biologist may want to highlight {{fmt-latin}} to make it easier to spot species names.

Trivia: Until earlier this year Wikipedia had {{bold}} and {{italic}} templates. See their Template for discussion entries of April 13, 2012. As you can see from the discussion, these templates weren't "simple" italics and bold, they were written for specific cases. [wikipedia.org]

Re:No manual formatting (1)

loufoque (1400831) | about 2 years ago | (#42014867)

The difference is in semantics.

Re:No manual formatting (1)

MightyYar (622222) | about 2 years ago | (#42014153)

Leave the buttons, but make them change the entire style.

That'll learn 'em.

Re:No manual formatting (1)

Johann Lau (1040920) | about 2 years ago | (#42014301)

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 real simple if you will. The semantic structure is the one piece that has to be thought out real well; but then you can have as many ways to input and output that as you want, and keep experimenting with them to boot. I know it's easy to say... but a huge, and moving target in practice. Still :)

impossible mission (1)

Anonymous Coward | about 2 years ago | (#42013787)

The problem with visual editors is... well.

If you look at ms word clones, they always fight an uphill battle: what's the minimum subset of features needed?

Answer depends on who you ask, and if the sampling group is big enough, the minimum subset becomes "everything".

Re:impossible mission (3, Insightful)

afgam28 (48611) | about 2 years ago | (#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.

Re:impossible mission (1)

loufoque (1400831) | about 2 years ago | (#42014899)

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:impossible mission (1)

jgrahn (181062) | about 2 years ago | (#42015237)

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:impossible mission (1)

loufoque (1400831) | about 2 years ago | (#42015273)

well, *what*, exactly?

Plain text files with wikitext in ithem

Re:impossible mission (0)

Anonymous Coward | about 2 years ago | (#42014091)

If you look at ms word clones, they always fight an uphill battle: what's the minimum subset of features needed?

At a bare-bones minimum:
Import data from a file, keyboard, or another source into a document and/or begin editing a "new" document.
Allow changes to the document.
Export a rendering of the document to a file, screen, printer, and/or another source. /s/ Mr. Smarty Pants

Re:impossible mission (1)

kestasjk (933987) | about 2 years ago | (#42014553)

Last week someone came to me and requested that the DotNetNuke wiki we added for them be able to copy and paste full Word documents (including images) straight into the WYSIWYG editor. We got them to compromise on having to upload images manually, though able to copy and paste from Word, but now the formatting for their pages now looks terrible.

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 a real "Word-processor" like editor.

Specifically for Wikipedia.. (3, Insightful)

caferace (442) | about 2 years ago | (#42013805)

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

Re:Specifically for Wikipedia.. (2, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:Specifically for Wikipedia.. (1)

Intrepid imaginaut (1970940) | about 2 years ago | (#42014149)

Yikes I thought they were starting over, they're seriously going to try and put another layer on top of that?

document structure, not just dumb formatting. (5, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:document structure, not just dumb formatting. (1)

AmiMoJo (196126) | about 2 years ago | (#42014617)

Well that's a given for Wikipedia since the style is fixed across the whole site.

Re:document structure, not just dumb formatting. (0)

Anonymous Coward | about 2 years ago | (#42014691)

I'm pretty sure he means:
Text != formatting

It's the syntax stupid (0)

Anonymous Coward | about 2 years ago | (#42013857)

Good luck to Wikipedia making a WYSIWYG editor for an unparsable, moronic syntax.

Just take a look at the MediaWiki parser (and the 'graveyard' folder of broken parsers). I hope whoever coded that horrid shit stain is never somebody on my production team.

It is nothing short of a disservice to the very values it seeks to embody.

Re:It's the syntax stupid (1, Troll)

cheesybagel (670288) | about 2 years ago | (#42013969)

IMO a visual editor is a mistake. There are enough morons on Wikipedia as it is. If they lower the barrier for entry further who knows what drivel will show up...

Re:It's the syntax stupid (3, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:It's the syntax stupid (2)

93 Escort Wagon (326346) | about 2 years ago | (#42015285)

I've always found it funny that any supposedly modern system of organization can't even handle spaces in names.

No. (0)

Anonymous Coward | about 2 years ago | (#42013865)

It can not.

LyX (5, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:LyX (2)

Monkey-Man2000 (603495) | about 2 years ago | (#42014339)

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:LyX (1)

loufoque (1400831) | about 2 years ago | (#42014919)

Better make it for a real language than for mediawiki which is just a bunch of hacks without specification though

(lyx) WYSIWYM (0)

Anonymous Coward | about 2 years ago | (#42015107)

WYSIWYM instead of WYSIWYG :-)

wrong (1)

Anonymous Coward | about 2 years ago | (#42013887)

The ribbon bar in office. So much for file, edit, view.

VisualEditor? (5, Funny)

Culture20 (968837) | about 2 years ago | (#42013889)

That's the long name for vi. Why don't they consider emacs?

Re:VisualEditor? (0)

Anonymous Coward | about 2 years ago | (#42013919)

All the mac text editors have emacs bindings

Re:VisualEditor? (1)

Anonymous Coward | about 2 years ago | (#42014037)

Well, Emacs is a nice operating system, yes. But its editor is a bit shitty. ;)

Also, Emacs inside of e.g. Firefox... Sup dawg, I herd yo like virtual platforms... so we put Emacs inside Firefox inside yo OS on yo computer. So yo can run an OS, while runnin' an OS, while runnin' an OS!

Also: We need to go deeper: http://jslinux.org/ [jslinux.org]

Re:VisualEditor? (1)

partyguerrilla (1597357) | about 2 years ago | (#42014573)

'sup dawg, we heard you like dependencies...

Re:VisualEditor? (0)

Anonymous Coward | about 2 years ago | (#42014585)

Eight megabytes and constantly swapping - that is why. Emacs can really bring servers to a hold when opening a lot of files or large files. I have seen it bring down 12-core, 24 GB machines, so not really optimal for having a lot of people do editing.

Megabyte units? (1)

symbolset (646467) | about 2 years ago | (#42015187)

A megabyte is what, like a milligig, right?

For wikipedia (2, Funny)

Anonymous Coward | about 2 years ago | (#42013893)

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.

Why can't they just accept Libre Office docs? (0)

Anonymous Coward | about 2 years ago | (#42013901)

Publish a template, style guide, and move along.

CKEditor (2)

Intrepid imaginaut (1970940) | about 2 years ago | (#42013907)

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:CKEditor (1)

Anne Thwacks (531696) | about 2 years ago | (#42014003)

The multicoloured text is really hard to read.

not if you are under 13.

Please can we have wysiwyg AND "Reveal Codes" (I am talking to you LibreOffice! )

Re:CKEditor (4, Interesting)

Owyn (934) | about 2 years ago | (#42014131)

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.

The Wheel? (1)

s1d3track3D (1504503) | about 2 years ago | (#42013925)

What am I missing? what's wrong with TInyMCE or CKEditor?

Re:The Wheel? (0)

Anonymous Coward | about 2 years ago | (#42014053)

Have you tried using those with wikisyntax? ;-) Try them out, and see in how many wonderful ways they &*@^#&@^#&@#^ your text

Poor mediawiki syntax (1)

Raul654 (453029) | about 2 years ago | (#42013931)

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.

Re:Poor mediawiki syntax (1)

Anonymous Coward | about 2 years ago | (#42013985)

So switch to using proper HTML instead of... Whatever that abomination they use at present is called.

5 words (-1)

Anonymous Coward | about 2 years ago | (#42013939)

crowd sourced auto spelling correction

speaking as a person with dyslexia, i've wanted something like this all my life and no of the tech giants ever seemed to catch on.

all the people out there that think this would be bad for language as a whole or make people "lazy" can go suck a lemon

WYSIWYG Least of the problems... (2, Informative)

Frosty Piss (770223) | about 2 years ago | (#42013949)

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:WYSIWYG Least of the problems... (0)

Anonymous Coward | about 2 years ago | (#42014145)

I keep reading these claims, but I've never seen an example myself.
Can you name an article that has had this problem?

Re:WYSIWYG Least of the problems... (1)

Frosty Piss (770223) | about 2 years ago | (#42014247)

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... (4, Insightful)

dotHectate (975458) | about 2 years ago | (#42014431)

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.

Re:WYSIWYG Least of the problems... (1)

Trepidity (597) | about 2 years ago | (#42015153)

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:WYSIWYG Least of the problems... (1)

loufoque (1400831) | about 2 years ago | (#42015001)

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's the same for wikipedia articles. If you want to make changes, you'll have to work on getting them integrated, which can be as much if not more work than the change itself.

Wrong question to ask (1)

davidwr (791652) | about 2 years ago | (#42013955)

The right question is:

Does your word processor do the job it claims to do well, and what, if any, of its failings are relevant to a Wikipedia-specific word processor.

I agree with previous commenters: A page-editor for a wiki page needs to be about structure, not WYSIWYG. Now, it's convenient if what you see as you are editing is approximately what you will get when using your computer and your web browser, but there should be no illusion that everyone else will see the same thing, or even anything close to it.

In any case, it's critical that editors be able to tell in real time the difference between a structural element, such as a section heading or the start or end of a template, and pure formatting, such as a change in font.

Visual editors work poorly (1)

EvolutionInAction (2623513) | about 2 years ago | (#42013981)

They should avoid going WYSIWYG, because WYSIWYG never works correctly. There's a reason TeX is so popular.
Hell, there's your answer. Just get everybody to write in TeX.

Re:Visual editors work poorly (3, Interesting)

CRCulver (715279) | about 2 years ago | (#42014023)

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.

Re:Visual editors work poorly (1)

loufoque (1400831) | about 2 years ago | (#42015013)

Looks like you're confusing TeX and LaTeX.
Only the latter claims to be semantic markup.

Re:Visual editors work poorly (1)

cgt (1976654) | about 2 years ago | (#42014089)

I don't care for visual editors either. However, the visual editor is not meant to replace the current raw editing of MediaWiki code, but rather to complement it. Experienced editors can edit raw MediaWiki code, while new, inexperienced editors can get started editing easily with the visual editor.

ditch the syntax (0)

Anonymous Coward | about 2 years ago | (#42013989)

it is a complete nightmare if you have any kind of accessibility issues. i never understood why they didn't just use HTML, or LaTex. Both better understood and with an already established community with good editors.

Too many options! (1)

Zandamesh (1689334) | about 2 years ago | (#42013997)

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 a button for "for loop" "while loop" "new method", a button for everything? Learning programmling like that would be very annoying.

It's a bit like the "command line" vs "user interface" debate. You trade a slightly higher learning curve for a better understanding and usage later on. If you're gonna build a WYSIWYG interface with all the capabilities of the normal interface, it'll probably end up more complicated than the normal interface.

Look, I'm not saying abstractions are bad, they're very important, but you have to put those abstractions in the mind of the user, not on a screen as buttons.

Re:Too many options! (0)

Anonymous Coward | about 2 years ago | (#42014051)

Have you ever used National Instruments Labview [ni.com] ?

It's exactly what you're describing, and it works great.

Editor vs WYSIWYG (1)

bussdriver (620565) | about 2 years ago | (#42014239)

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 can plug-in a newb editor later on, have a contest or something.

Keyboard shortcuts + "cheat sheet" its all javascript; program it open enough and people will write their own bindings.

Wikipedia thankfully lacks the formatting options of WYSIWYG editors and that keeps the site more like an encyclopedia. What could really be used is better quality table editors - I've not met a table editor I liked. If they want to innovate, create nice table and hierarchy content editors for structured text... it could lead to more interesting uses of the information beyond just sorting tables by row. One could specify related topics in a hierarchy - akin to breadcrumbs and that information could be interpreted differently than simply a list of links. Properly defined tables can be intelligently converted for better use/presentation. I don't think their markup goes much beyond presentation only so this would involve some changes. For example, typing in table information is easier done as an shallow outline then converting that into a table than it is to fuss with a table editor or even a spreadsheet (but it depends.) A newb would be confused how a table can go to and from an outline but newbs are slow anyhow and should stick to their mouse driven GUI table editor.

Re:Too many options! (1)

NotBorg (829820) | about 2 years ago | (#42014421)

If you're gonna build a WYSIWYG interface with all the capabilities of the normal interface, it'll probably end up more complicated than the normal interface.

Sure, but you don't have to incorporate every feature if you're targeting the novice like Wikipedia team is.

Citations (0)

Anonymous Coward | about 2 years ago | (#42014009)

I just tried out the beta editor. Pretty neat.

I think the project could make citations easy to do. There's tools to add content using the appropriate font size, etc. However, I don't see anything about citations that go at the bottom of the page.

A lot of programs make citations difficult (Word, LaTeX, etc). There are some tools to assist, like Zotero and Mendeley. Wikipedia could use some smart tool to help people create citations, etc.

Good luck!

WYSIWYG is already a failure by definition. (5, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:WYSIWYG is already a failure by definition. (1)

allo (1728082) | about 2 years ago | (#42014271)

mod parent up, for truth.

It's not about formatting. (3, Insightful)

Animats (122034) | about 2 years ago | (#42014031)

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.

BAD idea. (1)

arisvega (1414195) | about 2 years ago | (#42014047)

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:BAD idea. (1)

Osgeld (1900440) | about 2 years ago | (#42014685)

...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:BAD idea. (1)

jgrahn (181062) | about 2 years ago | (#42015171)

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. (1)

Hatta (162192) | about 2 years ago | (#42014057)

It's better for Wikipedia to remain tool agnostic and support any editor the users wish to use.

Re:It cannot, and should not. (0)

Anonymous Coward | about 2 years ago | (#42014199)

Copy-paste the actual wikicode from any text editor will always remain an option.

Style vs Content (1)

PPH (736903) | about 2 years ago | (#42014067)

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 guide for adoption.

XML (0)

Anonymous Coward | about 2 years ago | (#42014071)

We should write everything in XML. You can select a formatting template for viewing and everyone will be happy! ,/sarcasm>

Drag and drop file/image uploads (1)

Jjeff1 (636051) | about 2 years ago | (#42014075)

If we can't have drag and drop uploads, a least an easier way to upload and place images into a page.

WYSIWYG is wrong (1)

Anonymous Coward | about 2 years ago | (#42014107)

When editing, you need to see more information than someone who is just reading the page. Specifically, you need to be able to distinguish between structure and formatting.

Another problem is the horrendous spaghetti code WYSIWYG tools tend to produce. Imagine Wikipedia source code looked like the HTML produced by Dreamweaver or Frontpage. The result is practically a lock-in, because the code comes out so bloated that you can't make sense it in a text editor. There's a reason nobody uses these anymore.

Don't lower the bar. (1)

TwineLogic (1679802) | about 2 years ago | (#42014185)

If the prospective editor can't use mark-up, what does that tell you about their overall intellectual ability? Keep Wikipedia great, full of high-quality articles by intellectuals -- disallow visual editing.

Re:Don't lower the bar. (1)

LQ (188043) | about 2 years ago | (#42014305)

If the prospective editor can't use mark-up, what does that tell you about their overall intellectual ability? Keep Wikipedia great, full of high-quality articles by intellectuals -- disallow visual editing.

And while we're at it, let's get rid of drive-by editors, introduce a pending queue for edits by new editors etc etc. Wikipedia is now to important to allow kiddies and spammers to, even temporarily, introduce mis-edits.

I'd welcome Wikidot-like syntax (1)

VAElynx (2001046) | about 2 years ago | (#42014187)

I'm an author at the SCP Foundation wiki, which uses it, and it's head and shoulders better than mediawiki syntax, at least in my opinion. The commands used are more obvious, such as **bold** //italics// instead of wikimedia's deluge of dashes that has to be supplemented by HTML anyways, modules work in much more obvious ways, and there's much less formatting that induces accidental screwups. WYSIWIG is not a good way to edit anything but plain text, either way.

Re:I'd welcome Wikidot-like syntax (0)

Anonymous Coward | about 2 years ago | (#42015249)

That's more due to the SCP Foundation wiki not trying to do more complex things. '''Bold''' and ''italic'' are fairly straightforward in media-wiki. Dashes are due to tables which the SCP wiki doesn't use much. Then there are templates which wikipedia uses to a much greater extent than just about anyone else.

Citations, references, templates (1)

eclectro (227083) | about 2 years ago | (#42014207)

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 (1)

Okian Warrior (537106) | about 2 years ago | (#42014237)

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 data mining on the editing process and count the types of changes people make. Take the logarithm of that number and put that many icons and shortcuts for the most used operations on the front page. Make everything else available, but hide it.

Rather than making a zillion incomprehensible icons and using tooltips to clarify, consider using icons of 2-letter abbreviations. Use English abbreviations - no one cares that music notation is in Italian, no one cares that medical notation is in Latin, and no one will care that the interface notation is in English (...but translate the popup messages and help files into native, of course). With 2-letter abbreviations (and throw in a few extra symbols) you can make icons that remind the user of the function. (For comparison, consider the 2-letter abbreviations in Perl: $! means "What went bang?", $= means "number of lines in file", &c.)

If Icons can have 2 letters and other symbols such as dingbats or greek letters, you can have a large number of mnemonic functions such as <scissors>-2 meaning "cut to the 2nd cut buffer".

If you make some good conceptual design decisions you can make the interface intuitive and eliminate lots and lots of widgetry. For example, instead of considering the document a page of text with inserts of other things (as does Microsoft Word and HTML), consider going to an object/position model.

Suppose the page starts blank and requires the user to place objects before anything else. A text box is an object, as is an image or video. Once the user can create and size text boxes (rubber banding), you no longer need a complex "column layout" panel with all sorts of widgets to define columns - just have the user place text boxes where needed, and note how the text should flow from one to the other. Add in some group/distribute/z-order functions to tidy things up (common across all objects) and all the layout becomes intuitive - no complex interface needed.

Instead of making the help files a search in the linear manual, make the help into a tree structure. Start with "is your question about text, images, or video", let the user select one of these, then ask more clarifying questions until you get to the topic the user wants to know about. With 3 options per node, the user can drill down into the subject matter very quickly. This is especially useful when the user doesn't know how to properly describe what they want to do, or when the subject is some jargon word the user doesn't know like "Kerning", "Alpha transparency", and so on.

Include a long list of "How do I..." answers, and have this list be searchable.

It's incredibly useful to be able to leverage functionality externally, so consider making your editor in two pieces - a functional engine and an interface/display engine. Make the connection between these two pieces a socket interface and publish the API - this way other people can invoke your engine using external programs, and make automated scripts &c.

Also, people can make alternate interfaces to play around with different display techniques.

too easy? (0)

Anonymous Coward | about 2 years ago | (#42014295)

While a GUI editor may not be an entirely bad idea, is there such a thing as making editing too easy? Perhaps having to learn the syntax is a good, modest "entrance test" in the abilities of the potential contributor?

The project has made it this far without a GUI, is there really a need to lower the "barrier to entry"?

I (Not Heart) Hyperlinks! (3, Interesting)

rueger (210566) | about 2 years ago | (#42014417)

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.

Re:I (Not Heart) Hyperlinks! (0)

Anonymous Coward | about 2 years ago | (#42014975)

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.

Surely this should be handled at the copy, not the paste. I know there's a Firefox extension called Copy As Plain Text. [mozilla.org] Is that what you're looking for?

TrimWord (-1)

Anonymous Coward | about 2 years ago | (#42014429)

If you want a good editor for win 8, A friend of mine developed http://apptivate.ms/apps/197/trimword
Its actually a great application

Rationale (3, Interesting)

tbird81 (946205) | about 2 years ago | (#42014621)

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.

Inclupedia. (0)

Anonymous Coward | about 2 years ago | (#42014875)

Agreed. Seen to many changes just reverted. You have no time to fight over reverts with people that have much more time and termonology to fight revert wars.

And to reflect the optiion that there is room enough for more info, the editor should include ALL options.

Every uses just 20 % of his favorite editor, the problem is that every one uses a different 20% , so you cannot leave the 80% of other options out.

Re:Rationale (0)

tepples (727027) | about 2 years ago | (#42015161)

The problem is that most of what you write will be deleted

True. Most of what people write lacks a citation to a reliable source.

any image you upload will be deleted

Are you referring to self-made images or to images of inherently non-free subjects such as contemporary media?

Missing: Intelligent placement of figures, etc. (1)

iliketrash (624051) | about 2 years ago | (#42015045)

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 major piece of technical writing. Not even the vaunted Microsoft Word can do this. My astonishment is due in part because from about 1988 to 1998 there was a word processor for the Mac that did this with aplomb.

Second on my "missing" list is built-in equation editor. Again, LyX handles equations natively, not as an afterthought or as a third-party kludge.

Re:Missing: Intelligent placement of figures, etc. (1)

iliketrash (624051) | about 2 years ago | (#42015065)

I should have mentioned that the word processor that placed graphics intelligently was Fullwrite Professional.

Don't! (1)

Anonymous Coward | about 2 years ago | (#42015079)

I have some content that is hard to understand. How can I make it easier for people who don't understand what they're doing to fuck with it?

Ob car analogy: My car engine has all these fiddly wires and bits. This is preventing people who are not mechanics from tinkering with it. How can I put larger handles on engine parts so that the average car driver can get them out?

Why Bother? (4, Insightful)

Kagato (116051) | about 2 years ago | (#42015173)

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

Structured editing (1)

frisket (149522) | about 2 years ago | (#42015179)

There have been many attempts to tackle this problem (not just with wiki markup) and most of them have foundered when the requirements of the document type went beyond the facilities that could conveniently be represented in a synchronous typographic interface (I have been gathering these for my thesis on structured editing). Let's hope this implementation is more successful, given that the wiki markup is relatively simple.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>