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 282866
To read all comments associated with this story, please click here.
DAs served different purposes ...
by MacTO on Mon 5th Nov 2007 18:46 UTC
MacTO
Member since:
2006-09-21

Thanks to Thom for recognizing that the early DAs offered "multitasking" capabilities on older operating systems. But I would argue that modern DAs have nothing to do with that heritage or even usability.

I would argue that modern DAs serve two purposes:

Eye-candy sells modern operating systems or add-ons (like DesktopX). For whatever reason, people want something that looks good rather than something that just does the job.

While I cannot really speak for Vista or DesktopX, I think it is safe to say that Dashboard provides a development framework that is more accessible to non-programmers because it uses web-development technologies. Sure you end up doing some programming at the end of the day, but HTML, CSS, and JavaScript are things that people actually want to learn.

If is was a usability issue (i.e. people need the functionality wrapped up in DAs), then I would argue that all of these modern DAs would be pointless. A vanilla C application would do the job just as well. All you have to do is tweak the UI and avoid adding a glut of features.

Reply Score: 1

Thom_Holwerda Member since:
2005-06-29

If is was a usability issue (i.e. people need the functionality wrapped up in DAs), then I would argue that all of these modern DAs would be pointless.


That sentence makes no sense. Care to elaborate?

A vanilla C application would do the job just as well. All you have to do is tweak the UI and avoid adding a glut of features.


No, a c application would not do the job just as well, because a c application is a lot harder to write. By using web languages you allow a whole lot more people to scratch user itches, opening up a lot more possibilities. They're the ultimate in high-level programming.

Reply Parent Score: 1

MacTO Member since:
2006-09-21

"If is was a usability issue (i.e. people need the functionality wrapped up in DAs), then I would argue that all of these modern DAs would be pointless.


That sentence makes no sense. Care to elaborate?
"

I should have said that these DA environments (like Dashboard and DesktopX) do not add much in terms of usability. I've used DesktopX before, and everything that it adds to the screen could be accomplished through a regular application that doesn't have DesktopX as a dependency. Much the same can be said for Dashboard, with the (arguably) minor difference that all Dashboard widgets are on a single layer.

"A vanilla C application would do the job just as well. All you have to do is tweak the UI and avoid adding a glut of features.


No, a c application would not do the job just as well, because a c application is a lot harder to write.
"

Didn't I say that distinction exists from the perspective of the developer. At any rate, it is a pointless distinction from the perspective of a user.

Reply Parent Score: 1

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