In WPF there are Panels that get used often: the Canvas, DockPanel, Grid, StackPanel, and even the WrapPanel. These Panels feel a lot of love. The UniformGrid, not so much. While most Panels are displayed proudly in System.Windows.Controls, the UniformGrid has been pushed into the Primitives namespace along side the TabPanel and the ToolBarPanel, both of which are too specialized to be given any real attention.

The UniformGrid is a great Panel to keep in mind. Once you do you’ll use it more often than you think. It does what the name implies, it lays out its children in a grid with uniform cells. You can specify neither the Rows or Columns, in which case it creates a square grid (3 x 3, 4 x 4, etc). You can specify either Rows or Columns, in which case it forces that number of cells in the given direction. For example, specifying 2 columns and providing six children would result in a 2w x 3h grid, providing one child would result in a 2w x 1h grid. Finally, you can specify both Rows and Columns, creating a grid of a fixed size. If you specify both Rows and Columns and provide more children than there are cells then the extra children will not be displayed. Finally, by placing the UniformGrid in a ScrollViewer and binding the size of the UniformGrid to a multiple of the actual size of it’s parent, you can achieve some great results.

Here are some of my common uses for the UniformGrid:

• Laying out icons in a uniform way (think of the iPhone home screen)
• Photo or video galleries where every item should be the same size
• Specifying Rows=”1″ and providing only two children for side by side comparisons
• Even spacing of children with a fixed size
• Using it as a uniform StackPanel by specifying either Rows=”1″ or Columns=”1″
• A quick way to layout controls, such as in a sandbox application

If you have any more good uses for this neglected little fella leave a comment.

I was going to write my own entry on the Parts & States Model for defining contracts between a control’s logic and visuals but you can’t get much better than this article by Karen Corby. Check it out.

I often hear people mention that an operation or action takes “too many clicks”. Clicks themselves are relatively harmless critters. On their own they’re small, innocuous actions that put little burden on the user experience. What can impact the overall user experience is the weight of each click. Ten clicks with little weight will flow effortlessly from the user, but a few heavy clicks can really kill a user’s rhythm. A click’s weight falls into four main categories:

Decision Time

This is the time it takes for a user to decide that they need to click on something.

Suggestions: This greatly depends on your application. If your application will be used frequently then the user’s decision time will decrease as they learn how to use it (this may also apply to second guessing). If your application will not be used frequently then it’s best to make available actions obvious and to appeal to the user’s past experiences by making it familiar.

Seek Time

This is the time it takes a user to visually locate a button (or link) and move the mouse to that location. For keyboard users it’s the time it takes to decipher the appropriate hot key.

Suggestions: Use gestalt theory to drive the layout of your UI. Group similar items and make available actions obvious. Provide gestures that mimic the minipulation of physical objects. Use animation, brightness, and contrast to guide the user’s eye. Make shortcut keys apparent. Keep accessibility in mind (especially color blindness).

Second Guessing

Users guess frequently when using an interface, drawing on past experiences, but second guessing adds weight to a click. What will happen when I click? Will the application act immediately or will I be prompted first? What risk is involved with this operation? Can the operation be undone?

Suggestions: Build on the user’s past experiences. Add an ellipsis when a dialog precedes an action. Properly warn users of the risk. Don’t group actions that can’t be undone with those that can. Experiment with positioning and scale to communicate weight. Use expressive iconography. Provide extended ”helptips” rather than tooltips. Remember that users are less likely to second guess when they trust your application.

Wait Time

This is the time spent waiting after a click is performed.

Suggestions: Never allow the UI to lock or freeze (I cannot emphasize this enough). Provide visual feedback of progress. Provide detailed feedback of long running operations. If an operation can be performed asynchronously then don’t force the user to wait for it to complete. Perceived performance has great deal of influence, time flies when you’re occupied.

When designing an application think about how you can make a click weigh less if you’re unable to remove it completely, or if it wouldn’t make sense to do so.

WPF 3.5 SP1 will allow a custom image to be used as a spash screen. The display of this splash screen is implemented in native code and therefore will display fairly quickly while WPF spins up. When your application loads the splash screen will fade out.

Here are some nifty interfaces to think about when creating data objects that will be used in a WPF application. I’ve intentionally kept these descriptions very brief.

System.ComponentModel.INotifyPropertyChanged

This is probably one of the most common interfaces to implement in your data objects. Implementing this interface allows you to notify WPF that a property has changed when the data object is data bound.

