Longhorn, what does everyone think?

[JDeats]

Just spent some time browsing around here:
http://msdn.microsoft.com/Longhorn/

I can see the benefits from WinFS (as long as we tag all in-coming
data this should be nice, tagging everything could be a tedious
process though) but I haven't been able to pick up the practical
advantages of XAML. From my assessment, XAML will provide separation
of UI logic from business rules/procedures for applications. It seems
like an HTML of sorts for desktop application UI. But where are the
big advantages of designing desktop applications this way? It may
provide a nifty way to create UI-"skins" to provide a custom
experience for different users, but that can do as much harm as good,
it's not revolutionary.

I can think of some disadvantages to this approach, namely all the UI
logic has to processed at run-time (interpreted) and a generic
container application has to exist to marshal between the presentation
and the procedure code. Even if this marshall process is part of the
core OS, it still seems like needless overhead without any
clear-advantages.

Also the Longhorn UI guidelines are nothing to wow over, there's a new
side-docking bar that we can use to provide small bits of information
at all times, it's going to get cluttered quickly.

I don't know about most of you, but with all the processing power or
modern PCs I was hoping for something more radical (how about a 3D
User Interface for the OS), am I alone here?

 

[Daniel Pratt]

Hi JDeats,

Just spent some time browsing around here:
http://msdn.microsoft.com/Longhorn/

I can see the benefits from WinFS (as long as we tag all in-coming
data this should be nice, tagging everything could be a tedious
process though) but I haven't been able to pick up the practical
advantages of XAML. From my assessment, XAML will provide separation
of UI logic from business rules/procedures for applications. It seems
like an HTML of sorts for desktop application UI. But where are the
big advantages of designing desktop applications this way? It may
provide a nifty way to create UI-"skins" to provide a custom
experience for different users, but that can do as much harm as good,
it's not revolutionary.

I can think of some disadvantages to this approach, namely all the UI
logic has to processed at run-time (interpreted) and a generic
container application has to exist to marshal between the presentation
and the procedure code. Even if this marshall process is part of the
core OS, it still seems like needless overhead without any
clear-advantages.

I have for a long time now wished to have asp.net-ish features in my
windows app (flow layout, nested elements, cascading stylesheets, UI/logic
seperation, etc.). Until now it hasn't been worth the trade-offs for the
kind of applications I develop. It sounds to me like XAML brings what is
good about ASP.NET development to windows applications without the
trade-offs and that I'm pretty excited about.

I would not assume that XAML applications will be strictly interpreted.
ASP.NET doesn't run interpreted, after all, and XAML applications are able
to be converted into strictly windows apps. Between Windows itself and the
managed runtime, I would doubt that the container process (assuming there is
one) would add any significant overhead to the application.

Also the Longhorn UI guidelines are nothing to wow over, there's a new
side-docking bar that we can use to provide small bits of information
at all times, it's going to get cluttered quickly.

Looking at my icon tray this seems quite possible, yes.

I don't know about most of you, but with all the processing power or
modern PCs I was hoping for something more radical (how about a 3D
User Interface for the OS), am I alone here?

3-D seems like the inevitable direction for interfaces of the future,
but coming up with something that's more than just a gimmick seems like a
sizeable challenge, especially if you expect to make a smooth transition
from the 2-D interface world.

Regards,
Dan

 

[Alvin Bruney]

i'm interested to see if it will catch on, the resistance to change, the
separation into longhorn camps and longhorn biggots. interesting stuff. time
will tell.

 

[Jack Mayhoff [MSFT]]

Ya think Window will catch on? Do ya really?

--

Jack Mayhoff
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Daniel O'Connell]

Just spent some time browsing around here:
http://msdn.microsoft.com/Longhorn/

I can see the benefits from WinFS (as long as we tag all in-coming
data this should be nice, tagging everything could be a tedious
process though) but I haven't been able to pick up the practical
advantages of XAML. From my assessment, XAML will provide separation
of UI logic from business rules/procedures for applications. It seems
like an HTML of sorts for desktop application UI. But where are the
big advantages of designing desktop applications this way? It may
provide a nifty way to create UI-"skins" to provide a custom
experience for different users, but that can do as much harm as good,
it's not revolutionary.

