Ellen Beldner

iTunesSymphonicMetadata.scpt

I listen to a fair amount of symphonic music.

I think of symphonic music first in terms of the composer (e.g. Bartok, Beethoven), then the work (5th Piano Concerto in E Flat Major), and then, in the cases where I have multiple performances of the same work, the conductor & performing orchestra (Julius Katchen & London Symphony Orchestra; Hélène Grimaud, Staatskapelle Dresden & Wladimir Jurowski).

However, music metadata format lists the conductor and symphony in the "artist" field on CDDB / iTunes. This is moderately annoying to deal with in the iTunes interface (I have to display and then sort by the correct columns of metadata) but absolutely intolerable on my iPod. Trying to listen to Smetana's Ma Vlast means that I have to remember the name of the composer and orchestra? Oh come on.

So I wrote an Applescript to fix the metadata on my symphonic catalog. It searches my library for all tracks whose genre is "symphonic" and swaps around some of the field values. I still retain the performance info, but as "album artist" instead of "artist".

(It similarly annoys me when other albums list both performers of a one-off song (e.g. Madonna and Justin Timberlake), which breaks that one song apart from the rest of the album when I sort by artist. In these cases I manually reset the "artist" field.)

* What people generally call "classical," but I refer to it as "symphonic" because of a snobby old habit of mine: "classical" refers to a specific period / style of symphonic music in the Western canon, e.g. Haydn and Mozart, so I use the more general "symphonic". I guess "orchestral" might be more appropriate... anyway, the organizing genre in my iTunes library is "symphonic".

Thanks to http://safari.oreilly.com and the O'Reilly Rails Cookbook, I have learned the answer to my burning question:

Yes, I *do* need to create join tables in my database migration definition files.
It wasn't clear to me at first, but now what I'm realizing -- and hopefully this is correct -- is that the rails migration schema file is really just an abstracted way of writing a database setup script. Rails can translate its file into the setup script for whatever database you're using, but you still have to specify all the joins, defaults, etc. just as you would if you were setting up the database in its native language. Check and check.

I do use the scaffolding command to create multiple model-controller relationships. (See O'Reilly OnLamp: Rolling with Ruby on Rails Revisited.)

"test" is a reserved word.
This is apparently a problem. I'm building a DB to track usability tests, and I named one of my tables "test". I'm trying to migrate to "usabilitytests" but i'm running into problems. Solved by deleting the entire app and recreating. Obviously not something that one would always want to do, but I don't know how to un-create models and controllers and whatnot that have already been set.

functions in the controller are lowercase with underscores.
I'm not entirely sure of this, but I downloaded a sample application and checked out that code.

TOTALLY STUMPED: Radio buttons in RoR?
Okay, I found the documentation for how to render a checkbox. Am I smoking crack? Did the entire RoR project forget about the existence of radio buttons? From an interaction perspective, radio buttons are the exact same as SELECT boxes: They afford one-from-many selection. They're just rendered in an easier-to-read and easier-to-operate widget. (Select boxes are hard for people to use, and even if you know what you're doing, they're way more of a pain particularly for administrative-type applications when you interact with the box a billion times a day.) I expect there to be a function like collection_radio that operates almost exactly the same as collection_select -- but as far as I can tell, no such thing exists.

Yesterday someone sent around a link to http://hotcaptcha.com, which selects images with the Am I Hot or Not API and asks users to choose the 3 of 9 pictures whose subjects are hot. Very cool idea, drawing on both biological and cultural expectations of attractiveness.

However, amongst my colleagues and some of my friends, we realized that we were all getting something like 100% accuracy for female photos, and 0% accuracy for male photos. I had orignally thought "gee, I'm 100% accurate on females and 0% on males, I wonder why?" My friends' verdict: it's a trick or a bug, and the male images aren't being selected properly for hotness. (For example, the writer of HotCaptcha had written the call to the Hot or Not API and forgotten to set a minimum rating threshold of, say, 9.)

My only way to find out was to get an API key and pull profiles myself.

My first attempts at doing this with AJAX failed, because I forgot that XMLHttp doesn't work across domains. Bleh. I switched to a PHP file() call, but it wasn't working. WTF. Struggled for a half hour.

Then I realized that I had been tormenting my function getProfiles() but had failed to actually call the function in my PHP script.

Sigh.

Less suck, more hot. We did a ton of usability testing of Base in the past few months, and this revised homepage came out of it. Goals were to make item types more visible, help users understand what base is, deemphasize search (to keep the focus on Base as place for uploading, not for searching) and help users make better choices about the right upload technology for them.

One of the things that I think makes this design work really well is the IA of the page. Users who come here are either brand new (never heard of Base), brand new but who have heard of Base (e.g. through a marketing email or similar), or are returning users who want to manage their items. I wanted to clearly draw users' attention to the first choice they have to make: how are they getting their stuff on to Base? This is a bit system-centric (how will a user know which technology to choose?) but it turned out in all the studies that we did that people did a good job of identifying the technology that would be suitable for their needs.

Everything that you need to do to get going is on the right: either sign in (for existing users) or click one of the giant iconed links to get started. The blue background draws further attention to the section and, along with the icons, helps balance the huge sea of blue links on the lefthand side of the page.

The left, in its turn, is the "learn more" part of the page. If you're not sure what Base is, you can focus mostly on the left -- browse a few item types, see which ones are popular and which ones are sort of randomly interesting, and get the couple lines of promo / marketing text. Some users really really want to investigate; some users want to jump right in and start playing around to figure it out. (I'm not sure if it has more to do with technology familiarity, age, or how much you need your stuff to show up on Google for your business to survive.)

