Related
I'm looking for systematic review of the algorithms used for GUI layout. I'm particularly interested in the algorithms that favor speed over complexity, but it's hard to find anything useful other than "don't use constraint sovers".
So far the best one I've found is Constraint Solving for Beautiful User Interfaces: How Solving Strategies Support Layout Aesthetics by Clemens Zeidler,Christof Lutteroth and Gerald Weber. Unfortunately it is very short and is not very specific.
The layout algorithm landscape looks to me like this so far:
There's everybody's darling Cassowary that made its way just about everywhere.
There's the Auckland Layout Model which no one seems to use but thanks to its authors being prolific writers is well known.
There's the universally hated HTML/CSS combo that completely destroys the former two when it comes to the flow layout (especially the text flow).
Next come the algorithms used in desktop GUI frameworks, with WPF, Qt and MigLayout for Swing lauded the most. (I haven't figured out their performance characteristics yet, but I remember being disappointed by WPF layout speed compared to WinForms - the gains from faster drawing were offset by slower layout)
Than there's a handful of game engines UIs that no one seems to know anything about.
The rest are the ancient GUI toolkits that typically have an unsophisticated grid container as their most potent layout tool.
Have I missed anything significant?
Consider a single button.
At one extreme, we have a black OpenGL window, with:
outline (in white) of a rectangle
bitmap remdered font inside of it, saying "Ok"
At the other extreme, we have Mac OS X, a button that is:
well rounded
has some gradient showing light effects on it
nice antialiased "OK"
soft shadow of some sort
These two UIs present very very different user experiences. The former says "This is from the 80s" the latter says "this is professional".
This is something I do not understand well as a programmer (and don't know where to learn about this).
Does anyone know of a good technical resource for this? [I'd prefer things that draws upon psychology / perception literature to say why to do something rather than design books that just says "use color XYZ with a gradient of blah"]
Here is something on it. http://www.alistapart.com/articles/indefenseofeyecandy
You can check this link out to answer the part of your query in the comment. It has lots of references to samples and some helpful links too. http://www.usernomics.com/user-interface-design.html
The perception and psychology part of designing the UI does not come as any rule or steps, as we all know. It gets developed over time. Making your application user friendly and pleasing, that part of the magic or deal gets added from experience\survey and also you can include layman testing. I do it many times.
Also thinking out of the box. You will get a solution when solve it within the box. But you will get a better solution when you think out of it.
Another useful thing is be a good learner and observer. Note something nice and useful when you visit sites or use other applications. You might not even notice it. It might be something very small or trivial but it makes a lot of difference when it's used in the right places.
You will want to read up on Human User Interface guidelines HIG and Usability:
Apple's Human Interface Guidelines
Windows User Experience Guidelines
Platform agnostic guidelines
Amazon has plenty of books on the HIG subject, but I'd also recommend books based on usability. Steve Krug's "Don't make me think" is a great book (mainly tailored for web usability)
etc.
A classic: The Design of Everyday Things
Pretty quick read, discussed some of the psychology behind using and understanding human interfaces. It's a bit dated and doesn't directly focus on programming GUIs but I would start here.
I'd start with Vitruvius' firmness, commodity, and delight.
Also Gibson's affordances. Also, many HCI researchers have applied activity theory, with mixed results. Norman's DOET is a good start, but I think it covers only the first 2 of Vitruvius' triad - you're asking about the delight. Might also look at McCloud's Understanding Comics.
The Opera web standards curriculum has a very good section on aesthetic aspects, especially regarding color usage. I think it's very useful reading not only for web development, but all application design.
Chapter 8: Color Theory
Chapter 9: Building up a site wireframe
There is also a color scheme designer website, which allows you to play around with some of the color theory aspects. Definitely worth a visit.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In my experience, UI programming is very time consuming, expensive (designers, graphics, etc) and error prone - and by definition UI bugs or glitches are very visible embarasing.
What do you do to mitigate this problem?
Do you know of a solution that can automatically convert an API to a user interface (preferably a Web user interface?).
Probably something like a JMX console
with good defaults
can be tweaked with css
where fields can be configured to be radio button or drop down list, text field or text area, etc
localizable
etc
Developing UI is time consuming and error-prone because it involves design. Not just visual or sound design, but more importantly interaction design. A good API is always interaction model neutral, meaning it puts minimal constraints on actual workflow, localisation and info representation. The main driver behind this is encapsulation and code re-use.
As a result it is impossible to extract enough information from API alone to construct a good user interface tailored to a specific case of API use.
However there are UI generators that normally produce CRUD screens based on a given API. Needless to say that such generated UI's are not very well-suited for frequent users with demands for higher UI efficiency, nor are they particularly easy to learn in case of a larger system since they don't really communicate system image or interaction sequence well.
It takes a lot of effort to create a good UI because it needs to be designed according to specific user needs and not because of some mundane API-UI conversion task that can be fully automated.
To speed the process of building UI up and mitigate risks it is possible to suggest either involving UI professionals or learning more about the job yourself. Unfortunatelly, there is no shortcut or magic wand, so to speak that will produce a quality UI based entirely and only on an API without lots of additional info and analysis.
Please also see an excellent question: "Why is good UI design so hard for some developers?" that has some very insightful and valuable answers, specifically:
Shameless plug for my own answer.
Great answer by Karl Fast.
I don't believe UI programming is more time consuming than any other sort of programming, nor is it more error prone. However, bugs in the UI are often more obvious. Spotting an error in a compiler is often much more tricky.
One clear difference between UI programming is that you have a person at the other end, instead of another program, which is very often the case when you're writing compilers, protocol parsers, debuggers, and other code which talks to other programs and computers. This means that the entity you're communicating with is not well-specified and may behave very erratically.
EDIT: "unpredictable" is probably a more appropriate term. /Jesper
Your question of converting an API to a user interface just doesn't make sense to me. What are you talking about?
Looks like you are looking for the 'Naked Objects' Architectual pattern. There are various implementations available.
http://en.wikipedia.org/wiki/Naked_objects
I'm not providing a solution, but I'll attempt to answer the why.
So I don't speak for everyone, but for me at least, I believe one reason is because programmers tend to concentrate on functionality more so than usability and they tend not to be too artistic. I think they just tend to have a different type of creativity. I find that it takes me a long to time to create the right graphics, compared to how long it takes me to write the code (Though, for the most part, I haven't done any projects with too many graphical requirements).
Automatically generating user interfaces may be possible to some extent, in that it can generate controls for the required input and output of data. But UI design is much more involved than simply putting the required controls onto a screen. In order to create a usable, user friendly UI, knowledge from disciplines such as graphics design, ergonomics, psychology, etc. has to be combined. There is a reason that human-computer interaction is becoming a discipline of its own: its not trivial to create a decent UI.
So I don't think there's a real solution to your problem. UI design is a complex task that simply takes time to do properly. The only area where it is relatively easy to win some time is with the tooling: if you have powerful tools to implement the design of the user interface, you don't have to hand-code every pixel of the UI yourself.
You are absolutely correct when you say that UI is time consuming, costly and error prone!
A great compromise I have found is as follows...
I realized that a lot of data (if not most) can be presented using a simple table (such as a JTable), rather than continuously try to create custom panels and fancy GUI's. It doesn't seem obvious at first, but it's quite decent, usable and visually appealing.
Why is it so fast? Because I was able to create a reusable framework which can accept a collection of concrete models and with little to no effort can render all these models within the table. So much code-reuse, its unbelievable.
By adding a toolbar above the window, my framework can add to, remove from or edit entries in the table. Using the full power of JTables, I can hide (by filtering) and sort as needed by extending various classes (but only if/when this is required).
I find myself reusing a heck of a lot of code every time I want to display and manage new models. I make extensive use of icons (per column, rows or cells, etc) to beautify the screens. I use large icons as a window header to make each screen 'appear' different and appealing and it always looks like new and different screens, but its always the same code behind them.
A lot of work and effort was required at first to do the framework, but now its paying off big time.
I can write the GUI for an entirely new application with as many as 30 to 50 different models, consisting of as many screens in a fraction of the time it would take me using the 'custom UI method'.
I would recommend you evaluate and explore this approach!
if you already know or could learn to use Ruby on Rails, ActiveScaffold is excellent for this.
One reason is that we don't have a well-developed pattern for UTDD - User Test Driven Development. Nor have I seen many good examples of mapping User Stories to Unit Tests. Why, for example, do so few tutorials discuss User Stories?
ASP.NET Dynamic Data is something that you should investigate. It meets most, if not all your requirements
It's hard because most users/customers are dumb and can't think straight! :)
It's time consuming because UI devs/designers are so obsessive-compulsive! :)
Say for instance I'm going to do some seat of my pants coding adding a feature to an enterprise app. What are some good examples/tenants/cardinal rules a person can follow for making a fairly complex setup/config screen not look like feet.
What I'm looking for is along the lines of "Don't put one thing in a group box". But I'd also like some help with symmetry if anyone knows what layouts are most likely to achieve a relative amount of good looks that would be helpful.
Here's a cardinal rule you asked for: line up the controls vertically /horizontally and equally space the various related elements. And use correct spelling on your labels!
We've all come across screens where there are misaligned controls (even a couple pixels is noticeable) or misspelling on labels. When this happens to me I can't help but subconsciously look for other mistakes, plus it decreases my confidence in the application I'm using!
This is actually a huge topic. I frequently go to the Microsoft UX Guide for reminders on how to do this.
Some basics:
Make your app read like a book: left
to right, top to bottom
Use goal-oriented language instead of
technology oriented language
Not a cardinal rule but a great resource:
Apple UI Guidelines (good info for any OS)
EDIT: Re: achieving symmetry - things don't have to be perfectly symmetrical, but you want a feel of balance. Take a step back and get a sense of whether the page or form feels like it's leaning/falling to the left or right.
E.g., with stackoverflow, the main content is to the left, but it's nicely balanced by the extra stuff on the right.
I find that paper is my friend. I like to write out a list of objectives the form has to accomplish, and then sketch the form by hand, labeling the parts. Drawing it out lets me get away from making sure it looks perfect and that everything is aligned just right, and lets me focus on making sure that all the components I need are placed, hopefully somewhere logically. It also forces me to lay out the UI twice, so by the time I open my UI designer, I've already designed the form once and you hopefully know what I am doing
Some basic rules for you.
Try to make effective use of whitespace. Don't cram everything together in an effort to get as much stuff on screen as possible. This will make grouped controls more clear and text more legible.
Basic typography. Limit your use of fonts to 1 or 2. Don't use bold too much or it loses its emphasis.
The same goes for colours. Don't use too many, the fewer the better most of the time.
Don't just use icons to save space. Tiny icons with no explanation are useless.
Copy. Not wholesale of course, but if you are not well-versed in UI design yourself, it makes sense to take elements of interfaces you know work and apply them in your own designs.
Be clear about the purpose of the interface. How does it fit within the broader application for example? And what are the specific objectives you are trying to satisfy with it?
Get people to test it for you, early and often. I don't know what setup you are working with, or what kind of organisation you are in, but getting some kind of human feedback on your work will always be helpful, even if you lack the time and expertise to conduct proper usability evaluations.
Since you use the term, "seat of your pants," I'm assuming that you don't want to spend too much time on the UI. If you are willing to devote some time to the UI, you may want to look into custom control or UI development that will suit your situation. Like Firefox's Options UI or the .NET project properties in Visual Studio 2008.
If you are looking for something using standard controls, it is probably best to separate out different sections of related items into tabs or some other type of stacking control (i.e. Ribbon control). A good example of the tabbed version would be the Notepad++ Preferences UI. Many other programs use a similar scheme.
The best way to get a UI that makes sense is to follow Joel's advice:
Eat your own dog food.
Do it a few times to your own UI, and you'll notice some things you didnt think of intially.
I've found that a really good test is getting someone non-technical to use your GUI. Watching someone use it for 5-10mins normally gives me a very good idea about what is/isn't easier to understand.
This series by Joel Spolsky is a pretty good read and Jakob Nielsen's stuff Usability and Web Design is pretty useful.
Specific rules I try and use are:
Put items in logical groups
Line everything up
Use sensible images/icons
Spend 5-10 mins thinking through why things are the way there are
Only use words that make sense to the user not to you!
Start from the setup/config UI of an existing application that you feel is both simple and usable.
Most tenants/cardinal rules apply to UI in general and fill hundreds and hundreds of pages in UI design and HCI books, so you probably want to just work your way by example for now, while trying to capitalize on existing user experience (habits), i.e. obeying the rule of "least surprise": e.g. if your application is a Windows application, use the Installation Wizard pattern, if it's an ncurses app for a particular flavor of *nix follow the style of that particular OS's actual installation UI, etc.
You might be interested in the book "Don't Make Me Think," (author's web site) or "About Face 3.0". Both come highly recommended for reading about how to design interfaces.
Speed and learnability do not directly fight each other, but it seems easy enough to design such a GUI that lacks either (or both) of them. GUI designers seem to prefer 'easy to learn' most of the time even when 'fast to apply' would be wiser.
There's only few UI concepts or programs that are weighted towards maximizing the peak efficiency of whatever you are doing with the program. Most of them haven't gotten common.
Normal people prefer gedit instead of vim. For normal people there are already good-enough GUIs because there was tons of research on them two decades ago.
I'd like to get some advices on doing UIs that do the tradeoffs from 'easy to learn' rather than from 'fast to apply'.
We have a product in our lineup that has won numerous awards based largely on its ability to provide more power with an easier interface than any of our competitors. I designed the interface a few years after holding a position in one of Bell Labs' human interface research groups so I had a pretty clear idea of what constituted "success" when I approached it. I have four pieces of design advice for creating easy but powerful interfaces.
First, select a metaphor that makes sense in their environment and do your best to stick to it. This doesn't have to be a physical metaphor although that can help if working with people who are not tech savvy. This was popular in the early days of Windows but its value remains. We used a "folder and page" metaphor that permitted us to organize a wide range of tasks while not crimping power users' style.
Second, offer a consistent layout relationship between data display and tasks. In our interface, each "page" displays a set of action buttons in the exact same position and, wherever possible, uses the same actual buttons. Thus, once one page is learned, the user has a head start on learning the rest. One of these buttons, always placed in a distinctive position, is a "Help" button...which brings me to point #3. The more general rule is: find ways of leveraging learning in one area to assist in learning others.
Third, offer context-sensitive help and make sure that it addresses the user's primary question (which is usually "what do I do now"?) How often have you seen technical help that simply shows you the Inheritance tree, constructor syntax and an alphabetical list of methods? That isn't help, it is abuse. We focused all of our help on walking people through sample tasks. In particularly tough areas, we also offered multimedia tutorials.
Fourth, offer users the ability to customize the interface. Our users often had no use for specific "pages" (analysis types) in their work. Thus, we made it very simple to turn them off so that the user would see an interface that was no more complicated than it had to be. Our app was usually installed by a power user and then used by multiple staff members so this was more of a win for us because we could usually count on the power user to understand what to shut off. However, I think it is good advice in general.
Good luck!
Autocad has a console mode. As you do things using the mouse and toolbars, the text-equivalent of those commands is written to the console. You can type commands directly in there. This provides a great way to learn the power-user names for commands (they are very short, like unix commands) which aids greatly the process of moving from beginner to productive power-user. Generally speaking, one primary focus has to be in minimising movement between the mouse and keyboard, so put lots of functionality into the mouse, or into the keyboard, because when you have to move your hands like that, there is a real delay in trying to find the right place to put them.
Beyond avoiding an angry fruit salad, just try to make it as intuitive as possible. Typically, programs with a very frustrating UI share one common problem, the developers didn't define a clear scope of what the program would actually do prior to marrying a UI design.
Its not so much a question of 'easy' , some people jump right into the UI and begin writing stuff to back the interface, rather than writing the core of a planned program and then planning an interface to use it.
This goes for web apps, desktop apps .. or even command line programs. A good design means writing the user interface after (and only after) you are sure that 'scope creep' is no longer a possibility.
Sure, you need some interface to test your program, but be prepared to trash it and do something better prior to releasing the program. Otherwise, there's a good chance that the UI is only going to make sense to you.
Rant (or, Stuff I think you should keep in mind):
Speed and learnability do directly fight each other. A menu item tells you what it does so that you don't have to remember. But it's much slower than a keyboard shortcut that you have to memorize to benefit from. The general technique for resolving this conflict seems to be allowing more than one way of doing things. While one way of doing something usually cannot be both fast and easy to learn, you can often provide two ways to accomplish the same task: one that's fast, and one that's obvious.
There are different kinds of people. The learning gap is a result of interest, motivation, intellectual capacity, etc. There is a class of person that will never bother to even learn which menu provides the action they want, and they'll scrub the menubar every time. There is also a (minority) class of person that thinks vim (or emacs) is the best thing since sliced bread. Most people probably fall somewhere in between these extremes.
My answer to the actual question:
I think you are asking how to strive for a fast UI. Your question wasn't particularly clear (to me).
First of all, be consistent. This helps both speed and learnability. Self consistency is the most important, but consistency with your environment may also be important.
For real speed, require as little attention and motion as possible. Keyboard shortcuts are fast because experienced users know where they are (they don't have to look), and their hands are already on the keyboard. Especially avoid forcing the user to change their position in front of the computer (e.g., moving one hand between the mouse and keyboard).
The keyboard is almost always faster than the mouse.
Customization (especially the ability to write custom scripts) will let power users make the interface work the way that is fastest for their specific habits.
Make it possible to get by without the most powerful features. All you need to know in order to survive in vim is "i, ESC, :wq, :q!". With that, you can use vi about the same way a lot of people use notepad. but once you start learning "h,j,k,l,w,b,e,d,c" (and so on) you get much more efficient. So there is a steep learning curve, but you can get by until you surmount it.
Keep in mind that if you focus on interface efficiency, you will probably limit your user base. Vim is popular among programmers, but lots of programmers use other tools, and it's virtually unknown among non-programmers. Most people want easy, not fast. Some want a balance. A very few just want fast.
I would like to point you towards Kathy Sierra's old blog for thoughts on 'easy to learn' and 'fast to apply' — I don't necessarily agree there needs to be a tradeoff between the two.
Three posts to get you started:
How much control should users have? This post ponders on whether 'fast to apply' is the ideal we should strive for.
The hi-res user experience talks about what you say about "normal people" vs. others. It's not so much that there are different kinds of people, but there are different levels of learning/expertise/involvement. Some are satisfied with less, some need more. How you get from less to more is arguably pretty much the same for everyone.
Finally, Featuritis vs. the Happy User Peak talks about the scope creep pointed out by #tinkertim.
Have you seen Gimp shortcuts?
Use nice visual controls and show keyboard shortcuts for them while hovering control - that will help to learn fast mode. If your software copy some behavior of other programs - copy shortcuts mapping from them (such as Copy/Paste/New Tab/Close Window/etc), but allow to dynamically re-map them as shown in Gimp. For reaped operations you could implement Action recoder. But it depends on type the software.
The main thing to be careful of is putting UI elements where they are most commonly located for other applications in that environment. For example, if you're going to make use of a menu system, people are accustomed to it being along top of the window by default for a desktop application. If you're in a web browser a menu system on a webpage seems out of place because it's not a consistent feature. If you're going to have an options/preferences configuration window, people are used to finding it under the Tools menu option, occasionally under the Edit menu. The main thing with keeping a UI "easy to learn" is that your UI elements shouldn't break the mold too much of how they're used in other applications.
If you haven't had the opportunity to see Mark Miller's presentation on The Science of Great User Experience, I'd recommend you watch the DNR TV episodes Part 1 and Part 2.
While I've been writing my own UI I've understood couple of things myself.
I imitated vim, but at the same time realized why it's so fast to use for text editing. It is because it acknowledges a thing: People prefer doing one thing at a time (inserting text, navigating around, selecting text), but they may switch the task often.
This means that you can pack different activities into different modes if you keep the mode switching schemes simple. It gives space for more commands. The user also gets better chances at learning the full interface because they are sensibly grouped already.
Vim is practically stuffed full of commands, every letter in the keyboard does something in vim, depending on the mode. Still I can remember most of them. And it's all because of modes.
I know bunch of projects that sneer at mode-dependent behavior. Main argument is the uncertainty of which mode you are in. In vim I'm never uncertain about the mode where I am in. Therefore I say the interface design is a failure if a trained user fails to recognize in which mode the interface is operating at the moment.