Ryan Dawson on Longhorn

The software we think, but do not write

October 2004 - Posts

  • Visionaries, Back to the Drawing Board

    Posted by rdawson to Ryan Dawson on Longhorn on Oct 25 2004, 11:28 AM
    Filed under:

     

    Many visionaries predict that the next Windows will be built through the web browser.  They believe that Google will host these largely distributed applications, and Windows will come crashing down.  This is only slightly after the fact that they had a hard enough time selling consumers on the idea of open source.  I guess they didn’t think roach motels were that hard to break.  The plan seems great, it seems futuristic.  I go to any computer and log in to find that all of my applications and data are there to use at a whim.  Sounds terrific!  I mean, look at all of the visionaries who are predicting it.

     

    Well, on second thought, many of the visionaries have a significant stake in making it succeed.  That is their only way to tap the money they so dearly want.  So, in a sense, these guys just don’t see it as the future, they see it as the only future in which they survive.  Are they visionaries or businessmen?  Look, let’s be honest, everyone wants a slice of the pie; I’ll give them that much, at least.

     

    They just forgot one thing…On small thing…

     

    Computers have continually advanced throughout time.  And, it is through this progression that people become dependent on the infrastructure and presentation to which they have become accustomed.  They will only upgrade if the next big thing sits on the shoulders of the past.  Imagine that I came out with a killer word processor with AI (Artificial Intelligence) and the likes, but it ran on a character-based input.  I wouldn’t sell one copy.  This is a drastic example, but it proves that I must use a GUI (Graphical User Interface) in order to take the next leap and add AI to my word processor.  It is a requirement, not a suggestion.

     

    Now, fast forward till today.  On one hand, there are these games that keep coming out that have killer graphics (absolutely spectacular), and on the other we have the static web, with a few hints of dynamism.  On the one hand, we have these people getting used to playing these games with rich interaction, on the other we have a system where information is seamlessly connected to everyone.

     

    Now, do you seriously expect people to drop the games?  Or do you expect them to drop the interconnectedness?  I suspect neither.

     

    People want stunning applications with magnificent graphics, extravagant interaction, and incredible connectedness. 

     

    So, please tell me, visionaries, how in the world do you plan for me to turn my back on the graphics and responsiveness that I have become accustomed to?  I think you can’t ask the question, it’s ridiculous.  I may be biased towards rich graphics since this article comes to you from a source who is a major proponent of the Avalon graphics system for Windows.  But, it’s not just me.  Everyone loves rich graphics.  That’s why those computer animated films are becoming so popular.  Pixar and Dreamworks are making great products, and people love them (if you don’t believe, check how much money they have made).  People love TV.  That is almost too evident.

     

    Software is at an age in which graphics and UI (User Interface) really matter.  If you don’t have a great experience, your customers won’t use your product.  Point.  And, that is only the tip of the iceberg.  I think modern UI’s are antiquated.  Microsoft Office is great, but I feel a revolution is upon us.  Transparencies, rounded edges, gradients, and animation are a few of the concepts that are around the corner.  Stunning interaction in which things are moving with crisp refresh and making me enjoy the product, connect with it.

     

    How does a designer make a user connect with their product?  They make their product evoke emotions in the user.  So, that they have a bond.  When the next version comes out, they are hesitant to upgrade, no because it is not a better product, but because the user and the product are bonded.  They share feelings together.  I have digressed, but this is the next step in software.

     

    Now, onto the web.  The web is also antiquated, at least for the sake of the users.  Like it or not, Microsoft has brought the computer industry so far in the simple fact that there was only one platform.  I don’t care if you don’t like it, but we, as a society, were not to the point where our software from different platforms could integrate seamlessly.  I just can’t begin to say how much that one monopolistic operating system has done for us, for the sake of users.  For the sake of my grandma.

     

    But, the web is only what its name implies – a communication network.  HTML over HTTP is just one aspect.  Why does the web have to be so apparent?  When I want to check stock prices: I care nothing about web browsers.  I care nothing about web sites and domain names.  I care nothing about navigation and advertisements.  I care about the stock prices and that is it.

     

    We are on the verge of abstracting the web.  Why?  Because my grandma doesn’t care about the web.  She cares for ideas and information, and the web is just a confusion point.  She cares for rich graphics and interaction.

     

    There is no reason why I should beat the idea with a stick, but you see where I am going.  You may ask how I am so sure this is where things are going.  The answer is because I am working on a product weeks away from shipping that encompasses all ideas that I have talked about, and users love it.  If that isn’t evidence enough, then I don’t know what is.

     

     

    PostTypeIcon
    4,311 Views

  • Flex has potential

    Posted by rdawson to Ryan Dawson on Longhorn on Oct 11 2004, 04:34 PM
    Filed under:

     

    Over the weekend I decided to play around with Macromedia Flex.  This stuff is really cool…really!  I swear if they had a full code backing – like .NET, and all of the UI was handled by their goop, they would have a killer app.  I was doing some serious thinking and I don’t think it would be that hard – just sort of mask all the Flex controls with .NET controls, and then interop out (or however) to the Flex UI layer.  If Flex (Flash) is coded well enough, it should be a walk in the park with the declarative markup already written, everything is probably abstracted well enough.

     

    Did you hear that Chris Coenraets or Matt Chotin…put some serious ability (code, real code) behind your graphics and you could put Avalon on XP to bed.  Think about it: the Flash graphics platform has already shipped (long ago), and the redist is small.

     

    Flash is just so much more appealing than WinForms.

     

    PostTypeIcon
    7,596 Views

  • Indigo Untyped Channel

    Posted by rdawson to Ryan Dawson on Longhorn on Oct 09 2004, 01:48 AM
    Filed under:

     

    [Primer] There are two types of channels in the colorful world of Indigo: typed and untyped.  A typed channel is the way by which you program against the service WSDL, typically through an auto-generated interface.  Obviously, as the name implies, you must conform to a contract.  On the other hand, there is the notion of an untyped channel, in which you basically pass Messages (the basic unit in Indigo) from Port (the basic endpoint) to Port.  No contract is required, and processing usually happens based on the action URI.

     

    The most basic untyped channel example.

     

    using System;

    using System.MessageBus;

     

    The client:

     

          class Client

          {

                [STAThread]

                static void Main(string[] args)

                {

    Uri client = new Uri(String.Format("soap.tcp://{0}:6000/Client", System.Environment.MachineName));

    Uri server = new Uri(String.Format("soap.tcp://{0}:6001/Server", System.Environment.MachineName));

     

                      Console.WriteLine("Client - {0}", client.ToString());

     

                      Uri action = new Uri("http://tempuri.org/action1");

                      Message message = new Message(action, "Hello");

     

                      message.Headers.Add(new PathHeader(server));

                      message.Headers.Add(new ToHeader(server));

                      message.Headers.Add(new ReplyInfoHeader(client));

     

                      Port port = new Port(client);

     

                      port.Open();

                      port.SendChannel.Send(message);

                      port.Close();

                }

          }

     

     

    The Server:

     

          class Server

          {

                [STAThread]

                static void Main(string[] args)

                {

    Uri server = new Uri(String.Format("soap.tcp://{0}:6001/Server", System.Environment.MachineName));

     

                      Port port = new Port(server);

                      ServerMessageHandler handler = new ServerMessageHandler();

                      port.ReceiveChannel.Handler = handler;

                      port.CloseTimeout = new TimeSpan(1, 0, 0, 0);

     

                      port.Open();

                      Console.WriteLine("Server - {0}", server.ToString());

                      Console.ReadLine();

                }

          }

     

          public class ServerMessageHandler : SyncMessageHandler

          {

                public override bool ProcessMessage(Message message)

                {

    string content = message.Content.GetObject(typeof(string)) as string;

     

                      Console.WriteLine(content);

                      Console.ReadLine();

     

                      return true;     

                }

          }

     

    Excuse some of the server logic, such as multiple Console.ReadLine()s and no port.Close().  I had some trouble figuring out the threading issues with Indigo and a console application. 

     

    I just love the fact that there is essentially one channel that everything flows through.  Although there is the notion of typed channels, they are resolved into Messages at the most basic level, and so they are pretty much untyped channels with the semantics.  What a difference a clean architecture makes…

     

    PostTypeIcon
    1,840 Views

  • The Smallest MSBuild Project

    Posted by rdawson to Ryan Dawson on Longhorn on Oct 09 2004, 01:32 AM
    Filed under:

     

    The smallest MSBuild project, considering of course, the included assembly could be excluded:

     

    <Project>

    <Item Type="Reference" Include="$(lapi)\Microsoft.NET\Framework\v2.0.31113\System.MessageBus" Name="System.MessageBus" />

         

    <Item Type="Compile" Include="Client.cs" />

         

    <Target Name="Build">

    <Task Name="CSC" Sources="@(Compile)" OutputAssembly="client.exe" TargetType="exe" />

          </Target>

    </Project>

     

    There are variations of a simple project (.proj) definition floating around, although I believe simplicity should be maintained at all costs.  For example, I don’t like the ability to be able to create the same thing two different ways.  I would say it follows the law of squares, in that it is x^2 times harder to learn something in programming when variations exist that do the exact same thing.

     

    PostTypeIcon
    3,177 Views

  • Avalon 3D Must-Haves

    Posted by rdawson to Ryan Dawson on Longhorn on Oct 05 2004, 06:54 PM
    Filed under:

     

    Speaking of features that can wait…Take a look at the 3D stack.  I am positive that things have improved since WinHEC.  But, I was recently working with 3D samples on an extremely good machine and the performance was ridiculous.  I mean terrible as in I wanted to throw the machine out the window.  I always knew it was bad, but now I don’t know how much of a priority it should be.  I thought the Avalon 3D stack was only a wrapper around MDX9, did I miss something?  Obviously it has an intermixed relationship with Avalon, but can it really be that bad.

     

    Here is what a 3D Avalon developer wants:

     

    1. I want the ability to seamlessly add a 2D surface with Avalon controls to a 3D mesh; if that isn’t solid then you guys need to get out now.  I didn’t even say there had to be animation.  All I want is a ListBox, or something, angled on the screen.  Furthermore, if the performance is crappy, to only angle a ListBox, then get out.  No, I’m serious.
    2. I want the ability to create 3D charts and what not.  Again, animation does not need to be included.  So, this is more of a programmability thing.  But, it needs to be solid.  The semantics of creating a chart should be my concern, not the 3D aspect.
    3. Now, onto the animation.  This stuff is cool, but it definitely needs to come second, and it definitely needs to perform, or it’s a waste of time.  People want to take a control and do some rotations, flips, and translations.  They want to do this on a form load and unload.  How they can do this is beside me.  I am not sure if every control will have to be placed on a different 3D surface and then animated.  However, I don’t know if this will work since the controls are going to be on a FlowPanel, and that means they would have to Remove them and then Add them to the 3D surface.  Since I am not involved in the implementation, I don’t really care; I just know it needs to happen.
    4. Personally, I could care less about little animations that I feel are going to replace the File Copy dialog in the Windows Shell.  From a realistic stand point, I don’t have any screen real-estate to put dumb little animations like that.  So, I don’t think they should be a priority.

     

     

    All in all, I think those are the things that need to be hit.  A tight integration between Avalon 2D and 3D needs to happen, or the whole thing is going to be a dud, trust me.

     

    PostTypeIcon
    5,315 Views

  • Avalon Knock-Offs Don't Make the Cut

    Posted by rdawson to Ryan Dawson on Longhorn on Oct 04 2004, 03:34 PM
    Filed under:

    Lately I have been testing the Avalon knock-offs, VG.Net and Xamlon, to name the ones I am aware of.

     

    I would have to say that I am pretty impressed by what both companies have done.  They are both in release about a year after the initial PDC that started it all, and they both seem to be healthy.

     

    Xamlon is going more for the ultimate compatibility road to Avalon, while VG.NET is more about having the best platform while borrowing ideas from Avalon and XAML.

     

    To both companies, I like what you are doing, but I think you both miss the boat; here is what people want:

     

    1. People aren’t going to switch to Avalon for XAML.  Not a chance.  It just happens to be a neat serialization format that is easy-to-use for designers (the software type).  Also, it can double as a text-based programming language (like HTML) which means it simplifies development for trivial tasks.  On the other hand, you guys have put so much time and effort into having compatibility and what not with Avalon, and I think it’s a waste of time.  It reminds me of a post by Rory where he explains how everyone on SourceForge spends so much time setting up the license type and administrative details, but they never get around to actually writing a product.
    2. Vector graphics are cool and everything…but, not by themselves.  Vectors are great because they have scalability.  Although, it only works if you can get everything vector-ized.  A vector graphic sitting in the background of my application is never something that I have wanted.  Granted that bitmaps don’t scale, I am happy using them for background transparent images, and they work great.  So, bringing the ability to put a vector image in my application is nonsense.  What I want are controls that are completely vector-ized, period.
    3. One of the biggest keys to productivity that the .Net Framework does not currently (<= 1.1) have is a state of the art layout engine.  This is by far one of the biggest keys to development of a UI.  The amount of dumb code that I used to write for resizing and layout was huge.  It reminds me of type mapping for databases to CLR types.  Both are dumb code and very error prone.  I didn’t see a layout engine in either of these products.  I may have just not noticed it, but that is a huge mistake on both parts.  Huge.
    4. I want a custom TextBox.  That is all.  When I get that, I will go back to my corner and never say another thing again.  The same applies to all controls, but the TextBox is the worst since it is drawn by Windows.  Back to the vector point; people don’t want vector graphics, they want controls -those are what compose applications, not stupid pictures.  On the simple side, I just want controls with borders that are anything but square (and no, simply setting the Region property is not good enough, it’s too rough).  Rounded is in.  Just like any designer will tell you - ebony is the new black.  Round is the new square.
    5. Both companies went after animation (Xamlon for 3D, VG.Net for 2D – more like Avalon).  Animation is great, although, again, animation of stupid little pictures is the biggest feature that people will not put into their programs.  People want menus that use cool animation (gravity) - or any feature that opens and closes; or the way controls populate and de-populate a form – like expose for Mac.  Simple animations will not cut it unless you have a full support through the platform.

     

     

    I don’t want to sound like a jerk…but, they both should have just teamed up and wrote a new composition engine where they could get everything right.  I mean, it’s a hard problem without solving some platform issues.

     

    I only mentioned things that I know are possible using GDI+ and .NET.  These don’t include things that Avalon (itself) is going to have a hard time with on XP.

     

    If I have anything wrong, please correct me!

    PostTypeIcon
    4,637 Views

  • Avalon Stack Levels

    Posted by rdawson to Ryan Dawson on Longhorn on Oct 02 2004, 01:57 PM
    Filed under:

    I know this is sort of old, but I was digging through the Avalon stack today and I didn’t think this statement by Miguel de Icaza was correct.

     

    For anyone who didn’t read it, here is a summarization:

    • The Avalon API is too complex because it exposes too many hierarchical levels in the stack
    • They are over-designing, which will set them up for failure
    • Worry about extensibility later

     

    A view of a TextBox and base classes in Avalon:

     

     

    I don’t think his statements are fair because he is recommending that you should throw good object oriented design out the window in favor of sheltering the developer.  In any other context, I think he is right, favor simplicity.  But, in this case, Avalon goes out of its way to extend controls.  For example, all of the styling mechanisms can be built right on top of a control without even sub-classing.

     

    I know that adding code to Avalon in the future will be much easier than if a WinForms-ish design existed.  Now, if there are any changes that need to be made, a dev can go to that exact level, which will then have an appropriate semantic set associated with it, and things will be much simpler.

     

    Also, every developer who comes over to Avalon will probably come from a WinForms background, and in WinForms, Control is the basic unit that a person used to create a custom control (or in other terms, it is basically the lowest level).  Now, look at Avalon, Control is the immediate base class of TextBox  (UPDATE: DesignSurface is now between Control and TextBox.  DesignSurface is the semantics associated with moving, resizing, and rotating an element.  I was initially looking at the PDC build, but this is the WinHEC build.  This sort of makes sense, it makes it so auto-layout is an opt-in thing only.  Basically, it cuts down on details for controls that do not want auto-layout.).  That means that a dev should stay above that level, which they will do, and they will never worry about anything below it.

     

    Now, imagine that you have some terrifically unique problem in which you need to change some base level behavior details –well, you then go below Control, but in that case, you probably know what you are doing.  I expect the number of people who will go below that line is .1% of all developers.

     

    PostTypeIcon
    2,449 Views