iLife ’11, unveiled at the latest Apple (s aapl) event, brings no update for iWeb. Users should rightly wonder what the fate of the app will be. It’s a shame iWeb is being ignored, because it made web design accessible to all levels of Mac users, but maybe it’s just time for a new model.
The design philosophy behind iWeb is summed up best in the Keynote slide pictured below, from Macworld 2006. According to Steve Jobs, software was either too simple for producing web sites that looked good, or too complex for the average consumer. Instead of HTML editing, iWeb used customizable themes and a WYSIWYG interface.
It was easy to use, and things looked good, but cross-browser compatibility proved to be difficult. iWeb’s solution caused immediate problems, most notably the creation of multi-megabyte webpages that substituted .png images for elements like text to ensure iWeb designs looked the same in all browsers. Even then, there were issues with compatibility, and the HTML iWeb generated was pretty ugly.
Not surprisingly, a large update was quickly issued that addressed complaints about generating and publishing pages. A year later, iWeb 2.0 in iLife ’08 added more themes, blog comments, photo gallery pages, widgets, user-generated “HTML snippets” on web pages, and integration with domain names hosted on MobileMe. This was a big update, and demonstrated a high level of commitment to the software on Apple’s part, but then something happened.
With iLife ’09, iWeb got… more widgets. Development had dropped off sharply. Now, with iLife ’11, the drop has ended with a splat, as any development efforts seem to have become simply code maintenance. So has the program indeed been abandoned?
It probably has, and it could be that Apple had no choice, since making iWeb work across all platforms would be nearly impossible. But it could also be the case that iWeb’s replacement will be even more elegant.
iWeb’s Fatal Flaw
The main problem is the document model. In iWeb, a single bundle is created for all web pages and websites from which HTML pages are rendered when publishing. While this allows for an incredibly rich and easy-to-use development environment, it also means iWeb documents can balloon into huge files over time.
More importantly, the document file can only be accessed by iWeb from the Mac it resides on. That means you can’t create a gallery page with pictures just taken from your iPhone, or blog from your iPad. iWeb was created before these devices really became established as tools for producing content, and now its single-location model looks antiquated.
Somewhat ironically, the solution to iWeb’s computer-centric dilemma is also built into the program: MobileMe. While iWeb does not strictly require MobileMe, server-side features like blog comments, passwords, search, and domain name association require it. The future of iWeb development is to fully integrate it with MobileMe.
For photos, that future is already here, too. MobileMe Gallery already duplicates the functionality of photo galleries in iWeb. You can even create a Flash—don’t tell Steve—widget in iWeb that links to a MobileMe gallery.
Why can’t the same services be set up for blogs, podcasts, and web pages? Now that Apple has finally announced the end of .Mac HomePages, perhaps that’s what will happen. Instead of giant documents on one computer and spaghetti HTML, we could have HTML5, Ajax, H.264, all kept in the cloud and accessed via MobileMe from anywhere.
Of course, it’s highly unlikely there’d be a way to integrate current iWeb sites into that MobileMe future, so iWeb’s past would be lost, but at least there would be some way to create “beautiful websites, so simply, so easily” from Macs and other Apple devices.
Related content from GigaOM Pro (sub req’d):