XamlXaml.com

See the image above? That’s an actual screenshot of the PostItBoard WPF example I’ve been working on. This application attempts to make good use of a non-standard interfaces to provide a rich UX (user experience). It takes a keyword(s), grabs images off of Flickr.com which match those keywords, and displays the photos on the cork board. The images can be moved around the cork board and additional layers of images can be added/removed. As you move your mouse over an image, information on that photo is displayed on the post-it note.

One aspect I focused on for this app is to minimize my input interface while maximizing functionality. I was discussing this with my colleague, Beth Massi, the other day and she suggested using gestures. Great idea! While gestures and gesture recognition is typically the domain of tablet pcs, they are appearing more often in apps made for non-tablets too. To integrate gesture recognition I overlayed an InkCanvas onto the details PostIt note and bubbled up the recognized gestures to the main window. So, if you have 3 layers of images on your cork board you can discard the top layer by issuing a down chevron gesture on the details PostIt with your mouse or a stylus. To clear all photos, make an O gesture. To increase/decrease the size of all the images make a greater-than/less-than gestures. To increase/decrease the number of photos pulled per layer use up/down gestures. Gestures seem to be an effective way to add functionality without having to add interface elements.

Also of note is that the app uses a transparent window, which allows post-its and pics to hang off the edge of the cork board. While this looks visually compelling, I’m not sure the additional CPU requirements would justify the use of a transparent window in this type of app in a production environment.

From a GUI design point-of-view things are pretty straightforward. I’ve created three custom usercontrols: SnapShot, SnapShotQuery, and SnapShotDetails. The SnapShot control takes care of displaying pics and storing information about those pics. The SnapShotQuery gathers information on the type of pics you want to see and uses a RoutedEvent to bubble this information up to the main window. The SnapShotDetails provides a canvas to display additional information about the pic.

The C# code side of things is fairly standard too, with a few exceptions. First, trying to get a group of photos to either not overlap at all or overlap in the least amount was a bit of fun. Luckily the Rectangle object has some limited hit testing built into it. Second, although the initial code to be able to drag the pics around the cork board was straightforward, once I started allowing the pics to be resized it became problematical. I still haven’t worked out this bug, but it seems as if the transformation which changes the size of the pics is changing the visual representation of the objects but not the physical representation. So, while it may look like the pic has been changed from 75×75px to a 120×120px, method calls are still returning info related to the original 75×75 size.

That’s it for now. I’ll have the full demo along with code snippets up next week…apologies folks. I’m traveling right now and don’t have access to my dev environment

-MGE

Some of you may know me from my blog over at mgemmons.com. While I will still be using that space for general topics I find of interest to me and an occasional rant, xamlxaml will be focused specifically on the Microsoft .NET 3.0 Windows Presentation Foundation and XAML.

Why the move toward blogging about a specific technology? I believe WPF represents a great stride forward for software developers and architects. Our mantra has always been, “Extract the UI from the business logic, extract the UI from the business logic…” Unfortunately, while we may be much better off than we were 10 years ago, we’ve never really come close to that ideal…until WPF.

Think about it-developers generally aren’t good at creating effective user interfaces and designers generally aren’t good at coding functionality. So, in a perfect world we would have graphics designers design our user-interfaces and developers design the functionality behind that interface. We come nowhere close to that today. Oh, once in a while we may work closely with graphics designers to try to create an interface for our application, but what that really involves is the designer creating a mach-up in Illustrator or other graphics package, sending us a screenshot of that mach-up and us trying to implement it as best we can. To acerbate the situation, there isn’t a whole lot of “design” that can be developed into an application. Sure, we can change the color scheme, fonts, and how our controls are laid out…these are all important considerations in creating an effective application, but one windows application looks pretty much like every other because we have little choice about how control are rendered-how they look, how they interact with each other and the data they are associated with.

With WPF, for the first time there is the opportunity for real effective communication between the designer and the developer. A designer can create a user interface in their native tools such as Illustrator, export that to XAML and have the developer hook up the logic for the interface. Not just a mach-up for the interface, the actual interface the designer created. This is the great draw WPF has for me. To be able to integrate good design with good development can only make our applications better.

This space will be an exploration of just how we can make our applications better using WPF. I’ll pass along my ideas, insights, and plenty of WPF examples. Come along on this ride with me and let’s see what we shall see.

Michael G. Emmons