I just downloaded IE8 and have to say I'm liking it so far. I was pretty concerned that it was going to be a horrid experience, but it hasn't been. Of course, the next thing I did in this self-centered world of ours was check my website. Being built on DotNetNuke, which is notorious for non-standard HTML, I was concerned. I was happy to see no problems. I'm sure there will be some, but at least I'm looking good so far. I guess all that work I did trying to keep tables out of my design was well worth it.

My only real disappointment has been the fact that web slices have to be explicitly coded into web content. For some reason, I was thinking we could simply select a portion of the age and tell IE to create a web slice from it. I guess not. Maybe I was just thinking of Dapper.

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?

If you're not familiar with the story behind Open XML to date, Rob Weir  of IBM has a decent overview. I'd be remissed if I didn't say he was somewhat biased, tho. An example of this is a comment he made about how he believes Microsoft will drive change in Open XML with every release of Office. This, in itself, shows how little he understands about the Open XML format and why its proponents believe in it as a superior format to ODF. I have no doubt Microsoft will try to push modifications as more and more customers ask for new and innovative features, but that's exactly why Open XML is better -- it was built with extensibility in mind, unlike ODF.

Here we are, waiting for the last leg of the process to kick off at the end of this month and some skeptics say, "While you're waiting [for the ISO decision on standardization], don't save in OOXML format." Should you listen? Probably not. There are some seemingly logical arguments behind the comment, but the position is flawed. He states that you should use the legacy binary formats to ensure a truly "open" experience. To word that another way, you should use a proprietary binary format instead of one based on open standards, such as ZIP and XML. I'm sorry, but I'll stick with my Open XML file formats, which I have full control over and can get data out should I need it, unlike formats like the legacy DOC and PDF formats, which require binary interpreters. I can get my data out of Open XML files without any document reader. I simply need a tool to extract the content and read text files -- not that I expect everyone to feel this way. Also, with more and more format converters out there, I fail to see the importance of constantly saving to a format your tool of choice doesn't natively support without translation. You'll get a much better experience working in native formats and only converting to another when you need to publish or share your content externally.

We're not looking at all bad news, tho. With the 3522 comments made on the original specification, most overlapping on similar concerns, 662 responses have been made. I don't know if there was truly that much overlap that would support 662 answers to 3522 comments, but you can browse the comments and responses online. In another attempt to ease the community into the new formats, Microsoft has also published the legacy binary formats.

What's perhaps more interesting is the fact that, in a truly independent study, the Burton Group  found Open XML to be a superior format. You can get that report online, but I doubt most people will see it. Perhaps developers at traditional Open XML opposing companies like IBM and Google read it, tho, seeing as their products seem to support the new formats. Of course, I think this is a must-have. You can't have a tool that neglects the native file format for the de-facto standard when it comes to productivity applications.

What do I expect? I expect the format to be approved. I'd be lying if I said there wasn't a doubt in my mind, but the evidence is there that it's a superior format. The fact that these open source companies are so up-in-arms about Microsoft wanting to push its own formats thru the standardization process says something about their motives. Microsoft wants options and, with that, extensibility. If the format is judged on the merits, like all good arguments, the answer is clear. If you ask me, the worst thing about Open XML is Microsoft's name on it. If that weren't there, it'd already be a standard.

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.

As promised three months ago, the source code to the majority of the .NET Framework is now available... and ahead of schedule, I might add. Check out Scott Hanselman's  short list of requirements before digging in. Looks like we'll get a download version as well as having it integrated into Visual Studio 2008's debugger. Bon apetit!

Microsoft’s search story has been a bad one. Not because the tools are lacking; it’s the marketing that has hurt the product. You’re probably asking, "What search story?" Windows Desktop Search has been out for desktop users for a while, but I have to say the WDS experience on XP sucks. I’m not sure why it changed so much for Vista, but it’s completely different. After experiencing Vista, I look for search everywhere; and, when it’s not there, it’s my first complaint. Vista sold me; search needs to be completely ubiquitous. If your app doesn’t incorporate search, you’re probably not doing your customers justice.

