Woe Is iWeb

By Cody in Commentary, Usability

After our post about the inability to print pages created with iWeb, I decided to take a crack at the problem.

The first thing I did was to determine the exact cause of the problem. It turns out that the body_content <div> unnecessarily has the overflow property set to hidden. Since the <div> is relatively positioned it overflows the first page when printing, and therefore the overflow is hidden. By setting overflow: visible the problem would be fixed.

Unfortunately, iWeb writes this property as an inline style directly on the <div> itself, so there’s no way to override it. Even !important declarations with high selector specificity in external stylesheets don’t take precedence over inline styles. (This is unfortunate, in general.)

It was at this point we received a very friendly email from Mike Lee. He helpfully showed us that the printing problem doesn’t occur in Safari or when sending the page via Mail. This does make it clear that the iWeb developers were writing iWeb primarily for Safari. Not everyone is using Safari, though (we had been using Camino and Firefox). And while the Mail workaround let’s us print the page, it’s a big hack.

Mike’s suggestion was to write an XSLT stylesheet that would transform iWeb’s misbehaving inline CSS into something more palatable. And this is what I came up with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <!– The identity template. –>
  <xsl:template match="@*|node()">
    <xsl:copy>
      <xsl:apply-templates select="@*|node()" />
    </xsl:copy>
  </xsl:template>
  <!– Add an ‘overflow: visible’ declaration to the body_content div. –>
  <xsl:template match="*[@id=’body_content’]/@style">
     <xsl:attribute name="style">
       <xsl:value-of select="concat(., ‘ overflow: visible;’)" />
     </xsl:attribute>
  </xsl:template>
</xsl:stylesheet>

This XSLT stylesheet uses an identity template to copy all attributes and nodes, changing only the ones overridden by other templates. Here, the only thing we want to override is the style attribute on the body_content <div>. In this case, we just concatenate the required declaration to the existing value of the attribute.

Unfortunately, when trying to run Mike’s page through this transform, it turns out the XHTML that iWeb generates is invalid. One of the (numerous) problems is that the <link> tags aren’t closed in the head. This makes the XSLT engine choke. Unlike the cause of the printing problem, though, this isn’t a simple browser incompatibility between how Safari and Camino interpret the overflow property. It’s just shoddy work on the part of the iWeb team.

Mike gave another suggestion: use Tidy to clean up iWeb’s mess. Since OS X 10.4 comes preinstalled with both the GNOME xsltproc utility and tidy, all that needs to be done is

tidy < input.html > fixed.html
xsltproc iweb_fix.xslt fixed.html > fixed.html

This little fix is something that maintainers of iWeb-generated pages will have to apply themselves before uploading their websites. Perhaps like so:

find /path/to/website/files -type f -iwholename '*.htm*' -exec tidy -modify {} ; -exec --output {} xsltproc /path/to/iweb_fix.xslt {} ;

Share This

Concerning iWeb

By Matt in OS X, Commentary, Usability

I’ve been reading and enjoying Mike Lee’s new blog for a few weeks now; it’s entertaining, smart, and well-written. As I was heading out the door one morning recently, I noticed he’d posting something new: a rather long piece concerning all things economic, called On Selfishness. I wanted to read it, but not right then, and preferably not on a computer screen.

I went to print the page, but opted for a print preview first; one can never be sure how a web page will be printed. Sure enough:

Where is the rest of the essay? Only the first page is printing.

It wasn’t difficult to guess why this was happening — it’s usually the result of content that’s in a box whose position isn’t static. (See Positioning schemes in the CSS specification for more on this element of web design markup.) Mike uses iWeb to publish his site, and the code that iWeb generated floats and absolutely positions blocks of content in order to make everything look nice. iWeb apparently has enough foresight to generate a print stylesheet, but it doesn’t include appropriate countermeasures for the site’s relatively and absolutely positioned boxes.

At first I tried to download the webpage and hack at the CSS to see if I couldn’t produce something better, but everything I tried had no effect. The massive amount of external and inline styles iWeb generates are so tightly wound around one another that it was difficult to tell which element(s) I should be targeting.

I became frustrated enough to stop trying, and ended up copying and pasting the text into another document and printing it out that way.