There are still a few bugs, but those will get worked out soon. Official post on the Google Base blog.

When it comes to discussions about writing software specs, I really like to quote Sen-Rikyu, the master of the modern Japanese tea ceremony: "Tea is naught but this. First you make the water boil. Then infuse the tea. Then you drink it properly. That is all you need to know." But if you know anything about the actual practice of the tea ceremony, there is -- for laypeople who have not mastered the Zen of simply boiling the water and infusing the tea -- an immensely complex protocool, replete with symbolism that must be adhered to.

Writing specs is simple. All you do is document what has been decided and capture known uncertainties, and underlie everything with a giant disclaimer that until the code is written you won't know exactly how it's going to work.

In fact, perhaps we shouldn't think of specs as specifications of software. They are specifications of goals for the software.

I'm about to start working on a UI spec for some upcoming changes to the Google Base UI. I'm always looking to improve, and this is a pretty complex series of workflows that we have to get just right. So I want to make sure that I capture and communicate all of the decision points that I've traversed up until now, and that I specify behavior that may not be fully obvious in the prototype that I built.

Let me highlight some key concepts from that last paragraph: Capture. Communicate. Spell out corner cases.

So I searched for write UI specs. The first result is 37 signals explaining why specs don't work. I read this type of article -- along with some Agile and XP techniques -- as a radical overreaction to the other extreme (of overplanning and presuming you can actually precisely specify software on a piece of paper before anything is written). In that sense, the 37 signals article is irresponsible. It's speaking to a particular historical context of software engineering without acknowledging that there are a lot of ways that specs can be written, usefully, in the context of more modern software engineering practices. Moreover, when you're not working at a small startup, it is irresponsible to not write specs. Specs help other teams anticipate and plan for what's happening down the line, and when you don't have the same 10 people doing everything -- when you have a marketing department, a customer service team, writers who have to do help documentation -- you need to let them know as early as possible what you think is coming down the pipe, so they have maximum time to plan their own resources and schedules.

In javascript, I needed to compare the "for" attribute of a LABEL with the ID of an input object to see if I'm looking at the LABEL associated with that radio button / checkbox.

Programmatically, it doesn't work to say something like

if( theLabel.for == theRadio.id ) 

because for is a reserved word in javascript.

So after some investigation (spitting out every single property of the LABEL element and looking to see how the "for" is referred to programmatically), I learned that the way to refer to the FOR attribute with JavaScript is with the htmlFor property:

if( theLabel.htmlFor == theRadio.id ) 

Pironimo.net is a twiki installation that I deployed, customized, and maintain for a small community of friends (around 30 people). It began on another server in September 2002. Since then I've done about three major UI revs and one software upgrade.