Now that I’m attempting to soundtrack a friend’s upcoming video game, and that my original song is being featured elsewhere, I thought it time for my musician alter ego to have a proper home.
This was a fun design task, as it was an exceedingly simple single-page HTML/CSS-only site, and I gave myself the artificial restriction of a 3-hour time limit. Normally I overwhelm myself by considering every possibility, but this time it was pretty much all instinctual, and it turned out well. There are of course far more ambitious ideas for it but for now it’s off to a modest start, just like the project itself.
The nice little embedded music player is 1 Pixel Out’s Audio Player WordPress plugin, modified to work in a non-WordPress site with this tutorial from Mindy McAdams. This Boagworld tutorial was also helpful in making the fixed footer.
Good Old Games — a place to buy classic PC games, modified to work on modern PCs, for ridiculously low prices.
GOG sports a nice and classy design as well, a rarity for gaming sites.
If anyone else out there is irritated that some MP3 stores like Amazon MP3 Capitalize Every Word In Song Titles, Even Small Ones Like ‘The’, you may enjoy this AppleScript.
That’s Proper English Title Capitalization by Cantus Vetustus, which is excellent except for the fact that the list of ‘small words’ that get uncapitalized is a bit incomplete. So I merely replaced the list with that of John Gruber’s Title Case (which gets its list from the New York Times Style Manual).
To install the script on a Mac (no luck for Windows users) drop the file into /[username]/Library/iTunes/Scripts (and if that folder doesn’t exist, make a new one). Then a little paper scroll icon with the new option inside should appear in your iTunes menu bar.
Just announced: Objectified, a new documentary on industrial design by Gary Hustwit (of Helvetica fame)
An interview with Jonathan Ive about industrial design? Sold.
43Folders’ faux full-screen mode is one of my favorite Mac tricks, and I don’t think I’ve ever linked to it. Let’s fix that.
Why now, over two years later? The excellent MenuShade stopped working with Leopard, and after throwing a tantrum, begrudgingly accepting an ever-present menu bar, forgetting about the trick, remembering the trick a year later when re-assessing my Quicksilver triggers, frantically searching for a Leopard-friendly menu bar auto-hide app, and finally finding one (Menu Eclipse), I now have faux full-screen goodness again!
Menu Eclipse doesn’t have the features MenuShade had… you have many choices for your desktop color, as long as it’s black. But now I can happily single-task once more! I highly recommend giving it a try.
When writing documentation, you can write it in one of two languages: Designese or Engineerean.
The perfect example of Engineerean is your typical O’Reilly book. These usually begin with a panoramic view of the topic as a whole, and then outline the specifics of every tool available. Engineereans go from the inside out, taking in the building blocks of the language and then using those to move towards a finished product. While a native Designese speaker such as myself may not learn a whole lot from Engineerean language books initially, they’re still invaluable desk-side references, as their structure makes it very easy to look up a specific property or method.
However, when you write documentation in Designese, then you’re speaking my language. The Designese approach is a very practical one: we as a people are visual learners, and we crave lots of examples. The Designese work from the outside in, seeing the finished product first and then analyzing how it works and going inwards from there. Dan Cederholm’s books are a great example: he begins with a functioning demonstration site and then dives in and explains the various parts that make it work.
So how can we bridge the culture gap and appease the citizens of both nations? The obvious answer is to start with a bunch of visual examples, and then have a full alphabetical glossary. But there are more subtle touches, for example, the excellent Visual jQuery, which is ostensibly Engineerean but is full of useful before-and-after code examples.
If you want people to use your library/framework/whatever, spend as much time as possible to write good documentation, and try to make it as accessible as possible. I see documentation as being much like product marketing, and arguably as important as the product itself.