Related
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?
There are a few aspects to having a polished UX for a piece of software.
Using the most native framework for the platform. Win32/WPF for Windows, Cocoa for Mac etc.
Application's visual artefacts are coherent - this includes images, graphics, toolbar icons etc.
Following the platforms guidelines and best practices.
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.
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.
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!
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!
For my university I (and three others), are searching for a project that utilizes at least one embedded device, web services or other web technology, and a Graphical User Interface.
Currently we are looking at developing a unified remote, that is an extendable application on a cell phone through which you can control your media center. Any ideas, or advice on this will be appreciated, though it is not the focus of this question.
We are having a hard time finding interesting (or funny) projects on which we can work a complete semester. Any ideas will be greatly appreciated. The software will be released as free software. (GPL or BSD license).
We all have a Bsc in Software Engineering.
EDIT: I am very pleased with the suggestions so far. Thanks to everyone, and keep it coming.
How about follower: carry a device, as you move from room to room in your house devices configure themselves to your preference - lights, music etc. If two people are in the room some precedence rules.
Is that possible just on the presence of a mobile phone?
Another idea (from the top of my head):
A work environment ensurance thing. We programmers like to develop in nice and quiet environments. Unfortunately some people tends to annoy us with their disturbing behaviour (or just by being loud).
So the project could be to create devices wich tracks the stress level (sweat levels, pulse etc.) of the individual and their impact onto others.
An example: One individual is very loud (the device should measure this), and others around him becomes stressed and/or unfocused because of this. The serverside sw, should then detect and warn him to quit down a bit to improve the work environment.
Comments?
What do you peeps like doing? Build an app for it.
So, if you like drinking coffee build a application which will find the nearest frothy coffee shoppe (or if you're particular, the nearest Peets/Starbucks/Whatever-ocino). This idea works for beer too.
If you buy stuff off e-Bay build a sniper app.
If you enjoy playing frisbee build an app which locates your nearest friends and sends them a text asking whether they want to goof off lectures and go to the park.
Heck, you could even build an app which monitors your SO questions and alerts you when you get an answer (although I don't know whether the data services SO currently offer will be up to the job).
The standout companies that have made great universal (programmable) remotes are : logitech, and philips.
One of the big problems with these types of devices is the ability of the general consumer to actually program all of their various devices. Logitech has done an outstanding job of providing a fairly simple Web based user setup experience that then implements a very usable universal control.
I would definitely look at what they have done for some ideas on universal remote controls.
How about an app and hardware that will tell me when my wife's plants need watering? (It's somehow my fault if they don't get watered.)
OK then: the recipe generating fridge. Rfid tags on the contents know what's available and the expiry dates. The database knows the recipes. The fridge emails/texts you to say "buy some mushrooms and you can have a delicous ham and mushroom omelette while the eggs are still fresh."
Benjamin and all those aspiring to do embedded projects ...
When you start a project, especially in embedded systems, you need to understand that the hardware is not your PC but some special device. And every sensor will be a transducer in itself. The only thing that would matter to students is that everything costs and are costly
So, it will be good to make sure that the idea is such that,
It can be completed by the
project members within the given timeframe
All the required development
tools like hardware etc can be
really bought
Of all, it good to ensure that the
project enables you to learn
something useful for your career ...
To do all this it is better set some achievable goals
Develop a system in which you can program the lighting system of your house. You can set up their schedule one time and everything should work automatically.
I really love working witht the Atmel ststk1000/stk1006/stk1002 development boards for tht AVR32. ATSTK1000
2x Ethernet
QVGA lcd
USB 2.0
SD/MMC
Conpact flash
Supported embedded linux
IR
Audio
ps2 interfaces
uarts
++
familiy atmel page:
AVR 32 family home
online forums
Forums for CPU
For common elements, such as a logout button on a website, save button in an application, need to be presented to users in an standard, easily discoverable way. How do you go about deciding where in your application to place these elements? Do you research similar apps and try to follow convention? Is there any database that attempts to track the use of these common elements or is this too hard to capture?
The goal is to put UI elements where users expect to find them. You want to leverage the knowledge that they already have about how applications work.
So, looking at the the UI elements for the OS that you are targeting is helpful. Unfortunately, there are some key differences here between Windows and Mac, you will have to pick one or switch based on the OS if you target both.
Looking at applications that are similar to yours is generally not a good idea unless you believe that people using your product are already using these other products and you want them to switch.
Instead, you look at products that are complementary to yours, or products that you expect everyone is familiar with. At one point it was a good idea to look at Excel and Word to know how an Windows application should work; But I don't think that the current versions of Excel and Word are a good model, they deviate too much from the way the OS works. You could still use older versions - before the ribbon, if you are targeting Windows.
It's best to be a bit conservative, choosing applications that have been out for a while and people are likely to be comfortable with rather than chasing the latest design innovations that are coming out of Apple and Microsoft.
I research similar apps and try to follow convention...
E.g. logout goes up in the top right near the "X"/close in most applications
Save/Edit buttons towards the bottom of the thing I'm editing... since contextually they happen after I finish the editing I just did.
Then again, you have apps like Outlook... that have the send/save buttons at the top.
In general though... I have application-wide actions (e.g. login/logout/help user info at the top)
Item specific tend to be inline or just after the item they are adding/editing.
I totally agree with leveraging knowledge that the user already has. Every techie is (or probably is) familiar with http://www.dice.com. It frustrates me to no end to see that their website is designed with the logout "link" (not even a "button") at the very BOTTOM of the page. In this age of security conciousness, what a place to put a logout link ???
I have used DeLorme Street Atlas USA mapping software ever since Windows 3.1. About five or so years ago, they changed their entire user interface, moving AWAY from all of the features that make application software in the Windows environment easy to learn and navigate and SIMILAR from one application to another, and TO a totally foreign user interface, unique to their individual product offering.
Was it necessary ? probably not... What was it's impact to the current user community ? probably not thought about... What was it's impact to someone new to Street Atlas USA ?? Probably LESSENED the adoption rate of the software product, because it looked so foreign compared to a user's already-used applications developed with the common Windows-based look and feel.
Although books can be written on how "we" dislike Microsoft, the value-added benefit to Windows since it's infancy with Windows 3.1 was that you could create totally different software applications, but have a SIMILAR navigation style threaded throughout all of the applications, LESSENING the new application learning curve, and INCREASING the adoption rate amongst software applications for the Windows user.
Leveraging positive current user knowledge can only increase the adoption rate of a software product. Why re-invent the wheel, when the current wheel is known and adequate ?
How do companies like Valve manage to release games to all three major gaming platforms? I am interested in the best-practices regarding code sharing specifically between Windows, Xbox360 and PS3, since the ideal solution is to reuse as much code as possible instead of rewriting the whole thing for every platform.
It's not any different than writing platform-independent code in other contexts. Hide platform-specific details (input, window interaction, the main event loop, threading, etc) behind generic interfaces, and test regularly on all the platforms you intend to support.
Note that the Cell's threading model is unusual enough that doing threading "generically" takes some care. I am not a Valve employee and I know none of their secrets, but it's my understanding that most game developers who want to target the PS3 use a job queue that the individual cell processors grab tasks off of as needed. This isn't necessarily the best way to use the Cell, but it generalizes nicely to more conventional threading models (like, frex, the one that thet PC and the 360 both use).
There's a bunch of Game Developer Magazine articles and GDC talks on the subject. In fact, since you mentioned Valve, they delivered a talk describing their approach at GDC08.
This is really a huge subject that I could (and have) talk about for hours upon hours, but elevator summary is:
Determine which parts of the engine are completely platform-specific and put them behind an abstraction. File and asset loading, for example, need to be rewritten for each console; but you can hide that behind an IFileSystem interface which provides a uniform API that the game code talks to.
The PS3 makes this hard because its abstraction point has to be someplace completely different from the other platforms. Even game features like collision and nav will have to be written differently for the Cell.
Try to keep leaf game code (entities, AI, sim) as platform-agnostic as possible...
But accept that even the leafiest of game code will sometimes need some platform-specific #ifdefs for perf or memory or TCR reasons. A lot of UI will have to be rewritten because the manufacturers have conflicting certification requirements.
Anyone who says the words "I'm not worried about performance" or "memory isn't an issue" shouldn't be on the payroll.
This question can be divided up into two separate questions. "How can I write portable code?" and "What are the divergent requirements of mainstream gaming platforms?".
The first question is relatively easy to answer. Best practices for abstracting your non-portable code are covered in Write Portable Code:
http://books.google.ca/books?id=4VOKcEAPPO0C&printsec=frontcover
Turning theory into practice, the Quake 3 source code does a pretty good job of dividing out different platforms into separate areas for a C codebase, available at http://www.idsoftware.com/business/techdownloads/ However, it does not demonstrate C++ patterns such as abstract interfaces, implemented once per platform.
The second part of your question, "What are the divergent requirements of mainstream gaming platforms?" is tougher. However, it is notable that your largest areas of change are still your renderer, your audio subsystem and your networking.
Each console platform has a series of certification requirements, available under an agreement with the respective console owners. The requirements drive consistency in user experience and are not focused on gameplay or qualitative, high level issues. For instance, your game may need to display a reasonably interesting animating loading screen, and black screens are unacceptable.
Getting your hands on this documentation as soon as possible is key to making the right choices in developing for a specific console platform.
Finally, if you can't get your hands on a console devkit, I suggest you port your code to the Mac from Windows. The Mac gets you an OS port ensuring you are not tied to Windows as well as a processor port if you support universal binaries. This ensures your code is endian agnostic.
If you support both PC and Mac, you will be well positioned to support a third platform, should you gain access to it in the future.
Addendum You wrote:
the ideal solution is to reuse as much
code as possible instead of rewriting
the whole thing for every platform
In many game porting scenarios, the ideal solution is not to reuse as much code as possible, but to write the optimal code for each platform. Code can be reused between projects and is relatively inexpensive as compared to the content that the engine takes in. A more reasonable goal is to aim for lowest common denominator content that runs on all platforms without modification (a build phase that packs the content for media is okay).
It's great to do simultaneous development. You find all kinds of bugs you wouldn't find doing just one platform.
I remember that programmers in DOS had null pointers all the time because writing to low memory didn't immediately crash them. When you ported to an Amiga, Atari ST, or Macintosh, boom! I remember telling a DOS programmer that he had a couple null pointers on an aready-shipped game. He thought for a couple seconds and grinned, "That explains a few things."
Now that games have such large budgets, it's important to ship them all at the same time so you don't waste marketing and ad budgets.
My advice on simultaneous development is to pick one lead platform, but never let the other platform(s) get more than a week behind. It will become obvious as you program which parts of the code are common to all platforms and which are different. Pull out the differences into one or more platform-specific areas.
My experience is in C/C++. It's a bigger problem if you have to port against different languages (say, Java and Objective-c).
A few years ago the Opera CEO said in an interview that the key to developing for independent platforms is to move away from any single OS/platform libraries. He went on and said that they developed their own libraries that improve OS performance.
My assumption is that big companies will have a common, Xbox, PS, windows, FooOS, separate teams. Each platform needs to be tweaked differently and requires different implementation methods. I don't think they do one source for all platforms; rather, they build one for each OS thereby, improving efficiencies. I remember EA used to release some console games earlier than the PC versions and vice versa.
Another issue is that different consoles have different hardware thus requiring different programming techniques.
there are two extremes, build one source that fits all (java for instance) but you run the risk of inefficiency or write 40 versions; one optimized for each platform
Back when I had a friend into educational computer games (before The Learning Company gutted the field), he was a great fan of creating cross-platform libraries for doing everything.
This is easier for games than other apps. If you have a word processing app to run on the Mac and Windows, for example, it really does need to look and behave like a Mac app on the Mac, and a Windows app on Windows. Write a game, and it doesn't have to conform to the native behavior, look, and feel.
If you want open source examples, you could look at source code of Quake 1, 2 and 3 engines. They are structured quite portably. (Of course, no ps3 or xbox360 support, but same principles apply)
http://www.idsoftware.com/business/techdownloads/
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...
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.
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.
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.
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.
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,
Do you have justification for doing so? (In order to present data in some way that's not possible within normal L&F)
What do you gain from doing so? (Improvinging usability?)
What do you lose from doing so? (Intuitiveness & familiarity?)
Don't simply do it 'To be different'
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.
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.
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 Are there any standards to follow in determining where to place menu items? for more information.
If you are on (or develop for) a Mac, then definitely YES!
And this should be true for Windows also.
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.
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.