How to make my applications "skinnable"?
Asked Answered
D

10

10

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?

Derinna answered 5/2, 2009 at 18:32 Comment(0)
B
8

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

Bio answered 5/2, 2009 at 18:44 Comment(0)
S
5

Keep all your styles in a separate CSS file(s)

Stay away from any inline styling

Swen answered 5/2, 2009 at 18:34 Comment(0)
M
3

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.

Murky answered 5/2, 2009 at 18:40 Comment(0)
A
3

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.

Aksoyn answered 5/2, 2009 at 18:49 Comment(0)
G
1

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:

  1. Title
  2. Blog Entry
  3. 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.

Geriatric answered 5/2, 2009 at 18:38 Comment(0)
F
1

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

Flout answered 5/2, 2009 at 18:39 Comment(0)
B
1

This should be relatively easy, follow these steps:

  1. Strip out all styling for your entire web application or website
  2. Use css to change the way your app looks.

For more information visit css zen garden for ideas.

Bifocals answered 5/2, 2009 at 19:56 Comment(0)
A
1

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.

Alfalfa answered 5/2, 2009 at 20:28 Comment(0)
G
0

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.

Gog answered 5/2, 2009 at 18:43 Comment(0)
B
0

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.

Bulganin answered 5/2, 2009 at 20:17 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.