Linked by Thom Holwerda on Sun 4th Nov 2007 19:24 UTC
Graphics, User Interfaces This is the third article in a series on common usability and graphical user interface related terms [part I | part II]. On the internet, and especially in forum discussions like we all have here on OSNews, it is almost certain that in any given discussion, someone will most likely bring up usability and GUI related terms - things like spatial memory, widgets, consistency, Fitts' Law, and more. The aim of this series is to explain these terms, learn something about their origins, and finally rate their importance in the field of usability and (graphical) user interface design. In part III today, we focus on the desk accessory, popularly known as the widget, applet, mini-app, gadget, or whatever the fashionable term is these days.
Permalink for comment 282882
To read all comments associated with this story, please click here.
Member since:

I'll have to disagree with you here, Thom, because it's rare to get the maximum flexibility out of what you can do with a scripting language when you're programming a sufficiently complex widget that's native to an OS: that is, something more sophisticated than that which will run from a webpage. The key here is not that web languages make it available for more average users to create widgets, so much as the barrier to creating relatively simple widgets is a bit lower than requiring them to use a fully systems-enabled language (in other words, a language that has full access to the full system API of the relevant OS) and the reality is that whether a systems language (such as C/C++ or Pascal variants with full API access, as just a couple examples) or a scripting language (JavaScript, VBScript, whatever) is used, has zero impact on usability of the resulting widget, with the greater limitation being what's available from within that language to access the GUI features of the platform, and furthermore, how much the developer wishes to actually use them: for example, in OS X there's a nice little widget that encapsulates a standard Terminal, which, by the standards of GUI usability, is about as far away from it as you can get, short of dip switches and blinking lights. I've not verified which language it was created in, but strongly suspect no web scripting language was involved, while in other cases, I suspect scripting languages were used for widgets I've got in use.

I've not had time yet to fully investigate the Mac OS X API and see which languages have complete (other than the system languages) access to all the features, but it behooves Apple to make as many bindings available as possible for the languages that people actually want to develop in. What's very important to keep in context is that the language doesn't enable the typical user to develop a decent widget so much easier, as does having proper editing tools and documentation. The net result (pardon any possible puns in reference to a web-enabled language) is that all developers of widgets that have any meaningful functionality have to be able to program and solve problems with whichever language(s) they use, and what that means is that people that can't solve problems regardless of development language, still won't be capable of developing widgets in even the "Easiest" scripting language, no matter how much they desire to do so. Adding a URL into a form and calling it a widget and pronouncing "Hey, I've just developed a Dashboard application!" just doesn't count, sorry.

Reply Parent Score: 4