Address Book

Mac OS X’s Address Book is one of the strongest features of the entire operating system, in my opinion. Accessible not only through the Address Book application, it can be queried and manipulated by any other application. This means my contact info for a person can be called (and edited) by my instant messenger app, my email app, my photo management app, and even my library cataloging app.

That’s killer. Sadly, though, the Address Book application hasn’t received much attention since it was released years ago. Occasionally a new feature is added (two, in fact, with the new Leopard release!), but fundamental Address Book issues haven’t been resolved for years. I won’t try to catalog them all, as honestly, that’s a pretty big task. However, there are a couple tweaks that would add significant value.

• Additional Services

  The Web’s changed a bit since 2000. OK, it’s changed a lot. Kids these days aren’t emailing; they’re sending messages via Facebook. They’re posting video on YouTube. They’re calling on Skype. And they’re uploading photos on Flickr.

  But how do I represent any of them in Address Book, as I’ve got a lot of friends who use these services? I could add direct links to their profile pages as Web URLs, but that wouldn’t make it easy for other applications to make sense of that data in a meaningful way (the way they can with phone numbers, email addresses, instant messaging handles, etc.).

  In my mind, the best way to accommodate this issue would be extending what I call the “Services” list, which currently lists IM services: AIM, Jabber, MSN, ICQ, and Yahoo. (I can tell you, as well, how many times I’ve updated anyone’s Jabber, MSN, and ICQ fields… hint: it’s less than 10!)

  

  Address Book’s Services menu exposed

  Why can’t I add Skype, Facebook, YouTube, MySpace, LiveJournal, etc. to the list? Why no “Custom” field for this list of services, the way there is with nearly all the other fields in an Address Book card? It’s a bit ironic, too, considering that the Web’s list of services grow at a far, far faster pace than, say, humanity’s definition of places like “work” and “home” or the 8 categories for a phone number.

• List My Groups

  What’s more embarrassing than trying to introduce your friend to someone whose name you don’t quite remember? Address Book seems to deal with this issue on a daily basis. Contacts can be added to multiple groups, a very useful feature. Problem is, once you’ve added a contact to several groups, how can you find out to which groups he/she has been added? Turns out, there’s an answer: while a contact card is selected, hold down the Option key. Once depressed, the associated group(s) on the left will highlight. Pretty cool.

  Only thing is, how did you know that? I sure didn’t. Took an accident of me wondering, “Why is one of the Groups highlighting when I accidentally pressed the Option key?” Neat discovery once I figured it out, but sadly, I’ve been trying to find how to determine what groups a contact belongs to for more than 2 years.

  This may sound crazy, but why not list the names of the associated Groups on the contact’s card? No one has to kill the fun Option key highlighting; but there could be a more intuitive way to lead to such a discovery.

• Big Boy Search

  This one’s simple. Know all those little modifiers you prepend to searches in Yahoo! and Google to get granular, advanced search results? Apple does; they use such operators for their OS-wide Spotlight search.

  Unfortunately, that power doesn’t translate to Address Book. Searching for “state:OH” doesn’t return folks who live in Ohio. Rather (and rather bizarrely), it returns anyone who had “United States” listed for their address’ country field and an “oh” in their name. I would propose, instead, that Address Book handle operator searches in the same fashion as OS X and major search engines. I know its not a regular feature most folks need, but it would give your power users and 3rd-party developers some great slices on the rich data contained inside.

• Fix Edit Mode

  Pierre Igot has actually done a fantastic job detailing issues with Address Book’s Edit mode problems, so I won’t try to compete with his thorough assessment. I’ll just say “+1″ and leave it at that. (Sad side note: his comments are 2+ years old.)

• Connections

  Address Book has a great feature: Related Names. I can enter in the name of a friend’s spouse or kid, as well as professional colleagues. Trouble is, though, these names are disconnected from… (drumroll) Address Book contacts! In other words, if under “Alex Meyer” I entered “Micah Laaker” in the “Friend” field, “Micah Laaker” wouldn’t in any way be connected with the “Micah Laaker” contact card in Address Book.

  Reduce the barriers between information. The Web has got me and millions of others used to hyperlinking to see more about an object… why not people in Address Book?

  Better yet, if the person on the contact card (let’s say my dad) has another person listed as “spouse” (i.e. my mom), and that spouse is listed in my Address Book, too, why not ask if I’d like to update her address after I update his? It would keep my Address Book data in much better shape, and show that Apple’s incorporating some of the best of Web functionality and smarts into its apps.

