I've seen these applications for skinning:
- Distributor/Customer Branding
- Feelgood applications
Distributor Branding gives the final user familiar names and looks - e.g. for support we use a remote desktop access tool that is branded with our name and logo. This makes the tool better integrate with our software, and the customer knows "he's dealing with us".
It's the difference between
"to get support for AceMe Works, run the AceMe Remote Support utility"
"to get support for AceMe Works, run the Fundunga Sambaga Conneculator, and enter AceMe-5647895324 in the Provider field".
Distributor Branding is rather simple to achieve from a implementation POV:
- Don't show your name everywhere
- Make room for the brander's
- (advanced) set defaults, and allow to hide settings
Something simple like reading the window title and a custom HTML / .png to be displayed from an .ini file is often enough. You can - and are encouraged to - stick to a OS/envirnoment standard UI. In addition, you are often expected to set defaults and limit some options - either from being changed, or being displayed at all.
Feelgood Skins - this is what usually receives techie hate. This is the realm of media players etc., often in a commodity market, where establishing an emotional, personal connection between user and product is one of the few competetive edges you can have. I'd avoid it in any other case.
Fundamental problem: it's often hard - or a lot of extra work - to provide a "OS default skin" that actually works like an OS default. Might also be considered a "toy" by a commercial customer.
The following applications don't need separate skins per se, but still a skinning framework with a fixed skin is a straightforward technical choice:
Bobify - you provide a skinnable interface, because you want to be deliberately simpler than the OS default.
There are targets even beyond the "kids & special needs" market. One thing could be a process that's normally perceived as complicated, or niche application of a complex, more powerful tool.
Fundamental problem: You are locked into Microsoft Bob mode. You create an additional barrier for your users to get used to a "full" interface.
Portability - you value consistent UI across platforms more than platform-compatible UI. I'd argue that's rarely a good idea, except maybe in combination with a simplified UI, as above, or a very loosely defined platform (such as the early www).
Again, you don't need separate skins