I made a few comments about Microsoft's work around MDA and how I don't quite understand Microsoft's official position on UML. David Cutler pointed out that I should take some initiative and dig around for some reasoning behind that. Well I did, and I found out that things are changing. Visual Studio "Rosario" will have a number of UML designers built on the DSL Tools designer framework. I'm very glad to hear this because I've been looking for them for quite a while and remember scoffing Microsoft for not investing more than a class diagram in Visual Studio 2005. I had hoped Visual Studio 2008 would have included some new designers, but alas, it didn't. The November 2007 CTP includes two new designers in Team Edition for Architects (Team Arch) and obviously the all-up Team Suite. I haven't used the new sequence or logical class designer, yet, but I'm definitely intrigued by them. I doubt the sequence diagram will be auto-generating at first, but you never know. Either way, I'm glad to see Microsoft is embracing UML more.

Of course, this doesn't answer the question of what Microsoft's official position on UML is. That's a hard one to answer, considering we're a company of individuals who have individual thoughts and ideals, just like any other company. Most of the people I talked to were the vocal few, but it's clear that UML isn't the unanimous terror that Microsoft seems to have made it out to be. I'm glad I'm not the only one to believe that. While I'm not making any anouncements today, I can say that we will get a clearer message of where Microsoft is going with respect to UML. As I understand it, there will be more designers on the books for the next CTP in the March/April time frame, so I think I can finally say we're on the right track. Better late than never, right?

In early December, I asked myself whether I'd rather go to Mix or SD West this year. I haven't been to either, but have wanted to go to Mix since its inception. After some thought, I've decided to go to SD West. The main reason for that is because I feel like it'll have better content given my focus. The first year of Mix was all about the web and the second year was a mixed designer+developer event, but still heavily rooted in the web world. I definitely feel at home with that mix, but things seem to be changing again. This year, it sounds like there's going to be even more focus on designer content, so I'll let Mix shake itself out one more year and check out SD West. I look forward to it.

I saw Simon Guest talk about user experience back in August and one of the things I liked was a tool he had to help decide what user interface platform was the best. Microsoft has 30-something user interface technologies. Sometimes it's hard to know which will be best. More often than not, we use the one the tech lead is the most comfortable with, which is pretty much a crap-shoot. Simon's app, UXIQ, asks 12 questions which you answer on a sliding scale. Ultimately, you're given three recommendations to decide on. I'll definitely keep this tool in my arsenal and suggest you do the same -- both the app and source are available on Simon's blog post.

I was just telling a co-worker how, despite the fact that it hasn't been said, I believe WPF will be the future of Windows development. This seems obvious, but my initial take on WPF was that it was merely another option. I even question a potential attempt to relace the myriad of web development technologies with a XAML development experience. I don't see this being overly successful, but the idea of a single development model intrigues me. If that were to happen today, it seems like XHTML + JavaScript would have more potential. Either way, I don't see it happening any time soon.

Whether or not we see a single language span Windows and web, it looks like we have something new to look forward to. Apparently, Microsoft is looking into yet another UI platform. I seriously question why, but welcome the change. I'd really like to know what WPF is missing that requires a new platform. At this point, tooling is my only real complaint about WPF.

I'v been a mobility enthusiast for a while and it's nice to see others picking it up as well. I feel like the iPhone has a lot to do with that, which I find somewhat humoroous, but that's neither here nor there. Berners-Lee announced a new W3C validator, mobileOK, which checks web pages for standards-compliance and proven practices. This is definitely a step in the right direction. I'm looking forward to initiatives that'll bring the same capability to dev tools. Of course, it's the developers that need to change more than the tools.

Looks like there's going to be a new certification by the SANS Software Security Institute on the market for those specializing in secure development. Honestly, its intended for -- and probably be obtained by -- all developers, but I don't see it playing out that way. My initial take on it was that it was a great idea, but after remembering the security exam I took for my MCSD, I'm wondering what the difference is going to be. Another thing I should mention is that there will be exams specific to most major platforms (i.e. .NET, Java, C/C++). So, my quandry only applies to the .NET world. This one seems much more structured and thorough than the MS exam, so I will say there's some good potential. Either way, it'll be interesting to see how it plays out.

I don't know if I'll ever understand Microsoft's official position with respect to UML. Sure, the concept behind domain specific languages (DSLs) is sound, but is it truly necessary? I haven't seen any proof of that. Well, to be more specific, I should say I don't see a need for DSLs when it comes to software analisys and design -- UML has just about everything I've needed and extending it seems to be the logical answer. On the other hand, DSLs are absolutely fantastic for applications that can visualize their data. Honestly, I think more apps should consider DSLs, but when most developers either don't know or don't use software modelling tools, I have to say I'm not surprised. I, for one, have been meaning to dig into Microsoft's DSL Tools, but haven't had the time. One of these days, perhaps. Either way, this is the foundation for Microsoft's MDA approach... well, the development environment, at least. There's an interesting story there, but I'll blog about that later.

Since I first had a chance to really get into it, PowerShell has been great. For the first time, I have a real issue, tho. PowerShell handles arguments differently than cmd.exe. Specifically, the difference is the colon (:). In cmd.exe, arguments are split by spaces; but in PowerShell, the colon translates into a new argument. For instance, myapp.exe -arg1 -arg2:abc translates to { "-arg1", "-arg2:abc" } in cmd.exe, but { "-arg1", "-arg2:", "abc" } in PowerShell. Sure, we can code around this; but why should we?

