As I may have noted, I’ve purchased every version of Mac OS X. That means that I’ve been around for some of the less-than-great versions and features and have seen those features eventually get finely tuned to become a seamless part of my computing experience. However there were some features that were perfect from day one, most notable in my books is “Dashboard”– the widget host for the Mac OS X desktop that premiered in Tiger (Mac OS X 10.4) in 2005. Whether or not you use, or even know about this, widgets have a long and great history…
Going back to the mid-eighties, you may remember that the early Macs didn’t multi task. The only exception to the “no multitasking” rule was drivers and desk accessories. A desk accessory was what I would call a micro-application in that it usually served one small function and could interact with other applications almost like a plug-in. They did have a few limitations though; the most notable being that they had to be written to a driver-like programming model which means that writing a DA (desktop accessory) in a higher-level language was difficult because most higher level languages (like Pascal) can’t directly interface with driver buffers. Also, a DA was only allowed to have one window. To make a DA was at one point considered more difficult than writing a standalone application, mainly because the early developer tools (provided by Apple) didn’t do much for DA developers. As Andy Hertzfeld mentioned on his folklore.org website, the Mac OS had previsions to load user-installable drivers, and so the team decided that the DAs be implemented as a “special kind of driver”. The system included a few by default; calculator, control panel, Scrapbook, and alarm clock just to name a few. A user could also purchase or download (in theory) 3rd-party DAs from developers; ie spell checkers, dictionary/thesauruses.
What is particularly interesting is the evolution of these desk accessories; after the release of System 7, which included native co-operative multi-tasking, Apple pushed people in the way of making small applications instead of DAs (DAs are more limited in functionality, so this was a much better route for a developer to go). The other benefit from this transition to applications was the ability to write (natively) in a higher-level language. However since the release of System 7 (in 1992) the world seems to have forgotten the need for simple programs like DAs–the advancement of all of what I’ve talked about just about ceased… until the release of Konfabulator in October of 2003.
Konfabulator is a javascript rendering engine that reads small package files that contain javascript (the main program code), embedded images and other resources, executes these “widgets”, then preserves widget specific variables and data between restarts. Konfabulator was released for $24.95 on Mac OS X (minimum Mac OS X v.10.2) in October of 2003. The best part of Konfabulator was the way that you could put widgets as being always visible like regular applications, behind the applications, or in a hidden layer of the desktop that is called when a user-defined event happens (key-combo pressed, icon clicked, etc…). Konfabulator was acquired by Yahoo in July of 2005 and still survives on Windows (2000 SP3+, XP SP2+, Vista) and Mac (v.10.3+, Universal) as Yahoo! Widgets. It has been available for free since it has been branded as Yahoo.
I’m going to go out on a limb and say that someone at Apple saw the future and envisioned the world as it is today (in 2009)–a world run almost entirely in the cloud–and saw an iPhone-like device that would run web-based apps, similar to what we saw announced in 2006 with the iPhone. The problem would be tuning their rendering engine and framework for the eventual iPhone web apps, which would demand much more performance, stability, and reliability. The biggest hole in my speculation is that the iPhone web apps ran in Safari on web pages that had to operate in the cloud (the iPhone has no functionality for web apps to keep their state inside of the device) and also required more programming than just javascript. Because of this lapse in my theory I also propose (as someone may have before me) that the iPhone was originally intended to run widgets. Why widgets on the iPhone didn’t pan out doesn’t make sense to me because it would probably be a great user experience. Not to say that the native apps we have today aren’t great, but to be able to have the iPhone run apps written in a language with such high adoption rate would definitely prove to be beneficial to the consumer.
1. Great! I love widgets!
2. I don’t think they will be that useful.
I remember back in 2005 I bought my copy of Tiger and imagined how great the many features, specifically Dashboard, will be. Tiger installed without a single issue–of course, being a veteran Windows user, I backed up my data and did a clean install. All said and done it took about 45 minutes to install and an evening to restore my data. The problem came when I tried using Dashboard and Spotlight and all the other wonderful features that I can’t imagine not having today on that eMac with an 800MHz G4 and 384MB of memory. It didn’t work. After further investigation I found that Tiger took a lot more of my hard disk, created a h-u-g-e page file, left me little free memory and decreased what had previously been a rock-solid machine to a quivering mess (almost like the previous PC I had, when trying to get it to use Windows ME). I can say that however the widgets were cool, they just required more from the host computer than it had to offer. I reformatted my hard disk and re-installed Panther (v.10.3).
Of course years passed and I (embarrassed to say) switched back to a PC in December of 2005. I didn’t see what I wanted in the then-current Mac lineup and made the move over to a PC. Of course I never really had a problem with the PC and I don’t regret my time on the Windows side of the fence, however when I moved-to-mac… again.. I found a lovely 24″ C2D iMac.. with Tiger. Except this time Tiger performed well in the 2GB of memory and the spacious 250GB hard disk and the dual-core 2.33GHz processor. The problem was that I was finally ready for widgets, but I didn’t want them. Widgets seemed to be a royal pain–they always seemed to crash or freeze, always seemed to consume too much memory, and rarely felt the way I wanted them to–they didn’t feel Mac.
I’m not sure what facet of my brain mandates how I feel about Dashboard, or in a more broad sense, my feelings about organization. Everyday I use many screens–in fact most of my work is done across four monitors–the 17″ laptop screen, 24″ iMac, 19″ secondary iMac LCD, and a 19″ tertiary computer that runs TV, Friendfeed, and TWiT all day (my information-at-a-glance screen). Why do I do this? Because I hate piles. Piles are an obvious fact of life–the problem being that you can’t see something in the middle of the pile without deliberately looking for it. The problem with computers is that they’ve taken this desktop-metaphor to include piles. Piles on a computer was a reason why the original Macintosh didn’t do multitasking. But we’ve gotten used to piling our windows on top of each other and have grown to use much more computer real estate than back in the day with a 9″ monitor. The issue I have with Dashboard is that it’s out-of-sight until you chose to view it. In all sense of productivity it may be the best thing that could be; a mode that you go to when you want to find something out such as the time, weather, tracking a package, sport scores, calendar, or do a quick calculation. It’s a separate desktop that is piled on top of my current desktop.