What's wrong with this dialog?
I am writing a book. And I am writing a chapter about UI design. And why not use the Internet?
So, go ahead and tell me all that's wrong with this dialog!
For example, I don't like the dead space at the bottom-left, the different-size of the "Close" button, and the misalignment of the icons.
Are those valid concerns? Are there many more? Would you do it completely different?
The book is open source, and available at http://nomuerde.netmanagers.com.ar (In spanish, sorry!)
IMHO, the up/down buttons, which are only changing the order (not changing anything to the radios themselves) should be split with a larger space from the add/remove/edit button.
how about putting them in the radios themselves (plus drag and drop)?
BTW: Drag&Drop for sorting is cool if your target is digital natives.. If not, i think up&down buttons are a better approach
Yes, I don't think losing up/down is a good idea.
Something we all get "wrong" (IMHO) when doing this kind of dialogs is that we mix-up single-object related actions with global actions.
In this case:
Add is global
Edit, Remove are single-object actions (one radio station)
Up, Down are single-object actions (radio stations list, as @jerome said)
good point. What do you think about adding the single-object ones in the list itself, and they appear when you hover over an item?
That would be cool... But keep in mind that it will require to increase each radio item's height (don't know if that's bad or not :P)
Well, it would be great for a touchscreen :-D
The "hovering" concept is terrible. Remember Microsoft's disaster with "disappearing" menu items -- users don't like interfaces that will change.
I'd separate Up/Down from the others (nonintrusive, trivial operation), and possibly separate "Remove" with some additional spacing around it, to make it harder to select a destructive action "by mistake". So I would end up with something like Add - space - Up / Edit / Down - space - Remove - space - Close. Obviously object-related actions should be disabled unless an item is selected.
Also "Close" is too ambiguous - when I close, will my changes be saved? I'm scared! "Done" would be better, it implies the changes will be saved. Talking of which, there is no Undo / Reset / Cancel feature, which is VERY bad.
The "Edit" icon is terrible. The "Add" icon is not much better. And obviously your remarks on alignment.
Agreed that "Done" is a better idea than "Close".
The icons do need some extra love, but they are not really the concern here.
Thanks for the feedback!
Primero quiero felicitarte, Roberto, por tu iniciativa. Aunque sigo tu blog desde hace poco tiempo, intento no dejar pasar ninguno de tus artículos. También yo estoy escribiendo un libro sobre programación (en mi caso es un libro introductorio) que incluye diseño de IGU.
Para el caso que presentas tengo para decir que:
- No me gustan los cuadros de diálogo, especialmente los modales porque son disruptivos.
- Los botones "Add", "Edit" y "Remove" están conceptualmente relacionados y ello debería reflejarse en el diseño.
- El botón "Remove" como toda acción destructiva podría estar ubicado en un lugar más alejado, de modo que sea difícil para el usuario hacer clic sobre él por error.
- Los botones "Up" y "Down" también están conceptualmente relacionados, por lo que deberían estar agrupados y algo separados del grupo anterior.
- El cuadro de diálogo tiene un botón "Close" pero no un botón "Ok", por lo que se deduce que las acciones realizadas tienen efecto inmediato, y esto podría no ser lo mejor. Entonces, podría ser necesario incluir los botones "Apply" y "Ok".
- Los botones "Add" y "Edit" parecen requerir sendos cuadros de diálogo que permitan la introducción y modificación de datos, con lo que la interacción se hace más tediosa innecesariamente. Podría modificarse ese diálogo para incluir los controles requeridos por las acciones "Add" y "Edit".
FInalmente, me resta decir que todo lo anterior es relativo porque la interacción debe estudiarse en función de las características de los posibles usuarios, siempre que esto sea posible.
Este dialogo es necesario porque la aplicación no tiene ventana principal, es un icono en el area de notificacion nomás.
Gracias por el feedback :-)
Read About Face by Alan Cooper. Every piece of UI (action, button etc) is forcing the user to make choices. Machines have billions of processor cycles per second and oodles of memory - so why make a human do these choices. You are the programmer of the app, and you can't make sensible choices despite having full detailed knowledge, so how would a user a do so?
You need to distinguish between goals and tasks. Goals are what the user actually wants to achieve (something with radios?) and tasks are the hoops you make them jump through to get there. Alan Coopers article on goal oriented design is a good primer: http://www.drdobbs.com/1844...
Sorry for the crappy formatting of that Dr Dobbs article. They make the screenshots be pages 1 through 7. Go to page 8 to read the actual article.
Thanks, I will!
To me, the most obvious problem is that there's only one value, but the Up and Down buttons are still enabled, even though they can't do anything.
You know, that's actually debatable, for example: http://www.joelonsoftware.c...
Joel say:
"Don't do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work."
The obvious clues (but maybe not enough) are in the available controls, than the user should use before. Moreover, you can put some kind of signal to guide at the user.
I don't see solids arguments in the article of Joel.
That than Joel describes is the kind of things that's part of an Intelligent GUI, whose purpose is avoid new users make mistakes or indicate about a condition that should be accomplished previously, and avoid the need to raise error messages. This kind of interaction can't be used in all cases, is just for some specific cases.
There are some studies about the evil of "changing UIs" but I don't know if disabling controls is considered in that.
I'm with Fabián on this one --- I don't see that any of Joel's arguments really apply here. If the user wants to click Up or Down here, they've misunderstood what those controls are for; having them disabled is a good hint that they're not applicable now.
I think the idea of having «move up» and «move down» buttons is wrong in the first place. Just allow me to reorder the list by dragging and dropping each value.
If that works too, you can just ignore the buttons.
The problem with *only* having D&D sorting is that it's impossible to discover, there's no hint in the UI.
I'd kill every button except "Add" and "Close." They can all be done easier in other ways.
I hate the way the button icons don't line up. When I'm looking for queues on what a button will do, I can find them faster is they're all in the same place.
What other ways? Context menus and drag&drop?
I think you can alleviate the dead space issue by splitting the buttons in two groups: one containing add, remove, edit and the other containing up/down. Separate up/down and move the down a bit. If you want, try inventing some labels to describe these two groups.
Alternatively you could try to layout the buttons horizontally and perhaps get rid of up/down as hinted above. Of course this means the functionality is hidden now. :) Perhaps it's better to replace up/down with sort (ie. click radio name selector header)? The function as it is now is a bit unclear.
Well, this is only half the app :-)
The main UI element is just a popup menu with a list of radios. This "edits" the menu. So, maybe sorting is just useless.
I would have given icon for each operation instead of giving names+icons and a tool tip for usage. this'll make ui much smaller and handier.
Also instead of bigger text area a drop down will do coz anyways for adding/editing you have to take user to another ui, there listing can be done.
Adding/editing is the whole point of this dialog, if I take that to another UI to use a drop down here, what would the user actually be able to do in this window?
I'll keep my remarks on the dialog design as it is, not supposing a complete or parial redesign.
- The icons for Add and Edit are not meaingful
- Icons and Text of the buttons are not aligned
- There is "Close" with a checkmark icon, but apparently no way to cancel your changes
- A hint on what you can and should do in this dialog and how it affects the rest of the program could be written above the controls, in the manner of "You can add, remove and edit radios that you can play on the "Radios" tab in the main window"
- The window title should read something like "Edit radios" or something like that
- The window is resizable! That's a plus
AFAIK HCI studies show that hints of the kind you're suggesting don't help the user; instead they hinder.
Without burn my neurons, I would design this dialog in this way:
[URL=http://img202.imageshack.us...][IMG]http://img202.imageshack.us...[/IMG][/URL]
Direct link:
http://img202.imageshack.us...
Without burn my neurons, I would to design this dialog in this way:
Direct link:
http://img202.imageshack.us...
Nice! What would the find buttons do, search in the list?
Oh, that's trivial. That function maybe can be accomplish by the control list or by a routine that should be triggered when the user write in the Name box or Address box, so these buttons could be eliminated.
Also, I put the button Remove below the control list, in vertical simetry with the buttons Edit & Add to show how the simetry helps to understand the relationship among them.
I put the boxes Name & Address to show that other dialog is unnecesary.
I didn't put the icons of the buttons Edit & Add accidentally, I thought them would help to understand what will happen with the data when the user click on them.
So, I don't think than this is the best dialog, just is a posibility. But, all depends on the kind of users.
I would remove the 'Close' button completely (there is one button to close the dialog already). Then I would move the Add, Edit and Remove buttons below the list, have Add button be a + and remove be a - and edit be a page with pencil writing on it, add '...' to Add and Edit (as they produce other dialogs), make the Up and Down buttons icons only and make them stretch so that the two of them have the same height in sum as the list, also support drag&drop reordering in the list, center the buttons under the list with a bit of spacing around them,
There is not necessarily a "Close" button other than the one in the dialog. Most netbook-specific interfaces on Linux would show this maximized and without title bar.
If this were used in a mobile device, there is no close button either.
I've only skimmed the comments here, so sorry if some of this is repetitive. I posted a response article to describe how I would design this dialog if it were up to me. Enjoy:
http://thesmithfam.org/blog...
Thanks for the feedback!
- Remove, Edit, Up, and Down should be attached to the item
- Add should be under it on the left
- Close should be resized
- Icons should be aligned and should look more obvious (arrows instead of triangles, please)
- The list should allow drag and drop reordering if it does not
Up and Down should not be attached to each item. I've used interfaces like that, and it's very frustrating to try to move one item across the list, because you have to chase after the button as it moves along.
Google Profiles has an interface like this to list one's websites. Once I wanted to move a item from the bottom to the top, so I unconsciously clicked several times to the item's Up button and then saved. When I noticed it was not where I wanted it to be, it took me a while to realize that I had to chase after the button to do it.