Since releasing of Crystal Clear and VacuumMail earlier this year, my download traffic has overridden my .Mac account ... and twice (so far) I've had to upgrade my account to accommodate the bandwidth. I don't mind that, nor do I mind the additional traffic on the Mars Downloads pages. What I do mind is the time it takes me to keep those pages updated! In fact, it takes so long I haven't been able to keep them in sync with the new stuff I was making.

I've been a pro webmaster for, well, a long time... since 1994, in fact. So keeping a couple of simple pages updated shouldn't make me break a sweat, right? Damn right! Problem is, the Download pages started as an experiment with Apple's iWeb software last year, and iWeb and WordPress don't mix well. To help them get along, I devised a simple checklist so all I'd have to do was:

1. Generate the raw HTML from iWeb
2. Massage the HTML by
   1. Tweaking a few CSS styles,
   2. Doing a few search/replaces,
   3. Doing a bit of reformatting, and
3. Plopping the iWeb HTML in the WordPress template, and
4. Moving the iWeb graphics and other files to the server.

At least, that's how I thought it was going to go. As it turns out, the convoluted HTML and CSS code that iWeb generates invariably causes problems when running inside Mars. This means each update can turn into a 2-3 hour scavenger hunt, with each contestant (Me, Me, and Me) trying to find a lost px in a huge block of unreadable code.

So last week I vowed to find another way, and I think I have. The end solution means more work up front in generating the site to begin with, but should make it very easy to rearrange, add, or rewrite content or images on those pages.

iWeb: Lovely Siren for Mac Web Designers

The great thing about iWeb is that it's so easy to design beautiful web pages, and the process of designing beautiful pages is so much fun! In fact, even though I had decided to swear off iWeb from now on, going back to her last week just rekindled my affection. Yes, as an HTML pro, there are many missing pieces and frustrating aspects to iWeb. But as a designer, I can't help but have a good time putting designs together.

And if you use iWeb to manage your site, it's equally easy: Just make the change in iWeb and click a button to push the site out the door. iWeb follows in the footsteps of older products like NetObjects Fusion, which pioneered this kind of totally visual approach. And iWeb's HTML code may even pass w3c validation tests, because it's not using any proprietary, browser-specific junk like Microsoft does with FrontPage.

My problem is that the iWeb code cannot be updated by hand. It just can't! Paragraphs of text get split into individual spans, each with their own lengthy inline CSS styles, and even more horrifying, the page content isn't presented in any understandable order. My best guess is that the iWeb code is generated as you add content to your page. This works because most DIVs on the page have a CSS style of position:absolute, meaning they are positioned by x and y coordinates, and each has the equivalent of a PostScript "bounding box" with a known width and height. As long as you change the content from within iWeb, this model, clearly derived from printing, works, since iWeb can recalculate the width and height and x and y positions of each "box" when it regenerates the code. But just try to do that on your own.

Fuggedaboudit!

And that's the main source of my frustration. Some users have complained about the size of the graphics files iWeb produces, but honestly I think that problem was either overblown, or has been remedied with iWeb updates. The way Apple handles drop shadows that you add to images in iWeb, for example, is ingenious for its ability to retain high output quality with small file sizes. It's an approach, again, that is difficult or impossible to replicate by hand. What iWeb does is generate a JPEG file for the main image, and a separate rectangular, 24-bit PNG image for the underlying shadow. (See the two examples here.) In the HTML, iWeb makes separate DIV layers for each, and positions the shadow layer precisely under the main image so that just its edges show.

