Todd Bishop is a reporter on the Seattle Post Intelligencer who has a blog where he posts stories about Microsoft that didn't make it into the paper. In a recent post entitled, Microsoft eyes podcasts he writes

During the revival of the Gillmor Gang audio program over the weekend, podcasting pioneer Adam Curry said he had been trying for some time to persuade Microsoft and Apple to pay attention to the trend and build podcatching features inside Windows Media Player or the iTunes software. He said things changed when Steve Jobs demonstrated the new iTunes podcatching feature last week at the Wall Street Journal's "D: All Things Digital" conference. On the Gillmor Gang, Curry explained what happened next:

"It was like 15 minutes after it showed up in the Wall Street Journal when Microsoft called, saying, 'Hey, how do we get in this?' I don't know a lot about Microsoft. I do see they're a lot hungrier company than they used to be. But every single time you talk to them about anything that's new, or in this case iPodder functionality inside Windows Media Player, the almost standard answer is, 'Yeah we're going to have a lot of that in Longhorn.' That to me means there is this huge steamboat that is very difficult to steer left or right, and it's just harder to get stuff done at Microsoft."

That's just a snippet of an interesting discussion of the topic. You can download the full program via the Gillmor Gang link above.

I had lunch with someone from main campus yesterday and it seems that Adam Curry's perception is also being felt by the folks who work on the product teams. To repeat myself, I hope it doesn't take the stock hitting $10 before some action is taken.

I was supposed to post this a month and a half ago but somehow never got around to it. Jon Pincus who organized the session put up his notes on the 20% time session at CFP 2005. It was a pretty interesting discussion, some of which is excerpted below

Some examples that started as 20% projects at Google include GMail, Google Suggests , Firefox prefetching, and various technology pieces that are used throughout Google's code base. At Microsoft, many of the Windows Power Toys had a similar genesis, and attendees thought that Apple's iPod may have had similar origins in a "part-time, on-the-side" project.

One question that came up repeatedly (in various forms) is "how does the company know that people aren't just goofing off?" The short-term answer comes down to trust (that is, the assumption is that most employees will do their best to use this time in ways that give value to the company); in the longer term, contributions from 20% time projects are considered as part of reviews, and so if you've wasted the time, it will come out at that point. [It was pointed out that trust in general reduces "transaction costs", and so can increase efficiency -- so that even if (say) 10% of employees are accomplishing absolutely nothing with this time, it still could be a big win not to have any monitoring overhead which would slow down the other 90%.]

Another question that came up a couple of times was how to manage the impact on schedules -- does this mean that all dates wind up 20% further out than they would otherwise? I don't think there was an explicit answer to this in the meeting, but several people pointed out that a large chunk of many engineers' days at a lot of companies goes to various kinds of not-specifically-product-related tasks (e.g., reading Slashdot); if that "breakage" is diverted into time on a 20% project, then the actual hit is much smaller.

Most of the discussion was devoted to discussing the reasons that this approach appears to work well at Google.

I personally think that creating a framework that encourages developers at a company to work on side projects is very rewarding for both the employees and the company. I don't know how I'd have dealt with some of the issues I had with being a cog in a [relatively] slowly moving corporate wheel if I didn't have RSS Bandit to work on in my previous job.  Now that it is a mature project that has seen hundreds of thousands of downloads since it started, I often end up talking to product teams working with RSS at Microsoft in an adviser role. I got something out of it and Microsoft got something out of it.

One of the questions that kept coming up during the session was how one measured 20% time and made sure employees weren't goofing off. The answer was that it isn't really about taking a day off every week, its more about factoring in the time that the person will spend on their side project into their work schedule. After all, no one has 20% of their time free just before shipping and then there are times when weeks go by with not a lot of work to do. 20% time is more about allowing developer employees to reclaim some of that slack in ways that may or may not benefit the company but would make them more satisfied with their day jobs.

Joe Beda mentioned that the fact that Google was a web application built around web services enabled people to quickly write interesting applications utilizing the data and processing power of their back end. Now that I work on the back end of various services at MSN I can see his point. It would be very interesting to see the kind of applications built if we encouraged people to go wild with the APIs behind applications like MSN Search, MSN Spaces, MSN Messenger, Hotmail, MSN Groups, Start.com, MyMSN and see what they could build in their spare time.  In fact, I've already seen one cool hack built on top of MSN Virtual Earth by some internal folks and it isn't even out yet. This is one of those things I'll definitely be evangelizing at work. Wish me luck. :)

