Sci-Fi Hi-Fi

If I’ve ever introduced you to my colleague and friend Peter Ammon, you’ll probably remember me describing him as “one of the smartest people I’ve ever met.” Evidently I’m not alone in thinking that, because he was recently awarded what many of us Cocoa devotees would consider a dream job: an engineering gig on Apple’s AppKit team.

Before Peter left my group for the big time, a lot of us were trying to get him to start a weblog so that his frequent, witty insights about things like the horrors of object oriented Perl (he vociferously renounced Perl once after we sat through a presentation about its OO facilities), the perversity of C++, or what exactly happens in Objective-C when you message nil, wouldn’t be wasted on our daily lunch conversation.

Peter liked the idea, but true to overachieving form, kept us all eagerly waiting while he set about perfecting a fancy (and previously unknown, as far as I know) CSS box corner rounding technique as part of his site design. Fortunately, he now seems to be ready to go, and has launched his weblog at ridiculousfish.com. Mac developers who have been around long enough to have suffered through the incomplete early Cocoa documentation will undoubtedly smile at his first post.

Only time will tell how much Peter will feel he can write about his work, but I for one think having a weblogger on the AppKit team could be a great thing. Whatever he ends up writing about, I’m sure it will be worth reading, so I encourage everyone to give Peter a warm welcome to the blogosphere.

Since I’ve been on a coding roll lately, I decided to fix several Cocoalicious bugs this morning, and consequently am releasing b34 right on the heels of b33. Beta 34 fixes the full text search sorting regression I mentioned in the previous post, as well as a timing-dependent extended search bug, and a long-standing issue with the submission of posts containing plus signs or semicolons.

It’s been a very long time (a few months, if I remember correctly) since I released a new Cocoalicious beta, but I think fans and critics alike will agree that Beta 33 was well worth the wait. I’ve been using builds of it for weeks now and I can’t get over just how significantly the changes I’ve made have improved the user experience. What are these wonderful changes you ask? Well, I’m thrilled to report that the internals of b33 have been significantly overhauled to minimize interaction with the del.icio.us API, and make all interaction with the del.icio.us server asynchronous.

You see, previous versions of Cocoalicious were heavily dependent on the del.icio.us API. Rather than maintaining its own post and tag lists, Cocoalicious always simply asked the del.icio.us server for updated data. This meant that the updated post and tag lists had to be re-downloaded every time a new post was added, or an existing post was modified. Constantly re-downloading the XML list of a user’s post gets to be pretty painful–particularly once the user has 1000+ posts and a 328 Kb XML download (as I do)!

Another major way the old Cocoalicious sucked was that, with the exception of the XML post list download, all of its HTTP requests were done synchronously. This meant that when the user posted a new link, deleted a link, tagged a link by dragging it to the tag list, or renamed a tag, the call to the del.icio.us API was done on the main thread. This blocked the UI (and brought up the dreaded spinning color wheel) until the del.icio.us server responded. Believe me: the lousy user experience this provided, as well as the irony of a “rich desktop client” that was less asynchronous and responsive than some of the new “Ajax” web apps, was not lost on me.

Fortunately, I put in a lot of work to fix these problems, and I think the experience of using Cocoalicious is improved massively by it. In b33, Cocoalicious does most of the work it used to rely on del.icio.us for internally. Cocoalicious now constructs and maintains its own tag list based on the current tags used in posts. When the user posts a new link, Cocoalicious simply adds it to its in-memory list, rather than re-downloading the entire post list every time. All of the server API requests necessary to relay these changes to del.icio.us are done in the background. The net effect is that Cocoalicious now truly feels as responsive as a desktop client should.

These are also important changes in that they pave the way for one of my biggest goals for Cocoalicious: implementing local persistence. The changes in b33 put Cocoalicious on the road to being an independent app that happens to sync with del.icio.us, rather than simply a rich front-end for it.

