Talk:Aloha Editor Dev Con Vienna 11

From AlohaWiki

Confirmed?

I added myself to the list of confirmed on position 26. Allowed are 25. Is it okay to just come and sneak around?

Stefan

Yes you are welcome to join as guest

Hi, you are welcome to join guest. The regular places are full.

Feedback from live stream watcher

Cu monday, Haymo

First of all, big thanks to everyone who was involved with the Aloha devcon last week. All of you did a really great job! Originally I would have liked to come over to Vienna myself, but for some reasons this wasn't possible. However, the live stream enabled me to attend almost any presentation (at least virtually), and the few ones I missed got recorded, so I could view them afterwards. Thanks for those very interesting and inspiring presentations! I had never before tried working / coding and listening to talks at the same time, but surprisingly this worked out for me. I even got a little sad on thursday as putting on the headset suddenly had no sense anymore ;) ... So, way thanks also for the live stream, at least I could participate as a remote listener this way.

If you permit I'd like to drop some lines about the talks themselves and some of the ideas that were presented.

1.) I really appreciate that in the meantime it seems to be common sense that ExtJS should be dropped in favor of jQuery UI. When I played around with Aloha editor for the first time last summer, ExtJS was my first and most important concern (licensing issues as well als the immense code overhead).

I have to admit that I don't have any noteworthy experience with neiter jQuery UI nor jQuery itself, as I'm spending most of my time with the development of a large long-term project which includes it's own JS library. So far I'm using TinyMCE as editor within this project, but I'd love to replace it with Aloha - the sooner the better. However, the involvement of ExtJS would not only arise licensing problems (as this project is not open source), but it would also bloat the code in an unacceptable scale (considering that it's needed "just for a few toolbars and buttons"). Of course, if my project was already based on ExtJS, the latter would be no problem. But it is not, and - even worse - my own library already includes a fair amount of UI related features, in fact I could solve all those toolbar and button things out of the box. But as long as ExtJS (or any other UI library) is hardwired into Aloha, I won't have any other possibility as to deal with the pain of requesting some further hundreds of kilobytes whenever I need to put an Aloha instance on the page.

In every respect jQuery UI seems to be the far better alternative, and I'm really looking forward to getting my hands on what's coming up. Thanks for the presence of the jQuery UI guys at the devcon, this really leaves a good flavor! Of course, the most desirable solution would be the free choice of which UI library to utilize (whether one of the publicly available ones or a private / proprietary one), but surely the support for jQuery UI is a very good start.

2.) Imho some of the ideas and topics presented at the devcon have been discussed in a black-or-white-like manner a little too early. In my understanding it's neither possible nor reasonable to generally classify ideas like e.g. the "private plugins" or the "security layer" into categories like "must have", "critical" or "unnecessary". All these ideas have their very own potential, although it will strongly depend on a) the concrete use case and b) the single user's preference whether one of them will be considered valuable or not. So, regarding those ideas that could end up in a result which is not applicable or desirable for any possible user, I was missing someone to simply say "Make it, but make it optional!". What about letting implementors and / or users decide what is useful in their concrete case? Giving a choice (while providing a reasonable default at the same time) is always better than taking a decision for someone else (imho). Modular as Aloha is it should be possible to implement those features in a way they can be activated on demand (and on one's own authority). Of course, there are a couple of problems to overcome, but features like these really could boost Aloha's value for editors a lot.

3.) I especially like the idea of the "security layer", although I'd rather rename and extend it to "content (model) validation layer". As I said before, it will possibly depend on the concrete circumstances whether one really has the need for it, so this would be a good candidate for being an optional feature. But speaking in general: support for this would be a great plus for Aloha!

