Tuesday, June 30, 2009

Simon a case study part 1 - designer developer work flow

So I while back a friend of mine and whom is another person that shows up to the local designer developer Interaction group and myself were talking about a simple demo app we could do that would show case a number of things, our goal was a good sample she could use on her resume and be a good sample application that could show case designer developer work flow and composite application development. Her idea was todo a simple Simon says game that we would have in Silverlight. As a team (such that two people being a designer and UX dev can be) we had our 'business requirement' but we needed to build on that with a comp or visual vision of what we wanted and a story (use case brief, scenario or other excuse for the same). Our user story went something like this:

John doe wants to play a game like Simon says. John sees link on a web page that says 'Simon says.' John clicks link and he doesn't have Silverlight installed so he gets a 'install me' link with a faded image of Simon. John can see from the faded image that Simon is what he is looking for and decided to install Silverlight. John then go to the Simon link and Simon comes up. John can click the new button to start a game and play a traditional game of Simon says buy following the sound and light patterns and clicking the appropriate game pads. John is able to use the high score button to see his high score. John has fun with and easy to use game and spends to much time playing the game.

with this as our user story, Ariel (the designer, names changed to protect the innocent or not) put together a wonderful bit of Xaml. Ariel being familiar with working with dev's took into account that things needed to be groups, and names reasonable or I would have a hard time working with the asset. For me the first thing I did was load the project and start to wire it up. One would think that Simon shouldn't be too complicated and at first it wasn't. A few events, and a game timer using a story board and we are good. Being the retentive dev that I am, I've had to learn to let go of that when it comes to Xaml as this tends to hamper or slow down the design to the point of just not being worth the time invested.

That all being the case we soon had a working game. Part of learning to work together and further learning to work on the same code at the same time that Silverlight and by extension WPF (actually that might be the other way around) is having the designer and dev work from source control. I know allot of dev's will have a cow about letting designer touch source control but its really not that hard. check out file, check in file... really even a designer can get the hang of it when their tool (Blend 3) supports it now. So we put this in source control (http://Simon.codeplex.com/). the one little detail we had to over come though was Silverlight 2 vs Silverlight 3 and we both were on opposite sides of the fence. This probably was our biggest issue we had to work out where we disagreed. And any time there is a designer and developer on the same project you tend to have at least one disagreement. We ended up eventually on Silverlight 3 as it supports more, the tools are better and it is being released next week. But generally deciding on any issue should be done based on the requirements and when the requirements don't provide enough bases then other reasons should come into play. The key then is to communicate. granted we hear that in everything from time immemorial but really how much do we have to tell people before the get it. 'TALK' things through and normally logic will dictate the best solution.

moving on...

Once in source and having the app running we would start building the application out. Ariel can muck with the design in more detail and focus on the finer points of the design to it was pixel perfect and I could play with game logic and function and we both could do it at the same time. Truly a zen moment for designer developer relations.

Friday, June 26, 2009

MediaElement for Sound effects

In doing Silverlight Simon and friends and then trying to port the uber tile from Silverlight to WPF I found that for doing quick short sounds there was a limit in Silverlight and WPF to the preformance and bahavior you can expect. WPF's 'MediaElement' is just horride but even in Silverlight if I try to use the same media element to play 2 short 2 second clips with in 1 second you will get issues. I must say though the Silverlight team has done a bang up job on the media element. It is orders of magnitude better then the one in WPF.

