Web-Style Widgets For Desktop UI 23
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."
Just when you thought it was safe.... (Score:3, Interesting)
on the other side though, as a native web developer, this could make programming in the windows application environment a little friendlier.
Re:Just when you thought it was safe.... (Score:2, Interesting)
If later parts are dependent on earlier parts, ghost them out until the earlier part is completed (perhaps also a "depend
Not wizards! (Score:5, Interesting)
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.
Re:Not wizards! (Score:1)
Re:Not wizards! (Score:2)
I realize that. I'm just thinking that many "uncommon" tasks aren't quite as "uncommon" as one might expect. Setting up a network interface, for instance, would probably be something that most folks would call "uncommon", but when a network guy has to configure a
Re:Not wizards! (Score:1)
Re:Just when you thought it was safe.... (Score:2)
Dorks should have used a term that actually implies what it will be used for. I use my wizards to smite my enemies. Will a Network Wizard help me smite my enemy networks?
I sure hope so because I have many. All I need now is a Pigeon
PHP-GTK? (Score:4, Insightful)
Nick
Re:PHP-GTK? (Score:3, Insightful)
Hm, where have I heard of this before? (Score:3, Insightful)
Re:Hm, where have I heard of this before? (Score:4, Informative)
Re:Hm, where have I heard of this before? (Score:1)
Re:Hm, where have I heard of this before? (Score:1)
Re:Hm, where have I heard of this before? (Score:2)
A brief history of desk widgets. (Score:4, Interesting)
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.
Re:A brief history of desk widgets. (Score:2)
Re:A brief history of desk widgets. (Score:2)
They tried to hide it in complicated talk about users and return on investmen, but it's just a shift to a component model that doesn't need a complicated UI involving menus. The problem with this idea is that it will limit what can be done. You will only be able to do what they, the creator of the component, want you to do.
For those who didn't RTFA (Score:2)
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.
Re:For those who didn't RTFA (Score:3, Interesting)
Right, which is exactly what Dashboard (and the like) do. Dashboard applications are entirely XHTML/WebForms2/Javascript based, and are meant to provide the functionality that is described in the article.
My previous tounge-in-cheek remark [slashdot.org] stands.
Um, No (Score:2)
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
Re:For those who didn't RTFA (Score:2)