About two and half years ago, I was hanging out with several members of the Office team as they gave the details about how Office 2003 would support XML file formats at XML 2002. Now that it's 2005, juicy information like that is now transmitted using blogs.

Brian Jones has a blog post entitled New default XML formats in the next version of Office were he reveals some of the details of XML support in the next version of Office. He writes

  Open XML Formats Overview

To summarize really quickly what’s going on, there will be new XML formats for Word, Excel, and PowerPoint in the next version of Office, and they will be the default for each. Without getting too technical, here are some basic points I think are important:

1. Open Format: These formats use XML and ZIP, and they will be fully documented. Anyone will be able to get the full specs on the formats and there will be a royalty free license for anyone that wants to work with the files.
2. Compressed: Files saved in these new XML formats are less than 50% the size of the equivalent file saved in the binary formats. This is because we take all of the XML parts that make up any given file, and then we ZIP them. We chose ZIP because it’s already widely in use today and we wanted these files to be easy to work with. (ZIP is a great container format. Of course I’m not the only one who thinks so… a number of other applications also use ZIP for their files too.)
3. Robust: Between the usage of XML, ZIP, and good documentation the files get a lot more robust. By compartmentalizing our files into multiple parts within the ZIP, it becomes a lot less likely that an entire file will be corrupted (instead of just individual parts). The files are also a lot easier to work with, so it’s less likely that people working on the files outside of Office will cause corruptions.
4. Backward compatible: There will be updates to Office 2000, XP, and 2003 that will allow those versions to read and write this new format. You don’t have to use the new version of Office to take advantage of these formats. (I think this is really cool. I was a big proponent of doing this work)
5. Binary Format support: You can still use the current binary formats with the new version of Office. In fact, people can easily change to use the binary formats as the default if that’s what they’d rather do.
6. New Extensions: The new formats will use new extensions (.docx, .pptx, .xlsx) so you can tell what format the files you are dealing with are, but to the average end user they’ll still just behave like any other Office file. Double click & it opens in the right application.

...

Whitepapers

The Microsoft Office Open XML Formats: New File Formats for "Office 12"

http://download.microsoft.com/download/c/2/9/c2935f83-1a10-4e4a-a137-c1db829637f5/Office12NewFileFormatsWP.doc

The Microsoft Office Open XML Formats: Preview for Developers

http://download.microsoft.com/download/c/2/9/c2935f83-1a10-4e4a-a137-c1db829637f5/Office12FileFormatDevPreviewWP.doc

This is totally awesome news. I remember asking, back in 2002, why Powerpoint didn't have an XML file format and the answer was that it was due to schedule constraints but it would be fixed in the next version. Not only did the Office guys keep their word but they went above and beyond.

This should make Sam Ruby happy.

In a recent post entitled Dare responds re: open and closed systems Tim Ewald writes

Responding to my statement:

Dare was quick to blame WSDL and XSD, noting that POX/REST/AJAX systems don't have this problem. Certainly the customers I talk to who have done POX/REST systems are moving toward WSDL and XSD because they want metadata about services in order to facilitate reuse. Without it, they don't have a clear picture of what their systems are doing - or how to reuse them in other contexts. For a closed system, lack of descriptive metadata is fine. But if you want something open and reusable across apps, it really helps to have it

he called me on my description open and closed systems:

Interesting. So Yahoo! Web Services, the Flickr API, Bloglines API, del.icio.us API, and every RSS feed on the planet are closed systems that aren't open and reusable?

Yes, Dare, you are right. I concede that these very public APIs are open and reusable. I was really talking about systems *inside* a company (which I meant to imply with my reference to our customers). In many cases, developers start using POX over HTTP to build systems. When people want to re-purpose those services, its hard because they don't have a lot of information about what message formats and exchange patterns they support. In many cases there is no documentation for that, other than the code and, in that sense, those systems are closed. XSD and WSDL help open them up by providing metadata about what those services do. In some cases that metadata is also useful for finding services that do interesting things. For many of our customers, that is the reason they are migrating from existing POX over HTTP systems to SOAP-based Web services.