I can think of some disadvantages to this approach, namely all the UI
logic has to processed at run-time (interpreted) and a generic
container application has to exist to marshal between the presentation
and the procedure code. Even if this marshall process is part of the
core OS, it still seems like needless overhead without any
clear-advantages.

Basically, it provides a way to declaritivly design a UI. There is nothing
saying you HAVE to use xaml files to produce UI's, there are classes that
are directly usable, as well as winforms, it however provides alot of nice
features(such as using the WIndows Client Print Driver or things like Adobe
After Effects to produce UI's). xaml in most cases will be compiled into a
standard EXEs(however it can be loaded directly in a browser or a seperate
window, as I understand it.)
From what I read, xaml files are transformed into partial C# or VB.NET
classes, for example, and the associated code behind files provide other
parts of the partial classes, allowing you to seperate UI and code nicely in
some cases, but it still generates an executable class.
I don't consider XAML to be a revolution so much as an evolution of existing
concepts, evolved in such a way that it operates well within Windows. Total
revolution is really rather rare and I don't expect that anything major will
be totally revolutionary about longhorn(or any other major software,
revolution tends to come in little bits, in little projects until its
proven)

I think it might be nice...but until I get to play with it I won't know,
asp.net wasn't my favorite thing. However because XAML isn't required, I
think Avalon is far more important, XAML is just a different way to utilize
it.

Also the Longhorn UI guidelines are nothing to wow over, there's a new
side-docking bar that we can use to provide small bits of information
at all times, it's going to get cluttered quickly.

I don't know about most of you, but with all the processing power or
modern PCs I was hoping for something more radical (how about a 3D
User Interface for the OS), am I alone here?

I tend to shy away from 3d interfaces, I've seen very few that were really
usable. There is a level where you have to consider nice looks and
usability, and 3d interfaces often require to much work to get where your
going, not to mention they are difficult to manipulate with standard PC
HID's.

 

[Christoph Nahr]

From what I read, xaml files are transformed into partial C# or VB.NET
classes, for example, and the associated code behind files provide other
parts of the partial classes, allowing you to seperate UI and code nicely in
some cases, but it still generates an executable class.

As I understood the Petzold example, I don't think I'd put _any_ code
in XAML files. Sure, you can (in CDATA blocks), but that looks rather
clumsy and it's apparently unnecessary.

I think the most useful aspect about XAML is that you can use it as a
glorified resource script format that defines a UI's visual appearance
plus the event handlers to which all UI elements are mapped, but the
actual event code would be written in a normal separate C# file.

 

[Daniel O'Connell]

As I understood the Petzold example, I don't think I'd put _any_ code
in XAML files. Sure, you can (in CDATA blocks), but that looks rather
clumsy and it's apparently unnecessary.

I think the most useful aspect about XAML is that you can use it as a
glorified resource script format that defines a UI's visual appearance
plus the event handlers to which all UI elements are mapped, but the
actual event code would be written in a normal separate C# file.

I probably wouldn't write inline code either(although they do make it clear
you could), however from what I read, I think the build would go something
like this:
Form.xaml -> partial class Form; containing code generated from Form.xaml,
including inline code
Form.xaml.cs -> partial class Form; containing code-beside\behind code in a
model similar to asp.net.
resulting in a form class object when compiled which is mostly what I
meant.(Unfortunatly I can't find the page I was reading that on...there is
really alot more up on that longhorn sdk site than it seems at first
glance).

However, for writing quick 'n dirty applications, note organizers or other
apps that may only consist of a UI and maybe 50 lines of code, inline coding
is potentially nice, no reason to launch VS, handle multiple files and a
build setup for that, when you can just write out a XAML file with some
quick C# in it.

Personally I'm not sure if I'd even be motivated to use XAML directly often,
I would most likely just use it inderictly via the designer or other tools.
If I'm designing a UI by hand, I like to do it in code...quirk from my
pre-designer days I guess, . It will remain to be seen what I think of it
once I get my hands on it, I'm not a fan of HTML and don't expect this to be
much better...but they may surprise me.

 

[JDeats]

3-D seems like the inevitable direction for interfaces of the future,

but coming up with something that's more than just a gimmick seems like a
sizeable challenge, especially if you expect to make a smooth transition
from the 2-D interface world.

Regards,
Dan

I expect whatever the next big leap is, it will start out as an
application that runs on top of the existing OS (just as Windows
started out as an application on top of DOS). With $6.5 million a year
spent on pure R&D, I'm just surprised Microsoft hasn't come up with
somethine more innovative. For people who don't play games on their
PC's I'd say about 80% of their video hardware's potential is left
completely untapped. How much power does it take to display a 2D
display at 1024x768 or even 1280x1024? in true color, you're average
16-bit video card with 16-MEG of RAM does the trick. But just about
every video card (even the motherboard basec chipsets) have 3D
capabilities, and most cards come with at least 32-MEG of RAM.

 

[Alvin Bruney]

Yay, more Z order Just what we need! Lets not simplify, lets complify!

 

[Alvin Bruney]

Ignore this idiot. He is spoofing my email account

 

[HD]

Tried the first two alpha leaks of longhorn.
Really curious as to how its gonna turn out at the end. Partial
implementation of CLR over win32 making win32 extinct should be fun (even
though i used be a C++ ATL Person) Also excited bout the ultimate database
being handled by next gen Yukon implementation. Something radically
different from tried and trusted ways. But considering the microsoft is
getting towards how we remember happening and instances guess multiple
attribute based indexing of file is a good approach. Will be getting the
official PDC release in a few days time and my laptop's to be dumped all
over again.

 

[Daniel O'Connell]

I did read on one of the winfx newsgroups that there will be somethign to do
with 3D UI's, but it was not delievered in the PDC build(and possibly not
available even in the preview build). If 3d is used, I would expect it would
be used mostly to use the hardware in full instead of provinding a radically
different interface(I don't think that hardware is up to the challange of a
3D interface. We need better mice, monitors, plus I don't want to be running
around my computer, like most 3d interfacesw have been so far, .

 

[Alvin Bruney]

If you haven't seen the power of longhorn in the flesh, check out this
video. It is absolutely amazing what this thing will do
http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031028LHORNDB/manifest.xml

amazing

 

[Daniel O'Connell]

If you haven't seen the power of longhorn in the flesh, check out this
video. It is absolutely amazing what this thing will do

http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031028LHORNDB/manifest.xml
Unfortunatly the PDC was definatly out for me, havn't really watched any
videos(however I've seen some old screenshots and such from other things), I
will take a gander at it shortly.

Thanks

 

[ozbear]

http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031028LHORNDB/manifest.xml
Unfortunatly the PDC was definatly out for me, havn't really watched any
videos(however I've seen some old screenshots and such from other things), I
will take a gander at it shortly.

I'm not sure I'd bother....I watched the first 5 minutes or so...lots
of time spent looking at a crooked camera view of a monitor while
some guy slooooowly type in stuff...I began to think the site had
been hijacked to some joke website.

Maybe it gets better later on.

Oz

 

[JamesMason]

Well, without spending much thought on it I can imagine a 3D version
of the existing Windows UI. For example, imagine if you could click on
the lower left corner of any desktop window and a little rotation icon
appears, then you could move your mouse over it and rotate the window
so that the right side of the screen appears to move back (in 3D
space) the left side of the window would also rotate to display a thin
bar that displays the windows title bar text (the effect would be just
as if you were holding a book looking at it's face and then you turn
it to look at it's spine).

Then the user could maybe pull up a virtual book shelf on the desktop
and place the window in it. This virtual book shelf could hold
hundreds of windows apps like this, it could auto alphabetize, our
even provide grouping options.


Would a feature like this provide any functional advantage, probably
very little, but it would enhance the user experience. It would also
give existing Windows customers another reason to upgrade. You have to
consider that the average user will largely base their judgement of an
OS by it's cosmetic features and usability. As long as the team is
careful not to lose any usability, the fluff should be pilled on thick
in every release just to make the new OS a more attractive product for
the home user.

I disagree with the original post a radical change would be a poor
move because people need to be allowed to gradually adopt features.
Also if this new 3D environment ran on top of Windows, that wouldn't
be very practicle. It wasn't untill Windows 95 that Windows really
took off, Windows 3.x was a failure because applications that run
under it were much slower than their DOS counterparts. If a new 3D
environment is to be introduced I see its first incarnation as 3D
version of the existing UI (as stated) and I see it as an optional
feature that can be disabled. As with any technology it will have to
evolve.

 

[JDeats]

Okay, I watched the video. The demonstration of XAML (oddly pronounced
zam-el) was kind of neat, but "amazing", nope. So you play a video in
the background of you form, so all the controls on the form are now
vector based (humm wonder where Microsoft got that idea..), it's cool,
but it's not mind blowing amazing. Couldn't these type of features
just as easily have been part of the new .NET Framework? Why do they
require OS release to be possible.

The Indigo demo was boring and uninspiring. What's special about that,
I could create a generic messaging class in C# in a days worth of work
or less and accomplish the same type of thing, again why is this a
core OS feature? It seems like it should just be part of the next
incarnation of the .NET Framework.

WinFS is by far the coolest thing about Longhorn, but I still have a
lot of unanswered questions. For example, let's say running on
Longhorn I have an MSAccess database file, an Excel file and an XML
file, all in different folders. If WinFS archives all files inside a
SQL Server style dbase how much power will it give me in querys?

Say the MSAccess file has a table called "Users" that has ID and Name
columns, the Excel spreadsheet has an ID and Name column and the XML
file has a similar structure with ID and Name nodes. Would it be
possible to perform a SQL JOIN on all three files based on ID and get
back a result set? When I think of everything in the file system as a
database object, that's the kind of power I'd be expecting.

What's more likely is that each file is tagged with metadata and it's
metadata is what gets indexed and is available for Query (all the
examples I've seen thus far show this). That's really not all that
impressive.

 

[Daniel O'Connell]

Okay, I watched the video. The demonstration of XAML (oddly pronounced
zam-el) was kind of neat, but "amazing", nope. So you play a video in
the background of you form, so all the controls on the form are now
vector based (humm wonder where Microsoft got that idea..), it's cool,
but it's not mind blowing amazing. Couldn't these type of features
just as easily have been part of the new .NET Framework? Why do they
require OS release to be possible.

No, not in any serious way. A new rendering engine is an OS feature, not a
framework feature. Just because its written for .NET doesn't mean its part
of the framework.

The Indigo demo was boring and uninspiring. What's special about that,
I could create a generic messaging class in C# in a days worth of work
or less and accomplish the same type of thing, again why is this a
core OS feature? It seems like it should just be part of the next
incarnation of the .NET Framework.

Could you design one that supports SOAP, SOAP1.2, Xml Serialization and all
the other bits that can travel over any communication mechanism in as many
days?
As for why its an OS component...that I can't say, except perhaps because ti
was written for Longhorn and is used in Longhorn.

WinFS is by far the coolest thing about Longhorn, but I still have a
lot of unanswered questions. For example, let's say running on
Longhorn I have an MSAccess database file, an Excel file and an XML
file, all in different folders. If WinFS archives all files inside a
SQL Server style dbase how much power will it give me in querys?

Say the MSAccess file has a table called "Users" that has ID and Name
columns, the Excel spreadsheet has an ID and Name column and the XML
file has a similar structure with ID and Name nodes. Would it be
possible to perform a SQL JOIN on all three files based on ID and get
back a result set? When I think of everything in the file system as a
database object, that's the kind of power I'd be expecting.

I don't know for sure if this is possible and I don't know if there really
is any point to that, in 98% of usage cases this would be extra code for no
use, and I bet you probably wouldn't even use it yourself. That is what a
database is for and you could do it via ADO.NET easily(WinFS can be accessed
via ADO.NET). However, it has alot to do with the objects and schemas
designed into WinFS, there is NO way the system could understand every
possible file placed on it, and I suspect it would be more a matter of how
the schema works internally than WinFS itself.

 

[Daniel O'Connell]

Actually, I just read a post on the windows.winfx newsgroups that points to
an article about its release:
http://msdn.microsoft.com/longhorn/...ull=/library/en-us/dnlong/html/indigofaq1.asp
<quote>
Indigo is part of Windows Longhorn and is available to every Longhorn
application. Indigo will also be available as a separate download for
Windows XP and Windows Server 2003.
</quote>

So it seems it will be something like the WSE implementations, addons to the
framework.

 

[Alvin Bruney]

So you play a video in

the background of you form, so all the controls on the form are now
vector based (humm wonder where Microsoft got that idea..), it's cool,
but it's not mind blowing amazing. Couldn't

Think about it. Can you do that today how it was demo'd? Transparently?
Freely mixing form elements? Think about doing it today and how much effort
it would take. Now think about whipping it up in a couple seconds with a
couple lines of code.

If that doesn't amaze you, nothing will.