Here's the demo, where you can edit some canned texts (but not actual Wikipedia articles, yet):
http://www.mediawiki.org/wiki/Special:VisualEditorSandbox
Post bugs here:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&...
And here's the blog post, which puts it more in context.
http://blog.wikimedia.org/2011/12/13/help-test-the-first-visual-editor-devel...
This new editor was mostly written by Trevor Parscal and Inez Korczyński, although lots of others have contributed. I've sat a desk away from them for a few months and I have to say I'm extremely impressed with what they've put together. If you're expecting Google Docs, we're not there yet. But the basics are starting to solidify, and it's getting easier and easier to add cool features.
Hey MediaWiki developers, surely you're not going to let Trevor and Inez have *all* the fun?
Awesome work - Trevor, Inez, Neil! Thanks to Brion, Gabriel and Roan for all your work behind the scenes!
Look forward to everyone's feedback and bug reports to help us improve the functionality.
-Alolita
On Tue, Dec 13, 2011 at 1:27 PM, Neil Kandalgaonkar neilk@wikimedia.orgwrote:
Here's the demo, where you can edit some canned texts (but not actual Wikipedia articles, yet):
http://www.mediawiki.org/wiki/Special:VisualEditorSandbox
Post bugs here:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&...
And here's the blog post, which puts it more in context.
http://blog.wikimedia.org/2011/12/13/help-test-the-first-visual-editor-devel...
This new editor was mostly written by Trevor Parscal and Inez Korczyński, although lots of others have contributed. I've sat a desk away from them for a few months and I have to say I'm extremely impressed with what they've put together. If you're expecting Google Docs, we're not there yet. But the basics are starting to solidify, and it's getting easier and easier to add cool features.
Hey MediaWiki developers, surely you're not going to let Trevor and Inez have *all* the fun?
-- Neil Kandalgaonkar (| neilk@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Neil Kandalgaonkar schrieb:
Here's the demo, where you can edit some canned texts (but not actual Wikipedia articles, yet):
http://www.mediawiki.org/wiki/Special:VisualEditorSandboxHey MediaWiki developers, surely you're not going to let Trevor and Inez have *all* the fun?
Very impressive. But I've seen no handling of template/preprocessor syntax? I thought I had seen beginnings in that field around those Future/Parser pages in the wiki, but does it work?
For over a year I have ideas how to build a Javascript live preprocessor, but since I've studied the preprocessor code and written a static js preprocessor I had no time to start it off. So now I'd really love to help with that.
Bergi
Bergi wrote:
Neil Kandalgaonkar schrieb:
Here's the demo, where you can edit some canned texts (but not actual Wikipedia articles, yet):
http://www.mediawiki.org/wiki/Special:VisualEditorSandboxHey MediaWiki developers, surely you're not going to let Trevor and Inez have *all* the fun?
Very impressive. But I've seen no handling of template/preprocessor syntax? I thought I had seen beginnings in that field around those Future/Parser pages in the wiki, but does it work?
Agreed. Very nice work! :-)
It may make sense to have a list of "known limitations" somewhere to avoid duplicate bugs/issue reports. There are already several feedback comments describing issues that I'm almost positive were already known about by the developers involved.
I'm very excited to see what comes next.
MZMcBride
On Tue, Dec 13, 2011 at 10:28 PM, MZMcBride z@mzmcbride.com wrote:
Bergi wrote:
Neil Kandalgaonkar schrieb:
Here's the demo, where you can edit some canned texts (but not actual Wikipedia articles, yet):
http://www.mediawiki.org/wiki/Special:VisualEditorSandbox
Hey MediaWiki developers, surely you're not going to let Trevor and Inez have *all* the fun?
Very impressive. But I've seen no handling of template/preprocessor syntax? I thought I had seen beginnings in that field around those Future/Parser pages in the wiki, but does it work?
Agreed. Very nice work! :-)
It may make sense to have a list of "known limitations" somewhere to avoid duplicate bugs/issue reports. There are already several feedback comments describing issues that I'm almost positive were already known about by the developers involved.
I'm very excited to see what comes next.
MZMcBride
Yes, congrats! Works quite well and quick, considering the early stage.
/me is off to create bug report flood
Magnus
On Tue, Dec 13, 2011 at 20:28, MZMcBride z@mzmcbride.com wrote:
It may make sense to have a list of "known limitations" somewhere to avoid duplicate bugs/issue reports.
The following list may help with that: https://bugzilla.wikimedia.org/buglist.cgi?component=VisualEditor
Very impressive. But I've seen no handling of template/preprocessor syntax? I thought I had seen beginnings in that field around those Future/Parser pages in the wiki, but does it work?
The current tokenizer handles template syntax well, but template expansion is work in progress. Doing the expansion on the token stream should allow us to render unbalanced templates like the table start / row / table end combinations.
Representing these unbalanced templates in an expanded state in the editor is difficult though, so I guess the most likely solution is to wrap these templates into an opaque object editable with a specialized widget.
For over a year I have ideas how to build a Javascript live preprocessor, but since I've studied the preprocessor code and written a static js preprocessor I had no time to start it off. So now I'd really love to help with that.
We try to do without a textual preprocessor, and instead move most preprocessor tasks to transformations on a token stream produced by a grammar-based tokenizer [1]. Template expansion is already implemented for a tree structure, but needs to be ported to handle tokens. Many other parser tasks are listed in the todo section of [1].
I am currently working on a conversion of HTML DOM to WikiDom, with template expansion planned next. Feel free to dive into the code and tackle any of the tasks on the list ;)
Gabriel
[1]: https://www.mediawiki.org/wiki/Future/Parser_development
On 12/13/2011 10:27 PM, Neil Kandalgaonkar wrote:
Here's the demo, where you can edit some canned texts (but not actual Wikipedia articles, yet):
http://www.mediawiki.org/wiki/Special:VisualEditorSandbox
Something that looks like a working prototype is exactly where LiquidThreads were two years ago, and we got all excited and wanted so hard to try this for the Swedish community, and asked to have it installed first in the Swedish Wikisource. We had to wait for months until it was finally made available. But this enthusiasm turned out to be a really big mistake. It never worked, and the WMF never invested any effort in fixing the problems. At last, in October this year, we gave up and are now using old-style talk pages for all discussions again. This most painful experience will make me advocate against any attempt to use the Swedish projects as a pilot to try out the new visual editor. I do mistakes, but I learn from them.
Your timeline (http://www.mediawiki.org/wiki/Visual_editor) does mention the WMF annual plan for 2011-2012, http://wikimediafoundation.org/wiki/2011-2012_Annual_Plan_Questions_and_Answ... which states "first small wiki default deployment by June 2012." But the important part is the plan for the year 2012-2013, and what effort and budget the WMF will spend on rescuing the roll-out, even in the casethe main developers suddenly leave the project.
My mistake, from which I learned, was that I didn't ask for that kind of plan, when I first heard about LiquidThreads. I couldn't imagine that such a major usability improvement as getting rid of indented talk pages could be a zero priority for the WMF, one that was allowed to depend on the personal schedule of a single main developer. Even today, as we lament the decline in contributors, how can it not be important to fix LiquidThreads?
Cool editor! Do you support collaboration via something like http://code.google.com/p/google-mobwrite/ ? In any event, great work, hope it sees the light of day.
On 12/13/11 4:33 PM, Olivier Beaton wrote:
Cool editor! Do you support collaboration via something like http://code.google.com/p/google-mobwrite/ ? In any event, great work, hope it sees the light of day.
We've done experiments with collaboration. We have no official mandate to do a collaborative editor, the only thing we're officially working on is a GUI editor.
But, we've spent a lot of time studying Wave and Etherpad, and we're trying to ensure that our transaction model would allow for live collaboration. It is difficult to see what this would mean for Wikipedia exactly, but I think it could help pass on Wiki values and practices if people could collaborate in real time.
We will probably never support live updates of the page you are looking at though. This would be collaboration by users who join some kind of editing session. The security of that session is another unsolved problem.
On Tue, Dec 13, 2011 at 1:27 PM, Neil Kandalgaonkar neilk@wikimedia.org wrote:
Here's the demo, where you can edit some canned texts (but not actual Wikipedia articles, yet):
This looks really cool. :-)
What browsers/versions are you targeting?
Out of curiosity, what is making the (un)toggle operations on the right take so long? Actually, it looks like you are marking up individual lines of text. I suppose that is time consuming. Why is that necessary?
Will there be a toggle for editing wiki text directly (I see wikitext display is already there)?
~Rusty
On Tue, Dec 13, 2011 at 4:34 PM, Rusty Burchfield gicodewarrior@gmail.com wrote:
Out of curiosity, what is making the (un)toggle operations on the right take so long?
From http://www.mediawiki.org/wiki/Visual_editor/Feedback#Fantastic.21_A_few_poin....
:
"Oddly, I don't see this with Firefox, and it comes down to Webkit taking a ridiculous (like 10x) amount of time to give a result for domElement.clientWidth (which measures the size of an element on screen). But yes, we are looking into it for sure. --Trevor Parscal 22:08, 13 December 2011 (UTC)"
On Wed, Dec 14, 2011 at 1:34 AM, Rusty Burchfield gicodewarrior@gmail.com wrote:
On Tue, Dec 13, 2011 at 1:27 PM, Neil Kandalgaonkar neilk@wikimedia.org wrote:
Here's the demo, where you can edit some canned texts (but not actual Wikipedia articles, yet):
This looks really cool. :-)
What browsers/versions are you targeting?
Out of curiosity, what is making the (un)toggle operations on the right take so long?
AFAIK this is a known bug specific to WebKit-based browsers. It doesn't happen in Firefox.
Actually, it looks like you are marking up individual lines of text. I suppose that is time consuming. Why is that necessary?
The edit surface is *entirely* implemented in JS, almost nothing is done by the browser. Breaking lines is one of the many things that's done in JS.
Will there be a toggle for editing wiki text directly (I see wikitext display is already there)?
We can't implement that right now because the wikitext -> WikiDOM (the model used by the editor) isn't ready yet.
Roan
On 13/12/11 21:27, Neil Kandalgaonkar wrote:
Here's the demo, where you can edit some canned texts (but not actual Wikipedia articles, yet):
http://www.mediawiki.org/wiki/Special:VisualEditorSandboxPost bugs here:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&...
And here's the blog post, which puts it more in context.
http://blog.wikimedia.org/2011/12/13/help-test-the-first-visual-editor-devel...
That is really cool; at long last, the WYSIWYG editor is not just on its way, but looking really good!
Once the wikitext parser (which is, of course, the hard part) is ready to be bolted in, that should give a big improvement in Wikipedia's accessibility for new editors -- almost everyone knows how to use a word processor.
-- N.
----- Original Message -----
From: "Neil Harris" neil@tonal.clara.co.uk
On 13/12/11 21:27, Neil Kandalgaonkar wrote:
That is really cool; at long last, the WYSIWYG editor is not just on its way, but looking really good!
Once the wikitext parser (which is, of course, the hard part) is ready to be bolted in, that should give a big improvement in Wikipedia's accessibility for new editors -- almost everyone knows how to use a word processor.
Yup. And they use them to write email.
<pessimist> Which is just as bad an idea as using them to write wikitext. </pessimist>
Cheers, -- jra
On 14 December 2011 02:57, Neil Harris neil@tonal.clara.co.uk wrote:
Once the wikitext parser (which is, of course, the hard part) is ready to be bolted in, that should give a big improvement in Wikipedia's accessibility for new editors -- almost everyone knows how to use a word processor.
As you say, it's the wikitext bit that's hard. Without that, a wysiwyg editor is reasonably simple (we could have just used the one Wikia created, perhaps with a few modifications). The challenge is having pages that can be edited both by wysiwyg and in wikitext without the two tripping over each other. That's why I'm going to keep the cork firmly in the champagne bottle until we're asked to test that bit (I'll keep the bottle on ice, though, because this looks like a great start!).
Thomas Dalton writes:
The challenge is having pages that can be edited both by wysiwyg and in wikitext without the two tripping over each other.
To address this, I think any visual editor project needs to decide which audience it's serving:
- The average user - The average user AND power users
If you're serving power users, the visual editor must perform powerful edits more quickly & easily than typing wikitext directly. If you're serving only the average user, you don't have to worry about this, but complex wikitext (templates & parser functions/tags) needs to be protected against breakage by the average user.
DanB
On Dec 14, 2011 3:16 PM, "Daniel Barrett" danb@vistaprint.com wrote:
Thomas Dalton writes:
The challenge is having pages that can be edited both by wysiwyg and in
wikitext without the
two tripping over each other.
To address this, I think any visual editor project needs to decide which
audience it's serving:
- The average user
- The average user AND power users
If you're serving power users, the visual editor must perform powerful
edits more quickly & easily than typing wikitext directly. If you're serving only the average user, you don't have to worry about this, but complex wikitext (templates & parser functions/tags) needs to be protected against breakage by the average user.
The issue is that, even if power users don't use the new interface they still need to be able to use the old one to edit the same articles. If the wikitext created by the visual editor is unnecessarily complicated and unreadable (like the html produced by ms frontpage, for instance) then there is problem. Similarly, the visual editor needs to be able to parse even quite strangely written wikitext.
The issue is that, even if power users don't use the new interface they still need to be able to use the old one to edit the same articles. If the wikitext created by the visual editor is unnecessarily complicated and unreadable (like the html produced by ms frontpage, for instance) then there is problem. Similarly, the visual editor needs to be able to parse even quite strangely written wikitext.
^^ This, 100 times over :)
Writing a visual editor is painfully hard. I've just finished one for a current project after we evaluated what felt like a billion pre-existing alternatives. Without fail they all suffered in that their output left a * lot* to be desired.
The key thing to remember is that the output should be indistinguishable from what a power editor would have written.
And cover all the edge cases (because with millions of articles we have lots of those).
However; this looks an interesting start. I like the simplicity.
Tom
Thomas Dalton wrote:
even if power users don't use the new interface they still need to be able to use the old one to edit the same articles. If the wikitext created by the visual editor is unnecessarily complicated and unreadable (like the html produced by ms frontpage, for instance) then there is problem. Similarly, the visual editor needs to be able to parse even quite strangely written wikitext.
You are absolutely right. I was just saying something additional: that if VisualEditor isn't targeting power users, then the dev team shouldn't build a powerful editing UI for templates. Instead they should worry about preserving an article's template transclusions from damage by non-aware users.
To add to your words: the visual editor should be able to:
- Parse, render, and write 100% of wikitext. - Produce minimal, correct wikitext for new edits. - Exactly preserve any other (unchanged) wikitext that it loads & saves; otherwise version diffs will show changes that the author didn't explicitly make. (Prime offender: the ASP.NET editor in Visual Studio.NET, which used to completely rewrite its contents.)
DanB
I'm far from being enough skilled to understand the whole stuff. Working as hardly as I can into wikisource, I found that the most useful tools are js scripts like RegexMenuFramework by Pathoschild, t.i. a "container" for personal, highly customizable js scripts to work on wikitext (fixing scannos, formatting, adding specific templates); there's no need of so much skill to build new simple, effective tools by a js beginner as I am; this is simple dealing with a plain text into text box of a form, I guess it would not be so simple into the highly structured html of Visual editor.
Is there some hope about keeping js editing of wikitext/source text into Visual Editor as simple as it is presently?
Alex
Hoi, While testing the visual editor I changed my language in my preferences to Tamil and it insist on the Latin script for entering text.
When it does allow for other scripts I will be very happy to open the floodgates of Indic language users for you :) . I am sure that they will be more eager to test the visual editor in a timely manner. This would be a win-win situation because the visual editor seems to me to be a great usability improvement
Also, consider the use of Narayam and WebFonts on the MediaWiki wiki. This is necessary for an Indic environment and consequently testing in the Indic scripts and languages. Thanks, Gerard
On 13 December 2011 22:27, Neil Kandalgaonkar neilk@wikimedia.org wrote:
Here's the demo, where you can edit some canned texts (but not actual Wikipedia articles, yet):
http://www.mediawiki.org/wiki/Special:VisualEditorSandbox
Post bugs here:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&...
And here's the blog post, which puts it more in context.
http://blog.wikimedia.org/2011/12/13/help-test-the-first-visual-editor-devel...
This new editor was mostly written by Trevor Parscal and Inez Korczyński, although lots of others have contributed. I've sat a desk away from them for a few months and I have to say I'm extremely impressed with what they've put together. If you're expecting Google Docs, we're not there yet. But the basics are starting to solidify, and it's getting easier and easier to add cool features.
Hey MediaWiki developers, surely you're not going to let Trevor and Inez have *all* the fun?
-- Neil Kandalgaonkar (| neilk@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org