As part of my day job I'm in the position of having to work on both internal and external web services at the same time. I can totally see how internal services can end up not being documented well especially since they usually are written for one or two specific partners whose questions can be answered over the phone or email. In fact, I've been meaning to add code samples to one of our specs for over six months but have never gotten around to it because there's always a higher priority issue to work on.

On the other hand, an external web service could be accessed by dozens to hundreds of developers, many of whom will be unable to contact the creators of the service. In this case,  the onus is on the creators to either provide excellent documentation or use standard interfaces that are well documented elsewhere if they actually want anyone to use their service. 

In both situations, I wouldn't consider an XSD or WSDL file as being sufficient documentation. They are definitely better than nothing but they are a far cry from providing enough metadata for users of a service to determine how to properly interact with a service especially when dealing with operations that have to be performed in a series of steps (e.g. uploading a photo or enclosure to a user's home directory then attaching it to a subsequent blog entry).

If your organization is having problems with poorly documented internal services then the answer is to document them NOT to rely on WSDL & XSD files as documentation. As David Ing mentioned in a response to Tim's post   

- XSD/WSDL helps automate the contract side but doesn't really reduce documentation when compared to POX/H, in fact sometimes they increase the complexity up a notch too high. The tools aren't up to a state where you can hook up and just go - staring at the wire and talking on the phone are still facts of life in enterprise integrations. That's a side affect of the problem domain rather than the technology.

In summary, there is no substitute for good documentation. Anyone who tells you otherwise is most likely trying to sell you something.

A number of MSN Spaces users had to deal abusive comments from malicious users impersonating others on their weblogs. This is a problem we are well aware of and are examining various approaches to curtailing.

Recently on I found an entry on Jen's Space entitled Petition where one of our users who's fed up with malicious comments wrote

The following petition was made with regards to suggestions for further upgrades to MSN Spaces as pertains to security.

1. We would like to see the option to enter any URL in your comment removed and replaced with a field showing the URL of the commenter by default. This field should also be inactive and therefore not available for modification or the changing of the default URL. There have been several cases where individuals have left hateful and slanderous comments on other Spaces using the URL of another member to avoid being identified. This sort of thing should be stopped and we believe that the above recommendation will help.

2. As with MSN Messenger, the ability to have your Space public and still being able to block certain members from viewing or commenting on your Space would also be beneficial. There have been several members that went Private to avoid people they did not wish viewing or commenting in their Spaces.
   

If in agreement to the above suggested upgrades to MSN Spaces please sign your names below in the form of a comment so that we can pass this on to the powers that be. I think we can all agree that these two recommendations will help with some of the ridiculous problems that certain members have been forced to deal with.

We've considered both approaches to solving the malicious commenter problem but neither one seems like a complete solution. The main problem with the first request is that it doesn't handle the case where the commenter is a valid Passport user who doesn't have a Space. Unless we prevent people from being able to provide their own URL, name and email address then this solution wouldn't really work. Given that we already get complaints that requiring Passport to post is restrictive, this would seem even more problematic. The second request doesn't really work if the Space is public because all the malicious commenter has to do is sign out and then they have access to the Space even if their Passport account is blocked.

For now, the best solution is to create a private space and add the Passport accounts of the various people you want to access your Space to your permission list. We have excellent documentation about permission settings which should show how to make your space accessible only to specific people in your address book or your MSN Messenger contacts.

In the meantime, rest assured that we are working on solutions to the impersonation problem which allow users to trust that commenters are who they say they are while not limiting the expressivity of people who leave comments in a blog. 

I love the tough problems.

If you are a geek, you may have heard of the Firefox extension called GreaseMonkey which lets you to add bits of DHTML ("user scripts") to any web page to change its design or behavior. This basically enables you to remix the Web and either add features to your favorite web sites or fix broken UI design.

Over the Memorial day weekend, I got the hookup on where to obtain a similar application for Internet Explorer named Trixie. Below are some excerpts from the Trixie website

What is a Trixie script?

Any Greasemonkey script is a Trixie script.  Though, due to differences between Firefox and Internet Explorer, not all Greasemonkey scripts can be executed within IE.  Trixie makes no attempt to allow Greasemonkey scripts to run unaltered, since it is best to have the script author account for the differences and have the script run on both browsers if he/she so chooses.

Refer to the excellent Greasemonkey documentation to learn how to write Greasemonkey/Trixie scripts.  Note that some of the information there won't be applicable to Internet Explorer and Trixie.

