Yesterday we hosted the second session of out WPF Workshop. We let the students work their way through the excellent lab described in my previous post. They got pretty excited about the possibilities of Blend even though its workings sometimes proves a tad complex.
There was a little discussion though about the applicability of WPF and its flashy interfaces for in the business application field. Why would a bank benefit from a flashy interface? What benefit would the eye-candy offer an insurance company?

I have to agree that for the backend-applications that are maintained by often well-trained and computer-minded people the added value wouldn't be enormous. However, most insurance companies f.i. deal with intermediates. These people would surely benefit from a better UI. In this case, looks are important, since they can increase usability, when carefully designed.

In an interesting session at the DevDays 2007 in Amsterdam, Mark Miller held an interesting lecture about the The Art of A Great UI. Allthough he didn't cover WPF-specific issues, the guidelines he mentions apply to all kinds of interfaces. Given the large freedom WPF gives to developers in terms of 'eye-candy' and 'flashy screens' we need to be cautious not to get carried away.
So, we could say, 'with great power comes great responsibility' and this should be our credo when designing the UI for our application!

Martin Grayson has created an excellent tutorial to get you started with Expression Blend. In this easy to follow step-by-step guide you're re-creating one of those swanky Vistalike Glass buttons:



Although the process requires you to step into the shoes of a designer and might seem overly complex if you've never worked with Flash, Photoshop or other graphics software, but the results are pretty cool.

If you want you can open up the project in Visual Studio afterwards and add f.i. an OnClick eventhandler. Afterwards you can reopen the project in Blend and the code still works! This provides awesome possibilities in collaboration terms.

I did notice a peculiar thing: if you open the Blend project for the first time in VS2008, the Conversion Wizard will popup. Then, when you try re-opening the solution in Blend and try to build it, you will not be able to. You need to create an alternative app.config for Blend itself in order to fix this. In the Blend readme you can find the contents for this file. After starting Blend with the config-file, things work like a charm!

For most people the term 'Device Independent Pixel' seems both confusing and misleading. If it's device independent, how can it be pixels? And, for those adventerous souls who started googling for answers the weird 1/96th of an inch seems ludicrous, especially if you are born in one of those civilized, metric part of the world. So, what's the deal with these device independent thingies?
well, 96 dpi is a default resolution for TFT-monitors, so this means that on that type of device, one of the most common ones around, a pixel IS a pixel, even in WPF.
Charles Petzold says in his bookblog:

In WPF, you always draw in units of 96 DPI. For example, if you want to create a one-inch square Rectangle object, you make it 96 units wide and 96 units high. If the program runs on a video display set at 96 DPI, the object will be drawn 96 pixels square.

This makes sense. A better explanation and excellent examples can be found at WPF Learning Experience where they conclude:

In conclusion, we’ve seen that WPF really is resolution independent as long as Windows display properties scale factor settings are properly taken into account. What WPF Resolution Independence really means that two monitors set to their native resolution and which are accurately reporting their DPI settings to WPF will display the same WPF window at the exact same size. Under those conditions a monitor with 96 physical pixels per inch will display any WPF window at the same size as a monitor which has 192 physical pixels per inch. The only difference between the two is that the latter monitor will look much sharper than the former.

Yesterday I piloted the WPF workshop I've set up for my compangy, Sogeti, together with Dennis Olsthoorn, one of my colleagues. I had planned for the seven students to actually get their feet wet in WPF by letting them do some of the excellent HOLs Microsoft supplies, but unfortunately, the software-gods had other plans. The virtual PC image we had prepared refused to run and my backup plan -install Visual C# Express 2008 on all machines- failed because the installer kept crashing :(
So, I ended up typing in a lot of code myself while the students were watching. Allthough there were a lot of questions and people were generally enthusiastic about WPF I still feel bad about the whole thing. Next week I hope we're able to get the software running properly!

One of the questions I got during the course was: "How can you access system specific settings, such as the current Window color?". This is easily achieved from code with:

this.Background = SystemColors.WindowBrush;

The SystemColors enum is accessible in XAML throug the x: namespace, using the x:Static markup extension:

Background="{x:Static SystemColors.WindowBrush}"

This will give the control the background-color the user has specified for his system (through Control Panel > Display -> Appearance.