Learning lessons from game studios…

For the most part, .Net developers are continuing to use Visual Studio the same way they always have, even when it comes to creating new WPF solutions, but interesting enough quite a few developers that I have spoken to recently also now find themselves working with Expression Blend. Considering that the Visual Studio design surface struggles to render even the most basic of XAML in some cases, I guess I could understand developers using Blend, even if it is just to see what was going on in design time with their user interfaces.

I think it’s great that developers are trying Expression Blend and even better still if it gives developers more appreciation for the designer’s skills, as well as an open view on how beneficial a designers input into their solutions could be – for the most part I think that is me just being optimistic though. In reality the truth is more along the lines of ‘no other choice’ with the state of Visual Studio.

Back in 2001 I undertook an advanced Diploma course in 3D games design and development, to try to better understand the DirectX API’s from Microsoft, and it was during this process that I really became open to the idea of designers and developers working collaboratively to build a standard Windows application. I had never before been involved in a process where designers had any input at all; usually they were given instructions on what to create, not being asked “how should it be created?”

The 4-10 person groups in the course were mentored by game companies, which meant that designers and developers collectively were involved in the brainstorming and storyboarding of a game, working together to understand each others requirements and implement them without differing interpretation. Everything from the loading screens, right the way through the instructional routines, menus and of course character and game play. The designers had their tools in 3D modelling programs like 3D Studio Max and Maya etc, graphic assets were developed with Adobe products and the developers had their tool which was (and still is mostly) Visual Studio to code up in C++.

When I returned to my day job, the same old scenario would continue to take place. An idea for a product would be conceived by upper management and then it would slowly but surely make its way down to the code monkeys to implement – not once was an interactive designer consulted on the pending applications projected runtime end user experience, because lets face it, the standard controls looked the same pretty much all the time, and the functionality of the ending application was always directly related to the control features that were used.

And so around and around the endless cycle of “not getting it right” would continue.

The primary reason for this was the lack of integrated tooling. Getting a designer to work in Visual Studio was never going to happen, and rightfully so. Also, let’s face it, anyone could drag and drop a control onto a design surface and the only modification from there was pretty much little things like background colour etc and no one really thought they needed a designer to do that.

But what about todays development practices?

The tools are now here, designers have thier tools and developers can use them as well - all outputting an understood syntax that .Net eats up. XAML.

Windows applications can finally be built along the same winning processes that game studios work with - a proven method of collaborative design and development.

What ever the reasons may be, there certainly is very little excuse to let it continue. The tools are now here, so I guess it is just the attitudes that need to change.

So what do you need to do?

Get an interactive designer and graphic designer involved in your development lifecycle (preferably one that has an understanding of WPF) even if it is just for a pilot. Work out the process of delivery of inception through implementation.

If it’s done right, your application(s) will

  • look better
  • work better
  • encourage more people to keep using your application
  • ultimately be faster to deliver to your market.
  • Sound like good enough reasons to try it?

    Yes I know what you are going to say next… “It’s easier said then done” and you would be right, so the next few blog posts are going to be about how I go about implementing the process into development teams of any size.

    ITWorld DealPost: The best in tech deals and discounts.
    Shop Tech Products at Amazon