dezineforce Proof of Concept Interview

Following on from my post yesterday about the dezineforce proof of concept, I spent a little more time with Peter Williams (dezineforce), Neil Kidd (Microsoft) and Josh Twist (Microsoft) quizzing them on various aspects of the project…

1. Tell me a little about dezineforce and the sorts of problems you’re trying to solve.

(PW) Dezineforce focuses on empowering design engineers to create better designs faster. To produce a good design engineers need to balance many different requirements; an engine must produce lots of power and yet be fuel efficient, it must be rugged and reliable yet lightweight and cost effective to manufacture. Dezineforce’s services enable engineers to systematically and efficiently explore different designs and understand the complex trade-offs that need to be made.

2. What’s been the typical approach to engineering design? How does dezineforce’s approach differ?

(PW) Typically an iterative and manually intensive process is used. A skilled engineer creates an initial design and schedules computer simulations to analyse its performance. The results of the analysis are then used by the engineer to modify the design and the new design simulated. This continues until the engineer is fully satisfied with the design or quite often until they run out of time or resources.

The dezineforce approach allows the engineer to provide a parameterised design and select from a number of workflows that will systematically simulate, analyse and adjust the design using advanced mathematical models in a process known as Design Search and Optimisation (DSO). This creates a body of knowledge that the engineer can use to make informed decisions.

3. You’ve just completed a proof of concept (PoC) exercise in the Microsoft Technology Centre. Tell us a little about that. What was the need for change? Where did you perceive that Microsoft could add value? What was the specific focus of the PoC?

(PW) In order to make decisions engineers need to quickly and effectively make sense of the large volumes of data that can be generated during an optimisation process. Our existing system made extensive use of AJAX to allow engineers to navigate and view this data, but we were reaching the practical limits of that technology. We thought it likely that Silverlight would enable us to take this to the next level and wanted to prove whether or not that was the case.

For the proof of concept we focused on a particular engineering problem, a filter, for which we already had all the output data. We looked at how we could use Silverlight to expose that data in a way that would enable the engineer to better explore and understand the design tradeoffs in order to better inform their decisions. We also looked at how Silverlight could be used to drive further analysis.

4. What were the most challenging aspects of the problem?

(NK) For me, the biggest challenge was understanding what the software was actually supposed to do! The dezineforce system is a very complex beast requiring a large amount of domain knowledge in engineering and mathematics. Trying to develop an intuitive user interface on an application you don’t fully understand is somewhat of a challenge. It sounds obvious, but making sure that the whole team understood the problem domain and the data we were going to be working with was my first priority. After this happens everyone becomes much more productive as they are able to take more responsibility for the bits of the application they are working on and make decisions independently.

5. Can you explain a little bit about the PoC process eg what precedes the PoC? What does the PoC look like? How big’s the team? Who’s in the team etc

(NK) An engagement in the MTC really consists of two things:

• A two day Architectural Design Session where we spend time understanding the customers requirement, working out what technology is appropriate, identifying any risks in adopting that technology and scoping out what the proof points are for the prototype we are going to build.
• A three week Proof of Concept. This is where we build the prototype we designed in the ADS. In between the ADS and the PoC we will have put together a team comprising of people from the customer, Microsoft and potentially from one or more Microsoft Partners. This ensures we have the technical skills in the room to do the work, but also ensures we have people from the customer to transfer any technical knowledge to. There is no point in handing over a prototype to the customer who has no experience with the technology or visibility of why design choices were mode – hence it is essential to have people from the customer working on the team.

In my mind one of the most important things here is to ensure that the Architect that ran the ADS also runs the PoC – taking responsibility for the delivery of the project is a great way to help ensure that you get the scope correct.

The size of the team depends on how big a problem we have bitten off, but we would typically look for 4-8 people. In the dezineforce PoC we had 3 developers from dezineforce, one Silverlight developer from a partner (DotNet Solutions) a Microsoft Application Development Consultant, 2 designers from a partner (Tricky Business) and the MTC Architect. This provided comprehensive converge of all the skills we needed from the design and creative side, client and server development and domain engineering knowledge.

