Thursday, November 26, 2009

Making an Integrator

There are still a lot of names for it but I’m going with ‘Integrator.’ I’m not sure exactly who coined this but I tend to like it. But what is an Integrator? At least in the context of the WPF/Silverlight world an Integrator tends to be some one that sits between a design team and the developer team at least initially when a company first gets someone to fill the integrator role. In the long term the Integrator becomes more the designer as part of an integrated team where there is not a design team or a developer team and we get into this Agile sort of cross discipline team that is building better UX faster in order of magnitude then anything before. There are lots of things that have come together of the past few decades to make this kind of team possible. We are going to focus on the Integrator but let take a quick look at the cross discipline team that the integrator role tends to move teams towards.

The New UX team tends to be on one spectrum a developer that can do dev work in the data base, in the web services space and then into the .NET and WPF. This developer might be a software architect with expanded data modeling an application modeling etc but tends to also be able to do some light reasonable UI and knows what good design looks like. The next team member might be an IA or Information Architect. Granted the Software Architect might have some IA skills and if so might even be a UX Architect. So the IA helps make sure the data and the flow of the IA in the IA are solid on the up take for the team but on the end the IA is making sure the user experience is good and doing user testing and other interfacing with users to make sure what they see makes since and works well.

From IA we start to get into the Integrator role, the Integrator will have a sound understanding of IA, UX and be able to write code but most importantly they are able to visually decompose what they see into Xaml and do design and design integration. Going Past the Integrator is the pure designer then might live in more disconnected tools. But as a team evolves into this sort of zen state each role including the dev’s, the IA, the architects, the designers and integrators tend to take on some of the skills of all the others. When everyone can do a little bit of everything the team is able to functional more tightly than ever before using some version of Agile and WPF/Silverlight todo more better and faster than before. It is even possible to take this even further and bring in the PM (Project Manager) to be able to work with customers and take on much of the skills of the IA.

In a way the Integrator can become kind of a seed that when planted in the fertile soil of a dev team that loves design and a design team that loves to see their hot designs alive over time turns the team into a UX monster (in a good way). Here is where we see the best innovation and the hottest UX (User eXperiences) at least in my experience.

Integrators are not born though they have to be grown (again in my experience). Now we get to the point of the article… how do you grow, build or otherwise make and Integrator?
So there seems to be two kinds of coal for building the integrator: The Designer and The Developer. In either case there are good points and bad points about each kind of ‘coal’…
For the Developer (especially/mainly the WPF/Silverlight developer) the good points are if they are already comfortable with Xaml and building WPF/Silverlight applications jumping into blend and becoming technically proficient is relatively straight forward but on the downside… if a developer doesn’t have any design sense at all… really give up now before you hurt someone. The hardest part of making a rock star integrator is getting a design sense, point 8 Helvetica is NOT the same as point 9 Ariel and if there is a question over it then you need to start again. Ok so we then make a huge assumption that you have some design sense. How do you cultivate it? Well ideally working in blend with some hot designers (and no this does not mean ‘hot’ looking although that is good too). But here is a good reading list for the dev aspiring ‘Design Integrator’

• Presentation Zen (really you must stop making crappy slides)

• A Whole New Mind by Daniel Pink

• Foundation Expression Blend 3 with Silverlight By Victor Gaudioso ( )

• Neuro Web Design – What makes them click? by Weinschenk

• Information Architecture by Wodtike and Govella

• MVVM for tards ( )

• Foundation Silverlight 3 Animation by Jeff Paries

Once you get this or in the process of getting this along with working with a designer is learning how to talk to designers. More than any other thing is team dynamics and team dynamics is primarily about good communication. Outside of the basics of good communication is when coming from the dev world to the design world you need to get in touch with the vernacular as much as possible. Working with designers you can get it from osmosis to some degree assuming you don’t piss them off, part of this means that when you talk to designers about changing their process understand that you probably don’t understand their world and that you can’t be condescending with really you probably don’t know what you are talking about when it comes to design. As an example designer typically don’t’ name and group elements in the same way that a dev is going to need them. When you talk to designers about naming conventions you need to be nice and explain why you need their help to have things grouped and named in the assets even from Photoshop and Illustrator.

What about making a designer into an integrator?

In this case the biggest problem tends to be getting past the normal design tools to looking at Xaml at times, wiring up a basic event and some basic code. Understanding the basics of how to work with dev’s is secondary to getting the new design integrator up to speed. While the designer brings the most critical skill to the Integrator role (being a design sense) they have a huge learning curve to wrap their mind around Xaml and Code. While a designer doesn’t need to code an Integrator needs too at least a bit. Much like the dev needing to understand design at a certain level the same goes for the designer to understand some coding in the context of Xaml and Visual Studio.

So how do you get a Designer to be able to write a method in Visual Studio? I would say to start with the most obvious and that is blend. The designer has to be interested in being an Integrator. If the designer is not passionate about learning to make their designs real then they are going to have a hard time. Starting with Blend the tool is designed to at least on some level be straight forward for designers and for starters they can focus on the WYSIWYG. For example all the short cut key codes are the same or mostly the same as Photoshop and the tool is great for doing WYSIWYG sort of ‘design’ but the native format is Xaml. Once the designer gets to the point of being limited then introducing Xaml to the designer is a great next step. So building on this to being able to wire up and event in code and launching in VSTS is about the limit. Here is where the sweet spot kind of happens and this like the dev being an integrator works best when it is a composite designer developer team.

From a learning standpoint the reading list might be:

• Foundation Silverlight 3 Animation by Jeff Peries

• Foundation Expression Blend 3 with Silverlight By Victor Gaudioso ( )

• MVVM for tards ( )
• A Whole New Mind by Daniel Pink

• Neuro Web Design – What makes them click? by Weinschenk

• Information Architecture by Wodtike and Govella

So let us go back to what is an Integrator?

The Integrator needs to appreciate design and to do good design and recognize good design. An Integrator needs to be able to be able to visually decompose a design and build it in Blend as Xaml. An Integrator needs to learn how to talk to designers and developers and be able understand the needs of both. Dev’s need names, designers need design time data and that sort of thing. Most of all the Integrator needs to help facilitate the communication dynamic between design and development and that is what makes the magic juice you see in some of the high end UX companies building on the Microsoft Stack.

Lastly one of the key aspects of getting companies to buy off on supporting the transition from traditional approaches to composite teams (of designers, developers and integrators and IA’s and anyone else we can get our hands) is ROI for better UX. Companies need to see how better UX can increase productivity, increase sales and user satisfaction and more. And they need to see how the composite team using designers, developers and integrators using the Microsoft WPF/Silverlight stack (Xaml, .NET 4, Visual Studio, Expression Suite) saves development costs, time to market and enable the better UX in general. That is the job of the integrator…

Tuesday, November 24, 2009

Silverlight and Dual Screen Monitors...

So I'm working on this dual screen kiosk thing and want to use Silverlight as for some reason I can't use WPF / .net4 etc. long story and not the point. What do I do now?

Well along time ago in a galaxy mostly still down the street I used do alot of 'dhtml' or ajax kinds of things or whatever we are calling it now days and there was this little thing called an hta you could do to get around all that silly security stuff in the browser that keeps you from nuking the hard drive, and file system access etc.

So the trick I found is to have the hta host the Silverlight app and have it resize its self to take up all the monitors. with a third monitor hidden in the kiosk... poof, Silverlight dual screen full screen black magic.

for those interested in hta's:

basically you want the following properties set on the hta tag in the html header:


and then on load on the body tag execute the following:


which could be a function of
window.screen.availWidth and or window.screen.availHeight

see black ecma magic saves the day.