The next version of the Microsoft Windows operating system, code-named “Longhorn,” marks a significant change not only in terms of how the operating system works, but also in the way in which applications are built.The Longhorn version of Windows includes a new storage system, natural search technology, and an increased emphasis on security and trustworthy computing.
Here the author provides an overview of Longhorn, focusing on the build-once, deploy n-times application model.
In addition, he discusses the new language, code-named “XAML,” that’s used to create UI elements, then presents some working samples.
In attempt to head the conversation away from the usual flamewar that results from these Longhorn posts …
What does everyone think of MS’ plan to push this Task based Inductive UI thing? They’re building a whole framework for supporting web application-like navigation, ability to start at arbitrary points (ie: bookmarked URL) in the app, and history tracking for rich client apps. With current tools you would have to roll your own framework to do the same.
Will this be the future for many apps? I think It’ll be a good choice for database type apps. You get web like navigation without having to worry about storing state, what happens when you go back from a form POST, and other ugliness of web programming.
Should other toolkits be jumping on the bandwagon or should they stick with MDI, multiple top level forms, trees in the sidebar and other existing rich-client paradigms?
And for those who don’t know WTF I’m going on about, some references:
Older IUI article:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dn…
Reference for Longhorn Navigation classes:
http://longhorn.msdn.microsoft.com/lhsdk/appcore/overviews/appmodel…
Aero User Experience Guidelines: Sampler for PDC 2003:
http://msdn.microsoft.com/Longhorn/understanding/ux/default.aspx?pu…
DB App example (With pictures!):
http://msdn.microsoft.com/Longhorn/understanding/ux/default.aspx?pu…
I think its strange, I’m not sure how it will work. They say to think of a page view as a function call rather than a goto but to me it seems like jumping right in at the 5th page of a wizard. How can you have the data in a consistent state if the user can start the program at any position.
I’m also not sure of the usability of it either. Is the front page of an application just a list of tasks you can perform, and then a multistep process for performing the task before taking you back to the menu? I think users prefer the MDI views of database backed data, it makes them feel more in control of what they are doing. I think I’d prefer it that way anyway.
You can edit what you want, when you want, and the database rules and business logic take care of the interellations for you. You also need to have an undo feature.
I have been using technology like what you see in Longhorn for a long time. I’ve worked in places that had a UI markup in XML similar to XUL, but much more advanced and in Java.What ends up happening is you have a mishmash combination of XML, SQL, JavaScript, HTML, CSS, and maybe calls to backend objects. What a fricking nightmare. The main problem is that for simple things, it’s fine. However, in the end, you end up needing the power of a full programming environment. For *extremely* simple things, XAML/XUL will be OK (maybe not as good as something like VB), but in the end, you end up doing so much work around it in the core programming logic, that you simply give up on all of the meta markup crap and start programming a real interface. It’s not like someone will be able to come along and do much more than change VERY basic layout, or the background color. So what! This idea that you will be able to separate the interface designers from the “coders” is probably overblown.
XML is not a programming language. HTML is not a programming language. They are markup languages, and deserve to stay that way. This XAML thing will be a big flop relative to the amount of attention it’s getting. After all, it’s just another syntax to do some of what you can do in C#, but much more limited. How much more difficult is it to learn the full XAML way of doing things than C#? Not much, really.
The intention behind using XAML instead of C# for GUI definition is that you can resort to using complex XSL transformations to modify your GUI ‘document’ in various ways, presumably. For those who love XML and enjoy thinking recursively (hah!) it allows for a lot of different GUI states to be represented purely as XSL transforms. Also, XAML may be the format of choice for various new GUI Macromedia Flash-like toolkits that will be used to create these new ‘inductive UIs’ (see sub-project “Sparkle”, which is a part of Longhorn).
I forgot to add that it could turn out that XAML may be useful only as a GUI toolkit generated format that will be essentially unreadable by humans and can only be edited and maintained effectively by this Sparkle app, some other Flash-like app or Visual Studio. Aren’t the latest tools moving us away from hand-crafted HTML and XML for the mostpart anyway?
Hmm, the task-based UI seems pretty interesting. Is there anyone in the open-source community thinking about implementing something like that?
Victor.
I can truthfuly say that Longhorn is the only version of Windows that I have ever had any real interest in, it just sounds like if they stick to their guns, like it will be very snazzy.
That said, the whole task-based UI thing could be a good thing for inexperienced users, but if it comes at the cost of the horrid look of 4051, I’m gonna have to second guess my attraction to it. The whole horizontal layering in the Explorer windows absolutely does not agree with me.
Time will tell.
It is similar to libglade. Create the interface using Glade which creates a xml file. Then use a programming language that has binding to libglade to create the backend workings. I created a small Python program this way.
One of the differences I see is that a xaml file can be viewed in a browser. Libglade would need XSL and style sheet support to be able to do that.
This also means that Longhorn’s desktop is basically a web browser. You will not see this with Gnome and KDE anytime soon. But this does not mean that X11 is not capable of having a XML interface. Someone just has to create it.
I haven’t looked but it would be interesting to have Python bindings to the Mozilla/XUL.
Look very close of .dfm files in Delphi…
In a lot of ways, this strikes me as a new improved version of Apple’s OpenDoc architecture, yet another of the interesting technologies that Apple left to wither on the vine.
But I don’t mean to be another “MS never thinks of anything new” voice: MS Research employs some very bright people with some very good ideas, and some of those ideas are in Longhorn.
Rather, I think it is interesting to speculate on why OpenDoc failed. It had the backing of Apple, IBM and Lotus — not small players. It was (and is) a Good Idea. Big developers hated it. Microsoft hated it. So bye-bye, OpenDoc.
The thing is, the big software houses don’t want to muck about with writing a bunch of little components that they have to micro-market. They want to sell you a Big Complicated Integrated Suite which locks you into their architecture forever. Open architectures give them the creeps. Microsoft, for example, wasn’t going to break Office into a bunch of little components. But then neither was Adobe.
OK, that was ten years ago — perhaps a century and a half in internet years. Maybe things have changed. Maybe it makes a difference that MS is doing it instead of Apple. Who knows?
But in the meantime, a lot of OpenDoc thinking did get spread around the software libre movement, and you see the results in Gnome, for example. So I think there is still hope.
I think XAML is a good thing. XML/HTML interfaces currently are stuck using the components/widgets the web browser provides which is a very limited selection. I think XAML will jump start the W3C and others to provide standards which better suit web applications and richer content on the web. I think soon enough you won’t be able to tell the difference between an application written in markup v.s. a compiled app.
I think XAML is a good thing. XML/HTML interfaces currently are stuck using the components/widgets the web browser provides which is a very limited selection.
First you say XAML is great. Then you say XML is not so great. Do you know XAML is just an XML application? There is nothing great about XAML. This is the kind of stuff that annoys me… everybody and their dogs have been doing this before (XUL, Glade), and then MS “invents” this XAML and suddenly everybody is “oooh, aaah, W3C should adopt it! ooooh”
Victor.
I wonder nobody is asking why MS is doing all this, what’s the business strategy behind all this? Could somebody please enlighten me
“Note: This document was developed prior to the product’s release to manufacturing and, as such, we cannot guarantee that any details included herein will be exactly the same as those found in the shipping product. The information represents the product at the time this document was printed and should be used for planning purposes only. Information subject to change at any time without prior notice.”
Let me know when there’s something concrete.
1) What does this mean for Winamp?
2) Why are the title bars so friggin’ huge? (And further, what does the star-button-thing do? And A home button in an app?–where does it take you?)
3) Are they going to force this onto every app, or will you have the freedom to choose when it’s appropriate to develop such a thing?
… and lastly, I was kind of kidding about that first one.
Victor, I am well aware that XAML is an XML application. I also know that XAML is an offshoot of ideas from XUL. I think now that a big player such as MS is adopting this way of writing programs it gives it more awareness to the public and can help give momentum for adopting standards. This is why we have c/c++ programs that you can run on many platforms, because big companies adopted it and helped get the ball rolling. So basicly by MS using ideas from XUL/Glade then they will get this style of programming out to a much larger audience than what Mozilla can do on their own and ultimately aid widespread adoption.
First you say XAML is great. Then you say XML is not so great. Do you know XAML is just an XML application? There is nothing great about XAML. This is the kind of stuff that annoys me… everybody and their dogs have been doing this before (XUL, Glade), and then MS “invents” this XAML and suddenly everybody is “oooh, aaah, W3C should adopt it! ooooh”
Victor.
1) What does this mean for Winamp?
I think Winamp will always be self-contained and use their own skinning system because I’m sure they eventually want to be cross-platform which I think they tried doing with WA3
2) Why are the title bars so friggin’ huge? (And further, what does the star-button-thing do? And A home button in an app?–where does it take you?)
You have to remember that they are designing this for higher resolution and widescreen displays that they assume will be mainstream in 2006 (I hope!) so things won’t look as large as they do today. And the sidebar won’t be as obtrusive since it will be on the edge of a wide display instead of the current square-like monitors we have today. As for the star-button, it deletes random important system files every time you click it
3) Are they going to force this onto every app, or will you have the freedom to choose when it’s appropriate to develop such a thing?
I saw a video demo of XAML programming and the developer is able to specify what kind of junk they want around their window like titlebar, buttons, etc… you can turn anything on or off.
Many reasons – all of them are “profit”.
I saw a video demo of XAML programming and the developer is able to specify what kind of junk they want around their window like titlebar, buttons, etc… you can turn anything on or off.
I guess my question wasn’t worded so well. I think it’s best put, “Must ALL programs be XAML programs?”
“I guess my question wasn’t worded so well. I think it’s best put, “Must ALL programs be XAML programs?””
XAML is simply another .NET language. It maps to the .NET/Longhorn object model.
Anything you do in XAML can be done in C# or VB.NET, etc. In many cases, it just takes more lines of code to do so.
XAML’s primary use is to seperate UI development from the backend, and provide a language that is easier to use for developing UI.
“Many reasons – all of them are “profit”.”
and how exact does Bill G. want this to work, it appears to me not many people understand what he’s actually planning. I mean it’s obvious, Microsoft want to blur the difference between normal programs and web content and the .NET technologies WinFS and XAML are used to achieve this. It looks they want to sell software as service or something like this in the future