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 Павел Петроченко<[email protected]>:
>> Hi, glad to present our first demo on editing media wiki articles:
>> http://www.screencast.com/t/NmMzMjVkNjUt
>> Regards,
>> Pavel
>>
>> 2010/8/3 Павел Петроченко<[email protected]>
>>
>>> 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<[email protected]>
>>>
>>> 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 (|<[email protected]>
>>>>
>>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [email protected]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
