Proposal talk:WYSIWYG default editor

Proposal discussion

If you like this idea please help me improve the proposal. -- Eb.eric 15:30, 13 August 2009 (UTC)

You might also check out Proposal:Wikimedia editor, which is another idea along these lines. Sounds like folks are interested in that! -- Philippe 15:34, 13 August 2009 (UTC)

• Personally, I hate WYSIWYG editors. I prefer to see and edit the source code, and I find that in other areas, such as HTML editing, it is far quicker and simpler to just type source, rather than having to constantly use toolbars, menus, etc to find the options in order to correctly format the text that I am editing. --GW… 16:02, 13 August 2009 (UTC)

I would also opt to edit the code. However, I propose a default WYSIWYG editor for the reasons listed. Primarily because I believe it would greatly increase the number of people who are able and willing to contribute. Do you agree? Eb.eric 16:12, 13 August 2009 (UTC)

ACCCHHHH - NO! Wikia tried this, users said it's a living hell to use. We don't want Wikipedia like that POS. (though I will admit, this is one better, but still horrid. --MisterLambda of Wikipedia's IP, 156.34.84.89 18:57, 13 August 2009 (UTC)

Dismissing the whole idea because of a bad implementation doesn't seem fair. Do you think a WYSIWYG editor could be implemented in a way that isn't a living hell to use? Eb.eric 20:10, 13 August 2009 (UTC)

Well it's true that WYSIWYG online editors can be quite slow and still be hard to use. However, I think we could make the WYSIWYG editor the default for anonymous users and the standard one the default for registered users, but on the other hand that would confuse users who just register (alternatively, we can make the choice of the editor an option that has to be checked on the inscription, so that no one would be surprised). Anyway, having started to contribute actively only a few days ago, I can tell that the syntax is quite counter-intuitive at times, and this can prevent some people who aren't as willing to learn it as I am from editing articles. Last thought: wouldn't a WYSIWYG editor be a problem for people with a slow computer/connexion or who use a text-only browser (like lynx)? AdrienE 22:57, 13 August 2009 (UTC)

That's a good point. The server knows which browser is accessing the site, and can change the output accordingly. So for a text-only browser the code editor could still be default. This probably represents an extremely small proportion of editors though. As for speed, it would have to be assessed how much slower a WYSIWYG editor would be. Even the code editor has a toolbar as it is, so it's possible the further reduction in speed wouldn't be too significant.

I think the best way to implement it would be to keep the code editor as default for all current users, but set the WYSIWYG as default for anon and new users. I think the button to switch back and forth should be quite prominent though, as I think all users can benefit from using both systems, depending on the kind of edit they are making. This is how it is in Blogger, if anyone is familiar with it. Eb.eric 01:03, 14 August 2009 (UTC)

Wikia started to test its WYSIWYG editor site-wide in August, and their was initially a lot of protest focused mainly on the bugs of the updated editor. However the number of reported problems has decreased a lot since September (cf: Wikia Forum New Visual Editor). I'm sure that the wikia technical team will have solved most of the problems in a few more months. Their implementation of a WYSIWYG editor would then be a good starting point for Wikimedia (since Wikia and Wikimedia web sites are technically very similar and use mostly the same markup language). -- Ryk V 16:36, 12 October 2009 (UTC)

I personally think that this is a brilliant idea, as I don't like the Wiki source and would find it easier. I reckon that there should be three tabs with 'Design', 'Source' and 'Preview'. --Billinghamj 21:36, 14 August 2009 (UTC)

I think a WYSIWYG web page editing software(like dreamweaver) can be adapted to edit the wiki. Easy to use OSS html editors like Nvu and KompoZer exist. But these projects have been lying idle for a while. I think wikipedia should revive those projects. Thus wikipedia will have a easy to use editor which can be used by newbies and power users alike. The community will also get a html editor which can rival dreamweaver. A win win situation for all. --Prakreet

It would already help new users if wikiEd would be standard. This one is already programmed and making it standard wouldnt cost a dime. --Hannes Röst 12:41, 22 August 2009 (UTC)

Yes, WYSIWIG editing should be default for new users; obviously old hands will want a preference setting to change default to edit syntax. w:Confluence (software) and other enterprise wikis approach this as a fundamental design feature for encouraging use and to get people editing. Jtneill 02:07, 27 September 2009 (UTC)

Usabilitiy initiative

Have you seen the usability initiative? Dedalus 13:47, 15 August 2009 (UTC)

yes, but the explicetly dont develop a WYSIWYG editor! --Hannes Röst 12:40, 22 August 2009 (UTC)

Why this hasn't been done yet?

The question I am asking is : Is the absence of a WYSIWYG editor on Wikimedia websites a consequence of technical problems / lack of resources, or is it a deliberate choice?

Wikipedia is by far the biggest and most read wiki on the web. Its Moto is "the free encyclopedia that anyone can edit" according to the w:Main_Page so one would think that it would be at the forefront of user-friendliness, yet if you look at the list of Wiki farms only one out of more than 30 wiki farms still follows wikipedia example of not offering a WYSIWYG editor.

These wiki farms are supported by ads or subscriptions, so it is possible that some of them have more financial resources than Wikimedia (especially Wikia), but some of the free ones (like MyFreeWiki) have such a low Alexa ranking, that it's hard to believe that they had huge financial resources, and yet they still managed to create a WYSIWYG editor.

It is possible that the complexity of the media wiki mark-up language used on Wikimedia websites makes it especially difficult to develop a functionning WYSIWYG editor for Wikimedia (as shown by the problems of the wikia editor). But the reason for the absence of WYSIWYG editor may be elsewhere:

Some bloggers have suggested that the absence of a WYSIWYG editor on Wikipedia is a way of limiting edits by non-registered users so as to keep Wikipedia from getting out control (cf: an article on calcanis and another on wired). The typical way in which articles are developed on wikipedia is : some anonymous contributor add some data to an article then registered users edit and format the new data , correct errors, add references, etc so that the overall quality of wikipedia's article remains good (cf Who Writes Wikipedia?). The theory is that if the number of edits by non-registered users increase too much (for example because of a WYSIWYG editor), the registered users won't be able to keep up and Wikipedia will spin out of control (with vandalism or inconsistent formating, lack of sources).

If this is (one of) the real reason(s) behind the absence of a WYSIWYG editor, I think it should be clearly discussed and explained. -- Ryk V 19:06, 12 October 2009 (UTC)

it's very simple: deployment of a WYSIWYG editor requires a _massive_ amount of javascript, and the sheer quantity of javascript involved not only results in a significant increase in wikipedia's network traffic as every user wishing to do edits goes and downloads it, hundreds of thousands of times, but also the execution of that javascript in browsers such as IE6 and Firefox 2, and the execution of that javascript on smaller embedded systems, results in an absolutely god-awful response time. FF2 on a 1.2ghz dual-core system with 2gb of RAM takes ONE MINUTE to load the strategy.wikimedia.org WYSIWYG editor, and i got so fed up with it, and the race condition event-driven bugs in it that i eventually switched it off.

take a look at fckeditor's source code. it's 25,000 lines of tangly nightmare specialist javascript. all of it is necessary. the _actual_ work is done by the web browser engine, simply by switching on "Design Mode" in the browser. however, the support infrastructure necessary to pull up dialog boxes (what to do when editing a table; what to do when editing a cell; what to do when inserting a hyperlink) is massive. and, if fckeditor itself isn't good enough, you need to go in to that god-awful code and convert it to support wiki formatting. it's a _lot_ of work.

so - basically, i'm writing this to advise you not to credit a conspiracy theory where in fact there is a simple explanation: a javascript WYSIWYG editor is a monstrous resource hog, and is deployed at wikipedia's risk. Lkcl 14:04, 13 October 2009 (UTC)

You seem to know more about javascript and the technical problems of WYSIWYG editors than I do. However, I also tried the wikimedia adaptation of the fckeditor here (click on the "rich editor" link) and it didn't feel slow : I have a 1.3 Mb/s downlaod speed according to the test I just took and my laptop is 3 years old so not really blazingly fast either, yet it took me exactly 7 seconds to load the editor and once loaded it worked just fine.

According to an article of the Usability survey (mentioned at the end of this proposal) the fckeditor is 399KB and the Wikia "rich editor" is 132KB (can be tested on most wikia wikis, here for example) so they are not that monstruous. The 2 were tested for their loading time and responsiveness and were found to be quite good (first load time is between a few to 10 seconds while subsequent loads are faster). I think the wikia editor was improved since they tested it because it felt faster than the fkceditor especially for dialog boxes.

You also mention the load it would put on Wikimedia server, but the size of these editors is small compared to some wikipedia article (this discussion page alone was 215KB before my edit), and the number of edit by unregistered users (the target of this editor) is negligible compared to the total pageviews of wikipedia anyway.

I don't think the older browsers such as IE6 and Firefox 2 are a problem either : if the WYSIWYG editor works on them then great, if it doesn't then they keep the old editor, they will disapear soon enough anyway.

As for the "conspiracy theory", of course the two articles I site are extreme but it was to launch a debate. My personal opinion is that the absence of a WYSIWYG editor on wikipedia is a consequence of its decision-making process : improvements are brought to wikipedia either because someone at Wikimedia (a developer or a board member) decides it would be a good idea or because consensus appears among wikipedia active editors. But the guys at wikipedia probably thought they had more urgent things to deal with (I understand that they already have enough work on their plate as it is) and there is no reason the community of wikipedia editors see a need for a WYSIWYG editor when they are already very comfortable with the current editor and it's mark-up language. That's why this Strategic Planning is such a great idea : it gives the opportunity to wikipedia editors (and new members like me) to seat back and ask ourselves what is better for the Wikimedia project as whole (not just for how we use and contribute to wikipedia) -- Ryk V 01:23, 14 October 2009 (UTC)

compatibility

I am worried about the compatibility of WYSIWYG with the almost programme-like wiki-syntax. Many people simply isn't aware that the wikitext is much more than just a mark-up, it is just a few steps from being a full-blown programming language (see meta:recursive conversion, for example). Would WYSIWYG create difficult to maintain wiki-codes? Hillgentleman 14:30, 15 August 2009 (UTC)

I agree, it would be much easier to make a hybrid editor like WikiEd standard. --Hannes Röst 12:42, 22 August 2009 (UTC)

Now, it's a good idea to have a hybrid editor, starting in WYSIWYG but being able to switch to WikiCode for fine-tuning. -ArkBlitz 20:56, 23 August 2009 (UTC)

Sounds good to me. Eb.eric 17:39, 24 August 2009 (UTC)

Introduce New Users to Wikipedia

I hardly edit wikipedia pages, other than editing typos and spelling mistakes or the odd sentence or two. This is mainly because I am confused b the code and would personally much prefer a visual editor as it would help new editors to improve wikipedia easily Xcoderules 18:53, 24 August 2009 (UTC)

Maybe offline editor?

It is somehow assumed that the WYSIWYG editor must be embedded into web site itself. Then it must be implemented in relatively slow scripting languages plus has a lot of security related limitations.

While it may be more work, I would like to suggest to discuss the standalone WYSIWYG editor that just talks to Wikipedia server same way as browser does. It actually could be a little kind of browser, being able to follow links inside Wikipedia and open all others in the system default browser. That way Wikipedia markup would simply be a format in which the editor is capable to save the output. Also, it should be a cross platform tool or provide executables for all most popular platforms. Serious project, I do not deny, but might be reasonable.

Lightweight JavaScript WYSIWYG editor would also make a lot of sense just it is clunky if badly written so also does not promise an easy progress.

Audriusa 19:09, 27 August 2009 (UTC)

Actually, if we could get rid entirely of this web crap (I mean W3C, HTML, CSS and lousy browsers stagnating the technical development), and base the development upon entirely new tools using wikitag language instead of those web standards, using and maintaining wikipedia would probably be a more straightforward process. Rursus 08:11, 29 August 2009 (UTC)

i like the idea of an offline editor. the reason why the assumption you've noted is made is for several reasons. the first is because wikipedia is presently an HTTP service; the second is because the creation of an actual "editor" is technically damn hard, and so using browser engine's "Design Mode" - which is what all these browser-based WYSWYG editors do - is much, much easier. fortunately, there's actually a way to have cake and eat it: browser engines, and technology that sits on top of the browser engines. by "browser engines" i am referring to Trident (aka MSHTML), XULRunner (the engine behind firefox) and Webkit (the engine behind chrome, safari, the iphone, android, nokia S60 and more). by using modern programming languages to access the DOM model of these "browser engines", you can enable the "Design Mode" in the web "page" and so have the best of all worlds. best of all is if you use a well-defined API such as the http://pyjs.org Pyjamas API, where you can have the exact same application be available both offline _and_ online. Lkcl 23:29, 11 October 2009 (UTC)

also, btw: it's worth noting that the fckeditor has a "wiki" mode, currently in development, to support WYSWYG editing of pages in wiki markup language. exactly how this is achieved i do not know, but unless there is something especially clever going on, i am slightly alarmed by what technically might be going on, under-the-hood :) Lkcl 23:29, 11 October 2009 (UTC)

also, you should be aware: fckeditor and other "quality" (i.e. feature-rich) javascript-based WYSIWYG editors, are horrendously large, and can take anything up to fifteen to twenty seconds to load and stabilise in a page, even on a decent 1.2ghz dual-core system with 2gb of RAM. so you have to be really careful about how you go about implementing the editor (online or offline). Lkcl 23:33, 11 October 2009 (UTC)

Impact?

Some proposals will have massive impact on end-users, including non-editors. Some will have minimal impact. What will be the impact of this proposal on our end-users? -- Philippe 00:18, 3 September 2009 (UTC)

Well if it is implemented the way I see it (as default for new and anonymous users, but optional for existing users), the impact will be very big for all new editors, but minimal for existing editors (unless they opt in) and non-existing for users who do not contribute (aside from the potential increase in productivity and thus content). Eb.eric 15:51, 9 September 2009 (UTC)

assuming that fckeditor's "wiki" mode (still under development?) is completed, the impact will be large and detrimental to those users with access to hardware with limited resources (15-year-old machines; mobile devices; e-Books etc), or software that is not up-to-date (FF2, IE6). taking fckeditor as an example of a javascript-based editor which enables "Design Mode" of the browser engine: the cost of the support infrastructure (to provide menus, toolbars and the dialog boxes behind each toolbar button) is huge, and thus dramatically slows down the slower browser and/or the underpowered hardware. Lkcl 23:40, 11 October 2009 (UTC)

A tool for references

WYSIWYG editor is not necessary for an experienced user, but it would be good to add some (WYSIWYG) tool into menu for adding references with every features for adding references include real-time adding references from DOI, adding references from some databases, citing websites with automatic adding date of creation of certain page, easy adding of a reference which a user used before, .... --Snek01 01:01, 29 September 2009 (UTC)

Potential Cost

Could the person who added the 100 million dollar cost estimate add a reference to the interview mentioned (Dedalus I think)? Because a 100 million or even 50 million dollar seems like a huge over-estimation (but I'm not an expert). I'd probably put my estimate around a few million dollar. It should be noted that adapting editor from an open-source project to Wikipedia would be even much cheaper. -- Ryk V 16:03, 12 October 2009 (UTC)

According to Wired ([1]) Jason Calacanis, CEO of Mahalo, estimates the cost of putting up a WYSIWYG editor on Wikipedia at $50 000. -- Ryk V 19:16, 12 October 2009 (UTC)

Maybe Java applet?

If JavaScript editor is difficult to write because it is slow and complex, maybe Java applet could be tried? Java platform is much faster than JavaScript and also better adapted to support complex implementations. Browsers cache applets so even if it may have a size of the big image (2Mb or about is the most I can imagine), it would only be downloaded once, at the end do not adding a lot to the traffic. It is trivial to install Java even if it is missing and it is possible to use tools like NoScript to disable it everywhere apart Wikipedia. I did not find the active FOSS project offering such an applet but there are some commercial implementation [2] showing that the idea may be serious enough to discuss. AudriusA 07:32, 2 November 2009 (UTC)