To get started with our XAML Application Review, let's take an overall look at the UI look and feel. As a reminder, the XAML Tips application that we'll be looking at is a replica of a Silverlight application that went into production in 2009. You can download the code here: Jeremy Bytes - Downloads.
Operation
First, let's take a look at how the application operates. Here is the login screen:
Here, we can see the use of gradients that we saw in a previous article (XAML Tip: Gradients). We'll consider the look and feel in just a moment. On this screen, we have a menu bar to the left of the application that is used to navigate between screens. If we click the "Popup Message" link on the left, it will take us to the following screen (Note: for this sample, authorization code has been removed, so the login screen doesn't do any validation):
The effect is that the main client area (everything but the menu bar) is replaced with a new screen. The data screens from the original application are not re-created here, but they are collections of primarily list boxes and buttons that allow the user to make selections of existing data and to add mappings for data between systems. We are taking a look at the overall UI design here.
Pros:
This behaves similarly to the WinForms applications that we had deployed at our site. This gave users a familiar interface. The application itself has a limited number of screens (there were a total of 7 screens); and most of these screens had similar operation (either data selection or data mapping). So, we were able to give the users the advantage of a web deployment and a familiar interface.
Cons:
This behaves similarly to the WinForms application that we had deployed at our site. (Yes, I realize that I just put this into the "Pros" section.) Silverlight (and XAML in general) gives us amazing flexibility for UI design. Billy Hollis (one of the "voices of reason" in the developer community) sees XAML as the opportunity for us to completely rethink how users interact with our applications. He has said that one of the worst things you can do when coming to XAML is to simply re-host your WinForms apps. There are tons of exciting things that we can do with XAML that would be extremely difficult in WinForms. We should be thinking about how we can best present our applications to the users to enhance usability.
Verdict:
There's really nothing "wrong" with the overall operational design. It fulfilled its purpose even if it's not very exciting. I'm very big on using the right tool for the job. This one worked well. For other jobs, I might be looking at the page-based navigation that's available in Silverlight. Or I might come up with something completely different -- but considering that I generally like to use well-tested solutions, I'll probably look for ideas from other developers.
Look and Feel
This application is a bit "gradient happy". The actual data pages (which aren't shown) are mostly non-gradient list boxes and standard buttons. Gradients aren't really "in" anymore. But that's part of the great thing about XAML. This application makes extensive use of styles (web developers can think of this as similar to CSS). Because these styles are shared, they are very easy to update if we get tired of the look.
Let's take a look at how these are implemented. Here's a snippet from the App.xaml page in the code:
These brushes are all in the application's resources collection, so they can be referenced across all of the pages in the application. Notice the names that are used for the keys. The names are things like "ClientBackgroundBrush" and "DarkBackgroundBrush" that tell how the brushes are used. They do not have names like "BlueGradientBrush" or "YellowGradientBrush". A name like "BlueGradientBrush" really limits how this can be changed. If you change the color, then the name is no longer correct. If you change it from a gradient brush to a solid brush, then the name is no longer correct. Instead, if we use names that reflect how the brushes are used, we can make those color and style changes without invalidating the names.
Here is an example of some styles from the App.xaml:
This shows the styles that are used to display data to the user. Since these values are centralized, we can easily make changes to the fonts or margins, and all of our detail controls will be affected.
Pros:
Centralizing the colors and fonts in the application resources allows us to easily update the visual elements of our application. If we decide that we no longer like the gradients, we can change to solid brushes with different colors or patterns in this one place, and our entire application will pick up those changes. The same is true for the fonts and alignment of our controls.
Cons:
Some of the names could be a bit better; "DarkBackgroundBrush" and "LightForegroundBrush" are a little limiting (if we wanted to switch to a light background and dark foreground). Also, there are some styles that are in the resources section of MainPage.xaml. And while these styles are only used on the MainPage, they should probably be centralized for consistency.
Verdict:
The colors and gradients are looking rather dated, especially compared to the Metro interfaces that are starting to become popular. However, since the brushes and styles are centralized, it is fairly easy to update the application when we come up with a new design. In the future, I would use fewer gradients (even though I personally like them), and I would be more consistent with the centralization of the style and brush resources.
Next Time
So far, we've seen that there are some improvements that can be made to this application. By reviewing what we've done in the past in the context of our current experience, we can make sure that we're always moving forward.
There's still quite a bit to look at in this application. Next time we'll be taking a look at the form manager that keeps track of the different forms and how they get docked to the client area.
Happy Coding!
No comments:
Post a Comment