Proposal talk:Wikimedia editor

is there any plan to add distributed version control as storage mechanism to do proper mergers? like http://selenic.com/mercurial in case its python?

Added into the features :) --Millosh 17:09, 2 August 2009 (UTC)

if that's part of the "user interface application" and such version control is not aimed at being an enhancement of the actual wikipedia database ITSELF, then this proposal remains firmly in the "View" category of the MVC "pattern". however, IF by "distributed version control" it is meant "wikipedia's database should become a peer-to-peer distributed database, such that distributed version control is possible" THEN this proposal also falls into the "Model" category, and should be merged with e.g. Proposal:Distributed_Wikipedia. Lkcl 11:21, 10 October 2009 (UTC)

no WYSIWYG

WYSIWYG editors ususally produce sourcecode that is really hard to read for humans. Advanced users who optimise articles using enhanced wiki markup will have a hard job to clean everything up again to make it readable again. Matthias M. 11:07, 3 August 2009 (UTC)

My understanding is that the prototype Google Wave editor is WYSIWYG while retaining human-readable wiki markup.--Pharos 11:28, 3 August 2009 (UTC)

Many people think it's hard to read wiki codes, and then they don't edit. It's really bad to some wikis. WYSIWYG editors can help them.--Hat600 06:59, 12 August 2009 (UTC)

Is it easy to make template calls WYSIWYG? --Liangent 04:19, 12 August 2009 (UTC)

Maybe the editors are able to read templates ONLINE, and some useful templates may be added in the database.--Hat600 07:02, 12 August 2009 (UTC)

I mean, not only render it but also edit it in a WYSIWYG interface. --Liangent 12:13, 13 August 2009 (UTC)

I am separately proposing a WYSIWYG editor be implemented: Proposal:WYSIWYG default editor. Eb.eric 15:41, 13 August 2009 (UTC)

OMG Yes

Getting a working API ecosystem with outside editing and content management apps might help us do more with the volunteers we have, garner new editors, and possibly even support new projects. It could also let people build new strategies for use of Wikimedia content (Adobe AIR apps of Wikipedia?) like they have on the iPhone and Android. Steven Walling 00:43, 6 August 2009 (UTC)

While many Wikipredia reader apps exist, an editor (outside of Safari) would be very useful. Wikimedia could develop it as a web app, saving the trouble of App Store distribution and the cost of Apple's developer program. It would just need to be a slimmed-down interface.--HereToHelp 13:22, 13 August 2009 (UTC)

Usability initiative

The Usability initiative is in the process of overhauling the interface. Pragmatically, what cam we do there to implement some of the features of your editor?--HereToHelp 13:22, 13 August 2009 (UTC)

AWB

Could anyone tell me the difference between a WYSIWYG editor and the AutoWiki Browser?... I haven't tried it but my idea was almost that it's the same thing this proposal is about... if i'm wrong plz correct me!. Cheers Koraiem 01:39, 14 August 2009 (UTC)

I think you rises my general question: why just a WYSIWYG editor, why not a wiki-specialized browser? Rursus 08:02, 18 August 2009 (UTC)

you can get one of those, very easily: see | pyjamas desktop. Pyjamas Desktop has back-end code for three separate engines: webkit, mshtml and xulrunner, with a large amount of effort gone into making the differences between the three engines non-existent. Lkcl 10:47, 10 October 2009 (UTC)

Outside WP

I think the proposal aims at making a WYSIWYG editor for a generalized information collaboration that could be refered to as Web 3.0++ or something very much needed but hard to achieve given the current web. Google docs tries something like this, but doesn't have a natural system for hindering collaborative edits from overwriting each other. It is possible to write highly collaborative software by using HTML/XHTML and EcmaScript (JavaScript and similar), but it is unstable like Lower H*ck, an provides less than zero protection. The idea is somewhat that I've thought up from times to another – perfectly suitable for Net collaborations of any kind – but it isn't strictly required to maintain and build an encyclopedi, and it requires a web beyond the current stagnant Web 1.0, which is essentially stalled by all competition between lousy web browsers (none mentioned, none forgotten). Rursus 11:11, 18 August 2009 (UTC)

