Archive for August, 2006

The Importance of an Eco System

In my ongoing attempt to buy a decent “iPod alarm clock,”: I discovered the “Big Screen Zip Connect”: from Sharper Image.

The unit has several nice features I’ll never use like the ability to tune to non-US radio stations and listen to TV (I don’t get any broadcast signals strong enough at my house). The unit is also pricey – $173 w/tax and the iPod Remote Zip Connect. I never thought I’d use the Sound Soother feature but found I like it – as does my wife. The volume for waking to the iPod has three choices, “Soft”, “Loud”, and “Ramp” (from Soft to Loud). “Soft” has a volume level of 5 (on their scale of 0 to 99). Again, on this device I wanted a volume of 2 but gave it a try. Still too loud, not as bad as the other units but bad enough that I’m returning it. Worse, the machine “pops” the speakers when it powers up the alarm, and if you hit the snooze or the alarm off you get a loud “beep” confirming your selection. The result is “pop…hmmm…MUSIC…BEEP!” – all I want is “music…” is that so hard? I tried waking to the soothing sound of the ocean – still loud enough to drown in. There are other UI problems, like you can turn off the iPod with the units power switch, but you can’t turn the iPod on, you have to lift it out of the unit and use the iPod controls. So this unit goes back and I’m looking for another.

What was interesting with this device though is the “Zip Connect.”: Sharper Image has taken nearly all of their audio gadgets and added a proprietary Zip Connect to it. Each of these devices comes with a module to adapt the connector to a standard stereo mini line-in. You can buy an optional module to connect to your iPod which will play through the unit while charging the iPod, and some unites allow you to control the iPod. None of the units that I saw cradle the iPod as well as most iPod specific accessories but their functional and work with any iPod. The Zip Connect is Sharper Image’s way to protect themselves in case Apple suddenly changes connections or they may support other devices in the future.

Having owned a Palm V, m505, Treo 600, and Treo 650, all of which have different connectors, I can appreciate this. I’ve spent a fair amount on accessories for older units which I couldn’t use with new units. This became a barrier to upgrade and with each upgrade I’ve been hesitant to invest in more accessories to avoid lock-in. I’d still be running the Treo 600 except it failed one month out of warrantee. Had Palm stuck with a single connector – they could have a rich eco system as the iPod does now.

The Sharper Image approach is the hardware equivalent of a private, pure virtual function call – it’s expensive (costs you $10 to subclass + added cost for default line-in module), it can’t do anything without a subclass, but it does provide some flexibility for the future – but only friends of Sharper Image can provide modules.

Ideally, we’d have an open standard for such connectors (maybe call it USB) with standard protocols for controlling audio devices. Carefully thought through, legacy devices would either just work or only require a small adapter – but new devices would plug right in. But for now, Apple, Sharper Image, Palm, and most other manufactures are sticking to the proprietary interfaces. Even if I do settle on the Zip Connect device, I still can’t plug my Treo into it.

The software solution to this problem is standardized Concepts. C++ provides the requirements for items such as iterators but stop short of semantic requirements. Even the most basic requirements of “regularity”: are not universally adhered to. A colleague recently sent me a piece of code which contained the following:

Matrix Inverse (const Matrix &M)
Matrix S(M), T(M); // temporary matrices of the same size as M

T = M;

Without the comment, I would likely have deleted the assignment – there is something very wrong when a copy constructor doesn’t copy. A Zip Connect won’t help you here.

Building Software Oracles

I’ve been giving some thought lately about how to structure software applications. One of the long term goals for the Begin example application, part of “ASL,”: is to create a rich web client for “desktop like” hosted applications. In a recent discussion it occurred to me that there isn’t any good reason why we shouldn’t keep the application front end in it’s own process. We can have a single, universal, application interface which is configured with declarations to be any application and pair with an app server, running locally or across the network. Yes, I know, this isn’t a particularly novel idea (I’m typing this in a browser at the moment) – I just happen to think with ASL we’re getting close to making it work _better_ than the current all-in-one-process desktop model.

In some ideal world this would have three layers – a declarative UI front-end, a declarative document model back-end, and a collection of generic algorithms to do processing in the middle. The difference between Photoshop and Word becomes the descriptions at both ends and what algorithms are in the middle – the more algorithms we have the more applications we can build.

