The Gu has spoken! Silverlight 3 is shipped!

  • William Dasilva
  • June 10, 2009
  • http://weblogs.asp.net/scottgu/archive/2009/07/10/silverlight-3-released.aspx

    This is a great release… something MSFT should really be proud of and a real enabler for amazing experiences across multiple platforms.

    I am just finishing up my first v1 of an SL3 project that we have been building on beta bits and the experience has been great. Its not so hard to be a WPF guy in Silverlight anymore.

    So ya wanna be an “Integrator” huh?

  • William Dasilva
  • May 13, 2009
  • Got an email this morning from one of our talented designers who has a ton of Flash/Flex experience and is interested in joining our “UX Integration” team. He wanted to know what was the most important stuff to be learning.

    A bit of background, at IdentityMine we have 4 major roles contributor roles in the app development process. Information Architects, Designers, Integrators, and Developers.

    The UX integrator is the guy who sits between the Developer and Designer and can talk both languages ( design “geek” and developer “nerd” ). Unfortunately as of late this has been called the “Devigner” or “Deseloper”. Both don’t really work for me on my business card and since I lost the arm wrestle to get my title to be “User Experience Ninja”, the title User Experience Integration Developer or User Experience Integration Designer is what stuck.

    Along the axis of the skills spectrum from Creative Designer > Technical Designer > Creative Developer > Technical Developer, the Integration Designer is the Technical Designer and the Integration Developer is the Creative Developer.

    A UX Integration Designer typical comes from a design background and knows some code (enough to be really dangerous). These cats are usually the best candidates for facilitating workflows in a Designer to Developer Direction. Meaning they can take design assets from the standards in the industry and convert those to XAML or functioning Expression Blend projects.

    A UX Integration Developer is the dude (or dudette) who usually has a Compute Science background but has a strong empathy for users and a passion for good user experiences. (Coincidentally this is pretty much the criteria for working at IdentityMine… Love your software! ) This person excels in the Developer to Designer communication. In other words this is the guy who knows how to take Dev created UI and make it beautiful.

    On the UX Integration team each role strives to get better at what they are good at and to aim for the other side of the spectrum. An Integration Developer should want to be a better Integration Designer and should be learning those tasks. And vice versa.

    Ok enough already… So what did I tell the designer who wanted to know what to learn to become an Integrator?

    1.) Start to gain a holistic understanding of the platforms… Know the feature set and be ready to see where the dots connect when you are looking at solutions.. (Designers are typically connecting the dots without this context and it’s a huge shortcoming). Try to discover every control in both Silverlight and WPF that you have never used before… They are all there for a reason because some customer wanted them… usually we end up working with those customers at some point and knowing about these controls is an ace up your sleeve. Knowing about Flow Documents and Annotations might not be something you use today… But if you know it tomorrow you are ready.

    2.) Once you know of all the controls in the platform the next step is learn to “style” them. This means learning to do simple styling as well as deep “templating” where you completely reconstruct the visuals. Its really important to get your head around the concept of “lookless controls” it’s the magic of WPF/Silverlight and basically means that a control has functionality but not visuals… so that any visuals can be mapped to that functionality later on. The goal of learning to style the controls is to get you to a point where you can see a control and confidently say I can style that one… For example scrollviewer is complicated… it usually takes a day to learn how to style it the first time… The next time… about an hour.

    3.) Start exploring different workflows from designers and IAs and Devs… This means to be ready to accept a handoff from these folks in a myriad of different ways… The key is to learn to be flexible. Everybody works in different ways and I’ve found more success in just accepting people’s hand off as is and providing key tips to those people rather than getting frustrated and expecting those assets to come “just the way you like them”.

    4.) Learn to prototype fast… A key to our position is our ability to communicate interactive ideas really fast… These are the ideas that don’t communicate well on paper or in static mediums… As well 25 cent usability is our secret sauce. If you can test something out really quickly against real people and against “real” data you will be able to make alterations to the user experience on the fly that correct mistakes that are made at the envisioning stage.

    5.) Learn from the other guys There is so much great thinking happening in the Adobe/Apple camps that it would be a tragedy to unplug from those worlds. Without being cliché lets do what they do and learn from their mistakes… It’s incredibly valuable to not reinvent the world.

    6.) Of course learn your tools and learn the syntax.
    Tools 
    – Learn Blend… Learn it like a hammer… You don’t build a house with only a hammer… But you can’t build a house without one. The point behind tools is to be able to do things you couldn’t do before, and do things you could do before faster. Don’t expect your tool to be a silver bullet or holy grail.  Once you accept that you will realize how amazing Blend is… warts and all.  I crash Blend all the time and it never bugs me… Crashes usually make designers write Blend off as a tool. Don’t go there.
    Code - (as in C#) is probably not as important as learning markup (XAML) is. But I still stand firm that learning code and XAML is akin to Michelangelo learning the technologies behind paint and marble… Had he not figured these things out he would not have had a lasting impact.

    7.) Try to understand the concepts of different patterns like MVVM 
    This will give you a greater understanding of why apps are architected the way they are from the development side and give you some expectations.

    8.) Learn to make decisions and measure success by asking yourself if you or your audience will “Love their software”?
    If the answer is no start over again or keep iterating. Look for holes and incompleteness or hard edges in the experience. Try to soften the hard edges and fill in the holes. Learn how to simplify things by being more explicit or via reduction. This is the true value add of the integration role. (It’s also the hardest to define and learn)

    http://www.emethod.ca/calgary-seo/

    Dinner with Dr. WPF (another witness)

  • William Dasilva
  • October 30, 2008
  • Walt and Josh blogged about it. It would be wrong of me not to.

    Dinner with the disciples last night was great…

    …a bit uncomfortable since most people were visibly awestruck by the doctor’s presence at our table.

    I think its important to say that I feel like the doctor isn’t a bad guy. It just appears like he is the prototypical evil eccentric mastermind when we breaks into a loud “mooo hooo hooo ah a ahhhhh” (I did however hear that he is wanted in peru for kicking a llama and he conceived his first child at the age of six on a subway in a cloning experiment gone awry but I digress).

    It was actually a night to remember. A life changing night. I will always remember the doctor’s powerful voice as he explained to us the importance of “oslo” and “m” and modeling saying, “From now on you will always measure life’s achievements as life before this asparagus and life after this asparagus.” It was truly life changing asparagus.

    It was when the doctor told me I should be getting my Crack online and that “it was good quality stuff” that I realized that he really did care. His cold maniacal exterior was really just a visual style applied to his lookless control. Really he is a man of many dependency properties. His commands might have too many parameters but he is a great resource dictionary to hang out with at your next routed event.

    Dr. WPF I look forward to having dinner with you at PDC 09