The reason this is smart is that JPEG is the most efficient format for full-color images (although iWeb could be improved by giving authors the ability to set a sliding scale of quality for those images... Apple opts for the highest possible quality), while 24-bit PNG is the only format that retains the shadow's alpha layer so it can be composited against any kind of background seamlessly. Apple could have used PNG for the entire image in order to preserve the alpha layer in the shadow (in fact, I think that's what was happening in early releases of iWeb), but that would produce real, unsustainable image bloat. 24-bit PNG files are huge compared with equivalent JPEG files, except for files like this drop shadow that are mostly transparent and consist of a single color. In this case, the 24-bit PNG shadow is actually more than 50% smaller than an equivalent JPEG file... even though it still retains that cool transparency. So iWeb is doing the most intelligent thing possible with these images from both a quality and a file-size angle: JPEG is best for the heart of the image (both in quality and file size), and 24-bit PNG is best for the shadow area (both in quality and file size).

And yet... iWeb has this totally annoying and so-far-unresolvable habit of giving the image files it generates names that are either impossible to decipher, because they bear no relation to anything on the web page, or way too long to be absorbed by human eyes. The only approach to control image naming I'm aware of is to name files in iPhoto and then bring them into iWeb. But that's just not going to fit in my workflow very well, and besides, it doesn't help when iWeb goes to name the shadow file behind that image of Crystal Clear. No, it resorts to names like "imageEffectsBelow_desktop_preview_full_cclite.png." Or if you define an area in iWeb with a gradient background (for example), you get names like "shapeimage_7.png", which don't do much for the readability of the page code.

Anyway, I don't know if I'll be able to keep away from iWeb the next time I feel a web page design coming on, but I do know I'm not going to try to use iWeb's page code on Mars anymore.

If Not iWeb, What?

My search for an alternative was frustrating as well. Without going into detail (maybe another day), let me just relate the visual HTML editors I tried and tossed aside this week:

• Dreamweaver CS3. Yep... that's right, in my opinion the spanking new version of Dreamweaver, released as part of Adobe's Creative Suite 3.0, simply sucks. And I don't say that lightly, since I have been a Dreamweaver evangelist in all of my jobs since the very first version in 1998, although I began to drift /Volumes/Files/Sites/mars/images/away from it for personal projects a couple of years ago. Talk about feature and user-interface bloat! Man, and I used to pitch Dreamweaver as a good tool for beginners! Even though I'm familiar with Dreamweaver interfaces through MX 2004, as well as with the terminology of the web, CS3's convoluted interface simply boggled my mind. The simplest tasks are impossibly hidden in a submenu somewhere or a floating palette's hidden tab, or it wasn't there at all. In any case, I certainly won't be putting in for an upgrade to CS3 in order to get Dreamweaver!
• Sandvox. I'll keep watching Sandvox, but to date (through version 1.1.2) it's struck me as less flexible than iWeb for designing sites or pages from scratch. It is developing a raw HTML capability that will come in handy for pros, but its templates are more rigid than I'd like, with elements that can't be changed in any normal way. Unlike iWeb, you can't just drag images to Sandvox and place them wherever you like... and Sandvox has none of the advanced design tools for image alignment and enhancement (iWeb now includes an image adjustment HUD like iPhoto), or for fully flexible web "parts" like rectangles (rounded or not), lines, and other shapes, or even for typographic niceties like paragraph, character, or line spacing. Heck, you can't even insert a bullet list. Sandvox works best if you want to use one of their prebuilt templates, but is just frustrating as heck otherwise. Even if you add existing HTML using a raw HTML "pagelet," you can't edit it visually within Sandvox... it sits there like an alien "other thing," even though it's just HTML.
• RapidWeaver. I actually bought a license for RapidWeaver a couple of years ago, but found it totally incomprehensible from an underlying code perspective. RapidWeaver is a close cousin of Sandvox, but a bit older and in some ways wiser one. There certainly are a lot more, and more interesting themes, plugins, and add-ons for RapidWeaver by now. But like Sandvox, it doesn't really help you with the design aspect of the web, which is what iWeb does so well.

That left Freeway Pro from Softpress, which I would have tried again except they make it so hard to get a trial version, and the old one I had already downloaded no longer works. Besides, Freeway Pro is almost as expensive as Dreamweaver. I'm not sure whether GoodPage can do visual HTML editing, because likewise I couldn't get the software to run again after having exhausted the first trial last fall. (I think I opened it twice.)

