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.
