Here's a picture of exactly how large the Silverlight Twitterboard was at TNE was.

The Microsoft Silverlight powered Twitter board makes another appearance in The New Efficiency launch event at KLCC today!

And this time it's being projected on a HUGE projection screen on the wall.

Well, Silverlight 4 has been announced and the Beta tools have been made available for developers to try out. And you can grab said Beta tools from this location.

The new features have been nicely summarized here. It still doesn't have native 3D scene creation support ala WPF but it reads out like a laundry list of feature requests made by developers. Web cam support, printing support, full network library support. etc. etc. But to me... there's one little bullet point stood out that had me grinning non stop.

FULL TRUST Out Of Browser Application Support.

If you're familiar with Silverlight 3 you'll of course have heard about Out Of Browser (OOB) support which allows an application to be installed then invoked like a normal application on the user's desktop. There was just one little... deficiency in that feature. The application would be run through a sandbox with some tight security restrictions that limited the OOB app to be a FULL BLOWN application.

This was of course due to the people at MS not wanting to cause another hysteria that had people crying fowl over how much power plugin applications can have over the system. ala The ActiveX Incidents.

But Developers recognized the full potential of having full trust apps capability and I'm guessing a lot of people sent a lot of requests over to the Silverlight team about this. Also more importantly...

Adobe's AIR platform, which basically is also a deliver RIA applications through the Internet DID allow for full trust capabilities when it deployed it's applications. This gave Adobe AIR a BIG one up over Silverlight 3 because it could do things that users wanted, and developers wanted ie. Full access to user's drives and network resources (no cross domain, or site of origin needed) And it was a generally lightweight platform as well.

But of course, all that has changed now that with Silverlight 4, developers can make FULL TRUST apps. To me it means one thing, Silverlight 4 now has the potential to allow .Net developers to easily create RIA applications on both Windows and Mac platforms. With Silverlight 4, a .Net developer can now tell people that in addition to Windows Applications, Web Services, Rich Web Sites now they can also tell people they can make applications that run on the Mac! A whole new platform just opened up!

To me.. Silverlight 4 has the potential to be the new .Net Client Platform!

And I do believe that I'm not the only one who sees this. I wonder what's going on at Adobe AIR's department right now?

Spotted in the Windows 7 Malaysia launch, a live Twitter hashtag display. Powered by Silverlight.

When Blend 2 SP1 was launched along with Silverlight 2.0, I had one problem with it. While the new visual state manager concept was great in allowing designers to define how the controls looked there was still one problem. There was no way for designers to do things like dictate that clicking a button started an animation, or moved to a different place in the application. This means that if you were creating an RIA application, the programmer would first had to create the basic navigational and behavioral skeleton of the application before the designer could start work. And also if the designer wanted to test some simple flow changes it be a bit of a trouble for them to do any changes unless they happened to know a little bit of .Net programming.

If we compared Blend 2 SP1 with Adobe Flash’s development environment, Blend 2 was at a disadvantage because of this. Since there wasn’t any way for a designer to complete their ideas without asking the developer for help. And now.. we have Silverlight 3 along with the RC version of Expression Blend 3. And I’m LOVING IT!

What’s there to love? For one thing, in order to solve the problem I described above I would have accepted it MS would have just written in some more event triggers in Silverlight instead of just having the useless ONLOAD that we had in SL1 and SL2. But MS went above and beyond that. Instead of defining additional triggers, they now allow the DEVELOPERS to create their own TRIGGERS. And instead of defining additional actions to the base elements. The DEVELOPERS themselves can create their own ACTIONS that can be attached to TRIGGERS to make them functional.

Ok, I’m not making much sense without an example. Basically a TRIGGER is an event, it could be something like on mouse click, on mouse move, etc. etc. And an ACTION is well… an action that does something. Let’s explain with the earlier example of a designer wanting to add some functionality to the app they’re designing. For example:- once a button is clicked, start an animation. This was not possible in Blend 2, and in order for the designer to see the results of this effect a developer would have been needed to write the code to wire up the logic. But in Blend 3, the designer would drop a MOUSE CLICK TRIGGER onto the button and then on the trigger he would drop a PLAY STORYBOARD ACTION and set the target storyboard to the name of the storyboard they wanted to play.

But that’s nothing new to Flash users, and I wouldn’t be making it sound like a new innovation if that was just the case. The fun part about this is that because the DEVELOPER can make new TRIGGERS and ACTIONS it means that if the base ones don’t work for the application and logic you require for YOUR APPLICATION, JUST MAKE SOMETHING that YOU NEED!

