AboutJoinDiscussionMembersLocal
 
Matt Doe

Hi everyone,

We are charged with the redesign of a cross platform (Windows, Mac and Linux) application. From data we've collected, we know about 93 percent of users are Windows users, 6-7 percent are Mac and the remaining 1 percent are some flavor of Linux.

The application was originally written to have a native look and feel and users have been used to that for the past 6 years. We have moved onto the visual design phase and we are torn between going completely native, or doing a non-native feel across platforms.

Certain windows applications like Picasa have a non-native look and feel, but they can get away with this very easily because it still follows a lot of windows conventions like the primary color being a shade of grey and using soft borders around buttons, etc...

Then you have the polar opposite like iTunes on windows or even more extreme, some Adobe Air applications like eBay desktop, where the look-and-feel deviates so far from the platform it just feels awkward to use it. What I find interesting is that web applications have a non-native look-and-feel (gmail, facebook, etc...), but they are no less usable and don't feel awkward to use. Maybe it's because it's wrapped in a native browser?

Does anyone have any research or experience about the usability of non-native look-and-feels across different platforms?

Thanks!

Katie Albers

Hi,

Color me confused. What exactly do you mean by native? Do you mean you've designed a different interface for each platform (which is what I usually understand native to mean in this context) or do you mean that you're designing a single interface for all 3 that is native to some unspoken standard platform, or do you mean that it's "native" in relation to the browser (which is also problematic, since browsers have differing characteristics in their interfaces)?

In general I think "nativity" is an over-rated characteristic. It's merely a tool to help users learn an interface more quickly. That goal can often be achieved through a variety of other methods in interfaces which enable different tasks, and it's not unheard of for "native" interfaces to impede usability in those cases where the native didn't anticipate the use or the user group or the technology.

But all of that is subject to how you're using the word. Since you seem to have a large user group, you should have enough to run low level prototypes by them (since you're considering visual design at this point, I'd probably mock up a couple of pages in each option and ask the users to narrate their way through the pages: "What's clickable" "What would happen if you clicked it" etc) and see what works best.

Katie

At 3:51 PM -0400 9/9/08, Matt Doe wrote:
Hi everyone, We are charged with the redesign of a cross platform (Windows, Mac and Linux) application. From data we've collected, we know about 93 percent of users are Windows users, 6-7 percent are Mac and the remaining 1 percent are some flavor of Linux. The application was originally written to have a native look and feel and users have been used to that for the past 6 years. We have moved onto the visual design phase and we are torn between going completely native, or doing a non-native feel across platforms. Certain windows applications like Picasa have [trim]

Jarod Tang

Hi Matt,

Take eclipse (www.eclipse.org) example, they have the native look and feel at every platform, but at the same time, keep the interaction (behavior) as uniform as possible, which definitly help it's user experience.
But the key here, is
1, first the user experience is uniform

2. second, the native look and feel Many guys in this forum may tell you, the first factor is far important than second from different perspective, but the core may lat at the native look and feel have little to do with usability, until it will harm the interaction significantly.

Cheers,
-- Jarod

On Wed, Sep 10, 2008 at 3:51 AM, Matt Doe mysocalledmike at gmail.com wrote: Hi everyone, We are charged with the redesign of a cross platform (Windows, Mac and Linux) application. From data we've collected, we know about 93 percent of users are Windows users, 6-7 percent are Mac and the remaining 1 percent are some flavor of Linux. The application was originally written to have a native look and feel and users have been used to that for the past 6 years. We have moved onto the visual design phase and we are torn between going completely native, or doing a non-native feel across platforms. Certain windows applications like Picasa [trim]

-- Designing for better life style.

http://jarodtang.spaces.live.com/
http://jarodtang.blogspot.com

Matt Doe

Thanks Katie,

