Post Archive
› June 22, 2005
OS X Widget Designer's Checklist
I've been quite annoyed with myself for making the "I hate OS X dashboard" post quite so negative. I'm actually quite excited about the possibilities that dashboard allows, the potential is great - especially for those with web level (but not desktop app level) programming skills.
What spurred me to eschew widgets to begin with is the catch-22 they present: easy to build equals more folks can produce them (wonderful), but easy to build also equals opportunity for poorly thought out ideas to be built (not so wonderful). With a desktop app, the investment in time and money to build is much greater, and so, more likely to be carefully considered - and of course we all know that even that barrier doesn't put a harness on bad products.
So, with that in mind, I thought I'd put together a widget designer's pre-launch checklist:
- Are the features in my widget more easily accessible elsewhere?
Calculator widget fails, but clock passes because multiple clocks can be used for time-zone comparison - Can the exact functionality of my widget be found as part of a free desktop application? (e.g. showing song title from iTunes)
- Is my widget still useful without any visual dressing? Is it just about looking cool?
- Am I providing an interface and feedback mechanism that is best suited for the user? Or just easiest to build? Or just neat looking?
- Does my widget take up more screen real estate than needed? Conversely, have I spaced things out enough for it to be easily usable?
- If my widget passes the other criteria, have I designed it beautifully, or hired a designer to do so?
- Widget interfaces are extremely flexible, have I truly considered non-conventional solutions that might add real value to the user?
The first one is the most critical by far. I'd hope that most of these are common sense, but because of the ease and speed with which these widgets can be built - it's a good idea to slow down and consider these things before launching. Any widget makers or users have other things to consider?
Comments
1. June 22, 2005 01:49 PM
2. June 22, 2005 02:58 PM
Nate Posted…
David, these are good points. I don't want to discourage would-be widget developers, but I'm just thinking in terms of cutting down on the clutter and maybe raising the bar for what passes as a widget. For instance, your google-maps widget, I would say that it passes all the checkpoints. Yes, google maps is available on the web obviously, but your version has less to load, and therefore loads quicker, and it also remembers where you were. These are clear advantages over the web version.
But the overall point you make: usefulness being in the eye of the user - that's important, and a good reason why my checklist should be taken with a grain of salt.
3. June 23, 2005 12:15 PM
Egor Kloos Posted…
I once posted and article on my site with the title, "sIFR sucks". After the fact I didn't feel that it reflected my post in best way possible. In the end I didn't change the title. I made my bed I thought I'd just lie in it.
4. June 23, 2005 12:20 PM
Nate Posted…
Well, yeah I didn't edit my original post either - that would be somewhat disengenous. But I can't see anything wrong with a little clarification, especially when there's more ideas to share. Just tucking in the sheets here. :-)
5. June 23, 2005 03:44 PM
Darrel Posted…
Seems like a good list of questions a designer should ask themselves in almost any design (web or otherwise) project.
6. June 24, 2005 10:32 AM
Damian Posted…
" ...the potential is great - especially for those with web level (but not desktop app level) programming skills."
Exactly. Which is why you were right first time. Apple shouldn't be encouraging people who can't cut the mustard to kid themselves they're programmers. They're not. Want to consult an encyclopaedia? Use the browser, because it's simpler than using some half-baked widget. Want a calculator? Use the one in /Applications not something cobbled together in HTML/CSS/JS by someone who doesn't know how to program.
7. December 24, 2005 06:22 PM
blah Posted…
remember, you dont have to install anything. there are just as many crappy applications as there are potentially crappy widgets. i didnt like the widget-top either at first, but once you get used to it, its actually quite helpfull. its just all about finding the right widgets and the right layout on screen for the ones you need the most. while i admit, a google widget is kind of dumb, sence its going to open a browser anyway, why not just open the browser to begin with?
David Lindquist Posted…
This is a good list of things to consider before developing a widget. The only quibble I have with it is that it seems to imply that if you cannot answer the questions it poses satisfactorily, you should not make the widget. Considerations about the widgets design, usefulness, and redundancy are all good, but I would not discount this: widgets are fun. That was my primary motivation in making the Google Maps Widget. I was perfectly aware that the Google Maps web site was just a CMD-TAB and a URL away, but I wanted to make the widget for fun and experience. Along the way I honed my JavaScript skills, learned AJAX, and am now delving into Objective-C in order to write plugins. If some people find the widget useful and/or entertaining, that is icing.
There are very few widgets that represent a truly original idea and singular source of data. But they provide a novel and entertaining interface as an alternative to web browsers and other applications. Whether or not they are useful or redundant depends on the user's particular habits. For example, in Nate's estimation above, the world clock is worthwhile (due to multiple instances), but the calculator is not (presumably because OS X comes with its own). But I think just the opposite, based on my habits. I have little use for multiple clocks. If I need to know the time on the east coast, I just look at the clock in the menu bar and do the mental calculation (my forgetfulness about Daylight Savings Time notwithstanding). If I need to do a more complex calculation, I use the calculator widget rather than Calculator.app. That is just my preference.
The point is that widgets, besides being fun and educational (for the developer) offer the user a choice they would not have otherwise.