Silverlight is supposed to support the excellent Opera web browser, but there is a long road between theory and reality. As of right now, a clean instal of Silverlight will not function at all in Opera, even with the “masking” or “cloaking” feature. According to Opera themselves, Silverlight was supported already in version 9.22, but I’m running 9.26 and it doesn’t work for me.

Crazy Boomerang Blog has come up with a snippet of JavaScript that seems to solve this problem by cloaking Opera and pretending it’s Safari (!?!?) running on Windows. This works to a degree but depending on the SL app will cause the browser to crash. So far there is no support for Silverlight 2 and if you try to apply this smart little JS app, all you get is a blank space. I can’t say for sure, but it appears that this is actually an Opera problem and not a Silverlight one. Regardless, I hope the people at MS and Opera can get their heads together and get this app running on what is possibly the best (and definitely the fastest) browser on the planet.

[Crazy Boomerang Blog]

I got a couple of emails about my post yesterday from angry web devs who wanted to complain about my Microsoft Fanboi attitude toward Silverlight. I won’t post the emails themselves here (let’s put it this way: had they been comments I would have deleted them) but I’ll reiterate their overall message:

Microsoft is already dominating the PC world and with Silverlight they are trying to take over and dominate the web world as well. Since Microsoft by default is an evil monopolistic corporation, noone should support their new scheme to monopolize the internet.

I realize this is a common sentiment among a lot of programmers, especially those that use Open Source software heavily, and it should come as no surprise that Mac users also share these attitudes (ironically because to describe Apple as a company you need a whole new definition of the word “monopoly”). I also understand the sentiment to some degree but at the same time I think it has more to do with the built in hatred we as humans have for those who do better than ourselves. For the most part, the ever-so-popular pass time of Microsoft bashing is wholly undeserved and misguided. But I digress.

In light of these emails I did some quick searches on the web for articles on Silverlight vs. Flash (because even though the two apps are two entirely different animals, they are still direct competitors). What I found was not too surprisingly a whole whack of misinformation, assumptions and good old fashioned propaganda.

There seem to be two fronts: Those that have tried and tested Silverlight and love it on one side and those who think Silverlight is a Flash rip-off and therefore are not interested in testing the application on the other. What I found most striking is that there are very few Silverlight-deniers who have actually tested the program - they just hate it by default and predict it’s demise purely because it is a Microsoft creating (and thus should be full of bloatware, holes, bugs and other garbage). I think that says a lot. If my theory is correct, most developers and designers who get their hands on this incredibly powerful application will be blown away by how much better it is than Flash. And I highly doubt anyone in their right mind would predict it’s demise once they realize what it can do. One noted exception is Lee Brimelow whose expertise in Flash ActionScript and authoring is unparalleled. He is thoroughly unimpressed by what Silverlight has to offer and considering his background and skill level it would be stupid of me to question his attitude. It is worth noting that he is an Adobe Evangelist so his views will be slightly biassed to the rival, but nevertheless I think it important to include his objections. Brimelow’s main stance is that Silverlight has little to offer that Flash hasn’t already done. And that might very well be true. But what Silverlight has that Flash is lacking is an accessible code language. While Lee and his kin will have no problem churning out hundreds of pages of ActionScript that can make Flash do pretty much whatever they want, most devs and almost all designers don’t have the chops (nor the time) to do this. Silverlight on the other hand has a more approachable code language and though this alone it becomes a more usable application. And when it comes to video handling, I think he will agree with me that what Silverlight offers is lightyears ahead of the Flash status quo (though his custom video player, which I painstakingly emulated some time ago, is amazing).

One interesting feature in Silverlight that is getting very limited attention is the ability of the apps to interact with common navigation tools in browsers. Anyone who has surfed through a Flash based website will know that hitting the “back” button on the browser by mistake is a big mistake. At MIX one of the Silverlight guys showed me a simple code set that let the application interact with the navigation buttons so that they functioned within the application itself rather than on the browser window as a whole. This is a huge feature that will make life a lot easier for devs and designers and I think once people start messing around with it they’ll realize it is something they have missed in the past. I know I will.

