What's Broken in iWeb: A Wishlist

When Apple announced iWeb, I was seriously impressed. Rather than being a utilitarian HTML editor, they delivered a website tool that simply did seemingly everything, and a few more things, too. It was more than I was expecting.

Sometimes, after getting exactly what you want, you realize you really want something different. The good news is that iWeb 1.0 is a great start, and its problems should be easy for Apple to address.

Introducing iWeb presented the new iLife application as a novel approach to publishing web content for people who have no interest in messing around with HTML code. Like Pages, iWeb is template driven to the core. Templates provide a lot of iWeb's unique brand of utility, but also are the basis for the app’s most frustrating limitations.

Templates vs. Skins

In iWeb, once a template is selected, a large number of design decisions are fixed going forward. Most of the elements in a template can be modified, but once you start into an iWeb project, it is not practical to swap the design into a different template. Sandvox, in comparison, employs a very different system where you can pick a set of design elements that 'skins' your web content into different flavors.

It is impossible to deliver both approaches. I prefer Apple's use of structured templates that serve as a starting point for further creative exploration, but the templates provided in iWeb beg for more customization potential.

Apple recently rolled out a second, free set of templates in a minor update for iWeb. All together, there are eighteen predefined templates that allow users a wide range of variety. However, there are some key features in all the templates that are not editable: some templates have gimmicky graphic elements that can't be deleted, which locks the overall style; all of the templates have unique navigation menus that are unchangeable; and each template has a blog and podcast page that involve automated components that can't be edited at all.

The templates in Pages are just a starting point, but the set limitations in iWeb's templates really prevent users from moving very far beyond the original design. Each template has a strong theme that seems to impose too much style. Some themes force a text field to be in all caps, for example. Why?

The differences in style elements for navigation menus in each theme make it impossible to seamlessly mix and match pages from different templates, because they can't be edited to match each other. Ideally, there would be more variations of pages within a template set, or even better, a...

Template editor

Apple's templates are stored within in the iWeb application, and can be modified by the most determined of users, but it's a violently steep learning curve. Templates are dense and opaque XML files.

Apple really needs to unleash iWeb’s template designs by bundling their in house template editor. That would serve to create a market for iWeb designs alongside Dashboard Widgets and Automator Actions. The availability of third party designed templates would really open up iWeb's appeal.

At a minimum, Apple should make it possible to do limited edits to the way navigation, blog and podcast elements in a template work. In particular, adjusting the size, style, and positioning of blog pics that appear next to the entries on the index page, adjusting the color and font of the blog entries, and a way to edit the font, color, size and positioning of navigation links.

Fixed Features Flaws

Along similar lines, while most template pages can be heavily modified and then cloned with the Duplicate command to create additional pages with identical modifications, entire blog and podcast designs can't. That is, entries can be cloned, but not the bookend set of blog index and archive pages. Duplicate should just work everywhere.

Another aspect of iWeb pages that can't be edited is the centering of pages in the web browser. This results from Apple acting as a good taste guide to keep iWeb pages looking pretty decent even in the hands of the most brutally awful and clumsy designer, but it would be nice to have the tools available anyway.

Clearly, Apple is trying to keep iWeb users from generating a horrifically painful mess of pages on the order of MySpace. I'll give Apple an A for effort, but please: leave the training wheels on out of the box, but at least let people take them off at some point.

Perfecting Photo Placement

Another strange oversight is the way placed graphics can not be manually tweaked within an existing mask. Currently, if you drag a photo into a graphic zone in a template, it automatically chooses how to frame it. It would be ideal if you could simply grab the photo within the masked off region and slide it around inside the clipping region (frame) as desired, perhaps by command key dragging.

Instead, you have to unmask the photo, position the raw photo, then create a new mask. The default area for the new mask is never set to the former (or a reasonable) size, so this is more manual and tweaky than it should be.

(Update: I’m so happy I was wrong about this one. Photos within a mask, and the mask area, can be edited by double clicking on the photo region. Thanks to Brian Peat for the heads up.)

The Blog Entry Dating Game

When I first looked at iWeb, I was afraid it did not allow blog entries to be dated in the past, before other existing entries. Fortunately, it was just non-obvious that the date is set using the blog entry list, not on a blog page's inspector panel. There is some internal magic for keeping track of the dating on generated blogs pages, but unfortunately, it doesn't work correctly yet.

When a new, back dated blog entry is created, iWeb correctly displays it in chronological order on the index page by the date assigned, and also correctly adds the new page to the top of the RSS feed, but I found that the navigation buttons on individual blog entry pages don't correctly follow the order presented by the index page. Instead, they seem to follow the internal posting date stamp. That is confusing and mysterious for readers, who can see the date assigned to the posting, but have no way to know when entries were actually created.

You can observe the error by trying the next and previous links on the first entry in my blog here: A New RoughlyDrafted. It should send you back to the Archive page, but instead, iWeb has it out of order because I deleted and rebuilt the entry. The navigation links are created by the page’s creation date, not by the date I assigned it, despite appearing correctly on the index and archive pages.

Extra Plugins, Please

It's not hard to understand why Apple hides any and all access to HTML in iWeb. Once some random code is edited, there is no safe way for iWeb to incorporate the modifications and remain editable. The only way to tweak iWeb generated pages is to export pages and edit them afterward, a step that needs to be repeated every time pages are pushed live. Apple could account for this limitation by adding more prefabbed plugin elements.

Apple supplies a small palette of elements to plug basic features into pages: a page counter; XML subscribe buttons for blog, podcast and photocast pages; and an email link button. Apple should replace their Email Me element, which just inserts a mailto: link to the user's email address, with a simple javascript that obscures the address and makes it harder for spammers to skim email links from iWeb generated pages. This would be easy to do, and a nice touch.

The program sorely begs for more extensible elements, such as the ability to imbed arbitrary HTML for things like meta data tags, alt tags, and javascripts for third party tools: more sophisticated web traffic tracking, site search, comments, ad sponsors, and other features. Many of the examples I could think of compete with .Mac services, but Apple should open up an API to allow third parties to create the plugins anyway, because .Mac needs competition to spur innovation and stay healthy.

Apple could also make .Mac far more compelling by borrowing features from a range of existing websites. Many of these features could work hand in hand with iWeb. I explain how next in an Introduction to .Mac and wishlist.