Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
On Being Skinned

By carlfish in Op-Ed
Mon Sep 09, 2002 at 01:21:11 AM EST
Tags: Software (all tags)
Software

One of the User Interface trends that emerged in the 1990's was ‘skinnability’: the ability to customise the appearance of an application right down to its controls and window decorations. Skinning continues to be a big hit amongst computer users who can now make their entire computer look like their favourite cartoon, but it presents a challenge to User Interface designers. Paradoxically, skinnability reduces the expressiveness of a user-interface. It does so by restricting the vocabulary of the interface to those things that can be expressed compatibly with all existing skins (or even all potential skins). This is a minor problem for applications, and a huge problem for platforms.


System Colours

On most Operating Systems you can customise the system colours. The reasons for doing this range from the insignificant (you just like purple a lot), to the incredibly significant (you are colour-blind or visually impaired, and you want a contrasting colour scheme that would look really stupid to anyone else).

While they increase the freedom of the user, customiseable system colours reduce the possible range of expression within an application. The typical computer can display several million different colours, but an application designer can rarely use them, because they are restricted to the small set of named and customiseable colours. If you are designing some interface element, the colour of which can not be described in this language, you just have to pick the one that is ‘close enough’.

Using colours in a User Interface can be a bad thing if the colour-choice is bad (making for an ugly application), or if colour is the only thing that distinguishes a particular element (making the feature unuseable for the visually impaired). However, colours can be a useful tool, and colour is an important way of communicating with people who can see it.

Notably, Mac OS X only has two supported colour-schemes: Blue (with the familiar aqua controls), and Graphite. Graphite was provided for graphic-designers who found the blue interface made it harder to judge colours while working on a picture. When designing an OS X application you can pretty much rely on having black-on-white windows with those horizontal stripes. That said, the UI toolkit still has a set of named system colours, and recommends you use them instead of defining your own.

Speaking in Tongues

Full skinnability adds to the limitation of expressability by limiting the available vocabulary of an application to those interface objects that are already supported by the available skins. This problem appears in skinnable toolkits, such as GTK+, or Java Swing.

A common metaphor in interface design is that of language. The vocabulary of a user-interface lies in the set of available controls. The controls themselves are nouns. The state of a control is an adjective. The actions that we can perform on those controls are verbs.

Most platforms come with a particular dictionary of available nouns, verbs and adjectives, and developers are encouraged to stick to the official dictionary as much as possible. Firstly, users find it easier to understand an application that way because the language is familiar. Secondly, if the official language is changed or expanded in the future, it can be done in a way that doesn't conflict with existing applications. The exception to this rule is games, but the analogy holds—fiction-writers have always been able to be freer with language than technical writers.

Sometimes, however, you come across something that you want to represent in an application that, as hard as you may try, can not fit into the existing vocabulary. At that point, you must create a new control, and wear the cost of having your user learn it for themselves. New words are invented by looking at existing words, and maybe crunching a few of them together, or making something that looks very similar to the words you almost mean. Similarly, you make a custom control either by combining existing controls, or by looking at the existing controls and thinking what changes you would need to make to them so that they have the capabilities you want.

When an interface is skinnable, each different skin becomes a dialect of the language. So if you want to write a custom control, you are no longer introducing a new word to a single language, you're introducing the same word to an infinite variety of languages. You either have to choose a control that looks natural in every skin (impossible), or ‘translate’ your control to each skin (far too much work). Designers of skinnable applications come across this problem freqiently—having to render all existing skins incompatible (or horrendously ugly) because the application has some new interface element that only the default skin supports.

Buttons!

It is even worse when skinnability not only alters the appearance of the generic controls (“This is the appearance of the class of all buttons”), but allows the customisation of specific controls (“This is the appearance of the ‘Go Back’ button). Most skinnable applications, such as Winamp or Mozilla take this route.

For a pathological case, consider Mozilla. The hypothetical case is a developer wishing to write a Mozilla add-on that places a “blog this page” button on the toolbar. Like all buttons, it needs an icon, but unfortunately ‘Blogger Button’ is not a supported noun in Mozilla's skinning vocabulary.By default, Mozilla comes with two skins (Modern and Classic), and there are several popular third-party skins such as Orbit (which the author uses).

