I was one of the lucky speakers at Øredev, a developer conference in the Malmö/Copenhagen region where I live and work. The subject for this particular seminar happened to be .NET and Windows Presentation Foundation (though the name Avalon has stuck) and I talked together with a colleague of mine. However the issue of this blog-entry will not be the seminar in itself but the usability of such.I see usability in almost every detail, and though it seems far fetched there is usability in talking to an audience as well. Some of the basic usability rules still apply; know your users, always give an escape route and don't leave them confused. I'll try to focus on these three issues of usability.Starting with the users. Being a developer you manly deal with exceptions, special issues and border cases (no I don't mean borderline cases, though there might be a great deal of those in the developer community). When it comes to usability you are allowed to do the complete opposite, or actually you are obligated to. Generalize to your hearts content and use stereotypes, never try to cover all special cases. This is the real fun part and you get to be politically incorrect. To give you an example: You know developers are not female and they are anti-social. They are impatient and just love technology for the technology itself, not what they can do for humanity.Is that hard on them? Try to come up with Bob the developer yourself, make him plausible, take a few of your fellow developers around you and derive Bobby from what you see. It probably won't be a woman with social skills, a real knock out that are dying for pizza while playing a good game of Unreal. Creating fictive persons like this is a powerful usability tool and each description is called a persona. It’s like creating a user caricature.Moving on to the the escape route. Well, as you can imagine there were no problem there. They were clearly marked with exit signs. Anyone should be able to get out of there, had we been nauseatingly boring.The third part confusion is harder. Well, not causing it but to avoid it. Doing our outline there were this feeling that we should aim the seminar to what the audience would expecting: slides with facts concerning WPF. (Ahhh, a new acronym to add to the Great Acronym Collection, aka GAC…).However, the fact that what users expect and what they say they want is not the same thing as what they need. As you can imagine facts and figures concerning WPF can be found googling for a few minutes. Well, we are developers our self and focusing on the impact on development that we believe WPF will have, was an approach we could live with.In the end it got a different structure than first imagined, being two speakers we made it into dialog which hopefully was more fun listening to. The interactivity part was easily managed; just raise a hand and talk, one of the most powerful user interfaces. The structure was the good old report thing: Problem, execution, result and summary. Slides were kept to a minimum, just acting as a visual aid. The performance was also coached by Anki Nilsson who did a great job on focusing our efforts and boosting our self confidence.<