Mailing List Archive

Developing true WISIWYG editor for media wiki
Hi guys,

At the moment we are discussing an opportunity to create full scale
true WYSIWYG client for media wiki. To the moment we have a technology
which should allow us to implement with a good quality and quite fast.
Unfortunately we are not sure
if there is a real need/interest for having such kind of client at the
media wiki world, as well as what are actual needs of media wiki
users. So we decided to write to this list. Any feedback/suggestion
will be very helpful.

P.S. Screen cast demonstrating our experimental client for Trac wiki
http://www.screencast.com/t/MDkzYzM4

Regards,
Pavel
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
Павел Петроченко wrote:
> Hi guys,
>
> At the moment we are discussing an opportunity to create full scale
> true WYSIWYG client for media wiki. To the moment we have a technology
> which should allow us to implement with a good quality and quite fast.
> Unfortunately we are not sure
> if there is a real need/interest for having such kind of client at the
> media wiki world, as well as what are actual needs of media wiki
> users. So we decided to write to this list. Any feedback/suggestion
> will be very helpful.
>
> P.S. Screen cast demonstrating our experimental client for Trac wiki
> http://www.screencast.com/t/MDkzYzM4
>
> Regards,
> Pavel

Yes, of course we are interested on it.
Specifically, the ideal WISIWYG MediaWiki editor would allow easy
WISIWYG editing to newbies, while still allowing to use the full
wikisyntax to power users, without inserting crappy markup when using
it, or reordering everything to its liking when WISIWYG was used to do a
little change.

From the screencast, it seems your technology is based in a local
application instead of web. That's is a little inconvenience for the
users, but an acceptable one IMHO. You could plug your app as an
external editor, see: http://www.mediawiki.org/wiki/Manual:External_editors

The problem that makes this really hard is that MediaWiki syntax is not
nice. So I'm a bit skeptical about that fast quality editor. You can
find in the list archives many discussions about it, and also in wikitext-l.
Things like providing a ribbon is a completely esthetical choice, it
can't really help on the result of its editing. Maybe your backend is
powerful enough to handle this without problems. Please, show me wrong :)


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
On 8/2/10 9:29 AM, Павел Петроченко wrote:
> Hi guys,
>
> At the moment we are discussing an opportunity to create full scale
> true WYSIWYG client for media wiki. To the moment we have a technology
> which should allow us to implement with a good quality and quite fast.
> Unfortunately we are not sure
> if there is a real need/interest for having such kind of client at the
> media wiki world, as well as what are actual needs of media wiki
> users.

Definitely interested.

As for what the needs of MediaWiki users are, you can check out
everything on http://usability.wikimedia.org/ . We are just beginning to
address usability concerns. This study might be interesting to you:

http://usability.wikimedia.org/wiki/Usability_and_Experience_Study


> P.S. Screen cast demonstrating our experimental client for Trac wiki
> http://www.screencast.com/t/MDkzYzM4

That was very interesting. Any chance the rest of us can try it for
ourselves?

I personally like the idea of a ribbon. I think we can assume that most
wiki editors are always going to be novice editors, so taking up
tremendous amounts of space by default to explain things is warranted.
Experts should be able to drop into raw wikitext, or otherwise minimize
the interface.

I don't have an issue with there being a closed source Windows app that
edits wikitext well, but then there is going to be a bit of a difficult
transition from reading to editing and back again.

And just FYI, generally our community is more interested in free and
cross-platform software than proprietary, single platform software.

Still it looks interesting. Please let us know more.

--
Neil Kandalgaonkar (| <neilk@wikimedia.org>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
On Tue, Aug 3, 2010 at 00:49, Platonides <Platonides@gmail.com> wrote:
> The problem that makes this really hard is that MediaWiki syntax is not
> nice. So I'm a bit skeptical about that fast quality editor. You can
> find in the list archives many discussions about it, and also in wikitext-l.
> Things like providing a ribbon is a completely esthetical choice, it
> can't really help on the result of its editing. Maybe your backend is
> powerful enough to handle this without problems. Please, show me wrong :)

I agree, wikitext is notoriously developer-unfriendly. A survey of
currently existing ideas and extensions is on
http://www.mediawiki.org/wiki/WYSIWYG_editor

As a shameless self-promotion, I encourage you to look at
http://www.mediawiki.org/wiki/Extension:MeanEditor for the approach we
took:
1. supporting only a limited subset of wikitext
2. supporting that subset well, leaving a clean history

The rationale here is that supporting all quirks of wikitext adds
little value both for new users (they should not be editing complex
stuff anyways!) and for advanced users (who probably already know
wikitext). I hope this idea can be useful to you.

However, the "editing mode" provided by browsers is a nightmare of
incompatibilities. Basically, each browser produces a different output
given identical commands, so currently MeanEditor is not completely up
to the task. An external application might be an interesting solution.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
On Tue, Aug 3, 2010 at 10:53 AM, Jacopo Corbetta
<jacopo.corbetta@gmail.com> wrote:
> However, the "editing mode" provided by browsers is a nightmare of
> incompatibilities. Basically, each browser produces a different output
> given identical commands, so currently MeanEditor is not completely up
> to the task. An external application might be an interesting solution.

I don't have the link ready, but Google solved this in Google Docs by
re-implementing this in Javascript... they intercept mouse
movements/clicks and keyboard events and then javascript-render the
page.
Given the complexity of wikitext, I fear rewriting the parser in
Javascript is the only way to get a 100% compatible wikitext editor...

Marco

--
VMSoft GbR
Nabburger Str. 15
81737 München
Geschäftsführer: Marco Schuster, Volker Hemmert
http://vmsoft-gbr.de

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
Hi,

>Yes, of course we are interested on it.
>Specifically, the ideal WISIWYG MediaWiki editor would allow easy
>WISIWYG editing to newbies, while still allowing to use the full
>wikisyntax to power users, without inserting crappy markup when using
>it, or reordering everything to its liking when WISIWYG was used to do a
>little change.
Thanks for the note, it may be an important issue.

>From the screencast, it seems your technology is based in a local
>application instead of web. That's is a little inconvenience for the
>users, but an acceptable one IMHO. You could plug your app as an
>external editor, see: http://www.mediawiki.org/wiki/Manual:External_editors

Yep according to my understanding this is major problem, but unfortunately
we are rich client developers, so going web is only in our future plans.
(Actually we are thinking about moving to it, but waiting for a first
customer to help with transition)

On other side being a rich client app may add some benefits for advanced
users, which are still hard
to do in web apps (according to my poor desktop developer understanding).

custom groupings, personal inbox, local for work flow/validation rules and
review. (just as initial examples)

>The problem that makes this really hard is that MediaWiki syntax is not
>nice. So I'm a bit skeptical about that fast quality editor. You can
>find in the list archives many discussions about it, and also in
wikitext-l.
>Things like providing a ribbon is a completely esthetical choice, it
>can't really help on the result of its editing. Maybe your backend is
>powerful enough to handle this without problems. Please, show me wrong :)

