Slashdot Mirror
Web-Style Widgets For Desktop UI
prostoalex writes "Longhorn libraries for UI will include Web-style UI widgets to be used in desktop applications. Michael Weinhardt talks about building inductive user interfaces and general UI guidelines in the MSDN article."
So this means... more wizard-style interfaces? There must already be 15 useless wizards in 2000 and XP.. things like the "connect to the internet" wizard, where all the defaults are always wrong... now it just got easier to do.
on the other side though, as a native web developer, this could make programming in the windows application environment a little friendlier.
In Soviet Redmond, software programs you!
This kinda sounds like the inverse of PHP-GTK, But... could PHP-GTK be used in this way?
...
Nick
Electronic Music Made Using Linux http://soundcloud.com/polyp
Hm, where oh where could it have been...
This idea is said to have originated way back in Mac OS . . . 1. Well, this was before the web. But the idea was similar. The original Mac OS had no multitasking. So, the developers created something called "Desk Accessories", in assembly, to run as useful little utilities that didn't quite qualify as full-fledged apps.
I've never really understood, however, why people would want this. On Mac OS X, there's a program called Konfabulator that offers this functionality. In the end, I found it just to be mere clutter and eye candy rather than actual functionality. But, it seems, a lot of people have come to like the concept and implementation.
So this means... more wizard-style interfaces?
No. It's actually a different metaphor. I really think that this guy is still missing the point -- I really think that Apple Guide-style interfaces are the best approach around. Here's a breakdown:
* Wizard-style interfaces. The purpose of these is to allow either a simpler or faster interface that is an alternative to the regular interface. A more limited featureset is available from a wizard, ideally representing the most common tasks. This in theory inconveniences neither basic users nor advanced users, since advanced users can simply use the full interface, and basic users can stick with the wizard for their "common" tasks. The main drawback is that knowledge gained about one interface fails to carry over to the other interface -- there are largely two pieces of software present. In addition, it's the most expensive to maintain, since there are two full interfaces present.
* This IUI business, based on the article, involves use of a single interface (unlike the twin-interface wizard approach, which has a "basic" and a "full" interface), and simply places instructions for what the user must do throughout the interface. It serializes tasks ("do A, then B, then C"), and probably trades off speed of use for an experienced user to help inexperienced users know how to perform the operation. IUIs are probably the easiest of the three to implement, but they also annoy the bajezus out of people that know what they're doing.
* The third approach, Apple Guide-style, which is what the old Mac UI engineers came up with. Unfortunately, their implementation wasn't so hot -- a pain to actually do up Apple Guide docs, so it fell into disuse. The concept, though, is excellent. A developer provides the full, advanced interface, just as with wizards. However, they then provide a large set of interactive help files that walk a user through common tasks, circling the widgets to click onscreen, and so forth. With this approach, the user is rapidly converted into an advanced user, and can take advantage of the full interface, though it may be slower than wizards to do a common task the first time. The only issue with the AG-style approach is that sometimes wizards are used to provide macro-like functionality -- suppose setting up a network interface for a particular common configuration involved entering the same number in three different places (say, allowing UDP from the nameserver through the firewall, telling the resolver to use the nameserver, and telling a network monitor program to use the nameserver as the box to ping to determine if the interface is having problems or not). A wizard could take a single value and slap it in three different places, but the AG-style approach would still require the user to enter the number three times.
On the whole, I think that IUI is just a poor replacement (though somwhat cheaper to implement) than AG-style interface. Take the *IX philosophy -- we'll try to empower you as much as possible, just as long as you're willing to learn, and add the phrase "and we'll also teach you as you work", and you have a good idea of what the AG approach is.
Just another amazing piece of work from Apple in it's golden days of interface design that unfortunately wound up dead. Sigh.
May we never see th
This isn't about Dashboard or the like (Wait for an article on the Longhorn sidebar for that, but make room for the WindowMaker/NeXtStEp users).
Longhorn will provide a framework (not required) for organizing your app into pages with web like navigation. This series of articles illustrates a library for doing the same using the current WinForms library.
DCMonkey
This article is about creating web-like navigation for normal native windows apps.
/. story at it's word (not a safe thing to do, sadly).
Dashboard is about using web-like markup and scripting to create small desktop utilities. While I imagine you could do the former with the later, that isn't it's purpose.
Your remark only applies if you take the title of the
DCMonkey
when it was called Active Desktop.
It's a very dark ride.