This topic

Looks like a good suggestion as long as this is in addition to being able to use a web browser to edit Wikipedia and not instead of using a web browser to edit. 98.227.232.84 21:30, 31 August 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:19, 3 September 2009 (UTC)

If adopted, this proposal would have massive impact on end-users. This software would increase participation a lot if it would be properly presented. --Millosh 13:27, 11 September 2009 (UTC)

Merging

I do not thing that this proposal has enough common with Proposal:Separate content from style to make the merging reasonable. Audriusa 17:39, 6 September 2009 (UTC)

I think so, too; but there are a couple of projects which may make one group and, probably, be merged with Usability initiative. --Millosh 13:29, 11 September 2009 (UTC)

MVC

it should come as no surprise that there is a reoccurring theme to proposals, that fall into the categories of:

1. provide easier read-write access to the wikipedia database
2. provide a means to create alternative front-ends
3. provide alternative front-ends

unsurprisingly, these fit into "Model", "View" and "Controller".

so, this _particular_ proposal fits into the "View" category, but is also proposing a bit of "Controller", too. Proposal:Separate content from style definitely falls into the "Controller" category, but is also proposing a bit of "Model" as well, and describes how it would be good to have "View" bits.

so, Audriusa - whilst at first glance you are correct, it entirely depends on which of the three categories of MVC that these two proposals are focussing the most on. But, from all of the proposals, it should be blindingly obvious that people are absolutely clamouring for better access on all fronts. Lkcl 10:57, 10 October 2009 (UTC)

Let's not demand Wikimedians Reinvent the Wheel

Please before asking it be done one specific way, please read up on the issue. Learn your stuff. http://www.mediawiki.org/wiki/WYSIWYG_editor

There already are several WYSIWYG implementations. There already have been a dozen attempts at making wiki markup well-formed to be better for WYSIWYG and transitioning current lexer mark-up to well-formed markup.

Yes, it would be really cool if we could have a working-all-the-time WYSIWYG editor which didn't create a bunch of mucky source code (I've never known a functional WYSIWYG editor which didn't) and didn't require the source code to be ugly as hell (I've never known a functional WYSIWYG editor which didn't).

It's important to have a page's source code to be readable text and not a gigantic mucky ugly jumble. Why? Think storage space, or think about if you have your own local copy of wikimedia data and you don't know how to set up your own local wikimedia server / parser, or Think about the problems of establishing and maintaining what is essentially a new, complex file format or document standard (You know how the W3C standard for HTML5 has been under debate for years? It'd be worse here). We try to go WYSIWYG too sloppily, and improving the software with wikipedia or working with pages en masse, or otherwise maintaining the server may become 20x harder. It's a big trade-off. Figuring out how to minimize that is one of the things that will have to happen first.

The usability study confirmed to the WMF foundation and the dozens of volunteer WikiMedia Software programmers that people want easier editing and many people want wysiwyg. They know that already. That's not what's holding them back. The problem is how it might be done. If you want Wysiwyg to happen, the best way to do it is to get a sense of its problems and the arguments against it, so you can argue for how.

For example, I also want to see WYSIWYG happen, but only if it's done in a graceful way which doesn't destroy the current simplicity of data on a wiki. Learn about the subject so you can understand the complexity of it and make better and more nuanced arguments. --Lyc. cooperi 11:23, 2 October 2009 (UTC)

I prefer wiki instead of WYSIWYG, too. Probably, I would like just to have syntax like "[[local:" which would pop-up file browser for file upload (and upload file in background). However, this proposal is not just about WYSIWYG, as well as WYSIWYG is necessary if we want to see Wikimedia projects as a general purpose scientific tool (and not just scientific tool). Technical knowledge should be lowered if we want to have contributors which don't have strong technical skills. --212.69.3.36 05:07, 3 October 2009 (UTC)