Yep - already meet some crap in dealing with it(much more complex than, Trac
wiki one).
But still hope to over helm most of problems, in a couple of month

> I don't have an issue with there being a closed source Windows app that
> edits wikitext well, but then there is going to be a bit of a difficult
> transition from reading to editing and back again.
Yes, this is one of pote

> And just FYI, generally our community is more interested in free and
> cross-platform software than proprietary, single platform software.
Actually we are going to be open source and cross platform (we are Eclipse
RCP based)

> That was very interesting. Any chance the rest of us can try it for
> ourselves?

Our media wiki support is at very early stage now. Actually we are still not
sure how much we are going to be committed into it,
If there will be enough interest (at least couple of volunteer beta
testers), we will start publishing builds somewhere.

Regards,
Pavel
OnPositive Technologies.

2010/8/3 Neil Kandalgaonkar <neilk@wikimedia.org>

> On 8/2/10 9:29 AM, ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ wrote:
>
>> Hi guys,
>>
>> At the moment we are discussing an opportunity to create full scale
>> true WYSIWYG client for media wiki. To the moment we have a technology
>> which should allow us to implement with a good quality and quite fast.
>> Unfortunately we are not sure
>> if there is a real need/interest for having such kind of client at the
>> media wiki world, as well as what are actual needs of media wiki
>> users.
>>
>
> Definitely interested.
>
> As for what the needs of MediaWiki users are, you can check out everything
> on http://usability.wikimedia.org/ . We are just beginning to address
> usability concerns. This study might be interesting to you:
>
> http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
>
>
>
> P.S. Screen cast demonstrating our experimental client for Trac wiki
>> http://www.screencast.com/t/MDkzYzM4
>>
>
> That was very interesting. Any chance the rest of us can try it for
> ourselves?
>
> I personally like the idea of a ribbon. I think we can assume that most
> wiki editors are always going to be novice editors, so taking up tremendous
> amounts of space by default to explain things is warranted. Experts should
> be able to drop into raw wikitext, or otherwise minimize the interface.
>
> I don't have an issue with there being a closed source Windows app that
> edits wikitext well, but then there is going to be a bit of a difficult
> transition from reading to editing and back again.
>
> And just FYI, generally our community is more interested in free and
> cross-platform software than proprietary, single platform software.
>
> Still it looks interesting. Please let us know more.
>
> --
> Neil Kandalgaonkar (| <neilk@wikimedia.org>
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
On 8/3/10 2:18 AM, Marco Schuster wrote:

> I don't have the link ready, but Google solved this in Google Docs by
> re-implementing this in Javascript... they intercept mouse
> movements/clicks and keyboard events and then javascript-render the
> page.

http://googledocs.blogspot.com/2010/05/whats-different-about-new-google-docs.html


--
Neil Kandalgaonkar ( <neilk@wikimedia.org>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
Every time this comes up, I feel compelled to point out that true WYSIWYG has to work with all parser tag extensions. Otherwise, it's not really WYSIWYG.

Jim

On Aug 3, 2010, at 12:25 PM, Neil Kandalgaonkar wrote:

> On 8/3/10 2:18 AM, Marco Schuster wrote:
>
>> I don't have the link ready, but Google solved this in Google Docs by
>> re-implementing this in Javascript... they intercept mouse
>> movements/clicks and keyboard events and then javascript-render the
>> page.
>
> http://googledocs.blogspot.com/2010/05/whats-different-about-new-google-docs.html
>
>
> --
> Neil Kandalgaonkar ( <neilk@wikimedia.org>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

=====================================
Jim Hu
Associate Professor
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
On 3 August 2010 11:18, Marco Schuster <marco@harddisk.is-a-geek.org> wrote:
> On Tue, Aug 3, 2010 at 10:53 AM, Jacopo Corbetta
> <jacopo.corbetta@gmail.com> wrote:
>> However, the "editing mode" provided by browsers is a nightmare of
>> incompatibilities. Basically, each browser produces a different output
>> given identical commands, so currently MeanEditor is not completely up
>> to the task. An external application might be an interesting solution.
>
> I don't have the link ready, but Google solved this in Google Docs by
> re-implementing this in Javascript... they intercept mouse
> movements/clicks and keyboard events and then javascript-render the
> page.
> Given the complexity of wikitext, I fear rewriting the parser in
> Javascript is the only way to get a 100% compatible wikitext editor...

*cracy idea here*

What about compiling PHP for the Flash extension?
http://labs.adobe.com/technologies/alchemy/

Then you can use a modified version of the original PHP files.




--
--
ℱin del ℳensaje.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
> Every time this comes up, I feel compelled to point out that true WYSIWYG has to work with all parser tag extensions.
> Otherwise, it's not really WYSIWYG.

Not to mention, it puts all of the presentation logic in the article
which eliminates the benefits of using CSS. I'd much prefer a Content
Editor that is WDYGITDYG (What Data You Give Is The Data You Get) -
much like Semantic MediaWiki Forms does.

Mark W.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
On Wed, Aug 4, 2010 at 12:05 PM, Mark Wonsil <wonsil@4m-ent.com> wrote:
> Not to mention, it puts all of the presentation logic in the article
> which eliminates the benefits of using CSS.

That is not an inherent characteristic of WYSIWYG. It's true of
WYSIWYG as implemented in, for instance, Microsoft Word, but it
doesn't have to be true of other WYSIWYG systems. The defining
characteristic of WYSIWYG is that while editing the page, it looks the
same as it will be displayed when you save, rather than looking like
plaintext markup while you edit and then looking like rendered
non-plaintext when you save. No one is suggesting that we give users
a menu to change the color or size of text, or do any other purely
presentational thing like that. A WYSIWYG system that we'd use and
support would probably have similar features to the current edit
toolbar -- headers, links, bold, etc.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
Tei wrote:
> On 3 August 2010 11:18, Marco Schuster <marco@harddisk.is-a-geek.org> wrote:
>> I don't have the link ready, but Google solved this in Google Docs by
>> re-implementing this in Javascript... they intercept mouse
>> movements/clicks and keyboard events and then javascript-render the
>> page.
>> Given the complexity of wikitext, I fear rewriting the parser in
>> Javascript is the only way to get a 100% compatible wikitext editor...
>
> *cracy idea here*
>
> What about compiling PHP for the Flash extension?
> http://labs.adobe.com/technologies/alchemy/
>
> Then you can use a modified version of the original PHP files.

That talks about compiling C/C++ to Flash, not PHP to Flash.
Unless you use hip-hop to do PHP->C++, then alchemy for C++ -> Flash...

A really crazy idea :)


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
> Unless you use hip-hop to do PHP->C++, then alchemy for C++ -> Flash...
> A really crazy idea :)

crazy uneducated idea :)

