 Video streamVideo streamVideo stream |
 |
 |
|
|
|
| Question indexQuestion indexQuestion index |
|
|
|
|
|
| Interview transcriptInterview transcriptInterview transcript |  Discuss this interviewDiscuss this interviewDiscuss this interview |
|---|
|
I am Ian Griffiths. I am a DevelopMentor, instructor, and also a freelance consultant and a C# MVP. I do a mixture of some software training, some software development and a lot of consulting work, and also some writing. I have got a couple of books and doing a magazine column for MSDN on Avalon just for the moment. We will most likely see a Whidbey version of a Windows Form book from me, although it may not be exactly the same kind of format because the nutshell books are gradually evolving I think because of the way that the Internet has displaced some of the roles that it used to fulfill because you can just get the reference material, you can get the class definition, you can get the basic structure straight away. It is very easy with Google to just go and download information surrounding a subject. We are probably going to have a slightly different style to try and provide a bit more value. I don't know. I am prioritizing the Avalon book that I am working on. That's probably going to be done before the Whidbey book because the Avalon is going to be a Beta book in time for the next Beta release of Longhorn. The Windows Forms book would come after that, probably closer to the actual final release of Whidbey.
I am indeed doing an Avalon book. This is initially going to be a kind of introduction to Avalon. This is actually a bit to explain. There is going to be Avalon Essentials is the current working title. The idea is to provide people who know .NET maybe know Windows Forms provide them with the basics of what Avalon is all about, enough information to get up and running to know what sort of things it will do for them, have a good overview of the technology, but not a complete comprehensive description of what it is all about and then follow it up sometime later when the final release of Avalon eventually becomes available. We are going to have a more comprehensive volume that is probably in line with the programming series that are already there. TSS: Big, big, thick thousand page... Knowing how verbose I am , it is going to be a big book. Even the Nutshell book was ironically titled at 800 pages. That is my small book. TSS: That was you with a lot of time to make sure it was a very short terse... I wanted to get everything in the most conscience possible fashion, 800 pages, that's what it had to be. TSS: Okay. You are well known for your, how shall we say, extremely full featured blog entries. I just like to type, I mean writing. I just enjoy any good explanation or something out. I don't really feel the need to make it any particular length, but just type as much as it takes for me to cover what I think, it is what I want to say. That tends out to be rather a lot. I've always been that way, articles that are over the limit and I've gone there a bit and they don't seem to mind too much. I think one of the nice things about the Web is that there isn't really that much material cost if you overrun on pages.
We are going to cover the essential programming model, the new elementary stuff that supersedes the HWND model we have had since the Windows. We are also going to look at the high level stuff built on top of that because they are actually built two levels of framework. The underpinnings of the raw, UI infrastructure and then on top of that they are layering high level concepts like controls and styling and those sorts of things. They are also building on top of the user interface elements underpinnings. We are also going to look at XAML, the XML application mark up language. The most common means by which user interfaces will be designed using Avalon. You're not required to use mark up but it makes the most sense for typical application development and we are going to look probably at things like localization and animation and other sorts of things that tie everything together. It is aiming to cover all the bases of the new technology that has been introduced with Avalon.
One of those has actually gone away. The CAML and BAML are essentially compiled versions of XAML. So XAML is an XML-based format. You don't really want to be dealing with that at runtime. If you try to run an application and launch it you don't ideally want to wait for an XML parser to be loaded off disk and for that to run all the way through the document before you could even think about showing anything on screen. The model involves preprocessing the compile time. What ends up in binary is not the actual XAML itself. It is a boiled down version of that. Now CAML looks lot like the way that Windows Forms does things today. It is a code-gen approach. So it would take your design, and would convert it into a bunch of lines of code that would construct an object to represent the root elements than construct child objects and attach those to the root element and so on. Conceptually very similar to the code you find in InitializeComponent today whereas BAML was a binary representation of the information represented in the XAML file. So it is pretty powerful to see you don't have to do any of the syntax checking. The compact format designed to be lightweight passing over the wire. It was indented to be the low bandwidth representation of a XAML file. Now I gather what they discovered was the speed at which CAML actually loads and realizes user interface was not significantly different from the speed at which BAML can be read and they same UI can be represented. So they felt the marginal differences in efficiency were not worth having two completely separate representations. My understanding is that BAML will be the way forward. So XAML will be the source code if you like and BAML will be the compiled version and CAML goes away. Disappears. People are using things like Flash to build kinds of user interfaces that are very hard to do with HWND. You have shapes which are not basically rectangle or if you want partial transparency and overlapping and if you want easy animation, this is not something that the HWND model was ever designed to cope with so that is one of the problems we have is the sort of user interface experiences that people are trying to build for certain styles of applications just don't work. You can go down a route where you start to build that on top of an HWND infrastructure and even it won't go fast not to be animations or you will find there are restrictions on how you can have things overlapping with respect to one another and you just paint yourself into a corner. TSS: Literally Yes, you WM_PAINT yourself into a corner. And so what you find out you have to do is you end up building the one big control model as I tend to call it where your use interface consists of a big HWND, huge rectangle on screen and you manage all the rendering internally. If you look at something like Internet Explorer that is how it works because some of the dynamic relayout they want to do and the speed of rendering they require and being able to scroll up and down vast documents. It is hard to do that if you use HWND as the basis for your fundamental user interface elements. It wasn't designed to support dynamic reflowing as user interfaces resize. It was not designed to support an awful lot of kinds of media that we are seeing out there now. If you have a video element to your display today, it works fine until you try and make it move and then you get window moves, video follows. Everything feels like it was stuck on with some slightly loose cellophane tape and isn't quite staying still as the UI moves around. That is a problem, it makes your interface look ropy and if your use interface feels a bit shabby people don't feel that good about the software. They feel it isn't working that well that the polish is actually important when it comes to the user perception of the application. If you are trying to build something, which is maybe having a sort of entertainment role as well as a functional role and there is a certain amount of crossover there as people are trying to build applications that are fun to use then that is an issue. If ITunes didn't look nice people wouldn't like it.
Those kinds of data entry style line of business applications, the whole Avalon visual impressiveness proposition isn't really all that relavent. However, there is a whole other side to Avalon, which is very relevant to those sorts of applications and it is one of simplifying the programming model and to some degree, it is actually the logical conclusion of where Microsoft has been going for a while. They have with Windows Forms already started this whole move towards simplifying the model, where the things you programmed with were directly connected to things on screen, because in Win32 you had HWND then you had a bunch of APIs and there was a bit of a disconnect between those. Windows Forms improved things a great deal, that is one of things I really like about Windows Forms is that you have a control, it is an object. You want to set its text, there is a property called Text and there is a much more direct connect with the kinds of language level features you are dealing with and the actual things on screen being that are happening and Avalon takes that slightly further and doesn't simply wrap the underlying things, they built the whole model to be implicitly linked in with the way that .NET works, is designed from day one to support the kinds of APIs people are in practice using. So you don't end up with this feeling that sometimes it doesn't quite line up because you have already got a wrapper around a different abstraction, that is no longer going to be the case. It simplifies things, which at the end of the day means you are not gonna have to write so much code to get things done, a lot of legacy baggage that tends to cause problems with Win32 applications, just gradually goes away. Whatever it might be weird focus management, not that great support for layout. Those things can make a difference even for simple line of business applications because even just presenting a lot of data on screen, there is actually quite a lot of work to be done as far as laying it out goes and Avalon provides new layout models that are going to improve things there as well. It is really the same kind of thing the .NET Framework has been driving towards which is trying to enable people to get what they need done with less code with less effort.
You could have asked the same question a few years ago about .NET. I think certainly in retrospect the answer there has been yes in comparison to what came before it and I think the answer is going to be same with Avalon. There is in practice with Windows Forms development a certain amount of pain, which just has to do with accidental historical features that are in there. I think having a clean new purpose built API is going to make a difference to the user that you can develop stuff and partly it's a case of maybe if you are already fully versed in the whole world of Windows and Windows Forms today. The incremental benefits if all you are doing is building things that you can build easily today with Windows Forms than the benefits may look marginal, you might think well this probably isn't worth it for me. It might be more of a long-term proposition for that sort of environments where the cumulative costs of dealing with that kind of stuff as years go on. In the long run if you are going for 10 years and carried on using HWND stuff for that long and then maybe you are going to think, maybe we should have switched 10 years ago, and that's going to be a difficult decision. That's going to be something a little bit hard for companies to work out. If there is no single obvious proposition that makes Avalon a no-brainer then at what point do you switch and you don't necessarily have to if Windows Forms is working well, if you have an existing code base and an existing developer skill sets in your company than Windows Forms is not about to go away. It is going to be supported indefinitely, so maybe for some people it will makes sense not to look at Avalon for a very long time to come and the thing that may eventually drive it is the number of available Avalon developers in the market versus number of available Windows Forms developer, that's a good reason for some technologies to go away. Otherwise, we are working fine.
The early adopters are gonna have to have a good reason. Initially it will be people who go "Oh yeah! Ok Avalon makes this thing that I was trying to do that was really hard much much easier." For example, one of my customers works in Imaging Systems and the support for high quality imaging to the extent required for things like medical imaging where you have to have detail beyond what the eye can see, so you can then process and bring out features that are not really visible. That requires a high quality of image handling than you get today with the built in GDI+ support. Whereas Avalon is gonna support much higher intensity definition, the resolution with which you can represent the brightness of an individual pixel in its color is that much better that it supports a range of applications which today you have to write special custom built code for. For those sorts of things or people are trying to built visually spectacular applications or people who may want to build applications where building large quantities of UI as mark up makes sense, because they are building new UI from time to time on a regular basis because maybe they're presenting information. For those sorts of things Avalon will offer an immediate value proposition, XAML.
The thing about XAML is it is not tied to any particular object technology, was not tied to any particular .NET Framework. It is tied to .NET but it is not specifically tied to Avalon. It is an XML syntax for representing trees of .NET objects. So you can write an arbitrary .NET object with just a couple of properties on and it is instantly XAML ready, which means you can take the XAML compiler and feed in a XAML document that represents a Windows Form with some controls in it and you can construct a Window Forms UI today. So it will be possible to do this. What is perhaps, a part of question to the answer is whether they're gonna build any support for that into the designer and I have no idea where they're going to do that. We haven't seen any of the design time tools for XAML emerge and XAML itself is still a moving target, which is one of the reasons for that. There are third party companies that are trying to support XAML on today's platform before Microsoft ships Avalon. They're obviously having to integrate with the Windows Forms world, because you want to open a window in .NET today it's got to be Windows Forms, so having to mix with that world. It will make sense to start seeing usage of XAML in a Window Forms context from those sorts of people. I am sure it will happen, whether it will be mainstream and supported out of the box by whichever version of Visual Studio.NET supports it, I don't know. You would have a single unified syntax, you wouldn't have a single unified programming model because the kinds of objects you are going to be creating in a web application are not the same kinds of control, not the same actual classes that will work in a rich client context. What you would end up doing there is using XAML to piece together ASP.NET web controls. At that point is that so very different from what is being done today, and the thing about the ASP.NET syntax is that it evolved out of an HTML world and very often you have the requirements to mix a bit of straightforward HTML non-dynamic mark up with ASP.NET specific content. I think it maybe makes sense just to have the syntax we already know that is already supported by tools like Dreamweaver. Just leave that in place. I don't see so much of an obvious benefit from moving from ASP.NET to XAML because they do very similar kinds of things, but ASP.NET is already specialized for what it does well. So you could technically build a web page with XAML. TSS: But you don't thinks it is going to be worth it? I don't see the benefit. I thought it was very interesting that this week at Win-Dev, when we had a show of hands of how many people are writing ASP.NET applications and how many people are writing Windows Forms applications, for the first time the Windows Forms hands outnumbered the ASP.NET hands. I was surprised to see that. I am a fan of Windows Forms. I thought it was gonna take a little longer to see that kind of transition. We are definitely seeing genuine momentum in that direction. It is not just Microsoft saying, "Hey! Tie yourself to our interface platform rather than using the web." There is actually movement in that direction. People have looked at it and thought maybe this is worth doing, an I don't think it is going to displace HTML completely, because there are things you can do with HTML that are never going to be available on every single platform in the world, because the thing about HTML is as Microsoft's way to put it, its got reach. It works on all sorts of platforms. I you are using a non-Microsoft web browser it generally speaking doesn't matter. There are sites on the web that in practice people would only test it against Internet Explorer. There is a movement to try and avoid that and it is gradually getting better particularly as all sort of shake up over standards and browser wars. That is now settling down to a large extent. TSS: We hope, we'll see what happens with Mozilla and FireFox now. It may all have to kick off again, but there has been a period of relative stability. Maybe we won't go through that again in quite the same way. I am not sure that Microsoft will necessarily feel the need to sort of go through all that again in terms of adding new functionality to their browser. They may just decide to match whatever new features FireFox seems to bring in. I think it is definitely not going to go away for the very simple reason that not everyone is going to be running Windows on every device. That isn't clearly going to be the case here. Apple has got a niche. They've been predicted for demise any number of times, but it doesn't seem to be happening and they seem to have a strong base in certain areas. Interestingly they are very appealing to a lot of consumer markets as well. For web sites that are trying to reach out to the same kinds of areas that they're popular in, it wouldn't make sense to tie yourself to the Microsoft client platform, which is what the smaller client will do. And likewise a lot of places seem to be going for Linux on the desktop and again, for that sort of scenario HTML makes sense because right now there isn't a particularly compelling Linux based smart client technology.
You asked about when would people choose a smart client, I've just given you a whole load of reasons not to. So when would people choose a smart client? It's often in cases where you know the exact deployment scope. You know exactly who's gonna be using the application. So intranet applications, the key example, you have companies that have what is currently a web based application for all the users in that organization or some particular subset will use and the thing is that very often they mandate a particular web browser because the team developing, don't want to test against a million different browsers because why would you? If you own all the machines that are going to run it you might as well standardize the desktop roll out. If you are going to do that you are going to deploy several megabytes of web browser. Why not deploy several megabytes of .NET Framework. And the reason for going down a smart client path will have two reasons, one of which is it is often easier to develop equivalent functionality in something like Windows Forms. It just takes less code. You don't have to deal with the fundamentally round-trip driven nature of HTML or the horror of having to do your entire user interface and validation in DHTML. These are not nice routes to go down. It's an expensive way to develop a software so if you can mandate exactly what gets installed on the desktop and you've got Windows around the organization then it is simply better value for money to develop in Windows Forms than it is to try and build a web application in lot of cases and deployment was really the only thing stopping people from doing this. Even today, there is a better deployment story for Windows Forms than there ever was with say Visual Basic 6, which is we have the ability to call HREF executables, you can build a normal .NET executable stick up on the web server, point your web browser to it and if the machine has got .NET Framework installed in the client then it will just run the application. There are a number of security constraints just like they were with Java Applets, it's a similar kind of idea, except its not constrained by the web browser it launches the application in a sort of standalone window and then you can shutdown the web browser and carry on. That gives you the centralized deployment of updates because you can simply copy new files to the web server, the next time some one clicks on the link, there it is. There are a number of limitations with this, first of all dealing with security if you need the code to be able to do things that would generally speaking be perhaps risky, like accessing the file system, connecting to the database, connecting to some web server other the one they came from for web services. There are configuration issues and operational management issues that need to be dealt with to make that happen, but those are often worth biting the bullet over because they are solvable, we know how to deal with these issues and then you can use this simple programming model without giving up the deployment benefits. Now of course it's not as good from a user perspective in some cases as a normal standard, rich client application which was deployed via CD or installs in an explicit MSI step because it is not there if the network isn't there. Which again it's obviously true for a web application and in theory one of the big benefits you should get from something like Windows Forms is you do not need a network connection. Things like Outlook work offline. I regularly before leaving the hotel download all my e-mail so I can work with that on the plane and that does not work with a web-app and that's hard to do with Outlook Web Access. Unless you install a local copy of Exchange Server, just so you can run Outlook Web Access that would be a mad thing to do you just run a copy of Outlook or what ever your favorite e-mail client is. So often access ought to be one of the big benefits that you get and today with Windows Forms to get that you have go back to a normal sort of Microsoft Installer or InstallShield or whatever it is you are using, one of those kinds of explicit installation steps at which point you lose some of the benefit. But Whidbey improves on this. You don't have to abandon this clicking on the web page, this URL based launching and the automatic updates, you don't have to abandon that just because you want off line operation so in Whidbey this Click-Once technology combines those two things together. They have a piece of the .NET Framework which sits on the client side, which manages the things you run off the URL. When you go and click on that, it goes ah right you are running a .NET application I'll download that into a cache and I will remember that you've done that and you can even arrange to add it to you Start menu so that when you're next running the computer up you are not connected, you are in an airplane, you click on the Start menu there it is and click on the link it goes "Okay, well I will go and check for an update right now except you appear not to have a network connection so we will just run the local copy". You get the best of both worlds. If you're connected to the network and there is an update there you get it, there is no need to go every single desktop manually but you get the offline operation well. So that is something you can't get with a web application that's a fundamentally different model you get all the deployment benefits but with no other disadvantages.
I think both Microsoft the Sun really spun their wheels a few times when it came to trying to come up with a user interface framework based upon virtual execution environments. Sun went through a number of iterations, we had AWT and then a number of version of Swing, but Windows Forms was by no means Microsoft's first attempt in this space, they had a couple in the Java space before that and one of them went down the same kind of the path as Swing of trying to just ignore the underlying windowing architecture and present complete self contained architecture of how to present the stuff on to the screen and it doesn't work that well. It turns out that the performance on today's hardware is enough, that it feels just not quite there. It is a similar kind of experience to the video stuff I was talking about earlier. None of the controls quite feel like they are connected. You sort of click and then it goes in and it just feels a little bit like it's not working properly. I think that was one of the problems is the way to build responsive applications on today's window and technology using today's virtual execution systems like Java or .NET turns out to be the approach that Windows Form has taken, which is wrappers on top of the underlying system functionality because the Windows Team have put a lot of work to making sure that when you click on a button it responds really, really quickly, because you have a surprisingly small budget to play with in terms of delay of input and response before you start to get ergonomic problems with the way the user interface feels. I think that is the first problem. You need to deal with the technological limitations of the platform to get something that actually feels like it is working properly. Computers are not yet infinitely fast, we still do have issues with how fast things can be done and only certain approaches work. I think that was one of Java's problems is it had a nicely defined approach that worked not at least because they had to deal with multiple different platforms. With Microsoft they have the benefit of going "We just gotta make it work on Windows, nothing else matters to us." They had a big advantage there and have taken that advantage. I think another issue is that my feeling that a lot of the Java user interfaces that I've used is they just don't feel quite as mature. There are also little things that Windows controls do. They've been built up over the years, keyboard shortcuts that work, little tricks and tips that most people don't even know about, but most people have a collection that they know and maybe each of us knows about 20% of the possible things we could know, but if the one use isn't there it's hugely frustrating. I can't even say what it is about the Java OpenFileDialog that I didn't like, but I think it won't do the if you type in the first letter it finds the item in the list like the list used in Windows. The last time I used the Java application that wasn't working, that for me actually turns out to be enough just really annoying every time I open something. It's little things like that. When you describe it, that's just an irrelevant feature, and has nothing to do with the function of the application, but it turns out to have a big impact on how easy it is to use from day to day because if it puts friction in your way, it's going to slow you down, it's going to be annoying. I think to reduce for that kind of friction, usability, or just removing barriers where it really turns out to matter is a place where Windows doesn't get as much credit as perhaps it deserves I think. The Windows team has done an awful lot of work over an awful number of years to try and make that sort of thing work well. I think the Java world has not got as far. Perhaps they will eventually, but I also get the impression that no one in the Java space cares quite as much, that's not really central to today's Java proposition. TSS: I know that people have looked at a lot of the Java applications as back end systems that Java is for the backside, J2EE rules the enterprise and so forth. All the Java work I've done was entirely in that space. It was all building web applications, all building the things that would have to sit on top of it. It was never building rich client front ends.
It's certainly feasible and particularly with web services becoming an increasingly popular way of connecting the rich client up to the back end or connecting different bits of systems together. There is no real reason that you have to be using a Windows-based back end just because you're using a Windows Forms front end. It's certainly a viable architecture. I think today the kinds of places that are using Windows Forms in the front ends tend to be more Microsoft shops than others because they are the ones to whom this message has been most pushed at, but I think you may also start to see that kind of mixture. A lot of companies in London certainly are using a mixture of Java and .NET. On the back end largely, but it would make sense to see .NET coming to the front and where today maybe Visual Basic 6 still dominates. You might see .NET replacing that but the back ends will remain a mixture of old C++, Unix based systems, Java systems and .NET systems. I think that's certainly a viable approach.
In the .NET space what I miss from Java ironically an IDE feature, which for the longest time it was Microsoft's IDE is way ahead of all the Java things, but Java got the refactoring long before that became prevalent in the Microsoft space. Now, today, you can buy it and you can retrofit that to Visual Studio 2003 and I like that and it's going to be built-in. Some refactoring is going to be built in to Visual Studio 2005. Today the out of the box experience with the main IDE most people use for .NET is lacking in that, whereas in Java that's pretty much considered very good these days. That will be the single biggest thing that I miss. Going back to the Java space, whenever I do that, the thing that tends to trip me up the most in practice is actually the amount of effort it takes to get a working test system up and running. It seems to take a lot more to assemble whichever JSP container my vendor is using this week, we would have a database back end they're using this week and building a working system on my own computer that I can then say ok this is reflecting what my clients using it. I often spend a few days getting to the point where I can even start thinking about doing the work I have been asked to do. I think that's largely just the way that I would work to be honest. That's a personal thing, but I tend to work in a lot of different projects. So I end up paying the initial cost of what does it take for me to get going, much more than most people do.
It's particularly expensive going into Java, whereas in .NET, it always going back to the .NET Framework with the Microsoft IDE and the only question is which database are we using. TSS: Even that eight times out of ten in SQL Server. Yeah, in the Microsoft projects I work on. Yes, it does tend to be that. The startup cost, the initial sort of barrier to entry, what do you need to get working to get up and running seems to be higher. That may not be relevant to most people.
Click-Once is obviously a crucial feature, but we've already discussed that one. The layout has been enhanced. One of the things I liked about Windows Forms, one was a certain styles of lay out. If you wanted to have resizable forms that can adapt to whatever screen real estate the user chose to give to the windows. Certain styles of layout will work, certainly just you have to write code to do it, just like you did that in the old days. Now we have added to the old docking and the anchoring based layout we had before, we've now also got HTML style flow layout. You have a bunch of controls into a space and if the user makes it that shape, it will lay them out left to right, but user makes it thin and tall it will go top to bottom. That's a nice thing to have and it is also table-based lay out. If you're doing HTML table layout, you've got exactly the same sort of facilities available. TSS: Sounds familiar for some reason. I could swear that we have seen this before some place. Some other user interface technology you might have done this.
TSS: Yeah, it calls back a few memories. Yes, there was of course a bit of philosophical difference between the way that Microsoft approached layout to start with and the way Java approached it. Whereas Microsoft pretty much assumed the most people are going to want to have design slips they could look at, they can drop things onto, whereas Java, Swing in particular, took an approach of you're going to build objects to represent the UI. So to have automated layout mattered a lot more there because you needed it to do anything much really, but as a result of that they had a much richer suite of layouts out of the box. Probably because they didn't have to work out how on earth is it going to work at design time because that's actually a nontrivial problem. Working out the designer experience is a large part of the battle because in truth, .NET Windows Forms has always had those features. You could go to GotDotNet, download the free open source implementation of all the features I just talked about but they were impossible to use at design time. You pretty much had to draw on paper the layout you were gonna use and say, "Here I am going to use a flow container inside that and I am going to have a table and I am going to make that one spring," pretty much what you in practice often had to do with Java as well. TSS: You just described how I wrote Swing UIs, paper and then write code from there. In practice we always have had that, but now we have the designer experience to go with that, which makes it a whole lot easier to use. You don't have to use the on paper first approach and it also made it easier to work at where you're going because the problem with going down these highly automated layout approaches is the nesting in the relative relations of controls starts to matter a whole lot more, whereas in the static layout things there are simple, but if you've got all those things there, but its size is determined by the nested thing here. You then suddenly want to know what the structure looks like. The design time support is there for that as well, they've get the document outlined, which shows you the complete hierarchal structure of your form, which is actually, now that I have that how did I ever work without this, I must have been insane. How did I ever get anything done without the document outline view, so that's another useful feature. Also speaking of design time support, It's now possible to use the splitter control without going mad, which is a nice feature. The designer has been significantly improved. What else? There is also the ability to write menus and toolbars that look like they were written this millennium, which is nice because previously they actually managed to take a step backwards with the look and feel of the toolbars. The Windows Forms ones didn't look quite as good as the MFC ones, which didn't look that great to start with. But I think with Whidbey it's a first. The toolbars you get on your application are the same look and feel as the ones that Visual Studio itself is using, which has never hapened before, or at least not within living memory, using it since version 1. I think that's a good achievement and it kind of feels a bit sort of fluffy. It's like Oh, its just look and feel, it isn't that important except it does also have things like the editability. You can switch on the ability to be used as a palette of buttons dragging from left and right and how and what they need to use for that particular style of application usage. That's all tied into the new configuration framework, which is another new feature, the ability to automatically store settings into the user's profile with a lot less code than required before and that hooks up to some of these new UI features. It's relatively easy to have it remember all the positions of the toolbars, what's on the menu, which things are configured where and so on. A lot of these improvements are really about the whole story, it's not about any single feature, the way some of these new features interact as a whole is important.
The most important thing, do you mean the most important technology? TSS: You have 30 seconds in which he is an empty sponge, ready to soak up whatever wisdom you can give him. Just some nugget that he will frame and put over the top of the cube, what do you tell him? What's the one thing he needs to know to be a successful programmer? Whether it's technology, style, language, what? I actually think that possibly the most important thing is a familiarity with what the libraries as a whole have to offer. I wouldn't say any single feature, getting comfortable with .NET Framework, knowing what pieces exist, knowing the structure, knowing the roadmap is far more important than any single detail. I wouldn't say just focus on Windows Form or just focus on Avalon, I would say, "Look at the class diagrams, see what kinds of things you have." Because I know so many people went into .NET, after like a year or more go, "I have been spending the last three months writing this masterpiece of framework, just to discover it's already done for me. I've never found it before." I think it's a familiarity with the lay of the land of the .NET Framework as a whole is probably the single most important thing because most of the details are relatively easy in an awful lot of cases. That's one of the attractive features. I think knowing the roadmap, knowing the outline is more important than any of the individual details. Okay cool. Thanks Ian very much and good luck in future endeavors. Thank you very much.
|