It’s no secret that iWeb generates some muddy markup — Todd Dominey pointed out the multitude of issues with the first version of iWeb early in 2006. The meta tags for Mike’s blog reveal he’s still running on iWeb ‘06, but, unfortunately, an upgrade to iWeb ‘08 wouldn’t fix the problem — my own tests with iWeb ‘08 reveal that the generated code is much the same, and the printing issue remains.

There are other problems with iWeb’s webpages — the URL for posts is a prime example:

The web development community ignores iWeb for a reason — it flagrantly disregards the clean, refined standards they have long championed. But whether the code is valid or the site adheres to various standards is much less important than it being easy to use in a variety of media. As Mike himself says, “I don’t want this site to be about what a good (or bad) web designer I am. I want it to be about the message, whatever that might be.” So what do I suggest? Personally, I’d like to see Mike’s content on a different blogging platform, because the other solution — an update to iWeb that generates better print stylesheets — may be long in coming.

He’s a busy man, though, and doesn’t have time for a different platform, and that’s certainly understandable. I’d like to suggest a third solution: that we fix iWeb ourselves. Who’s “we?” Well, Mike knows iWeb well and is comfortable with it; perhaps he could take a look at the print stylesheets and tweak things. I’ll even dive back in myself. And of course, there’s our multitude of readers — together we can find a way! “Lazyweb?” Hardly.

Share This

Constructive Criticism: OS X Firmware Update Notifier

By Matt in OS X, Constructive Criticism, Design, Commentary, Usability

If you have a MacBook Pro, you may recently have been asked to update your firmware. Firmware is the embedded software in your hardware. (A PC’s BIOS is a well known example. See Firmware on Wikipedia.) This is the dialog box, which serves as both a notification and warning window, that’s supposed to guide you through the process:

There are a few things wrong here, and they all have to do with the fact that, for beginner users, this is a potentially confusing process already.

First of all, what is firmware? And do I have an Intel processor? It doesn’t seem like a lot of thought or time was put into designing this dialog box.

Unlike software updates, which can occur in the background and at most require a few “OK” clicks, this firmware update presents a challenge: it requires the user to perform a special action on their physical computer, one for which the instructions can’t be displayed on the screen while it’s happening. So it makes sense for Apple to recommend printing out the instructions or, for those without a printer, writing them down. But how do I print these instructions? I think a button would help:

Apple does provide more information about these updates. Links to the support document for EFI Firmware Update 1.4 or the more general overview of firmware updates for Intel-based Macs would be helpful, but they’re strangely absent.

In the interest of eminently usable software, I present a redesigned alternative:

As always, we welcome and appreciate your comments.

Share This

Nice Touch: Search Stores by ISBN

By Matt in Nice Touch, Commentary, Usability

Did you know that Amazon’s search field accepts ISBNs? It does — both the 10- and 13-digit variety. Type or paste in an ISBN, hit “Go,” and you’ll be taken straight to the book page. It’s perfect for when you’re searching for a book whose title isn’t very unique. (Sorting through the various editions of “The Elements of Style” is how I found this feature.)

It’s the sort of obvious, hidden feature you don’t think about until you try it. You’re hoping it will work, and it does. Sweet.

(This also works on Half.com, Barnes & Noble, and of course Borders, which is just an Amazon storefront.)

Share This

Constructive Criticism: The Library Postcard

By Matt in Constructive Criticism, Design, Commentary, Usability

Okay, so maybe I was nitpicking when it came to the postcard, but I stand behind my critique! “It could be better,” I said, and I meant it. We’re as much about construction as we are about criticism here at Sakuzaku, so I’d like to present a hypothetical redesign to the Hawaii State Public Library System book request notification postcard. Click the image below for a closer look.

To Consider

• Braille would be a nice addition and would make the card much more accessible.
• The backside of the card currently lists the phone numbers for every library on the islands. It would be nice to have the website URL listed there as well.
• I tried to avoid any solid blocks of color or images in the interest of saving ink.

I still think the postcard itself is obsolete, and I should have been able to receive an email notification. For those without email, though, this should suffice.

What do you think? Leave your thoughts in the comments here or on the photo page.

Share This