What is Microsoft doing for enterprise search? The answer over the past year has been SharePoint for Search. Now, you’re probably asking why you need SharePoint. This is exactly the problem. You don’t need SharePoint and, honestly, SharePoint doesn’t have anything to do with it, hence the marketing problem. Well, it seems like things are changing. Microsoft is now pushing Search Server (MSS) 2008. Perhaps one of the best things with this announcement is the lighter-weight companion, Search Server 2008 Express. I don’t know all the rules behind when you would want to use one or the other, but this is a great opportunity.

If you’re asking yourself why you’d want MSS when Google has such a strong search technology, I’d have to argue that perceptions aren’t always reality. I’m not saying Google doesn’t have a good product on their hands; I’m just saying MSS is better than you probably think. I live in search and have for the past 9 years. I picked up on Google fairly early and made it part of my life. When I switched to Windows Live, I thought I’d be missing something, but I wasn’t. I haven’t looked back. I’m not saying it’s been a better experience, but it hasn’t been worse. It’s equivalent. With respect to enterprise search, MSS is hands-down a better choice than Google. Why? Security. Google knows search in the public domain; that’s what it’s good at. Grabbing everything and making it discoverable to the masses. Tell me; do you want your company's contract details and competitive info made available to everyone who has access to the intranet or just those with the right need-to-know? Google can’t give you discoverability and security of sensitive material -- it’s all or nothing. Microsoft has been very good at only showing results to those who have access to them. For this reason, I think Microsoft has a stronger enterprise search story. What’s great is that you can now take advantage of this search and the security included in that within your applications.

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.

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.

Within the past month, the Open Document Foundation officially declared it would no longer support the Open Document Format (ODF). I had my speculations about the reasoning behind this move, but I can't say I would've guessed the foundation would close its doors. Of course, that was before the W3C knocked its own contender who the Open Document Foundation has chosen as its next poster-child, Compound Document Format (CDF), down a few pegs. That may sound a bit harsh, but apparently, W3C's Chris Lilley stated, "CDF... was not created to be, and isn't suitable for use, as an office format." There's nothing really wrong with this, but it definitely took the wind out of the foundation's sails. So much so, that there doesn't seem to have been any public announcement of the end of the foundation. All we know is the official website (broken link) has been taken down.

So, what will this mean for ODF? Who knows. It would've been nice to have seen the foundation approach Microsoft regarding Open XML, but that obviously didn't happen -- surprise, surprise. ODF won't simply go away. Sun and IBM are pushing it with pretty big budgets, hoping it'll grow the dying Open Office initiative. There have been some speculations noting that this could be the early stages of ODF's slow death, but I don't think it'll go so easily. I guess the astonishing thing is that the foundation just called it quits on the effort they supposedly felt so strongly about. If they really felt so strongly, I imagine they'd have worked a little harder to find a viable solution, even if it was to back Microsoft.

Maybe it's just me, but I keep waiting to see some major reason to switch back to Firefox and it just isn't happening. I picked it up pretty quickly at about 0.7.something and fell in love. Well, maybe it was more lust. I still go back and forth between the Firefox and IE, but that's more about getting things to work in both major browsers. Since IE7 was released, it's been my default; and, after looking at Firefox 3 Beta 1, that won't be changing anytime soon. There are only a small handful of features in Firefox I feel really out-step IE and I find most of those in add-ons. Honestly, there's only one feature I miss. Well, it's not really a feature, but the actual architecture. Firefox reminds me of two other very successful applications, Visual Studio and Eclipse. Why? Because all three are biult on extensibility. All three are merely skeletons to be built upon. Everything you get when you download/buy these apps is an extension that was merely packaged with it on the install. If IE had such a framework, I'd argue that it was better than Firefox. The lack of this framework is why I believe Firefox is so successful... aside from great timing given Microsoft's lack of improving IE. A lot of good work went into IE7, but it's not enough. IE8 is fairly hush-hush and, while I have a few ideas of what will be added, I don't think we're going to see a change in the underlying architecture. From what I've heard, there's a potential for a small revolution, but that all depends on implementation, of course. If you ask me, tho, I'd like to see a complete rewrite for IE9. I don't think that's necessarily out of the question, either. There are some good things we could see out of it. Anyway, what I really started this post for was how disappointed I am in Firefox 3. Aside from the architecture, Firefox doesn't bring anything revolutionary to the table and I'm still waiting for more. One day we'll see something big. The question is, who will push it out first and when? I have a feeling that'll be IE.