But wait! I nearly forgot... ! I also did a very interesting, though ultimately not usable, experiment with Apple's new Dashcode software, which will be officially released as part of Leopard in September (??) It's been available as a public beta since December. Dashcode is a visual IDE tool for building Dashboard widgets, but since such widgets can be nothing but HTML, JavaScript, CSS, and images, they are, as I've pointed out in the past, just little web pages. That being the case, could Dashcode be used to design a web page? The answer turns out to be, "Sorta." If you want to see a quickie sample made from one of my iWeb pages, you can download it here. Just for fun, of course! No, although Dashcode is fun to use in the same way iWeb is, it's even worse when it comes to writing out HTML and CSS code you could edit later by hand. Each element from the Dashcode library becomes a "part" that a special JavaScript file sets up when the widget runs. And then there's the very practical limitation of widget size. You can use big content for your widget, but Dashcode won't let you scroll down to see it while working. It's just not meant to be used that way. Still, it was a fun experiment.

In addition, I tried the following programmers' text editors to see if they could clean up the iWeb code in any way, or make it easier to manage. None of them could help:

• Smultron. Has no particular facility with HTML, although it does have a web-page preview that works well unless you have a bunch of images that aren't located where Smultron can see them. This can be fixed by adding a meta tag for the base URL, but it would be nice to be able to set this up as part of the project definition. Still, Smultron remains a favorite for general programming since it offers great syntax coloring options, code folding, tabbed windows, and split views. Its syntax smarts aren't so good on cross-language files, though, as is typical with web code: HTML with CSS and JavaScript, or PHP with HTML etc.
• TextMate. This is probably the best of the lot for HTML, because it has a terrific built-in web preview and is enjoyable to use. But it's not exactly easy to troubleshoot HTML in TextMate, nor is it a good place to think about refactoring your HTML code. TextMate does offer code-folding, split views, tabbed editing (if you're working in a project), and much more. Unfortunately, its code folding smarts could use a brain boost, since they can be foiled by inconsistent indentation.
• BBEdit and TextWrangler. I'd used BBEdit for years in working with HTML, and though it does some things extremely well (code blocking anyone?), it's incredibly boring and ugly, and has no preview facility. The best thing about BBEdit is that it can open extremely large text files, which isn't something you find in HTML very often. It's worth noting that the recent upgrade to BBEdit 8.6 requires a license upgrade, even though the only noticeable difference to someone interested in HTML editing is a new icon. TextWrangler is a popular free version of BBEdit, minus various power tools and sporting a different icon.
• Coda. This new kid on the block has a lot of promise, but at the moment it's mostly a website management tool and can't replace the best text editors available for coding. I'll be doing a more complete review of Coda later on, but for now I'll just note that it falls down in several important respects: No searching across files, no code-folding or way of tracking HTML code blocks, weak code completion and indentation functionality, no code reformatting options. It does, however, have excellent built-in previewing, amazing eye-candy, split-view editing, and a parser that tracks and presents a list of DIVs with ID references. Its full-featured CSS editor looks great, but can't see or help with inline styles.
• JEditX. I had tried this earlier and rejected it mainly because it has no support for tabbed editing or anything similar.
• Xcode 3.0. As Apple has revealed in its Leopard "sneak peek," Xcode 3.0 has some rocking new features. Although it's still not exactly designed as a tool for building web pages or editing HTML code, Xcode 3.0 has a feature that beats everything on the above list in terms of making sense of your HTML (or any other language) and determining context, code block closures, etc: Apple's calling it a "focus ribbon," but I tend to think of it as code-folding on steroids. The worst thing about using Xcode for HTML is that it has no built-in preview function (though you can launch the page in a browser). Still, like Smultron, it's free!

There are a few other text editors I've either tried before or plan to try soon, but didn't open them specifically for this project:

