Topic on Extension talk:InlineEditor/Flow

Hello Jan Paul,

I'm one of the volunteer admins for a civic wiki in Portland, Oregon (USA), PortlandWiki.org. For the past couple of weeks I've done a lot of research aimed at finding some way to improve ease of use, particularly with editing articles. In the age of Facebook and Twitter, a lot of people who might otherwise want to contribute to a civic wiki seem to have little patience with wikitext.

While researching, I stumbled across your InlineEditor extension. I really like it, and want to install it on PortlandWiki. I've looked at the code and have gone through your documentation and everything looks good, from what I can tell (I'm certainly no hardcore coder).

I also set up a little test sandbox here -- http://www.telecafe.org/smw/Sandbox -- (actually that whole wiki is InlineEditor enabled). I haven't tested it extensively, but the tests I've done so far have gone well.

Is there anything you might suggest I think about before installing your extension on PortlandWiki?

Thanks!

Hi Dave,

The problem is that more complex pages will not be edited correctly, as there are still things that need to be implemented for this editor to fully work (and better tested, etc.). This editor is first and foremost a proof of concept to show that this new paradigm of editing works without having to change the parser of MediaWiki, and it isn't actively developed because of the work by the Wikimedia Foundation to fix the parser problems and build an actual visual editor (cf. Google Docs).

I'll put some more information on the extension page to avoid confusion for other people.

Thanks,

Hi Jan Paul,

Thank you for getting back with me. I've read your thesis, as well as some of the other documentation on your extension that I've been able to locate (basically the stuff listed here: http://portlandwiki.org/User:WikiMaster/WYSIWYG#InlineEditor). As such, I think I understand that InlineEditor isn't necessarily ready for prime time yet.

That in mind, a small civic wiki like PortlandWiki may find it necessary to move at a bit faster pace than what Wikimedia Foundation might commit to. Raw wikitext is painful to most of our would-be contributors, and most of them won't put up with it. The various WYSIWYG editors we've tested tend to break the wikitext on PortlandWiki's pages immediately. Your InlineEditor seems to work quite a bit better.

Even if your extension isn't production ready, is it possible to restrict use of InlineEditor from some of the more complex pages? If not, will the potential parser issues create some kind of permanent damage I'm not thinking about (keeping in mind that I'm not a real coder)? Or will parser errors result in possibly a mangled article, but nothing more damaging than that?

Thanks for your patience with me!

Hey Dave,

Thanks for your persisting interest! First of all, the editor will not damage articles in a way that can't be fixed by rolling back a page. Actually, the entire design goal is to avoid the garbled round-trips that most WYSIWYG editors generate. Having said that, the final few algorithms from my thesis have not been implemented, which is why especially templates which leave HTML elements open (e.g. table start, table end), but also other more constructions, are not supported. There might also be other undocumented/unknown bugs, which may or may not be easy to resolve, which is also something to think about when installing this extension.

There is functionality there already to restrict the editor to certain namespaces, and this could quite easily be modified to exclude certain pages based on a hard-coded list, or (a bit more difficult) on other indicators (regex, page flag, etc.). I would be more than happy to advise in that matter, but as I'm not actively developing this now my time would be limited.

Which brings me to the excellent point that other organisations may want to use this kind of editor already. I totally understand this, however because of the tight schedule of the WMF on the one hand (opt-in production usage in December 2011, deployment to small wikis in 2012), and my quite intensive studies this year on the other hand, it seems logical to wait at least until the evaluation of these first milestones. If it turns out that progress is slower than expected, I will try to find a way to get this project going again. Of course, on a general note, developers who'd like to continue this project themselves are always welcome!

I know this answer is not completely satisfying, but I hope this explains the situation.

Hey Jan Paul,

Thank you for your fuller explanation above! Actually your answer reads more like a "best case scenario" response than "not completely satisfying": InlineEditor is potentially useful now (albeit with certain significant limitations). The extension is not likely to blow up the wiki, can be customized to impose restrictions beyond the namespace restrictions already built in, etc.

Your point about the seriousness to which WMF is taking regarding visual editors, and the tight development schedule the organization has committed to, is well taken. Logically it is reasonable to just wait and see where that development goes. That said, one of the features you point out in your thesis is about how experienced wiki editors can benefit from using this extension--keeping the visual representation of the page intact even while editing that page, etc. How true this is for us older wiki geeks who are feeble and half-blind! :-)

If you don't mind, I'll try to put together a small "best practices" list for using InlineEditor in its current state of development (experimental) for sysops who're willing to throw caution out the window and use it anyway, then see what input you might have regarding what I've come up with.

Thanks!

Alright, good luck, and I'm looking forward to seeing how it will work for you in practice!

Also, that's a good point (about experienced wiki editors), you have read my thesis quite carefully then. :-) Once a better parsing method is available, it should be a lot easier to port this in-line editing interface to the new framework, than it is now to circumvent the current parser. I will certainly do so when the time arises.

Cheers,