The user of an application wants to
assign a task to a programmer.
The "Edit Task" form is presented to the User.
A popup (actually an absolutely
positioned div) window comes up with
all the programmers to choose from.
The programmer is not there so the
user asks for a "new programmer"
screen. The popup is replaced with a
"New programmer" form.
The user fill the data, and comes to
"Works at" field.
A (2nd or 3d) popup comes to the
stack with all the "Places" to
choose from.
This can go ad infinitum.
How do you design your applications, to avoid the infinite stack of lookup/Entry forms?
Alternatively to creating a (recursive) stack, you could make it a sequential queue of information that still needs to be entered (similar to a wizard). I.e. where you select the programmer, an item would say "(new - will ask for details later)". If it's going to be a wizard, it should have forth-and-back buttons everywhere.
If all the information is required, and none of it is in the system, I don't see how you can avoid having that many dialogs, really.
You can design the UI so it's not to intrusive, of course - try to make the transition between "pick a place" and "new place" as smooth and seamless as possible. In particular, I'd try to avoid it making the first dialog "go away" as such - perhaps just make it extend the existing one, collapsing the existing choices.
It sounds like you've got an appropriately logical division between "who" and "where" though, which I like - I hate entering completely disparate pieces of information on the same form, even if cuts down the total number of forms displayed.
Try not to lose the scope and the target of the screen. For example, in the "Programmer" screen, you need at least to add the basic details of the new programmer item. The user shouldn't add all the details. If the user wants to add more details, he should add it later from the related "Add Programmer" screen.
Check GMail when you create a new filter and you need to add a new label for example.
Related
I'm working on redesigning a web interface to provide the same functionality it has currently but with easier use via good UX design. Currently, here is what the design looks like:
I'm less worried about the tofu look and feel, that can come later, I want to nail the UX functionality first. The idea here in this tab is the user can select the items via a checkbox and perform the actions in the "I Want To" drop down (which opens different modal dialogs depending on the action). The 3 dot ellipsis on the right of the items in the list allow the user to perform the same actions via another drop down control, with the idea that they use the top drop down to perform the actions on multiple items, the ellipsis three dot menu for one item.
The obnoxious part of this control is that the list could contain hundreds of items, and the check box takes too much precision to check quickly. The user would select which items they would like to perform the actions on sequentially, then have to scroll up to the top of the page to select the action. This could be 5 seconds of scrolling, which I find obnoxious. I want to develop a good UX pattern to provide the same functionality in less clicks, scrolling, and frustration.
My inital idea was to provide a floating action button. The user could then * somehow * (I haven't thought of an idea yet, at minimum at least a bigger check box) select multiple items then pick what they want to do via the floating action button which is always within the bounds of the screen instead of the horrible scroll back to the top (I don't think a "scroll to top" button is a good solution for this either).
So I need some recommendations on a UX pattern or some general suggestions on how to make this process less frustrating for users. I'm a fan of material design right now, but I'm open to any suggestions, material design guides don't seem to have any paradigms for something like this.
I think the UX steps are in a good track: first select them, then set the action.
Instead of it being only a checkbox to click, the whole top part of each line could be clickable to select the item. This would make it much easier for the user, and less frustrating not being able to hit the checkbox.
Fixing the header on top would be usefull for adding a "Select/Unselect all" option and having the actions always available. Adding a searchbox to filter could be as well a good option if you are thinking of long lists. Combining the search box and the "Select all" option should help the user in their tasks.
If that is the most important action to be done in that screen, making the "What to do" button stand out a bit more would be a good idea to differenciate the primary from the secondary options for the user to do.
I see two simple things you can do to make this more usable with very little effort.
Remove the checkbox and make the entire row tappable, highlighting those selected. Each row would essentially become the checkbox's label, and the checkbox itself would be hidden from view.
Fix the header to the top of the browser window when the user scrolls down.
I have little experience in developing GUI for desktop applications, but I want to develop a typical GUI for creating/editing entities (e.g. Customer, Suppliers, etc.) which would be similar for many cases and would be comfortable for the users.
[* Please don't close the question. I put much effort in preparing the question and I really need help. *]
After analyzing our tasks I designed the following possible options:
1) In simple cases it is possible to solve the task by using an ordinary grid:
I.e. the workflow is: On pressing the Add button, a new row is added to the grid. On pressing Delete the user is asked for confirmation if he/she really wants to delete the focused entity instance. On pressing Save all previously made changes are saved. On pressing Close the form is closed (user is asked if he/she wants to save changes before closing).
Cons: I think such a GUI will only work for very simple cases. Editing something complex in a grid is not comfortable neither for a user nor for a developer (implementing complex editing in a grid will not be trivial I think).
2) For more complex entities the following option is possible:
The grid is used here only in the read only mode. On pressing Add a modal form for filling information about a new entity is shown. On pressing OK in that form the data is validated and if everything is ok the object is added to the grid datasource. On double clicking on a grid row the same form for editing the chosen entity instance is shown.
Cons: For every entity we will have to create 2 forms.
3) Another possible option:
The grid is also in the read only mode. When focusing a row in the grid, the fields above the grid are filled and a user can edit them. On pressing Add a new entity instance (object) is created and added to the grid's datasource, then the new row is focused, fields above the grid are cleared (binding helps here), the cursor is placed to the first field and the user can start typing.
I don't see any cons here except that maybe you will not have enough place for the grid and the fields on the same form. I like this option though I don't remember that I saw it anywhere.
I tried to ask the users of my program to help me decide which GUI is better for them, but the typical answers are "I think both options are ok" or "I don't know, you decide which one is better".
Now I would like to ask people with experience in GUI design the following questions:
1) Which option do you use usually? Maybe another one (not shown above)?
2) Would be nice if you also said a couple of words about your implementation (dataset/custom business objects/binding, etc.)
3) Which cons did you notice in my options?
4) Any advice on what I can read on the subject?
Thank you for help!
Junior1993, This is a great question, and there are many online resources that will spell out the trade-offs of each of these interaction design patterns, when to use them, and when they are most effective. You did not provide project-specific details, so it's impossible to answer those questions.
The "Work With" pattern is the foundation of your write-up, and you were asking about the pros and cons of different variations. Here is some reading on "Work With": http://quince.infragistics.com/html/PatternView.aspx?name=Work+With
All of the patterns you described are well-documented and can be modified to fit different purposes.
Your #2 pattern is "Edit-In-Place". It can also be found on the Quince site.
Your #3 pattern is "Two-panel selector".
This one takes many forms, but it helps to preserve context while editing.
The one you did not mention was "New-Item Row". You might want to look at that one, too, and select the pattern or combination of patterns that best fits your users' goals and the content they are creating/editing.
There are other pattern websites out there, and most build on the work of Jennifer Tidwell, author of "Designing Interfaces", an interaction design classic.
Best of luck to you!
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?
In a project I'm working on, we have a nav menu where items are colored when the relevant section has information beneath it, or faded when there's nothing available to the user. In the case of an admin, these items may have no useful information but may still be clickable (since things like "Add news item" or "Add file" are implemented as sub-menus).
The call from On High has come down to make these admin items stand apart somehow. Since we're already using the faded text for unclickable items, I was wondering if there's an established UI convention for denoting that an item is clickable, yet contains no information.
And yes, I've already asked why we're bothering to show items that aren't available to the user. The short of it: because On High wants to.
Short answer, no I don't think there's a convention for this. Lots of people would say if its not applicable, don't show it. However, there's some debate on this. One of the reasons Microsoft started using The Ribbon in MS Office is because they wanted to get away from dynamic menus where options hid and showed 'intelligently'. Users couldn't figure out the rules for what appered where, and when.
Maybe separate the concerns here: 1) how to indicate the item is clickable, and then 2) how to indicate the item contains no information.
The first one is relatively well established -- blue underlined text. You can also make it look like a button Of course, if you've got a site-specific look for your hyperlinks, use that. Basically don't break the users' expectiations of what things are clickable.
Second, how to show there's nothing there worth clicking on. I think what you want is some visual indication of the priority/utility of these admin links relatively to others. Some options:
Can you move the admin links to the bottom of a list?
Add a number indication how many things are on the other side of the link?
Strikethrough on the text?
Since there are no hard-and-fast conventions on this sort of thing, just remember that anything you do which is consistent will work. Some things will just work better than others.
No matter what you choose, the user will learn after a few tries what the new method of empty indication is.
If it is well thought out and consistent, they will probably get it after a couple of clicks.
Also, remember that too many highlights, colors, fades, and underlines will wash out any amount of effectiveness at visually organizing your menu so it is easy to use. At some point it can actually get harder to use by over-organizing things.
Think about it this way: There are two boxes sitting on a virtual shelf. One is red and the other is blue. The selected box is identified by a differing color than the other box... Now, which is the selected box?
We are designing the UI for a new line of business application. We have no real constraints and are free to design the UI as we see fit. The UI will be done in WPF and targeted for Windows 7, Vista, and XP Pro users.
Many dialog boxes contain OK and Cancel buttons in their lower right corner. Do you feel it is necessary to have this Cancel button or is the red X in the upper right corner sufficient? We are discussing this as we have been noticing more UIs that do not have cancel buttons, only the red X.
Not only you should add it but also make sure ESC is mapped to it.
Present the two designs to the customer - one with the "Cancel" button, the other without. See what their thoughts are.
Better still present them as partially working prototypes and watch them as they use the dialogs. If you ask them to perform a set of tasks and see if they have trouble when asked to cancel an operation.
Having said that, my preference is to include a "Cancel" button for the reasons others have mentioned:
Accessibility (especially as Esc should be mapped to it).
Convention (users will be expecting it).
Include the Cancel button. The red X is VERY hard to tab to. ;)
Include it. This is very common in other user interfaces. Give the user the choice of which to use; making it for them might make them annoyed with your interface.
Users are used to having standard GUI layouts - otherwise they get confused. They also have different ways of using the standard interface. Some people only use the X, some people only use Cancel. People usually ignore the one they're not using, but get confused if their one isn't present. So be safe and keep them both in - it should only be a one-liner function for Cancek anyway.
Include it!
From a user interface perspective, not including a cancel button might leave some users feeling like they have no choice, which is certainly not the case. Imagine the following simple decision scenario:
Warning: All of the files in the selected folder will be deleted. This action cannot be undone. Are you sure you would like to continue?
How silly would an interface be if the only option was Ok? Also, as noted above, on many platforms the Escape key is mapped to Cancel. It's also probably worthwhile setting a default button so that pressing the Enter/Space key doesn't inadvertently perform the action that cannot be undone.
+1 on including it. If you don't include it now and then need some different functionality on Cancel to Close later on, your users will already be used to automatically closing.
Just like we have 'ESC' button on keyboard, we need 'Cancel' in dialogs.
A matter of usability :-)
Include it. And please also make sure that you make sure that hitting the Escape key does the same thing as the Cancel button.
Also, just because you're designing from scratch, please don't throw out all convention. Take a look at MSFT's UX Guidelines for dialog boxes.
The red button is really for 'Close' rather than 'Cancel'. 'Cancel' canceling a running task. Use a 'Close' button instead. And yes include the 'Close' if there is a reason for people to click on it. The red button is quite difficult to click when you really want to close something quickly.
If you have that kind of freedom, consider eliminating dialog boxes from your application entirely, especially ones with the typical "OK | CANCEL" paradigm. Dialog boxes disrupt the flow of action and generally should only be used for things which absolutely require the program to interrupt the user.
You'll notice how disruptive they are in the web environment -- e.g., Stack Overflow only uses them when it needs to be able to OVERRIDE your action, e.g., when you navigate away from an unsubmitted answer.