• Komodo Edit. The freeware version looks very good.
• SEEdit Maxi. I wasn't impressed with this when I reviewed it last year, but then, at the time I really thought I'd find a lot of HTML editors that offered basic WYSIWYG editing for things like tables and lists, so perhaps I was too hard on SEEdit.
• skEdit. Wouldn't open when I tried it last week in Leopard.
• Taco HTML Edit. I like Taco, but it feels very much like a project that got a great start and then stalled. I guess that can happen when you're not getting any income... but if Taco were actively being developed, it's appealing enough in various ways to tempt me away from Smultron or Xcode. See my recent review for more info on Taco HTML Edit.
• WebDesign. I had tried this out last year some time because of its tie-in to the terrific CSS tool StyleMaster, but didn't care for its interface. That said, WebDesign might be a good choice for beginners who don't mind actually working with the HTML code, and it's got a nice built-in preview window.
• WebScripter IDE. Has a wonderful-sounding feature set, but nothing works in Tiger as far as I could tell.
• HyperEdit. Sounds good... handles PHP and JavaScript as well as HTML.
• Eclipse (I've tried Eclipse several times in the past, but keep planning to give it another go. My main problem with Eclipse is its complex interface and way-too-complex set of preferences. Eclipse does so many things it can't keep track of context, presenting the user with irrelevant choices to what their currently doing. Still, I'm curious to see if anyone has beefed up the tool's ability to manage HTML, CSS, and JavaScript by now.)
• Aptana. This is a new open-source IDE specifically for website development.

And That Left... Photoshop?

Having exhausted all these options, I somehow remembered good old Photoshop. Then, after using it a few times to convert a design to HTML, I realized why none of the otherwise highly visual HTML tools previously mentioned (like Coda?) include the logical functionality of WYSIWYG design. Nearly all professional Mac designers use Photoshop, and that's been their tool of choice all along. I myself used Photoshop to design Mars... but I didn't use its HTML output capabilities. Instead, I made individual graphics from Photoshop designs and did the HTML by hand in BBEdit or Smultron. However, there's an easier way, which is probably what folks coming from the design side of the business are used to. So, even though I've used Photoshop frequently to design web pages and sites, I've never made the leap to thinking of Photoshop as a web design tool.

I'd even used Photoshop a few times to generate HTML, but it was for very simple pages consisting totally of sliced-up graphics. I'd never consider using Photoshop as a website maintenance tool, because then you get into the same sorts of issues you do with iWeb. That said, the HTML code you can get from Photoshop isn't as bad as you might think, and it's way better than what you get from iWeb. That's because Photoshop's output options give you some control over file naming and code handling that iWeb doesn't. As a result, when you look at the images output by Photoshop after you've set up your "slices," you know what they are by name. And you can block out the page in slices in a logical way that makes sense to you, rather than trying to figure out the logic behind iWeb's automated slicing and dicing.

As a result, what I ended up doing was recreating the iWeb Download page design in Photoshop and then putting the pieces of HTML, CSS, and images together by hand... in Xcode. iWeb still came in handy, because nothing in Photoshop makes it so easy to generate a reflection, or quickly design a page layout or a few buttons, and it's still easier to construct the text in iWeb than in Photoshop. Of course, the text bits now get copied from iWeb to TextEdit, which does a great job of generating clean HTML. iWeb and Photoshop also work well together when sharing data: Anything copied and pasted from iWeb goes into Photoshop as a vector "smart image", which can be edited in Adobe Illustrator if you have it on your system. Or you can rasterize them in Photoshop and work with them as bitmaps. The point is, you lose no quality, and even the iWeb effects get transferred.

So now that I've got the Download section set up with HTML code I can actually read, keeping it updated should be a breeze. When it's time to put up a new version of Crystal Clear (next week?), I won't have to spend an hour or two just to make a few changes to the text!

As good as this new process will be for me, what I really want is for Apple to release the new version of iWeb with all the silly bits fixed. As I said, in her current state there's no denying she is gorgeous, and I can hardly resist her when she calls, but for a sustained relationship she's far too high-maintenance for my health.