is it worth keeping the OS look and feel ?

Question

Is it worth to try to keep your GUI within the system looks ?

Every major program have their own anyways... (visual studio, iexplorer, firefox, symantec utilities, adobe ...)

Or just the frame and dialogs should be left in the system look 'n feel range ?

update:

One easy exemple, if you want to add a close button to your tab, usually you make it against your current desktop theme. But if the user has a different theme, your close button is out of place, it doesn't fit the system look anymore.

I played with the uxtheme api, but there is nothing much you can do, and some themes i've seen are incomplete sets.

So to address this issue, the best way i see, is to do like visual studio/firefox/chrome roolup your own tab control with your theme...

Answer 1

If you are on (or develop for) a Mac, then definitely YES!

And this should be true for Windows also.

Answer 2

I think, that unless your program becomes a very major part of the users life, you should strive to minimize "surprises" and maximimze recognizability (is that even a word?).

So, if you are making something that is used by 1.000 people for 10 minutes a day, go with system looks, and mechanisms.

If, on the other hand, you are making something that 100 people are using for 6 hours a day, I would start exploring what UI improvements and shortcuts I could cram in to make those 6 hours easier to deal with.

Notice however, that UI fixes must not come at the expense of performance. This is almost always the case in the beginning when someone thinks that simply overriding the OnPaint event in .Net will be sufficient.

Before you know it you are once again intercepting NC_PAINT and NC_BACKGROUNDERASE and all those little tricks to make it go as fast as the built-in controls.

Answer 3

It depends on how wide you would define system look'n feel... But in general, you should keep it.

Do not surprise the user with differentiating from what he is used to. That's one of the reasons why we call him user ;-)

Firefox and Adobe products usually don't because they are targeting several plattforms which all have their own L&F. But Visual Studio keeps the typical Windows L&F. And, as long as you are developing only for Windows, so should you.

Answer 4

Apart from the fact that there is no well-defined look-n-feel on Windows, you should always try to follow the host platform native L&F. Note however that look-n-feel is just as much about how a program behaves as how it looks. Programs which behave in a counter-intuitive way is just as annoying as programs sporting their own ugly widgets.

Fraps is a good example (IMHO) of a program which is actually very useful, but breaks several user interface guidelines and looks really ugly.

Answer 5

Yes, if only because it enables the OS to use any accessability features that are built in like text-to-speech. There is nothing more annoying for someone who needs accessability features to have yet another UI that breaks all the tools they are used to.

Answer 6

I'd say it depends on the users, the application and the platform. The interface should be intuitive to the users, which is only the same as following system UI standards if they are appropriate for those users. For example, in the past I have been involved in developing hand held systems for dairy and bread delivery on Windows CE hand helds. The users in this case typically were not computer literate, and had a weak educational backround. The user interface focussed on ease of use through simple language and was modelled on a pre-existing paper form system. It made no attempt to follow the Windows look and feel as this would not have been appropriate.

Currently, I develop very graphical software for a user group that is typically 3rd level educated and very computer literate. The expectation here is that the software will adhere to and extend the Windows look and feel.

Software should be easy and intuitive where possible, and how to achieve this is entirely context dependent.

Answer 7

I tend to agree with others here- especially Soraz and Smaci.

One thing I'll add, though. If you do feel that the OS L&F is too constraining, and you have good grounds for going beyond it, I'd strive to follow the priciple of "Pacing and leading" (which I'm borrowing here from an NLP context).

The idea is that you still want to capitalise as much as possible on your intended audidences familiarity with the host OS (there will be rare exceptions to this, as Smaci has already covered). So you use as much as possible of the "standard" controls and behaviours (this is the "pacing") - but extend it where necessary in ways that still "fit in" as much as possible (leading).

You've already mentioned some good examples of this principle at work - Visual Studio, even Office to some extend (Office is "special" as new UI styles that cut their teeth here often find their way back into future OS versions - or de-facto standards).

I'm bringing this up to contrast the type of apps that just "do it their way" - usually because they've been ported from another platform, or have been written to be cross-platform in GUI as well as core. Java apps often fall into this category, but they're not the only ones. It's not as bad as it used to be, but even today most pro audio apps have mongrel UIs, showing their lineage as they have been ported from one platform to another through the years. While there might be good business reasons for these examples, it remains that their UIs tend to suck and going this route should be avoided if in any way possible!

The overriding principle is still to follow the path of least surprise, and take account of your user's familiarity with the OS, and ratio of their time using your app to others on the OS.

Answer 8

I'd like to reply with another question (Not really Stackoverflow protocol, but I think that, in this case, it's justified)

The question is 'Is it worth breaking the OS look and feel?' In other words,

1. Do you have justification for doing so? (In order to present data in some way that's not possible within normal L&F)
2. What do you gain from doing so? (Improvinging usability?)
3. What do you lose from doing so? (Intuitiveness & familiarity?)

Don't simply do it 'To be different'

Answer 9

If you're developing for Apple's Mac OS X or Microsoft Windows, the vendors supply interface guidelines which should be followed for any application to be "native".

See http://stackoverflow.com/questions/268532/are-there-any-standards-to-follow-in-determining-where-to-place-menu-items for more information.

Answer 10

In general, yes. But there's the occassional program that does well despite being not formatted for all the OSes it runs on. For example, emacs runs pretty much contrary to every interface guideline on OS X or Windows (and probably even gnome/KDE) and it's not going away any time soon.

Answer 11

I strongly recommend making your application look native.

A common mistake that developers who are porting an application to a new platform seem to make is that the new application should look-and-feel like it does on the old platform.

No, the new application should look-and-feel like all the other application that the user is used to on the new platform.

Otherwise, you get abominations like iTunes on Windows. The same UI design may be exactly right on one platform and very wrong on the next.

You will find that your users may not be able to pin-point why they dislike your application, but they just feel it hard to use.

Yes, there are valid exceptions, but they are rare (and sure enough, they tend to be the major applications like Office and Firefox, rather than the little ones). If you are unsure enough to have to ask on StackOverflow, your application isn't one of them.