As long as one "only" deals with HTML (and stays within a pure HTML realm), it might be not that important how valid (regarding the content model) a edited result finally is. browsers used to be tolerant in a certain extent, and there's a pretty good chance that they will also behave alike in the future. But as soon as one leaves the pure HTML world and uses an editor like Aloha for working on content which is not solely intended for the display in a browser (but which e.g. has to be post-processed in some way), the validity of the content might gain another level of importance. I'm more the XML than the HTML guy, and I work a lot with e.g. XSLT for transforming between different dialects. I can hardly count the cases where a transformation process failed and had to be "repaired" just because a user had - once again - copy-pasted some content (including tons of invisible formating crap and such alike ...) from wherever into a content editor like Aloha. For the normal user this can be a really frustrating experience, as he does neither see what he did wrong nor does he want to deal with it - he just wants to edit content, without all those internal hassles. Finally it's up to the editor to deal with these problems. To be a serious alternative / replacement for MS Word it's necessary for Aloha to also provide working means for importing content from as much sources as possible. To acchieve this, a "security" respectively "content validation layer" seems essential to me.

Besides the mere validation I also can imagine a couple of cases where it could be desirable to restrict the valid content model even further. As mentioned in the talk there could e.g. be some corporate guidelines that don't permit certain content in certain situations, or the content model of an editable area is restricted by design / definition (as in the case of the editable TYPO3 content element headline, which - of course - should not contain any other block level element etc.). But I can imagine even much more complicated cases ... I'd like to provide an example out of my personal experience, which has arised again just last week:

From time to time I have to write (software) documentations, and I prefer to write them as Docbooks. [For those of you who never got in touch with Docbook: It's an XML dialect especially layed out for writing documentations. The most noteworthy advantage of Docbook is the fact that it's neutral in respect of the output medium and can easily be transformed to screen (e.g. HTML) as well as printable (e.g. PDF) versions] Some time ago I had to collaboratively write a documentation together with some co-authors. Docbook provides a pretty extensive set of features, and in order to take the most advantage of it one will likely want to use e.g. cross-references a lot. The available Docbook editors are not really "user friendly", thus editing a Docbook results in a mixture of writing and coding - which was not acceptable for my co-authors. Furthermore, all the available editor used to be desktop applications, so they didn't support collaborative work as well. Next up we thought about using a wiki for writing our documentation - but we came to the conclusion that a normal wiki wouldn't meet our requirements regarding the structuredness of the edited content (for cross-media publishing). I ended up in using the means I'm familiar with: I wrote a TYPO3 extension which enabled us to write the documentation as TYPO3 website, with regular TYPO3 content elements, and with the support for exporting the whole site (or parts of it) as Docbook (in fact one could even download the whole documentation as layed out PDF). The solution solved most of our problems:

• all the authors were capable of using TYPO3 (even collaboratively)
• the documentation was always immediately viewable as website
• the final result was a well structured Docbook

The only drawback was that we had to limit ourselves to a subset of Docbook, as we were bound to the features of the TYPO3 richtext editor, but it was sufficient for our needs at that time.

Today I'm still working with this solution, but due to several TYPO3 changes the extension is partly broken. Right now it seems I will have to pay attention to this again, as there is another documentation project coming along. Since my last efforts another Docbook version has arised, and I see the need for repairing and updating my workflow. Looking into the new Docbook specs I realised that I will have to waive even more features than with the last version, as there are still almost no means of restricting the content model within the TYPO3 richtext editor. Sure, I can possibly establish simple rules like "these elements are allowed, these are not ...", but there's no way of defining something like "these elementes are only allowed within theses contexts ..." or "this element always appears with exactly this structure of subordinate elements ..." (which is what I would need to assure the compatibility with Docbook and what would be simple to express as e.g. XML Schema or Relax NG). In order to use (X)HTML (respectively an (X)HTML editor) as an obvious and user friendly method for editing structured content (which is - in this case - not solely intended for browser display) I would need the possibility to influence the content model regarded as valid in this certain context.

Of course, this might be a very special case I'm talking about. If I didn't miss the point in the talk there would be (or is already?) an explicit content model integrated into Aloha, namely the HTML5 content model. If there were the possibility to further restrict this model (or even articulate a private subset) in a - let me say - XML Schema like manner, Aloha could be suitable for an even wider (though specialised) range of applications. I could even imagine this as a feature independently applied to single Aloha instances by means of explicitly assigning a content model definition (defaulting to the HTML5 content model). I'd really love to see this discussed further ... What do you think?

---

So these were my two cents ... Again, big thanks to all who contributed to the Aloha devcon last week - it was truely very inspiring!

Regards, Joschi Kuphal