6. What risks did you identify for the PoC?

(NK) Having worked on a number of Silverlight applications I was pretty sure the risks weren’t really from the technology side - I’ve seen enough Silverlight applications to have a great deal of confidence in the platform. The area I was most concerned with was ensuring that as we were going to have a lot of people working on a relatively small code base, we didn’t spend all our time tripping over one another. Ensuring that we picked the right architecture and tools to support this was pretty key to our success. In this case we chose to build the client using the Model-View View-Model (MVVM) pattern; this gave us a huge boost in productivity and really helped solve the problem of multiple people working on a small code base.

7. Which technologies did you identify as key to delivering a solution for dezineforce?

(NK) Silverlight 3 was due to be released during the PoC, so I decided that it should be stable enough for us to start work with and then migrate to the release version at launch. Silverlight 3 gave us a few new things that we couldn’t have done in version 2 (specifically with respect to data binding and writable bitmaps) and as such was worth the small risk.

The Visual Studio Tools for Silverlight 3 and Expression 3 were also stable enough so we adopted them.

Visual Studio 2008 is the obvious choice for the C# and services development. We created some WCF services talking to the SQL 2008 database and deployed it all on a Windows 2008 server.

8. You had a good mix of different skill sets in the project including a nice blend of developers and designers. Given the short timescales, how did you go about making this work from the off?

(NK) With the work that we do, the wire frames are the key. These consist of sketches of each screen in the application. They give us two main things;

· An understanding of these users navigation journey through the application

· Details of what data will be displayed on each screen.

We try to have the wire frames completed before the PoC starts – we print them on A3 sheets and stick them round the wall of the project room where everyone can see them. This allows us to get the customer to sign off the wire frames to ensure that we are about to build the right thing.

When the project starts the wire frames are the starting point, the designers can start working on the look and feel of each of the screen and the developers can be building the data model and view model to support the application. Having the wire frames ready before the PoC starts ensure that everyone can start work from day one.

Starting with the wire frames may not be suitable for every project (especially one with no UI ;-), but with short time scales they ensure that everyone in the team starts head in the same direction right from the start.

9. What is MVVM and what are its benefits?

(JT) MVVM stands for Model View ViewModel – it’s a presentation (UI) layer pattern that helps you separate the logic that controls your View from its visual layout. In this pattern we separate the code from the view (XAML and code-behind) and place it inside a new class, the ViewModel, that is a canonical representation of the presentation state of the application – a model of the view, if you will. MVVM is similar to the MVP (Model View Presenter) and MVC (Model View Controller) presentation layer patterns but aims to fully leverage WPF and Silverlight’s amazing data-binding capabilities.

10. What does it bring to a project such as this one?

(JT) Because the View and ViewModel are very loosely coupled, the ViewModel can easily be unit tested and the designer has total freedom to change how the application looks, constrained only by the basic conceptual UI exposed by the ViewModel. On this project this pattern actually created opportunities for enhancing the application – once we’d created the ViewModel, new and powerful ways of visualising the data became obvious that simply wouldn’t have transpired without this approach.

11. How does it help designers and developers work together?

(JT) This layer of abstraction provided by MVVM better supports the designer-developer workflow as designers can work on the View whilst a developer works on the ViewModel concurrently. To get started, the two roles simply have to agree on how they’ll model the view so that this contract can be agreed and implemented in the ViewModel.

12. What does it look like from a designer’s perspective?

(JT) Expression Blend 3 has a new Data tab that can help designers populate the ViewModel with sample data. Using this, a designer can see exactly how the UI will look when bound against an actual ViewModel but at design-time.

13. What about lookless controls as another enabler to the workflow?

(JT) Lookless controls are another great feature of WPF and Silverlight that give designers the freedom to change how standard controls look. For example, a designer can take a ListBox and change its appearance in any way they see fit. Again, these changes are abstracted from interactions with the controls in the view and designers are thus free to experiment and exercise total creative freedom over the look and feel of the application – without upsetting the developers on the project.

