more on web tools

A little over a month ago I had a short post about web authoring tools. Mike offered a few suggestions in the comments but said his main tool is plain text editor – mostly because he would have to clean up the auto-generated code. Even when I did use tools like FrontPage and Dreamweaver, I found myself doing the same thing. The generated code was never that smart. Aside from inefficiencies, as in span tags that defined styles already in place for a given paragraph, the generated code tended to cause more complications when editing later. For example, because of the poor code structure it can be near impossible to unwind styling.

Since the post I tried a few tools. The first was Amaya, an open source tool developed jointly by the W3C and a division of INRIA. The second tool was Nvu. This is another open source tool initaited by Linspire, Inc.. Here are a few notes on my experiences.

Amaya

This seemed like a visit to the horse’s mouth of sorts. Since the W3C oversees web standards, it was reasonable to assume that it would offer a tool for convenient editing. Amaya is actually both a web browser and web editor. (To an extent I suppose all web authoring tools are web browsers but usually they are rather clunky.) You can visit pages, view their code, modify the code and update the code if you have permission to do so.

As a web browser, it left a good deal to be desired. Many sites I tried to visit wouldn’t render properly, e.g., MSN and SmugMug – probably anything dynamic or that needs a plug-in (Actually on further reflection, while the plugin issue will certainly affect the page, the more general issue is probably that browser detection doesn’t include Amaya. This may cause certain pages to render incorrectly. As an example, MSN defaults to a text-based offering.) The rendering is also very blurred/hazy/fuzzy. It’s clear that as a browser it’s not going to overtake any of the common favorites. But with respect to browsing and editing, it offers a unique characteristic. For example, if you point Amaya to Google’s homepage, it renders and you can interactively modify the page. Sure, you’re only modifying your local copy but you can still tweak it and see what happens.

As with such tools, you can modify the source code or the rendered page itself. You can have both views open at the same time via splitting the window or just one view at a time. The round-tripping occurs when you either save your changes or click in a different view. In itself, that’s not bad. You can easily clean up the code as you go and the code isn’t all that messy.

While the rendering of the page and source code is not ideal, I could live with it if it weren’t for a variety of other issues. As with most tools I’ve used the generated code wasn’t done that well but I had two main problems that led to me abandoning it for now.

First, Amaya was rather sluggish with its rendering of the page. This would have been fine if it was only a problem on the initial load but cutting and pasting were also affected. It felt like I was tripping over untied shoelaces since my editing wanted to progress faster than the tool could respond.

The second issue, and probably the more concerning, was Amaya regularly lost the cursor. There were times when I would try to edit the rendered page itself and the cursor would not be shown. This, coupled with the sluggishness of the rendering, made it almost impossible to edit documents. The same problem occurred, but less frequently, when editing the source code in the tool.

The tool suggests it renders CSS and HTML correctly – and it might. However there were times when the view Amaya showed were not the same as what appeared in either IE7 or Firefox. Since there doesn’t seem to be consensus on how all CSS elements should be rendered (or at least it seems there is room for interpretation), it’s hard to say that Amaya isn’t doing it correctly. That said, I do want to say that more often than not, Amaya proved useful for cleaning up my CSS.

Nvu

While I found Amaya on my own while poking around the internet, a student suggested Nvu. Nvu is (self-)described as being an open source equivalent to the commercial tools like FrontPage and Dreamweaver. It does have Dreamweaver like qualities. (By the way, I am talking about FrontPage in a historical sense since I think it has recently evolved.)

The tool offers several views – accessed by tabs – when you edit a page:

• Source: Edit the raw html code
• Normal: This view that is reminiscent of Dreamweaver. It renders the page with icons placed on the page to indicate different divs.
• HTML Tags: Similar to the Normal view but icons representing the HTML tags are rendered to the document.
• Preview: Shows the page rendered in a browser. This view, unlike in other tools, is editable.

I didn’t find much use for the HTML Tags view. And, once the page layout was done, the Normal view didn’t come into play. I’m not sure what advantage it offered since I could just as easily work with the Source and Preview views. Of course, the Source and Preview views were where I got most of my work done.

Editing in the Preview view is nice. It’s straight-up WYSIWYG. The code generator is far from efficient. More often than not, this tool embedded <span> tags to override paragraph formatting. This meant that was almost impossible to get back to normal paragraph styling without cutting the entire paragraph out or working with the source code. The Preview also had a dropdown menu – similar to FrontPage – that enabled you to select a CSS-defined class for an element. While it could be a user error, you could not change the style with this menu. It would just enable multiple classes to be applied to the element. To clear it, you had to work with the source code.

The Source view gives a straight-forward text editor. There is not much to say about it. There are few quirks, though. For example, the editor has line numbers running down the left hand side. Once in a while you will be editing the code and an unnumbered line appears. This is correct on save and is probably not a big deal. What is a big deal is that the editor regularly prohibits you from moving into pasted code with the keyboard. That is, if you copy/paste a code within the document you cannot move the cursor via the arrow keys into the pasted code. If you save or use the mouse, things work well. But if you are editing raw code, you are probably keyboard-centric and this really disrupts your chi, man.

Some of the Preview issues were manageable. If a tool gets me 95% of the way, I can live with an irritation here and there. The biggest problem I encountered is that the tool likes to make its own decision about how to format the source code. And it does a horrible job of it. If you search the web for formatting horror stories with Nvu, they are plentiful.

I’m probably overly anal about the organization of my source code. (But, and I say it probably all too often, no one has told me my code is too readable.) This tool however makes an absolute mess. In one instance it put multiple blank lines in the source code (of course the rendered page looked fine).

The solutions you find online are to use tools like HTML Tidy. Those tools are great but it seems like a duct tape cast – there are far better solutions.
In the end, Nvu gets the job done for me now but I’m not all that happy with it. Eventually one of these tools will evolve to my satisfaction or I’ll find one that works for me.