Where does the professional sheen of a GUI application realistically come from?

Question

I have been playing around with php-gtk recently and in the past I have experimented with Java to make GUI 'hello world' apps.

However both these types of applications have had a bit of a clunky (almost childish) look and feel to them. I cannot deny that they are handy for making apps for in-house use (and I totally respect the amount of community effort that goes into these projects). But I would not necessarily be proud to sell it as a commercial application with a price tag of, say, £450 or £1,000.

If I wanted to make an application that had the look and feel of, say, Firefox for Windows, or Adobe xyz, what GUI/language should I use?

Is the 'professional sheen' or smart look and feel 100% down to the designers or is it the case that, no matter how good a designer is, picking the right GUI framework is essential to get that look?

Answer 1

Always try to use the GUI framework that's used by your desktop environment. .NET's libraries are probably the best for creating Windows apps. GTK+ is always the best on GNOME, while Qt works well on KDE - even though all three work on each other's systems, their visual appeal decreases with their lack of visual integration.

Answer 2

I don't care for the way Java application GUIs tend to look using the usual toolkits. If you like the way Firefox looks, you might look into XUL and the GUI framework shared by most Mozilla applications. Komodo Editor/IDE use the same tools (along with several other applications). GTK is very powerful, and I really doubt it is what is preventing your applications from having that professional sheen. Keep exploring it's features, and rethinking the best way to display your components, and I'm sure you'll stumble upon an arrangement that feels better.

On the other hand, it isn't all about the toolkit. Good interface design is an art, and interfaces like Firefox have evolved through endless amounts of feedback. The best thing to do is talk to users and find out what will make them more comfortable using your application. I've found that software tends to look good when it is also functional.

I would recommend spending a lot of time in software that you find pleasant to use. Make notes of the way things are done, and look for commonalities among interface elements. Most software sticks to a pretty common set of principles that make using the software easier, and the more you explore the software you find appealing, the sooner patterns will start to emerge.

Good luck!

Answer 3

There are a few aspects to having a polished UX for a piece of software.

1. Using the most native framework for the platform. Win32/WPF for Windows, Cocoa for Mac etc.
2. Application's visual artefacts are coherent - this includes images, graphics, toolbar icons etc.
3. Following the platforms guidelines and best practices.

Answer 4

For Java there is a library called JGoodies. I've worked on Swing applications before, usually they looked like hell. It wasn't so much due to deficiencies in Swing, it was due to crappy designs and apathy toward UI design, it takes time and effort to make an app look presentable and nobody wanted to budget for it.

Answer 5

The GUI API/language used is utterly irrelevant to UI design, although some APIs make it easier or fasterto implement.

Good UI is about:

• Good graphic design/artwork (visual balance and symmetry, complementary colours, visually 'pleasing' shapes and layouts, visual consistency within your app and with the other apps around it - consistent positioning, sizes, gaps, colours, etc)
• Understanding the user's workflows and making what they want to do easy and intuitive. This often means implementing 3 or 4 ways of achieving the same action (e.g. "Copy and paste" can usually be achieved by: main-menu->copy/paste, context-menu->copy/paste, ctrl+c/v, button:copy/paste, drag-and-drop)
• Keeping everything simple. Remove as much as possible to cut the UI back to just what the user needs and no more.
• Being intuitive and not surprising the user. Controls should look like the controls the user knows, work like the controls the user knows, and be located in the places a user expects given their previous experience with the computer.
• Following the conventions (position OK/Cancel buttons in the standard locations, use the OS-defined colours for highlighting selected objects etc)

To get this, you need to look at lots of "good" applications and dissect what makes them good. Get a good artist/graphic designer to draw you good icons etc. And spend a lot of time thinking about the user's workflows.

Make sure you separate the business logic from the UI - this will allow you to re-skin the app easily to improve the UI. And usually the data the program needs is not related to the way the user needs to use the application - don't be tempted to just expose your x,y,z variables in editable fields! UI is the layer that hides your implementation and makes it usable!

Answer 6

It's overlapping a bit with Igor's reply, but here's my take:

Native Control Look - UI controls today have a rather complex appearance. There are many visual cues we instinctively derive from them, and even if it's a white rectangle with some frame, with the wong shadow it looks strangely out of place. A context menu often doesn't just open today, it slides in from some direction, or fades in.

Native Control Behavior - Even more complex than UI, there's a lot of detail to behavior: different context menus depending on click position, different "hot" areas when selecting or dragging items, keyboard shortcuts, etc.

Attention to detail - There's a lot of consistent UI behavior to discover on any platform. Just the way arrow keys work in a tree control WRT selecting, opening and closing nodes.

Just look at Windows: Most non-native toolkits get the basic keyboard navigation wrong - Arrow keys, Home, End, PgUp and PgDown, behavior modified with Ctrl, extending selection with Shift gives up to 32 behaviors. Copy & Paste is traditionally with Ctrl+C/Ctrl+X/Ctrl+V and Shift+INS,Shift+DEL, and missing. Mouse double click often selects a word, mouse triple click sometimes a sentence, line or paragraph.

Response time and Muscle Memory - There are, basically, two UI operation modes:

act-look loop, where you wait for the response before deciding the next step,
playback from muscle memory, which is much faster and requires less mental processing ressources.

There are, however, two requirements for that: response must be uniform and "instant", and the next action must be registered correctly immediately (at least within 10 ms)

Often enough, with non-native toolkits, this gets hard by the response lagging behind one or two actions (the mind locks on the discrepancy), and by toolkits that take 50ms or more to show a menu, in which time a click isn't registered as intended.

A polished UI takes long to get right - A good control library can solve most of the per-control issues, but there's some final 10% taking 90% of the time, and you have control interactions. You have to try different approaches, you have to expect users with FPS-trained reflexes, you have to try all kinds of workflows.

Cross-Platform toolkits can't get it perfectly right - they are stuck between a rock and a hard place: They can opt for internal consistency independent of the platform, or being consistent with platform they currently run on. To get it right, the latter often requires platform-dependent code in the calling code, the actual thing you are trying to avoid.