Microsoft’s Real Punishment is Having to Fight with the Gloves On

By the time the Microsoft anti-trust cases wound down, it could be argued that the alleged damage was long since done to the industry.

In a curious reversal, it appears that Microsoft’s direct penalties from the case were only a tiny beginning.

The real penalties Microsoft pays are not in money, nor in shipping “K” and “N” SKUs. They are in product strategies unpursued because they would be too provocative. In other hands, such strategies  might be reasonable if aggressive, but for Microsoft they might look like “relevant conduct.”

Today’s announcements about Office 2010 (“14”) were … well … let’s just say if you didn’t read about it, the most interesting thing you missed was seeing critics point out that Microsoft, inventor of AJAX (literally, for the Outlook web client), is only bringing other apps online 10+ years later.

The reasoning here is not about selling client OS licenses. Microsoft could have moved to the cloud richer and faster and more profitable if it could take the gloves off.

Need to get Silverlight penetration up from its abysmally low numbers to where it can really compete with Flash and become a meaningful platform? Just ship it with Windows and make it a priority update to every Windows box in the world. Problem solved. Now we can get down to the real work writing apps. Or at least Adobe could actually face some competition. But Microsoft doesn’t dare do this.

Why not stitch cloud storage directly into the OS? I hate leaving files “on the other machine.” Right out of the box, anytime I see an “Open…” or a “Save As…” dialog box on Windows 7, I would like the default destination to be a secure folder on Windows Live SkyDrive. Using the provider pattern, other vendors could offer a similar service, and the end user could choose. But Microsoft doesn’t dare with this either.

It is quite possible that the long-term benefit to the industry of having Microsoft thus restrained far outweighs the “lost” value we could have had from Redmond. But let no one fool himself into believing that what we see from Microsoft these days is everything they have to offer.

Silverlight Sound And Fury (You Know the Rest)

So as not to bore regular readers, I’ll skip the jeremiad.

Bottom line: despite the hoopla at MIX over Silverlight 3 – which is an incredible platform – there were still no meaningful penetration numbers presented.

And while it’s great to see the platform revving and maturing, the various version make a development decision that much harder. If you have a new idea for a Silverlight app, and you imagine your target audience will have the plugin or is able to install it, do you aim for v3? v2? v1?

I also haven’t heard a word about any explicit program to drive Silverlight client installs.

According RIAStats.com – perhaps not the best source of detected install info, but … wait, I guess if it’s the only source of information, that automatically makes it the best – Silverlight is on 22.3% of their observed clients.

Adobe Time-Warps Half a Decade Back, Will Still Probably Defeat MSFT

Earlier this week, I went to see a couple of folks from Adobe present their latest progress on Flash Catalyst, Flex "Gumbo," and the "Spark" UI component framework.

As someone who does a bunch of Flex work, I liked everything I saw.

Especially since it was the second time around.

No, I didn't see this stuff at MAX, I saw it at Microsoft PDC in 2003 and 2005.

It was shocking how pleased Adobe seems with itself now that it's almost ready to release a design tool that generates XML and RIA code... since everything they showed -- and more -- was part of the earliest Microsoft Expression Blend alphas that I saw years ago.

The Microsoft product was code-named "Sparkle." But we won't get this confused with Adobe's "Spark" because (1) "Spark" refers to a different bit, Adobe's re-invention of lookless, templated controls, which Microsoft implemented in WPF and shared with the world at the time (around '04 or '05), and (2) because Expression Blend is already out in a 2.0 version, so unlike the Adobe products, it doesn't need a codename anymore.

Adobe even has yet another XML dialect to facilitate moving design assets through the workflow -- it's called "FXG." And it appears to supplement MXML quite well in specific areas, so that if you take MXML and add FXG, you get XAML. Not that XAML was de novo or anything -- the XUL and Java folks (desperate to stop writing Swing code) had been creating similar XML formats for a while. The Java community was especially fond of XML with tons of imperative programming constructs mixed in alongside data objects and calling it "simple and declarative." What XAML did was provide all the necessary power, while keeping it declarative.

Anyway ... Adobe should get credit for recognizing the right way to do this when they saw it. Namely, they realized which workflow tools were needed, embraced the idea of export from Photoshop and Illustrator to a vector markup with a visual editor with timelimes, and thence to an RIA build tool with a code-oriented IDE.

Now that they're finally getting this on track, Adobe is even more likely to trounce Microsoft in the RIA world. They have penetration numbers that MSFT can only dream of, and for a company that doesn't build real developer tools they're giving it the college try.

Which is kind of sad, since I believe Silverlight is a better technology with better language and tool support ... and not any less rather more open than Flash.

Adobe and Microsoft Get Into It Like Children on the Playground

A week or so back, Adobe exec Mark Garrett got a bunch of attention for insisting that Microsoft's Silverlight effort has "fizzled."