Domas

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
On 8/4/10 2:47 PM, Platonides wrote:
>> What about [various insanity snipped] Flash

On a more serious note: when it comes to Flash on Wikimedia projects,
the WMF board has said no.

In this modern age of HTML5 and so on, I wouldn't ever pick Flash as a
technology the WMF should use going forward, but it could have helped us
with some older browsers.

However, I'm not really complaining -- Flash has way too many issues for
our projects. Even if you accept Adobe's claim to Flash now being an
"open" technology, there are all sorts of other issues. Security,
accessibility, take your pick. Plus it's better for us to put our full
weight behind technologies that we *can* live with long term.

--
Neil Kandalgaonkar ( <neilk@wikimedia.org>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
On Wed, Aug 4, 2010 at 6:10 PM, Neil Kandalgaonkar <neilk@wikimedia.org> wrote:
> On a more serious note: when it comes to Flash on Wikimedia projects,
> the WMF board has said no.

Has it? Where? I think everyone is grudgingly okay for Flash as a
fallback for browsers that don't support standards-based markup . . .
but not if it's the only way to get the functionality.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
On 8/4/10 3:14 PM, Aryeh Gregor wrote:
> On Wed, Aug 4, 2010 at 6:10 PM, Neil Kandalgaonkar<neilk@wikimedia.org> wrote:
>> On a more serious note: when it comes to Flash on Wikimedia projects,
>> the WMF board has said no.
>
> Has it? Where? I think everyone is grudgingly okay for Flash as a
> fallback for browsers that don't support standards-based markup . . .
> but not if it's the only way to get the functionality.

I looked for some sort of meeting minutes before posting, but couldn't
find them. Maybe I don't know where or how to look.

Anyway, this is what I heard from Danese. A few weeks ago Tim Starling
noted that the PLupload library* looked interesting, which falls back to
Flash quite a bit for older browsers. So I tried to figure out if we
could use it (or its approach to things) and started asking around.
Danese and I had a short informal discussion, but it seemed pretty
unambiguous to me, but I could be mistaken.

Danese is on vacation until August 8th, but maybe others have heard this?



[1] PLUpload's model of separating presentation and backend upload
transport is nice, definitely cleaner than ours. But we were doing
something similar anyway. The difference is that we're trying to make
HTML4 really good and then swapping in HTML5/modern browser trickery
when we can, whereas they started with Flash/Silverlight/Gears/HTML5 and
their HTML4 version isn't that good.

--
Neil Kandalgaonkar ( <neilk@wikimedia.org>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
On Wed, Aug 4, 2010 at 11:47 PM, Platonides <Platonides@gmail.com> wrote:
> Tei wrote:
>> What about compiling  PHP for the Flash extension?
>> http://labs.adobe.com/technologies/alchemy/
>>
>> Then you can use a modified version of the original PHP files.
>
> That talks about compiling C/C++ to Flash, not PHP to Flash.
> Unless you use hip-hop to do PHP->C++, then alchemy for C++ -> Flash...

Nope, Tei indeed proposes something nice here... compile the php
interpreter itself in Flash.

Marco
--
VMSoft GbR
Nabburger Str. 15
81737 München
Geschäftsführer: Marco Schuster, Volker Hemmert
http://vmsoft-gbr.de

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
Hi, glad to present our first demo on editing media wiki articles:
http://www.screencast.com/t/NmMzMjVkNjUt
Regards,
Pavel

2010/8/3 ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ <pavel@onpositive.com>

> Hi,
>
>
> >Yes, of course we are interested on it.
> >Specifically, the ideal WISIWYG MediaWiki editor would allow easy
> >WISIWYG editing to newbies, while still allowing to use the full
> >wikisyntax to power users, without inserting crappy markup when using
> >it, or reordering everything to its liking when WISIWYG was used to do a
> >little change.
> Thanks for the note, it may be an important issue.
>
>
> >From the screencast, it seems your technology is based in a local
> >application instead of web. That's is a little inconvenience for the
> >users, but an acceptable one IMHO. You could plug your app as an
> >external editor, see:
> http://www.mediawiki.org/wiki/Manual:External_editors
>
> Yep according to my understanding this is major problem, but unfortunately
> we are rich client developers, so going web is only in our future plans.
> (Actually we are thinking about moving to it, but waiting for a first
> customer to help with transition)
>
> On other side being a rich client app may add some benefits for advanced
> users, which are still hard
> to do in web apps (according to my poor desktop developer understanding).
>
> custom groupings, personal inbox, local for work flow/validation rules and
> review. (just as initial examples)
>
>
> >The problem that makes this really hard is that MediaWiki syntax is not
> >nice. So I'm a bit skeptical about that fast quality editor. You can
> >find in the list archives many discussions about it, and also in
> wikitext-l.
> >Things like providing a ribbon is a completely esthetical choice, it
> >can't really help on the result of its editing. Maybe your backend is
> >powerful enough to handle this without problems. Please, show me wrong :)
>
> Yep - already meet some crap in dealing with it(much more complex than,
> Trac wiki one).
> But still hope to over helm most of problems, in a couple of month
>
>
> > I don't have an issue with there being a closed source Windows app that
> > edits wikitext well, but then there is going to be a bit of a difficult
> > transition from reading to editing and back again.
> Yes, this is one of pote
>
>
> > And just FYI, generally our community is more interested in free and
> > cross-platform software than proprietary, single platform software.
> Actually we are going to be open source and cross platform (we are Eclipse
> RCP based)
>
>
> > That was very interesting. Any chance the rest of us can try it for
> > ourselves?
>
> Our media wiki support is at very early stage now. Actually we are still
> not sure how much we are going to be committed into it,
> If there will be enough interest (at least couple of volunteer beta
> testers), we will start publishing builds somewhere.
>
> Regards,
> Pavel
> OnPositive Technologies.
>
> 2010/8/3 Neil Kandalgaonkar <neilk@wikimedia.org>
>
> On 8/2/10 9:29 AM, ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ wrote:
>>
>>> Hi guys,
>>>
>>> At the moment we are discussing an opportunity to create full scale
>>> true WYSIWYG client for media wiki. To the moment we have a technology
>>> which should allow us to implement with a good quality and quite fast.
>>> Unfortunately we are not sure
>>> if there is a real need/interest for having such kind of client at the
>>> media wiki world, as well as what are actual needs of media wiki
>>> users.
>>>
>>
>> Definitely interested.
>>
>> As for what the needs of MediaWiki users are, you can check out everything
>> on http://usability.wikimedia.org/ . We are just beginning to address
>> usability concerns. This study might be interesting to you:
>>
>> http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
>>
>>
>>
>> P.S. Screen cast demonstrating our experimental client for Trac wiki
>>> http://www.screencast.com/t/MDkzYzM4
>>>
>>
>> That was very interesting. Any chance the rest of us can try it for
>> ourselves?
>>
>> I personally like the idea of a ribbon. I think we can assume that most
>> wiki editors are always going to be novice editors, so taking up tremendous
>> amounts of space by default to explain things is warranted. Experts should
>> be able to drop into raw wikitext, or otherwise minimize the interface.
>>
>> I don't have an issue with there being a closed source Windows app that
>> edits wikitext well, but then there is going to be a bit of a difficult
>> transition from reading to editing and back again.
>>
>> And just FYI, generally our community is more interested in free and
>> cross-platform software than proprietary, single platform software.
>>
>> Still it looks interesting. Please let us know more.
>>
>> --
>> Neil Kandalgaonkar (| <neilk@wikimedia.org>
>>
>
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
Hi,

I sent a mail several months ago on this list to 'advertise' for a
wysiwyg editor for wikipedia. It is still hosted on a server, for
instance if you attempt to edit the page Open_innovation you get that
: http://www.myrilion.com:8080/wysiwyg?article=Open_innovation

The point with this editor that it is fully client based: the wiki
markup is transformed in html on client side, edited as html through a
javascript editor and then transformed back to mediawiki markup on
client side as well.

The code of the translation engine is written in OCaml (www.ocaml.org)
and compiled to javascript.

If anyone here is interested I'll be happy to clean the sources and to
release it as an opensource project.

All the best,

William

2010/8/13 ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ <pavel@onpositive.com>:
> Hi, glad to present our first demo on editing media wiki articles:
> http://www.screencast.com/t/NmMzMjVkNjUt
> Regards,
> Pavel
>
> 2010/8/3 ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ <pavel@onpositive.com>
>
>> Hi,
>>
>>
>> >Yes, of course we are interested on it.
>> >Specifically, the ideal WISIWYG MediaWiki editor would allow easy
>> >WISIWYG editing to newbies, while still allowing to use the full
>> >wikisyntax to power users, without inserting crappy markup when using
>> >it, or reordering everything to its liking when WISIWYG was used to do a
>> >little change.
>> Thanks for the note, it may be an important issue.
>>
>>
>> >From the screencast, it seems your technology is based in a local
>> >application instead of web. That's is a little inconvenience for the
>> >users, but an acceptable one IMHO. You could plug your app as an
>> >external editor, see:
>> http://www.mediawiki.org/wiki/Manual:External_editors
>>
>> Yep according to my understanding this is major problem, but unfortunately
>> we are rich client developers, so going web is only in our future plans.
>> (Actually we are thinking about moving to it, but waiting for a first
>> customer to help with transition)
>>
>> On other side being a rich client app may add some benefits for advanced
>> users, which are still hard
>> to do in web apps (according to my poor desktop developer understanding).
>>
>> custom groupings, personal inbox, local for work flow/validation rules and
>> review. (just as initial examples)
>>
>>
>> >The problem that makes this really hard is that MediaWiki syntax is not
>> >nice. So I'm a bit skeptical about that fast quality editor. You can
>> >find in the list archives many discussions about it, and also in
>> wikitext-l.
>> >Things like providing a ribbon is a completely esthetical choice, it
>> >can't really help on the result of its editing. Maybe your backend is
>> >powerful enough to handle this without problems. Please, show me wrong :)
>>
>> Yep - already meet some crap in dealing with it(much more complex than,
>> Trac wiki one).
>> But still hope to over helm most of problems, in a couple of month
>>
>>
>> > I don't have an issue with there being a closed source Windows app that
>> > edits wikitext well, but then there is going to be a bit of a difficult
>> > transition from reading to editing and back again.
>> Yes, this is one of pote
>>
>>
>> > And just FYI, generally our community is more interested in free and
>> > cross-platform software than proprietary, single platform software.
>> Actually we are going to be open source and cross platform (we are Eclipse
>> RCP based)
>>
>>
>> > That was very interesting. Any chance the rest of us can try it for
>> > ourselves?
>>
>> Our media wiki support is at very early stage now. Actually we are still
>> not sure how much we are going to be committed into it,
>> If there will be enough interest (at least couple of volunteer beta
>> testers), we will start publishing builds somewhere.
>>
>> Regards,
>> Pavel
>> OnPositive Technologies.
>>
>> 2010/8/3 Neil Kandalgaonkar <neilk@wikimedia.org>
>>
>> On 8/2/10 9:29 AM, ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ wrote:
>>>
>>>> Hi guys,
>>>>
>>>> At the moment we are discussing an opportunity to create full scale
>>>> true WYSIWYG client for media wiki. To the moment we have a technology
>>>> which should allow us to implement with a good quality and quite fast.
>>>> Unfortunately we are not sure
>>>> if there is a real need/interest for having such kind of client at the
>>>> media wiki world, as well as what are actual needs of media wiki
>>>> users.
>>>>
>>>
>>> Definitely interested.
>>>
>>> As for what the needs of MediaWiki users are, you can check out everything
>>> on http://usability.wikimedia.org/ . We are just beginning to address
>>> usability concerns. This study might be interesting to you:
>>>
>>> http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
>>>
>>>
>>>
>>> šP.S. Screen cast demonstrating our experimental client for Trac wiki
>>>> http://www.screencast.com/t/MDkzYzM4
>>>>
>>>
>>> That was very interesting. Any chance the rest of us can try it for
>>> ourselves?
>>>
>>> I personally like the idea of a ribbon. I think we can assume that most
>>> wiki editors are always going to be novice editors, so taking up tremendous
>>> amounts of space by default to explain things is warranted. Experts should
>>> be able to drop into raw wikitext, or otherwise minimize the interface.
>>>
>>> I don't have an issue with there being a closed source Windows app that
>>> edits wikitext well, but then there is going to be a bit of a difficult
>>> transition from reading to editing and back again.
>>>
>>> And just FYI, generally our community is more interested in free and
>>> cross-platform software than proprietary, single platform software.
>>>
>>> Still it looks interesting. Please let us know more.
>>>
>>> --
>>> Neil Kandalgaonkar (| š<neilk@wikimedia.org>
>>>
>>
>>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
William Le Ferrand
President

Speed matters : http://www.corefarm.com

Mobile : +33 6 31 27 18 55
LinkedIn : http://www.linkedin.com/in/williamleferrand

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
This looks very interesting.

1. Have you been checking the cleanliness of your diffs?
2. It seems like some of the links which link to a different word
than the label text are being rendered incorrectly. Examples
include "parents" and "joint ventures" in the second paragraph.
3. This page uses an enormous amount of JavaScript code... Even after
combining all 161 JavaScript files, minifying them with JSMin, and
compressing them with GZip, we're looking at 209KB, which is
miraculous when you consider it started out as 2.4MB, but still,
yes, trimming would help. Here's the stats for the files in
various stages.
-- 2408505 bytes (2.4 MB) wysiwyg.combined.js
-- 1136034 bytes (1.1 MB) wysiwyg.combined.min.js
-- 208361 bytes (209 KB) wysiwyg.combined.min.js.gz
4. What's browsers does this work in?
5. What's the performance like in less-modern browsers (if it
supports them) such as any Internet Explorer browser, especially
IE 6 and 7 which have some of the slowest JavaScript interpreters
among the more common browsers.
6. What is your Wikitext > HTML / HTML > wikitext system using to
parse and how much of the document does it understand as opposed
to passively transform? Regex? BNF? Anything particularly cool or
new? Just a port of the existing MediaWiki parser?

Let me also say, thank you for your work in this field, it's a very
important area for research and development to be taking place, both at
the foundation but most importantly in the community.

- Trevor

On 8/13/10 8:27 AM, William Le Ferrand wrote:
> Hi,
>
> I sent a mail several months ago on this list to 'advertise' for a
> wysiwyg editor for wikipedia. It is still hosted on a server, for
> instance if you attempt to edit the page Open_innovation you get that
> : http://www.myrilion.com:8080/wysiwyg?article=Open_innovation
>
> The point with this editor that it is fully client based: the wiki
> markup is transformed in html on client side, edited as html through a
> javascript editor and then transformed back to mediawiki markup on
> client side as well.
>
> The code of the translation engine is written in OCaml (www.ocaml.org)
> and compiled to javascript.
>
> If anyone here is interested I'll be happy to clean the sources and to
> release it as an opensource project.
>
> All the best,
>
> William
>
> 2010/8/13 ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ<pavel@onpositive.com>:
>> Hi, glad to present our first demo on editing media wiki articles:
>> http://www.screencast.com/t/NmMzMjVkNjUt
>> Regards,
>> Pavel
>>
>> 2010/8/3 ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ<pavel@onpositive.com>
>>
>>> Hi,
>>>
>>>
>>>> Yes, of course we are interested on it.
>>>> Specifically, the ideal WISIWYG MediaWiki editor would allow easy
>>>> WISIWYG editing to newbies, while still allowing to use the full
>>>> wikisyntax to power users, without inserting crappy markup when using
>>>> it, or reordering everything to its liking when WISIWYG was used to do a
>>>> little change.
>>> Thanks for the note, it may be an important issue.
>>>
>>>
>>> > From the screencast, it seems your technology is based in a local
>>>> application instead of web. That's is a little inconvenience for the
>>>> users, but an acceptable one IMHO. You could plug your app as an
>>>> external editor, see:
>>> http://www.mediawiki.org/wiki/Manual:External_editors
>>>
>>> Yep according to my understanding this is major problem, but unfortunately
>>> we are rich client developers, so going web is only in our future plans.
>>> (Actually we are thinking about moving to it, but waiting for a first
>>> customer to help with transition)
>>>
>>> On other side being a rich client app may add some benefits for advanced
>>> users, which are still hard
>>> to do in web apps (according to my poor desktop developer understanding).
>>>
>>> custom groupings, personal inbox, local for work flow/validation rules and
>>> review. (just as initial examples)
>>>
>>>
>>>> The problem that makes this really hard is that MediaWiki syntax is not
>>>> nice. So I'm a bit skeptical about that fast quality editor. You can
>>>> find in the list archives many discussions about it, and also in
>>> wikitext-l.
>>>> Things like providing a ribbon is a completely esthetical choice, it
>>>> can't really help on the result of its editing. Maybe your backend is
>>>> powerful enough to handle this without problems. Please, show me wrong :)
>>> Yep - already meet some crap in dealing with it(much more complex than,
>>> Trac wiki one).
>>> But still hope to over helm most of problems, in a couple of month
>>>
>>>
>>>> I don't have an issue with there being a closed source Windows app that
>>>> edits wikitext well, but then there is going to be a bit of a difficult
>>>> transition from reading to editing and back again.
>>> Yes, this is one of pote
>>>
>>>
>>>> And just FYI, generally our community is more interested in free and
>>>> cross-platform software than proprietary, single platform software.
>>> Actually we are going to be open source and cross platform (we are Eclipse
>>> RCP based)
>>>
>>>
>>>> That was very interesting. Any chance the rest of us can try it for
>>>> ourselves?
>>> Our media wiki support is at very early stage now. Actually we are still
>>> not sure how much we are going to be committed into it,
>>> If there will be enough interest (at least couple of volunteer beta
>>> testers), we will start publishing builds somewhere.
>>>
>>> Regards,
>>> Pavel
>>> OnPositive Technologies.
>>>
>>> 2010/8/3 Neil Kandalgaonkar<neilk@wikimedia.org>
>>>
>>> On 8/2/10 9:29 AM, ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ wrote:
>>>>> Hi guys,
>>>>>
>>>>> At the moment we are discussing an opportunity to create full scale
>>>>> true WYSIWYG client for media wiki. To the moment we have a technology
>>>>> which should allow us to implement with a good quality and quite fast.
>>>>> Unfortunately we are not sure
>>>>> if there is a real need/interest for having such kind of client at the
>>>>> media wiki world, as well as what are actual needs of media wiki
>>>>> users.
>>>>>
>>>> Definitely interested.
>>>>
>>>> As for what the needs of MediaWiki users are, you can check out everything
>>>> on http://usability.wikimedia.org/ . We are just beginning to address
>>>> usability concerns. This study might be interesting to you:
>>>>
>>>> http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
>>>>
>>>>
>>>>
>>>> P.S. Screen cast demonstrating our experimental client for Trac wiki
>>>>> http://www.screencast.com/t/MDkzYzM4
>>>>>
>>>> That was very interesting. Any chance the rest of us can try it for
>>>> ourselves?
>>>>
>>>> I personally like the idea of a ribbon. I think we can assume that most
>>>> wiki editors are always going to be novice editors, so taking up tremendous
>>>> amounts of space by default to explain things is warranted. Experts should
>>>> be able to drop into raw wikitext, or otherwise minimize the interface.
>>>>
>>>> I don't have an issue with there being a closed source Windows app that
>>>> edits wikitext well, but then there is going to be a bit of a difficult
>>>> transition from reading to editing and back again.
>>>>
>>>> And just FYI, generally our community is more interested in free and
>>>> cross-platform software than proprietary, single platform software.
>>>>
>>>> Still it looks interesting. Please let us know more.
>>>>
>>>> --
>>>> Neil Kandalgaonkar (|<neilk@wikimedia.org>
>>>>
>>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
Hi Trevor,

Thanks for the reply! Actually I wrote this code for fun a few months
ago; the core is done but there is still a lot of room for
improvements ;)