Installing Trixie

Trixie requires the Microsoft .NET framework to be installed.

To install Trixie, download and run TrixieSetup  (latest version: 0.2.0).  You should ideally close all instances of Internet Explorer before doing this.  By default, TrixieSetup installs Trixie to your Program Files\Bhelpuri\Trixie directory (you can of course change this location).  It also installs a few scripts to the Program Files\Bhelpuri\Trixie\Scripts directory.

Restart IE after installing Trixie.  Once you have restarted, go to the Tools menu.  You should see a menu item called "Trixie Options".  Selecting that will show you the list of scripts installed and which one's are enabled or disabled.

Once you have installed Trixie, you browse the Web just like you always do.  Trixie works in the background executing the scripts on the designated pages and customizing them to your needs.

I've been using Trixie for the past few days and so far it rocks. I also looked at the code via Reflector and it taught me a thing or two about writing browser plugins with C#. So far my favorite Trixie Script is the one that adds site statistics to an MSN Spaces blog when you view your own space.

It looks like I need to spend some time reading Dive Into Greasemonkey so I can write my own user scripts to fix annoyances in web sites I use frequently. Remix the web, indeed.

Update: It took me a few minutes to figure out why the project was called Trixie. If you're a Speed Racer fan, you probably figured it out after reading the second paragraph of this post. :)

Over the past week and a half, I've been fixing bugs in the implementation of newsgroups support in RSS Bandit. Yesterday I celebrated getting the last major networking issue being fixed by posting a somewhat empty message to the microsoft.public.xml newsgroup from RSS Bandit. The main thrust of what's left is for Torsten and I to decide how we want newsgroups to be exposed in the user interface.

It is time to start thinking about another item on the roadmap for our next release. This time I want to focus on what we'll do to better support RSS enclosures and podcasting. If you are unfamiliar with either of these concepts, you should read Dave Winer's blog post Payloads for RSS from 2001 which describes the concept of subscribing to digital media content such as songs and videos as opposed to just text as is common today.  

Although I am not interested in any of the amateur talk radio or audioblogging that is typically associated with podcasting I still think this is a very interesting development that should be supported by RSS Bandit. I would love to be able to subscribe to the G-Unit website and get new songs that have been released to the public or subscribe to the various XBox 360 rumor mills to get new videos of game demos.

Below is a list of features I'd like to see in RSS Bandit.

1. Ability to download RSS enclosures to a folder of my chosing. This folder can be configured per feed so I can have some stuff go to C:\G-Unit and other stuff go to C:\XBox360.
2. A list of files currently being downloaded or that have been downloaded.
3. A download meter to indicate how much of a file has been downloaded.
4. Ability to add files to my Windows Media Player or iTunes playlist of my choosing on successful download. The level of configurability of this feature will depend on how much work is entailed. :)

If you have any ideas that I have left out or comments about the above list, just go ahead and reply to this post.

Of the major online service providers, Yahoo! has always been one of my favorites. I may use the Google search engine to find stuff online or MSN Messenger to chat with friends and coworkers, but I utilize more services from Yahoo! than any Web company. In fact, I'm the main reason that all the Windows machines in the computer labs of the College of Computing at Georgia Tech had the Yahoo! Toolbar installed on them when I was in college.

Now that I work at MSN, I get to work on stuff that makes me as excited about software as I used to be in college when I first marvelled at the utility of Yahoo!'s toolbar. Even better is seeing a lot of the stuff I work on either directly or indirectly, influence one of my favorite online services.

In a recent blog post entitled Not Nerdvana, But Maybe The Suburbs, Stowe Boyd writes

