Nice Touch: Tips Pre-Calculated on Restaurant Bill

By Matt in Nice Touch, Usability

Perhaps some of you have already seen this, but we were recently impressed at a restaurant upon noticing the tip percentages for our meal printed on the bill. Check it:

You can even choose from three levels of benevolence. Have you run into this before, and do you find it useful? We think so, but do you find it tacky? Do you not like being told what to tip? Would a split-up of the cost between patrons be just as or more useful?

Announcing Sakuzaku’s ‘Lunch With You’ Series

By Cody in Commentary

If you’re someone active in the Web 2.0 sphere and we know who you are, and you’re in Honolulu for whatever reason, we’ll take you out to lunch on us. Just shoot us an email at contact@wearesakuzaku.com or call us at 808-366-0694 while you’re here. Short notice usually works. The only thing we request in return is to ask you a few questions about your work and your specialties while we chow down, and permission to post what you say here.

(We’ll be posting our first few interviews in the next few weeks.)

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>

iweb_fix.xslt

4 Kilobytes

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

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

I Am Building Ruby, Rails, Subversion, Mongrel, and MySQL on Mac OS X — Automatically (And So Can You!)

By Cody in Systems, Software Development

Here’s a script to automatically download, build, and install the OS X versions of the following software:

• Readline (5.2)
• Ruby (1.8.6)
• Rubygems (0.9.4)
• Subversion (1.4.5)
• MySQL (5.0.45)
• Rails (latest version)
• Mongrel (latest version)
• Capistrano (latest version)

The steps it takes mirror those explained in Hivelogic’s great post Building Ruby, Rails, Subversion, Mongrel, and MySQL on Mac OS X. If you’re of the variety that can’t easily understand the instructions in HiveLogic’s post (for some reason your humorless software-engineer–partner insists you run the Rails app on your local machine for development), or if you’re the variety that has to do this installation samba prance dance on a frequent basis, then this might come in handy for you.

Notes

• Before you run the script, you’ll need to have Xcode installed. Unfortunately, I can’t make the script download and install it automatically, since you need to login to with an ADC account to download it. It’s an almost 1 GB download, so plan accordingly. But real developers have Xcode installed, so it’s OK.
• While installing the gems, you’ll probably be prompted to choose which version to install for a number of the gems. Choose the option for the highest Ruby version listed (i.e., not the ‘mswin32’ version).
• If the script complains when installing the MySQL gem, see our post about Installing the Ruby mysql-2.7 gem on OS X 10.4.
• Since you can only really run this script once, I have only tested it a few times, on a Powermac and a few MacBook Pros running OS X 10.4.10. If you run into any problems, send me a bug report so I can improve the script.

There’s no easy way to make the script automatically download the latest versions of the software involved (except for the gems), so I’ll try to keep the script up-to-date as new versions of the software it installs are released. (If I fall behind, just email me and I’ll post an update, and maybe send you a Sakuzaku pin badge.)

Download

os_x_rails_auto_installation_pak.sh

8 Kilobytes

Usage

1. Open Terminal.
2. Type:
   bash /directory/where/i/downloaded/the/file/install.sh

Sudo will prompt you for your administrator password after you run the script, and then blast off with a flurry of downloading and compiling. You’ll have to do some clickety-clicking to help MySQL install itself. Then sit back — you just saved 15 minutes (or 4 hours).

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.