Aug 29, 2013 at 10:57 PM
Edited Aug 29, 2013 at 10:58 PM
I am looking at a Colors.xaml file and there are a number of values specified. But they are somewhat generic (BackgroundColor1, BackgroundColor2, etc.)
Is there a guide somewhere that will explain the purpose of the various colors so I be sure to select the appropriate one for a given task.
I would assume that the ones that end with 1 are the defaults. But what else? It doesn't appear that labels and textboxes use the same color values.
Some are well named and really don't need more explanation (CODE.Framework-Application-MenuSelectionColor for example).
So I guess the question is how do I know when to use which BackgroundColor, ThemeColor, ForegroundColor, and HighlightColor)
On that same note...
I will need some new colors and brushes. I don't mind adding them to my applications themes. But thought I would check to see if there were any plans to add them to the framework and, if so, the naming convention that the FW would be using (so I can use that
instead of mine.)
Colors I think I will need:
For validation errors:
Error Indicator (some icon/character associated with the item in question
To alert the user that the item is required:
Since I use the default colors for view mode, I like to have a way to make it clear that the user is in edit mode or not:
And for disabled controls:
Unless I hear otherwise, I will just create these in my apps theme.
Sep 4, 2013 at 11:14 PM
Well, that is a tough question to answer :-). Mainly because there are no hard rules. Each theme is free to define whatever colors it needs. And you are free to add your own.
With that said: It makes sense to try to keep the number of colors each theme uses to a minimum. It keeps things sane, and it usually also isn't a bad idea from a design-aesthetics point-of-view. So a few foreground colors (perhaps 3 or 4) and a handful of
background colors usually do the trick. They are then used for all kinds of things, from the color of headings, to the color of selected control outlines, and so on. Hence the generic naming.
The list you provide above is actually a good example as to how quickly the list grows drastically and becomes a) hard to manage, and b) you end up with an app that has all kinds of different colors, which usually doesn't look all that good. I would instead
use the standard foreground color (foreground color 1) for my editable foreground color and I would use background 1 for the background used by that control. For disabled controls, I would simply use the same color, but either make it slightly transparent,
or use our color helpers to darken or lighten the same color. This way, you have just one defined color, but you can use shades of these colors to indicate special meaning. This works well as editable controls are usually black (foreground) and read-only are
gray (a "lightened black"). Same if you were to make the foreground blue. Perhaps a lighter or darker blue would be a good indicator for a disabled control. Using this trick, you usually can create good looking apps without needing a lot of graphical
I could however see that a single color resource for errors could be added once we have built-in support for that. Then, that color (probably a shade of red) could be used for error-related things. Themes could then decide to use a certain shade of that color
to display control backgrounds for instance. But then again, not all themes may need special colors for errors. Perhaps themes choose to show errors in ways other than with colors (for instance in a theme for the visually impaired). So this would also be something
that many themes may need, but not necessarily all of them. Same for an icon. Some themes may want an icon, others perhaps not. This should be left for each theme to decide. We never want to restrict themes too much. Currently, a theme can simply create a
theme for individual controls (such as textboxes) and incorporate an error indicator (which they are free to choose). I think we already have icons in our standard icon resources that could act as such icons if needed, but perhaps we could add more when we
get to that.