• Date autocomplete

  Address Book’s dates field used to be smart. No matter what input I gave it, it could turn it into a data. “11 Jun 75″ became “June 11, 1975.” “10/11/2007″ became “October 11, 2007.” This makes things easy. No matter what format folks typed their birthdate, anniversary data, whatever,

  And then Leopard came along.

  Somehow, someone at Apple decided it would be better if we all manually entered data

  The real kicker? Try entering a date the way you might say it (after being trained by so many Web forms): 6/11/75.

  

  Address Book’s “improved” date input field

  The result? You won’t guess this: “6/11/0075.”

  Wow.

  That is easily one of the last things I expected, considering the day before I upgraded to Leopard, it did the right thing. (Hint: 6/11/1975.)

  Honestly, I’ve never been this disappointed in software. (There’s lots of frustrating software out there, but few that went from “Ahh, that was really helpful!” to “Are you $%*# kidding me?!” And very few Apple software releases that made me angry.) I don’t think I even need to spell out a recommended course of action for this overall (and specific) issue. Please just fix this. Fast.

Apple took an embarrassing step backwards with the Leopard release of Address Book. No one sued Apple for infringing on some “make software smart” patents (at least that I’m aware of), so there was no need to cripple the product this late in the game. It should fix the date auto-complete issue immediately, and then get on to some other much-needed improvements. Why let Address Book sit with so little attention, when it is a backbone service for the entire operating system (and numerous 3rd-party applications)?

And, remember: I only ask for this because I care. Address Book, and all the other apps/issues I mentioned, are products and services I use daily and evangelize to others. I just want to love them a little bit more… or, at the very least, be made so that it was easy for other developers to extend them to do just that.

(Ed. note: This was the last of a several part series. See previous posts re: .Mac, Customer Lifecycle, Apple.com User Profiles, and iPhone/iPod/iTunes.)

Once I began that quest, though, it struck me as odd that my library was tied to one computer; I couldn’t access/update it online, or share it with others. This led me to LibraryThing, less UI-candy but a powerful online library tool nonetheless. Further, LibraryThing helped and encouraged folks to use CueCats to input their collections, and seemed focused on open standards.

Enter: Shelfari.

I got an invite to Shelfari back in July from my friend Lowell. There seemed to be a level of design professionalism around the product, and it was backed by Amazon. Cool. Also, it looked like they might be trying to move towards a more visual approach, ala Delicious Library. I created a Shelfari account, added some books, and then largely forgot about the product.

Enter: Facebook’s F8 Developer Platform.

With waves of 3rd-party development of social profile apps, a number of book cataloguing apps appeared. Shelfari’s Facebook app appeared at one point in my News Feed, and I decided to add it to my profile page. After adding it, I went to Shelfari and added a couple other books I owned to make my profile module look a bit more impressive.

Then, I made a mistake. I opted to let Shelfari look through my Gmail address book to see who I was already connected with might also be using the service. (I have a general policy when it comes to inviting others to a service I belong to: if they are already a member, I have no problem asking if they’d like to link up; if they’re not, I may invite one or two folks who I think would be very interested. Otherwise, I either mention the service in person, or forget about inviting folks to it.)

I entered my Gmail login credentials, and pressed the Continue button.

The resulting screen showed a half dozen some users (from my address book of 800-some) as members of Shelfari. All the addresses were checked. Just to make sure, I scanned the page first… I didn’t want to spam everyone in the list. There were two sections of addresses: “Your Friends already on Shelfari” and “Your Friends not yet on Shelfari.” Each had a “Send Invites” button, and a toggle to select/unselect the addresses within that section.

Pretty clear.

I hit the “Send Invites” button beneath the “Your Friends already on Shelfari.”

Seconds later, I got the first of several mail delivery errors in my mailbox. It appeared Shelfari had emailed some of the addresses from the section whose button I didn’t press. I was alarmed, but not too worried.

Then came the acceptance emails. Emails from my mother-in-law, my dentist, past clients, eBay sellers, and folks on mailing lists whose addresses I didn’t even have. By the very fact that I had received mail from an address, Gmail had stashed it in my address book; that I found useful. What I found harmful was that, now, all those addresses (especially all those addresses of folks I didn’t ever even email… they had emailed me) had been pinged by Shelfari by me.

Should I send an email to everyone in my address book to apologize? That seemed even lamer.

So I channeled those feelings into an email to Shelfari support: “It’s bad enough to auto-check them all in hopes of spamming the whole list, but to then tie those auto-checked addresses to a disconnected button?” The response I received back (rather quickly) was infuriating. “That certainly is disconcerting,” it started. But then it took an odd turn. “We have actually evaluated numerous designs for this process and have chosen one that we felt was extremely clear explaining the process and what is happening.”

So while acknowledging what happened was not in a user’s best interest, they defended the design of the system. This struck me as something usability testing (even paper prototyping or casual man-in-the-field testing) would catch easily. Qualitative feedback captures gems like this in a way that raw, aggregate data can’t.

I replied again, but never heard further. I grumbled to myself, and to several co-workers.

And then, finally, this past week I came across O’Reilly Radar’s ‘Shelfari and the New Social Contract’. I wasn’t alone. Dozens of other Shelfari users were as angry as I, LibraryThing’s CEO had done an investigation (and expose) on the exact issue, and now O’Reilly was drawing attention.

Shelfari’s response seemed plausible on first read. And then I thought about it. Their new fixes, while solving my particular problem, still will result in unwanted, unsolicited emails being sent. (They choose to pre-select all email fields still; a convention long ago dropped by most companies wanting qualified members, not those too lazy to hit “unsubscribe” from the ensuing emails-to-come.) And, further, the pattern exposed (of their intern who hid under the guise of a happy fan while interacting with co-workers in comment threads) suggests that they don’t get it.

Long story longer, I’m still a Shelfari account holder. Part of me feels bad bailing on a service to which I inadvertently attuned so many people. Another part of me wants to believe this was just a couple of bad things coupled together, and Shelfari will learn from the mistakes.

But honestly? I’m doubtful. And it makes me want to use LibraryThing more. (I appreciate their allowance for site publishers to include their own Amazon Affiliates link in their widgets.) And the upcoming Delicious Library 2.

So, in the meantime, while Shelfari’s invite process isn’t on the up-and-up, I figured I’d publicly join in with the kicking.

Every 3 months, Yahoos from all parts of the company have 24 hours to build new products (or enhancements to existing products) with the express goal of showcasing their work in front of the company… and its top executives.

It’s what we’ve dubbed “Hack Day,” and it’s been remarkably successful at bubbling up top ideas and talent to decision makers internally… and then out to our users.*

So, it was out of our most recent event that Loc Amigos emerged. Fellow Developer Network crony Jason Levitt drummed up the idea of scouring the address books of a user’s different mail accounts to find which social networks these contacts may already be a part of… sure beats the current approach most use of sending emails to everyone in your address book. Using the Yahoo! Mail APIs as well as some screen-scrapers for Hotmail, AOL Mail, and Gmail, as well as the YUI user interface libraries, Jason worked with Kathleen Watkins and I to quickly assemble a working version of the product.

Does it work? Absolutely. Is it the best user interface for this sort of challenge? No way… but, it demonstrates something very important: a small, nimble team quickly working on a proof-of-concept can take a cool idea, get a working prototype, and now take it into usability labs to get real user feedback.

It’s this rapid, entrepreneurial spirit that is still fostered inside Yahoo!, and makes it a very exciting place to work. Even more exciting, the Developer Network (of which I’m now a part of) works on projects like this all the time in efforts to demonstrate and test the very APIs and Web Services we promote. It’s hard to imagine a more collaborative, inspiring environment, especially one built to encourage others (whether individual designers/developers, startups, or even our competitors) to succeed in similar ways using our (and others’) tools.

* For more on what Hack Day is, and why it rocks, see Chad Dickerson’s post on Yahoo! Hack Days as well as Matt McAlister’s Top 10 Reasons Hack Day Rocks.