Back from Portland Code Camp

ddietric — Mon, 01 Jun 2009 09:25:00 GMT

The Portland Code Camp yesterday was a blast. In fact, it was one of the best (un)conferences I've been to so far with a wide variety of topics and I'd like to share my personal Top 3 Best of Portland Code Camp 2009 (but keep in mind that that's 3 out of 5):

Patrick Cauldwell did a presentation titled Building Business Applications in Silverlight 3 which was a great introduction to what's new in Silverlight 3 for business application developers. He started by talking about what's already in Silverlight 2. His conclusion was that while the current version is a good platform for Rich Internet Applications implementing certain features is too much work. He then went on to talk about and demonstrate some of the new features in version 3 like navigation/deep linking and improved validation as well as the .NET RIA Services which are currently available as a preview.

Jason Kelly did an introduction to cloud computing focusing on two offerings which follow the utility computing model, Amazon EC2 and Microsoft Azure. After talking about the benefits and common usage patterns of cloud computing he compared EC2 and Azure in terms of the feature set and (dis)advantages of each platform. Jason also showed two versions of a simple application demonstrating how to use the Amazon and Microsoft cloud services. He has published his slides as well as the demo applications in a blog post (Portland Code Camp 2009 - Cloud Computing presentation).

The last session I attended was Brian Henderson's Implementing a Rich Interactive Application Design. The content was more general than the title suggests with many good tips on how to do good UI design and improve the user experience (UX) of your application. I highly recommend checking out the slides if you are developing applications without designers or UX engineers on your team and need some practical ideas that can help you deliver a better product; the slides can certainly not replace books or training but those two require time and money and who has those these days (unfortunately, the slides have not been uploaded yet but that should happen within the next day or two so keep checking the session page if they are still missing).

This posting is provided "AS IS" with no warranties, and confers no rights.

Reflections on MIX 08 part II: What's the secret Formula?

ddietric — Mon, 24 Mar 2008 12:03:49 GMT

One of the outstanding sessions I attended was What's the secret Formula? (PNL14). The panelists were (in alphabetical order):

Dan Harrelson - Senior Technologist, Adaptive Path LLC
Daniel Makoski - Microsoft Corporation
Jensen Harris - Principal Group Program Manager, Microsoft Corporation
Mike Schroepfer - Vice President of Engineering, Mozilla Corporation

The panel was moderated by Nishant Kothary who is a user experience evangelist at Microsoft. The list of panelists as well as the subtitle of the panel - A panel on designing stuff that rocks - promised a pretty user experience (UX) centric discussion. Fortunately they kept this implied promise and I found myself agreeing with most of the points made during the discussion. The following list is incomplete and by no means a transcript (meaning it is based on what was said during the panel discussion but the details are my take on the issues discussed by the panelists though you will notice quite a bit of overlap when watching the recording):

The ownership of UX must be shared by the whole product group
Sure, there are UX engineers who are the real experts and program managers usually care about UX as well. However, if developers do not care about UX when implementing features and testers do not look at the software under test beyond the specification the end result will most likely be suboptimal from a UX standpoint. To make things even worse the UX bugs that shouldn't have been there in there first place often have a lower priority than certain types of functional issues and the chance of getting the UX bugs fixed continually decreases as the ship date comes closer. That said there must be an understanding in a product team throughout the different roles that the idea of getting it right the first time applies to UX as well and that it's not enough for a feature to work in order to be of high quality as soon as a UI is involved.
There has to be one vision for the product
This is basically the limit to how much any individual can determine the UX and design for any given part of the software. Though the ownership and thus the responsibility for UX is shared the end result must be consistent in order to achieve a high overall quality. This suggests that there should be one vision and one set of design principles that everyone on the team believes in and - since there will be disagreements along the way - that a very small number of people should be in charge of making final calls on any decision if necessary so that at the end of the day the product looks like it was designed by one person although a large number of people contributed to make it happen.
Share user feedback with the developers
This goes for both negative and positive feedback. Negative feedback is important so developers (as well as testers and program managers) understand that some users will notice for example when UI elements are one pixel off even though the user may not be able to accurately express what the problem is (the user may just report that the affected UI "looks wrong"). Even more reason to take these issues seriously. Positive feedback is equally important. Jensen mentioned the example of the UI font for MS Office being changed and developers not understanding why since the new font wasn't that much different (at least from their point of view). But users did notice a difference (and again they might just say "I don't know what you did but it looks better") and sharing this feedback helps people in the technical roles to get a different perspective and be more open in the future.
Get continuous user feedback
Mike talked about how Mozilla has volunteers around the world testing the latest Firefox build every day and how it allows them to try new things and quickly get feedback. Now, obviously that doesn't work for every kind of software project. But getting user feedback throughout the development cycle to validate that you are on track and that changes and new features actually meet the needs of the customer leads to better products. For some projects this might be limited to beta releases other projects might have to resort to closed user groups under NDA but getting that feedback in early makes a difference so it's important to figure out which way of gathering feedback and how frequently works best for your project.
We are not the customer
I thought about typing this one in all caps but that would be rude. This is nevertheless a very important one. No matter if you are a developer, a program manager, a tester, a product manager, a designer or a user experience engineer (though UX engineers are usually very aware of this), no matter if you work for a global player or a startup, no matter if you work on a closed source or an open source project, you are not the customer! We use and think about software differently than everybody else and I'd say this is a pretty general rule with very, very few exceptions (and I can't even think of one right now - I just assume that there is one... there is always one). If you think about Microsoft Office it is probably obvious that the people who work on the product have a completely different point of view than the majority of end users. But even here in Microsoft's Developer Division this is true. Now you might think "you guys are developers, your customers are developers, what's the problem"? While we create IDEs, frameworks and controls for developers the majority of those developers create applications for end users who are not developers. That said, it is very important to figure out what the customers want - and it is a really good idea to have UX experts for that since customers often can't tell what exactly they need - and not to speculate what they want or even worse assume that they want what you want.
The first step of designing is a low-fidelity prototype
Let's work our way back to low-fidelity. It's tempting to do UI prototyping in a designer like Expression Blend or in Visual Studio. Those are the tools we know and they get the job done. But for prototyping they can actually be dangerous for a couple of reasons. For example they constrain you to whatever they are able to represent and they generate source code (if there is anyone out there who has never seen source labeled as "prototype" mysteriously becoming "product" code please leave a comment). The next step back is a graphics application like Expression Design or Photoshop but not everybody involved in the prototyping process knows how to use them which finally brings us to low-fidelity which can be done by anyone (even end users like your parents) at any time and is usually primitive enough for not having people get too attached to the prototype. I'm talking about any non-electronic method of drawing on a surface. Whiteboards, flip charts or simply a pen and a napkin if nothing else is available.

Again these are just a couple of points I thought were most noteworthy (which is of course completely subjective) and I really recommend watching the recording of the panel.

This posting is provided "AS IS" with no warranties, and confers no rights.

Happy Usability Day!

ddietric — Thu, 08 Nov 2007 21:05:00 GMT

Today is the World Usability Day 2007 and I'd like to encourage everyone to look into it especially of course the presentations given in the MS Conference Center throughout the day which are available online. So, why do I think this is important and why did I tag this post as a QA post? Because if you are serious about shipping high quality software you have to care about the user experience (UX). You can ship a virtually bug-free product which is mostly worthless at the same time because of poor usability. I don't suggest that QA should take over UX. But I firmly believe that one of the responsibilities of QA is to promote the idea of and need for UX activities throughout the product development cycle.

This posting is provided "AS IS" with no warranties, and confers no rights.

Dennis "D.C." Dietrich : User Experience

Back from Portland Code Camp

Reflections on MIX 08 part II: What's the secret Formula?

Happy Usability Day!