Saturday, February 7 2009, 16:25
Application skinning and user-interface consistency
To be remarked and distinguished, one's products must be clearly different from the others: it is a fact of marketing. When applied to software, there are two main kind of differentiation possible: the invisible to the eyes, yet noticeable, differences, such as better internal engineering and better performance, and the visible ones, most particularly the user-interface. In operating systems supporting windowing systems, the user-interface is one of the most important aspects of the product because it is the interface between the user and the machine: this interface thus needs to be both pleasing to the eyes but still ergonomic and efficient for the user to be able to accomplish his duties as quickly as possible.
Having one’s application stand out from the others is maybe a good thing for marketing, but what happens when every application on the system wants to look different from the other in term of user-interface of the system taken as a whole? This is what we are going to see through this argumented rant, with the help of some applications examples, and try to see whether the short-term benefits of these moves are worth the longer-term inconveniences of inappropriate user-interface skinning.
First case: “I want to look like the very newest thing available, even though it doesn’t suit your system”
Here is one of the application I have on my system “PDF Password Cracker Pro” which is able to recover/remove the password protection of some PDF files. The purpose of this application here is irrelevant, so let’s only look at its user interface.
As we can see, it is deeply inspired of the Windows XP “Luna” theme, while still looking a bit different from the ones provided by default on Windows XP, with this gold-ish color probably aiming to show it is a superior application. The first question we can ask ourselves is why such a mundane, single-purpose oriented application needed to be skinned in the first place… but as we have seen in the introduction, it’s all about marketing and showing your application is better on the first sight. Indeed back when this application was released, Windows 98 was still around and installed on a lot of systems and the authors probably thought that users would be happy to have a taste of the future by having an application with the XP-look enabled by default. “By default”… I’m not sure it is the appropriate word here since there is no setting to revert back to an unskinned user-interface, like too much often. Anyway, let’s fast forward to nowadays and imagine how this application looks on Windows Vista now? Like an outdated piece of rusty junk. Indeed, what the authors forgot to take into account is that what is considered the future at some point soon becomes the present and then the past. Had the developers have some self-restrain and pointlessly skinned the application, it would now enjoy looking perfectly fine on Vista and support Aero without the need of a single change in the application’s code. In other words, to please some Win98-users some years ago, this application today suffers a stuck and outdated user-interface.
Looks is one thing, but ergonomics and UI-features another: one thing I noticed a lot in shamelessly skinned applications is that they lack some common windowing features. There are different methods to skin an application and some require that the developers to rewrite a good part of the window management features normally provided naturally by the OS, such as the maximize/minimize/restore behavior, the context menus in the title bar and so on. Sure enough, right clicking on the title bar of this application doesn’t show the usual contextual menu, probably something the author forgot to implement or simply never used himself so didn’t bother implementing it for the other users. A pointless skinning is one thing, but a pointless skinning reducing the usual feature set that can be expected on usual applications is much worse. It reminds of a payroll software we had in our company, whose authors decided that the default edit control provided by Windows wasn't good enough... strangely it didn't look much different, although slightly worse (as if it had been badly reproduced) but didn't bother to implement copy/paste feature on that control, something which is automatically supported on the default Edit controls provided by Windows. In the end, we changed that software because this particular shortcoming was way too annoying and time-consuming for our payroll operator who frequently needed pasting a similar string of data in that software.
To come back to that PDF password recovery software, needless to say that this application doesn’t care a single second of accessibility features for disabled people, especially the visually-impaired ones, by completely ignoring the appearances settings the user could have defined in Windows.Second case: "I wrote a popular application, people are happy with it, but I’ve implemented almost every feature I could thing of but I still need to sell new versions…”
Here, I’ll talk about another application I use and like: SnagIt. SnagIt is (or rather used to be) a nice application for taking screenshots and do some basic editing on them. In my job, I find myself sometimes in need to document something while sending an e-mail to someone and sometimes, the best way is to show a window with some arrows on where the user should click to obtain the feature he wants. SnagIt is much quicker than opening Photoshop just to add a couple of good-looking arrows to a screen capture. The problem here for the authors was that this software is pretty mature and there isn’t a load of stuff you can add to a screen capture application once you’re done with it. Obviously, the software economy requires you to sell newer versions once in a while to keep making money from your product, so the SnagIt authors thought it could be a good idea to completely skin their application and sell it as “new and improved”.
Obviously, like many other developers out there, they decided to implement the controversial ribbon (which Fred has already blogged about in this article) to their application. The ribbon is something you either love or hate and I’m yet to stumble into someone that doesn’t really have an extreme opinion about it. Let’s be clear here, I hate the ribbon with a burning passion, mostly because it takes away from the compactness of traditional menus and gets quickly messy if you add too much items on it, but my biggest concern about it is that on most applications using it, there is no choice to disable it to get the traditional menu back. The ribbon was first introduced in MIcrosoft Office 2007 and it happens that every time a new Office version is released, its user-interface turns into some kind of fashion-model for the other developers and Microsoft even released a free WCF ribbon component to make sure the fashion would spread.
As I said, the ribbon is either hit or miss and isn’t really skinning-per-se: it is just a component, but the SnagIt developers decided to mimic the Office look as far as using its themes principle. Again, this skin can’t be disabled and looks completely ugly and out of place on “Windows Classic” or “Luna”.
What would be interesting now for this second case would be to see how the users reacted to the change of user-interface from version 8 to version 9. Fileforum is a download site where comments are pretty active and the SnagIt page on this site doesn’t lack of harsh comments regarding how bad the new user-interface is and how bloated the program has become. So much effort to only face rejection in the end…
I could go on with a dozen more of examples but I think these two are enough to show how much irresponsible UI-skinning can hurt in terms of performance, application’s reputation, and global user-interface consistency of the whole system. I think the latter is the biggest concern, since a computer contains a lot of programs that are supposed to interact nicely with each others both in term of technology (software conflicts) and in terms of looks. The OS defines its own windows style which can be globally customized through the OS-preferences but if every application decides to look different from each other and completely ignore the OS settings, the whole thing can look very messy and uneasy for the end-user. At any rate, any skinned-by-default program should have a way to be reverted to the OS-default to avoid this problem.
To close this article, here is a little list I would like for the developers around the world to consider thinking about before they go on and customize their application and which summarizes a lot of what has been said above.
- Skinning for today fashions might cause your application look plain old ridiculous in two or three years.
- Enforcing unchangeable skins and major interface changes (ribbon) without providing a way for the users to change how the interface looks show you don’t care about what they think or how they want to work. It is applying the “the user must fit the application” principle rather than the much better “the application must fit the user” one.
- You simply don’t care about disabled/visually-impaired people. If Microsoft and other Operating Systems developers implemented Accessibility features, it might not have been without purpose, so please don’t write your application in a way that overrides the accessibility settings.
- You look pretentious: what makes you think your application has the right or is so much better to look completely different from the others? It isn’t kind of cool… well, seeing this picture, I think it reminds me of how your application actually looks.
- Skinning requires CPU-cycles and is usually a memory hog (bitmap caching, double-buffering to avoid flickering when moving the windows). If your application is memory hungry, users will notice that and complain on download sites by posting not-so-nice comments. You also pointlessly raise the application’s hardware requirements which lowers your potential customer base.
- You risk to implement bugs: any code written is a chance to implement bugs, so you might as well not write “pointless code” (in most cases, it is not much better than easter-eggs). You also risk to forget about features you don’t know about or use but that are implemented by the OS by default on unskinned windows which results in frustration and annoyance for the users actually knowing about it and using it.
- If the customers do not like your user-interface, you have lost countless hours or development only to face rejection. Since putting so much work out the window (pun not-intended) is a difficult decision to make, you might take the worst decision possible and decide to ignore them and keep going…. whether they like it or not… Too bad you didn’t spend this time working on actual features…
- Even if you simply purchased a third-party-developed component-kit for the skinning, these are expensive and are going to be charged to the customer by increasing the price of your application, once more reducing your potential customer-base.
- If you still want to add skinning no matter what, make sure you have a decent reason to do so (artistic-oriented program like a music player: one of the only cases where this feature is admittedly an advantage) and make sure that the user can disable or change the skins and download new (possibly user-supplied) ones from the application’s web site.
I think it could make the computing world a slightly better place, but I don’t have much hopes.