What are the best practices for customizing themes for a WP7 application (font family, colours, etc)? Should I be sticking to the standard names and replacing them or creating new resource names and using those?
ie. "PhoneFontFamilyNormal" or "MyAppFontFamilyNormal"? "PhoneTextNormalStyle" or "MyAppTextNormalStyle"?
The documentation on the subject seems to focus soley on playing the straight and norrow, even though custom themes are supported (if disueded).
I would personally create my own resources with unique names and use those. This avoids any confusion relating to precedence (I can't recall right now the resource look-up mechanism in Silverlight, I know that it is a simplification of the WPF one - which is a little complex!).
One important consideration is whether you will support dark / light themes. The standard theme resources like PhoneBackgroundBrush will honour the users theme. Therefore, if you wish to support Dark / Light I would recommend deriving your own theme from the standard one, for example, you might derive your background brush from PhoneBackgroundColor.
Related
I'm creating some UI controls in Lab Windows CVI programmatically, and I saw on NI's site that there are two different graph types, "CTRL_GRAPH_LS" and "CTRL_GRAPH". Many other controls have the same suffix. What are the differences between the two?
Thanks in advance.
_LS is used to indicate Lab Style controls.
Using one over the other is completely preferential. The primary distinction is that Lab Style is a new style, as opposed to Classic, or old style. Lab Style has a richer, 3D look, where the old style is flatter in appearance. In terms of functionality, I have seen no advantage using one over the other. When using the NewCtrl function to programmatically create your UI controls, you can select Lab Style controls by including the _LS suffix option for controls that offer it.
I've continued my journey with Singularity, and I'm enjoying experimenting with this framework. I've created an experimental site at Sassmonster.com (Github repository here at https://github.com/58bits/sassmonster).
I was discussing this framework, along with other 'semantic' frameworks (if that's the right term in this case) vs presentational markup frameworks like Foundation, and Bootstrap.
I was wondering if anyone could summarize the relative merits of the approach that Singularity (and the original Semantic Grid) takes - without requiring grid classes or attributes to be present in markup.
The main advantage, if I've understood this correctly, is the ability to dynamically change layouts independent of document source order or any fixed class attributes (e.g. new grid layouts and grid span settings at given breakpoints, including source order independent changes like a sidebar switching from the left to right sides).
I'm sure there are others but would be grateful for a summary from someone with more experience than I have ;-)
Lastly - in terms of the future of grid systems in general - will the general adoption of the CSS Grid Layout Module obsolete frameworks like Singularity?
The advantage to semantic frameworks is that they take abstraction a level deeper than class names. This gives you, the author, the flexibility to generate your own list of classes like Bootstrap or Foundation OR you can apply grid styles to any element without being restricted by classes. Classes are flat and inflexible but having logic abstracted to mixins provides significantly more flexibility.
The advantages you address have more to do with the output model. Singularitys default output mode is called isolation and you can read about how it works here: http://www.palantir.net/blog/responsive-design-s-dirty-little-secret. With singularity you can use old fashioned floats or even write modules for CSS grid layout if you want. Singularity was designed to be future-proof and provide a common framework to do many different things with grids.
Lastly, yes, grid layout does some really awesome stuff and I hope it makes Singularity and other grid systems obsolete. However the syntax and conventions of grid layout is not so great and you may want to abstract some of it out. Some of the conventions are similar to that of Singularity like ratio based column math so that is pretty cool.
This is a topic that may be considered something not necessarily "programming related"; however, I feel it is since I'm asking for specific techniques.
Essentially, as a web developer, I work with a variety of platforms that include a WYSIWYG editor in the backend (TinyMCE, WYGWAM, etc) and one of the selling points of such systems is that it becomes easier to manage your own content because of these tools.
In theory, sounds great, in practice, not so much.
It can be way too easy for a client to break a layout by using many of the advanced features of a WYSIWYG editor. They can start floating things, setting too much margin/padding, etc.
Generally, I have tried to build any of these types of pages with only some sensible default styles applied to a few of the most common tags, such as setting a font size, colors, some margins, and some text decorations.
I would like to know if anyone has used anything more advanced to essentially turn the output of:
$cms->getContent();
...or equivalent into something that is effectively sandboxed and operates entirely agnostic of any other style/layout elements being used.
As often as possible, I express to clients that they should purchase an HTML/CSS book for Dummies and read it so that they aren't deer in headlights when they click "code view" in a WYSIWYG. But I know they don't do this, nor do they hire anyone who has experience, and it ends up allowing a client more control than they should responsibly have.
Plus, it sucks when you are using their sites as work samples to show others knowing they have the ability to take your beautiful design and development and make it look like crap.
A few things:
I have a standard WYGWAM config that I reuse on new sites by importing the exp_wygwam_configs table.
I keep options very limited in the editors
Areas of the page delineated for images should use a File field, with an image resizer like CE Image used to insure proper size
Client training. Make videos with Camtasia or similar tool if you have to.
Use a custom stylesheet for WYGWAM that has a small subset of styles, so they can choose h2...h4, for example, but not h1 or h5.
After encountering a lot of issues with WYSIWYG editors (which, by the way, never reflect accurately what you "get" in the end), I now prefer to leave only the most basic formatting features in the editor's configuration. For example, take a look at stackoverflow's editor.
It's got the following features: bold, italic, link, quote, pictures, lists, and alignments. The only special feature here are code sample and html, which are targeted to this site's audience. Most of your client don't need them.
I think it's the best approach, because if you give your clients the feeling that they can do whatever they want in the page, but in the end, this content is filtered when the page is rendered, they are going to be really frustrated. Not to mention the fact that the site will be slowed by the filtering process and the need to put the filtered content in cache.
Sometimes the client indeed wants to have a special layout in a page, but I think that can be best done by customizing the CMS so that it fits the client need.
Is there some standard way to make my applications skinnable?
By "skinnable" I mean the ability of the application to support multiple skins.
I am not targeting any particular platform here. Just want to know if there are any general guidelines for making applications skinnable.
It looks like skinning web applications is relatively easy. What about desktop applications?
Skins are just Yet Another Level Of Abstraction (YALOA!).
If you read up on the MVC design pattern then you'll understand many of the principles needed.
The presentation layer (or skin) only has to do a few things:
Show the interface
When certain actions are taken (clicking, entering text in a box, etc) then it triggers actions
It has to receive notices from the model and controller when it needs to change
In a normal program this abstraction is done by having code which connects the text boxes to the methods and objects they are related to, and having code which changes the display based on the program commands.
If you want to add skinning you need to take that ability and make it so that can be done without compiling the code again.
Check out, for instance, XUL and see how it's done there. You'll find a lot of skinning projects use XML to describe the various 'faces' of the skin (it playing music, or organizing the library for an MP3 player skin), and then where each control is located and what data and methods it should be attached to in the program.
It can seem hard until you do it, then you realize it's just like any other level of abstraction you've dealt with before (from a program with gotos, to control structures, to functions, to structures, to classes and objects, to JIT compilers, etc).
The initial learning curve isn't trivial, but do a few projects and you'll find it's not hard.
-Adam
Keep all your styles in a separate CSS file(s)
Stay away from any inline styling
It really depends on how "skinnable" you want your apps to be. Letting the user configure colors and images is going to be a lot easier than letting them hide/remove components or even write their own components.
For most cases, you can probably get away with writing some kind of Resource Provider that serves up colors and images instead of hardcoding them in your source file. So, this:
Color backgroundColor = Color.BLUE;
Would become something like:
Color backgroundColor = ResourceManager.getColor("form.background");
Then, all you have to do is change the mappings in your ResourceManager class and all clients will be consistent. If you want to do this in real-time, changing any of the ResourceManager's mappings will probably send out an event to its clients and notify them that something has changed. Then the clients can redraw their components if they want to.
Implementation varies by platform, but here are a few general cross-platform considerations:
It is good to have an established overall layout into which visual elements can be "plugged." It's harder (but still possible) to support completely different general layouts through skinning.
Develop a well-documented naming convention for the assets (images, HTML fragments, etc.) that comprise a skin.
Design a clean way to "discover" existing skins and add new ones. For example: Winamp uses a ZIP file format to store all the images for its skins. All the skin files reside in a well-known folder off the application folder.
Be aware of scaling issues. Not everyone uses the same screen resolution.
Are you going to allow third-party skin development? This will affect your design.
Architecturally, the Model-View-Controller pattern lends itself to skinning.
These are just a few things to be aware of. Your implementation will vary between web and fat client, and by your feature requirements. HTH.
The basic principle is that used by CSS in web pages.
Rather than ever specifying the formatting (colour / font / layout[to some extent]) of your content, you simply describe what kind of content it is.
To give a web example, in the content for a blog page you might mark different sections as being an:
Title
Blog Entry
Archive Pane
etc.
The Entry might be made of severl subsections such as "heading", "body" and "timestamp".
Then, elsewhere you have a stylesheet which specifies all the properties of each kind of element, size, alignment, colour, background, font etc. When rendering the page or srawing / initialising the componatns in your UI you always consult the current stylesheet to look up these properties.
Then, skinning, and indeed editing your design, becomes MUCH easier. You simple create a different stylesheet and tweak the values to your heat's content.
Edit:
One key point to remember is the distinction between a general style (like classes in CSS) and a specific style (like ID's in CSS). You want to be able to uniquely identify some items in your layout, such as the heading, as being a single identifiable item that you can apply a unique style to, whereas other items (such as an entry in a blog, or a field in a database view) will all want to have the same style.
It's different for each platform/technology.
For WPF, take a look at what Josh Smith calls structural skinning: http://www.codeproject.com/KB/WPF/podder2.aspx
This should be relatively easy, follow these steps:
Strip out all styling for your entire web application or website
Use css to change the way your app looks.
For more information visit css zen garden for ideas.
You shouldn't. Or at least you should ask yourself if it's really the right decision.
Skinning breaks the UI design guidelines. It "jars" the user because your skinned app operates and looks totally different from all the other apps their using. Things like command shortcut keys won't be consistent and they'll lose productivity. It will be less handicapped accessible because screen readers will have a harder time understanding it.
There are a ton of reasons NOT to skin. If you just want to make your application visually distinct, that's a poor reason in my opinion. You will make your app harder to use and less likely that people will ever go beyond the trial period.
Having said all that, there are some classes of apps where skinning is basically expected, such as media players and imersive full screen games. But if your app isn't in a class where skinning is largely mandated, I would seriously consider finding other ways to make your app better than your competition.
Depending on how deep you wish to dig, you can opt to use a 'formatting' framework (e.g. Java's PLAF, the web's CSS), or an entirely decoupled multiple tier architecture.
If you want to define a pluggable skin, you need to consider that from the very beginning. The presentation layer knows nothing about the business logic but it's API and vice versa.
It seems most of the people here refer to CSS, as if its the only skinning option.
Windows Media Player (and Winamp, AFAIR) use XML as well as images (if neccesary) to define a skin.
The XML references hooks, events, etc. and handles how things look and react. I'm not sure about how they handle the back end, but loading a given skin is really as simply as locating the appropriate XML file, loading the images then placing them where they need to go.
XML also gives you far more control over what you can do (i.e. create new components, change component sizes, etc.).
XML combined with CSS could give wonderful results for a skinning engine of a desktop or web application.
Although I'm specifically interested in web application information, I would also be somewhat curious about desktop application development as well. This question is driven by my work on my personal website as well as my job, where I have developed a few features, but left it to others to integrate into the look and feel of the site.
Are there any guides or rules of thumb for things like color schemes, layouts, formatting, etc? I want to ensure readability and clarity for visitors, but not be bland and dull at the same time.
As for my knowledge in this area - If you hand me a picture, I have enough knowledge to reproduce it on the screen, but if you ask me to design a new interface or redesign an existing one, I wouldn't know where to begin.
Usually, each operating System has user Interface Guidelines. For Windows, have a look here. (Edit: The links in that post are broken. But a Search for "User Interface Guidelines" on MSDN has articles about everything)
Apple has it's own as well. Also, you may want to keep accessibility in mind.
One tip to check if your colors have good contrast is taking a snapshot of it and converting to grayscale. If you can't read something, colors were surely bad choosen.
Plus, although it's not about user interfaces, Before & After Magazine can give you some pretty good hints about color, design and related topics. It even has got some free pdf's to download.
The book Designing Interfaces, by Jenifer Tidwell has a entire chapter on the subject (Chapter 9, excerpts accesible online).
The entire book is worth recommending.
For web UI, I'm going to go out on a limb here and say that the most important color in web design is white, or "light". This is the color on top of which you place dense tracts of content.
Dark text, light background, always, when it comes to your primary content areas.
And the most important rule in layouting is whitespace. Let the content breathe.
Following these two simple rules is worth more than most "user interface usability" guidelines.
And by the way, the MS user interface guidelines are (by and large) horrible. Read Jakob Nielsen, look at Apple design aesthetics, but stay away from the MS "neutral gray/blue crunchbox" 12-step Wizard 10pt text philosophy of UI.
(And I say that as a long-time MS GUI programmer)
I'm horrible at finding colors that look good together, so I cheat and use pictures from nature that are mostly the color I want (say, green) and then I use this website to pull out the main color scheme. Generally nature does a pretty good job of setting its own nice color schemes.
Use high contrast color combos; Black text on white background is the best example of a high contrast combo.
A bad combo is green text on red background. It's horrible for color blind people (like myself).
See what your site looks like to a color blind person: colorfilter.wickline.org
As for desktop applications: Whatever you do, do not use hand-picked colors. Stick with the named system colors such as "Window Background", "Menu Text", etc. Otherwise, people relying on OS accessibility features will be locked with your color choices (unable to choose a high-contrast theme, for instance) and to people who like to customize their desktop themes will think your application is fugly.
Here are some simple pointers for usability in your typography. These things mainly address readability and accessibility concerns.
DOs:
Use relative font sizing (em)
Identify language changes within a document using the LANG attribute
Black text on a white background
For headings, use H1, H2, etc. and nest them appropriately
Chunk up content and organize with headings that fit what your users are looking for
Write clear and simple copy
Align left, ragged right
Text-to-background color must be high contrast
DONTs:
Use "click here" or "more" as link text
Use underline for emphasis
More than 2 font-type families
Italics
Blocks of text using all caps
Use true red or true blue text on white background (chromatic aberration)