Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
GUI Software

Web-Style Widgets For Desktop UI 23

Posted by timothy from the one-and-the-same dept.
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."
This discussion has been archived. No new comments can be posted.

Web-Style Widgets For Desktop UI More

Web-Style Widgets For Desktop UI

Comments Filter:
  • 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.

    • Re:Just when you thought it was safe.... (Score:2, Interesting)

      by Anonymous Coward
      I wish web-style interfaces would lead to LESS wizards!. There is NO POINT separating stuff into a load of pages like wizards do. Why not give me a long document-like form to fill out? AND MAKE THE DOCUMENT INCREMENTALLY PROCESSED - each entry causes another validation pass, and good entries are ticked as good, missing entries question-marked if mandatory, and bad entries crossed as bad.

      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)

      by 0x0d0a ( 568518 ) on Saturday August 07, 2004 @01:06PM (#9909008) Journal
      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.
      • As mentioned in the article, this isn't meant to be a catch all interface used for all tasks, rather it's mainly useful for rarely used operations where the individual is unlikely to retain working knowledge over the time gaps seperating usage. Your criticism is appropriate where developers have overused the interface and applied it to common tasks as well, and I'm not sure that making it a readily availabe option with its inclusion in the Longhorn tools will increase misuse or not, but when used judicious
        • As mentioned in the article, this isn't meant to be a catch all interface used for all tasks, rather it's mainly useful for rarely used operations where the individual is unlikely to retain working knowledge over the time gaps seperating usage.

          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
      • Uh, Eclipse cheatsheets! I thought they were too kewel to be something non-Apple ;-) No seriously, I was thinking of building a client app using eclipse platform & cheatsheets... we can only hope Microsoft hasn't patented the damn thing! cheers!
    • Because the term WIZARD immediately connotes to the user just exactly what it is supposed to do. I mean everybody knows that Wizards use their powers for uhhh, gee, I dunno, so a Microsoft Wizard for a certain service will NATURALLY do uhhh, I dunno, WTF is this thing for?

      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)

    by polyp2000 ( 444682 ) on Saturday August 07, 2004 @11:36AM (#9908592) Homepage Journal
    This kinda sounds like the inverse of PHP-GTK, But... could PHP-GTK be used in this way?

    Nick ...

    • Re:PHP-GTK? (Score:3, Insightful)

      by Fweeky ( 41046 )
      Er, no; it's a set of UI elements which happen to look like HTML ones. PHP-GTK's no more relevent here than any other language-toolkit combo.

  • Hm, where have I heard of this before? (Score:3, Insightful)

    by GregChant ( 305127 ) on Saturday August 07, 2004 @11:45AM (#9908635)
    Hm, where oh where [apple.com] could it have been...

  • A brief history of desk widgets. (Score:4, Interesting)

    by Amiasian ( 157604 ) on Saturday August 07, 2004 @11:59AM (#9908682)
    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.
    • They can come in handy. I use Superkaramba in KDE, and wrote my own themes to gather and display some stats from around my home network using snmp. Obviously you can go a little overboard, but they don't have to clutter too much.
    • Microsoft is building a component arcitecture. They are extending the VB type model along. Unless Apple invented the component model, then I doubt this based on their work.

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

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

      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.

      • This article is about creating web-like navigation for normal native windows apps.

        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 /. story at it's word (not a safe thing to do, sadly).

    • Except that WindowMaker and NeXTSTEP had nothing like Konfab or Dashboard. I've heard a couple folks mention it like they did, but I've no clue what you could be talking about. In WMaker you have dockapps, but it's never seemed the same as konfab or dashboard- or even Longhorn's sidebar. A lot less flexible with that little 32x32 tile. *shrug* NeXT/OpenStep never reall had that though, the only app that did it was the clock. At least, in years of using NeXTSTEP and then OpenStep, I never found an app tha

Slashdot Top Deals

On the eighth day, God created FORTRAN.

Close