The name of the product I work on is Microsoft Expression Code Named “Interactive Designer/Sparkle”. This is not the final name.
For four years it has internally been known as Sparkle. So for a history of the product, I’ll use that name.
I wasn’t around for the start of Sparkle. The people who know the very origins of the product are either gone or very, very busy…but this is what have been able to reconstruct.
As the Avalon planning began it became apparent that new tools would be needed. Avalon is taking the UI platform up a level…merging the best of the web, of multimedia platforms, and of traditional GUI platforms like Win32. Though not as revolutionary as the switch from command-line to GUI, there are parallels. Features such as vector graphics, animation and 3D that have long been available in specialized environments like Director, Flash, Anark, ToolBook will soon be expected on all platforms: Windows, Mac, *nix.
It also quickly became apparent that a very visual design surface would be needed to properly integrate all this visual richness. And that most traditional “developers” were even less likely to have the skills to create good looking UIs with all this power than they have been known for their UI taste in GUI interfaces. In order to be successful we needed to involve the Designer in the workflow. And finally, we found Designers did not want to use Visual Studio.
The Sparkle team started with a couple of very senior developers writing a prototype using WinForms to test a few ideas: 1) that a full blown design application could be written using managed code and 2) That we could integrate some traditional GUI development concepts into a tool that Designers would like to work with. Meanwhile the GM for Sparkle, began hiring a real team to build the product.
I entered the picture about the end of the 1st year. I was working on Visio. My job for several years was to figure out how Visio played in the new Web world and with new technologies like XML. The fruits of those labors were the XML file format VXD (Visio Xml Drawing), the Visio Viewer Web Component and the SVG import/export capability in the product. The next steps I was looking at included .NET customization, interactivity and better multimedia support. When I heard about Avalon, it seemed like a natural fit. In investigating Avalon I came across the Sparkle team. I set up a meeting.
The week we met was the first week for Sparkle Employee #2, our now GPM Pete Faraday. The team was still in the very early conceptual stages, but I could see where they were headed. In a previous life I was the technical lead on ToolBook, a multimedia development environment with a custom runtime, programming language, graphics model etc. I had always dreamed of building something like that but based on a standard runtime, with a richly supported programming environment and systems level graphics system. .NET and Avalon promised to provide those features. In the months after that meeting I just kept thinking “…maybe I should go work on Sparkle.” And so I did.
When I started in April 2002 the team had grown to six. There was a GM, GPM, a development manager (John Bronskill, who hired me and is my boss to the this day), and the designer Manuel Clement. The only code was the WinForms based prototype, and the two devs who had built that were moving on to new projects. A product manager started the same week I did. Chuck Stoner was the first “full-time” developer hired onto the team. He started a few months before I did, Lutz Roeder started a few weeks after me and by summer we had two more developers and a couple of interns. For awhile the code base was so small we kept stepping on each other’s toes (Chuck and I have kept up that tradition until the current day), though today there is enough code that we rarely have merge conflicts.
The first couple of months we spent learning Avalon and playing with the prototype to add some real Avalon functionality. I was assigned the task of studying Layout and wrote a short whitepaper summarizing what was available in WinForms, Java, the Mac etc. and how they were all insufficient. I did not come up with a solution. That would have to wait for Grid and other minds.
The big decision we made was to abandon the WinForms based prototype and start again using Avalon from the ground up. The Avalon team and others asked us to build atop Avalon in order to provide them feedback on what it took to build a “real” application. We felt it would send an important message if we could use the platform as our customers would, and we felt it would help us understand what the tool must do if we were targeting Avalon ourselves. The downside was we knew Avalon was unstable, rapidly changing and we would constantly be faced with updating Sparkle to incorporate breaking changes. This all turned out to be 10x worse than I expected, but I would still make the same decision. Our feedback was crucial to the Avalon team, and our product is richer and more interesting than it would have been if we had built it using WinForms. Most importantly, I think the message is compelling: you could not build Director in Director, Flash in Flash, FrontPage in HTML. But we built Sparkle using the Avalon runtime it targets, and in fact much of the UI of Sparkle was developed using Sparkle (the internals are still built using VS…we still believe high-end developers will gravitate to that tool).
For simplicity let us say Sparkle Year One ended 3 years ago in June. The team was about 10 people, including 3 developers and a couple of PMs. We had a small core code base that created an Avalon Window and a DocumentManager and a few simple tools. We could load and save XAML using Avalon’s built-in parser. The next year would be much more interesting…