Ron’s post this morning on applying some lesson’s learned from Twitter to more effortless project management input is one of the first good reasons for using desktop widgets. I’ve long been skeptical of the idea of desktop widgets, primarily because I’ve used them so long myself on OS X with little value beyond quick “read only” scenerios. I use OS X “dashboard widgets” for clocks, the weather, and Feedburner stats. Occasionally I use the character look-up widgets for keyboard and HTML…usually when I need to to link to Bill ;>
The Value of Widgets, A Naïve View
There are three benefits to widgets:
Desktop widgets minimize context switching - because widgets are small and usually/hopefully perform just 1-3 functions, they’re both quick to switch to, quick to figure out what to do in, and quick to switch out of. Context switching is a big deal in information work, and cutting seconds here and there is an equally big deal.
Desktop widgets (should) be easier to code - most widgets are based on stripped down GUI models, perhaps HTML/CSS/JavaScript. Because desktop widgets are supposed to provide less features per widget, they need “smaller” frameworks.
Desktop widgets look cool - ‘nuthin’ wrong with looking cool. It motivates users and developers to use and create widgets.
Those are some nice motivations, but I never quite felt like they justified everyone’s enthusiasm for desktop widgets. Also, there’s the biggest argument about desktop widgets: why not make them web widgets? Don’t we want to get away from the web? On that note, in my experience converting from Windows land to OS X land some years ago, the desire to move to a web is more a rebellion against crappy desktop applications and workflow than moving to a whole-sale better platform for UIs, namely, the web. But, that’s a discussion for another time.
More germane is the idea that desktop widgets can be front-ends for web applications and platforms. Context switching to and fro the web is one of the biggest context switches there is, and desktop widgets might be a good de-clotter for that problem.
Again, even with all of this, my general feel on desktop widgets has long been: why bother?
All the Write Reasons
The main reason is that to me, any piece of software is more valuable when it performs write operations, not just read ones. So, while I like all the clocks, weather, and feed stats on my dashboard, they’re not really “needed,” they’re just window dressing.
But, Ron started to outline some compelling reasons, once a desktop widget is given “write power,” that widgets would be nice. Primarily, if I may layer my own wording on-top of it: desktop widgets seem like they’d be good for getting people to do boring tasks more often and more enthusiastically.
Boredom Costs, Prevent It
Updating project management stats (those that can’t be or haven’t been automated) is boring. Telling your ERP system about some state change in your organization is boring. Filing expenses is boring. Thinking creatively — and pulling some memories from SAP-land, where they’ve been going nutty on desktop widgets — you can imagine how a little desktop widget for each of these boring things would make the info worker who’s performing those tasks less bored. Boredom prevention is a tragically forgotten key to good software; Kathy Sierra’s build a nice profile of late reminded people to simply make their stuff fun.
Key to fighting boredom with desktop widgets is building out APIs on the core platforms that allow widgets to not only pull data out of the system, but push data into the system. For example, to add a new expense to the current pile of expenses; to mark some task as done; to approve a vacation request. The low hanging fruit here are work-flows in information worker life that require minimal entry, making yes/no/not now decisions (see Highrise for a brilliant approach to assigned due-dates to tasks), and, if you’re really cool, work-flows that are simplified once a user’s context is persistent and known by the system.
What’s the last one? Let’s take my favorite bugbear, expenses. An employee files batches of expenses every month (or two, or three…whatever interval). Between filing for expenses, spending money, putting together your expenses, and then filing for that new batch of expenses, there’s a certain “context” open for the employee. That context is, metaphorically, an open file that the employee can add expenses to. So, a desktop widget would be connected to the “back end” system that knew the current “open file” that an employee would add expenses to. The resulting widget then, could simply have 2-3 fields: expense description, expense amount, and (optionally if it wasn’t today), expense date. Now, if you could hook that widget up to a scanner to scan in that damn paper, that’d be even cooler.
I’m sure there’s plenty of people ready to point out all sorts of systems that already do something like that with expenses. The larger point here is to apply that kinds of user interaction to other, boring systems. And, of course, to make sure systems and platforms have open enough APIs to work with desktop widgets. Tara Hunt recently wrote up about all you need to know on the second point.
In that scenario, desktop widgets start to seem worthwhile to me. (Of course, it still assumes I care about the desktop: that’s the biggest issue.)
Previous Topic