But like I said before, it’s in the video handling Silverlight 2 truely shines. And I can see a future where the grimy, buggy, crunched and artifact-riddled video provided by Flash will be a thing of the past. The fact that Adobe is working on new codecs and YouTube is playing around with a HD feature might very well be a testament to what a threat Silverlight is becoming. Because regardless of the success of Flash as a video platform, any serious video content producer will agree that compressing video for Flash is like running it through a shredder. Sure you can make it look good, but only by following very strict guide lines. The VC2 codec in Silverlight 2 is the difference between old VHS rental tapes and Blu-Ray. And for people like me who want high quality streaming video on the web that’s music to the ears. Ad to that intelligent streaming and scaling, full meta-tag integration and endless expandability and it really starts looking like something.

Ivana Tilca contacted me the other day because she had a problem posting Silverlight content on her blog. On further inspection it turns out it’s impossible to post Silverlight content using the iFrame method on WordPress.com hosted blogs! And since you have limited access to the code set in these blogs I’m guessing the very cumbersome JavaScript method will be equally unsuccessful.

Why is this important? With Silverlight, Microsoft wants to put up some serious competition against Adobe Flash. But if the embedding code is being blocked because it is unsafe (and iFrames are unsafe) it means people will chose other media to put on their blogs - no point putting it there if it doesn’t work. I have yet to test any other blogging services but WordPress.com is one of the majors and if Silverlight content is pretty much excluded from these blogs it is a big deal.

Considering Silverlight is being touted as a viable alternative to viral video sharing, this is a problem that needs to be fixed asap.

As for the reasoning behind blocking iFrame and JavaScript embeds in WordPress.com it actually makes a lot of sense:

You can embed malicious code and other nasty crap using these codes. And once something is posted on the service WordPress becomes somewhat responsible for the content. So if someone posts malicious content like a virus using an iFrame on their service, you can be sure people will sue them for it. Or the whole service can go down like what happened to MySpace.

True - WordPress.com allows certain “approved” JavaScript and iFrame codes - and  Microsoft better get in touch with them immediately (by clicking here) - but the current embed options, both JavaScript and iFrame, are lackluster, cumbersome and not at all workable. There needs to be a better and less wishywashy solution if this format is to succeed. Otherwise people like Ivana are going to go crazy and abandon the format. And that’s not good.

Turns out there are many interesting applications for the Wiimote other than gaming. And now people are starting to really take advantage of this. Cynergy Labs has created a Silverlight (WPF) application that uses custom gloves with IR bulbs on three fingers for a whole new way of interfacing with the on-screen content. The result is a Minority Report or Microsoft Surface like experience without a touch-sensitive screen. Just wave your hands around and use gestures to control the content. This video shows the versatility of both WPF, Silverlight and the Wiimote.

No postings for a while. Sorry. I’m buried in work.

In the meantime I found an excellent video at ThinkSwedish that explains how to transition from Adobe’s MXML and ActionScript 3 to XAML and C#.

Interestingly the ThinkSwedish blog is built on a Flash platform (so I can’t embed the video here) - a concept worth exploring in Silverlight as well.

Video link 

I encountered some weird problems trying to post Silverligth content in my blog and I can’t find anyone outside of blogs.msdn.com who have done it. My problem seems to arise from a combination of complicated scripts from Microsoft and bad parsing from WordPress not paying attention to the code I was posting. Read on to get an idea of what went wrong. The second half of the post still applies tho - the one about the “old” method. Although it seems irrelevant considering.

Using the iFrame method
Below is a Silverlight application posted using the iFrame method. If you do not see the fancy cirlce animation you need to download the Silverlight RC plugin from Microsoft.

The problem I had comes from the code from Tim Sneath’s blog:

iframe src=”http://silverlight.services.live.com/invoke/32/SlLogo/iframe.html” frameborder=”0″ width=”258″ height=”100″ scrolling=”no” />

It seems WordPress isn’t very fond of shorthand endings like /> but prefers the full ending. Thus the program auto inserted the full iframe close command right after the src call causing the remainder of the code to remain outside of the code. This in turn caused havoc on the remaining page.

Here is the correct code:

<iframe src=”http://silverlight.services.live.com/invoke/32/SlLogo/iframe.html” frameborder=”0″ width=”258″ height=”100″ scrolling=”no”></iframe>

iFrame method conclusion
There’s clearly something wrong with how WordPress parses iFrame code. The iFrame itself appears as it should but it ruins the rest of the code making the remaining page disappear. This problem persists regardless of what content is contained within the iFrame itself. The iFrame method works fine in WordPress as long as you close your <iframe> call with a proper </iframe> call afterwards. Otherwise you end up with a big mess.

