Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I'm writing an internal-tools webapp; one of the central pages in this tool has a whole bunch of related commands the user can execute by clicking one of a number of buttons on the page, like this:
toolbar http://img709.imageshack.us/img709/1928/commands.png
Ideally, all of the buttons would fit on one line. Ordinarily I'd do this by changing each widget from a button with a (sometimes long) text label to a simple, compact icon - e.g.
button labelled "Save" http://img337.imageshack.us/img337/773/saver.png
could be replaced by a familiar disk icon:
Unfortunately, I don't think I can do this for every button on this particular page. Some of the command buttons just don't have good visual analogs - "VDS List". Or, if I needed to add another button in the future for some other kind of list, I'd need two icons that both communicate "list-ness" and which list. So, I'm still considering this option, but I don't love it.
So it's come time for me to add yet another button to this section (don't you love internal tools?). There's not enough room on that single line to fit the new button. Aside from the icon solution I already mentioned, what would be a good* way to simplify/declutter/reduce or otherwise improve this UI?
*As per Jakob Nielsen's article, I'd like to think that a dropdown menu is not the solution.
Edit: I'm not looking for input about the icon idea. I'm looking for other solutions. Sorry my example disk icon was a small one; it was just an example. I'm showing a bigger one now to hopefully be more clear.
I would add a More Link Like Google does.
See the Top Bar of Google with WeB Images Map More >>
To this more >> drop down you can add logic to add button less frequently used by user or something like that.
If you read Jef (and Aza) Raskin, you'll probably realize that icons are also not a good solution – both were pretty vocal in their dislike for them (with very few notable exceptions). For a start they're even harder to hit than tiny buttons, then their symbols can be confusing, culture-dependent and misleading. We're already good at reading text, parsing and interpreting icons is often slower.
In any case, that button bar looks like it accommodates pretty much anyone and their dog who might be using that product. You might have had some specific scenarios in mind when creating it that should be easy to do and are important. Most likely not all buttons are needed at once for such a task to complete.
Another thing is that maybe not all buttons are even useful at any single state of the application. Can you maybe branch into different sets of buttons, depending on the state. That's only possible however, if each state has clearly defined what actions can be taken. If all buttons are equally pressable regardless of state this won't do anything.
Grouping commands according to related functionality might also be an option. This doesn't have to be done with menu-like idioms, you can also put them into containers with different background color or even color the buttons themselves (just keep in mind color blindness, though). Depending on how related those individual functions are this can be a good way of speeding up interaction. It might requier some training for users to know what the colors refer to but for an in-house tool that's only used by people you know (instead of by arbitrary random ones [which is a problem Microsoft faces quite prominently]) this should pose not much of a problem.
What if you use icons and text?
For the commonly understood commands - use just an icon (like the save)
For the uncommon commands use an Icon + the text.
If you put a border around the button as a whole it should tie the icons / text together nicely and show it's still a button. You could also do some hover effects.
Since you can't do a dropdown menu (or similar techniques like clicking a button to generate a secondary menu). The best I can think of is what Prescott did or showing an area of buttons that are grouped in such a way to make it easy for the user to know which section their button should be in.
I would start by changing some of the longer labels. At a minimum, "Application Loading" could be abbreviated "App Loading." What's another (shorter) way to say "Quick File Transfer"?
You could also group the buttons into tabs (i.e. make it a ribbon). That might work particularly well if different classes of users tend to use different, non-overlapping sets of buttons.
Numerous options:
Group and labeling. Any time you have more than eight commands, you should divide the menu items into semantic groups of about four to help the user scan for the command they want. Labeling the groups also helps the scan and can make the menu more compact. For example, Instead of VDS Ping and VDS List, Have a group labeled “VDS” with “Ping” and “List” menu items. You’ve one less word to fit in (two if you put the label above it’s associated menu items when using a horizontal orientation).
Pulldown menus. Nielsen is correct about avoiding the use of a dropdown menu for making commands. However, he’s clearly in favor of pulldown menus which look and behave like a menubar in a thick client app (Nielsen calls them “command” and “navigation” menus). I think you’ll find that there are several Javascript pulldown menus out there now, unlike back in 2000 when Nielsen wrote his post. You can fit 100s of commands in a menubar.
Sidebar menu. Arraying the menu items vertically and you should be able to fit 20 or more commands and you won’t have to shorten any command names to something user might not understand. If that’s not enough, consider a “menu bank” than combines the benefits of sidebar menu with the capacity of a pulldown menu.
Ribbon. If your commands fit into discrete tasks, where the user tends to stick to one task for a while, you can arrange the buttons on a tab control, with one sheet per task.
Command Overloading. Represent your data objects as selectable entities in your window and change your commands into more general operations, like Drill-down, Create, Copy, Move, Delete, and Link, that can be applied to various different classes of objects, thereby reducing your total number of commands. The user can select one or more data objects then select the desired command to act on them.
Work Area Attributes. Some of your commands may not be commands by settings or attributes. Remove them from the menu and represent them as data objects in the work area of the page (or another page, if they are rarely used) using controls like radio buttons, dropdown lists, and check boxes. This has the added benefit clearly showing the user the current setting as well as providing a means to change it.
Variants. For an internal app, you probably have formal roles and responsibilities that vary by work position. Include the user’s position in your model, and dynamically hide commands (and other controls and pages) that aren't relevant to that position.
What about a combobox and a Confirm button?
Or a simple dropdown menu?
Add a "Tools" or "Actions" menu bar, and stick rightmost 4 commands (or more) into the menu.
Would it be possible to implement a "most used" or "preferred" set of buttons (preferably for the user, but globally if necessary) and button to take you to the rest of the items if you need one of those?
You could group them (like the two 'vds' buttons) behind a single button that, when clicked pops a context menu with the individual icons.
It truly seems like what you're developing is a administration console which happens to present its UI through a web page, rather than something which I'd quantify as a web app. As such, especially given your statement that this is an internal use application, Jakob Nielson's advice regarding <select> tags being poor design need not apply.
For this particular set of assumptions, I think the better option is to imitate a system menu setup using one of the many CSS-based menuing designs possible.
Icons are terrible from a user experience stand point. A picture of a Floppy Disk doesn't un-equivocally mean SAVE. It means something to do with a Floppy Disk. A Floppy really, its 2010, SAVE on a web app means save to the server, how does a Floppy Disk even compute?
Here is an application that has had the same extremely usable interface for 10 years! And hardly any images for buttons, and it is one of the most productive applications in its category.
You know what ICONS stand for I ncomprehesible C ryptic O bfucsated N onsense S ymbol!
Also how do you internationalize an icon?
I have a Cocoa application managing a collection of objects. The collection is presented in an NSCollectionView, with a "new object" button nearby so users can add to the collection. Of course, I know that having a "delete object" button next to that button would be dangerous, because people might accidentally knock it when they mean to create something. I don't like having "are you sure you want to..." dialogues, so I dispensed with the "delete object". There's a menu item under Edit for removing an object, and you can hit Cmd-backspace to do the same. The app supports undoing delete actions.
Now I'm getting support emails ranging from "does it have to be so hard to delete things" to "why can't I delete objects?". That suggests I've made it a bit too hard, so what's the happy middle ground? I see applications from Apple that do it my way, or with the add/remove buttons next to each other, but I hate that latter option. Is there another good (and preferably common) convention for delete controls? I thought about an action menu but I don't think I have any other actions that would go in it, rendering the menu a bit thin.
Update I should also point out that delete should be an infrequent option - the app is in beta so users are trying out everything. This is a music practise journal, so creating new things to practise happens every so often (and is definitely needed when you start out using the app), but deleting them is not so frequent.
Drew's remark is always your first consideration. All other things being equal, I'm not a fan of making deletion as easy as creation; it's a dangerous and comparatively rarer action, and the UI should reflect that fact. However, not having an explicit delete control can indeed lead to support enquiries (the same happened in MoneyWell after the minus buttons were removed). The issue is that you won't hear from the people who avoided accidental deletion by hitting a too-close-to-the-plus deletion control; those people are happy and quiet. You will, however, hear from those who can't immediately find a button to click for deletion, even though almost all of Apple's applications have no such control.
If you feel that you need explicit UI for deletion, I think you can find a middle ground. The problem with deletion controls is accidental triggering, and the conventional "solution" to that problem is a confirmation alert. The problem with that is how intrusive and jarring they are, because they're modal. iPhone OS can teach us a lesson here: you can make confirmation entirely contextual and non-modal.
Examples are row-deletion (swipe to put the row into its "are you really sure you want to delete?" state, which visually tends to slide a red Delete button into view), then interact again (by tapping Delete) to actually confirm the action. There's a similar model on the App Store whereby tapping the price button changes it into a Purchase button; it's essentially an inline, non-modal confirmation. The benefit is that if you tap anywhere else (or perhaps wait a while), the control returns to its normal state on its own - you don't need to explicitly dismiss it before continuing work.
Perhaps that sort of approach (non-modal change as a sort of inline confirmation) can get rid of the support queries by making deletion controls explicit, but also patch up some of your reasonable concerns about intrusive confirmation.
I would say this depends on how important deletion is to the particular task. Is it something that the user has to do often, or very rarely. If it is rare, delete should just be left as an Edit menu option, and perhaps as backspace (Why cmd-backspace? If you can just have backspace, you probably won't get as many queries.)
As with everything in interface design, my take is to apply an 80-20 rule. If something belongs to the 20% of most used functionality, it should be exposed directly in the interface. If it is in the other 80%, you can hide it deeper (eg in a menu, action menu etc).
A + button is definitely in the top 20% --- you can't do anything without it --- whereas a delete is usually not a common operation, and is destructive, so can probably better be hidden away a bit.
The usual solution to this problem is to put the [+] and [-] buttons next to each other (see, for example, the Network pane in System Preferences). I generally find those buttons large enough that I don't hit the wrong one by mistake, although I can see that potentially being a problem.
If that option doesn't suit you, maybe take inspiration from Safari: put an 'x' inside the selected (or hovered) item.
Since your app supports undoing of deletion, I would suggest that you err on the side of making deleting stuff easy (at the expense of making it too easy) and make it obvious that these mistakes are easily undo-able. GMail does a decent job of that.
HTH.
How frequently is delete needed? Does the data and the user's expectation encourage deleting this data often? (is it a list of tasks, for example)? If so i'd certainly include a contextual action menu, even if Delete was the only option.
Cmd + Backspace may be a little unusual for people too - I know it's used in other places on OSX, but those places also provide context menus to expose the delete - i'd be surprised is every user knows about Cmd + Backspace, so i'd probably change it to Backspace (you do have undo support, so you're covered there).
Finally, and hopefully I don't sound like a git, but it suggests that the built-in help doesn't offer enough guidance on this - might be worth revising it?
Matt gave pretty much the same answer I was going to write.
Note that when you delete the object, you should animate it away: this provides valuable visual feedback: the animation (about 1/3 of a second is good) is long enough to catch the user’s eye, and they’ll see the object disappearing. If the object just disappeared without animating, the user would notice that something had changed instantaneously in the list, but would be less certain what it was. The animation reinforces the meaning of the delete button in the user’s mental model.
In the programming of a table-based application module (i.e. the user mostly enters tabular data in an already laid-out table), how would you reject user input for a given cell?
The scenario is: the user edits the cell, enters something (text, picture, ...) and you want them to notice when they finish editing (hitting enter, for example) that their entry is not valid for your given "format" (in the wider meaning: it can be that they entered a string instead of a number, that their entry is too long, too short, they include a picture while it's not acceptable, ...).
I can see two different things happening:
You can rather easily fit their entry into your format, and you do so, but you want them to notice it so they can change if your guess is not good enough (example: they entered "15.47" in a field that needs to be an integer, so your program makes it "15")
You cannot guess what to do with their entry, and want to inform them that it's not valid.
My question specifically is: what visual display can you offer to inform the user that his input is invalid? Is it preferable to refuse to leave the editing mode, or not?
The two things I can imagine are:
using colors (red background if invalid, yellow background for my case 1 above)
when you reject an input, do something like Apple does for password entry of user accounts: you make the cell "shaking" (i.e. oscillating left and right) for one second, and keep the focus/editing in their so they don't loose what they've typed.
Let's hear your suggestions.
PS: This question is, at least in my thought process, somehow a continuation and a specialization of my previous question on getting users to read error messages.
PPS: Made this community wiki, was that the right thing to do on this kind of question or not?
Be careful using autocorrection such as forcing user input to fit your format. See:
Is it acceptable to normalize text box content when it loses focus?.
It’s generally better to prevent invalid entries in the first place than to autocorrect them later. For example, if only integers are allowed, then you ignore any keying of the decimal point (along with all letters and most special characters). In some environments, you may want to provide a quiet audible signal that input is ignored (e.g., a dull thud).
As for when you need to alert the user to an error, how about a callout? Draw a bright line from the control or point in question (field, status annunciator, button, menu, location of a drag and drop) to the margin of the window and put a brief message (two or three words, like "Unrecognized date") in a balloon. Placing the message on the margin should keep it from occluding anything of interest in a crowded table.
The sudden appearance of the call-out should be sufficient to catch user attention, so it's okay to let the user move on to other cells in case they want to fix the error later. For efficiency, you may want to hold the user in the error-related field when the error originally occurs (since often the user wants to correct it right away), but then allow the next tab or mouse click to navigate the user away.
On mouseover or when focus is on the control associated with the error, the line is highlighted (to distinguish it from other callout lines that may be present) and the balloon expands to a full error message, providing more details on how to fix the problem (up to two sentences). Allow the user to drag and drop the balloon to a new location in case this occludes something of interest.
Include a Help button in the expanded balloon for further details. You can also include a button to fix the error (e.g., Retry, Reconnect, or set to default value).
The balloon disappears automatically when the error is fixed. Undo reverts whatever caused the error (e.g., reverts the field to its original value), which should clear the error.
If the user scrolls away from the place associated with the error, the balloon shrinks to an icon that remains in view so that the user is less likely to forget about it. Maybe an exclamation point in a triangle is a good icon. Place the icon beside or in the scrollbar track to indicate its relative location in the table, so the user can quickly scroll to find it later. Mouseover expands the icon to its full message. Perhaps clicking the icon can scroll to the right place in the table and put focus in the relevant control.
Balloons could also shrink to icons if they start visually interfering with each other. You may even want to include a control in a balloon to allow the user to force it to assume an icon.
For consistency, use for all errors, not just those associated with fields in tables.
The last time I did such a form (on a web page) I put a red box around the offending input.
I thought it was really neat... until a user asked me "Why's there a red box around this cell?"
What'd be nice is also displaying why the input's incorrect: "This field accepts only numbers", say.
You could display an icon in the cell, or a tooltip. The tooltip could open automatically or when mouse pointer hovers over the icon. It could disappear automatically when user edits another cell or when some timeout expires.
You can go with arrow tooltips like Adobe Flex's error tooltips. It focuses the attention to the error and supplies a brief description.
One of the window dialog of a software I'm working on looks a bit like this : (original screen-shot copied from this coding horror post, other examples available on this SO question)
The thing is that none of the options can be removed (those who can have already been), and that they must all be visible at a glance (i.e. no tabs allowed) Edit : I've added a comment explaining why tabs are not an option in my specific project.
I've tried to use colors, to add icons, but it just added to the overall feeling that someone had just dropped controls randomly using Visual Studio Form designer during a summer internship.
How can I make this dialog more user-friendly less horrifying without deleting features ?
Edit :
The GUI example I took has a lot of obvious design flaws (see those answers 1 2), but even after fixing those (which I've done on the software I'm working on), the dialog still looks pretty ugly.
Below is another example (credit). Controls are (almost) lined up correctly, appropriate controls are used, etc, but the overall result still looks terrible :
(source: judahhimango.com)
Given the constraints I think you won't have many options.
A good starting point would be to equal the alignments and control distances to increase overall symmetry with the ultimate goal to reduce visual clutter.
Examples:
The group boxes "Special" and "Running options" should have equal height.
The distances between the four buttons "Save settings" and "Exit" should be equal.
All buttons should have the same height, if possible avoid word wrapping.
Use the same height for all single-line edit boxes.
The quota label and its text field should be at the same baseline.
The distance between a group box caption and its first control should be equal (compare "Running options" to "Retrieval options")
Increase the distance between the controls in general, i.e. make the form look less dense.
Content fixes:
Use the same captions/names for the same things. For example, you use "Append to logfile" but "Overwrite Logfile
Use the same character case, sometimes it's "Only the first one", "Every Single Word" and sometimes "it is Camel-cased". Decide on one scheme and use it consequently (Sentence case and Title case are the most common)
Don't try to be cool, "Go 2 background" doesn't look very professional.
Avoid controls with unreadable shortcuts or no content at all. It doesn't help if the user has to stop on every control and think: "What does this thing do?"
Some more radical/controversal changes:
Try making the group boxes more symmetric, possibly be re-positioning them and use the same height. If necessary use two columns of checkboxes, that would still look better than uneven group boxes.
Unless it's absolutly necessary, remove the horizontal scroll bars from the two multiline edit boxes
Get rid of the "Clear" buttons. For the list box on the buttom left you have to provide some other way to delete items, perhaps make this into a multine text box, too.
Try replacing the checkbox collection with a checkable list box or a property grid.
A rule of thumb:
Imagine the lines of the bounding box of each control lengthed until it reaches the form boundary. The less different lines reach the boundary, the better. (Because correctly aligned controls produce more incident (-> less unique visible) lines)
On the use of colors and icons:
Simply adding icons and colors doesn't solve the fundamental problems such forms have. They all suffer from being overloaded with controls and adding even more only worsens the problem, because they just add more visual noise, but don't provide any more visual cues.
The problem with your examples, and the reason that they look cluttered is that there's not enough spacing between the elements. You think you're saving space by making things smaller, and putting them closer together, but it's a false economy because your eyes have to work harder to differentiate elements from eachother. Think about writing a computer vision program that had to OCR those interfaces, and the challenges you'd have just figuring out which element was which, let alone what the type says.
Regardless of what your programmer efficiency instincts might say.. it's okay to put space between your elements, and hell, it's okay to even have large amounts of completely "wasted" space too.
have a look at this
There's a clear boundary between the flower and its background. The shallow depth of field of the photography gives a clear contrast, and allows you to very rapidly construct a mental sillouette.
jungle http://www.statravelbuzz.co.uk/wp-content/jungle-taranaki-new-zealand.jpg
what's going on in this image? There's too much detail, and it's all over the place.
have a look here
http://www.papress.com/thinkingwithtype/text/line_spacing.htm
(source: papress.com)
think about what the line spacing is doing to your ability to distinguish words from eachother. What's it doing to the visual sense of clutteredness?
You can see from the type example that you don't have to give up much in terms of space efficiency to see massive gains in visual appearance.
grid systems
grid systems http://ecx.images-amazon.com/images/I/51kcWOOyUoL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg
thinking with type
other reccomendations:
stop stealing sheep
elements of typographic style
the design of everyday things
the humane interface
If you've already dealt with alignment and organizational aspects as much as you can, then your problem probably is the graphic design of the controls. Heavy 3-D controls in large numbers are detrimental to the aesthetics and usability of a window. Consider editing their properties to flatten and lighten the controls’ appearance, using something I call “compact presentation.” In addition to removing the ugliness and distraction of heavy borders and backgrounds, this also allows controls to be placed closer together, freeing white space for grouping them without resorting cluttering lines and frames.
It looks something like this (after also fixing alignment and redundancy along with a little re-arrangement of groups):
(source: zuschlogin.com)
If you're on WinForms, One trick I've found useful is to pack multiple-instance data in a DataGridView, and single-instance data in a PropertyGrid. Both these controls help you pack lots of information in very small space, and still give you full control over their visualization (you can add descriptions, tooltips, etc.)
The thing is that none of the options
can be removed (those who can have
already been), and that they must all
be visible at a glance (i.e. no tabs
allowed)
Sigh. I would argue that, because everything is visible at a glance, they practically become invisible in a sea of controls.
That being said, the ff (yes another list) are my suggestions:
To reduce clutter, make the overall form bigger, and all controls more widely spaced apart in all directions
Standardize the height of the controls, e.g., textboxes must all have same height, buttons all have same height, etc
Align labels with text boxes more consistently
Make the layout flow down instead: 1 column, with each group having the same width as all other groups
Set all group box names in bold to make them stand out
Put all those "wGetStart.bat" commands in a group of its own
If you really want to learn more about making it "flow", with or without getting rid of all this "visible" information, you might wanna get a copy of Steve Krug's Don't Make Me Think:
Because tabs are not allowed, you can create a more grid like layout.
Adding detachable panes for related options and commands can help the user to organise them, at least. If they can be minimised/unpinned when not needed, then they can also free up valuable screen estate and unclutter the UI. See VisualStudio itself for a nice implementation.
Here's my random selection of suggestions:
make it bigger, this allows a more structured grouping by reducing the space constraint on each group
add some structure by grouping options that the user might want to combine at the same time
add meaningful headers (might require the previous item). "special", "running options", "retrieval options" don't really convey any useful information.
make sure that only options that can be combines randomly are checkboxes (for example are "no info", "all info", "some info" really completely independent options? Same for "append to logfile", "overwrite logfile").
use appropriate controls (spinner for number entry, file selection dialog for files, radio buttons for mutually exclusive items, ...)
deactivate controls that make no sense with current configuration (for example custom directory text field).
move all actions to a single place
hide the scrollbars unless they are actually needed (i.e. reduce visual clutter)
be more consistent (why is it "running options" and "retrieval options" but not "special options"?)
One thing that you may have, but is obvious for the WGET example is the use of a main menu, e.g. File, Edit, Tools, Help. And also a button bar too?
First, define a hierarchy of control blocks. Even if everything must be visible, I think that some functions are more important than others. Also, make a clear separation between functions that apply to the domain (e.g., Start wGetStart.bat) and functions that apply to the software (e.g., Save settings).
Second, organize the layout according to this hierarchy: most essential to the top and to the left.
Third, let your design breathe. Space is fundamental for defining content.
Since no one has said this yet, I will: your window isn't really all that bad. Yes, it's ugly, and yes, I would be personally embarrassed to admit that I designed an interface that looks like that.
However, this window only produces a negative reaction the first few times you look at it. Once a user has used this form a couple of times, they will stop seeing it as a random collection of controls and instead start perceiving it as an interface that lets them see every piece of information that they require at a glance and that lets them do everything they need to do with a few mouse clicks.
It's a dialog for setting a bunch of options, and it's probably perfectly functional and not a big deal at all for your users. You could put a lot of work into some weird, fancy-schmantsy replacement UI that might impress the StackOverflow code-noscenti, but we don't pay your salary.
Now, the second window - that's a piece of crap.
Without knowing both the content your application and what it currently looks like, I can only guess at the problems you are facing, but here goes.
You say that this is being used by traders. While I have never dealt with that segment of the market I have often dealt with executives who need very specific information to run their businesses and the first cut of the application almost always looked like what you have displayed.
The original solution back in the day was to build a very light custom interface for each user of the application focusing on only the information relevant to that person. More recently the move has been toward making the interface customizable by the end user.
Chances are that none of your users are using all of the information presented to them. Each of them is using only a small subset. But each user is using a different subset. Try building the software so that each user can display only the information that they will be basing their decisions on.
Aside from other much-needed changed, adding a banner (displaying the company logo or something like that) seems to improve the overall appearance of the dialog.
I know it's a pure waste of space but it seems to improve the global feeling about the window.
alt text http://img24.imageshack.us/img24/3423/wget.jpg
Duplication - they might all have to be available instantly, but they could be available elsewhere as well. So you can have a keyboard accelerator, menu option, detachable panel, tabbed area ...
So this existing form could be the main, default interface (albeit improved with some of the other good design tips in other answers), but why not create an "expert" panel which can be a lot neater and try to work your users on to that, and away from this old "do everything" blotter.
I would really consider evaluating the usability goals of your project. Figure out what users want to do most frequently and most consistently with your application and default to that.
You should consider a wizard for this UI. Guide the user through a set of screens for the first use. And move many of these features as configurable options preferences.
Usability is not merely aesthetics IMHO. It is about making clear what the app is intending to do. I would refactor this app to provide shortcuts to common options patterns. If 90% of the time I am going to use a specific configuration of options why do I need to see every feature enumerated in the UI 100% of the time? It is just unnecessary clutter. Sensible defaults powerful configuration that is the goal. You don't have to sacrifice features, in a sense not making me think is a feature, perhaps the most important feature.
With respect to your specific app I would rework it with two basic screens a clean default screen and an advanced screen. Add the ability to create shortcuts to common configuration sets on the default screen. A simple button that maps to a specific configuration set and asks me for a url. And if the user needs to tweak an option present them with the advanced screen but treat it as preference configuration screen that saves the preference out to a shortcut button. If I want to use the configuration more than once let me save it as a custom bookmark or option on the defaults screen.
This is one of the things OS X does really well. There is a lot of power and customizability in OS X, "hidden features" if you will. But the OS defaults to sensible and straight forward options. Provide tools to the power users but don't clutter the system for the first time or casual user. This is not sacrificing functionality, it is effectively organizing functionality.
That is my first suggestion. But if absolutely don't want to hide options, I would make this a long scrollable vertical list organized in clear steps with explanation for each step:
Step 1: Provide URL ______________
Step 2: Configure Hosts _____________
Step 3: Configure Retrieval Options:
() option
() option
() option
() option
And so on...
At each step provide some context to the meaning of the configuration options.
The advantage to this is that you can clean up the UI aesthetically and provide useful configuration hints. I don't know what "Empty wGetStart.bat" means. I presume this empties a batch file of some sort. Provide me an explanation so that I know whether I want to click that button or not. And then let me hide explanations under a collapsible menu if I use the interface regularly.
My two cents.
This may not be appropriate, but...
Hide all the options in a stylesheet, much the way that all the paragraph formatting options are hidden in a word processor. Most of the time, the user just picks a named style. When the scary stuff is necessary, a click of an 'Advanced' button can grow the form to show all the options at a glance, to allow a few to be overridden, or to allow new named styles to be defined.
Obviously, a major advantage is that if there are a few particular configurations that are regularly used, it's trivial to switch between them and there's very little risk of accidentally setting one of the options wrong.
Another option - don't have all your options on display, use tabs or a wizard or whatever. Instead, have a text list of all options currently set (or all options in non-default states or whatever) to get the at-a-glance visibility.
These could be combined, so that your summary display says something like "like <style name>, except for ...", based on the style that's least different to the current options.
In a comment you say that a user "HAS to have all information available at once". Does that mean they have to see all the checkboxes and frames and scrollbars at once, or just the information?
For example, instead of having a multitude of checkboxes for option 1, option 2, option 3, etc, in the main GUI, only show the selected options and give the user a way to open a configuration window when they need to change something.
Instead of this:
+- Feature Set X - +
| |
| [x] option 1 |
| [x] option 2 |
| [ ] option 3 |
| [x] option 4 |
| |
+------------------+
show this:
feature set x: option 1, option 2, option 4 [configure...]
This lets the users see all the selected options without having to take up valuable real estate for all of the widgets necessary to change the values.
(apologies if the ascii art doesn't appear right -- it looks right in a fixed font :-\ )
An interesting article on this topic:
Managing UI Complexity by Brandon Walkin.
In the second example I would remove most of the arrows from the right hand side box. I would add the ability to click and drag to change the number(if your users are used to that I know several 3d packages that do it so it wouldn't be uncommon in relation to the example). You can change check boxes to buttons with backgrounds that change color or stay depressed when clicked as another option to reduce visual clutter.
In the right hand side box there are two or three separate functions mixed together that very well could get their own tab. When you are working with an object's color and texture you aren't going to be changing its size and view aspect ratio so having them right there means they are in the way. At the very list they need to be rearranged to be in some sort of logical order right now they are all over the place. Texture and color(things that effect color) should be together. Position rotation and view(things that effect shape\size) should be together.
It has already been said, but without seeing your application we can't give you a concrete answer on how to make your dialog less horrifying. If you can't post screenshots, then the best advice I can give is to hire a designer to help you work on the graphical end of your application; otherwise all you will get are general guidelines here.
Some things that might have not been discussed:
Think about the users of your applications and the systems that they run. I believe that most stock traders will have large dual monitor setups, so you can probably make your dialog larger and add space between your controls to make it look less cluttered. You should research your audience and see what they use.
Are you using the best controls for the job? In the first screenshot you posted I noticed a few controls that could be changed:
a. Under "Running Options" I see three checkbox options called All Info, No Info, Some Info. If only one can be selected at a time then maybe they could be changed into a drop down selection menu. Also under the same "Running Options" there is Append Logfile, Overwrite Logfile, which again you can convert to a drop down menu since you can select only one.
b. The two text fields where you can put in hosts, can probably be combined into one gridview with three columns. The first column is the host, the second is a checkbox for Accept, and the third is a checkbox for Reject.
By simply using different controls, we can still see everything we need but have less controls on the application.
Again, like I said above, witout seeing YOUR applications I can't really give you any specific suggestions.
Hope this helps.
Often times convention is one of the most important design consideration for user interface. Usually the advice goes to do it like Microsoft does.
This is for three reasons:
If it ain't broke, don't fix it.
If your users expect to click on a floppy disk icon to save, don't change the icon (even though some of them may have never seen an actual floppy disk).
Users don't want to re-learn the interface (and hot keys, etc.) with each different application they use.
At the same time Emmerson said "*A foolish consistency is the hobgoblin of little minds.*" So when does maintaining a consistent user interface cross the line from a good idea to stagnated innovation?
Microsoft shook up the good old WIMP GUI with the introduction of the tool bar, and then again with the Ribbon control (which is the natural evolution of the tool bar, like it or not.) Now we are seeing ribbons everywhere.
So my question is, what are some user interface paradigms that are accepted and consistent across multiple applications, but have stayed past their prime and are starting to reek? Are there some important changes that would benefit from a grass roots push by developers to innovate and improve the user interface experience for our users?
One thought that came to mind for me is the modal pop-up dialog. You know the ones that say: "Are you sure you want to . . .. - [Yes] [No] [Cancel] [Maybe]" and its evil twin "Successfully completed what you wanted to do! [OK]." We are seeing a movement away from these with the "info panel" in browsers. I think they need to be adopted in windows application development as well.
If possible please list a solution for each stale UI item.
And please don't list clippy. We all know he was a bad idea.
NOTE: This is specifically Windows client user interface paradigms, but I am certainly open to drawing inspiration from the web, the Mac, etc.
You mentioned popup modal dialogs , and I'd argue that non-modal ones are just as bad. Any dialog box remove focus from the program, they could end up behind the program and make it hard to find it, they might not even appear on the same virtual screen.
I'd like to see an end to all dialog boxes. If you need to stop someone from using the UI because of some non-normal circumstance, then remove the relevant parts of the UI from the window, and replace it with what the dialog would contain. Bring back the UI once the problem has been handled.
Clicking things on touch interfaces
It's incredibly difficult to click on things on a touch interface, because you don't know when you have pressed the screen hard enough. And if you add an animation to the button you are clicking, you most likely wont see it, because your finger is in the way. Adding other reactions, like vibrating the phone or painting waves on the screen might work, but there is usually a delay which is too large, much larger than the tactile sense of a button being pressed. So until they invent a screen with buttons that can be pressed, all touch devices should move towards dragging user interfaces (DUIs) instead.
Counter intuitively it is easier to press an object on the screen, drag it, and then release it than it is to just press and release it. It's probably because you can see the object moving when you start dragging, and you can adjust the pressure while dragging it. Dragging also has a lot more options, because you now have a direction, not just a point that you clicked. You can do different things if the user drags the object in different directions. Speed might also be used, as well as the point where the user releases the object. The release point is the real strength of DUIs, because it is very easy to release something, even with pixel precession.
Some designs have started to use DUIs, like (here we go) the iPhone, palm pre and android phones. But only part of their design is DUI, the rest is clicking. One area they all have in common is the keyboard. Instead of clicking on a key the user presses any key, then drags their finger towards the key they really wanted to click. Unlocking these phones also uses dragging.
Other easily implemented DUI features would be things like mouse gestures, where dragging in different directions, or drawing different shapes does different things. There are also alternate keyboards being researched which puts a bigger emphasis on dragging. All buttons can be changed into switches, so have to drag them down a bit to click them. With a well designed graphics, this should be intuitive to the user as well.
The Apple Human Interface Guidelines are a good read on this topic. They discuss this from a very broad point of view and the guidelines apply to any platform, not only Mac.
The file system. I want to save a file.. >OOOPs I need to think of a file name first. Well.... how about ... blah.doc.
6 months later...
Where the %#*(%& * did I save that %()#*()*ing file?
The solution is build a versioning system into the application, or better, the OS. Make files findable by their content, with a search engine, instead of forcing the user to come up with a memorable name, when all they want is for their file to not get lost.
Eliminate the save step. Type something in to the application, and it's just there, and there's no risk of losing it by some misstep, like forgetting to save. If you want an older version, you can just pick a date and see what the document looked like back then.
To build on the search engine idea: It's a pain having to navigate some arbitrary tree structure to find your stuff. Searching is much easier. However, you might still want to have something like a "folder" to group multiple files together. Well, you can build a richer metadata system, and have a "category" or "project" field, and setup the search engine to show items by project, or by category. Or group by those, or whatever new UI discovery we make next.
This question is a bit too open-ended, IMHO.
However, my main approach when designing anything is:
Fits in to wherever it is. If it's a windows app, I copy MS as much as a possible
It's simple.
It provides options
Buttons have a nice description of what the result of clicking will be, as opposed to 'yes or 'no'
Harder to answer the rest of your post without spending hours typing out an arguably useless (and repeated) set of guidelines.
In my mind, the one thing that really stands out is that USERS need more and easier control over the application's user interface appearance and organization.
So many interfaces can not be modified by the user so that the most used/favorite functions can be grouped together. This ability would make your favorite software even easier for you to get things done.
Error messages need a "Just do it!" button.
Seriously, I really don't care about your stupid error message, just DO WHAT I TOLD YOU TO DO!!!
I think the entire Document model of the web needs to change. It's not a user interface, but it leads to many, many bad user interfaces.
The document model was a good idea to connect a bunch of documents, but now the web is also a collection of applications. Today, I think the Page/document model corrupts our thinking. We end up lumping things together that aren't related, modularizing our code wrong, and in the end confusing users with our monolithic control board type websites.
Find dialogs that sit over the widget in which you are doing the search are terrible. Loads of apps do that. The find bar in Firefox works much better.
Many applications have multiple panes within the UI - eg in Outlook there's the preview pane and the inbox pane (amongst others). In these applications typically cursor key presses apply to the currently focussed pane. But there's very poor hinting to show the user which pane has focus and there are seldom keyboard shortcuts to move the focus between panes.
The focussed pane should be highlighted somehow.
Something like alt+cursor keys should move the focus around.
Ctrl-Tab and Ctrl-Shift-Tab cycle left and right through tabs instead of MRU behavior, even though in most cases the same behavior is duplicated with Ctrl-PageUp and Ctrl-PageDown.
There are a lot but here's an idea for a couple of them:
Remove some clicks like in "add another" or "search item" and the like.
This is well done with interfaces like ajax which have autocompletes ( and auto search ) but is slowly being adopted for platform UI's ( and in some cases they were originated in platform UI's. )
This is how StackOverflow does it for some scenarios.
But of course, we all know that already don't we? No need for "Seach tag" or "Add another tag" buttons, they just happen
Dialogs as you described.
Guys at Humanized proposed Transparent messages which actually are used in their product Enso and some other places.
Mac uses them for notifications ( like in Growl ) use them very well, or Ubuntu new notification system.
alt text http://blogs.sun.com/plamere/resource/NowPlayingGrowl.png
Firefox replaces the traditional "Search" dialog box with a search bar at the bottom.
Although not everyone likes the placement for next/previous as in this screenshot
And even SO ( again ) :) replace the notification with the yellow bar.
Finally:
File managers
I really like ( sometimes ) the simplicity of regular file managers, but some times I would like to work faster/better with them.
If you compare IE 4 with IE 8 you can tell the advance ( even better compare IE 4 with Google Chrome )
But if you compare Windows 95 Explorer with Win XP they are almost the same!! ( Win Vista/7 is a step forward )
But I wonder: Why haven't file managers improved as much as webbrowsers?
That's one reason I like stuff like QuickSilver but it is just a step. Much work is needed to create something like a "Perfect program launcher" or (FileManager/DesktopSearcher etc as you wish )
QuickSilver featuring "move to" action