Reflections on Tech-Ed 2007 - Part 2

There was obviously more to Tech-Ed than the excellent keynote mentioned in the previous post. As I stated earlier, the sessions made up bulk of the conference, and there were some definite highlights among the sessions I attended.

Here are the highlights, ordered from the high-level to the technical:

• ARC306 – Interface Design Patterns
• DEV309 – Best Practices for Team-based Development
• ARC302 –TDD Meets MVP
• DEV313 – LINQ Deep Dive
• CON206 – Custom Activities in Windows Workflow Foundation

These sessions will be discussed in the remaining posts within this series, starting with ARC306 below. The presentation slides can be downloaded from the Tech-Ed website, with the exception of DEV309 – which can be downloaded from Lukas Svoboda’s blog.

ARC306 – Interface Design Patterns

Following on from the theme of the keynote, this session provided numerous points to consider when designing and building applications. The central focus covered the cloud of related concepts such as interaction design, usability, human factors, HCI and UI engineering. The presenter, Darryl Chantry, delivered an engaging and entertaining presentation on these topics, punctuated with interesting videos of these concepts in action.

Here are some key points:

• Be multi-disciplinary. By developing a wider skill set (beyond the mechanics of programming software), software developers can more effectively convey information and therefore satisfy the needs of users better. Darryl displayed a diagram to demonstrate this – a full-colour artistic rendering of a cross-section of the human head, depicting an aneurysm. The extraordinary thing is that this was hand-drawn by a neurosurgeon. Not only did this neurosurgeon have the medical skills and knowledge to understand aneurysms, he/she also had the artistic skills to render this in a way that effectively communicates this specialist medical knowledge to anyone outside their profession.
• Good design is invisible. By human nature, people take things for granted when they work as expected, but actively notice or complain if something is wrong. Therefore a good way to assess how good a design is, is to ask ‘What could cripple usability?’ ‘What’s slowing me down [as a user]?’ Design can be improved by removing these obstacles, but it takes skill to identify these obstacles in the first place.
• Users want to be in control. If software does things that are unexpected, users won’t trust it. Their expectations are based on what is familiar to them and fits a particular pattern. This also presents a paradox: that software can be designed to be so simple to use that it’s revolutionary, yet by its revolutionary nature it becomes unfamiliar for users (e.g. if the standard control types aren’t used).

Just as interfaces in C# or Java provide a contract between a caller and a class that implements the interface, the user interface provides a contract between the software and the user. When using the software, the UI declares, “Under these circumstances, this is what I’ll do,” to the user, who interacts based on the contract. If clicking a certain button causes some extra things to happen that are behind the user’s back (let alone unexpected), or leaves out another action, then that contract is broken and so is the user’s trust.