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.
Thread beginning with comment 282882
To view parent comment, click here.
To read all comments associated with this story, please click here.
JonathanBThompson
Member since:
2006-05-26

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

leavengood Member since:
2006-12-13

"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."

From what I have seen, the Mac OS X Dashboard provides some additional HTML elements (canvas for example) as well as some Javascript bindings for parts of the system. In addition there are "Widget Plugins" which can be implemented in Cocoa to provide Javascript bindings to essentially anything. I believe this is how the iTunes Widget works for example.

So I suspect almost anything could be implemented as a Widget, though obviously implementing plugins in Obj-C is a bit beyond anyone but programmers.

Once my WebKit port to Haiku and its associated browser are in good shape, I will probably investigate making a Dashboard/Sidebar like thing for Haiku. I'm not sure how useful it would be, but I imagine it would be fun to implement ;)

But at the rate things are going, I doubt I will get around to that until February/March next year.

Reply Parent Score: 1