A quick update on WYSIFTW, my "augmented wikitext" editor. (Please see http://meta.wikimedia.org/wiki/WYSIFTW for details.)
Wikitext support is nearing completion. I added bold/italics a few days ago, and yesterday it got some buttons to apply/remove such markup from a selection. Just a few minutes ago, I finished wikitable support - you can now edit text in table cells, in the same table layout and style you see in the real article (though you cannot alter the table or cell markup itself, add/remove rows, etc., which can later be achieved through buttons in the sidebar or similar).
As of this moment, lists, indentations, <nowiki>, <pre>, and "---" (<hr>) are not supported. These shouldn't be too difficult, compared to the things already done.
I have taken great care to avoid unnecessary changes in the wikitext being introduced through the parsing/unparsing process. I am not 100% successful, but after test-loading dozens of random pages, as well as a few of my standard tests (including [[Paris]] and [[Berlin]]), these events seem to be rare, and do not appear to break valid wiki syntax. If you find a page (it will warn you in the sidebar after parsing), please add it to http://meta.wikimedia.org/wiki/Talk:WYSIFTW#Pages_with_inherent_differences .
The editing components have improved as well, but are far from the usual Word-like capabilities. No cut/copy/paste, and no undo. The former should be easy to do, at least for plain text; the latter will require "recording" of all editing actions, which sounds like work to me :-(
Speed has become an issue. I work with Chrome 10 on a not-too-old iMac, so even behemoths like [[Paris]] are parsed in <20sec. However, I have heard reports about times of >200sec, which is clearly too much (20 sec is as well, IMO). A large chuck of the time seems to come from bold/italics parsing, which can include up to four separate parsing steps in my implementation. There is clearly room for improvement, but I hesitate to optimize until all major features (e.g. lists) are implemented, and I have some standard test pages available. I am also thinking about using Selenium once WYSIFTW is feature-complete (as far as wikitext goes).
There is the question of what browsers/versions to test for. Should I invest large amounts of time optimising performance in Firefox 3, when FF4 will probably be released before WYSIFTW, and everyone and their cousin upgrades? As a one-man-show, I have to think about these things.
Finally, there are, undoubtedly, a large number of bugs hidden in the code. I assume they will be weeded out, given enough eyeballs (testers and developers).
That wasn't as quick as I said in the first line of this mail. OTOH, it's past midnight here (again!), and I'm getting too old for this...
Cheers, Magnus
Magnus Manske wrote:
There is the question of what browsers/versions to test for. Should I invest large amounts of time optimising performance in Firefox 3, when FF4 will probably be released before WYSIFTW, and everyone and their cousin upgrades? As a one-man-show, I have to think about these things.
It depends what your goal is. If your goal is to use this by default with core MediaWiki, it's going to have to support Internet Explorer 6 and Firefox 3, as well as a lot of other browsers. If your goal is to create another WikEd, it can support whichever browsers you choose to support. Given the widespread use of Firefox 3, I can't see any widespread adoption of this tool happening without support for it, even if Firefox 4 is on the horizon.
Finally, there are, undoubtedly, a large number of bugs hidden in the code. I assume they will be weeded out, given enough eyeballs (testers and developers).
Are you looking for testers and developers? Where would a tester submit a bug report? The page at http://meta.wikimedia.org/wiki/WYSIFTW doesn't seem to address this.
Also, is the use of document.write() still required in order to install the script? I thought that had been intentionally avoided for years in favor of importScriptURI(). (I suppose that would be my first bug report.)
MZMcBride
Op 17 jan 2011, om 01:35 heeft MZMcBride het volgende geschreven:
Magnus Manske wrote:
There is the question of what browsers/versions to test for. Should I invest large amounts of time optimising performance in Firefox 3, when FF4 will probably be released before WYSIFTW, and everyone and their cousin upgrades? As a one-man-show, I have to think about these things.
It depends what your goal is. If your goal is to use this by default with core MediaWiki, it's going to have to support Internet Explorer 6 and Firefox 3, as well as a lot of other browsers. If your goal is to create another WikEd, it can support whichever browsers you choose to support. Given the widespread use of Firefox 3, I can't see any widespread adoption of this tool happening without support for it, even if Firefox 4 is on the horizon.
Finally, there are, undoubtedly, a large number of bugs hidden in the code. I assume they will be weeded out, given enough eyeballs (testers and developers).
Are you looking for testers and developers? Where would a tester submit a bug report? The page at http://meta.wikimedia.org/wiki/WYSIFTW doesn't seem to address this.
Also, is the use of document.write() still required in order to install the script? I thought that had been intentionally avoided for years in favor of importScriptURI(). (I suppose that would be my first bug report.)
MZMcBride
* Moved the page to mediawiki.org * @MZMcBride: https://jira.toolserver.org/browse/MAGNUS Component: WYSIFTW
-- Krinkle
Krinkle wrote:
- @MZMcBride: https://jira.toolserver.org/browse/MAGNUS Component:
WYSIFTW
Noted here: http://www.mediawiki.org/w/index.php?diff=376424&oldid=376410
MZMcBride
On 17 January 2011 01:35, MZMcBride z@mzmcbride.com wrote:
Magnus Manske wrote:
There is the question of what browsers/versions to test for.
It depends what your goal is.
Absolutely. As it stand now it's more of a proof of concept than anything else. It's incredibly interesting technically, but it's not at all clear what it will look like in the end, and who the target audience for this is.
If your goal is to use this by default with core MediaWiki, it's going to have to support Internet Explorer 6 and Firefox 3, as well as a lot of other browsers.
If this is indeed the goal, you're basically making something that will need to be at least as good -- as fast, as stable, as user-friendly as Google Docs. I say "at least", because ideally it would be better than that: the clipboard troubles alone that Google Docs has can be deal breakers for some users.
If this is going to be a tool that is meant for a large audience, I would stop developing *right now* and *first* try and find out whether WYSIWTF *if it worked perfectly* solves the users' problems. Do some basic prototyping, test stuff with a mockup, go from there.
If your goal is to create another WikEd, it can support whichever browsers you choose to support. Given the widespread use of Firefox 3, I can't see any widespread adoption of this tool happening without support for it, even if Firefox 4 is on the horizon.
If this is your goal, disregard previous. :)
Michel Vuijlsteke
On 17 January 2011 00:35, MZMcBride z@mzmcbride.com wrote:
Magnus Manske wrote:
There is the question of what browsers/versions to test for. Should I invest large amounts of time optimising performance in Firefox 3, when FF4 will probably be released before WYSIFTW, and everyone and their cousin upgrades? As a one-man-show, I have to think about these things.
It depends what your goal is. If your goal is to use this by default with core MediaWiki, it's going to have to support Internet Explorer 6 and Firefox 3, as well as a lot of other browsers. If your goal is to create another WikEd, it can support whichever browsers you choose to support. Given the widespread use of Firefox 3, I can't see any widespread adoption of this tool happening without support for it, even if Firefox 4 is on the horizon.
FWIW: testing on a single example, I got 218 sec in FF 3.6.13 and 71 sec in FF 4.0b9 on the same system. FF 3.6 is really quite slow for these purposes. IE9 will be unusable.
FF users seem to update pretty quickly once the new version is released and their favoured extensions have updated. Even IE users seem to update quickly once the new version is out. Except IE6 users, who are of course damned to perdition.
Though obviously, optimisation before feature completion is evil.
Before it goes anywhere serious or universal, it'll need some proper usability testing - to see if Magnus' full screen editing approach actually works for other people.
Finally, there are, undoubtedly, a large number of bugs hidden in the code. I assume they will be weeded out, given enough eyeballs (testers and developers).
Are you looking for testers and developers? Where would a tester submit a bug report? The page at http://meta.wikimedia.org/wiki/WYSIFTW doesn't seem to address this.
The talk page is being used for this so far.
- d.
On Sun, Jan 16, 2011 at 7:16 PM, Magnus Manske magnusmanske@googlemail.com wrote:
A quick update on WYSIFTW, my "augmented wikitext" editor. (Please see http://meta.wikimedia.org/wiki/WYSIFTW for details.)
Shouldn't it be WYSIFWT?
Op 17 jan 2011, om 02:12 heeft Anthony het volgende geschreven:
On Sun, Jan 16, 2011 at 7:16 PM, Magnus Manske magnusmanske@googlemail.com wrote:
A quick update on WYSIFTW, my "augmented wikitext" editor. (Please see http://meta.wikimedia.org/wiki/WYSIFTW for details.)
Shouldn't it be WYSIFWT?
No. The name was WYSI WTF. Now it's WYSI FTW[0].
How is fwt related ?[1]
-- Krinkle
[0] http://www.mediawiki.org/wiki/Talk:WYSIFTW#Name [1] http://acronyms.thefreedictionary.com/FWT
On Sun, Jan 16, 2011 at 8:24 PM, Krinkle krinklemail@gmail.com wrote:
Op 17 jan 2011, om 02:12 heeft Anthony het volgende geschreven:
On Sun, Jan 16, 2011 at 7:16 PM, Magnus Manske magnusmanske@googlemail.com wrote:
A quick update on WYSIFTW, my "augmented wikitext" editor. (Please see http://meta.wikimedia.org/wiki/WYSIFTW for details.)
Shouldn't it be WYSIFWT?
No. The name was WYSI WTF. Now it's WYSI FTW[0].
How is fwt related ?[1]
I thought it stood for wikitext formatted and formatted wikitext.
On Sun, Jan 16, 2011 at 7:16 PM, Magnus Manske magnusmanske@googlemail.com wrote:
There is the question of what browsers/versions to test for. Should I invest large amounts of time optimising performance in Firefox 3, when FF4 will probably be released before WYSIFTW, and everyone and their cousin upgrades?
Design for only the fastest browsers. Other browsers could always just be dropped back to the old-fashioned editor.
Aryeh Gregor (2011-01-17 17:31):
On Sun, Jan 16, 2011 at 7:16 PM, Magnus Manske magnusmanske@googlemail.com wrote:
There is the question of what browsers/versions to test for. Should I invest large amounts of time optimising performance in Firefox 3, when FF4 will probably be released before WYSIFTW, and everyone and their cousin upgrades?
Design for only the fastest browsers. Other browsers could always just be dropped back to the old-fashioned editor.
+1 IMHO on some later stage (after optimizing and testing) you should think about quickly dropping to either simple version of the editor (e.g. only folding ref) or to the plain textarea version. Also old versions of browser might benefit a lot by not using jQuery too much (IIRC Google JS engine was the first to be optimized for frameworks like jQuery and that is why it behaves better). Maybe also some hint for users might be given that their browser/machine is too slow for more advanced editor on whole page and that they might want to edit a single section...
Regards, Nux
On Mon, Jan 17, 2011 at 10:18 PM, Maciej Jaros egil@wp.pl wrote:
Aryeh Gregor (2011-01-17 17:31):
On Sun, Jan 16, 2011 at 7:16 PM, Magnus Manske magnusmanske@googlemail.com wrote:
There is the question of what browsers/versions to test for. Should I invest large amounts of time optimising performance in Firefox 3, when FF4 will probably be released before WYSIFTW, and everyone and their cousin upgrades?
Design for only the fastest browsers. Other browsers could always just be dropped back to the old-fashioned editor.
+1 IMHO on some later stage (after optimizing and testing) you should think about quickly dropping to either simple version of the editor (e.g. only folding ref) or to the plain textarea version. Also old versions of browser might benefit a lot by not using jQuery too much (IIRC Google JS engine was the first to be optimized for frameworks like jQuery and that is why it behaves better). Maybe also some hint for users might be given that their browser/machine is too slow for more advanced editor on whole page and that they might want to edit a single section...
Thanks. Most options (bold/italics, links, HTML/references, images, tables) can already be configured separately before parsing. This can be linked to browser sniffing to reduce parse time in older browsers at the expense of "nice" layout. It could also be a user option.
OTOH, it might not be necessary: I just added section editing (including intro section 0). The section can be edited in place, and "cancel" will show the original HTML without having to reload the page.
On my usual test article [[Paris]], the slowest section ("History") parses in ~5 sec (Firefox 3.6.13, MacBook Pro). Chrome 10 takes 2 seconds. I believe these will already be acceptable to average users; optimisation should improve that further.
Cheers, Magnus
Magnus Manske wrote:
On my usual test article [[Paris]], the slowest section ("History") parses in ~5 sec (Firefox 3.6.13, MacBook Pro). Chrome 10 takes 2 seconds. I believe these will already be acceptable to average users; optimisation should improve that further.
Cheers, Magnus
What about long tables?
On Wed, Jan 19, 2011 at 8:25 PM, Platonides Platonides@gmail.com wrote:
Magnus Manske wrote:
On my usual test article [[Paris]], the slowest section ("History") parses in ~5 sec (Firefox 3.6.13, MacBook Pro). Chrome 10 takes 2 seconds. I believe these will already be acceptable to average users; optimisation should improve that further.
Cheers, Magnus
What about long tables?
Worst-case-scenario I could find: http://en.wikipedia.org/wiki/Table_of_nuclides_(sorted_by_half-life)#Nuclide...
4.7 sec in Chrome 10 on my iMac. 6.2 sec in Firefox 4 beta 9. 10.7 sec in Firefox 3.6.
Could be worse, I guess...
On Wed, Jan 19, 2011 at 10:57 PM, Magnus Manske magnusmanske@googlemail.com wrote:
On Wed, Jan 19, 2011 at 8:25 PM, Platonides Platonides@gmail.com wrote:
Magnus Manske wrote:
On my usual test article [[Paris]], the slowest section ("History") parses in ~5 sec (Firefox 3.6.13, MacBook Pro). Chrome 10 takes 2 seconds. I believe these will already be acceptable to average users; optimisation should improve that further.
Cheers, Magnus
What about long tables?
Worst-case-scenario I could find: http://en.wikipedia.org/wiki/Table_of_nuclides_(sorted_by_half-life)#Nuclide...
4.7 sec in Chrome 10 on my iMac. 6.2 sec in Firefox 4 beta 9. 10.7 sec in Firefox 3.6.
Could be worse, I guess...
Another update that might be of interest (if not, tell me :-)
I just went through my first round of code optimisation. Parsing speed has improved considerably, especially for "older" browsers: Firefox 3.6 now parses [[Paris]] in 10 sec instead of 32 sec (YMMV).
Also, it is now loading the wikitext and the image information from the API in parallel, which reduces pre-parsing time.
For small and medium-size articles, editing in WYSIFTW mode now often loads (and parses) faster than the normal edit page takes to load (using Chrome 10).
Cheers, Magnus
On 23 January 2011 00:45, Magnus Manske magnusmanske@googlemail.com wrote:
Another update that might be of interest (if not, tell me :-)
Lots. Making this style of editing (whole-page) usably fast is essential to giving it any serious consideration.
I just went through my first round of code optimisation. Parsing speed has improved considerably, especially for "older" browsers: Firefox 3.6 now parses [[Paris]] in 10 sec instead of 32 sec (YMMV).
[[:en:Anonymous (group)]] - 9.8 seconds in FF4b9 on Dell Mini 9, down from 71 seconds a week ago. Holy crap!
- d.
wikitech-l@lists.wikimedia.org