Given my new venture, I have to complain about something... small tools/utilities that don't close when I hit Esc. Don't get me wrong, I'm not saying everything needs to close on Esc, but there is a lot that could. Take, for instance, the vast number of utility windows in Windows... wait, no, let me revise that... How about every control panel applet (or whatever you call them). Ok, sure, a lot of them are dialog-based and close as you'd expect when Esc is pressed. Let's look at the Windows Update window in Vista, tho. Since it's based on Windows Explorer, Esc doesn't close it. There's no OK/Cancel button; no buttons at all. So why would it hurt to support Esc? Perhaps this is simply an oversite, but it's one that way too common. I can name a dozen places like this in Windows, but I'll spare you the agony. Microsoft isn't the only culprit, tho. All I ask is that developers think about their users a little more. Is there any way you can shave one keystroke, one mouse move, or even a transition from the keyboard to the mouse. All these things add up to big points in the user experience arena.

To my surprise, HTML 5 has been in the works since 2004. While still 5 years late, in my mind, this just shows the ridiculous nature of these standards. I'm not saying all standards are this way... who am I kidding? I love the idea of having standards, but they take entirely too long to make it to the real world. It's like seeing a fantastic project in a research firm. It most likely resolves something you've been pained by for years, but you won't be able to benefit from that work for several more years, most likely. But, I digress... HTML 5 seems to have 3 main goals in mind: flexibility, interactivity, and interoperability.

When thinking about flexibility, HTML 4 gives us a lot. One of the problems HTML 5 seeks to attack is the lack of meaning to one of the most popular tags. No, not the <table>, which is used entirely too much; the <div> tag. Wondering what the problem is? So was I at first glance, but I think what the group is coming up with is better. There will be new tags to represent different sections of a web page. I liken this a lot to a newspaper or magazine, but it works fairly well for the web. The idea is, instead of creating <div> sections to correlate to your header, navigation, different sections and the footer, you'd use more descriptive tags (i.e. <header>, <nav>, <section>, and <footer>). Consider the following images. The first represents what you might do in HTML 4 and the second in HTML 5.

The markup would then look like this for HTML 5...

<body>
  <header>...</header>
  <nav>...</nav>
  <article>
    <section>
      ...
    </section>
  </article>
  <aside>...</aside>
  <footer>...</footer>
</body>

The first thing I thought was that this new model may not map 100% to all sites. Then I realized, they're just websites. You may not think about things as "articles," but that doesn't mean there isn't an equivalent in your context. There are, of course, more and more apps are moving to the web, so depending on how that happens, these may not work. I don't see this getting rid of the <div> tag, tho; merely offering something more specific to use, when applicable. Mixed with CSS, these new tags could be very nice.

There will also be better support for the head (<h#>) tags. Currently, most people use different tags at different levels and style them appropriately, so every <h1> looks the same, no matter what level they're at. With HTML 5, head tags will be more contextual, where different levels will be treated differently. Actually, I'm making an assumption here that probably isn't true at this time -- that CSS will know the difference between the different tags at different levels. CSS 2 most likely won't be able to, but hopefully CSS 3, whenever that's supposed to be out, will. Here's a block of HTML to portray the structure I'm referring to...

<section>
  <h1>Level 1</h1>
  <section>
    <h1>Level 2</h1>
    <section>
      <h1>Level 3</h1>
    </section>
  </section>
</section>

My vision is that the 2nd and 3rd <h1> in this example would be treated as <h2> and <h3> tags today.

While the new tag structure is nice, it's more for designers than developers. The feature developers will be happy to see will be the additional interactivity support, which will require much less work and more compliance across the board. Given the rise of multimedia content online, native support for multimedia content via <video> and <audio> tags is one of these improvements. One of the things that aggravates me about the current talk of these tags is a controls attribute, which specifies whether to use the default or custom controls. This is an attribute with no value, which isn't XHTML compliant. I know HTML isn't XHTML, but it'd be nice if the damn standard would at least take a step in the right direction. The additional ="true" wouldn't polute the spec. Despite that, the tags look promising. With the ability to customize the UI and built-in support for common actions like play, pause, and setting the current play time, I think most people will be fairly happy. That's not it, tho, there will also be APIs to support 2D drawing, storage, offline capabilities, editing, drag & drop, messaging, and my favorite, back button management. I haven't seen much about these, but I'm very excited about storage, offline, and back button management capabilities. These are problems that plague web developers.

As for interoperability, HTML 5 will be represented by its structure, rather than syntax. The key benefit of this is that it allows better support for the two formats HTML documents support: HTML and XHTML. As I understand it, the dual support is to provide better backward compatibility support with HTML. I see this and think, "Then why the hell would I even use HTML?" Maybe it's just me, but I'd rather use the markup language that provides the most forward compatibility. XHTML also provides some integration with external XML formats. The argument for HTML seems to be all about supporting lazy designers/developers who feel burdoned by the enforced structure. To me, they just need to get over it. The lack of structure in HTML is one of the main reasons the language sucks so much and causes so many problems across browsers. You could probably liken this to the VB vs. C# wars that were kicked off 7 years ago. To me, forward compatibility is more important than backward compatibility (aka laziness ). Different strokes, I guess.