And the coolness doesn’t stop there yet, other than triggers and actions. You can also develop and drop BEHAVIORS onto your elements. And this is where it gets interesting. A behavior is exactly that, it tells the element it was dropped on how to behave. An example of a behavior is like Drag To Move, Shrink On Click etc. etc. And.. the most extravagant example of behaviors comes straight from the Blend 3 samples. It’s called BeeHive and is essentially a BreakOut clone, but what’s special about it is that the whole game was written by dropping custom game behaviors like collision behavior, movement behaviors, etc. etc. onto simple Image elements and poof.. GAME!

This just makes me wondering.. when creating a SL application (or WPF for that matter) it almost seems as if that I should write my application logic as behaviors so that designers can just drop the behaviors onto the elements which they see fit so they can easily change how the UI looks without going through me.

Wow.. what a long post.. and I haven’t even talked about sample data generation… and SKETCH FLOW! Another time then.

I was in the middle of writing a sample page to create a compeling Silverlight install experience (ie. anything better than the plain Install Silverlight Now button that appears in Silverlight Streaming hosted apps) so I can show how well the user can be guided to install Silverlight for a project we're working on.

As I hunkered down and got ready to hit the code, I find a link to... a white paper and sample code on how to make great Silverlight install experiences.

Well.. that sure saved me a lot of trouble! :P

Here's a preview of the what I've been working on during my free time. It's basically the next version of my YTBNSystem which I use for my video postings. It now contains a navigation system, allowing multiple short videos to be viewed sequentially, and also allows navigation menus to be built so you can have sort of a DVD like experience.

I encoded the video at a rather HIGH bitrate though, we're talking 400k ~ 450k. Cause I wanted to test out the data transmission performance. Let me know how it works out for you.

ps. As usual.. the UI design sucks ass because I'm a software programmer, not a graphics designer!

I've made a few references to the Silverlight Streaming Service a few times before on my website but I never quite explained what it is before. A lot of people thinks that the Silverlight Streaming service (SLS) is meant for hosting and streaming videos that are delivered via a Silverlight based video player. And thus when people go to the website they're expecting to see something like YouTube or some other video service.

But SLS is NOT JUST for hosting videos, it's meant for hosting Silverlight Applications. With Silverlight, a content creator is able to create rich interactive applications and media experiences which of course can be hosted on their own server of choice. But then, bandwidth issues come into play. Take for examples the various video podcasts/reviews/shows  and deepzoom albums I have on my site. Like any other web content I could have just hosted the files on the server itself. And that would mean that people from around the region would be able to retrieve and view the files very quickly because the server is close to them.

But... what if the viewer was from another geographical region? What if my webhost's network pipe is being throttled or consumed by someone else who is being hosted on the same server network? As an independent developer while I am able to make rich media content, I do not have the ability to host the content on some super fast, globally distributed server network.

And that's where SLS comes into the picture. As I mentioned it's not just meant for videos but entire Silverlight Applications (this includes everything on the client side ie. Your XAP file, any additional resource files, images, sounds, etc. etc. The service is not for hosting backend applications such as ASP.Net)

How SLS works is that first you upload your application files to the service and then you use the HTML tags (typically an iframe) to refer to your application. Then when a browser requests for the application, that's when the magic happens, SLS has a bunch of distribution nodes around the globe, when a request for content comes in the content is blasted via a high speed network into the distribution node closest to where the request is coming from and the content is served from that node.

This technique in theory allows most users to be able to grab the content at an efficient rate since the content will be coming from a server that's closer to the user.

There are 2 problems with this approach though, the first is a minor issue. Because the content is cached in the distribution node, any changes that you might upload (ie, replacing the XAP or an image file) might not be immediately visible to you.

The 2nd problem is much more of a headache that someone realized over at the Silverlight forums. Because the distribution nodes are given unique URLs and identifiers, if you use Isolated Storage in your Silverlight application, it's very likely that everytime a user hits the page, they'll never be able to read back their previous settings.

But other than those 2 problems, I'm happy with SLS. I'm glad that it is able to deliver my video shows on a steady bitrate. Though I do wonder what's the experience like for people outside of our region?

A new version of the Microsoft Deep Zoom Composer has been released, one of the cool things that it can now do is generate a Javascript Deep Zoom viewing client! Which is great when you want to allow people to view Deep Zoom images when you can't install a Silverlight client. The Javascript version is a bit slow though but I guess that's mainly because it's displaying images with the web browser's IMG display algos. But hey.. it's an alternative if you want to use it.

The other interesting tidbit is that the image generation tools is now a .Net ASSEMBLY!!! So no more hacking command line tools to generate your DeepZoom images, this opens up a LOT of doors for future integration and expansion.

Let me just insert this into my Deep Zoom Album creator program... hmmm.. oh oh.. what's the redistribution rights of the DLL?

Finally!! The Silverlight Streaming Service is now ready and compatible with Silverlight 2.0 Release version! To celebrate.. let's have a quick deep zoom album…. hmmm.. maybe I should just throw images in without worrying about how well they look?

Hmmm.. maybe I should make one of the panoramas I made. So here they are.