I'm using a functional language called OCaml (www.ocaml.org). Have you
ever heard of it?

It comes with several fancy tools; I used ocamllex to generate the
lexer; and a custom parser to cope with the grammar. I didn't reused
any line of the mediawiki parser, it is entirely written from scratch
in pure ocaml. The ocaml code is compiled to javascript to get the js
code you can see on the website. Using those tools, I've been able to
set up a rather complicated program in js that I couldn't have written
in a non typed language. (but perhaps because I'm a bad js
programmer..)

About your questions:

1) No, I haven't check that. It is a very important issue, but if the
current result is not correct it should be a matter of fixing a few
bugs here and there, not a global design issue.

2) Yes, this case is not correctly handled. One more time, I didn't
spent too much time on this, even if I'd love to !

3) Ah, perhaps, yes. This js is autogenerated. A friend of mine
released a new ocaml->js compiler ( available from www.ocsigen.org ),
perhaps his compiler will produce more compact code.

4,5) I only tested on safari and chrome where the preformance is
actually quite good. Of course, the computations that were originally
handled by the server have to be done by the browser, so it is slower;
but with this method there is less load on the server (at least I
believe so), the load is distributed to the users; it is a nice scheme
for a community project isn't it ;)?

5) Well, the best should probably that you have a look to the source
code. I can put it on github if you want; would you be interested? Is
there an ocaml developer on the list that could give his opinion about
the global process ?

