I thought I will like ecto 2’s WYSIWYAG editing capability. I was definitely excited by it. Before I go on though, let me explain my expectation of this feature.
From the screen shots and description, I imagined that it would work similar to Dreamweaver or even Frontpage! What do I mean by that? I expect the ability to switch between HTML code mode and Preview mode seamlessly (in ecto 2 they are called ‘HTML mode’ and ‘Rich Text mode’ respectively). This will allow me to compose new blog post in HTML mode, add link, add html tags, etc. while switching to Rich Text mode as a form of quick preview. I understand that the Rich Text mode is not designed to be used like this, but hey, it is there someone will use it this way 🙂 And by switching modes between HTML->Rich Text->HTML (I will call this ‘mode flipping trick’ from here on), I do not expect ecto to generate additional html tags for me.
So I was surprised to find that ecto 2 will generate XHTML tags for me automatically if I perform the modes flipping trick. This of course makes perfect sense in hindsight. And if I were to stick with just using Rich Text mode with the occasional switching to the HTML ‘view’ for other purposes such as altering a alt tag I would be very happy camper. Notice I use the phrase ‘HTML view’ rather than ‘HTML mode’. This is because when doing the mode flipping tricks the HTML at the end are no longer the original HTML. Rather it is the XHTML representation of what the Rich Text mode of the post will look like, which in terms are generated from the original HTML. Thus, really the mode flipping trick does is HTML->Rich Text->XHTML of Rich Text.
I mentioned this to Adriaan tonight and we had a healthy discussion on IM. Adriaan argued that there is really no difference, semantically, between the original HTML and the resultant XHTML. In fact, the XHTML has a better chance of being W3C compliance than the HTML. I agreed with him 100% on this point but my issue is not technical. Rather my issue is about user expectation, or my rather high and precise expectation as an user.
During the mode flipping trick, there is nothing (no beep, no warning message, no big flashing red light on the screen :-D) that tells me my HTML code (most likely W3C non-compliance) will be replaced by ecto with XHTML code. Actually since I am using TypePad/MoveableType with Convert Linebreak set, my HTML post can actually be XHTML compliant without the <p> and </p> tags. Therefore, imagine my confusion when flips modes and gets a face-full of XHTML back.
I as an user was not expecting switching mode will change the total content of the post (text + html). Intuitively, and I am most definitely in the minority here, I expect modes switching is what it says. Switching between different editing/displaying mode. The closest analogy I can think of right now is the XML editor in Visual Studio .Net 2003. I can hand craft a XML file in text mode. I can switch to visual mode and VS.Net will show me the XML as a data grid or entity diagram, depending on the type of XML (XML data or XSD). I can edit in this visual mode and when I switch back to text mode, my existing XML will not be changed unless I edited them in visual mode. Of course VS.NET can’t display invalid XML in visual mode and ecto 2 behaves like that already by warning the user of invalid XHTML.
ecto 2’s UI gives me the impression that it can be presentation independent, i.e. same data can be displayed and edited in different presentation modes. But this is cannot be true if mode flipping changes the underlining data.
Anyway, with my dumb user hat on, I believe this can be resolved in a number of ways. Here are a few in no particular order:
a) Keep it the way it is. But leave, to all users, in no uncertain terms that this is the expected behaviour of ecto 2. Existing posts will be converted to XHTML without Convert Linebreak set if they are edited using ecto 2 in Rich Text mode (or in HTML mode even if the user just do the mode flipping trick).
b) Shows all posts as XHTML if editing mode is set to HTML mode, even if the post is really HTML in origin (i.e. replacing the original post in ecto presentation to the user). This, of course, will just create another type of confusion for the user. The user can log onto the blog service and sees that what is stored on the server in the web browser is different from what ecto 2 shows. And there is no way for the user to get ecto 2 to show the original HTML.
c) Has 2 modes but 3 views (Original HTML, Rich Text, and XHTML of Rich Text). Any edit in any views will be synchronised in the others. No additional tags will be added if the user so desired. This will be highly complex for theh application to keep track of the tags that an user will insert while preserving any existing tags. Notice that there are no applications out there (including Dreamweaver, etc.) that can achieve this.
d) Since c) can’t be done, don’t allow on the fly mode switching. Mode can only be changed in Preference window and comes with giant, red, flashing warning that mode switching is hazardous to your existing posts’ health! Personally I think this is the best compromise.
The ideal behaviour for me c) is probably impossible to implement (this is me with my developer hat on talking). For myself and probably the other 0.001% of the blogging world, the perfect way to utilise both modes (as mentioned briefly in the beginning of this post) is to compose post in HTML mode with Convert Linebreak set. This will allow me to write without worrying about those paragraph tags or any HTML. Then I would switch to Rich Text mode for style editing, adding bold, italic, links, etc. After that, I may or may not switch back to HTML mode to check on other HTML code such as the alt value of an anchor tag or image tag, for example. ecto will work out whether there is a need to add paragraph tags according to the Convert Linebreak setting. May be with additional preference options, ecto will also know to preserve existing HTML, if there are any. The post will be sent to the server as would be seen in HTML mode with Convert Linebreak set, and not the XHTML generated by Rich Text mode.
This will let me have the best of both worlds. I can compose in a content-centric environment where content takes priority over style. But I can also use the Rich Text mode and ecto UI elements to apply styles to my post while seeing their effect first hand. Afterward I can switch back to HTML mode to fine tunes all the stylistic changes. May be I apply the link to one to many character and I want to change that? Rich Text mode may not be the easiest or fastest way to accomplish this.
So the bottom line of this long winded, self important, post is that I will be sticking with HTML mode in ecto 2. That is until Adriaan performs miracle and grants me my wishes! 😉 Then he can patent his code and license it to Adobe,Macromedia, etc. and retires to a life of luxary living…
[composed and posted with ecto 2]
Lost in Colonisation 