SFist Tech Labs: Reading Too Much Into iWeb

Initial Impressions
We were impressed to the point of shameless cultism with the iWeb demo at MacWorld. And the first 20 minutes using the app didn't pour cold water on us — the program does exactly what it purports to do. Start with one of Apple's slick-looking themes. Drag your own content from iPhoto, GarageBand, or iMovie onto the page. Move and resize the columns, mess with the text, rotate pictures, add drop shadows. Publish it, and the resulting web page looks exactly the same as you saw in iWeb. (At least, in the latest versions of Safari and Firefox).

That WYSIWYG experience was enough to give us flashbacks to our first experiences with the Mac and the desktop publishing/multimedia "revolution." But what started the HyperCard nostalgia was Apple's big push for podcasting, of all things.

All of the iLife apps got an upgrade with iLife '06, with the most notable new features all having to do with better integration. iPhoto can now send pictures to GarageBand, which can score projects in iMovie, which can be published on a podcast page in iWeb. Whether or not the majority of us would actually ever want to make a podcast is somewhat irrelevant — the key is that iLife is now positioned to be your amateur home studio for the complete production.

Customization
Lest we be accused of being too hypnotized by Apple's siren song, we should point out that iWeb is definitely not without its faults. It's very much an initial release, and although it makes a strong first impression, it doesn't take long for it to reveal its limitations.

Apple's included themes are as attractive and well-designed as you'd expect from the company. But you can't edit the themes, at least, not without an impractical amount of effort. You're allowed a good bit of customization past the default theme — most items can be moved or deleted entirely, fonts and colors can be changed, and the layout is as flexible as possible — but the further you try to depart from the default template, the more time-consuming and tedious it becomes.

To use another HyperCard comparison: one of that program's strengths was how well it scaled complexity. Simple applications were trivally quick and easy to produce, but as you wanted to deviate from the template and make something more sophisticated, the program gracefully made that possible. A big improvement for iWeb would be to include a theme editor, like HyperCards "background" and "design" modes, which would allow customization changes to be made in one place and reflected throughout the site. That is one of the principles of CSS, after all.

As it stands now, we're going to see a glut of pages using the default themes, and users will likely be frustrated at how Apple is encouraging them to "express themselves," but their pages end up looking like everyone else's.

Version 1.0
Most of the other problems with iWeb have to do with its being a 1.0 release. The blogging system is rudimentary, offering little support for layout changes or searching, and no support for the basics such as comments and discussions. It's unlikely to pull away anyone who has an existing blog — services like Blogspot and livejournal are more full-featured and are no more difficult than iWeb.

Although pages created with iWeb look nice, that comes at a price. Pages are big and slow to load. The program converts text to images in a way that's not always obvious to the user (whenever text is rotated or shadowed, for example). The resulting pages can be exported to a local folder and then uploaded to any webserver, so a .Mac account isn't required. However, the process doesn't support incremental changes; the entire site is regenerated from scratch, which can be a time-consuming process.

And the code that's generated is enough to make experienced users of CSS wince — or, more likely, begin blogging furiously about it. iWeb uses various tricks like inline styles and images to achieve its WYSIWYG results, breaking the philosophy of CSS and extensible website design, even though the syntax is still valid.

This is actually where the regenerate-everything-from-scratch method pays off, though. Users of iWeb don't ever have to maintain or even look at the resulting CSS and HTML. As the code generation becomes more sophisticated in future revisions, it shouldn't break existing iWeb projects.

More Money, More Problems
Aside from the technical issues, we were disheartened by some of the "philosophical" issues that are made glaringly obvious with iWeb. Even though we're not required to use .Mac, Apple keeps reminding us that they'd really, really prefer it if we did. A .Mac subscription window appears at the beginning of every iWeb session, which makes us feel as if we're using a piece of shareware on trial instead of something we'd just paid seventy bucks for. The new "photocasting" feature is only available for .Mac users, as is the fancy photo slideshow. (Although one user has already posted a very slick alternative for the rest of us).

One of the features that seems like a neat piece of integration on first glance, also turns out to be a crass marketing ploy in practice. Dragging a playlist from iTunes into a text field will automatically fill the field with track listings and hyperlinks... to the iTunes Music Store. And if one of your tracks isn't available in iTMS, it's simply left out. We can thank the RIAA for that, of course, but we're sure that Apple doesn't mind the extra advertising.

The Archetypal Grandma
Whenever criticisms of iWeb are brought up, the response inevitably turns to "Know Your Audience," in the form of the archetypal grandma using an iMac, desperate to see baby photos on the internet box. We appreciate attempts to personify the "casual user" market, but are still baffled at the idea; our grandma would've balked at how much time we spend in front of the computer and asked why we didn't just bring the baby out to visit.

Still, the argument is valid. Semantically correct HTML and CSS don't mean anything to the causal user; she just wants her page on the internet to look exactly like it does on her personal computer. But that's only part of the picture, and part of why iWeb is important.

Some critics of iWeb have already pointed out that third-party apps like RapidWeaver and Sandvox are more powerful than iWeb and generate better code. Our opinion is that neither is as clear and simple in design as iWeb, and neither gets good-looking results as quickly, right out of the box.

The market isn't so cleanly divided between Grandma and Professional Web Developer. There are plenty of users who want a simple website they can customize, just as there are experienced developers who would like to be able to do designs and prototypes more quickly. That type of iterative process is key to a product's success, and again, HyperCard facilitated it well. iWeb does a great job with the initial iterations of a site, giving complete control over the initial layout.

Sandvox's creators dismiss iWeb as "just a toy" on their own website, but it's a toy that produces great results with a minimum of investment. And starting now, it's a toy that's going to be included with every new Mac.

The Stack is Dead, Long Live the Intarweb!
iWeb's biggest weakness, at least at the moment, is its lack of scalability and extensibility. The entire iLife suite is supposed to encourage creativity, and there's a menu item in most of the apps that reminds us to "Share." But how much is Apple going to open up the system to those who want to make more than clones of their skiing-obsessed photo album pages?

What turned HyperCard from a weird combination of BASIC and a proto-web database into something that's still remembered fondly by computer users almost 20 years later, was its extensibility. People looked at the app and asked, "What am I supposed to do with this?" and the app answered, "What do you want to do with it?" And it presented few limitations towards extending it and twisting it to do things the designers never intended.

What killed HyperCard wasn't Flash or DreamWeaver or Visual Basic or even Apple's Job-less Dark Ages; it was the World Wide Web. Now we're in the age of open source and non-proprietary standards and hacks, toys, plug-ins, and extensions. And now that the computer extends past a single box, Apple doesn't need to re-invent the HyperTalk scripting language to turn iWeb from a simple personal blog maker into a general purpose web-development app. It simply needs to make writing extensions as easy as it is to make a Dashboard widget, at which point any one of the ten billion scripting languages and web services and open source databases can take over.

That would allow iWeb to become a truly innovative design studio for making limitless applications, while still making it simple for casual users to post their vacation pictures. The direction Apple decides to take iWeb will determine whether it takes hold as a content-creation revolution as ubiquitous as Blogger and livejournal, or whether it just becomes a footnote (albeit a very attractive footnote, full of good-looking young people on vacation) on some Apple history website.