It seems that Apple have all but killed off their iLife website creation application iWeb. The last ‘real’ version was to be found in iLife ’09 about 3 years ago. Although there was an iWeb ’11, the actual application was practically the same version as the one they released two years prior to it. With the announcement of iCloud and the simultaneous death of Apple’s online storage and hosting platform MobileMe (something which even Steve Jobs admitted was a bit of a failure), it seemed pretty clear that iWeb – which was designed to tie in heavily with MobileMe – would meet its demise.
The Problem with iWeb
iWeb was actually one of the reasons that I was able to start this website with very limited prior knowledge of web design. I liked it. It’s very unintimidating for the newcomer, and that’s clearly what Apple were going for. I’m much happier and more comfortable when I can see how everything is going to look and how everything connects visually. I also like making little tweaks on the fly. For this iWeb was much more accessible to me than, say, something like Dreamweaver. It’s effectively a website-oriented version of PowerPoint, or a desktop publishing program.
However, quite early on, I spotted a few very strange behaviours when I tried to create content. iWeb likes to give you the freedom to do anything. “How wonderful! Why can’t I do that with practically any other website design application?” I thought to myself. Turns out there’s a reason why you can’t.
Firstly, I was using some very cool fonts for parts of my site. Indeed, the in-built theme I started out with used Futura for pretty much everything. Unfortunately, this is not a web-safe font (and most non-Mac users wouldn’t have the font on their system anyway). Luckily, I changed this quickly, but I was rather confused as to why there was not a restriction put in place regarding font selection. What was even worse is that I started putting drop shadows on titles, and that screws things up to the point where text is saved as an image file! My first site creation attempt was a slow and buggy mess – and that was before I tried viewing it on Internet Explorer 6!
Secondly, the impression I got that I could drag and drop anything anywhere was misleading. Once the site was published, I ended up with shapes being split up and scattered across the page, and images overlapping text instead of the text wrapping around it.
Both these cases are examples of the wool iWeb puts over your eyes with regard to how web pages actually function. Because web pages are designed in terms of style sheets and frames, manual placement of individual elements wherever you want for each individual page should not be possible without some horrible and inefficient coding. And horrible and inefficient it all was.
iWeb treats each page as an individual – not as part of a template that runs throughout your site. This means that to create new pages in a unified style, you had to keep duplicating pages. This wasn’t much effort in itself, but because iWeb treats each page as unique, even if it is following exactly the same style as all your other pages, it means that common elements are stored and loaded separately for each page.
As an example of how silly this is, consider my signature image in the header of this page. It appears in every page (and in the same place) so the smart thing would be to remember this positioning and have one copy of the image on the server. Then, that image could be referenced for each page load. Because it is the same image, your browser wouldn’t have to keep reloading it, as it would be stored in your local cache. Instead of this process (which is what happens now), iWeb would save a new copy of that header image for each and every page I had on my website! This means that every time you navigated to a new page in my site, it would have to pull out the same image but from a different location. As far as your browser knows, this is a completely separate image, so it has to fully load it each time! This happened for every single image element in my pages, meaning that my site was horribly slow to load and used up far more storage space than it should have.
Finally, iWeb was designed to tie in closely with MobileMe. It meant that Apple wanted you to pay an extortionate yearly subscription fee for hosting your site. In return for this, your site would function with all the bells and whistles that they intended. I had no intention of doing this, of course, so I had to sacrifice automatic FTP updating and things like an inbuilt commenting system – something that is practically essential in a blog-based site.
Alternatives to iWeb
I stuck with iWeb for a long time for a few reasons. Firstly, I’d reached a steady state where I’d learnt how to get what I wanted out of the program by invading it a little. I discovered the deeply buried theme files and edited them to my liking. I’d learnt what fonts to use and how to avoid putting things in my pages that would create major slow-downs. The limitations and inefficiencies were frustrating, but I somehow hoped that some of these issues would be addressed even slightly in future program updates. Once I heard that iWeb was pretty much dead, and that there was therefore no potential for improvement, I thought it would be a wise time to ditch it altogether. I knew the process would be painful initially, but I was looking forward to having a much cleaner and more functional website.
Hence, I started looking at some alternatives. I wanted something that would allow me to create and maintain a site with dynamic content easily, which meant something with a large visual editing component. However, with the knowledge I’d amassed over time regarding web design, I was less afraid of dabbling with a little code if necessary.
Desktop Based Applications
Naturally, the first applications I tried to look for were direct iWeb equivalents. I tried a few of them out to see how easy it would be to customise my site to my liking, and what sorts of new things I’d be able to do (as well as the obvious issue of how easy it would be to transfer over a whole other website).
This was the first application I found when searching for an ‘iWeb killer’ and it’s one that I’ve come across in the past. It is less of a WYSIWYG experience compared to iWeb, but one that allows your end product to be more standards compliant. However, I found it to be way too fiddly to get things looking right. Whilst there are a lot of customisation options, you are still bound to built-in themes. These can be edited in a similar way to iWeb’s themes – via the back end. However, this usually involves editing chunks of code, which can become tricky and unintuitive.
Failing this, there are a lot of ‘plugins’ that can be downloaded for RapidWeaver that allow you to add tables and frames to your page. However, I found it strange and silly that many of these things aren’t built into the application itself. As an example, without the ‘Stacks’ plugin, there is no easy way of arranging your page into columns or framed segments. This wouldn’t necessarily be a problem on its own, but everything that even marginally improves RapidWeaver’s functionality must be paid for. This includes themes. Just to recreate my iWeb site on RapidWeaver, I would probably have had to spend in excess of $100. iWeb, whilst unwieldy, at least did it all for free.
Put simply, Sandvox is ‘iWeb Plus’. It’s pretty much exactly like iWeb, but with a few more features. It also generates cleaner code. For someone familiar with iWeb, it is instantly usable. However, I came across niggles in designing pages that were somewhat similar to RapidWeaver. Still, I liked the application, but I never really felt like it was much of a step up from iWeb, and there wouldn’t have been much point in expending the effort of migrating my site to practically the same program. It would have been like moving from solitary confinement to solitary confinement in a room that was a couple of square metres larger. Sandvox doesn’t really give you very many possibilities of expansion beyond the iWeb experience, and is certainly less advanced than RapidWeaver.
Goldfish and Freeway Pro
These applications gave me a much more desktop publisher-like experience than the former two. This was nice, as it appeared to give me more flexibility. However, I found that the freedom was actually a bit too great. I felt like I was designing isolated sheets of A4 rather than a contiguous, flowing web page. These tools were probably not designed for dynamic content such as blogs, and so it seemed like I could only really create a blog by creating individual static pages and manually linking pages together. This was actually a step down from iWeb in terms of functionality (though the page generation may well have been cleaner)!
RapidWeaver seemed to be the best option as far as the desktop clients were concerned, but I still wasn’t prepared to put my faith in it entirely. As I had pretty much exhausted the list of programs that I was after, my next step was to look at content management systems that were remotely stored and edited, rather than locally on my computer. I never really liked the idea of online editing, but there’s no harm in giving these solutions a try.
Blogger, WordPress.com, Tumblr etc.
I’ll give a brief mention to these ‘ready-made’ blogging infrastructures. I considered them when I first created this website, but discounted them almost immediately because I didn’t like the lack of control I was afforded. I would be lumped in with millions of other users with no real means of differentiation or sense of identity. A blog, which to me is a form of expression, becomes redundant when you surrender the extent to which you can express yourself. This is the reason why I still look down upon these platforms, and why I wasn’t going to consider using them this time either.
I’d mucked about with WordPress in the past, and although I liked it, this was at a time when I was less comfortable at fixing and playing around with code directly to get what I wanted. At the time, WordPress was on version 2, and quite a bit less intuitive than it is now. (Note that WordPress is a content management system that is found on WordPress.org, but WordPress.com is a closed version of WordPress that is designed to function as a fixed, ‘ready-made’ blogging tool like Blogger)
Once I tried it again, I knew it was the right direction for my site. It is completely flexible, as you are directly in touch with the source files right from the get go. At the very least, you need to understand how everything pieces together so that you know where to look if something goes wrong, or if you want to change anything. The great thing about this is that it forced me to get my hands dirty and play around with code. By doing this, you get a real sense of the things you should and shouldn’t do when designing your site.
Like RapidWeaver, WordPress relies on themes and plugins. However, because WordPress is open-source, there is a huge support base for all related things on the internet, and almost every add-on or bit of code is freely available. Once you get more proficient at PHP and CSS editing, the only real limit to the things you can do is your knowledge of the code and your imagination. This is the kind of open-ended potential I was after. If you visited the old site, hopefully you’ll appreciate the difference!
Drupal and Joomla seem to be the two main contenders to WordPress’ online content management system throne. I haven’t really looked into these two enough to be able to comment on them, but I do feel that these types of open-source, remote packages represent the best option for those looking to make an individual and powerful website that is very easy to maintain and update with rich content.
What next for Apple and website creation?
One word – iCloud. Apple announced this as the replacement to MobileMe a few months ago, and it was this that effectively signalled the end of the road for iWeb. As I’ve discussed earlier, iWeb really creates horrible websites from a usability standpoint, and this goes quite against Apple’s own ‘clean yet functional’ design philosophy. Although you’ll still be able to use iWeb to create your own sites as long as you have the application on your Mac, the fact that Apple have stopped including it in new Macs with the release of OS X Lion suggests that they really want you to stop using it, and won’t really offer any support to people who run into problems with it.
One option is for Apple to call it a day when it comes to web/blog designing tools. They may just accept that there are enough good alternatives out there for them not to get involved. But does that really sound like Apple to you? After all, if anybody is capable of consolidating available technologies into a neat and elegant package, it’s Apple.
With iCloud, I think Apple may well go the way of self-contained blogging hosts like Tumblr and Blogger. By ditching the application-based method of content creation, they can make sure that everything runs optimally and smoothly within their own environment. This includes things like proper indexing, search engine optimisation and so on. With no software on the user end, it makes it easier for Apple to keep themselves up-to-date, and also gives them the degree of control that they desire over how people should and shouldn’t go about doing things.
Apart from the fact that they are easily capable of creating something that looks and feels a lot more polished than something like Blogger, the other big draw to a platform created by Apple is down to the fact that so many people are already part of the iTunes infrastructure as a result of the iPod, iPhone and iPad. Because of this, and because of the syncing features that Apple are planning to offer with iCloud, they can allow you to access this repository of data to add dynamic content to your website. For example, people could have their top 10 most played songs on iTunes listed on their front page, and this list would be dynamic as it would pull data from your desktop and mobile versions of iTunes. It would allow you to put a map with a live geolocation flag indicating your position via your iPhone. It would allow you to post new content easily from any iDevice. It could pull up your current availability from iCal and the calendar on your iDevice.
Yes, all of this technology is currently available, but it will be much easier to implement successfully if everyone is already part of the shared information infrastructure – which is certainly the case with iTunes.
All I can say is – watch this space. If this is the direction that Apple choose to go in, then it could even give social networking sites like Twitter a run for their money. Whilst I’m happy with my decision to switch to WordPress, I’m also interested (as always) to see how the future of content creation will unfold.