System.ComponentModel.IDataErrorInfo

In .NET 3.5 WPF looks for this interface when data binding. This interface allows you to mark properties on your object as being in an erroneous state. On your Binding object set ValidatesOnDataErrors to true to enable this behavior.

System.ComponentModel.IEditableObject

In .NET 3.5 SP1 WPF included the IEditableCollectionView. When using the IEditableCollectionView, IEditableObject allows you to handle the transactional editing of your individial data objects using BeginEdit(), EndEdit(), and CancelEdit().

System.ComponentModel.ISupportInitialize

If you need your data object to perform an action after WPF has set each property from Xaml, this is the interface you need to implement. WPF will call EndInit() when all the properties have been set.

Which ones did I miss? Which interfaces do you think are important to keep in mind when creating data objects?

Jeff Atwood (of Coding Horror) has an article about Alan Turing, please check it out. Alan Turing is widely considered to be the father of modern computer science. He was also greatly responsible for breaking the Enigma code during World War II. In January of 1952, Alan Turing was arrested for having sex with another man. As part of his conviction, he was forced to take estrogen hormone injections or risk going to jail. On June 7th, 1954 Alan Turing killed himself by eating half of a poisoned apple, he was 41.

When many people first bind a bitmap image (say a PNG, or JPG) to an Image control in WPF, an overly astute developer might scratch his or her head and think “Why is my image 33% too big?”

It all boils down to DPI. Say you have a 720px x 720px image at 72dpi (many images have a DPI of 72). Physically, this image would be 10in x 10in. WPF will maintain this size, and since WPF defaults to 96dpi, at 10in x 10in the image is shown on the screen as 960px x 960px, 33% bigger than it’s original size.

Noodle on that for awhile and you’ll realize that although it’s a stumbling point, it is indeed the correct behavior. Images should display according to their intended DPI. Images with a DPI below 96 will be scaled up, and those with a DPI above 96 will be scaled down (assuming you have not changed your machine’s native DPI).

The problem is that the WPF team has provided no easy means by which to say “I want to ignore the DPI of the image, give it to me in its original pixel size.” This behavior is often the desired one when building a simple image editor for example.

Wouldn’t it be great if you could set a property called ScalingBehavior to DpiAdjusted or OriginalPixelSize? Well, you can’t, not yet anyway. There is a solution however:

Here we’ve set Stretch to Uniform and bound the Width and Height to the PixelWidth and PixelHeight of the Source, effectively ignoring DPI. The image however will not be pixel perfect, even when using SnapToDevicePixels (which simply snaps the borders, not pixels within the image). However, WPF in 3.5 SP1 will support a NearestNeighbor BitmapScalingMode, which should correct this.

In most Software Development Life-Cycle (SDLC) models, the first phase is often considered to be planning and analysis. In a real world scenario this often translates into gathering requirements, writing specifications, and so on. However, I believe this methodology skips an important step.

When a project begins, even when specific needs are put forth, it is in an abstract state and the path ahead is vague and unclear.

Think of this vague state as a blank sketchbook, an empty sheet of paper, or a table top covered with a plethora of Lego bricks. As an artist/writer/builder do you plan and analyze the path ahead or you or do you explore your medium? An artist will free sketch, a writer will free write, and a kid (or adult) with Lego bricks will pick up seemingly random pieces and snap them together.

This is an important and well respected process in many disciplines, and yet one largely ignored by the software development industry. Why deny people their natural urge to play with what’s at hand and discover what’s possible? Why suppress the natural human mechanism that leads to truly creative thinking?

A logical discipline such as software development does not preclude the need for creativity. Creating software is as much about innovation, a creative process, as it is of logic and reason.

Creative thinking and logical analysis cannot drive one’s thought-process simultaneously without one being a burden on the other.

Therefore, the first phase of the SDLC should not be planning and analysis, it should be a distict phase dedicated solely to a creative thought process. Every member of the team should be given the freedom to explore their own ideas. Concepts should be expanded, ideas researched, sketches drawn, prototypes developed, and possibilities discovered. Meet with stakeholders and share in dialog that’s driven by imagination and not requirements. Where once was an empty space, a vacuum, a blank canvas, there is now a living source of inspiration. This inspiration is the seed from which a truly successful software project can grow and thrive, inspiration often stillborn in our current landscape.

Please see the following for more insight into creative thinking:

10 Mental Blocks to Creative Thinking