Archives / Search ›

Even free, iCal isn't worth the price. Everyone else is pointing to this, I might as well too.

Consider the history of the iApps: iMovie was, and is, great, defining a category of its own with its power and ease of use. The few bizarre interface designs in its early versions were worked out. iTunes made its name among MP3 players with some incredible design, and rose to the top when nothing else could compete. It's simply terrific, one of my favorite programs, though it was a bit buggy in early versions, and keeps getting better. iDVD I've never used, so I can't comment. iPhoto was slow, clunky (especially in its on-disk storage), innovative in places but overall so very capable that people used it despite its failings. iChat is decent, cute (in a good way), somewhat feature-poor and buggy, but has a lot of promise for the future, and compares especially well against the commercial IM clients with their constant onslaught of ads.

iCal is slow, clunky, innovative almost nowhere, and aside from the calendar sharing, is outshone by Palm Desktop. When Palm Desktop was Claris Organizer, I switched to it from Now Up-to-Date and Contact, and was willing to give up a bit of functionality for the amazing elegance (and, at the time, lower memory use). Earlier versions of Palm Desktop had some issues with database corruption, especially relating to Palm synchronization, but it's been months since I've had any problems. Not to mention the personal support I got at MacHack from Chris Page :-).

Some apparent trends from the above: Almost every iApp had some bizarre interface quirks in version 1.0 which were later resolved. There's been a general decline of initial quality. There's a discontinuity after which the products exhibited much poorer initial quality starting with iPhoto, when Cocoa became the implementation language of choice.

Hints to Apple: Make sure your new iApp competes favorably with the free software you already bundle with your machines. Cocoa doesn't have to equal buggy and slow. Test your software.

Hint to Palm: Develop a multiuser and iCal-compatible calendar-sharing version of Palm Desktop for Mac and charge for it. I'll pay $100 for it. So will a lot of other people I bet. Really.

Robb Beal posted a comment on my entry pointing to Spring. He describes Spring with a lot more precision than I was able to muster (not that it is hard to do, given my tongue-tiedness on the subject :-)):

As Paul Snively so aptly described it, Spring allows you to discover applications of data. It's a zag on conventional wisdom where the apps work with a single type of data and app vendors are choke points on integration. (Power users can define new drag between actions via XML.)

Check out this post to the Signal vs Noise weblog for other reasons:

http://www.37signals.com/svn/comment.php?postID=467&9

A new release of the Pinstripe Theme for Mozilla is out, the first in several months. If you never peek in the dialog boxes or menus, you could almost mistake Mozilla for a real Mac OS X application.



I'm now primarily using Chimera at work, and Mozilla at home. The primary Mozilla features I'm missing in Chimera are support for boomarking groups of pages, and the Password Manager. I know the latter is being worked on…

Aaron Swartz: The road to RSS 3.0. While I found this humorous, it demonstrates some unstated assumptions about the core of site syndication.

First, note the absence of 'backwards compatibility' in the RSS 1.0/2.0 comparison. The RSS 0.9x/1.0 split doesn't bear a lot of resemblance to, say, HTML 4.0/XHTML 1.x. Everything is smaller: the number of elements and attributes, the amount of divergence between 0.9x implementations, the number of clients and servers and their complexity, the number of unique documents and generators (people or scripts). See the comments in this post on Sam Ruby's weblog for some good discussion.

Mark Pilgrim writes there: “It appears that RSS 2.0 will be much like HTML 4.0 Transitional. Lots of cruft built up that no one is brave enough to deprecate, raising the barrier of entry for developing news readers, and causing confusion for newbies trying to learn by example.” At first glance this seems obvious—there's plenty of cruft and breakage caused by the 0.91 to 0.92 transition which will stick around in a hypothetical 2.0 transition—but the interoperability problems have already been solved. RSS 2.0's core is small. Breaking stuff is bad; needless complexity (RDF) is bad. The audience of tool vendors is much smaller than the audience of people who simply use RSS as opposed to writing it.

Mark has the right idea in his next comment: “I guess we're going to need a widely publicized 'RSS 2.0 Best Practices' document to accompany the spec. Maybe even a weblint-type validator that not only validates but recommends usage patterns.”

Second, more than its unstated goal of stripping RSS to unusability, the sample RSS 3.0 feeds do not allow for including unstructured, hyperlinked text within a feed. Like it or not, I don't want to follow individual article links. The very benefit of writing a syndicated weblog for me is that per-post, they're unstructured, but in summary form (posts, calendars, feeds), they're structured and aggregatable, sortable, and easily navigable.

Nobody asks a newspaper reporter to limit him/herself to one quotation per article, or to make a reader change contexts to move from headline to article. I'd rather the entirety of the content I'm subscribed to (within reason, up to a few paragraphs per entry) were syndicated. We're perfectly capable of visually skipping unimportant information.

As I'm exercising each morning I sit or stand looking at my PowerBook, hitting the space bar or saying “next page” to it as I read through the day's accumulated news. If the entire feed consisted of snipped entries with ellipses at the end, I'd have to stop and click on links all the time.

RSS 2.0 appears to be heading in the right direction. Sjoerd Visscher has a succinct summary of the important backwards-compatibility features of an ideal RSS 2.0, which don't serve to limit its expressivity.

Jim Roepcke points to Tapestry, a Java Web component framework. Zoe is moving to Tapestry from WebObjects, which is as good an endorsement as any. I'm not doing Java web application stuff any more, but if I were, I'd definitely give it a good look.

‹ Newer Posts  •  Older Posts ›