I was out in California on the 12th, getting briefed by the Yahoo Messenger folks about the newest release of their instant messaging suite
....
Note As I sketched in a recent post (Nerdvana: A Better Tool For Communication (I Can Dream, Can't I?)), I would really like a rich client on my desktop that put the buddy list firmly at the center of the universe, and all other stuff -- email, blog posts, to-dos, appointments, geographical location, whatever -- hanging off the buddy list as a collection of attributes. Because people and social relatedness is the center of the universe, not documents, calendars, email, etc.
...
Note the 'contact card' in the screenshow above, where various elements of Jessica's digital relationship to me are displayed. We see various icons, representing ways I can contact her. But better, much better, we see the music she is playing, and new profile info and blog entry.

The contact card is something we pioneered in the most recent release of MSN Messenger. It's illuminating to compare Stowe's screenshot of the Yahoo! Messenger contact card with a screenshot I took last year of the MSN Messenger 7.0 beta contact card.  I totally agree with Stowe Boyd that software should help people better communicate and interact with each other in social contexts. This is something that lots of folks at MSN are passionate about and it is edifying to see our competition follow our lead in this area.

This morning I saw an article in Infoworld titled The battle for the blogosphere which had some interesting comments about competition between Yahoo! and MSN in the blogging arena. Some of the excerpts from the article are

Introduced in beta form just last December, MSN Spaces now hosts over 10 million blogs, an eye-popping adoption rate that has blown past internal Microsoft expectations. "MSN Spaces is the fastest growing service MSN has ever introduced," said Brooke Richardson, lead product manager at MSN communication services.

The significant thing for the blogging market is that Microsoft is doing it its way, designing MSN Spaces to have a central text-blogging core but complemented by and integrated with a suite of MSN online services, such as instant messaging, e-mail, music playlist posting, and photo sharing. Microsoft also built into the service access control features to let users determine who can view their blogs, although they can make their blogs totally open if they want. MSN Spaces will also notify users when blogs from friends have been updated.

In March, Yahoo introduced in limited beta a service called Yahoo 360 whose concept and design are similar to MSN Spaces. This service comes as no surprise, because Yahoo, like Microsoft's MSN, has a wide variety of online services with which to surround its blogging service. As two leading Web portals, MSN and Yahoo have an amount and variety of online services under one roof that few others can rival, and blogging is something they're weaving into their overall fabric.

Later on the in the article, the author takes issue with the lack of customizability of MSN Spaces in comparison to other online services such as Google's Blogger and even mentions Robert Scoble's post from last year, MSN Spaces isn't the blogging service for me. We've gotten a lot of feedback about customizability and we definitely will be looking into how we can offer more flexibility. 

From my perspective, the competition between Yahoo! and MSN around who can build a better social computing experience for end users is a lot more exciting than the competition around search engines that have garnered all the press. This is definitely a fun time to be working at MSN.

There have been a number of events over the past week that have gotten me thinking about XML Web Services and how the technologies have been handicapped by the complexities of the W3C's XML Schema Definition Language (XSD) and Microsoft & IBM's Web Service Definition Language (WSDL). The events that brought this issue to mind have been

• Contributing to Mike Champion's efforts in putting together Microsoft's submission to the W3C Workshop on XML Schema 1.0 User Experiences and having to revisit the various interoperability problems caused by the complexity of XSD.

• A recent paper by Steve Loughran and Edmund Smith entitled Rethinking the Java SOAP Stack which argues that since the complexity of Object<->XML mapping based on XSD/WSDL is too difficult that Java SOAP toolkits should simply work with XML directly instead of doing data binding of XML to objects.

• A recent post by Steve Maine, who works on the XML Web Services team at Microsoft, entitled Travelling through hyperspace where in response to the various arguments about the complexities of XSD and WSDL he states "WSDL, XSD, and SOAP are facts of life in the web services world"

• The W3C's creation of the public-web-http-desc@w3.org mailing list to discuss the creation of a web services description format (i.e. a WSDL replacement) for RESTful web services

These are definitely interesting times for XML Web Services. The complexity of the technologies that form the foundations of SOA is now pretty much acknowledged across the industry. At the same time more and more people are taking the idea of building web services using REST very seriously. I suspect that there might be an opportunity here for Microsoft to miss the boat if we aren't careful. 

Paul Thurrott has an interesting series of articles about MSN's past, present and future. In some ways it could be called How MSN Got It's Groove. 

1. Part One: Beginnings
2. Part Two: Fly, Butterfly
3. Part Three: Services That Communicate

The article does a good job of capturing a bunch of the changes that have happened in the organization over time as well as offers some hints as to some of our future plans. My favorite part of the article is this excerpt from its conclusion.

When I speak with people from the Windows division at Microsoft about new product releases, there's always an unspoken assumption that I won't see these people again for many months or even years. With MSN, it's sort of a running joke that I'll often be speaking with them just days later. They just have so much going on.

And we have a bunch of stuff planned for this year. The recently announced MSN Virtual Earth is just one of many cool things we'll be shipping this year.