One complaint I see a lot about apps built using the Compact Framework is that they look terrible. It doesn’t have to be that way, and honestly the Compact Framework really isn’t at fault here. Generally speaking the problem is that developers are lazy and want to just use what’s in the off-the-shelf toolbox. If you do that, then yes, you’ll have something that looks like a Windows 95 application. But again, I don’t fault the CF for that, I fault developers (or more likely their managers).
If you want an app to have good aesthetics you need two things:
- To hire a real graphic designer to at least produce collaterals
At the risk of making broad generalizations, I’ll state that developers suck at producing graphics (it’s OK, graphic designers suck at writing code). You wouldn’t hire a plumber to hang drywall, why on earth are you having developers create UI? Hire a designer that has experience building UI collaterals and you’ll find that not only will your app look a thousand times better, it will get done faster than having your devs hack at it.
- To break your developer’s reliance on the off-the-shelf controls
Using the controls that install with the CF is a sure-fire way to end up with a dated-looking app. This doesn’t mean you have to go buy a 3rd-party set of controls; that may help, but don’t just assume it’s going to solve the issue. What we’ve done internally is to build a set of controls that we use. Most people would be surprised to know that we have a very small set. We wrote the entire device application for a commercially-available time clock that you’d never know was based on CE by looking at it and I believe that the number of Control types used (other than a Form and SmartPart) was one. That’s right – we used a single control type for everything. We use it as a Button, a Label, a CheckBox and stacked together to make a List (it’s a touch device with only 5 or 6 items visible at a time).
There’s not much I can do for you on point #1, but for #2 I can at least give you the control we use. It’s called ImageButton due to it’s genesis as a button that, surprisingly, held an image. It got more complex as we needed and added new capabilities and features. You can set the up and down images (to get that nice “inverted” look on click), put align text left, center or right (with an appropriate margin if you’d like), put text and images together, and several other features.
Here are some quick screen shots:
The first screen shows rounded buttons (the change to a blue background when clicked) with the grey “>” and the text aligned in different ways. Note that the right and left justified text have a fairly large margin; this is settable.
The second is probably not the greatest picture as it looks a lot like a normal checkbox, but those checkboxes are actually images. You could easily change them to a round “bubble” or a box with a check that extends beyond the box border.
The third is a simple drawn-gradient background. Note that the button in the upper middle (which again is an ImageButton) has rounded corners and the gradient background is visible through the transparent corners of the button (this was a real challenge in the CF). The “State1” text on this view is actually another ImageButton control so it can respond to clicks. Again note that the gradient background is visible through the control.
The final view shows yet another use of the control. The two-state capability is actually done with two images. The control is a single ImageButton and when it gets clicked, we swap the image to toggle the “on” or “off” selection. Notice that the text in the images is less pixelated becasue we don’t have ClearType turned on.
Since I didn’t really have a better place to put the code, and since the sample app showing it was using the IoC framework, I’ve simply put the code in the OpenNETCF IoC Framework tree on Codeplex (under Samples). Also note that the code for this is not yet in the release. That means you need to pull it from the source view (starting with change set 59250)