Thanks !

William






2010/8/13 Trevor Parscal <tparscal@wikimedia.org>:
> šThis looks very interesting.
>
> š 1. Have you been checking the cleanliness of your diffs?
> š 2. It seems like some of the links which link to a different word
> š š šthan the label text are being rendered incorrectly. Examples
> š š šinclude "parents" and "joint ventures" in the second paragraph.
> š 3. This page uses an enormous amount of JavaScript code... Even after
> š š šcombining all 161 JavaScript files, minifying them with JSMin, and
> š š šcompressing them with GZip, we're looking at 209KB, which is
> š š šmiraculous when you consider it started out as 2.4MB, but still,
> š š šyes, trimming would help. Here's the stats for the files in
> š š švarious stages.
> š š š-- 2408505 bytes (2.4 MB) wysiwyg.combined.js
> š š š-- 1136034 bytes (1.1 MB) wysiwyg.combined.min.js
> š š š-- 208361 bytes (209 KB) wysiwyg.combined.min.js.gz
> š 4. What's browsers does this work in?
> š 5. What's the performance like in less-modern browsers (if it
> š š šsupports them) such as any Internet Explorer browser, especially
> š š šIE 6 and 7 which have some of the slowest JavaScript interpreters
> š š šamong the more common browsers.
> š 6. What is your Wikitext > HTML / HTML > wikitext system using to
> š š šparse and how much of the document does it understand as opposed
> š š što passively transform? Regex? BNF? Anything particularly cool or
> š š šnew? Just a port of the existing MediaWiki parser?
>
> Let me also say, thank you for your work in this field, it's a very
> important area for research and development to be taking place, both at
> the foundation but most importantly in the community.
>
> - Trevor
>
> On 8/13/10 8:27 AM, William Le Ferrand wrote:
>> Hi,
>>
>> I sent a mail several months ago on this list to 'advertise' for a
>> wysiwyg editor for wikipedia. It is still hosted on a server, for
>> instance if you attempt to edit the page Open_innovation you get that
>> : šhttp://www.myrilion.com:8080/wysiwyg?article=Open_innovation
>>
>> The point with this editor that it is fully client based: the wiki
>> markup is transformed in html on client side, edited as html through a
>> javascript editor and then transformed back to mediawiki markup on
>> client side as well.
>>
>> The code of the translation engine is written in OCaml (www.ocaml.org)
>> and compiled to javascript.
>>
>> If anyone here is interested I'll be happy to clean the sources and to
>> release it as an opensource project.
>>
>> All the best,
>>
>> William
>>
>> 2010/8/13 ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ<pavel@onpositive.com>:
>>> Hi, glad to present our first demo on editing media wiki articles:
>>> http://www.screencast.com/t/NmMzMjVkNjUt
>>> Regards,
>>> Pavel
>>>
>>> 2010/8/3 ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ<pavel@onpositive.com>
>>>
>>>> Hi,
>>>>
>>>>
>>>>> Yes, of course we are interested on it.
>>>>> Specifically, the ideal WISIWYG MediaWiki editor would allow easy
>>>>> WISIWYG editing to newbies, while still allowing to use the full
>>>>> wikisyntax to power users, without inserting crappy markup when using
>>>>> it, or reordering everything to its liking when WISIWYG was used to do a
>>>>> little change.
>>>> Thanks for the note, it may be an important issue.
>>>>
>>>>
>>>> > From the screencast, it seems your technology is based in a local
>>>>> application instead of web. That's is a little inconvenience for the
>>>>> users, but an acceptable one IMHO. You could plug your app as an
>>>>> external editor, see:
>>>> http://www.mediawiki.org/wiki/Manual:External_editors
>>>>
>>>> Yep according to my understanding this is major problem, but unfortunately
>>>> we are rich client developers, so going web is only in our future plans.
>>>> (Actually we are thinking about moving to it, but waiting for a first
>>>> customer to help with transition)
>>>>
>>>> On other side being a rich client app may add some benefits for advanced
>>>> users, which are still hard
>>>> to do in web apps (according to my poor desktop developer understanding).
>>>>
>>>> custom groupings, personal inbox, local for work flow/validation rules and
>>>> review. (just as initial examples)
>>>>
>>>>
>>>>> The problem that makes this really hard is that MediaWiki syntax is not
>>>>> nice. So I'm a bit skeptical about that fast quality editor. You can
>>>>> find in the list archives many discussions about it, and also in
>>>> wikitext-l.
>>>>> Things like providing a ribbon is a completely esthetical choice, it
>>>>> can't really help on the result of its editing. Maybe your backend is
>>>>> powerful enough to handle this without problems. Please, show me wrong :)
>>>> Yep - already meet some crap in dealing with it(much more complex than,
>>>> Trac wiki one).
>>>> But still hope to over helm most of problems, in a couple of month
>>>>
>>>>
>>>>> I don't have an issue with there being a closed source Windows app that
>>>>> edits wikitext well, but then there is going to be a bit of a difficult
>>>>> transition from reading to editing and back again.
>>>> Yes, this is one of pote
>>>>
>>>>
>>>>> And just FYI, generally our community is more interested in free and
>>>>> cross-platform software than proprietary, single platform software.
>>>> Actually we are going to be open source and cross platform (we are Eclipse
>>>> RCP based)
>>>>
>>>>
>>>>> That was very interesting. Any chance the rest of us can try it for
>>>>> ourselves?
>>>> Our media wiki support is at very early stage now. Actually we are still
>>>> not sure how much we are going to be committed into it,
>>>> If there will be enough interest (at least couple of volunteer beta
>>>> testers), we will start publishing builds somewhere.
>>>>
>>>> Regards,
>>>> Pavel
>>>> OnPositive Technologies.
>>>>
>>>> 2010/8/3 Neil Kandalgaonkar<neilk@wikimedia.org>
>>>>
>>>> On 8/2/10 9:29 AM, ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> At the moment we are discussing an opportunity to create full scale
>>>>>> true WYSIWYG client for media wiki. To the moment we have a technology
>>>>>> which should allow us to implement with a good quality and quite fast.
>>>>>> Unfortunately we are not sure
>>>>>> if there is a real need/interest for having such kind of client at the
>>>>>> media wiki world, as well as what are actual needs of media wiki
>>>>>> users.
>>>>>>
>>>>> Definitely interested.
>>>>>
>>>>> As for what the needs of MediaWiki users are, you can check out everything
>>>>> on http://usability.wikimedia.org/ . We are just beginning to address
>>>>> usability concerns. This study might be interesting to you:
>>>>>
>>>>> http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
>>>>>
>>>>>
>>>>>
>>>>> š P.S. Screen cast demonstrating our experimental client for Trac wiki
>>>>>> http://www.screencast.com/t/MDkzYzM4
>>>>>>
>>>>> That was very interesting. Any chance the rest of us can try it for
>>>>> ourselves?
>>>>>
>>>>> I personally like the idea of a ribbon. I think we can assume that most
>>>>> wiki editors are always going to be novice editors, so taking up tremendous
>>>>> amounts of space by default to explain things is warranted. Experts should
>>>>> be able to drop into raw wikitext, or otherwise minimize the interface.
>>>>>
>>>>> I don't have an issue with there being a closed source Windows app that
>>>>> edits wikitext well, but then there is going to be a bit of a difficult
>>>>> transition from reading to editing and back again.
>>>>>
>>>>> And just FYI, generally our community is more interested in free and
>>>>> cross-platform software than proprietary, single platform software.
>>>>>
>>>>> Still it looks interesting. Please let us know more.
>>>>>
>>>>> --
>>>>> Neil Kandalgaonkar (|<neilk@wikimedia.org>
>>>>>
>>>>
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
William Le Ferrand
President

Speed matters : http://www.corefarm.com

Mobile : +33 6 31 27 18 55
LinkedIn : http://www.linkedin.com/in/williamleferrand

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
2010/8/13 William Le Ferrand <william@corefarm.com>:

> I'm using a functional language called OCaml (www.ocaml.org). Have you
> ever heard of it?


Our math extensions for displaying TeX use it. In fact, they've been
languishing for a lack of OCaml programmers ...


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
Very exciting work, thanks for the quality responses.

I'm not an OCaml programmer, so I'd likely be useless in giving input -
but open-sourcing it and putting the code in a repository is always a
good way to find people who are and to get them involved.

- Trevor

On 8/13/10 12:19 PM, William Le Ferrand wrote:
> Hi Trevor,
>
> Thanks for the reply! Actually I wrote this code for fun a few months
> ago; the core is done but there is still a lot of room for
> improvements ;)
>
> I'm using a functional language called OCaml (www.ocaml.org). Have you
> ever heard of it?
>
> It comes with several fancy tools; I used ocamllex to generate the
> lexer; and a custom parser to cope with the grammar. I didn't reused
> any line of the mediawiki parser, it is entirely written from scratch
> in pure ocaml. The ocaml code is compiled to javascript to get the js
> code you can see on the website. Using those tools, I've been able to
> set up a rather complicated program in js that I couldn't have written
> in a non typed language. (but perhaps because I'm a bad js
> programmer..)
>
> About your questions:
>
> 1) No, I haven't check that. It is a very important issue, but if the
> current result is not correct it should be a matter of fixing a few
> bugs here and there, not a global design issue.
>
> 2) Yes, this case is not correctly handled. One more time, I didn't
> spent too much time on this, even if I'd love to !
>
> 3) Ah, perhaps, yes. This js is autogenerated. A friend of mine
> released a new ocaml->js compiler ( available from www.ocsigen.org ),
> perhaps his compiler will produce more compact code.
>
> 4,5) I only tested on safari and chrome where the preformance is
> actually quite good. Of course, the computations that were originally
> handled by the server have to be done by the browser, so it is slower;
> but with this method there is less load on the server (at least I
> believe so), the load is distributed to the users; it is a nice scheme
> for a community project isn't it ;)?
>
> 5) Well, the best should probably that you have a look to the source
> code. I can put it on github if you want; would you be interested? Is
> there an ocaml developer on the list that could give his opinion about
> the global process ?
>
> Thanks !
>
> William
>
>
>
>
>
>
> 2010/8/13 Trevor Parscal<tparscal@wikimedia.org>:
>> This looks very interesting.
>>
>> 1. Have you been checking the cleanliness of your diffs?
>> 2. It seems like some of the links which link to a different word
>> than the label text are being rendered incorrectly. Examples
>> include "parents" and "joint ventures" in the second paragraph.
>> 3. This page uses an enormous amount of JavaScript code... Even after
>> combining all 161 JavaScript files, minifying them with JSMin, and
>> compressing them with GZip, we're looking at 209KB, which is
>> miraculous when you consider it started out as 2.4MB, but still,
>> yes, trimming would help. Here's the stats for the files in
>> various stages.
>> -- 2408505 bytes (2.4 MB) wysiwyg.combined.js
>> -- 1136034 bytes (1.1 MB) wysiwyg.combined.min.js
>> -- 208361 bytes (209 KB) wysiwyg.combined.min.js.gz
>> 4. What's browsers does this work in?
>> 5. What's the performance like in less-modern browsers (if it
>> supports them) such as any Internet Explorer browser, especially
>> IE 6 and 7 which have some of the slowest JavaScript interpreters
>> among the more common browsers.
>> 6. What is your Wikitext> HTML / HTML> wikitext system using to
>> parse and how much of the document does it understand as opposed
>> to passively transform? Regex? BNF? Anything particularly cool or
>> new? Just a port of the existing MediaWiki parser?
>>
>> Let me also say, thank you for your work in this field, it's a very
>> important area for research and development to be taking place, both at
>> the foundation but most importantly in the community.
>>
>> - Trevor
>>
>> On 8/13/10 8:27 AM, William Le Ferrand wrote:
>>> Hi,
>>>
>>> I sent a mail several months ago on this list to 'advertise' for a
>>> wysiwyg editor for wikipedia. It is still hosted on a server, for
>>> instance if you attempt to edit the page Open_innovation you get that
>>> : http://www.myrilion.com:8080/wysiwyg?article=Open_innovation
>>>
>>> The point with this editor that it is fully client based: the wiki
>>> markup is transformed in html on client side, edited as html through a
>>> javascript editor and then transformed back to mediawiki markup on
>>> client side as well.
>>>
>>> The code of the translation engine is written in OCaml (www.ocaml.org)
>>> and compiled to javascript.
>>>
>>> If anyone here is interested I'll be happy to clean the sources and to
>>> release it as an opensource project.
>>>
>>> All the best,
>>>
>>> William
>>>
>>> 2010/8/13 ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ<pavel@onpositive.com>:
>>>> Hi, glad to present our first demo on editing media wiki articles:
>>>> http://www.screencast.com/t/NmMzMjVkNjUt
>>>> Regards,
>>>> Pavel
>>>>
>>>> 2010/8/3 ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ<pavel@onpositive.com>
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>> Yes, of course we are interested on it.
>>>>>> Specifically, the ideal WISIWYG MediaWiki editor would allow easy
>>>>>> WISIWYG editing to newbies, while still allowing to use the full
>>>>>> wikisyntax to power users, without inserting crappy markup when using
>>>>>> it, or reordering everything to its liking when WISIWYG was used to do a
>>>>>> little change.
>>>>> Thanks for the note, it may be an important issue.
>>>>>
>>>>>
>>>>>> From the screencast, it seems your technology is based in a local
>>>>>> application instead of web. That's is a little inconvenience for the
>>>>>> users, but an acceptable one IMHO. You could plug your app as an
>>>>>> external editor, see:
>>>>> http://www.mediawiki.org/wiki/Manual:External_editors
>>>>>
>>>>> Yep according to my understanding this is major problem, but unfortunately
>>>>> we are rich client developers, so going web is only in our future plans.
>>>>> (Actually we are thinking about moving to it, but waiting for a first
>>>>> customer to help with transition)
>>>>>
>>>>> On other side being a rich client app may add some benefits for advanced
>>>>> users, which are still hard
>>>>> to do in web apps (according to my poor desktop developer understanding).
>>>>>
>>>>> custom groupings, personal inbox, local for work flow/validation rules and
>>>>> review. (just as initial examples)
>>>>>
>>>>>
>>>>>> The problem that makes this really hard is that MediaWiki syntax is not
>>>>>> nice. So I'm a bit skeptical about that fast quality editor. You can
>>>>>> find in the list archives many discussions about it, and also in
>>>>> wikitext-l.
>>>>>> Things like providing a ribbon is a completely esthetical choice, it
>>>>>> can't really help on the result of its editing. Maybe your backend is
>>>>>> powerful enough to handle this without problems. Please, show me wrong :)
>>>>> Yep - already meet some crap in dealing with it(much more complex than,
>>>>> Trac wiki one).
>>>>> But still hope to over helm most of problems, in a couple of month
>>>>>
>>>>>
>>>>>> I don't have an issue with there being a closed source Windows app that
>>>>>> edits wikitext well, but then there is going to be a bit of a difficult
>>>>>> transition from reading to editing and back again.
>>>>> Yes, this is one of pote
>>>>>
>>>>>
>>>>>> And just FYI, generally our community is more interested in free and
>>>>>> cross-platform software than proprietary, single platform software.
>>>>> Actually we are going to be open source and cross platform (we are Eclipse
>>>>> RCP based)
>>>>>
>>>>>
>>>>>> That was very interesting. Any chance the rest of us can try it for
>>>>>> ourselves?
>>>>> Our media wiki support is at very early stage now. Actually we are still
>>>>> not sure how much we are going to be committed into it,
>>>>> If there will be enough interest (at least couple of volunteer beta
>>>>> testers), we will start publishing builds somewhere.
>>>>>
>>>>> Regards,
>>>>> Pavel
>>>>> OnPositive Technologies.
>>>>>
>>>>> 2010/8/3 Neil Kandalgaonkar<neilk@wikimedia.org>
>>>>>
>>>>> On 8/2/10 9:29 AM, ðÁ×ÅÌ ðÅÔÒÏÞÅÎËÏ wrote:
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> At the moment we are discussing an opportunity to create full scale
>>>>>>> true WYSIWYG client for media wiki. To the moment we have a technology
>>>>>>> which should allow us to implement with a good quality and quite fast.
>>>>>>> Unfortunately we are not sure
>>>>>>> if there is a real need/interest for having such kind of client at the
>>>>>>> media wiki world, as well as what are actual needs of media wiki
>>>>>>> users.
>>>>>>>
>>>>>> Definitely interested.
>>>>>>
>>>>>> As for what the needs of MediaWiki users are, you can check out everything
>>>>>> on http://usability.wikimedia.org/ . We are just beginning to address
>>>>>> usability concerns. This study might be interesting to you:
>>>>>>
>>>>>> http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
>>>>>>
>>>>>>
>>>>>>
>>>>>> P.S. Screen cast demonstrating our experimental client for Trac wiki
>>>>>>> http://www.screencast.com/t/MDkzYzM4
>>>>>>>
>>>>>> That was very interesting. Any chance the rest of us can try it for
>>>>>> ourselves?
>>>>>>
>>>>>> I personally like the idea of a ribbon. I think we can assume that most
>>>>>> wiki editors are always going to be novice editors, so taking up tremendous
>>>>>> amounts of space by default to explain things is warranted. Experts should
>>>>>> be able to drop into raw wikitext, or otherwise minimize the interface.
>>>>>>
>>>>>> I don't have an issue with there being a closed source Windows app that
>>>>>> edits wikitext well, but then there is going to be a bit of a difficult
>>>>>> transition from reading to editing and back again.
>>>>>>
>>>>>> And just FYI, generally our community is more interested in free and
>>>>>> cross-platform software than proprietary, single platform software.
>>>>>>
>>>>>> Still it looks interesting. Please let us know more.
>>>>>>
>>>>>> --
>>>>>> Neil Kandalgaonkar (|<neilk@wikimedia.org>
>>>>>>
>>>> _______________________________________________
>>>> Wikitech-l mailing list
>>>> Wikitech-l@lists.wikimedia.org
>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
2010/8/13 Trevor Parscal <tparscal@wikimedia.org>:

> I'm not an OCaml programmer, so I'd likely be useless in giving input -
> but open-sourcing it and putting the code in a repository is always a
> good way to find people who are and to get them involved.


Particularly with such a desirable functionality as this.


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Developing true WISIWYG editor for media wiki [ In reply to ]
2010/8/13 William Le Ferrand <william@corefarm.com>:
> 1) No, I haven't check that. It is a very important issue, but if the
> current result is not correct it should be a matter of fixing a few
> bugs here and there, not a global design issue.
>
There is a very fundamental issue with converting wikitext to HTML,
then back, which is that there are multiple wikitext alternatives that
produce the same HTML: [[Foo]] and [[Foo|Foo]] for instance. Earlier
versions of FCKeditor used to 'normalize' all links looking like
[[Foo]] to [[Foo|Foo]], which resulted absolutely hideous diffs that
were nigh impossible to review because the actual changes got buried
in lots of link 'normalizations'. This is what Trevor is talking about
when he asks about the "cleanliness of your diffs".

I believe this particular bug was fixed, but the general point stands:
you need to somehow remember things about the wikitext that went in in
order to have a chance to get it back relatively unscathed. I
personally believe that the round-trip approach is fundamentally
flawed and that you should have some internal representation (not
HTML) closely connected to the wikitext in which you track changes,
but that's just my personal conviction and I'm not aware of any
successful editors built this way.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 2  View All