The only problem with this “async-ification” is that there is now no UI feedback to let the user know when (or if) the submission of a change to del.icio.us completes. I have some interesting ideas about how to address that I will try to post for critique and then implement in a future release.

In the meantime, enjoy the asychronicity! I know I have for the past few weeks.

(Update: Damn, I already noticed a regression: the post list is now unsorted when filtered by a full-text search. I guess b34 will probably involve fixing that…)

Just a thought, while I’m on a blog posting roll: wouldn’t it be cool if someone implemented a sort of del.icio.us“trackback” feature for weblogs? That is, a WordPress plugin that could display the number of times a post has been bookmarked on del.icio.us. It could be almost like the distributed, weblog-ish equivalent of the way Flickr displays the number of people who have marked a photo as a favorite. I’d do it, except I already have way too many side projects as it is. Jonas, any interest?

(Update: Ask and ye shall receive: Andrew Skinner has done it! It’s now running on my weblog, and I couldn’t be happier with it! Thanks for your hard work Andrew!).

A little while ago, Brent Simmons asked his readers about their window management style: whether they manage clutter by closing, minimizing, or hiding. Lately, I’ve been interested in a similar “Beatles People vs. Elvis People” distinction: some people tend to prefer to locate things by browsing, while others prefer search.

I, for example, fall squarely into the search camp. I almost never use the “Browse” view in iTunes–if I want to listen to a specific album, I find it more expedient to simply type the name of the album into the search field. This is a bit messier, of course, since it usually turns up songs that are not part of the album, but that doesn’t really bother me. I do the same thing with Mail: rather than sorting my messages into a number of folders, I prefer to let it all go into one big inbox and find what I need later by searching. I suppose you could say I prefer ad-hoc, logical views of my data to concrete hierarchical organization (which could also be one reason I love the concept of tagging so much).

Obviously Tiger, with its focus on search and metadata at both the system level and app level, is a huge boon to people like me, and I think my experience demoing it at MacWorld this year really threw the search/browse dichotomy into sharp relief. I demonstrated Spotlight features like Smart Folders to nearly everyone I talked to, but while everyone seemed to understand them, only about half seemed to think of them as killer features the way I do.

So how about you–are you a searcher or a browser?

Observant users of Cocoalicious who have updated to Mac OS X 10.3.9 may notice a problem with the “New Post from Safari” feature: namely, the selected text on the page is no longer captured. This problem is caused by an unfortunate regression in both Safari 1.3 and Safari 2.0: the Javascript “getSelection()” call no longer works properly when invoked through Safari’s “do javascript” AppleScript command. Rest assured, there is a bug in Radar for it, and hopefully it will get fixed at some point.

(Update: Sent trackback to Hyatt’s Safari 1.3 regressions post.)

If you’re as much of a del.icio.us addict as I am, you may have noticed that someone finally got around to releasing Scuttle, an open source, self hosted del.icio.us clone, a few days ago. I’d been waiting for this to happen for sometime, so that people could take advantage of a feature I put into Cocoalicious a little while ago: the ability to set the API URL prefix to something other than “http://del.icio.us/api/” (in the preferences window).

I put in a feature request for a del.icio.us API implementation on the project’s SourceForge page, and to their credit, the developers claim to have already knocked one out. So now Scuttle users should be able to set the API URL in Cocoalicious to the Scuttle installation on their own server and get all the same benefits as del.icio.us users.

I haven’t tried it out yet, but I think it should be a pretty cool thing for both projects.

Beta 32 of Cocoalicious brings both good news and bad news for our friends abroad. The good news is that I finally became ashamed enough of the app’s issues with posting international text that I fixed them (that’s why I had those Japanese Amazon links in my bookmarks for awhile, in case anyone’s wondering), and b32 now properly handles submission of unicode to del.icio.us. The bad news is that there is a character encoding problem in the XML returned by the del.icio.us API that prevents unicode from working properly in tags.

