Ryan Dawson on Longhorn

The software we think, but do not write

November 2003 - Posts

  • Designing the World

    Filed under:

     

    From Rob Relyea’s post, I think there are some things that need to be addressed (http://longhornblogs.com/rrelyea/posts/1336.aspx).  I feel strongly that XAML is for the designer only (the loaded word designer applies in this case to a person designer and the tool in VS).  I may be wrong, as time will prove, but that is how I feel.  The biggest part that I think is missing is a way to tie the programmer and the designer together, a sort of contract.  O wait, we already have a technology that helps us enforce that – XML Schema (http://www.w3.org/XML/Schema).  Albeit they both have to work together, the programmer is like the car engineer, he makes sure the car is functional.  On the other hand, a big part of selling cars means that you have to make your model look sporty, luxurious, and stylish. So the designer plays a VERY important role in designing the car, because their decisions lead to what becomes a trend, and later profit.  You can copy the engineering work of a car from one maker to the other, but the looks are what differ the most.  To say the least, don’t get me wrong, the designer has very strict guidelines they must follow.  For example, the designer cannot remove a wheel because they think it will make it look better. The first rule they must follow is to not break the functionality.  Without a wheel, they have violated rule number one.  Unlike the car makers, I think we are in the perfect position to enforce such rules.  If the programmer, who is ultimately responsible for the functionality says that we need a text box, then we need a text box.  The designer should not have the ability to delete the textbox.  At the end, when they check in their work, the Source safe should run it against the schema and only accept it if it meets the requirements.  I say text box, but underneath this means a string.  So you can imagine a text box, rich text box, combo box, and possibly a multitude of others that will be valid against the schema.  Part of being a designer is breaking from the norm and creating something unheard of.  So we must not stifle creativity, but more or less, check to make sure they are working within boundaries.  In the end, I think all XAML will be created by the designer only (unless that is also your programmer).  This is a bad example, but there is not one graphics designer that I know who modifies a picture on the bit level.  They use Adobe tools to apply transforms.  They use their mouse to drag shapes and lines around.  They use properties to select things like color and opacity.  Like I said, this is a bad example, but it can be likened to XAML.  Now, this premise resides on the fact that the tools exist.  If you cannot get the perfect effect you are trying to create, then the tools are not good enough, and at the same time, this gives you a reason to venture into the XML territory.  But, then again, you are mixing design behavior with imperfect modeling tools (XML).  A lot of designers that I know still work with paper and pen, because they are free to model everything with the strokes of their hand.  If you asked them to venture to the next level and modify the vectors they have created with math, they would look at you funny.  This is like asking them to modify the XML in XAML.  Working so closely with designers on your team means that we have to change the way we look at things, which also mean we need to support the tools to enable this.  I imagine a whole generation of tools for creating XAML, maybe even another company the size of Adobe to support this.  I can imagine the tablet having deep impact here.  None the less, mixing the two should be a no-no; designers and programmers have a common goal, but the way they get there should not be the same.  To this end, we need a way to bind the XAML to a schema.

     

    If you don’t believe me that UIs are going to turn into pieces of art, then I wait for the day when I can email you up, and say “ha, I told you so.”  Now a day, to get a stunning effect, we mix graphics from the designer with our graphics code (only the basics, gradients at the most).  With XAML, the whole UI will be a picture.  A textbox can be modeled as a mountain with snow, if someone so wishes.  Wait, I have not even ventured into the animation world!  Stay tuned, there are interesting things on the horizon.

    PostTypeIcon
    2,709 Views
  • On the Road to Longhorn

    Filed under:

    Like my first post on LonghornBlogs, I would now like to post my first one from Longhorn!

     

    I have installed it on one of my desktops, and I am still contemplating whether I want to use the other partition I made for WinXP.  Longhorn is just so appealing that it is a hard choice.  However, I am having a better experience than some, since this machine is a dual proc.  Another side note, you need more than 512MB of RAM.  There is no question.  Although, the paging system does a good job, you still need more, and since we usually follow 2^n, I would recommend 1GB, as does Microsoft.

     

    Following are some notes that I have compiled.  I am not sure if these issues are being addressed, but this should help if they are not:

     

    1) Sidebar

    a) Slide Show

    I need some options.  For one, I need to be able to select the directory where I want my pictures shown from, err in longhorn terms, let me define a filter.  Secondly, how about some timer settings between pictures.  More so, every time the picture changes, my CPU usage jumps around 20-25%, which does not seem likely.

    b) Clock

    I need to be able to change the time and date from the tile instead of going to the control panel.  The reason is because most people are used to right clicking the time in the tray, and so I tried to do the same with the clock, but it doesn't work.

    c) Positioning

    I have a dual monitor system and I want to have Sidebar on the secondary one.

     

    2) Search

    Search is still too slow.  It is still faster to open the browser, navigate to google, type in my query and then search.  Secondly, it sucks at finding things.  I search for a number of things using the "Help and Tasks" filter, and I rarely get any results.  For example, type in "time" and let it search.  Are you kidding me?

     

    I need to be able to search everything.  Right now, you have to search within a filter (Contacts, Email, etc...).  The reason is because things may span multiple criteria, and I don't want to have to go through relationships to see it.

     

     

    3) Explorer

    Well, what can I say, we all know of these problems.  Currently, explorer.exe is using 294MB of RAM.  I think a new Start Menu paradigm might be worth while.  The reason is because I like to have all of the 'Places' folders on the right (Documents, Recent Items, Videos, Pictures, Music...), I mean all of them.  This means that it makes the Start Menu really tall, and leaves a lot of white space on the left side since I only have 5 programs that show up.  I have not thought of a way to fix the Start Menu problem, all I know is that one exists.  Maybe, some people can throw comments up that have good ideas.

     

    I have a lot of MP3s (a lot), and explorer doesn't support the list view style anymore (that I know of), which means that explorer puts a little icon next to all of the MP3s of some random album cover that it generated from 1 of the songs.  Again, filtering comes in handy, but some times I like to see all of my songs.

     

    When dealing with pictures: I try to select the ones that I want using Ctrl + Mouse Click, but it is painstakingly slow.

     

    The found new hardware pop-up definitely has a bug, as it will continually keep popping-up until you restart.

     

    I am not sure how you configure the toolbars that show on the task bar, but I like the Windows Media one, and I cannot figure out how to enable it.  In previous versions, a toolbar menu was on the task bar context menu.

     

    The download manager does not remember my setting of "Close when download completes" and even when checked, it never closes.

     

    4) WinFS

    Again, we all know it is slow.  Another point of interest is the WinFS.exe 60MB footprint.  I am not sure if this is standard.  All in all, I am happy for this build.  However, I am not sure how successful WinFS is going to be right away, because it is designed to work with relationships and the like, but if no such thing exists on a document, then how can WinFS serve the user best.

     

    The same applies for filtering by Meta data.  If the Meta data does not exist, I am not going to take the time to fill in the values.  We need ways to tag the data without user interaction.  For example, at the PDC, Steve Swartz was telling me how future cameras would have built in GPS units to tag the location element of the picture.  This is good, but I don't foresee this anytime soon.  The same goes for all types of data.  How does Microsoft plan for an engine built on Meta data to work without a fair amount of work on the user’s part?

     

     

    The great, things that I really like that have not been mentioned, besides the OS in general:

     

    On the new hardware found pop-up, you can actually define rules, or you can simply say "don't show this to me again."  Rules are great, they work well in Outlook and I am glad to see them in the OS.  The same goes for file copy dialogs, now you can click a check mark that says "Remember this setting" or something. 

     

    User settings are much richer.  More things are customized per user than ever.  But on the same token, this has to do with superfetch.

    PostTypeIcon
    2,593 Views
  • Superfetch

    Filed under:

    Everybody has heard of the word in the PDC keynote.  There are ideas that are going around, but no one really has a strong grasp.  I Googled it and only found the word as used in keynote summaries.  That is not much help for a word used in front of 8,500 inquisitive developers.  Here is a little more:

     

    Superfetch is a word used to describe common pre-fetching technologies.  Who is to know if that will be the marketable word.  Pre-fetching was added to the XP kernel for memory management.  Here is a paper from MSR about general purpose pre-fetching.  Anyway, since WinFS has come around, it is critical to getting things to where they are going more quickly.  Definitely, this is one of the smart approaches to curing some perf problems in WinFS.

     

    Basically, superfetch takes note of commonly used items, such as applications and user settings.  Then, when you come to the screen with all the users and click your identity to log on, Windows takes the chunk of superfetch data and puts it in memory.  So this obviously means that it is personalized for each user of the system.  The interesting part is that you can store all the data together in a chunk and then just throw it into memory and it is ready.

     

    The more I look around and find good applications, the more I notice that they all use caching.  We may have all known this, but it looks like that is the future for good responsive apps.  However, this could be a problem since many people never mastered the threadpool.  So, lets all get started on it!

     

    On the bad side, everyone should know that superfetch technology is not in the current longhorn build.  I can imagine it takes a lot of tweaking and it is probably a problem in and of itself to get it into the operating system.  On the topside, superfetch seems like the intuitive way to do things.

     

    I would like to hear more about the indexing for WinFS.  Can anyone add some value there?

    PostTypeIcon
    6,420 Views
  • A Wonderful World

    Filed under:

    Having had a chance to settle down and peer into the Longhorn SDK, I can tell you it is going to be a fun ride.  I mean, I knew there were going to be cool technologies, but not to this magnitude.  Take a look for yourself, if you already haven’t: http://longhorn.msdn.microsoft.com, the samples section is my current favorite.

     

    Today, in .NET, when I want to do something, I usually fire up the scope operator “.” And Intellisense shoots back a bunch of namespaces/classes.  Having said that, now imagine this same principal on the operating system holistically, Longhorn style.  I have yet to get a desktop ready to go on the Longhorn build, but I am carefully planning the migration, and with that comes the joy of being able to think of new applications.

     

    Longhorn is so huge, and it has so many services to offer.  Before, it was such a chore to even include one of the services that will now be native.  For example, think back to the Speech API days, or even DirectX.  You pretty much had to choose what you wanted your application to be centered around, and then include those COM components, which was hard enough considering Microsoft packaged it for you.  Now, pick and choose as you may.  It is all there for the taking and it is as easy as using the scope operator.  Not to mention, managed code provides benefits such as security that would otherwise be hard to put into the operating system without cutting off legacy apps (Win32).

     

    Right now, I can tell you that one of my new favorite namespaces is going to be System.NaturalLanguageServices.  To add spelling and grammar to everyday textboxes is amazing!  Not to mention, extremely useful.  Check out the SpellIt sample.  I also like System.Net.PeerToPeer and System.Location.  I recently asked someone the significance of Location based services, and they put it so well that I will quote “Think about a simple task of going to the grocery store.  Today, we put it on our Task List of our Pocket PC device.  To think about it, that of itself is not very helpful.  On the other hand, think if the device could know you are passing the grocery store and then give you an alert.  That is what location services are all about.”

     

    The most dramatic change is going to be the disconnection of the graphical design process from the implementation.  Today they are so interwoven that I cannot call a difference, because there isn’t one except for the idea that “I am now coding the UI,” or “I am now coding the business logic.”  Sure, you could use designers, but for the applications that I build, I am far faster with the code, and secondly, the syntax is precisely how I like it.  On the other hand, VS has a “Format the whole document” button for XML-ish languages which destroys the latter argument.  Currently, in XAML, I have been playing around with Animations and colors.  To be exact, I have actually just been mixing controls and properties and noting the outcome.  I like to relate XAML with TV; it is the language that is going to bring the media experience to the PC (If that ever isn’t a tautology).  Now, we are free to break the norm and put on our black turtle neck and grab a latte and start producing visually astounding apps.  Bring out the art in everyone.  I can definitely imagine an Adobe Photoshop for the XAML world.  As in the keynote, I look forward to Adobe After Affects for XAML.  The graphics world is going to be interesting coming forward, to say none the less.  In the past, the company who had the best looking application was the one who went up to all the base classes and overrid everything they could, almost down to the point where c# started to look like c++ in Win32.  Ugly!  It is also going to be interesting to see if such a system creates an obnoxious and non-consistent user interface.  I doubt it will, but it is worth argument sake.

     

    Another interesting phenomenon in the storage world is WinFS.  I am extremely interested to see how developers are going to store data going forward.  Will people continue to use Access and like technologies, or will they create schemas and store the data as a file as such.  I am sure perf will dictate a lot of these decisions.  But by the same token, isn’t that what separates this operating system from others.  If outlook continued to store contacts in its own format, where would we be now?  Absolutely nowhere, WinFS wouldn’t be worth a damn thing.  So this is a note to all you developers out there, Longhorn marks a paradigm shift in operating systems.  If you don’t give a little, you can’t take a little.  Right now, my Longhorn build is slow and painful in some senses, but once Microsoft hits RTM, I will never think about going back, and I am only considering bug fixes, forget about perf for the moment.  WinFS gives me so much that I willing to sacrifice some speed.  Besides, we will get that back within a couple of years with hardware advances.

     

    I could go on for hours about this fascinating stuff… And I have only seen it for about a week, the tip of the ice berg, so to speak.

    PostTypeIcon
    1,424 Views