Why Microsoft FrontPage Didn’t Suck and Why That Matters

In a previous post, I talked about how you sometimes have to choose between ease of use and flexibility in designing applications. And as I said, the choice heavily depends on your intended audience. In the case of Microsoft FrontPage, I really think Microsoft had it right.

I agree that Microsoft FrontPage was not as feature rich as the Dreamweaver of that time. It was not meant to be. I also very much agree that it does not produce a clean and standards compliant code. But let’s set that aside for a while and look at why that is so and whether that was a smart move.

A WYSIWYG webpage creator/builder or visual webpage editor is a terribly complicated piece of software. Unlike word processors, WYSIWYG webpage creators have a lot more decisions to make. In the former, you can change the size of your font and the program just has font points to worry about; in the latter, the program has to consider whether to use percentages, points, pixels, ems, smaller (or bigger), etc. And we haven’t even gone to the layout aspect yet.

“Let the user choose the font unit”, you say? Uh, right; but who are the users of Microsoft FrontPage anyway? That it is included in Microsoft Office should give us a clue. They are the office guys and gals who are the same persons who use Word, Excel, PowerPoint, etc. These guys are far from being Web developers, and using pixels, percentages and other relative font sizes, among other things, would not make sense to them.

Being targeted to these non – Web developers, FrontPage need not be as feature-rich as the offerings directed at the Web professionals. It also has to be easier to use.

The last statement above would have been a major pain for the developers of FrontPage. Being easy to use means not bothering the (non – Web developer) users about a lot of the aspects of webpage layout and design. That means the program has to guess in many instances. The result is a generated code which is not elegant by any stretch of the imagination.

Well, that’s alright, it’s not for professional designers anyway. As long as it renders correctly in the viewer’s browser in their own private intranet, who cares about the code? But to ensure that this less than ideal code does render correctly, Microsoft has to tweak the browser. Of course, it can’t tweak Netscape’s browser or other browsers so it tweaks its own Internet Explorer to make it render FrontPage generated pages more properly. Herein starts the accusation that FrontPage created pages only work with Internet Explorer.

Based on the above, I can’t see how FrontPage sucked; I guess it didn’t. It could only be if you tried to erroneously compare it with Dreamweaver which is clearly intended for a different set of audience and which clearly has different design parameters, although both of them generate code from visual designs. If not compared to Dreamweaver and used only where intended, like in personal sites or private intranets, I think FrontPage was an OK product.

You might be wondering why I ramble about the unfair treatment a long-gone product had. The reason is that while FrontPage is no more, the mistaken idea that it sucked lives on to this day and is unfairly inherited by the new Microsoft Expression Web. If you don’t believe me, just try doing a Web search. That Expression Web is way better than FrontPage ever was makes the unfair stigma doubly unfair.

Perhaps Microsoft figured that since their lightweight WYSIWYG Web page builder had been pitted against heavyweight Dreamweaver despite the impropriety of the match, they might as well set loose a proper contender. I think they’re doing a pretty good job so far.