For those who care, the crux of the problem is that the XML returned by the “/api/posts/all” call is encoded as UTF-8, except for the contents of the “tag” attribute of each post element, which appears to contain text of some other encoding (UTF-16?). The problem is easy to see if you post a link and put the same non-ASCII characters in for both the extended text and the tags, then look at the XML output of “/api/posts/all.” The “tag” attribute and “extended” attribute will contain different data, even though both should be the same.

I’ve been working with Joshua on resolving this problem, so hopefully it will eventually disappear (or maybe if I get impatient enough I’ll bow to Postel’s law and implement a workaround). For now, I guess, just be advised that tag filtering with non-ASCII characters will not work correctly in Cocoalicious.

Beta 32 also contains a few nice patches and suggestions that people submitted:

• Ken Ferry finally implemented something people like Jon Hicks have been wanting for awhile now: services support. Using this feature, users can highlight a URL in any services-capable app (including almost all Cocoa apps), and either choose App Menu > Services > Post URL via Cocoalicious or press command-^ (shift-command-6) to send the URL to Cocoalicious for posting. This means that it’s easy to post from other browsers, such as OmniWeb and Camino (although, sadly, not Firefox, since it doesn’t support services).
  
  (Update: To get the services support to work, make sure Cocoalicious is installed in /Applications, and that you have logged out and back in after installing the new version.)
• Diggory Laycock submitted a patch which adds a handy dock menu, making “New Post” and “New Post from Safari” accessible when Cocoalicious is not the active application.
• John Gruber contributed his eye for UI detail and pointed out a few things that needed fixing here and there (most notably the lack of an obvious way to re-open the main window after it is closed). His suggestions have been incorporated into this release.
• Jason Deraleau wrote a very nice post about the full-text search feature, but mentioned that he wanted a way to index a single post, rather than having to constantly re-index his entire bookmark collection. This was a just criticism, so I added a more obvious menu item to index only the selected post (incidentally, pages also get indexed every time you open them in the web preview pane, but that’s not very obvious). Eventually I would like to add an option to make the indexing happen at the time of posting, but for now this is a good workaround.

Thanks, as always, to everyone who contributed! Oh, and if you’ve submitted a patch I haven’t incorporated yet, I apologize—soon, I promise!

Superbowl Sunday probably wasn’t the best day to do it, since most people were clearly preoccupied, but on Sunday I finally released Cocoalicious 1.0b31. This release took what seemed like forever, mainly because we were trying to get a very involved feature ready for prime time: full text indexing and search of bookmarked pages.

Andrew Wooster, our little project’s Minister of Search, put a great deal of his spare time into developing and debugging the new search code, negotiating, among other things, the complexities of the SearchKit API and the tricky nature of [NSURL hash] (it turns out, non-obviously, that the hostname portion of the URL is ignored in producing the hash, so any NSURL without a path component beyond the initial slash—e.g. “http://www.google.com/” or “http://www.apple.com/”—hashes to exactly the same thing). Fortunately, he stuck with it, and while the feature may still have some rough edges, Cocoalicious can now boast something close to that “private Google” experience I was raving about!

To try it out, download b31 and choose “Index All Posts” from the “File” menu. Wait until the little progress indicator shows the indexing has finished, choose “Full Text,” and search away.

Fraser Speirs also contributed an extremely useful feature that made it into Cocoalicious b31: tag completion. Now pressing F5 after typing a partial tag into the new post form will cause a list of possible completions to appear. I also added some code to provide the option of automatic completion, after a user-specified delay.

Thanks again to all of our contributors, and sincere apologies to the people who have sent patches I haven’t looked at yet—I’ve been extremely preoccupied lately, and I promise to get back to you soon.

Just a quick note to anyone who has been wondering: I have finally been able to confirm that PodWorks is compatible with the iPod shuffle. That means that my stalwart little app can boast compatibility with every iPod from the original 5 GB model up to the new wave, flash-based shuffle. Pretty cool!