Taking the long way round (using the cumbersome original method)
Originally publishing Silverlight apps in a web page was a bit more cumbersome. You can read the full description of the process here. When you post a Silverlight application the “old” way you have to do three things:

Insert script references in the header of the page:

<script type=”text/javascript” src=”http://agappdom.net/h/silverlight.js”></script>
<script type=”text/javascript” src=”CreateSilverlight.js”></script>

Insert html where you want the Silverlight application to appear:

<div id=”Wrapper_SlLogo” style=”width:258px; height:100px; overflow:hidden;”></div>
<script type=”text/javascript”>
var Wrapper_SlLogo = document.getElementById(”Wrapper_SlLogo”);
CreateSilverlight();
</script>

Create a file called CreateSilverlight.js containing the following script:

function CreateSilverlight() {
Silverlight.createHostedObjectEx ({
source: “streaming:/32/SlLogo”,parentElement: Wrapper_SlLogo});
}

If we dissect this process we see what happens:

1. silverlight.js is called. This file is (as far as I can tell) the Silverlight controller. When you create a Silverlight application the file is put in whatever folder you export to but for web purposes it is recommended you use the one posted on the agappdom.net site.
2. CreateSilverlight.js is called. This file contains the source and parentElement parameters showing the browser where the application is located and where to put it (name of the wrapper).
3. The html code creates a wrapper and inserts the object defined in CreateSilverlight.js into it.

For blogging purposes this is pretty much a non-functional process. To make this work in any reasonable manner the source and parentElement parameters have to be defined from within the page itself which means the JavaScript contained within CreateSilverlight.js has to be extracted and somehow inserted into the page itself. Seeing as you don’t have access to the header area in a blog post this means you have to insert the JavaScript in the code itself.

I tried doing this with unimpressive (non-existent) results. I can’t say if this is due to my poor knowledge of JavaScript or if it’s something else. I’m guessing the reason why Microsoft set it up this way to begin with had to do with being able to alter file calls without having to alter pages but that’s just conjecture on my part.

But like I said before: Since the iFrame method works as long as you close your frames properly there is no reason to start screwing around with the more cumbersome old method (unless you really want to that is).

It took way too long but now it’s here: My first video tutorial covering the overall design process of the iZufall.com website using Microsoft Expression Design. In the video I cover the overall design idea, how to import vectorized graphics form Adobe Illustrator and some other neat little things in the program.

Staying true to the Microsoft Expression experience the video is a Silverlight application hosted on Microsoft Silverlight Streaming. As you can see from my previous post I had some difficulties actually creating, uploading and posting the application but then a little bird tipped me off to this article that explains how to post Silverlight Streaming apps using iFrames and now it works splendidly.

So, without further ado, here is the first video. If you want a larger version to see all the small intricacies click here to openn a separate window. I advise you to do so so you can see what I’m doing.

Just a note: You’ll need to install the Silverlight RC plug-in to be able to play my video. It’s a small 2mb download that is completely safe, free and platform independent. You can download Silverlight by clicking here.

As I promised I’ve made an in-depth video tutorial on how I created the iZufall.com website using Microsoft Expression Design. The video itself was easy enough to make but I spent several hours today trying to conform it to the stats required to be able to upload it to the Silverlight Streaming Server.

Turns out publishing to the Silverlight Streaming Server and posting Silverlight applications isn’t all that easy. Here’s a “quick” run-through:

Step One: Create a Video
Easy enough. You can use anything to create the video and export it to whatever standard format you want.

Step Two: Conform the Video Using Microsoft Expression Media Encoder (EME)
Should be easy enough. Simply import the video file into EME and tweak the settins until you get the desired result. Only here you have to watch what you are doing. Turns out the Silverlight Streaming Server only accepts wmv files that are less than 22mb. My tutorial is huge (800×600) and over 13 minutes long (because I can’t stop talking). My first export (which took 20 minutes) totaled at 32mb so I was 10 over. With tweaking I managed to get it down to 23mb and finally 17.something. This tedious process took about 3 hours because the estimated size EME projects is completely off the charts wrong (the first time it estimated 70mb, the second 34 and the final one 26).

Anyway, when the video is exported EME spits out a list of files under the export folder. This list consists of the following (in alphabetical order):