By native, I mean this mostly as a programmer term. In a Java application, you can set the look-and-feel to be native, meaning the interaction will be identical across platforms, but instead of drawing a button the way the program wants to, it will know to render a button that looks like a windows button on windows and a button that looks like an OS X button on Mac. In terms of designing the entire interface natively (meaning following OS X design guidelines on Macs and Vista guidelines on Vista), we aren't going to be doing that.

So we are designing a single interface from an interaction standpoint, same layout, same navigation, etc...but in terms of the visual style of the application, we are torn whether to say "lets pick a visual style" and make it look that way on all 3 platforms, or whether to say "lets make this look like a windows app in windows, an OS X app on Macs, etc...Also, this is a desktop application, so there is no interaction with a browser at all. Have you had to design desktop apps that supported multiple platforms before, and if so, what was your solution?

Thanks Jared,

I agree 100 percent. But even if the interaction is solid, I feel like once you deviate too far from the OS look-and-feel, it starts feeling awkward to interact with a desktop application...that is why applications like Pownce ( http://pownce.com/ ) did a redesign of their adobe air application. It looked so much like a widget sitting on a desktop rather than a desktop application that in their redesign, they striped it down to have more or a windows look-and-feel. Do you think that if eclipse rendered it's own kind of buttons instead of a windows button it would feel completely awkward to use?

On Tue, Sep 9, 2008 at 8:38 PM, Jarod Tang jarod.tang at gmail.com wrote: Hi Matt, Take eclipse (www.eclipse.org) example, they have the native look and feel at every platform, but at the same time, keep the interaction (behavior) as uniform as possible, which definitly help it's user experience. But the key here, is 1, first the user experience is uniform 2. second, the native look and feel Many guys in this forum may tell you, the first factor is far important than second from different perspective, but the core may lat at the native look and feel have little to do with usability, until it will harm [trim]

Nathan

Design for both. I would say that is the norm. And it is a good idea, because you are designing an interface that is more familiar to the user.

Jack Leon Moffett

Matt,

I think what you are describing here has a lot to do with expectations. As a Mac user, I expect an application that I install and run locally to look and behave like a standard Mac app following Mac OS conventions. When I use an app that has been poorly ported from a Windows version, and it has, say, the Okay button on the left and the Cancel button on the right, it annoys me. However, when I'm using a web app, I don't expect it to look or behave like my desktop apps. Certainly, there are still conventions that I expect it to follow, but I am more open to "different" UI patterns.

Best, Jack

On Sep 9, 2008, at 3:51 PM, Matt Doe wrote:

Certain windows applications like Picasa have a non-native look and feel, but they can get away with this very easily because it still follows a lot of windows conventions like the primary color being a shade of grey and using soft borders around buttons, etc... Then you have the polar opposite like iTunes on windows or even more extreme, some Adobe Air applications like eBay desktop, where the look-and-feel deviates so far from the platform it just feels awkward to use it. What I find interesting is that web applications have a non-native look-and-feel (gmail, facebook, etc...), but they [trim]

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

Design is like California.
No one is born there.

-Dick Buchanan

Jarod Tang

Thanks Jared,

Sorry, I'm Jarod instead of another Jared from this list. : )

But even if the interaction is solid, I feel like once you deviate too far from the OS look-and-feel, it starts feeling awkward to interact with a desktop application...that is why applications like Pownce ( http://pownce.com/ ) did a redesign of their adobe air application. It looked so much like a widget sitting on a desktop rather than a desktop application that in their redesign, they striped it down to have more or a windows look-and-feel. Do you think that if eclipse rendered it's own kind of buttons instead of a windows button it would feel completely awkward to [trim]

I agree with you that look and feel affect the user ( it's obvious by comparing eclipse/SWT with the Sun/AWT,). And to achieve this, it's more like a widget selecting problem, like you use wxWidgets or rcp as development foundation.

Cheers,
-- Jarod
-- Designing for better life style.

http://jarodtang.spaces.live.com/
http://jarodtang.blogspot.com

Andreas Ringdal

I think it is more important to keep the core functionality and the process of using the application the same on all platforms.

I use Evernote both on Windows, OS X, iPhone and Web, and what really annoys me is that it behaves differently. When creating a new note, the windows version automatically adds the first line as a title and to tagg the note, I have to open a separate window. The OS X and iPhone versions both have separate fields for title and tags.

My opinion: make the application look native, but behave the same way.

Andreas

Jared Spool

On Sep 10, 2008, at 2:02 AM, Jarod Tang wrote:

Thanks Jared, Sorry, I'm Jarod instead of another Jared from this list. : )

That would be me, I guess.

This isn't a question about native vs. non-native. As Jack mentioned, it's about leveraging the experience and perceptions of the user.

Buttons, scroll bars, radio buttons, check boxes, and other commonly used design elements become part of the user's landscape. When they are new, they have to learn how to interact with them, since it's not knowledge they are born with.

Over time, they realize these always work the same and become adept to their usage.

When you change what they are used to, it creates a focus disruption for them. For example, when a new and novel scroll bar is created in a Flash application, the user has to stop thinking about the content they want the scroll (such as the article) and now focus their efforts on learning the new scroll bar. If it looks and behaves substantially different from what their experience has been, it will take more attention to do things that normally would go on peripherally.

So, when you're abandoning "native" elements, what you're basically doing is abandoning that previous users experience. This isn't necessarily a bad thing, but it is something that you should be very conscious of in your design. If you don't have a good reason to do so, you probably don't want to.

If you do feel you have a good reason, you want to make sure you've done it well. Elements, such as scroll bars, have very subtle behaviors that operating system designers have refined over a really long time, such as how it interacts with a scroll wheel. When the element doesn't behave the same way, it disrupts the user abruptly, probably at a point in the interaction where you, as the designer, don't really want them distracted.

Substantial usability testing is a requirement here. I wouldn't go "non-native" without it.

Hope that helps,

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845 e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks

Jarod Tang

So, when you're abandoning "native" elements, what you're basically doing is abandoning that previous users experience. This isn't necessarily a bad thing, but it is something that you should be very conscious of in your design. If you don't have a good reason to do so, you probably don't want to.

This hits the core the question.

Cheers,
-- Jarod

Håkan Reis

I would say, It depends:

It depends on the application; A game usually deviates a lot from native interaction. There are other applications that often do the same for example 3D modeling software. But the more "generic" controls you use in the application the more important it is to make it native to the operating system.

The example if iTunes, yes they keep it the MAC way and if it wasn't for their strong ties to iPod and iTunes music store I see very little that would make people use that as their media player. I think people put up with it just because the services it provides, not for the interaction in it. I use it myself and always feel lost as soon as I try to change sedttings etc.

// Håkan

Håkan Reis
Dotway AB
+46(768)510033

My blog || http://blog.reis.se
My company || http://dotway.se
Our conference || http://oredev.org - See you in 2008

Matt Doe

Hakan, A agree about games because the experience is very different. You are trying to create an environment for them to get lost in rather than a user interface to use. The game play should be the only thing the user is focusing on which should making the user interface transparent to the player. I still think games have some of the best designed (and hardest to design) user interfaces.

Jared, I agree about things such as flash scroll bars, but there are a lot of web applications out there that use a combination of native and non-native components and they are very usable. Even applications like Picasa 3 ( http://picasa.google.com/ ) does everything non-native, but it does it so subtly that I feel the user doesn't really notice.

Here is the problem with keeping a windows application completely native.You end up with an application that looks like this: http://pcwin.com/media /images /screen /AVG _Anti _Virus _Free _Edition _7 _5 _1010.png

Do you think there can be some kind of compromise to have it be visually appealing in windows without decreasing the usability?

On Thu, Sep 11, 2008 at 5:06 AM, Håkan Reis hakan.reis at dotway.se wrote: I would say, It depends: It depends on the application; A game usually deviates a lot from native interaction. There are other applications that often do the same for example 3D modeling software. But the more "generic" controls you use in the application the more important it is to make it native to the operating system. The example if iTunes, yes they keep it the MAC way and if it wasn't for their strong ties to iPod and iTunes music store I see very little that would make people use that as their media player. I think [trim]

Sascha Brossmann

I would like to argue in favour of %u201Cnative%u201D [1]. At least in the regular case: messing around with my motoric memory, my system's default shortcuts, my system's standard widget
look/behaviour/positions etc. is not likely to earn you good credits ;-) And, as frequently in design, it is details that count here: often the tiny well-dones/annoyances, that do not seem important/disturbing enough to be credited or reported, have a large impact on everyday satisfaction with an artefact/product/process. (I do not have the source at hand, sorry, IIRC it was somehow related to David Gilbert's research on happiness.)

Some of the few exceptions have already been stated above: a) games, b) web apps (at least partly), and c) scenarios where your average user uses your application across several platforms (i.e. the same user, not different ones). Though in the latter case I would still like to differentiate between transitional applications that get run once in a while and/or aside others and highly immersive applications (e.
g. an IDE or a large 3D design app) that get used over longer periods of time with mostly exclusive focus. And only in the second case I would accept sound reasons to ignore the platform's conventions. Amongst those reasons I would
e. g. count a highly domain specific workflow that is not sufficiently provided for by the system's native UI (video post production, 3d modeling, %u2026).

In short: a platform's native interface standards and defaults (definitely including the respective human interface guidelines) may be ignored if this leads to a substantial improvement for the user.

[1] With %u201Cnative%u201D, I mean as completely native as possible and not the superficial nativity you get
e. g. with Java without platform specific code. Just mor or less emulating native appearance is by far not enough. See a large share of Java apps as not-best-practice examples (Netbeans or Eclipse get somehow away with it, because they are on their own right good enough as IDEs). See OTOH Cyberduck on OS X for a very well-done example of a Java app not looking and behaving like an alien in half-disguise. Another good one would be Transmission (AFAIK built with Python).

Jared Spool

On Sep 11, 2008, at 8:13 AM, Matt Doe wrote:

Here is the problem with keeping a windows application completely native.You end up with an application that looks like this: http://pcwin.com/media /images /screen /AVG _Anti _Virus _Free _Edition _7 _5 _1010.png Do you think there can be some kind of compromise to have it be visually appealing in windows without decreasing the usability?

Hi Matt,

I'm not sure I understand your point with the AVG Anti Virus screen. Are you saying you feel it's not visually appealing? Or is there some other issue with it?

I think the tension between usability and visual appeal is always a false tension. It's created when a team is missing solid visual and interaction design skills.

There is no reason in my mind that the AVG interface couldn't be more visually appealing while feeling like a Windows apps. There are plenty of very appealing windows apps in the world. It just takes solid skills and a good design process to make them that way. It's likely that it wasn't a priority for the AVG team or they didn't have the skills to make it work.

So, if visual appeal is a high criteria for your design (and kudos to you for making it so), you're going to have to accept that it will take a significant investment to get there.

Jared

Jack Leon Moffett

Jared's right (as usual ; ). There are dozens of decisions about the design of that screen that lead to it looking the way it does. Chances are, most of the decisions were made by simply accepting the default appearance. This can happen on any platform. Had the implementor been given a specification that included pixel dimensions, color, type, and the like, and it was a well designed spec, it could have turned out much better without much more work on the implementor's part.

Jack

On Sep 12, 2008, at 11:21 AM, Jared Spool wrote:
So, if visual appeal is a high criteria for your design (and kudos to you for making it so), you're going to have to accept that it will take a significant investment to get there.

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

You could design a process to catch
everything, but then you're overprocessing.
You kill creativity. You kill productivity.
By definition, a culture like ours that
drives innovation is managed chaos.

-Alex Lee
President, OXO International

adamya ashk

Coming late to the discussion, here are my $0.02:

Does anyone have any research or experience about the usability of non-native look-and-feels across different platforms?

The 'native look and feel' exists simply to provide some guidelines for visual design. Since most operating systems go through iterative cycles of visual theme changes what exactly is a 'native' look? (think windows 95 look and feel & Vista or osx vs. os7) .

You said it when you talked about an app feeling 'awkward' when it veered too much from the norm. In this case, the norm simply happens to be what people have running on their desktop. That is a hard thing to predict and yet setting it to just that may make the design look sedate and unexciting.

I have seen users put up with radical changes in look and feel as long as the interaction design is good and the benefits outweighs the cost of learning. Some of these changes become necessary as our experience with computers constantly evolves and interface guidelines lag behind what designers want to do.
http://image.versiontracker.com/scrnsht /65428 /196459 /302Panther.png

Now, I'm not saying that each app has to be different. That would be denigrating to the experience. Small changes, however, when put together carefully, can get you to a greatly enhanced experience. Case in point is the new browser from Google which uses the changes in look and feel to almost 'highlight' new interaction models.

Substantial usability testing is a requirement here. I wouldn't go "non-native" without it.

Amen. Usability testing is always a requirement. In fact, I wouldn't go 'native' without it :-)

Cheers,

-Adamya Ashk

Milan Guenther

While this discussion raises some interesting questions on standards in UI design in general, in the future the user will be facing more interfaces incorporating their very own standards, both in interaction design and in visual appearance.

Due to the "melting" of web and desktop applications, aside from the release of cross-platform franeworks and apps, I think vendors of software products will be forced to estabhish individual standards and take this responsibility (and power) from the OS people.

This is could lead to chaos, but is also a great chance to make a difference.

milan

Jared Spool

On Sep 12, 2008, at 5:13 PM, Milan Guenther wrote:

While this discussion raises some interesting questions on standards in UI design in general, in the future the user will be facing more interfaces incorporating their very own standards, both in interaction design and in visual appearance. Due to the "melting" of web and desktop applications, aside from the release of cross-platform franeworks and apps, I think vendors of software products will be forced to estabhish individual standards and take this responsibility (and power) from the OS people. This is could lead to chaos, but is also a great chance to make a difference.

In my opinion, it won't lead to chaos. On the contrary — I believe it's standards that make the world chaotic.

UI standards have always been irrelevant. Designing to standards have never worked. Designing to the experience and knowledge of the user always produces great results. Standards fail to bring the order that they promised.

If you're designing to experience and knowledge, it will appear that a standard emerges, because the same patterns will occur repeatedly. As designers, we'd like to pay attention to those patterns and draw on them.

However, users pay no attention to the patterns. If the design is intuitive (meaning that the user knows what to do next with virtually no cognitive effort), they could care less if the design followed any pattern similar to previous designs. This is not chaos — it's good design.

Given the choice of a poorly designed application that closely follows a UI standard or a great design that avoids the standard, the users will choose the latter every time.

That's my thinking.

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845 e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks

Brian Pirie

When thinking about native vs. non-native, I think we need to remember that it goes far beyond the visual appearance of controls.

Firstly, the visual appearance of the controls is designed to work in the context of each platform's standards for control spacing, alignment, and the like. Simply switching the control appearance between platforms, without also redoing the layout of dialog boxes, for instance, won't give you something that feels like a native interface.

However, it goes much more deeply than that. Think about other conventions of each platform that users will be accustomed to, from where you find application preferences in the menu structure, to shortcut key conventions, to integration with online help, search, and other standard applications on each platform.

All of these things mean that an application which simply uses the native control styles on each platform can still end up feeling very unnatural to users.

In fact, I imagine users can quickly adapt to a different visual control style much more easily than if you break these other deeper conventions of each particular platform.

Back to Top