I was quite disappointed to hear that Robb Beal was not going to be spending as much time on Spring as he has been. I think Spring is an important step in the evolution of the computer interface, as we continue the path that the folks at Xerox PARC put us on when they invented the GUI.
It is not unsurprising, however, that Spring has failed to gain a large following outside the technorati. Spring has some serious deficiencies that I believe must be corrected before it can have any hope of wider acceptance in the Macintosh freeware market.
The first problem, and the most superficial, is the astoundingly spotty documentation. There are more examples than you can shake a stick at, which is usually a plus in software documentation. Unfortunately, there are very few actual instructions on establishing workflow. Some guides to establishing a process for use would be incredibly helpful.
There is also nearly no documentation explaining the limitations of the interface. I spent a maddening few minutes trying to figure out why the Me object I created did not carry the picture I had included in the Me dialog. Instead, I had to drag a picture on the object from outside spring, which worked fine.
Spring also has some frustrating and puzzling limitations on the apps that it considers "blessed" for interaction with Spring. As stated in the Spring Quickstart guide, "AOL Instant Messenger (AIM) is an integral part of the Spring experience." But what if you don't use AIM? What if you prefer Yahoo Messenger? Or Jabber? What if you don't want to support AOL for ethical reasons? This statement is strong enough to warrant putting Spring into the Trash Can without any further ado. One might even ask why a strong independent developer is giving free marketing to a multi-billion dollar company.
This leads to a deeper question of why there are so few ways to share objects between users. Why not Rendezvous sharing on local networks? By embedding Jabber client code, canvases could talk to themselves directly, using SSL even. Every Mac comes with an Apache distribution. This too, could be leveraged. Imagine Spring starting an instance of the Apache server running with user privs, bound to a non-prived port to avoid ISP port blocking, and using a custom configuration. Canvas and object sharing could then be done via http requests. The possibilities are endless. Yet, we are stuck with AIM?
There are more examples of this. Watson, for instance. For as much use as I give it, Sherlock is more than sufficient for my needs. I've tried the Watson demo several times and never felt that it was worth the amount Dan charges for it. That's a personal choice, not a reflection of the quality of Watson; I simply don't feel that it puts me out to visit the websites. Certainly not enough to pay US$30 for the nice interface. Its a really cool toy, but its a toy, and with the new baby, my pocketbook is not deep enough for toys. (Note that I feel the same way about Spring itself.) Were Spring to support even basic interaction with Sherlock, things might be different. I might spend US$30 on Watson, or US$21 on Spring, if either one of them made my life easier, but I'm really not likely to buy both.
The essential problem here is that by making these somewhat arbitrary choices of "complementary applications," Robb has limited the bulk of Spring users to the intersection of the set of AIM and Watson (and etc.) users. Limiting an already small userbase is not a recipe for success.
Of course, were Spring's methods for creating objects not crippled in such unusual fashions, this might not be an issue. The Spring website claims that Spring supports stock quote objects. It does. However, if you want to add your own (without Watson, I assume), you get to edit a template XML file included in the Spring distribution. This is not a stellar example of "user-centric" behavior.
I recognize that much of this represents a huge workload for a single developer. The time honored way of dealing with such bottlenecks is for the developer to write a plug-in API. And this is what I think is the key to Spring's woes are. If you are writing something to revolutionize the user experience, you have to have functionally infinite resources in order to get into every nook and cranny of the old user experience. And Spring is in this camp. I'll take a line from one of its pop-up menus as proof of the statement: Suggest an action.
In my current Desktop Canvas, about half of the possible object-object interactions currently consist of that one line. Suggest! Suggest, my foot! Give me the ability to write my own freaking actions! Give me the ability to write my own sharing protocol. Make it possible for the technorati like us, who love the app, to turn it into something more than a toy. Someone will write playlist object that lets you add live-updating "Currently listening to:" field to one's sharable user object. Then, I can bring up Spring, right-click on Robb's icon, see that he's listening to a band I've never heard of before. I know I like Robb's taste in music, so I drag to the iTMS store object, and iTunes pops up with all of that artist's albums. That is the kind of interaction Spring is about.
If Steve Gehrman is reading this, he's probably chuckling, because I wrote a similar rant to him in a private email in the days right before SNAX became Path Finder. I don't know if anyone else had also emailed him, or if I'd anticipated Steve's own design strategy, but Path Finder gained a plug-in API, and is infinitely cooler for it. (And I didn't even have to write the plug-in I really needed, the Image Converter, cause Steve made it one of the examples! How's that for service?) I think Spring would similarly benefit from a component architecture. With NSBundle (or CFBundle for the Carbon folks), there is precious little reason not to consider creating a plug-in API. The costs are so minimal compared to the potential rewards. Ranier Brockerhoff had a wonderful session and tutorial on using NSBundle at MacHack 2002. The notes for that may even be available on his website somewhere.
Posted by brent at 21:50