TL;DR: Today we are launching an alpha, opt-in version of the VisualEditor[0] to the English Wikipedia. This will let editors create and modify real articles visually, using a new system where the articles they edit will look the same as when you read them, and their changes show up as they type enter them — like writing a document in a word processor. Please let us know what you think[1].
Why launch now?
We want our community of existing editors to get an idea of what the VisualEditor will look like in the “real world” and start to give us feedback about how well it integrates with how they edit right now, and their thoughts on what aspects are the priorities in the coming months.
The editor is at an early stage and is still missing significant functions, which we will address in the coming months. Because of this, we are mostly looking for feedback from experienced editors at this point, because the editor is insufficient to really give them a proper experience of editing. We don’t want to promise an easier editing experience to new editors before it is ready.
As we develop improvements, they will be pushed every fortnight to the wikis, allowing you to give us feedback[1] as we go and tell us what next you want us to work on.
How can I try it out?
The VisualEditor is now available to all logged-in accounts on the English Wikipedia as a new preference, switched off by default. If you go to your “Preferences” screen and click into the “Editing” section, it will have as an option labelled “Enable VisualEditor”).
Once enabled, for each article you can edit, you will get a second editor tab labelled “VisualEditor” next to the “Edit” tab. If you click this, after a little pause you will enter the VisualEditor. From here, you can play around, edit and save real articles and get an idea of what it will be like when complete.
At this early stage in our development, we recommend that after saving any edits, you check whether they broke anything. All edits made with the VisualEditor will show up in articles’ history tabs with a “VisualEditor” tag next to them, so you can track what is happening.
Things to note
Slow to load - It will take some time for long complex pages to load into the VisualEditor, and particularly-big ones may timeout after 60 seconds. This is because pages have to be loaded through Parsoid which is also in its early stages, and is not yet optimised for deployment and is currently uncached. In the future (a) Parsoid itself will be much faster, (b) Parsoid will not depend on as many slow API calls, and (c) it will be cached.
Odd-looking - we currently struggle with making the HTML we produce look like you are used to seeing, so styling and so on may look a little (or even very) odd. This hasn't been our priority to date, as our focus has been on making sure we don't disrupt articles with the VisualEditor by altering the wikitext (correct "round-tripping").
No editing references or templates - Blocks of content that we cannot yet handle are uneditable; this is mostly references and templates like infoboxes. Instead, when you mouse over them, they will be hatched out and a tooltip will inform you that they have to be edited via wikitext for now. You can select these items and delete them entirely, however there is not yet a way to add ones in or edit them currently (this will be a core piece of work post-December).
Incomplete editing - Some elements of "complex" formatting will display and let you edit their contents, but not let users edit their structure or add new entries - such as tables or definition lists. This area of work will also be one of our priorities post-December.
No categories - Articles' "meta" items will not appear at all - categories, langlinks, magic words etc.; these are preserved (so editing won't disrupt them), but they not yet editable. Another area for work post-December - our current plan is that they will be edited through a "metadata flyout", with auto-suggestions and so on.
Poor browser support - Right now, we have only got VisualEditor to work in the most modern versions of Firefox, Chrome and Safari. We will find a way to support (at least) Internet Explorer post-December, but it's going to be a significant piece of work and we have failed to get it ready for now.
Articles and User pages only - The VisualEditor will only be enabled for the article and user namespaces (so you can make changes in a personal sandbox), and will not work with talk pages, templates, categories, etc.. In time, we will build out the kinds of specialised editing tools needed for non-articles, but our focus has been on articles.
Final point
This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.[1]
[0] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor [1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback
Yours, -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
On Tue, Dec 11, 2012 at 7:30 PM, James Forrester jforrester@wikimedia.org wrote:
TL;DR: Today we are launching an alpha, opt-in version of the VisualEditor[0] to the English Wikipedia. This will let editors create and modify real articles visually, using a new system where the articles they edit will look the same as when you read them, and their changes show up as they type enter them — like writing a document in a word processor. Please let us know what you think[1].
Congrats, team! :-D Being able to edit the Real Thing is indeed a huge deal -- even if it's still the very very very (very) first release to do so. A long road ahead, but maybe some sleep is in order. ;-)
The future just got a little more real.
Erik
For Trevor to remember...
So we tried visually editing using the PS3 browser...
Great job team! :-)
Sent from my <free corporate advertising removed at the request of the owner>
On Dec 11, 2012, at 10:07 PM, Erik Moeller erik@wikimedia.org wrote:
On Tue, Dec 11, 2012 at 7:30 PM, James Forrester jforrester@wikimedia.org wrote:
TL;DR: Today we are launching an alpha, opt-in version of the VisualEditor[0] to the English Wikipedia. This will let editors create and modify real articles visually, using a new system where the articles they edit will look the same as when you read them, and their changes show up as they type enter them — like writing a document in a word processor. Please let us know what you think[1].
Congrats, team! :-D Being able to edit the Real Thing is indeed a huge deal -- even if it's still the very very very (very) first release to do so. A long road ahead, but maybe some sleep is in order. ;-)
The future just got a little more real.
Erik
Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
tl;dr: VE does not work for me
https://bugzilla.wikimedia.org/show_bug.cgi?id=42988 Hanging after "Review and save" --> "Review your changes" hangs, no saving
On Tuesday, December 11, 2012 at 7:30 PM, James Forrester wrote:
TL;DR: Today we are launching an alpha, opt-in version of the VisualEditor[0] to the English Wikipedia. This will let editors create and modify real articles visually, using a new system where the articles they edit will look the same as when you read them, and their changes show up as they type enter them — like writing a document in a word processor. Please let us know what you think[1].
This is very exciting. Congratulations, VE team!
-- Ori Livneh
Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki.
-Chris
On Tue, Dec 11, 2012 at 8:30 PM, James Forrester jforrester@wikimedia.orgwrote:
TL;DR: Today we are launching an alpha, opt-in version of the VisualEditor[0] to the English Wikipedia. This will let editors create and modify real articles visually, using a new system where the articles they edit will look the same as when you read them, and their changes show up as they type enter them — like writing a document in a word processor. Please let us know what you think[1].
Why launch now?
We want our community of existing editors to get an idea of what the VisualEditor will look like in the “real world” and start to give us feedback about how well it integrates with how they edit right now, and their thoughts on what aspects are the priorities in the coming months.
The editor is at an early stage and is still missing significant functions, which we will address in the coming months. Because of this, we are mostly looking for feedback from experienced editors at this point, because the editor is insufficient to really give them a proper experience of editing. We don’t want to promise an easier editing experience to new editors before it is ready.
As we develop improvements, they will be pushed every fortnight to the wikis, allowing you to give us feedback[1] as we go and tell us what next you want us to work on.
How can I try it out?
The VisualEditor is now available to all logged-in accounts on the English Wikipedia as a new preference, switched off by default. If you go to your “Preferences” screen and click into the “Editing” section, it will have as an option labelled “Enable VisualEditor”).
Once enabled, for each article you can edit, you will get a second editor tab labelled “VisualEditor” next to the “Edit” tab. If you click this, after a little pause you will enter the VisualEditor. From here, you can play around, edit and save real articles and get an idea of what it will be like when complete.
At this early stage in our development, we recommend that after saving any edits, you check whether they broke anything. All edits made with the VisualEditor will show up in articles’ history tabs with a “VisualEditor” tag next to them, so you can track what is happening.
Things to note
Slow to load - It will take some time for long complex pages to load into the VisualEditor, and particularly-big ones may timeout after 60 seconds. This is because pages have to be loaded through Parsoid which is also in its early stages, and is not yet optimised for deployment and is currently uncached. In the future (a) Parsoid itself will be much faster, (b) Parsoid will not depend on as many slow API calls, and (c) it will be cached.
Odd-looking - we currently struggle with making the HTML we produce look like you are used to seeing, so styling and so on may look a little (or even very) odd. This hasn't been our priority to date, as our focus has been on making sure we don't disrupt articles with the VisualEditor by altering the wikitext (correct "round-tripping").
No editing references or templates - Blocks of content that we cannot yet handle are uneditable; this is mostly references and templates like infoboxes. Instead, when you mouse over them, they will be hatched out and a tooltip will inform you that they have to be edited via wikitext for now. You can select these items and delete them entirely, however there is not yet a way to add ones in or edit them currently (this will be a core piece of work post-December).
Incomplete editing - Some elements of "complex" formatting will display and let you edit their contents, but not let users edit their structure or add new entries - such as tables or definition lists. This area of work will also be one of our priorities post-December.
No categories - Articles' "meta" items will not appear at all - categories, langlinks, magic words etc.; these are preserved (so editing won't disrupt them), but they not yet editable. Another area for work post-December - our current plan is that they will be edited through a "metadata flyout", with auto-suggestions and so on.
Poor browser support - Right now, we have only got VisualEditor to work in the most modern versions of Firefox, Chrome and Safari. We will find a way to support (at least) Internet Explorer post-December, but it's going to be a significant piece of work and we have failed to get it ready for now.
Articles and User pages only - The VisualEditor will only be enabled for the article and user namespaces (so you can make changes in a personal sandbox), and will not work with talk pages, templates, categories, etc.. In time, we will build out the kinds of specialised editing tools needed for non-articles, but our focus has been on articles.
Final point
This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.[1]
[0] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor [1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback
Yours,
James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Dec 12, 2012 at 10:58 AM, Chris McMahon cmcmahon@wikimedia.org wrote:
Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki.
It's also enabled for the user namespace, so people can feel free to play with it and not be afraid of messing up a real article.
-Chad
On Wed, Dec 12, 2012 at 8:59 AM, Chad innocentkiller@gmail.com wrote:
On Wed, Dec 12, 2012 at 10:58 AM, Chris McMahon cmcmahon@wikimedia.org wrote:
Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki.
It's also enabled for the user namespace, so people can feel free to play with it and not be afraid of messing up a real article.
I was thinking of making some basic automated browser tests for it. test2 is more handy than enwiki for that. Beta labs would be even better. -Chris
On Wed, Dec 12, 2012 at 8:59 AM, Chad innocentkiller@gmail.com wrote:
On Wed, Dec 12, 2012 at 10:58 AM, Chris McMahon cmcmahon@wikimedia.org wrote:
Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki.
It's also enabled for the user namespace, so people can feel free to play with it and not be afraid of messing up a real article.
I was thinking of making some basic automated browser tests for it. test2 is more handy than enwiki for that. Beta labs would be even better. -Chris
This will also be useful to the Parsoid team as well so we can test changes to parsoid itself more thoroughly (outside the rt-testing and parser tests that we already use). This would require the VE instance to use a different Parsoid instance which could be the existing one at parsoid.wmflabs.org, for example.
Subbu.
On 2012-12-12 16:58, Chris McMahon wrote:
Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki.
Do you really mean http://test2.wikipedia.org? AFAIK the wikidata team uses this installation as a testing client for http://wikidata.org repository concerning the interwiki-links.
Cheers
Marco
On Thu, Dec 13, 2012 at 8:59 AM, Marco Fleckinger marco.fleckinger@wikipedia.at wrote:
On 2012-12-12 16:58, Chris McMahon wrote:
Would it be possible to enable VE on test2 in the same way? I would like to use it in a noisy way, and would rather not make noise on enwiki.
Do you really mean http://test2.wikipedia.org? AFAIK the wikidata team uses this installation as a testing client for http://wikidata.org repository concerning the interwiki-links.
Indeed. I think VE will be fine though.
-Chad
On Tue, 2012-12-11 at 19:30 -0800, James Forrester wrote:
This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.[1]
[1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback
Playing the bad cop who's reading random feedback pages daily:
As https://www.mediawiki.org/wiki/VisualEditor/Feedback also exists I wonder if the VisualEditor deployment on en.wp and its related feedback is so different from upstream that it needs a separate feedback page (instead of e.g. a soft redirect to the mw: one), or other reasons. Or does the en.wp one somehow make it easier for testers to report issues? When we deploy VE to other Wikipedias, will there also be separate VE feedback pages (maybe due to the different languages)?
Note: I'm not criticizing it, I'm just trying to understand, and I'm picking VE as the most recent example.
Thanks in advance for explaining, andre
Would it be possible to enable VE in a similar manner on other WMF wikis?
I understand the concerns about developers being unable to respond to feedback in other languages, but most large projects have at least a few technical people who could serve as "relays", and I'd like to see some of the interface improvements start trickling down to projects other than the English Wikipedia.
-- Matma Rex ([[:w:pl:User:Matma Rex]])
On 12/12/2012 09:31 AM, Bartosz Dziewoński wrote:
Would it be possible to enable VE in a similar manner on other WMF wikis?
Currently Parsoid does not support localized namespaces, link trail character classes and other features. Without support for these, pages will not render and round-trip properly.
Implementing this is not rocket science, but is currently lower priority than other more urgent tasks.
Gabriel
On 12 December 2012 11:57, Andre Klapper aklapper@wikimedia.org wrote:
On Tue, 2012-12-11 at 19:30 -0800, James Forrester wrote:
This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.[1]
[1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback
Playing the bad cop who's reading random feedback pages daily:
As https://www.mediawiki.org/wiki/VisualEditor/Feedback also exists I wonder if the VisualEditor deployment on en.wp and its related feedback is so different from upstream that it needs a separate feedback page (instead of e.g. a soft redirect to the mw: one), or other reasons. Or does the en.wp one somehow make it easier for testers to report issues? When we deploy VE to other Wikipedias, will there also be separate VE feedback pages (maybe due to the different languages)?
Note: I'm not criticizing it, I'm just trying to understand, and I'm picking VE as the most recent example.
Thanks in advance for explaining, andre --
You're after a different audience for this alpha test - not the technically confident user who wanders from wiki to wiki and instinctively understands just about any software variation thrown at them, but those whose focus is on editing. Mediawiki wiki uses Liquid threads, which pretty well everyone considers an unacceptable talk page method, and it creates an unnecessary communication barrier for those who just want to report their findings rather than having to figure out a different site's software. And a rather significant number of enwp editors avoid other WMF wikis like the plague for complex sociological reasons. Bottom line, the objective is getting a wide range of editors to test the software through its various functions, identify issues, and report them. Making it as easy as possible for them to do so will produce the best response.
Risker
On Wed, Dec 12, 2012 at 8:57 AM, Andre Klapper aklapper@wikimedia.orgwrote:
On Tue, 2012-12-11 at 19:30 -0800, James Forrester wrote:
This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.[1]
[1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback
Playing the bad cop who's reading random feedback pages daily:
As https://www.mediawiki.org/wiki/VisualEditor/Feedback also exists I wonder if the VisualEditor deployment on en.wp and its related feedback is so different from upstream that it needs a separate feedback page (instead of e.g. a soft redirect to the mw: one), or other reasons. Or does the en.wp one somehow make it easier for testers to report issues? When we deploy VE to other Wikipedias, will there also be separate VE feedback pages (maybe due to the different languages)?
Note: I'm not criticizing it, I'm just trying to understand, and I'm picking VE as the most recent example.
Thanks in advance for explaining, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/
Risker said many of the reasons but the biggest reason is that a large portion of testers would not move wiki. Opening up a local spot for feedback drastically increases the amount of feedback you get which can be really helpful. Personally I think we should do it on as many wikis as we can for major projects like this but it's obviously difficult to do on many because of both the language barriers and watching too many feedback channels.
Yet another thing that once a product like Echo works cross wiki it could be helpful for :) but that's a bit of a ways away.
James
James Alexander Manager, Merchandise Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
Hello,
On 2012-12-12 20:04, James Alexander wrote:
On Wed, Dec 12, 2012 at 8:57 AM, Andre Klapperaklapper@wikimedia.orgwrote:
On Tue, 2012-12-11 at 19:30 -0800, James Forrester wrote:
This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.[1]
[1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback
Playing the bad cop who's reading random feedback pages daily:
As https://www.mediawiki.org/wiki/VisualEditor/Feedback also exists I wonder if the VisualEditor deployment on en.wp and its related feedback is so different from upstream that it needs a separate feedback page (instead of e.g. a soft redirect to the mw: one), or other reasons. Or does the en.wp one somehow make it easier for testers to report issues? When we deploy VE to other Wikipedias, will there also be separate VE feedback pages (maybe due to the different languages)?
Note: I'm not criticizing it, I'm just trying to understand, and I'm picking VE as the most recent example.
Thanks in advance for explaining, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/
Risker said many of the reasons but the biggest reason is that a large portion of testers would not move wiki. Opening up a local spot for feedback drastically increases the amount of feedback you get which can be really helpful. Personally I think we should do it on as many wikis as we can for major projects like this but it's obviously difficult to do on many because of both the language barriers and watching too many feedback channels.
Yet another thing that once a product like Echo works cross wiki it could be helpful for :) but that's a bit of a ways away.
The Wikidata-Team lays focus on the testing on RTL-wikis. The first Wikipedia ever will be huwiki, because their community decided themselves to be the first. Itwiki wanted to be the second one, but the Wikidata-Team wanted to test RTL, therefore they asked the hewiki.
Here I think i18n is very important as well, but I think it had already been tested many years ago. The PHP-regex-construct aka. wikiparser which is unidirectional has to be reimplemented by a real parser in JS.
Implementing this is not very easy, but developers can may use some of the old ideas. Parsing the other way around has to be realized really from the scratch but is easier because everything is in a tree. not in a single text-string.
Neither de- nor searalizing includes any surface, testing could be done automatically really easy comparing the results of conventional and the new parsing. The result of the serialization can be compared with the original markup.
The components including surfaces will for sure need i18n. Using icons instead of texts in a menu can help getting around this issue very easily. Although using many icons we also need text, but IMHO this should be avoided, also in foresight to the need of translation. ;-)
So this early version is for testing user's experience with this surface. I think this is really great and am impressed of the result it is a bit slow but, guys, it's still the alpha 1, what should I expect?
It also does not work on all browsers, as mentioned. E.g. the latest Firefox (aka. Iceweasel) on Debian Wheezy (not yet released), is not supported. This is okay for me.
I also think that people using outdated browsers should not have the same great experience. Everything necessary should work, but is the VE really essential?
Cheers
Marco
On 12/13/2012 06:43 AM, Marco Fleckinger wrote:
Implementing this is not very easy, but developers can may use some of the old ideas. Parsing the other way around has to be realized really from the scratch but is easier because everything is in a tree. not in a single text-string.
Neither de- nor searalizing includes any surface, testing could be done automatically really easy comparing the results of conventional and the new parsing. The result of the serialization can be compared with the original markup.
Hi Marco,
we (the Parsoid team) have been doing many of the things you describe in the last year:
* We wrote a new bidirectional parser / serializer - see http://www.mediawiki.org/wiki/Parsoid. This includes a grammar-based tokenizer, async/parallel token stream transformations and HTML5 DOM building.
* We developed a HTML5 / RDFa document model spec at http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec.
* Our parserTests runner tests wt2html (wikitext to html), wt2wt, html2html and html2wt modes with the same wikitext / HTML pairs as used in the PHP parser tests. We have roughly doubled the number of such pairs in the process.
* Automated and distributed round-trip tests are currently run over a random selection of 100k English Wikipedia pages: http://parsoid.wmflabs.org:8001/. This test infrastructure can easily be pointed at a different set of pages or another wiki.
Parsoid is by no means complete, but we are very happy with how far we already got since last October.
Cheers,
Gabriel
Hi Gabriel,
thank you for that information. Actually I already knew of the project. Therefore I could imagine a process as I described. This IMHO doesn't need much i18n, because there is an defined syntax for wt and for html.
On 2012-12-13 20:57, Gabriel Wicke wrote:
On 12/13/2012 06:43 AM, Marco Fleckinger wrote:
Implementing this is not very easy, but developers can may use some of the old ideas. Parsing the other way around has to be realized really from the scratch but is easier because everything is in a tree. not in a single text-string.
Neither de- nor searalizing includes any surface, testing could be done automatically really easy comparing the results of conventional and the new parsing. The result of the serialization can be compared with the original markup.
we (the Parsoid team) have been doing many of the things you describe in the last year:
Ah, that was the project's name. ;-)
- We wrote a new bidirectional parser / serializer - see
http://www.mediawiki.org/wiki/Parsoid. This includes a grammar-based tokenizer, async/parallel token stream transformations and HTML5 DOM building.
Thank you for pointing to that. Will also be interested for one of my private project.
- We developed a HTML5 / RDFa document model spec at
http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec.
- Our parserTests runner tests wt2html (wikitext to html), wt2wt,
html2html and html2wt modes with the same wikitext / HTML pairs as used in the PHP parser tests. We have roughly doubled the number of such pairs in the process.
- Automated and distributed round-trip tests are currently run over a
random selection of 100k English Wikipedia pages: http://parsoid.wmflabs.org:8001/. This test infrastructure can easily be pointed at a different set of pages or another wiki.
Once the top results in English are reached it should not be a big deal testing it on other wikis.
Parsoid is by no means complete, but we are very happy with how far we already got since last October.
Congratulation for that results so far.
Cheers
Marco
On 12/11/2012 07:30 PM, James Forrester wrote:
TL;DR: Today we are launching an alpha, opt-in version of the VisualEditor[0] to the English Wikipedia. This will let editors create and modify real articles visually, using a new system where the articles they edit will look the same as when you read them, and their changes show up as they type enter them — like writing a document in a word processor. Please let us know what you think[1].
Congratulations! I've enabled it, and I can see the existing form is already useful for some workflows.
I look forward to providing feedback, and towards the gaps getting filled in.
Matt Flaschen
wikitech-l@lists.wikimedia.org