[pendragon]

Aside from the obvious (appearance, location, etc.) what are the differences between Widgets & Applications?

Andrew Welch’s Easy Envelopes widget (535k) seems quite comparable to the Addressix application (610k). Both “programs” do much the same thing, yet one is a widget and the other is not.

Is there some behind the scene process, coding etc. that prompts the development of one instead of the other, is there a difference in robustness, functionality, etc., or is it merely the developer’s choice?

I am not trying to start an address-envelope war, I just don’t understand why some programs are applications and others are called widgets and ergo have a different look and location.

[Horsepoo!!!]

Originally Posted by pendragon

Aside from the obvious (appearance, location, etc.) what are the differences between Widgets & Applications?

Andrew Welch’s Easy Envelopes widget (535k) seems quite comparable to the Addressix application (610k). Both “programs” do much the same thing, yet one is a widget and the other is not.

Is there some behind the scene process, coding etc. that prompts the development of one instead of the other, is there a difference in robustness, functionality, etc., or is it merely the developer’s choice?

I am not trying to start an address-envelope war, I just don’t understand why some programs are applications and others are called widgets and ergo have a different look and location.

Well...there isn't a difference. One could code a full-fledged app as a widget if one so wanted. Buuuuut...I think the rule of thumb is, if something has a single and precise function and can be wrapped up in a small and minimalistic interface, it should be a widget.

Easy Envelopes is simple enough to live as a widget but it's pretty borderline. Anything more complex should probably be released as an app.

[pendragon]

Presuming it is easy to convert a widget to an application and vice versa (and I have no idea that this is true), might a developer then release his program in both flavors?

And of course, thanks for the prompt, clear and concise reply!

[cla]

Originally Posted by pendragon

Presuming it is easy to convert a widget to an application and vice versa

False presumption, although there's nothing stopping a developer from creating a widget to go with the application. Or even rewriting the application into a widget.

Technically, a widget is just a OS X customized web page (having access to some of the OS X sub systems). Nothing more.

In my opinion, the most interesting aspect of widgets lies in their very existence: clearly they indicate a problem in the way we define and interact with applications today. Just like tasks and threads in computing, widgets separate applications into 'heavy' and 'light-weight'.
In my world this doesn't make any sense - why need I access different applications different ways? When should a light-weight application be a widget and when should it be an application? And then there's the cmd-ctrl-d (instant dictionary thing) which also is a light-weight application, invoked in a third way. And then there's the services menu, which also contains light-weight applications...

To me it's clear that widgets are the offspring of an interaction problem noone's been able to solve. A work-around. Although neatly packaged, easy createable and turned into an advantage in marketing.

[Horsepoo!!!]

Originally Posted by cla

False presumption, although there's nothing stopping a developer from creating a widget to go with the application. Or even rewriting the application into a widget.

Technically, a widget is just a OS X customized web page (having access to some of the OS X sub systems). Nothing more.

In my opinion, the most interesting aspect of widgets lies in their very existence: clearly they indicate a problem in the way we define and interact with applications today. Just like tasks and threads in computing, widgets separate applications into 'heavy' and 'light-weight'.
In my world this doesn't make any sense - why need I access different applications different ways? When should a light-weight application be a widget and when should it be an application? And then there's the cmd-ctrl-d (instant dictionary thing) which also is a light-weight application, invoked in a third way. And then there's the services menu, which also contains light-weight applications...

To me it's clear that widgets are the offspring of an interaction problem noone's been able to solve. A work-around. Although neatly packaged, easy createable and turned into an advantage in marketing.

Not really...a widget represents a highly specialized task that is repeated very often during the course of a day but isn't justifiable as a full-fledged app to some people.

Things like the Weather widget or the Stocks market widget...both are, to me, unnecessary as apps...I don't want the to clutter my usual desktop environment...both live happily as things I take a look at several times a day on a second and separate 'virtual' space. It's not called a Dashboard for nothing. You bring it up to monitor something or click a few buttons. You're not meant to interact with the widgets for more than a few seconds. Just like driving a car, you're concentrating 98% of the time on the road (the application that you're using), and every once in awhile, you'll check your speed, engine RPM, gas level, put on the air conditioning, change CD track (dashboard widgets).

An app brings together a group of inter-related tasks. A widget doesn't (or shouldn't).

EasyEnvelope is borderline. So is BitStick. Games in the Dashboard such as the Tile Game and some of the old arcade games (some author has started porting games such as PacMan, Pong, Asteroids etc.) are kinda going against what a widget should be.

Don't knock the Dashboard concept if developers don't use it the way it should be used (drawers come to mind here...boy have devs abused of those. :/ )

[m a d r a]

What is the difference between a Widget and an Application?

some applications are useful