I wanted to get back to my “Why I hate FrontPage” kick. As some of you no doubt figured out from the responses to my original post, the thing I always hated most about FrontPage, the mucking with my code, was fixed in FrontPage 2003. If you’ve used it, you know that FrontPage is much more code friendly than it was in previous years. This is great news for those of us who love to work with code. If you haven’t worked with it, I strongly encourage you to play with the online trial or order the trial CD.
FrontPage is no longer your mother’s (or grandmother’s) Web package. It’s not just for beginners anymore.
As an exercise, I decided to do some additional research on why people hate FrontPage. FrontPage has a BAD reputation, and that’s sad because there are some very cool things about FrontPage … at least FrontPage 2003.
Problem #1: Background
Of course, the most hated issue was that FrontPage mucked with the code, but this was such a common problem in early WYSIWYG HTML editors, that I don’t understand why people lay this problem solely on FrontPage’s doorstep, except perhaps that the people who are complaining haven’t used other WYSIWYG HTML editors and haven’t upgraded to a version newer than FrontPage Express or FrontPage 97.
To give you a bit of background, the first Web package I ever worked with was … okay, I’ll say it … Net Objects Fusion. I don’t think even it exists anymore, and no wonder. The HTML code that it generated was as UGLY. I’m talking UHH – GLY! If you thought FrontPage was bad, you haven’t seen anything. At the time I didn’t know any better, but then I learned, and Notepad became my best friend.
Homesite came next, and it was much better — definitely better than NOF and cooler than Notepad. (Side note: I was first introduced to Homesite because it shipped with NOF. Great tool, strange marketing strategy.) But even Homesite had problems with WYSIWYG editing. I remember once clicking on the design view in Homesite and getting a message that switching to design view would mess up my code (my words, not the actual message), and did I want to continue. No way! I had learned that lesson already, and I wasn’t letting anything touch my code.
FrontPage 2003 really is the best I’ve worked with yet. (Yes, I have worked with Dreamweaver, and, No, no one paid me to say that!) FrontPage added several features in 2003 that were designed solely for developers. IntelliSense is my favorite. (Ah, visions of Homesite spin through my head…) Split view is a nice feature. And, most importantly, no more mucking up my code.
Problem #2: Dependencies
The second most hated problem with FrontPage is dependencies … specifically FrontPage Server Extensions. (Yes, I hate them, too.) In FrontPage 2003, most of the FPSE dependencies have been removed. Now, when you use the Database Interface Wizard to add database results to a Web page, you can have the results returned in classic ASP or ASP.NET code. I have to be honest: I don’t much care for all the webbot code mixed in with the ASP, but I’m sure it’s there for backwards compatibility.
Although many of the dependencies on FrontPage Server Extensions are gone in 2003, FrontPage includes additional dependencies for Windows SharePoint Services. This can be seen as both good and bad.
I work with WSS sites every day. All my content goes onto a WSS site. I have my internal Microsoft tech reviewers open articles from a WSS site to review and comment on articles we are getting ready to publish. I think WSS is very cool, and I think it’s even cooler that I can pull my WSS site into FrontPage and change the way it looks, add images, change text. The WSS site admin tool is okay for simple stuff, but with FrontPage, I can give my WSS site a whole other look. I can even change it so much that people don’t know it’s a WSS site.
The downside, IMHO, is that WSS is for intranets and extranets (although I have been told that it can be used with Internet sites as well). This in it self isn’t a big issue, except that many of the features that require WSS are VERY COOL … (and it’s frustrating that I can’t use them in my own Web site, unless I ask my ISP to install WSS, at which point they would surely groan at yet another server dependency to support, because I’ve already asked them to install FPSE and the .NET Framework, neither of which they’ve installed or configured correctly…) … like WYSIWYG XSLT editing. From what I understand, FrontPage is the ONLY tool available for WYSIWYG XSLT editing … but only within WSS sites, and then only within the XSLT Web part.
Problem #3: Dependencies
This deserves another mention. You see, the problems with FPSE dependencies are less an issue with FrontPage and more and issue with the FrontPage Server Extensions. Okay, I acknowledge that I generally like to leave the server stuff to someone else, but lately I’ve been working with FPSE, and all I can say is administering the FPSEs sucks … and that’s the polite version! It’s not that it’s so hard; it’s just so confusing and frustrating and …. If all I had to do was apply the settings in the FPSE admin console, it would be fine, but there are OS settings, and IIS settings, and a host of other issues. I won’t tell you the hoops I had to jump through in order get anonymous browsing to work on my 2003 machine. And depending on the OS that you have, you may need to configure different server settings.
Windows 2003 is locked down much more than 2000 or NT, so I’m sure the issues I encountered were different from those of many of our users, and I suppose the more you do it, the easier it becomes. I gained a new level of respect and admiration for server admins who have to administer FPSEs. My purpose in going through this pain? To understand what was wrong with the FPSE pages on MSDN. (They are the most widely visited and poorest rated pages in the FrontPage developer portal.) Yes, they are horrible, but I am working on it, and gradually, they should improve.
Feedback, even negative feedback, is a wonderful thing …