14. What types of controls did you use in the project?

(NK) We were able to make extensive use of the Silverlight toolkit; we saved a significant amount of dev time by being able to build on the controls that the toolkit provides. I was really impressed by how extensible the toolkits’ controls are. If you see a screenshot / view of the application, then you should be able to see a scatter chart, bar chart and line graph and composed into the Simulation panel – all of these controls are laid on to of one another, so it takes a moment to work out which is which. Other toolkit controls include the data grid (for the property panel) accordion and rating control.

Some of the controls were built from scratch the parallel axis chart and the range sliders were the biggest examples of custom controls.

The Image plot control is a ListBox with a custom layout panel – this uses all the functionality of the built in control and just provides its own Measure and Arrange functions.

The tile plot panel is a deep zoom control that uses a service to dynamically generate the image tiles.

We also use the Blacklight control library’s drag drop panel to have 4 resizable panels.

15. What were the decision points as to whether to re-skin, customise or build from scratch?

(NK) The preference always has to be in that order – prioritise the rout that has the least development effort. I’m not sure that there is a really a magic formula for this except you need to spend some time understanding what the control needs to do. Once you have your head round that you can compare it to the functionality offered you the existing controls. This is worth a investing a bit of time in as sometimes you find that what looked like a start from scratch control is just a re-skinning of one you already had. The best example of that would be our image plot control – this displays an image of a design at a specific X-Y coordinate based on values chosen by the user. We started of thinking that it would be a new control then quickly decided that we could use a ListBox and provide our own layout panel – far less effort. After we had written it, we realised that we could probably just have re-skinned the toolkit’s scatter chart – even less effort.

16. Did you build any rich controls from scratch?

(NK) Yes. The Parallel Axis chart was written from scratch.

17. Why was that necessary and how much effort did it take? Are you pleased with the results?

(NK) The parallel axis chart is a very domain specific data visualisation as such there really isn’t anything that we could have subverted to our needs. Initially we thought that we could have used a line chart, but digging more into the functionality of the PAC we realised that it is quite different from a line chart and we would be taking on a lot of risk in trying to bend the line chart to do this as it was never meant to.

18. Did anything unexpected come out of it?

(PW) I was pleasantly surprised by the amount of new ideas that the proof of concept sparked. It was a very creative environment in which everyone was inspired and able to contribute new ideas.

(NK) I was surprised by just how productive a team we were. The application we built is of higher quality than I would expect from a prototype. The main reasons for this were:

By getting the wire frames created before project started everyone was productive from day 1.

Picking the MVVM pattern for the client side architecture allowed us to perform the developer designer split very well – this is where devs and designers need to work on the same part of the application at the same time without overwriting each others changes. Having the logic and the UI in separate files, using TFS and making heavy use of data binding to our View Model ensure that things ran very smoothly.

19. Were there any other interesting technology aspects?

(PW) The Model-View-ViewModel (MVVM) pattern was a very interesting aspect of the proof of concept. Being able to learn and explore patterns for using the new technologies was as useful to us as finding out what the technologies themselves were capable of.

20. What was it like working with Microsoft and their partners?

(PW) The proof of concept team was first rate. The people that Microsoft and their partners provided were able to quickly understand our business needs and get their heads around our specific challenges. This meant the team was productive very quickly and able to make intelligent tradeoffs in what was a time boxed exercise.

21. What was the outcome? How did you demonstrate success (or otherwise)? How did your sponsors respond?

(PW) The output from the proof of concept was very well received by our internal stakeholders. It very quickly achieved the first goal of proving to ourselves that a heavy duty, data intensive, rich user experience could be built using Silverlight. With relatively little work we were then able to turn the output from the proof of concept into something we could demonstrate to our current customers in order to gain detailed feedback before investing the effort required to take it into full production. It helped us to clarify the way forward and provided a medium to stimulate customer feedback. It also inspired the entire team with what could be done.

Technorati Tags: dezineforce,silverlight,mvvm,mtc,poc,engineering,design,blacklight