Microsoft promptly screamed back that it wasn't so, pointing to the inauguration video stream, and a few other factoids.

What makes this truly schoolyard funny though is what happened today when Adobe "announced" it was bringing Flash 10 to phones. This seems just as dubious as Microsoft's oft-repeated plan (since as far back as '05, when it was WPF/e) to get Silverlight onto mobile phones ... by last year ... which obviously didn't happen.

Meanwhile, for years, Adobe has been pushing a weak technology called FlashLite for mobile ... and for a variety of reasons it has never been a usable option for content providers to deploy Flash content or apps.

For both Microsoft and Adobe, for both PC and phone applications, the critical metric is current "content-ready" penetration. How many devices are ready to run new Flash/Silverlight content off of the web today.

In this 2x2, the only square that's solidly covered is Adobe's Flash on the PC. "Ready" penetration of Flash 9+ is near 100%.

On PCs, existing install base is critical because of locked-down corporate networks that won't allow end-user installs. Microsoft needs to stop talking about download numbers, or numbers of people who "can access a PC with Silverlight," and start doing anything it can to get these ready penetration numbers up.

On mobile, the barrier is user confusion over configuration. Vendors could push the updates to phones, but in nearly 10 years of smartphones, only Apple has done much of this. Windows Mobile 6 has an updater ... and in over a year I don't recall it ever updating a darned thing.

Flash Lite trumpets a large "installed base," but these are strange installs, where the runtime (but not browser integration) is baked into the phone, and there's no reasonable way to get new Flash content onto the phone, either via web pages or download.

Both of these players are big on bluster and have been for a long time. Meanwhile, developers are left with few options for all of the smartphones in the world that don't an apple on the back.

Approaches to the Silverlight Dilemma: Cashback? Vista SP? Win 7?

The jury's still out on Windows Live Search Cashback -- apparently there were some issues on Black Friday and, overall, things aren't up to goal ... but that could change.

In light of this cashback program, though, my proposal from last year that Microsoft simply pay people to install Silverlight seems astonishingly realistic.

The problem with Silverlight is that it doesn't have wide enough deployment -- so there is a chicken-and-egg problem deploying apps on the platform. Microsoft has released stats about how many people 'have access to a PC running Silverlight' -- but that's an odd definition of penetration (if a state university has 15,000 students, and 10 computers in a library lab have Silverlight, then presumably all 15,000 'have access to a PC with Silverlight'.)

So ... why not just pay folks a small amount to install? Maybe a $2 coupon(Starbucks/Amazon/PayPal/etc.) to install the plug-in in the user's default browser.

The WGA or XP key-checking components could be used to keep track of machines that have participated, making it impractical to game the system by performing extra installs. I'm sure a suitable equivalent could be used to verify installs on Macs and Linux boxes.

Another approach is to wait for a future Vista SP or Windows 7 upgrade cycle. Since Silverlight will presumably be included for IE, the trick is to hook the default browser selection and attempt to install a suitable version of Silverlight into the target browser (Firefox, Chrome) when the user selects it.

This move would surely be controversial -- even if there were a way to opt out -- and would bring back memories of the Microsoft of the 90s for some. But, since the web page itself decides what plug-ins to use, and no content is "forced" to render via Silverlight, it's only moderately different from making WMP or any other dynamically loadable object available.

And for those "open web" advocates who have nothing good to say about proprietary plug-ins ... consider that Silverlight does not really compete with the open web, but rather with Flash, which otherwise has a de facto monopoly on any RIA that cannot easily or cost-effectively be implemented in HTML/JavaScript. Breaking that monopoly could actually help the open web cause by creating a real platform debate in a space that doesn't really have any debate right now.

Free Idea: AJAX Desktop Publishing App

If you're hankering to join the web startup circus and have everything but an idea, here's one for you: a full-on desktop publishing app ... online. The ready acquisition market for decent online productivity apps can serve as inspiration, even as the insane complexity of the undertaking urges you on toward greater heights of caffeination and maybe some anti-depressants.

Seriously, apps that can deal with complex page layouts and can produce a variety of press-ready output (InDesign, QuarkXPress) are expensive and hard to learn, and the average person rarely needs them. It would be nice to be able to hop on a web page and do a quick design. Wizards or integrated help could go a long way. All the usual business models (adds, freemium, pay-per-storage, etc.) apply.

Now, if you build this in Flash/Flex or in Silverlight (2.0), you merely have a ton of work ahead of you. While challenging, you may feel like you're not ... well ... proving just how wicked you really are, since those two platforms give you all of the technical infrastructure you need.

So why not go all the way? Do it in JavaScript, in the browser. Yep, WYSIWYG, arbitrary page sizes and layouts, in the browser. Advanced typography too. Fun times.

Here's a hint: one of the tricky bits is measuring text line layouts, since you'll need to make sure that the view matches the backing data (from which you will be generating other "views" or output formats).

