As we gear up for the PDC, we’ve been spending a lot of time thinking about how to effectively communicate with a large group about the technologies we’ve been working on. This isn’t just turning on the marketing engine or finding our inner-wordsmith. It’s about condensing a lot of information and wanting to do so effectively.

Along those lines, I’ve been thinking about the best terminology to use to describe the process of using of control styles to change the look and feel of an app. Here’s my take so far:

Around here, we generally say that “theming” refers to the system theme and “skinning” refers to changes to a specific app. This has helped to clarify our internal communication.

That said, I don’t like the idea of “skinning” because it has a cheap connotation. It implies that you can just dress up a UI with a new look and add value. I guess the app might look better, but it undermines the real power of control styling.

The terminology I prefer is “customized visuals” or “customized control visuals.” I think that this connotes the power that WPF gives you to own the user experience. On the other hand, it’s wordy and definitely not catchy and no one immediately gets this like they do theming or skinning.

So that’s the conundrum. Other suggestions? Maybe something with “chrome” (custom chrome, custom application chrome, rechrome?). Not crazy about those either. If you have thoughts, please share them. Right now I’m inclined to revisit the term “theming,” maybe break it down into: application theming and system theming to clarify the context.

I’ve been playing with Flickr’s public API a little and I’m impressed. It’s pretty slick. Here’s a .NET wrapper.

In poking around, I’ve come across some really cool stuff that people have done with the API. My favorite of which is an app that blends fifty randomly selected images which share a common tag. The results are really intriguing. Here is a set posted on Flickr by the app author.

 Big thanks to Darius and Valentin for there help with the backport.  As far as I know, all styles now work with Beta1 bits.  I’ve created a page to keep track of progress on SimpleStyles, or you can download the update directly here.   Please let me know if you come accross bugs.

[UPDATE] Just posted an updated version with the offending controls commented out.  If anyone has time to backport the missing controls (ComboBox, Menu, TextBox) please email them my way.  Thanks to a number of you who found the errors. 

[PREVIOUS POST] An FYI that the Simple Styles I posted earlier are not working with public Beta1.  They were originally targeted at an internal build and then back ported.  Apparently my backporting was less successful than I thought.  I’ll have an updated version posted as soon as possible.  Thanks to Don and Valentin for taking to test and even debug the current styles.

I just discovered this word today. I love it. Believe it or not, the term actually came in a conversation about UI guidelines. I proposed the idea of hero elements—elements which motivate the functionality or purpose of the app. Everett, the writer I was working with called these moments in the app the app’s McGuffins.

Okay, so I’m not sure that it’s a perfect analog, at least not the way I originally understood the analogy. It’s a great word though, and there application to UI. A user experience is motivated by a task which is probably made up of a series of steps. Think of these steps as the story of the app. There are elements in the UI which motivate that story, even if they don’t directly contribute to it, the McGuffins.

Here’s an example: the desaturation of the desktop when you change themes in XP. Windows could just freeze up for a moment or give you an hourglass. The desaturated desktop, however, tells the story in a way that the hourglass can’t. It’s a “plot element…that catches the viewer’s attention or drives the logic or action of the plot.”

Is this a stretch of the term? Probably.

Just saw a post from Karsten about reverse engineering the default Avalon, err WPF control styles.  This technique for digging into the styles is clever (and useful), but has a couple of drawbacks.

Theme-specific Resources

First, keep in mind that WPF gets the default control styles from a default resource dictionary associated with the current theme.  You can see the assemblies that contain these—they’ll be in the same directory as PresentationFramework.dll (and named something like PresentationFramework.Luna.dll).  Here’s the imporant part: control styles in that resource dictionary may depend on other resources defined in that resource dictionary, and there is no guarantee that these resources will exist accross all themes.

This means that you can’t take a dependency on these resources.  We see people doing this from time to time and it has the potential to break your app when run under a different theme.  We’re looking into ways of further obfuscating these, but you will definitely uncover them using the technique that Karsten described.

Overly Complex Styles

Second, the default styles were built to look just like the system controls.  This introduces a certain amount of complexity into the styles that might obscure what’s really going on.  At first glance, it can be hard to know which parts of the style are important.  To familiarize yourself with the fundamentals of control styling, you may have better luck with the Simple Styles.

I just added the PDC badge to the sidebar.  I’m giving a talk at the PDC this year called Beautiful Code, Beautiful Design - Applications Your Designers Can Work With.  I’m really not crazy about the name.  Inspiration, however, has been slow on this one.  It may be too late to make changes, but please let me know if you have suggestions. 

The content, on other hand, is super compelling.  That’s important, I suppose, that I find the content of my own talk super compelling.  The talk will be pretty true to the abstract.  I’ll be talking about styling: resources, styles, templates, triggers, storyboards, etc. 

Getting the content together is a lot of work.  I’ve been focusing on the demo first so that the demo drives the rest of the content.  When I’ve done things in reverse order in the past, the demo ends up feeling contrived and hard to talk to.

I’ve also been helping other people on the team with their talks.  Actually, help may imply more than I’ve done.  More like listen.  We do a lot of this—bounce ideas off each other to make sure we’re presenting things in a way that makes sense.  So far the content is really coming together.  Expect compelling content this year and good insight from the speakers.  The platform has really matured since the last PDC two years ago and I’ve been really impressed with the depth and quality of the talks so far.

Other bloggers giving talks are: Kevin, Chris, Henry, Lauren, Nick, Fil, and Rob.

Control templating in Avalon is super powerful, but can be tough to get right.  There is a lot of minutae to keep track of to build a control template that works correctly.  This is especially true for some of the more complex controls (like Menu or ComboBox).

In an attempt, then, to give you a better starting point, I’ve put together a handful of “simple” styles.  Simple for two reasons: first is a simple design aesthetic—these are designed with the idea that they are a base for your own design kung-fu.  They are also simple in implementatio—I’ve minimized the unnecessary goo so it should be easier to see what’s going on. 

You can get them here.  Right now, I’ve only tackled the most common controls.  More will be coming though.  Chime in if you have requests.