I had a fun chat today with Coté on his “make all” podcast. Here are some of the topics I remember discussing:
Happy listening!
Update: I’ve created a test page for this scenario, but I haven’t had a chance to test it yet on my iPad.
In our Jazz UIs, we tend to use “hover previews” quite a bit. That is, if you hover over a link, after a second or so it will show a small preview of the resource at the other end [1]. Jazz style guide example below (copyright IBM).
This was always broken on the iPhone’s Mobile Safari browser because I couldn’t figure out how to perform a mouseover action on a mouse-less interface.
I just noticed that the iPad seems to support onmouseover. I believe I’ve observed the following behavior:
Obviously this implies that you should provide visual indications to your user whether the links provide onmouseover actions or not. For the Jazz links with hover previews we immediately decorate the link on mouseover (different color, double-underline, with a small chevron) and if the user remains over the link for a second or two we then show the preview.
[1] I realize that onmouseover actions attached to links represent a UX minefield. A page with too many / too aggressive hover actions can feel like an actual minefield!
I know this is total n00b stuff but I always forget the particular so I thought I’d write it down in a blog entry.
To add a custom scripts directory to your path, do the following:
In your root directory, create a file called .bash_profile with something like the following:
if [ -f $HOME/.bashrc ]; then      . $HOME/.bashrc fi
Then in .bashrc, put something like the following:
export PATH=$PATH:$HOME/Scripts
Make both scripts executable:
chmod +x .bash*
For extra credit, create a softlink from your Dropbox folder to your scripts folder and you can have the same scripts on all of your computers!
ln -s $HOME/Scripts $HOME/Dropbox/Scripts
I hit a very annoying issue using Audible.com on my Mac with iTunes and my iPhone. I thought I’d document it in case others hit it.
Setting the Stage
I got a MacBook Pro in early 2009. I buy audiobooks from Audible.com and store them in iTunes. From iTunes I sync the audiobooks to my iPhone so that I can listen to them while driving, cleaning, etc. The audiobooks are DRM-protected (urgh), so the first time you try to play an audiobook in iTunes it asks you to enter your Audible user ID and password. It then validates your Audible user ID and password and verifies that you have purchased the audiobook file. Once you have authorized your Audible.com account in iTunes, you never have to enter your Audible.com user ID and password again. Also, once you have authorized your Audible.com account in iTunes, you can sync audiobooks to your iPhone.
The Symptoms
Recently IBM got me a new 2010 MacBook Pro for work (thanks IBM) so I gave my 2009 MacBook Pro to my wife. So that I wouldn’t have to set everything up from scratch, I backed up my entire 2009 MacBook Pro to an external drive using Time Machine and then restored this configuration onto the new MacBook Pro. After a couple of hours of data transfer both ways, my new MacBook Pro was a clone of my old MacBook Pro, or so I thought.
Unfortunately I realized quickly that something was wrong with my Audible.com audiobooks. The first symptom was that none of my Audible.com Audiobooks were on my iPhone. I tried to play one in iTunes and it asked me to authorize my Audible.com account. This was a surprise because I would have expected the Time Machine backup / restore to have made this unnecessary (since my iTunes configuration was already authorized), so I typed in my Audible.com user ID and password, hit sync, and sure enough the ebooks synced successfully to my iPhone.
Later that week I noticed that the audiobooks had disappeared from my iPhone again!
The Bug
To make a long story short (too late), after some experimentation and support discussion with Audible.com, I discovered the following steps to reproduce the problem.
Basically anytime I closed iTunes, my Audible authorization was lost. This indicated that authorization was succeeding but was not being persisted to disk. I sent the steps to reproduce to Audible customer support.
The Solution
As I suspected, it was a persistence problem. The Audible support person pointed me to the file /Library/Preferences/com.audible.data.plist (a Mac property list file) where (apparently) the Audible / iTunes code persists your Audible authorization information (I peaked in the file and it contained a single ‘data’ property whose value was 4 KB of encrypted something or other). Interestingly, even though I’d at this point authorized my Audible account in iTunes many times this week, the file’s date stamp was from last year, indicating the file wasn’t getting updated and thus my authorization went *poof* whenever I closed the iTunes application and its process died.
The Audible customer support rep first suggested to check the file’s permissions to make sure that my user account was authorized to modify the file. No problems there – I had read/write access to the file. Her second suggestion was simply to close iTunes, delete the Audible property file, open iTunes and reauthorize the computer. I did this and sure enough when I reauthorized the computer, a new property file was created with the current time as the timestamp and I was able to close and re-open iTunes without having to re-authorize.
Lessons Reiterated
This experience reinforces two software principles I already believed.
Solution Proposal
I sent the following suggestion to the Audible.com support person:
Thank you <redacted>. It’s working now.
FYI, it was not a permissions issue – the permissions were correct. I had to delete the com.audible.data.plist file and restart iTunes / reauthorize Audible to create a new version of the file.
I suspect this is related to my restore from Time Machine on to a new computer. I would suggest your engineers who work on the Mac iTunes integration test this case:
1. On a Mac, authorize to read Audible content via iTunes
2. Backup a Mac onto Time Machine
3. Restore from Time Machine onto a new Mac
4. Attempt to play Audible content
I’m not sure what the ideal behavior is (e.g. just working or requiring a single authorization of the new machine) but I know what should not happen is what happened to me 🙂
Thanks again for your help.
– Bill
Occasionally I need to produce YouTube HD videos showing me doing something in a web browser. Up ’till now I’ve had to painfully, manually resize the browser window to 1280×720 so that the video didn’t get unnaturally shrunk or expanded by my screencast rendering software. Tonight I figured out a way to automatically resize my browser window to the exact dimensions using AppleScript.
Here is the magical incantation:
tell application “Safari”
activate
set the bounds of the first window to {0, 0, 1280, 720}
end tell
Run this application in AppleScript Editor (/Applications/Utilities/AppleScript Editor) and your browser will be the perfect size for recording movies. You can save the script to a folder for later reuse.
I used to read a lot of tech books, like a an hour or two a day. Several years, several promotions, two kids, and one deteriorating eye later, I realized I wasn’t reading much anymore. The combination of work commutes / Audible.com / iPod helped me keep up with novels and non-techy non-fiction, but I still had trouble keeping up with tech books.
Luckily, tech publishers are starting to publish more and more ebooks. Here’s some of the good and bad points of reading tech ebooks.
Tech Ebooks: The Good
Tech Ebooks: The Bad
Tech Ebooks I’ve Recently Bought
Now, for your reading pleasure, are the ebooks I’ve bought in the past few months (updated 25 Oct. 2009).
As my dear colleagues Simon Johnston and James Branigan have mentioned in various blog posts, on the Jazz project that I work on, we’ve (finally) fallen in love with the web/REST story. Because of this, we spend a lot of time in technical conversations using the standard REST alphabet soup vocabulary you’d expect – HTTP, XML, JSON, REST, URL, URI, etc.
One funny thing I’ve noticed is that there’s a certain conversational dance that goes on when the topic of URLs/URIs come up. For 99.9% of the web developers out there the distinction between “URL” and “URI” doesn’t matter, as the Wikipedia entry on URL points out:
In popular usage and many technical documents, [URL] is a synonym for Uniform Resource Identifier (URI).
However, some people who are a bit more pedantic than others care about the distinction (not me!) and tend to use “URI” in favor of “URL” when talking about REST stuff. People who are a bit new to the REST stuff on the other hand tend to use “URL”, since this term’s a bit older and a bit better known.
I’ve observed that when a REST newbie talks with one of the REST pedants, the newbie says “URL” while the REST dude uses “URI”. But as the conversation continues the REST n00b eventually uses “URI” – essentially deferring to and adopting the more knowledgeable person’s terminology.
I’ve also observed that when I talk with one of our REST dudes, if I continuously say “URL” (usually out of spite – I’m KIDDING!), they usually eventually start saying “URL”, I think just to bring more harmony to the conversation and because they realize that the distinction isn’t that important – probably simple mirroring at play.
I think in a future experiment, I will use the opposite term of whatever the other person (newbie or pedant) uses and as soon as they adopt my terminology I’ll switch back to the other term, and see what happens.
Should be fun.