As part of pulling bits out of the crossfader codebase to post on codeplex I built a new 'MediaElement' class (see http://Crossfader.codeplex.com/) that solves this problem with sound in Silverlight and WPF and makes my life just that much easier for building composite apps.

So Karim suggested something called channel support to solve this and in this control I implemented it. Basically what happens is that the usercontrol called 'MediaElement' creates a collection of MediaElements that it then can have events and flags for for tracking state and each of these is a 'channel'. When you call SetSource the control looks for the first available channel to assigns the source. this actually creates like a quing mechinism that allows me to rapidly play sound effects without loosing one or having to wait for the control to have its mediaelement in a ready state and I don't need to have an army of media elements.

Also in WPF and Silverlight the usage can be then the same where I call SetSource and pass in a local uri path like this:




in this case make sure the item is a local 'resource' in the xap with the control. In any case check out on the crossfader codeplex project or the HackingSilverlight library.

Tuesday, June 23, 2009

Silverlight Tour In Seattle

Just thought I would drop a note about the up coming Silverlight tour in Seattle. Erik Mork is speaking in Sept 2-4th.


and more about Erik


Wednesday, June 17, 2009

Silverlight at an End... RIP

I was aghast when I saw this article...


don't get me wrong I think html 5 is great but there are so many wholes and are we really expecting all the browser's to get together and get it straight as to rendering behavior? not to mention all the nonsense about 'assumed' markup that browsers try to fix poorly formed markup. I mean really why not just use the SGML spec and call it good...

Any case with the coming trends towards UX and high touch I think the html 5 spec is too little to late for killing Silverlight and flash.

Tuesday, June 16, 2009

MVVM Silverlight

So this topic has been going around for some time about building MVVM Implmentations in Silverlight a couple of people I know are doing toolkits (surprise surprise WPF guys mostly) but here are two of my favorites include Michaels:


and Laurents:


any real dive into the topic should also include shawn's blog/posts starting with say this one http://wildermuth.com/2009/06/10/DevTeach_Silverlight_MVVM=Easy_Demo

In any case since I've been focusing on the composite apps as of late I'm going to work on something based on Michaels and get that posted.

Thursday, June 4, 2009

Setter Value Binding Helper

A great little Hack in Silverlight, kind of technical stuff for the beginner but a good thing to have down in your professional developer toolbox.


thanks to karim for this link.

More Simon the Saga

in this latest chapter of simon I have been trying to get 'Simon' to run in a scatterview control on surface to be more 'Surfacy'? [Sir - fa - see]? (new word?) In any case the code from Silverlight Simon to Surface Simon had to have even more hacks... Finally had to convert all the game pads to buttons, hack out the control template and create new event handlers for all 4 buttons. but alas Surface Simon is not available for Download off of codeplex at: http://Simon.codeplex.com/

Also to get around the sound issue with WPF... which I must say the fact that the media element is so lame in WPF as opposed to Silverlight is very very sad. Anyway I changed the PlaySound method of Simon to look like this:

#if Silverlight
Uri MediaItem = new Uri(SoundFile, UriKind.RelativeOrAbsolute);
SimonSounds.Source = MediaItem;
SimonSounds.AutoPlay = true;
MediaPlayer mplayer = new MediaPlayer();
mplayer.Open(new Uri(SoundFile, UriKind.Relative));

you'll note the use of precompiler specifiers and that we are not using the Xaml based media element in the WPF/Surface versions any more...

Tuesday, June 2, 2009

From Silverlight to WPF to Surface... the Saga...

Going from WPF to Surface turns out to be a bit more in the line of code changes expecially in XAML then going from Silverlight to WPF. WPF Simon will run straight up in/on Surface the problem is all the click events are castrated by the Surface Framework as Suface focus's on 'Contacts'. In order these are the kinds of changes I had to make to make 'Surface Simon' playable.

First we couldn't just reference WPF Simon to make the chagnes we needed so I had to copy the code base. Then started with converting the 'Simon' user control to a 'Surface User control' something to the effect of:

<s:SurfaceUserControl x:Class="Simon.Simon" xmlns:s="http://schemas.microsoft.com/surface/2008"

and in the code behind:

using Microsoft.Surface.Presentation.Controls;
using Microsoft.Surface.Presentation;


public partial class Simon : SurfaceUserControl

then next thing I needed todo was swap out the button controls with surface button controls so I could get the contact events like this:

<s:SurfaceButton x:Name="ScoresBtn" Click="ScoresBtnClick" ContactUp="ScoresBtnContactUp" Style="{StaticResource ScoresBtnStyle}" Height="41" Width="34" Content="" Canvas.Left="98.407" Canvas.Top="-6" />

note I could leave the click even there and the new 'ContactUp' event basically just calls the click event like this:

private void NewBtnContactUp(object sender, Microsoft.Surface.Presentation.ContactEventArgs e)
NewBtn_Click(sender, null);