iWeb is not evil!
Subject level: Intermediate
When Apple launched the new iLife '06 suite at MacWorld SF two weeks ago, there was one completely new application in the pack: iWeb. iWeb is, in a nutshell, a blog publishing application for the casual Net user. However, several Web Standards advocates have gone into a bit of an uproar concerning the source code produced by this new Apple application. …all I can say is...WTF?
, It's so atrocious that it reminds me of Frontpage-generated code from the late 90s
- wait a minute guys, let's get some proper focus here!
When I watched Steve Jobs give a demo of iWeb during the MacWorld Keynote, I had two distinct thoughts:
- That is amazingly simple and powerful… wow!
- I am seriously wondering what the source of that page is going to be like…
I haven't quite had the time to go pick up a copy of iLife '06 myself, but some others have, including some who did it just for the sake of testing the source generated by iWeb. Their responses have been predominantly negative, as the iWeb source code doesn't quite use any semantic markup or clean CSS techniques.
In iWeb's defense, the markup does validate as XHTML 1.0 Transitional. That, on its own, is more than can be said of most content-publishing tools available today.
Nevertheless, People have gone so far as to say they were "ashamed" of being a Mac fan, given iWeb's code. They say Apple should have been innovative and different from competition by releasing a product that "spits out better markup than this." I think people are missing the bigger picture, with all due respect to those I've just quoted.
Not for you and me…
The issue, however, is not whether the markup is clean and easy on the eyes, semantically rich or (as is the case) a nightmare of div's. iWeb is not trying to be a replacement for Dreamweaver or a competitor to Microsoft's upcoming Expression Web Designer tools.
The "Standardistas" have assaulted iWeb in ways I'll probably never understand. Whoever said you had to use iWeb to build your next client website? It's a relatively simple tool for publishing a blog and some photos, not Apple's response to Macromedia (or as should be said these days, Adobe).
It's been on my mind for some time now, but I feel that the standards-savvy web designers of the world are starting to live in a secluded little 'clone' of the real world. The response to iWeb has given me the idea that these people were expecting the application to be made according to their standard of work, which is to say, extremely high quality. People like Todd Dominey do a fantastic job at putting high-quality, semantically rich, valid and clean CSS on major websites, and I applaud them for their work. That doesn't stop me from applauding Apple for their work on iWeb, though.
What's missing is the bigger picture: iWeb is not here to please to the scrutinous opinion of the web standards-advocates of the world. Their demands are set against their own situation, which represents at best 1% of Apple's targetted iWeb audience, and at worst not even a thousandth of a percentage.
Standardistas create their own sites generally by hand, through manual CSS and XHTML authoring. They like to play with their site, the system that powers it, add little features of their own or throw a bunch of plugins into the mix. These people are extremely unlikely to suddenly drop all that in favor of using iWeb, and Apple knows this just fine. They know that the Standardistas, such as myself, are not an audience that's likely to use iWeb. Instead, iWeb is for an entirely different group:
…but for them!
Rather than you and me, iWeb is for your mom, your dad, your grandmother or your computer-illiterate sister. It is made to let them publish a pretty website with their own pictures used in the design and nice-looking text in interesting places.
iWeb pages should be easy to create, easy to manage, and, and this is very important, they should work in all browsers without any issues!
When we Standardistas create a website for one of our customers, we hand-code the CSS to make sure that it works across browsers and operating systems. This more often than not involves some specifically tailored CSS hacks to make certain browsers follow suit - not necessarily IE, but usually, yes. This approach is what we're used to, and it's how we work and work well.
That approach is no option for a computer application like iWeb, though. You simply can't create CSS hacks on-the-fly as an application. So what does Apple do? They innovate in the aspects that matter (to their targetted audience): usability.
So what is the usability like, then? Well, from what I saw of Steve's demo of the product, it seems that iWeb is nothing short of fantastic. It looked amazingly simple to create an interesting and cool look for your blog pages, with the ability to just plug pictures into areas, rotate them in degrees and alter the position, look and content of text sections, et cetera.
Organising the various pages or areas of your own little site, including a gallery section and more, seems to be just as easy, which means that I can tell my mom to go start a blog with it (well, once she gets her Mac Mini, anyway) and know that she'll be able to figure it out on her own after that. That's not entirely unique, of course, but that simplicity combined with the spectactular-looking pages that iWeb creates most certainly is.
People like my mom couldn't care less that the site's source code isn't clean or easy to read. The people who would read my mom's blog and look at her pictures wouldn't care, either. Them, their friends and their friends' friends who might all become interested in publishing with iWeb, all wouldn't care either.
Why do you and I care? Because it's our job to care. It's our job (self-imposed or by actual employment) to create standards-compliant websites that have a clean, semantic structure and nice and pretty CSS code. It's what we like, and that's a good thing, because it makes the pages we create totally cool. It's also a process that we can't expect from a tool that has completely different purposes and goals than we do.
That doesn't mean there's no room for improvement in iWeb's code, though!
iWeb iMprovements
For starters, they could use something like my initial.css file to neutralize default browser styling of the elements, without the risk of overdoing it (such as you get when you use the * { … }-approach). This could then battle against things like this:
<div class="paragraph Body" …
Furthermore, they could use a bit of post-processing computation (which I'm sure is no problem, considering the amount of processing done on publishing anyway) to clean up the styling. All the inline styling on the "paragraphs" that are exactly the same can be combined in one extra class rule, and thus a gigantic amount of the markup bloat could be solved.
However, let us not forget that iWeb is a very first release, and as with any application out there, the first release is the one that has the most room for improvement. I'm definitely looking forward to seeing a big update to iWeb. It won't make me use it for client websites, and it never will because it will never be made to suit that purpose. I'll be suggesting my friends and family to use it, though, even the current version. It's a perfectly good tool for them, and that's what Apple is about: a good user experience.
You and me? We're not users, we're the professionals. Let's remember that.
- Related reading:
- iWeb's HTML markup. Not so good.
- iWeb code works, but does it do the job with standards?
- iWeb-Generated Source Code is Awful
- Microsoft Vs. Apple (again): The New Battleground
- Photo , iTunes, iForgotToTest
- iWeb generated code is crap
Bookmark: 
Newsvine 
del.icio.us 
Digg
Comments
Subscribe: atom, rss, ..what are feeds?
Archives
- Popular Posts
- Starting with CSS: revisited
- IE7 beta 1 release
- Starting with CSS-based design
- Debunking the price myth: Apple vs. Dell
- Typography: serif vs. sans-serif
- Accessibility Rules & Tips #1: simple steps to make your website more accessible
- Review: System of a Down - Hypnotize
- Announcing: Happy Clog!
- AJAX and Accessibility
- Introducing V8
- Recent Posts
- Times are changing
- A change in direction
- CSS hacks: useful, evil or …laziness?
- Updates on the web
- Pink for October
- Flickrlicious Screensavers with iPhoto 6
- On FACE updates and getting published
- Great speakers I admire
- A new passion
- Standards-senses tingling?
FlickrFire
All times are in CET. It is now 19:45.
I just really dispute that using semantic elements, like headings and lists, *even in the presence* of all those inline styles is really so hard to design into an application.
Agreed, I think my point about using my
initial.cssdidn't specify that nearly as clearly as I originally had it in mind. My (complete) point with that is that they can replace the semantically meaninglessdivs with proper elements without side-effects.The primary thing that iWeb can and must improve upon is the use of semantic elements, currently lacking, desperately needing.
I disagree, just because their target audience certainly isn't web professionals like us, doesn't give them an excuse to produce such sloppy code. The problem is, just like with every single WYSIWYG editor I've ever seen so far, that they've designed it to work backwards.
I'm not exactly sure how it works, I couldn't find much in the way of demonstrations or good explanations, but especially because they seem to rely heavily on templates, they could have been designed with at least the most common semantic markup in mind, like headings, paragraphs, blockquotes, lists, etc. The user should be able to say "This is a heading, level n" and the template should take care of it with a simple h1-h6, which is already pre-styled in the template CSS. Similarly for any other element. <div class="paragraph"> is just insane, it's like they've never heard of a P element which would have been perfect.
Of course, I wouldn't expect such a tool to handle really complicated page layout techniques designed by the user, but such layouts could already be done within the templates so that the user only has to pick a colour scheme and a basic layout/design, and then fill in the content, add images, etc.
The user doesn't even have to know what an h1 is, or a p element, or any other element. They'll just see a heading, a paragraph, a list, etc. layed out visually on the screen. There is no excuse for sloppyness.
And frontpage wasn't meant for professionals either? So I guess that piece of software is off the hook too.
Faruk, please, you have got to be kidding me. Are you honestly trying to justify this? You're effectively undoing all the work you have done and were planning to do.
iWeb is not innovative in any of the technical areas. It belongs right in the same area as the other mediocre WYSIWYG software.
Lachlan already said what I was thinking. There is simply no excuse for sloppyness. Not even the almighty "they can't do anything wrong" Apple.
What happens when my computer illiterate sister starts thinking that she knows what it takes to make websites (what she just did using iWeb) and tries to sell iWeb made sites?
I have to agree with Lachlan and Jeroen. There's no excuse for sloppyness, and there's _REALLY_ no excuse for creating crap like '<div class="paragraph">'.
I was going to say something about how this should be aimed at advanced amateurs, because it requires your own webhosting (probably) and ubernoobs don't have that, but then I found this, iWeb generated, code:
(Editor's note: large divitis example here, stripped by the system)
There is no way you can justify divitis that bad... And this isn't an isolated case, this construction (with two divs that do nothing but contain more divs, without even being styled!) occurs more often in this page ( http://theubergeeks.net/iweb/Welcome.html ).
I'm not a standardista, not by a long shot, but this code makes me shiver, in a Very Bad Way (tm). There's cases where there's eight levels of div's in an insanely simple page layout.
I'm sorry to say, but the backend of this thing is bad, really bad.
What you're saying is that you'd rather have outward ease of use and pretty-shiny-ness than inward quality and durability. To compare to cars, this is like the Ford GT. It's a definite fuck-me-on-the-hood-with-the-engine-running-hot car, and it's incredibly fun to drive, but you'll have to stop every 3 yards to fill the gastank and every 50 kilometers to have it serviced.
Oh, and even if I replace lesserthan signs in the brackets with ampersand l t semicolon, it still manages to dump the whole thing as html into my browser. I'm too lazy to try and figure this out, not to mention that I should do something useful now...
Faruk,
My first thoughts were 'WOW, I like the look of this' secretly knowing what monsters probally lurk within.
I can understand your point and can only comment so much as I know it is not meant to compete with Dreaweaver etc; It's meant to be for non-technical users.
The thing is, as a web developer I have had many a client say "I use Frontpage at the moment, it was all going fine till everytime I write something the page breaks.". What's stopping this happening with iWeb. The
divitus mentioned in your comments too... Apple have enough resources to make it clean and cut but that's not really nescessarry, true.. Apple's users are mainly creative types but the ones that'll be using this, have no care on how semantic it is and so they're less inclined to provide it.The worry I have is if we say "Yeah, fair enough... It's meant as an easy alternative", it'll end up the new frontpage and we'll be swarmed with nasty pages.
We Web Standardistas take it upon ourselves to improve the web for what it is and we do a good job I think so really, it's not unfair when we try to change this.
Lachlan,
That's the thing - that's asking for too much from the (clueless) user already.
On this, I agree completely. They could have used at least some semantic elements, which I do point out in my post.
This would severely "cripple" the user's freedom, which is why I think they didn't opt for that. They're offering the user the freedom to create really complex CSS-based layouts without making it impossible for a computer illiterate to use.
Hayo:
Let's go:
- no proprietary elements
- no proprietary attributes
- no proprietary values
- no table-based layout
- valid XHTML 1.0 Transitional
- CSS-based design
If you want to compare Frontpage to iWeb, please take the above into the equation, otherwise you're comparing apples to oranges.
Jeroen:
See my point above to Hayo. There's quite a difference. I'm not saying the iWeb code is good, I'm saying let's remember how this world works. And provide suggestions to the iWeb team so that they can clean up the code and add semantics to the pages. This is necessary, yes. But expecting Apple to create a system that's perfectly tailored to our needs is asking for too much, at least for the first incarnation.
Sjors,
Then at least we'll see some pretty pages that validate and use CSS for layout. That's a big step forward as it is.
Also, iWeb is far too limited to really create company websites with and such.
Jochem:
Not me, Apple. It makes sense for Apple to have that for this first incarnation product, which probably has been developed in less than a year's time (wow).
What I'm saying is this: it's far from perfect, but saying it's the new Frontpage is stretching it. That's neither fair nor helpful, so it's not going to do anyone any good. Be critical, but be realistic, too. And come up with suggestions for improvement.
Also, you don't need your own web hosting, necessarily. Just a .Mac account would suffice, and that's certainly not a geeky or tech-savvy thing to have.
Zach:
Well, you're right in that we certainly shouldn't just ignore the source code. It needs work. It really does. But it's not quite the seventh layer of hell either, and if you look at the interface for the user, that's something unparalleled.
No one was ever born with the ability to do magic right away.
Frontpage 2003 actually uses p tags - so in a sense it's _more_ semantic than iWeb..
I'll give iWeb this: it's so close that with a few p-tags and external css (which could just be a cleanup on publishing) it'd be quite alright.
And no, validation isn't enough of a saving grace here.
James: exactly, they're already quite close.
Frontpage 2003 was also a pain to use, and didn't produce anything that looked nice. And they spent 7 years on it.
The importance of iWeb lies in the fact that it makes it a lot easier for a lot of people to participate on the web.
To my mind it thereby falls in the category of tools, like blogging interfaces on sites like blogger, flickr and phenomennae like MySpace.
The results it will produce will not always be pretty, both on the viewers end as well as on the code end.
It is aimed at a different level of web-participation. And therefor not evil.
Please, a suggestion for an absolute source code dummy: Should I start creating webpages (for personal use) with iWeb or Freeway Express?
I can't write a single line of code and I'm not willing to learn it, so it just has to work and look good.
Thanks a lot!
Peter
I would like a car. A 1980's Skoda, or possibly a fiat 500. But i don't want to learn how to drive. It's for personal use only. Which one is best?
...
You're missing the point: I know how to drive, and I want to have a car that runs although I'm no mechanic (and I don't want to learn how to take the motor to pieces and put it together again).
Got it?
I got it. In that case you shouldn't go for the Lada, because it will fall apart without you knowing it, and as your gearbox trails behind your car on the highway, people will question your choice.
Also, if you don't know how your engine works, you might have to find out the hard way your car doens't like it when you put diesel in your petrol engine, just because diesel fuel is cheaper.
Yeah, i love car analogies :D
To all you purists out there, it sure is great that you can do the things you say you can. For that i commend you, but lighten up will you? We are all good at certain things in life and just because we are good at that, we shouldn't go smacking down those that aren't.
I for one could care less about how the code looks or doesn't look. I would also guess that a sizeable majority of the intended users of iWeb could care less about the code too. If it works for them, so be it.
It's like this: my favorite hobby or interest is skiing. I am very, and I mean very, good at it. I would take my chances against everyone one who has posted. I have the best equipment money can buy, ski at the top resorts, and am proud of it. But, and this is huge, I certainly don't look down on someone who is trying out skiing for the first time and using rental equipment. We all have to start somewhere.
Yeah, they would probably ski a bit better using new equipment, but why waste all that money if you don't like it. The point is, for some people, this kind of webpage (iWeb products) is a great way to introduce people to publishing that ordinarily would not.
So Faruk, thanks for defending it and pointing out that yeah, it probably could have been a bit better, but for its audience, it will do just fine. The rest of you, get over yourselves. We just aren't that impressed.
And frontpage wasn't meant for professionals either? So I guess that piece of software is off the hook too.
Two things:
1. RapidWeaver for OS X is much more semantically correct than iWeb. Apple should hire those guys to make iWeb.
2. Saying iWeb is OK for them, but not for us, is a bit short sighted. It's not good for the web, period. If iWeb was more semantically correct, you can bet it would be a lot easier for people like us to create themes for it and make a business off it.