JavaScript (the browser APIs really) don't give you everything you'd like. For example, one standard thing you need is to find out how many characters will lay out into a column of a particular width. Or simply what size a run of text will turn out to be.

While you can't ask these things directly, the clientHeight DOM element property can be useful: it shows the actual height that a DIV's content will lay out at ... so it will also signal when content has flowed from one line into a second line. By hiding the DIV, rigging up a while loop, and monkeying with the content (string), you can build a routine that measures text, so that you know exactly which characters are going to appear on a line.

Completing the application is left as a (possibly lucrative) exercise for the reader.

Take Silverlight Offline with Prism

Microsoft has been cagey about taking Silverlight "offline" to create cross-platform, desktop-installable RIA-style apps to compete with Adobe AIR. But if you are interested in building an offline or occasionally-connected app with Silverlight, it's not too hard to do.

If you're targeting Windows, then it's tennis-without-a-net:

1. you can create an "HTML Application" (HTA) and embed Silverlight
2. or you can create a Windows Forms app and embed Silverlight 1.0 in it as an ActiveX (this might be possible with Silverlight 2 as well)
3. or you can create a Windows Forms app that hosts the WebBrowser control, and load your Silverlight 2 app in there

Playing around with that last scenario, it was easy to get full communication between the Win Forms app (which has privileges based on the user who's running it), the DOM doc inside the browser control, and the Silverlight control inside the document. On Windows, that pattern allows a lot of options.

But what if you want a cross-platform app that works the same on Windows, Mac (and Linux, if the Moonlight initiative pans out)?

Take a look at Mozilla Prism: Prism gets you the basic desktop integration for running your app. Now you just grab your Silverlight files and make that the "web site" you're going to bundle via Prism.

Out of the box, Silverlight gets you offline isolated storage in the file system. Prism's separate Mozilla profile should keep the offline storage space separate from the user's general browser cache.

And with LINQ over objects and LINQ to XML, that may be enough for your data management needs. Silverlight doesn't come with a relational API or database like AIR does, though I expect someone will cook one up -- or write an adapter to SQL Server Express (if the odd restriction on Socket destination port numbers is relaxed.) And of course Silverlight doesn't have the native PDF support that AIR does (although XPS support will presumably show up at some point).

Before any of this can happen, all the related software has to get closer to production. Silverlight (2b1) has to stop crashing Firefox (3b4) when it terminates, and that combo also needs to get better at handling things like the SHIFT key.

Quick Poke: Look at MS Live Labs' Volta

If you haven't seen Microsoft's Volta project, it's worth a look.

Volta is about two big things:

(1) Blurring the lines between applications tiers to allow declarative or even automated tier-splitting (yes, there are lots of issues with this, but the MS team insists it's aware of the historical legacy of the distributed computing "leaky abstraction" and won't muck things up by pretending it's not an issue).

(2) Automagic cross-compilation between, say, .Net IL and JavaScript.

Whoa, what's that last bit?!

After the initial flurry of press coverage, the team insists that running arbitrary .Net IL on any old JavaScript-capable browser is no big deal, just a convenient demo, don't focus on that part... But, seriously folks, a couple of months on since the project was made available to the general public, the tier splitting is looking less and less interesting, and the cross-compilation is looking more and more interesting.

Once upon a time, crazy people did crazy JavaScript stunts. Like this demo that emulates the hardware of an entire 80s-era game system complete with game, or this similar 6502-based emulator.

Emulating a modern VM like the JVM or CLR is not practical from a performance point of view. But JavaScript runtime as a compilation target is becoming increasingly popular: first we had GWT and Script#, which compiled Java and C# respectively to JS. But because they only compiled your code supplied minimal bits of the respective class libraries (Java API/.Net BCL), their use was restricted.

So here's a wicked end run around that: take anything that compiles to IL -- or any IL binary! -- and run it in a browser. According to the Volta team, it has been done in such a way that all of the object semantics from the original language are preserved. Unless they also port the Win32 API to JavaScript, it's not like we're going to see WinForms apps running on Safari. But this is being positioned as a fallback for, say, places where Silverlight isn't installed.

Go here and look at the demos. The perf is awful -- but that's not the point of the demos. So far as I can tell, this is the first commercial implementation of what we all kind of knew might be coming.

Pascal Also a Silverlight Option

I try not to do too much "link/clip blogging." But I have a soft spot in my heart for Pascal, since some of my early PC and Mac programming was in Pascal. I had already racked up plenty of bad BASIC and assembler programming by that point. But both BASIC and assembly language encouraged the worst of my habits (hence "bad"), while Pascal made it easy to leave them behind.

Also I worked for a couple of years for one of Anders Hejlsberg's close friends, so if I didn't already admire him that experience was sure to raise his stature in my eyes.

So I thought it was cool that you can author Silverlight apps (along with any other flavor of app) in Pascal, using RemObjects Chrome.