One challenge with such an architecture is how do you monitor progress of the middle process? I certainly don’t want to require that the code be littered with “progress markers” to communicate state back to the interface. This is one of the challenges that’s often sited as a key feature for aspect oriented systems – you can build an “oracle” aspect which will monitor progress. That’s somewhat like littering the code with progress markers – except a less intrusive.

I believe there is a reasonably simple, generic, approach that should work quite well – for any operation which streams back results, we can simply mark progress by the data received – knowing the total amount of data expected and complexity of the operation this should work quite well. For operations which take significant time before they return a result, we should be able to accurately predict their completion by knowing the complexity of the operation and a profile of the operation for the machine (which can be generated through use) – in this way we can come to predict completion (and use this information to keep the OS from throttling our process back while we’re busy). If we run significantly over the expected completion time, we can assert failure and interrupt the process – with a good transaction model even failure can be graceful. What Apple is doing with “CoreData,”: is a good proof of concept for the back-end of such an architecture.

I think the key piece that has prevented desktop applications from having more of a “server” architecture (besides OS’s which could multi-task worth a damn until fairly recently) has been handling interactivity so the user is in direct control instead of feeling like they are filling out forms and issuing requests. By modeling the functions in the interface process, and building tight communication between the processes into the architecture this could be achieved.

A Crippled Human Interface

This is the first entry in what I intend to be my daily blog. I’ve been kicking the idea of a blog around for sometime – for me the question has been, “what should the purpose of the blog be?” My team already has a public face with the “Adobe Source Libraries”: so time spent working on a blog is time I’m not spending on code, documentation, a paper, or, more likely, answering e-mails. I decided a blog could be cathartic – a way to clear out the random thoughts rattling in my head before sitting down to focus on other work. (Of course, it could just be distraction in which case this will likely be a short lived blog.) So if your looking for deep insights, you’re likely better off reading something like my friend “Jon’s new blog.”:

The random thought for today has to do with a crippled human interface. I spend a fair amount of time thinking about human interfaces from the engineering side – a significant portion of Adobe’s application code is dedicated to the human interface and it is a focal point for our declarative programming efforts in ASL. I define a human interface as:

* A system to assist the user in selecting a function and providing a valid set of parameters to the function.

The definition of a GUI can be obtained by prepending “visual and interactive” to system. A key word in this definition is “assist.” There are many ways to assist and sometimes things go wrong – a little like the old story of the Boy Scout who insists on helping the old woman to cross the street against her will.

This morning I was rudely awakened by just such a case of assistance gone wrong. I’ve been on a mission to find a good alarm clock which can wake me to my “iPod mini.”: Last Christmas I was given an “iHome”: – the device is quite wonderful, except the minimum volume for the alarm is loud enough to wake the neighbors. It quite literally will blast you out of bed. I’m a fairly light sleeper and I can wake to just a little soft music – at the right volume it will wake me but not my wife. Because of this problem I returned the iHome.

The next alarm clock I tried was the “iBlaster.”: I didn’t even bring this one home, I tried it at the store and it had exactly the same problem. The interface is so close to the iHome that I’m certain they share the same internal circuitry.

Next up, the “Fisher Studio Standard.”: I purchased one of these yesterday and set it up last night. Again, I believe this device shares many of the same components with the iHome (and iBlaster) – but I had some hope. It appeared to be a “2.0” version of the interface. As I set the alarm it “asked” what volume I’d like – anywhere from 10 to 99. Except I want 2 and there is no way to get 2. 10 wasn’t nearly as loud as the iHome or iBlaster so I gave it a try. My wife was kicking me faster than I could hit the off button so this device is also heading back to the store.

I’m certain that the lower limit for the volume on all of these devices is an attempt to prevent me from picking a volume which is so low that I miss that important meeting – some very concerned UI Scout is trying to make sure I cross that road. There needs to be another merit badge for UI designers – one that teaches that the purpose of the human interface is _not_ to prevent me from getting to valid parameters. A perfect solution on these devices would be to have a volume level of 10 be the default when first setting an alarm, but let me pick the level I want.

If you have any suggestions for a good iPod alarm clock, post a comment.