• BasePlayer.js
• Default.html
• MicrosoftAjax.js
• player.js
• player.xaml
• PlayerStrings.js
• preview.jpg
• Silverlight.js
• StartPlayer.js
• YourVideoFile.wmv

The files are under a time stamped folder with a cryptic name like (in my case) “MORTEN 06-08-2007 1.24.08 PM”. I’m sure you can change this but I’m lazy.

Step 3: Upload Your Application to Silverlight Streaming Server
Once you’ve finished and tested your application you can post it on the Silverlight Streaming Server which allows you to post up to 4gb of free content. First you go to silverlight.live.com and create an account and then you log in. Once inside you can upload your application. But wait! Your application isn’t like a Flash .swf file… it’s a whole whack of files! So it’s not as easy as it seems after all.

As is typical I did not read any of the info and just zipped the whole export folder and tried to upload it directly. After waiting for an awfully long time (there is no bar telling you the progress of your upload or if it’s uploading at all) the project was created and I got a message that my archive was missing a file called “manifest.xml”. Serves me right for not reading the manual I guess. Turns out you have to build an xml file called “manifest” and put it in your archive to get your application to work. God knows why this xml file isn’t auto generated by EME since it is the same for all Silverlight Applications but alas it’s not so you have to make it yourself. The script is as follows:

<SilverlightApp>
<version>1.0</version>
<loadFunction>StartWithParent</loadFunction>
<jsOrder>
<js>MicrosoftAjax.js</js>
<js>BasePlayer.js</js>
<js>PlayerStrings.js</js>
<js>player.js</js>
<js>StartPlayer.js</js>
</jsOrder>
</SilverlightApp>

In addition the archive should not include all the files from the export. The proper zip archive should include the following:

• manifest.xml - The file you have just created in the previous step
• player.xaml - The XAML file correcponding to your Silverlight application
• *.wmv – Video file(s)
• *.jpg – Image file(s), thumbnails for the chapter markers and the preview
• *.js - All the scripts in the Output folder EXCEPT Silverlight.js

Confused yet? I know I was. Anyway. Once this is done you can upload the zip archive and the application will appear on the server.

Step Four: Posting Your Application
Again, if you are used to the relative simplicity of posting Flash content on a site you’ll be frustrated by how complicated it is to publish Silverlight apps. Once the project is uploaded you get a whole pile of code you have to use. I cut the below section straight out of the Manage Application page:

There are three steps required to add this Silverlight application to your web page.

1) Add the following script references to the page header section.

<script type=”text/javascript” src=”http://agappdom.net/h/silverlight.js”></script> <script type=”text/javascript” src=”CreateSilverlight.js”></script>

2) Insert the following HTML where you want the application to appear in the body of the page.

<div id=”Wrapper_iZufall1″ style=”width:500px; height:400px; overflow:hidden;”></div> <script type=”text/javascript”> var Wrapper_iZufall1 = document.getElementById(”Wrapper_iZufall1″); CreateSilverlight(); </script>

3) Save the following script in a new file named “CreateSilverlight.js” and place it in the same directory on the server as the page.

function CreateSilverlight(){ Silverlight.createHostedObjectEx({ source: “streaming:/[numbers]/iZufall1″,parentElement: Wrapper_iZufall1}); }

I believe there is an easier way of doing this - I vaguely recall seeing something about using iFrames but I have to do some more research before I can confirm it.

Final Thoughts

Since it took me so long to compress the project and upload it I had to leave my computer to go to my other job so I haven’t been able to test the last step and actually post the video tutorial yet. Hopefully I’ll be able to do this some time tonight so you can take a look at the final product and read my experiences actually posting an app.

For now I’ll just say this: Creating and publishing Silverlight applications seems unnecessarily cumbersome. I know this is just the beginning but for now this is not user friendly in any way. I’m assuming that publishing applications on your own server is easier (and I’ll test this tomorrow) but using the Silverlight Streaming Server is way too complicated for the novice user.

When I have this video and the second half where I demo how I the project went from design to functional website using Expression Web I’ll make another video walking through the process of creating and publishing a simple Silverlight application using Silverlight Streaming Server to make life a little easier for the next person that wants to try it out.

Here are some useful links to sites I used when figuring this whole thing out:

QuickStart: Package a Video File using Expression
Using the Silverlight Streaming Administration Site

That’s all I got for now. Stay tuned for the video tutorial :o)