I'm one of those throwbacks that learned HTML by typing it in Notepad. I've since moved up to using the Visual Studio editor; it does syntax coloring, error highlighting, and has a "design" mode for previewing the page, yet it's a very utilitarian editor that I feel comfortable with. I do use FrontPage when I need to manage connections between multiple HTML pages, but mostly in raw HTML mode. When I use WYSIWYG design mode in FrontPage, I inevitably end up cleaning out a lot of unnecessary junk that it includes in the generated HTML. I think it's fair to say that my obsession with clean HTML results in utilitarian, functional, and standards conformant presentations -- but with a decided lack of graphic appeal.

The ManuSoft and CADLock web sites are examples of this utilitarian approach. The ManuSoft site uses no fancy graphics and relies very little on client side scripting, and it supports a hierarchical navigation system using only standard hyperlinks. I like that minimalist approach, but the price for clean HTML being served to clients is a lot of work on the server to maintain the site. As a result, I don't update the site very often because it's just too difficult.

This blog was the first step toward realizing a goal of making it easier to add new content. After all, the raison d'être of blogs is to minimize the latency between the writer's stream of consciousness and words on the web by making it irresistibly easy to add new content. This is precisely why blogs have become so popular.

Unfortunately, I soon found limitations with my blog. Tabular lists of data still require manual HTML input, it is difficult to customize the content area outside the individual posts on the blog page, and most aspects of the hosted blog software are outside my control. I wanted more.

The Autodesk vs. Open Design Alliance lawsuit gave me an excuse to take the next step: implement the "blog" concept across an entire web site with software that I control. So, I decided to swallow my pride and learn how to create an entire web site that would be so easy to update that I would actually update it frequently -- even if it meant messy HTML code. Stay tuned for Part II, choosing a hosting service and deciding which software to use.

Labels: Autodesk, CMS, ODA, programming, Visual Studio

The recently filed lawsuit has been a hot topic lately, and I've been following it along with everyone else. As a little side project, I decided to create a parallel blog dedicated to the ongoing battle between Autodesk and ODA. The new blog is at http://www.ADSKvODA.com.

The site is still a work in progress, but I hope you'll check it out, and offer suggestions for improvements. Click on the Lawsuit Tracker link to view all the court documents in the case, and subscribe to the site's feed to stay informed of new developments.

Labels: Autodesk, legal, ODA

No matter the communication protocol used to transmit it, most information gets packaged into a file format for consumption. File formats are like virtual checkpoints along the information superhighway, and we would do well to pay attention to who is manning the gates.

We've heard a lot of noise lately about the need for "open" file formats, but documenting a file format is not the same thing as relinquishing control of the format. The key consideration is who decides when and how the file format changes. This is a dirty little secret about file formats that you are not supposed to know. By controlling when and how a file format changes, an organization can maintain a mindshare monopoly over consumers of its file format -- even when the format is "open".

It may be that the relative anarchy of the internet has given us a false sense of security. We happily use "open" formats like PDF, DWF, DXF, HTM, and others with relatively little concern about who controls them, but all of those formats (HTM perhaps to a lesser degree) are controlled by corporations whose allegiance is first and foremost to their shareholders. For example, PDF is "open", but did you know that third party developers need a digital ID signed by Adobe in order to create forms-enabled PDF files that can be opened in the free Acrobat Reader?

In April of 2006, Autodesk filed a trademark application for the word "DWG" when used to refer to DWG files. This may seem benign on the surface, but if successful it will give Autodesk more legal leverage in "defending" the file format. A few weeks ago, Autodesk filed a trademark infringement lawsuit against the Open Design Alliance claiming that the ODA infringed their "AUTODESK" trademark by embedding the mark inside DWG files created with its DWGdirect libraries.

Much has been written by the pundits about the pros and cons of the ODA lawsuit, and the Electronic Frontier Foundation predictably suggests that Autodesk is using trademark claims to stymie interoperability, but the bottom line is that the contention centers around a file format -- a file format that Autodesk considers valuable enough to wage war over.

Labels: Adobe, Autodesk, EFF, file formats, ODA