Happy new year all!
Let me welcome you to this historical year (10 years of Wikipedia! Wow!) with a working demo of WYSIWTF, a pure JavaScript attempt at (pseudo-) WYSIWYG wikipedia editing.
For the impatient, add
document.write('<script type="text/javascript" src="http://toolserver.org/~magnus/wysiwtf/wysiwtf.js"></script>');
to your vector.js, force-reload, and try any article, User, or Wikipedia namespace page. Click the WYSIWTF tab, edit, and save (yes, it does save. You are responsible for cleaning up if you make a mess ;-) (I invite you to try my test article at http://en.wikipedia.org/wiki/User:Magnus_Manske/test )
Now, this is not "real" WYSIWYG, but rather what I'd call "augmented wikitext". You still edit wikitext, but some elements (headings, links, images, and yes, template) are HTML-rendered for convenience. Large templates are collapsed into the template name; double-click it to show/hide the vast sea of parameters, which you then can edit like normal wikitext. Likewise, double-click links or images to get (currently quite limited) properties.
For this to work, wikitext is parsed into "augmented wikitext", which is then edited, and rewritten to normal wikitext upon save. Therefore, you can still enter wikitext directly, and it will "just work" (TM), except it won't show directly in its rendered form in the editor. Likewise, lots of wikitext markup is currently not parsed into an augmented form; bold/italics, lists, and tables, among others, are left untouched. I can do only so much for a demo :-)
The editor component is by far the weakest part of this demo. I looked at CKedit, but it seemed too much work to adapt it for a demo than to write my own editor, which I then did. To make my life easier, each wikitext character (!) is its own <span> element, which might tax your browser. Medium-sized articles work fine in Chrome on my MacBook Pro, but YMMV. You can click into the text to position the cursor, move it left and right with the cursor keys (not up or down!), type text, delete or backspace, and use Enter for new line. That's it. No text selection, not bold/italics buttons, no undo. All of which is entirely feasible, but too much work for this demo.
Some things can't be done with the demo right now, such as changing a template name, or resizing an image. Again, no technical reason, just a man-hour one. You will certainly find many ways to break it, and instances where it fails (correctly discerning whether and image if local or from Commons is one).
What I would like is some discussion about * if this approach (working pseudo-WYSIWYG instead of unattainable perfect WYSIWYG) is the way to go * if the code I wrote would be a suitable basis for a system we can throw at the general public * if anyone is willing to help me with that
As always, my code is GPL, and I would be more than happy if, in the end, it would become "official" Foundation code, with staff that supports it. Well, I can dream...
Cheers, Magnus
What I would like is some discussion about
- if this approach (working pseudo-WYSIWYG instead of unattainable
perfect WYSIWYG) is the way to go
- if the code I wrote would be a suitable basis for a system we can
throw at the general public
- if anyone is willing to help me with that
As always, my code is GPL, and I would be more than happy if, in the end, it would become "official" Foundation code, with staff that supports it. Well, I can dream...
You seem to want to do exactly the same thing as I'm doing, but in the browser only! Maybe you're interested in looking at http://janpaulposma.nl/sle/wiki, http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing, http://lists.wikimedia.org/pipermail/wikitech-l/2010-October/050031.html and http://commons.wikimedia.org/wiki/Category:Sentence-level_editing
Anyway, I have also looked at doing parsing in the browser, which is quite interesting. WikiBasha also uses JS parsing, so maybe it's a good idea to look at that too. Trevor also made a JS parser, but I think it's not in SVN (yet).
Regards, Jan Paul
On 1 January 2011 12:50, Magnus Manske magnusmanske@googlemail.com wrote:
What I would like is some discussion about
- if this approach (working pseudo-WYSIWYG instead of unattainable
perfect WYSIWYG) is the way to go
The question is: can it be incrementally improved, new tags and ways to deal with them etc, added as we go? Is it structured to make that a reasonably straightforward thing to do?
- d.
On Sat, Jan 1, 2011 at 3:43 PM, David Gerard dgerard@gmail.com wrote:
On 1 January 2011 12:50, Magnus Manske magnusmanske@googlemail.com wrote:
What I would like is some discussion about
- if this approach (working pseudo-WYSIWYG instead of unattainable
perfect WYSIWYG) is the way to go
The question is: can it be incrementally improved, new tags and ways to deal with them etc, added as we go? Is it structured to make that a reasonably straightforward thing to do?
I believe so, both for the parsing, where I actually have boolean flags in the JavaScript to turn off, say, image parsing, which will then just be rendered as wikitext, as well as for the display, where the possibility of marrying my code to, say, the Usability Initiative's template editor or multimedia assistant, has not escaped me :-)
An easy example will be external links, which I just might implement later today. Lists should be possible, tables a bit harder. HTML-like tags, including <nowiki> and <ref>, are on the to-do-list, obviously. Especially <ref>s could be collapsed like templates, which would again improve readability significantly IMHO.
So, yes, I think this can deal with more current and future wiki markup - no matter how complicated, it can catch the "safe" instances, and just default to plain wikitext when in doubt.
Cheers, Magnus
On Sat, Jan 1, 2011 at 1:50 PM, Magnus Manske magnusmanske@googlemail.com wrote:
What I would like is some discussion about
- if this approach (working pseudo-WYSIWYG instead of unattainable
perfect WYSIWYG) is the way to go
- if the code I wrote would be a suitable basis for a system we can
throw at the general public
- if anyone is willing to help me with that
I love it and for the sake of demonstration the deep impact of the approach, I recommend one minor change:
* deactivate or hide or shrink the "read" and "edit" tab as they are now obsolete or make the WYSIWTF tab the default display.
Mathias
----- Original Message -----
From: "Mathias Schindler" mathias.schindler@gmail.com To: "Wikimedia developers" wikitech-l@lists.wikimedia.org Sent: Saturday, January 1, 2011 10:34:00 AM Subject: Re: [Wikitech-l] WYSIWTF working demo On Sat, Jan 1, 2011 at 1:50 PM, Magnus Manske magnusmanske@googlemail.com wrote:
What I would like is some discussion about
- if this approach (working pseudo-WYSIWYG instead of unattainable
perfect WYSIWYG) is the way to go
- if the code I wrote would be a suitable basis for a system we can
throw at the general public
- if anyone is willing to help me with that
I love it and for the sake of demonstration the deep impact of the approach, I recommend one minor change:
- deactivate or hide or shrink the "read" and "edit" tab as they are
now obsolete or make the WYSIWTF tab the default display.
Are like hell.
Some people -- you can include me in this -- *actively* hate WYSIWYG editing, thank-you-very-much. Good bet at least 30-50% of Wikipedia's "power editors" are very well versed in MWtext[1], and how to use it to get what they want; I wouldn't recommend making it hard for those people to keep doing what they've been doing.
Cheers, -- jra
[1] Yes, I've just made that statistic up, but I expect it will track with other similar statistics.
----- Original Message -----
From: "Mathias Schindler" mathias.schindler@gmail.com To: "Wikimedia developers" wikitech-l@lists.wikimedia.org Sent: Saturday, January 1, 2011 10:34:00 AM Subject: Re: [Wikitech-l] WYSIWTF working demo On Sat, Jan 1, 2011 at 1:50 PM, Magnus Manske magnusmanske@googlemail.com wrote:
What I would like is some discussion about
- if this approach (working pseudo-WYSIWYG instead of unattainable
perfect WYSIWYG) is the way to go
- if the code I wrote would be a suitable basis for a system we can
throw at the general public
- if anyone is willing to help me with that
I love it and for the sake of demonstration the deep impact of the approach, I recommend one minor change:
- deactivate or hide or shrink the "read" and "edit" tab as they are
now obsolete or make the WYSIWTF tab the default display.
Are like hell.
Some people -- you can include me in this -- *actively* hate WYSIWYG editing, thank-you-very-much. Good bet at least 30-50% of Wikipedia's "power editors" are very well versed in MWtext[1], and how to use it to get what they want; I wouldn't recommend making it hard for those people to keep doing what they've been doing.
Cheers, -- jra
[1] Yes, I've just made that statistic up, but I expect it will track with other similar statistics.
I'll admit to hating Wikia's new system, but so far this looks interesting.
Even there though you don't have to select it.
Fred Bauder
On Sat, Jan 1, 2011 at 4:49 PM, Jay Ashworth jra@baylink.com wrote:
Some people -- you can include me in this -- *actively* hate WYSIWYG editing,
my comment was in no way about the pros and cons of WYSIWYG editing and the decision at Wikimedia to have its own turing complete language for content. My comment was about this demonstrator which should have a huge selection bias of non-haters :)
I reject the WYSIWYG concept itself much less then I dislike the effects it has on humans who start to "make things look nice".
----- Original Message -----
From: "Mathias Schindler" mathias.schindler@gmail.com
On Sat, Jan 1, 2011 at 4:49 PM, Jay Ashworth jra@baylink.com wrote:
Some people -- you can include me in this -- *actively* hate WYSIWYG editing,
my comment was in no way about the pros and cons of WYSIWYG editing and the decision at Wikimedia to have its own turing complete language for content. My comment was about this demonstrator which should have a huge selection bias of non-haters :)
I reject the WYSIWYG concept itself much less then I dislike the effects it has on humans who start to "make things look nice".
Oh: you were suggesting that *his demonstrator* not show the plaintext edit tabs.
Well, remember that those looking at it to evaluate it will *also* note that they're missing; this will have an effect on people's perceptions one way or the other, even though it's not a production implementation.
My apologies for misunderstanding you, and for sounding like Get Offa My Lawn Guy, something I have to guard against increasingly as I dive into my forties. :-)
Cheers, -- jra
On 1 January 2011 16:53, Joe Corneli holtzermann17@gmail.com wrote:
I love it and for the sake of demonstration the deep impact of the approach, I recommend one minor change: Retitle it WYSIFTW
+1
- d.
On Sat, Jan 1, 2011 at 6:17 PM, David Gerard dgerard@gmail.com wrote:
On 1 January 2011 16:53, Joe Corneli holtzermann17@gmail.com wrote:
I love it and for the sake of demonstration the deep impact of the approach, I recommend one minor change: Retitle it WYSIFTW
+1
I hope you're both referring to #1 on http://en.wiktionary.org/wiki/FTW ...
(#3 would work as well, for wheel wars ;-)
Unfortunately I would say the thing is broken for me, insofar as various keys (e.g. j,k,f,g,h,l) result in editor actions instead of characters being inserted.
On Sat, Jan 1, 2011 at 12:50 PM, Magnus Manske magnusmanske@googlemail.com wrote:
Happy new year all!
Let me welcome you to this historical year (10 years of Wikipedia! Wow!) with a working demo of WYSIWTF, a pure JavaScript attempt at (pseudo-) WYSIWYG wikipedia editing.
For the impatient, add
document.write('<script type="text/javascript" src="http://toolserver.org/~magnus/wysiwtf/wysiwtf.js"></script>');
to your vector.js, force-reload, and try any article, User, or Wikipedia namespace page. Click the WYSIWTF tab, edit, and save (yes, it does save. You are responsible for cleaning up if you make a mess ;-) (I invite you to try my test article at http://en.wikipedia.org/wiki/User:Magnus_Manske/test )
Now, this is not "real" WYSIWYG, but rather what I'd call "augmented wikitext". You still edit wikitext, but some elements (headings, links, images, and yes, template) are HTML-rendered for convenience. Large templates are collapsed into the template name; double-click it to show/hide the vast sea of parameters, which you then can edit like normal wikitext. Likewise, double-click links or images to get (currently quite limited) properties.
For this to work, wikitext is parsed into "augmented wikitext", which is then edited, and rewritten to normal wikitext upon save. Therefore, you can still enter wikitext directly, and it will "just work" (TM), except it won't show directly in its rendered form in the editor. Likewise, lots of wikitext markup is currently not parsed into an augmented form; bold/italics, lists, and tables, among others, are left untouched. I can do only so much for a demo :-)
The editor component is by far the weakest part of this demo. I looked at CKedit, but it seemed too much work to adapt it for a demo than to write my own editor, which I then did. To make my life easier, each wikitext character (!) is its own <span> element, which might tax your browser. Medium-sized articles work fine in Chrome on my MacBook Pro, but YMMV. You can click into the text to position the cursor, move it left and right with the cursor keys (not up or down!), type text, delete or backspace, and use Enter for new line. That's it. No text selection, not bold/italics buttons, no undo. All of which is entirely feasible, but too much work for this demo.
Some things can't be done with the demo right now, such as changing a template name, or resizing an image. Again, no technical reason, just a man-hour one. You will certainly find many ways to break it, and instances where it fails (correctly discerning whether and image if local or from Commons is one).
What I would like is some discussion about
- if this approach (working pseudo-WYSIWYG instead of unattainable
perfect WYSIWYG) is the way to go
- if the code I wrote would be a suitable basis for a system we can
throw at the general public
- if anyone is willing to help me with that
As always, my code is GPL, and I would be more than happy if, in the end, it would become "official" Foundation code, with staff that supports it. Well, I can dream...
Cheers, Magnus
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Works for me (Mac, Chrome). Not tested anywhere else. Your OS/browser?
On Sat, Jan 1, 2011 at 6:14 PM, Joe Corneli holtzermann17@gmail.com wrote:
Unfortunately I would say the thing is broken for me, insofar as various keys (e.g. j,k,f,g,h,l) result in editor actions instead of characters being inserted.
On Sat, Jan 1, 2011 at 12:50 PM, Magnus Manske magnusmanske@googlemail.com wrote:
Happy new year all!
Let me welcome you to this historical year (10 years of Wikipedia! Wow!) with a working demo of WYSIWTF, a pure JavaScript attempt at (pseudo-) WYSIWYG wikipedia editing.
For the impatient, add
document.write('<script type="text/javascript" src="http://toolserver.org/~magnus/wysiwtf/wysiwtf.js"></script>');
to your vector.js, force-reload, and try any article, User, or Wikipedia namespace page. Click the WYSIWTF tab, edit, and save (yes, it does save. You are responsible for cleaning up if you make a mess ;-) (I invite you to try my test article at http://en.wikipedia.org/wiki/User:Magnus_Manske/test )
Now, this is not "real" WYSIWYG, but rather what I'd call "augmented wikitext". You still edit wikitext, but some elements (headings, links, images, and yes, template) are HTML-rendered for convenience. Large templates are collapsed into the template name; double-click it to show/hide the vast sea of parameters, which you then can edit like normal wikitext. Likewise, double-click links or images to get (currently quite limited) properties.
For this to work, wikitext is parsed into "augmented wikitext", which is then edited, and rewritten to normal wikitext upon save. Therefore, you can still enter wikitext directly, and it will "just work" (TM), except it won't show directly in its rendered form in the editor. Likewise, lots of wikitext markup is currently not parsed into an augmented form; bold/italics, lists, and tables, among others, are left untouched. I can do only so much for a demo :-)
The editor component is by far the weakest part of this demo. I looked at CKedit, but it seemed too much work to adapt it for a demo than to write my own editor, which I then did. To make my life easier, each wikitext character (!) is its own <span> element, which might tax your browser. Medium-sized articles work fine in Chrome on my MacBook Pro, but YMMV. You can click into the text to position the cursor, move it left and right with the cursor keys (not up or down!), type text, delete or backspace, and use Enter for new line. That's it. No text selection, not bold/italics buttons, no undo. All of which is entirely feasible, but too much work for this demo.
Some things can't be done with the demo right now, such as changing a template name, or resizing an image. Again, no technical reason, just a man-hour one. You will certainly find many ways to break it, and instances where it fails (correctly discerning whether and image if local or from Commons is one).
What I would like is some discussion about
- if this approach (working pseudo-WYSIWYG instead of unattainable
perfect WYSIWYG) is the way to go
- if the code I wrote would be a suitable basis for a system we can
throw at the general public
- if anyone is willing to help me with that
As always, my code is GPL, and I would be more than happy if, in the end, it would become "official" Foundation code, with staff that supports it. Well, I can dream...
Cheers, Magnus
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
On 1/1/11, Magnus Manske magnusmanske@googlemail.com wrote: > Works for me (Mac, Chrome). Not tested anywhere else. Your OS/browser? That was on FF3.6, running under X11 on Mac OS. Not the most mainstream combo :)
I'm getting blank pages after adding that (in Safari, Mac). I tried using importScriptURI'ing it but to no luck. I presume because the script internally calls more document.writes.
-- Krinkle
Op 1 jan 2011, om 13:50 heeft Magnus Manske het volgende geschreven:
For the impatient, add
document.write('<script type="text/javascript" src="http://toolserver.org/~magnus/wysiwtf/wysiwtf.js"></script>');
to your vector.js,
Op 1 jan 2011, om 13:50 heeft Magnus Manske het volgende geschreven:
For the impatient, add
document.write('<script type="text/javascript" src="http://toolserver.org/~magnus/wysiwtf/wysiwtf.js"></script>');
to your vector.js,
Okay, I've switched to Firefox 4 Beta on Mac and it works there. One error I got though, when I click the WYSIWTF-tab it got stuck on "Parsing..." modal box. Console told me "images.query [undefined] is not an object".
API call to http://www.mediawiki.org/w/api.php?action=query&generator=images&tit... returned an empty array (the Sandbox page didn't contain any images at the time).
Another (that you already mentioned partially) is that when I went into "WTF"-mode the image suddenly changed from MW.org's local image to ENWP's local "File:Example.jpg". Although I understand it doens't differentiate between local and commons, I think we should keep wiki-independance in mind from the start. ie. using wgVariables instead of 'en'.
Op 1 jan 2011, om 15:40 heeft Jan Paul Posma het volgende geschreven:
What I would like is some discussion about
- if this approach (working pseudo-WYSIWYG instead of unattainable
perfect WYSIWYG) is the way to go
- if the code I wrote would be a suitable basis for a system we can
throw at the general public
- if anyone is willing to help me with that
As always, my code is GPL, and I would be more than happy if, in the end, it would become "official" Foundation code, with staff that supports it. Well, I can dream...
You seem to want to do exactly the same thing as I'm doing, but in the browser only! Maybe you're interested in looking at http://janpaulposma.nl/sle/wiki , http://www.mediawiki.org/wiki/User:JanPaul123/Sentence- level_editing, http://lists.wikimedia.org/pipermail/wikitech-l/2010-October/050031.html and http://commons.wikimedia.org/wiki/Category:Sentence-level_editing
Anyway, I have also looked at doing parsing in the browser, which is quite interesting. WikiBasha also uses JS parsing, so maybe it's a good idea to look at that too. Trevor also made a JS parser, but I think it's not in SVN (yet).
Regards, Jan Paul
Right now there are three or four projects in active development (including Magnus' WYSIWTF en Sentence-level editing). How about working together ?
Compare what the current status of the different projects is, what are the ultimate goals, which are closest to it ? Then import from others to it to make one awesome thing.
Personaly I also prefer the non-WYSIWYG editing style. In other words: Showing what things are but staying in (in)direct contact with wikitext.
-- Krinkle
2011/1/1 Krinkle krinklemail@gmail.com:
Op 1 jan 2011, om 13:50 heeft Magnus Manske het volgende geschreven:
For the impatient, add
document.write('<script type="text/javascript" src="http://toolserver.org/~magnus/wysiwtf/wysiwtf.js"></script>');
to your vector.js,
Okay, I've switched to Firefox 4 Beta on Mac and it works there. One error I got though, when I click the WYSIWTF-tab it got stuck on "Parsing..." modal box. Console told me "images.query [undefined] is not an object".
API call to http://www.mediawiki.org/w/api.php?action=query&generator=images&tit... returned an empty array (the Sandbox page didn't contain any images at the time).
Thanks, fixed now.
Another (that you already mentioned partially) is that when I went into "WTF"-mode the image suddenly changed from MW.org's local image to ENWP's local "File:Example.jpg". Although I understand it doens't differentiate between local and commons, I think we should keep wiki-independance in mind from the start. ie. using wgVariables instead of 'en'.
Also fixed now, using wgContentLanguage and a different API query.
Op 1 jan 2011, om 15:40 heeft Jan Paul Posma het volgende geschreven:
What I would like is some discussion about
- if this approach (working pseudo-WYSIWYG instead of unattainable
perfect WYSIWYG) is the way to go
- if the code I wrote would be a suitable basis for a system we can
throw at the general public
- if anyone is willing to help me with that
As always, my code is GPL, and I would be more than happy if, in the end, it would become "official" Foundation code, with staff that supports it. Well, I can dream...
You seem to want to do exactly the same thing as I'm doing, but in the browser only! Maybe you're interested in looking at http://janpaulposma.nl/sle/wiki , http://www.mediawiki.org/wiki/User:JanPaul123/Sentence- level_editing, http://lists.wikimedia.org/pipermail/wikitech-l/2010-October/050031.html and http://commons.wikimedia.org/wiki/Category:Sentence-level_editing
Anyway, I have also looked at doing parsing in the browser, which is quite interesting. WikiBasha also uses JS parsing, so maybe it's a good idea to look at that too. Trevor also made a JS parser, but I think it's not in SVN (yet).
Regards, Jan Paul
Right now there are three or four projects in active development (including Magnus' WYSIWTF en Sentence-level editing). How about working together ?
Compare what the current status of the different projects is, what are the ultimate goals, which are closest to it ? Then import from others to it to make one awesome thing.
Personaly I also prefer the non-WYSIWYG editing style. In other words: Showing what things are but staying in (in)direct contact with wikitext.
I'm not sure what's happening to that usability initiative template folder thingy, which looked way cooler than mine, but never made a live appearance.
The sentence-level editing looked great last time I checked, but requires server-side mods IIRC, and seems to be limited to smaller fixes. Maybe I'm wrong there, though. Not sure if we could join code, as we do different things on the content preparation level; maybe decent editor code? I could use some ;-)
I can see my solution and the sentence-level editing happily co-existing, though!
Cheers, Magnus
wikitech-l@lists.wikimedia.org