Unless you want to draw different icons for each of the popular skins, you are stuck with the fact that your icon will only fit in with one skin, and be inconsistent with all the rest. Inconsistency is a very bad thing in User Interface design, an icon that is incongruous will make it more difficult (and take longer) for the user to target any toolbar button as a result. For anyone not using the same theme as you, the overall user experience of your add-on will be negative, and people will not use it.

Choice

The problem with skinning is... users like it. From the point-of-view of a user, skinnability gives them greater choice within an application or environment because they can customise how it looks. Many people spend inordinate amounts of time on this pursuit. Unfortunately, from the point of view of an application designer, skinnability ultimately reduces the user's choice, especially when it comes to applications that may innovate in terms of their design, by reducing the vocabulary, or palette available to the developer.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Also by carlfish


Display: Sort:
On Being Skinned | 37 comments (35 topical, 2 editorial, 0 hidden)
A huge advantage of "skinning" (4.56 / 16) (#1)
by ucblockhead on Sun Sep 08, 2002 at 09:55:32 PM EST

One important advantage of skinning is that it forces the designer to seperate the UI from the application itself. That is a very, very good thing. It makes for modular, extensible applications. It also helps for designers into designing the UI and the program flow seperately. Too often, these two things are all muddled together. In that sense, I have to disagree with you. Designing and writing a "skinnable" application is harder, but the result is more modular and more extensible.

I also have to disagree with you that adding "skinning" detracts from other features, because when done will, you end up with a more modular design. For example, you end up with the application design completely seperate from the UI design. This means that the application designer doesn't have to worry about UI and the UI designer doesn't have to worry (much) about the application. Even better, it means that the UI design and creation can be shoved way off towards the end of the project. That's very good given that niggling complaints over UI are a very common way that projects are delayed.
-----------------------
This is k5. We're all tools - duxup

There's a difference. (4.25 / 4) (#3)
by carlfish on Sun Sep 08, 2002 at 10:16:22 PM EST

There's a big difference between writing well-factored UI code, and providing a public skinning interface. Often, applications that do the former also feel obliged to do the latter. Often, Open Source applications that do the former can not avoid doing the latter, because if the view is sufficiently abstracted from the controller, the chance of somebody writing the code to make it skinnable is just a function of the number of developers.

On the other hand, with Mac OS X 10.2 any window has the capability of either having the striped-white Aqua look, or the brushed-metal "iApp" look. You can even change existing applications to use the brushed metal look - open up the package, and edit the appropriate Nib file. You don't even have to recompile. However, it's clear from the steps you have to take to change it, that OS X has left it to the developer to decide if a window is going to be Aqua or "Textured", rather than up to the user. That way, the developer is still in control of the way the application looks, and doesn't have to test the appearance of the app in both modes, just in case the user has a different set of preferences.

Charles Miller

--
The more I learn about the Internet, the more amazed I am that it works at all.
[ Parent ]

yes and no (4.16 / 6) (#4)
by ucblockhead on Sun Sep 08, 2002 at 10:32:11 PM EST

In general (IMHO) the only significant difference between well-factored UI code and providing a public skinning interface is documentation and perhaps a couple of lib files.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
So requiring more work is good? (4.00 / 3) (#7)
by mozmozmoz on Sun Sep 08, 2002 at 11:54:03 PM EST

Seems to me that one major effect of skinning is that it adds work to the coding cycle, and so detracts from the overall effort. Especially since it's likely to suck energy from people who care about UI, which could often be better spent improving usability.

Skinning is fine where there's a limited number of forms in a project, but once you've got more than about 5 forms I think skinning becomes ridiculous. Trying to address specific usability issues within the constraint of a skinnable interface can be impossible. So we end up telling users "if you have trouble, choose the easy-to-use skin, and forget the pretty skins". Which works, but kind of obviates the who skin concept once that habit spreads beyond a small number of users.

This is, of course, only an issue for people who have to allow for user support, and have a limited coding budget (hours, coders, or dollars).

There's lots of comedy on TV too. Does that make children funnier?
[ Parent ]

UI is more than just appearance (5.00 / 7) (#9)
by mech9t8 on Mon Sep 09, 2002 at 12:36:21 AM EST

Creating 'skinnable' tends to end up with a lowest-common-denominator approach to interfaces -since everything must be skinnable, it limits what can be part of the default behavior.

Case in point: the mozilla interface.  Sure, you can change the appearance, size, maybe even what buttons appear - IF you want to write and draw an entire skin to support that.  But what's more important to most users - the complete skinning functionality, or the simple ability in Internet Explorer to customize the position, presence, and size of buttons and toolbars by a few clicks?

I would say the latter.  But if that was to be implemented in Mozilla, it would have to be written from a skinnable point of view, and every skin would have to support it.  So what happens? They can't support that, obviously, so you end up with a bunch of skins that look different but offer the same lacking functionality.  It may run on both Windows and the Mac, and may even look like it fits in, but it'll be missing the crucial interface differences that actually make each platform unique - for instance, Mozilla and Java 'swing' applications may have OSX's appearance, but lack the defining Mac top-of-screen menu bar.

Winamp ends up in the same position (especially WinAmp3) - there are all sorts of skins available with all sorts transparencies and funky appearances and odd shapes and whatnot - and as interfaces, they generally all suck.  And unless I want to go write my own skin, there's no way for me to improve or customize it.

Separating application functionality (the browser control, the business/data layers, the MP3 player layer, etc) is obviously a good idea, but that has nothing to with skinning - the data layer could easily be intermingled with the skin-presentation layer; skinning doesn't inherently make that go away.  What skinning does is separate the UI functionality from the UI appearance, which ultimately makes the UI suffer.

--
IMHO
[ Parent ]

I don't think that's true... (2.66 / 3) (#18)
by ucblockhead on Mon Sep 09, 2002 at 12:11:26 PM EST

A good skinning interface doesn't need separate UI functionality from UI appearance.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
In defense of Mozilla... (3.00 / 2) (#22)
by Karellen on Mon Sep 09, 2002 at 02:12:56 PM EST

Much as I hate skins, Mozilla does have a couple of points in its favour in regards of its decision to use totally custom controls.

As an HTML renderer, it has to be able to draw controls on a page under some conditions (like rendering a form).

As a CSS HTML renderer, it has to be able to draw all those controls according to CSS style rules, which can change the background color, foreground color, border color (on a per-edge basis), border style, font size, line size and about a zillion other parameters, on a per-control basis.

Given that Moz is designed to run on as many platforms as possible, there's no guarantee that the native controls for any of them will allow Moz to style them in accordance with all the CSS rules.

Furthermore, the fact that different platforms (and toolkits) have different levels of functionality with regards to controls (such as tree views, tabbed dialogs, etc...), writing any kind of UI for Mozilla that works semi-consistently across all platforms (regardless of how it looks) using native widgets would require the Moz team to use an unacceptably low lowest common denominator of UI elements to get the job done.

I don't think they had much choice in creating their own cross-platform TK. OK, maybe they might have used an existing, non-native, cross-platform TK (such as QT), but people would have still complained then about it not being native (on, say, Windows. Aside - does QT/Win have a `native' look/feel, or does it have it's own theme?), and they'd have needed to get into a whole bunch of licensing issues that they probably couldn't be bothered with.

K.


[ Parent ]

Options (none / 0) (#30)
by mech9t8 on Tue Sep 10, 2002 at 08:23:47 PM EST

I understand the rationale for the Mozilla UI decisions... I just think those decisions inherently limit the ultimate quality of the browser.

Instead of putting all the effort into writing a cross-platform GUI, perhaps they should've concentrated on writing good cross-platform components and then writing the shell natively... ie. imagine how good Galeon (Gnome), K-Meleon (Windows), Chimera (OSX), etc. could be if the effort directed at Mozilla's cross-platform interface went into developing them instead.

They could perhaps use an XML interface to generate dialog boxes that would be common on all platforms (ie. preferences and whatnot could be rendered in native widgets based on a common XML in all platforms).

They'd still need to implement a few controls with cross plat-form implementations (ie. buttons, text boxes, list boxes, etc) in the renderer control.  But it looks they do separate implementations for that anyway... in the current version, the widgets inside the browser window don't look like the widgets in the dialog boxes.

--
IMHO
[ Parent ]

recent skinning trends (4.25 / 12) (#2)
by hovil on Sun Sep 08, 2002 at 09:59:59 PM EST

If you look at applications like mozilla and winamp 3, they have shifted from having a window in which you can merely change the colours to having a high level API (XUL in mozilla, MAKI in winamp 3) where there is much more freedom to build interfaces that are completely different to any standard UI paradigms that are out there. They appear to be departing from the beveled grey toolbar as much as possible.

I gotta say (2.50 / 6) (#6)
by regeya on Sun Sep 08, 2002 at 11:42:13 PM EST

If it weren't for Graphite, I'd go insane. The regular Aqua interface is, as you say, too distracting. :-D

[ yokelpunk | kuro5hin diary ]

XP is the same (3.00 / 1) (#25)
by bobsandwitch on Mon Sep 09, 2002 at 09:09:17 PM EST

The Fisher-Price(tm) UI is just crap, but you can make it look like Windows 2000 again with little or no trouble :) Windows .NET Server looks like 2000 tho, which is good (and faster)

[ Parent ]
.net server (3.00 / 1) (#26)
by sethadam1 on Mon Sep 09, 2002 at 11:08:17 PM EST

I'm using .net Server RC1 right now, and I'm glad that Luna (the Fisher Price interface you refer to), isn't present.  It makes very little sense to make you server with the same interface as your workstation when a workstation is designed for productivity, not ease of administration.  

By the way, .net Server uses the XP-style start menu.  If you want to see the full Windows 2000-like environment, you still have to change the start menu back to "Classic."  

Adam
firsttube.com

[ Parent ]

No, XP is worse (none / 0) (#28)
by locke baron on Tue Sep 10, 2002 at 09:31:30 AM EST

By an order of magnitude (and I'm not talking about guts here, just UI). Aqua's candybubble-blue stuff is distracting, but otherwise, the interface is pretty functional. Luna, OTOH, has a horribly barfucious color scheme (like someone tried to copy Aqua, but completely missed the point), and an obsessively dumbed-down interface. Bah, humbug - where the fsck is a simple FILE PERMISIONS property sheet? I mean, XP is basically NT 5.5, and still even with NTFS, I can't change a file's permissions in any sort of fine-grained sense. (Well, I didn't look to see if CACLS.EXE is still there, I suppose I could cruft something together using that, but ick, why?)

MS, you should have stuck with the ok-but-not-great Workplace Shell ripoff that we've been using since Win95. (Ok, I know it's still there. But Luna is hellishly barfulous. Just kill that fucking thing.) As a hint, people weren't using NT and 2k because of FUD spread (mostly by MS) that their apps/games won't work. XP didn't really do much more about that than 2K did. (I've never found a win32 app that Win2K choked on. A few DOS and Win16 programs, but no real 9x/NT apps.)

Anyway...

Micro$oft uses Quake clannies to wage war on Iraq! - explodingheadboy
[ Parent ]

NT 5.1 (none / 0) (#29)
by ggeens on Tue Sep 10, 2002 at 02:29:59 PM EST

XP is basically NT 5.5

IIRC, it identifies itself as NT 5.1. Not that version numbers really matter...

I can't change a file's permissions in any sort of fine-grained sense.

Is that XP Home or Professional? I can imagine why they left it out of the home version, but the Professional version would certainly need it.

About Luna: my girlfriend changed to the "Classic" look on her PC after a few months. Her 7 year old daughter still uses Luna. (Large buttons? Bright colors? Does anyone really believe MS choose those to please people older than ten?)

Me, I wouldn't want to switch from 2000 to any other Windows version. (But I could do without any Microsoft OS.)

L'enfer, c'est les huîtres.


[ Parent ]
Sigh... (none / 0) (#31)
by mech9t8 on Tue Sep 10, 2002 at 10:52:57 PM EST

where the fsck is a simple FILE PERMISIONS property sheet?

Tools -> Folder Options -> View -> uncheck 'Use Simple File Sharing'

Luna, OTOH, has a horribly barfucious color scheme (like someone tried to copy Aqua, but completely missed the point)

Just because it's ugly doesn't mean it's an attempt to copy Apple.  I mean, it's looks absolutely nothing like Aqua.  At all.  Not even a bit. ;)

--
IMHO
[ Parent ]

Ok, then (none / 0) (#32)
by locke baron on Wed Sep 11, 2002 at 01:07:06 AM EST

Well, thanks for pointing out the option. I don't use XP with any regularity (the work boxen run NT4, and I use 2K at home when I use Windows at all (mostly for games - I do all my real work in Linux or BSD)). As for copying Aqua, note the following: WinXP was released hot on OS X's heels, probably to counter the damaging effect a Real OS with a good GUI could potentially have on MS's mindshare/marketshare. Further, I was mostly talking about the overall 'candybubble' appearance. But you're right, Aqua is way better looking. But hell, I think they both stink. NeXTSTEP had one of the best widget sets out there, one very worthy of emulation. (BeOS had a good one too, and Mac Platinum is quite functional, but neither had the NeXTSTEP scrollbar feature, that I can remember (arrows on one end, and thumb jumps under the mouse if you click in an empty section of scrollbar. GTK+ needs to do that!)

Micro$oft uses Quake clannies to wage war on Iraq! - explodingheadboy
[ Parent ]
Thumb jump under mouse click (none / 0) (#33)
by HoserHead on Wed Sep 11, 2002 at 03:08:05 PM EST

Try middle-clicking on the trough (I think that's what the term is) instead of left-clicking: the thumb jumps to where you have middle-clicked. This works in Mozilla, too, so you don't have to retrain yourself at all.

[ Parent ]
NeXT influenced Aqua (none / 0) (#34)
by fenix down on Wed Sep 11, 2002 at 06:11:02 PM EST

Aqua lets you use the nextstep scrollbar style. I think it's set on the old mac/windows style by default, but there is an option to put the arrows on one end or the other and make the bar skip instead of page down. Jobs didn't let NeXT die that easily.

[ Parent ]
actually... (none / 0) (#35)
by fenix down on Wed Sep 11, 2002 at 06:17:09 PM EST

Now that I have NeXT on the brain, I really can't think of any major NeXTSTEP UI feature that isn't used at least a little in Aqua. Aqua just gets rid of all the corners. NeXT had the dock, the wierd file manager where folders open as columns in the same window, and probably other stuff I can't think of since my knowledge of NeXT is mostly based on the skins it inspired...

[ Parent ]
Well, that makes perfect sense (none / 0) (#37)
by locke baron on Fri Sep 13, 2002 at 02:02:26 PM EST

MacOS X might be better termed either Rhapsody 2.x or OpenStep 6, so the NeXT inspiration is totally logical.

Micro$oft uses Quake clannies to wage war on Iraq! - explodingheadboy
[ Parent ]
I think you are confusing "users" and &q (3.33 / 6) (#10)
by a life in hell on Mon Sep 09, 2002 at 06:44:35 AM EST

You make the statement that allowing the user to chose their own colours reduces their choice, in that it reduces the application developers choice of colours with which they can bombard the user. I claim that this is no bad thing... I *like* that my desktop is blue, and it is not up to you as a developer to take that choice away from me, because *you* find green more astetically pleasing. Just because you are a "designer" or whatever you call yourself, does *not* mean that your choice is nessesarily correct. Reducing options does not increase choice, go read a dictionary or something.

That's what UI design is for. (4.50 / 2) (#11)
by carlfish on Mon Sep 09, 2002 at 07:47:37 AM EST

By reducing the vocabulary available to developers, you reduce the ability of the developers to create applications with custom controls (in the skinnable UI toolkit world), or to produce application add-ons that introduce new UI elements consistent with the existing interface (in the skinnable application world). In that way, the richness and variety of application available to the user is reduced.

Thus, skinnability is a trade-off. You give the user the ability to choose to give their mp3 player H R Giger buttons if they want to, but at the cost of reducing the richness of interface available to them, and tying their upgrade-path to the skin developer. You trade in power, you get back ‘pretty’. You get your choice of ways to look at Mozilla, but you don't get your choice of add-ons that might conflict with the user's chosen chrome.

Whatever you think is important, I guess.

Charles Miller

--
The more I learn about the Internet, the more amazed I am that it works at all.
[ Parent ]

costs (3.66 / 3) (#15)
by ucblockhead on Mon Sep 09, 2002 at 12:05:22 PM EST

If you are properly seperating your UI from the rest of your code, you should not have to sacrifice much in the way of richness.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Are you sure "skinning" is the problem? (3.20 / 5) (#12)
by zerth on Mon Sep 09, 2002 at 09:10:23 AM EST

If a coder adds a new button to an application, it's the responsibility of the author of a skin to create a new image for it, not the coder.

Furthermore if a skinning vocabulary doesn't support the adding of further buttons, it's not "fully" skinnable in my book.

  Ex: litestep(a shell replacement for windows).  If I want a new feature for the desktop or the wharf(LS version of the start button), I just write it. If I'm in the mood, I'll make an image for it for my current skin of choice, if not I'll use one of the generic buttons for that skin.

  If I share that feature and it is a popular feature, skin designers will add it to their skins.  If it isn't, those who use it will either just use one of the generic buttons provided with their favorite skin(If the skin doesn't come with at least 1 generic button for the wharf, the skinner was lazy)

If I dislike where a current button is, I pop up the config, change the position and save(I'm sure there is a configurator that lets you just grab it with your mouse and move it, but I'm lazy)


Rusty isn't God here, he's the pope; our God is pedantry. -- Subtillus

MVC and toys (4.16 / 6) (#13)
by revscat on Mon Sep 09, 2002 at 10:46:17 AM EST

I am fully aware of the necessity to separate form from function, and any good coder should do this with any app, whether it is a web application or a shrink-wrapped software package. However, I do not believe that skinnability is desirable in anything other than "toys", such as MP3 players, IM clients, and so forth. Yes, I realize toys is somewhat derogatory. I use these toys daily, and like to play with their appearance occasionally.

But. When it comes to the applicaitons that I use for my job, I for one have no desire for the application to be skinnable. Would I want there to be any effort expended on making my IDE skinnable? Or MS Money? Outlook? Nero? Not really, no.

I understand that some people like having a skinnable application, and that this is largely a matter of personal preference. But there are some applications that skinning just does not seem to make sense for, however neato keen the eye candy may be.



- Rev.
Libertarianism is like communism: both look great on paper.
Not just toays (4.00 / 3) (#16)
by ucblockhead on Mon Sep 09, 2002 at 12:05:38 PM EST

I've found "skinning" techniques useful in non-toy apps in a couple of different ways. First, I've worked at places where the software had to be "branded". That is, company X licenses its software to company Z, slapping on whatever look and feel company Z requires in the process.

The second is more important. When you use skinning techniques, you can react very rapidly to changing UI requirements.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Accessibility (3.00 / 4) (#14)
by brunes69 on Mon Sep 09, 2002 at 11:41:24 AM EST

Your article forgets one very vital component that any GUI designer must consider, and that is accessibility. One cannot depend on color alone to distinguish any particular element on the screen from another, just as one should not use only graphical elements for navigation, omitting the keyboard in their interface. What about screenreaders and the like?

Aside from that, skinning is not as difficult as you purport it to be. Just look at how skinnable the Qt toolkit, which KDE uses, is. You can reshape any button, change any color, even make it transparent, all without modifying your application source at all.



---There is no Spoon---
Third paragraph, first two sentences: (4.00 / 1) (#19)
by sage on Mon Sep 09, 2002 at 12:37:50 PM EST

Using colours in a User Interface can be a bad thing if the colour-choice is bad (making for an ugly application), or if colour is the only thing that distinguishes a particular element (making the feature unuseable for the visually impaired).

[ Parent ]
I hate skins (4.14 / 7) (#17)
by Mwongozi on Mon Sep 09, 2002 at 12:08:39 PM EST

Skins are a stupid idea, IMHO. I want all the applications on my computer to work consistently and using the same rules, so that I only have to learn how to use "my computer", and not each application individually.

Each app should use standard controls, and none of this skinning rubbish, it's just too confusing. I don't care if my computer's desktop looks pretty, I just want it to work.

A good argument for system-wide skins (3.66 / 3) (#20)
by Wateshay on Mon Sep 09, 2002 at 01:45:25 PM EST

You make a good point, and I agree that there is significant advantage in having the whole system work the same. I like it when all of my applications look and act the same. On the other hand, I'm also very concerned about my computer looking good. I don't want to spend 10-14 hours looking at something ugly. My idea of pleasing also isn't the same as everyone else's. The ideal solution, as I see it, is good system wide themability with a good usable default.

"If English was good enough for Jesus, it's good enough for everyone else."


[ Parent ]
App skins suck. (4.00 / 5) (#21)
by Karellen on Mon Sep 09, 2002 at 01:51:06 PM EST

But what's worst is an app that doesn't have a `native' skin, and uses it's own window decorations all the time. It's one of the things I really don't like about xmms.

I want the title bar to look the same as all my other windows, but no, it has to be different. So I'm stuck looking for a skin that looks the same as my window manager decorations every time I change my WM theme, or when I change WM.

If you really need a control that's not part of your standard toolkit, OK, create one. But at least submit it back to the TK maintainers for inclusion in the next (relevlant) release, so all the skinners will make it look like everything else on your desktop. Or at least like everything else created with that TK.

Ditto. (3.00 / 1) (#24)
by dilinger on Mon Sep 09, 2002 at 07:14:01 PM EST

That's why I use (and develop) sinek; I like my mp3 player to match my Gtk+ theme (which then makes it match my browser, my aim client, my terminal...)

[ Parent ]
borders (4.00 / 1) (#27)
by bags43 on Tue Sep 10, 2002 at 06:22:29 AM EST

I want the title bar to look the same as all my other windows, but no, it has to be different. So I'm stuck looking for a skin that looks the same as my window manager decorations every time I change my WM theme, or when I change WM.

In most window managers you can set the window to different styles, one of which is borderless (if that's what it's called), which is the xmms default. So you should be able to set it to bordered too, which will give the window a border like so many others.

[ Parent ]

Function vs uniformity (4.50 / 2) (#23)
by I am Jack's username on Mon Sep 09, 2002 at 06:50:56 PM EST

Mozilla 1.1 has an "Open a new tab" button which doesn't show up using an 1.0 skin. I think hackers should always include an option to display the new widgets even if the skin doesn't yet have a pretty glyph for it. Having to discover the new button by wading thru the "new features" list, or accidentally seeing it on a standard install is not acceptable. Guess who won't be using 3rd party skins.
--
Inoshiro for president!
"War does not determine who is right - only who is left." - Bertrand Russell
Surely anyone developing... (3.33 / 3) (#36)
by Sesquipundalian on Wed Sep 11, 2002 at 10:58:57 PM EST

something as large as a full scale commercial grade application (you know... everything works properly!), with documentation, UI/ENGINE separation and a defined development cycle, can handle the slight abstraction of thought required to handle the task of pairing colors, textures and pictures to backgrounds, menus, buttons, borders and various other large number properties of their application's problem domain.

The onus of ensuring consistent functionality across all possible skins falls with the developer, use-ability of a particular skin rests on the individual designing that skin (obviously the developer is expected to supply a use-able example or two).

To those who cry that making everything skin-able is too hard, If people don't use the application that often then don't bother. If you want to steal MS Office's market share with an embrace 'n extend that everyone will use, might I suggest skin-ability?, I find it very nice to be able to control the appearance of things I have to look at a lot, this makes it nicer for me to use my computer.

Personally I love skin-able applications so much that as of my company's most recent project (we write custom software for small businesses), everything we do with our user interfaces will go through a set of libraries that specifically support skin-ability. Among other things, it makes explaining, separated billing for design and development, to your customers, that much easier. And since our products tend to sit in retail locations, the skin-ability is actually a key selling feature.

Also remember that the concept of skinning is scaleable. Even simply making sure you use the default system colors in a consistent way is a nice thing to do.

In order to skin an application, you have to totally separate the UI from the rest of the application. Being forced to do this actually speeds up your development time.

You also have to separate UI performance (number of actions required of the user to complete a given task, etc.), from UI communication (color scheme, contrast, font size...). Both products of this little symmetry break are skin-able by themselves (the former by configurable, re-position able tool bars and the like, the latter a-la winamp style skins and color schemes.

My girlfriend says that certain nerds always criticize the cool flashy stuff and say that it's un-necessary, she says that these are the same nerds that don't understand hygiene or fashion either. So put good UI's in your applications, chicks dig it (and also, although my heart is already spoken for, I must admit that I'm more attracted to female coders that take the time give good, thorough UI).

As far as the disabled thing goes, skins can be used to make a UI more accessible, by designing a skin that is more accessible. You make compromises when you do that. As far as a skinning model that is always really accessible to the handicapped regardless of the skin, we may wait a for more years for that one .


Did you know that gullible is not actually an english word?
On Being Skinned | 37 comments (35 topical, 2 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!