[MAGNOLIA-292] unconventional UI when selecting paragraph type in dialog Created: 11/Feb/05 Updated: 27/Nov/13 Resolved: 29/Nov/12 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | admininterface |
| Affects Version/s: | 2.0 Final |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Chris Stephens | Assignee: | Andreas Weder |
| Resolution: | Outdated | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
all |
||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Date of First Response: |
| Description |
|
When you click the 'new' button to create a new paragrpah on a page - and if that paragraph is able to be of more than one paragraph type - the admin user is presented with radio buttons with which to select the paragraph type they want to enter into the page. On selecting a radio button the screen immediately redraws to show the input fields for that paragraph type. This is unconventional UI behaviour: conventionally a selection is made from a set of radio buttons and then a button is clicked to submit that selection. I have observed users (especially on slower responding servers) selecting a radio button and then heading for the OK button in the bottom right hand corner of the window. I have also observed people selecting the wrong radio button and then trying to correct their selection - as they should be able to do - but it's too late: the page is already redrawing... I suggest that an 'Ok' button is added to this dialog and the JavaScript removed from the radio buttons. |
| Comments |
| Comment by Boris Kraft [ 11/Feb/05 ] |
|
On the contrary, this behaviour should be added wherever possible. Each click that we can avoid is a step in the right direction. There is no need whatsoever to have an addition step in the scenario you describe, and once a user has seen how it works he will be happy to save mouse movements and clicks. If you accidentally click on the wrong paragraph type, you can always delete the paragraph and create a new one, so the behaviour is reversible. If you do what you always did you will get what you always got. |
| Comment by Ortwin Glueck [ 11/Feb/05 ] |
|
Boris, I don't quite agree. Usability has a lot to do with reusing patterns you have already learned. In this case the GUI looks familiar to ones that you already know from Windows dialogs. But instead of behaving the same way, it behaves a little different. This is very confusing for the avarage user. In this case it is especially bad because there actually are OK/Cancel buttons but they are of no use.ยจ I understand that you would like to save the user some clicks, which is also good from a usability point of view. However care must be taken to not abuse widgets here. The GUI can be changed a little to achieve better usability in different ways: a) Convert the list of radio buttons to a drop-down menu. Get rid of OK/Cancel buttons. Selections like this are found all over the web and thus are well-known to users. b) Replace radio buttons by real buttons labelled "select" or so. Get rid of OK/Cancel buttons. Users expect something to happen when they click a button. |
| Comment by Fabrizio Giustina [ 11/Feb/05 ] |
|
I think that the problem here is that we are presenting the user a set of radio button and the user expecs they work as radio buttons... One of the basic principle of usability is avoid changing the meaning or beavior of standard form widgets (eg. auto-submitting forms, <select> lists used for navigation, etc.) So for me this is absolutely a valid point, maybe we can simply find a better solution: if we don't want to add a submit button in order to reduce the number of steps, we can simply replace the radio with something different. Since now radio are actually working as buttons, why not to replace them with buttons (or images... just need to find something more clear than radio fields)? |
| Comment by Michael Aemisegger [ 11/Feb/05 ] |
|
Because everybody feels like an expert on usability issues, I add my opinion here. Boris, I also disagree with you. I totally agree with Ortwin and support his and Fabrizio's suggestion. User interfaces shouldn't be reinvented just because you (I mean anybody) think you have found a better way. Learning and pattern reuse are a big issue in research and expected user interface behaviour should be changed with care. |
| Comment by Boris Kraft [ 11/Feb/05 ] |
|
You are absolutely right, the problem is the radio button. Maybe we should use links instead. Dropdowns I dont like because they need again an additional click, which makes it slower to use. |
| Comment by Andreas Weder [ 11/Feb/05 ] |
|
IMHO, the radio button is not a big problem here. It does work nice in this context, if you require the user to click on OK. The drop down menu doesn't work, because the additional explanation what the paragraph is all about (and which was well received), doesn't fit anywhere. I'd stay with radio buttons, but I'd do nothing to avoid an additional click. If you want to avoid the click, the link is an alternative, yes. But I'm thinking of our users, which I consider typical for employees filling in a company web. These people know word, and they sometimes seemed to feel a little bit insecure as to what to do when. By first selecting, the confirming the selection, these users have time to verify their selection at least. |
| Comment by Boris Kraft [ 12/Feb/05 ] |
|
I don't see the value in first selecting, then clicking OK. Thats like Jeff Bezos with his one click ordering - he had a very hard time to get this through, because everyone screamed "no, our poor users, they need to click at least 3 times or else!" Now waht? One click has become a huge success. As I said before, my goal is to have the least posssible clicks necessary for anything. I'd even suggest to allow the use of a dropdown directly on the new bar, which would result in even faster access - albeit be loosing the "description" and optional image that the dialog panel displays. But for a power user, this would be a nice options. Back to the issue at hand: I want a single click solution, and I mean it. Now lets focus on how we can achieve that without confusing our oh-so-poor, overworked and overwhelmed users, that simply can't deal with an easy to use interface. Not that I like the idea, but how about keeping the radio buttons, not autosubmitting upon click, keeping, the OK button, so your poor users get what they always got. Now, in addition, we need to accommodate for power users. There aree a couple of ideas:
My favourite is to simply provide a list of links, no radio buttons, no ok, no cancel. Users know that clicking on a link will result in an action. And as stated before, it is trivial to delete a paragraph if you accidentally made a wrong decision. So noone gets unexpected behaviour, and its the most effective solution. The radio buttons would IMHO only make sense if thee form allows additional selections before submitting, which it does not. |
| Comment by Chris Stephens [ 12/Feb/05 ] |
|
I agree with Boris' last statement: I think the concept of the list of links (or buttons) that select the desired paragraph is correct. This is actually what we have now but the mechanism being offered is the radio button (incorrect in this context as we have discussed). The implicit question being asked is 'which type of paragraph do you want to work with?'. The user can most intuitively answer that question by making one single click on the desired paragraph type. Can we do exactly that? Can we have a question presented - with a list of links below as possible answers? Links are better than buttons for this because then the person clicks directly on their desired choice. A button implies a submission of some other information (such as form fields). I know one-click (and other things like it) are buttons but this is partly to make the whole function of one-click stand out visually and also it's a consistent action. Amazon is actually very good at buttons. E.g. the 'use this address' button - but in that context you couldn't really make the whole address a link and the address isn't the action: it needs an explanatory button label. To be purist I would say we should also de-activate the OK button when this choice is presented since it serves no purpose. Cancel is all right, though. |
| Comment by Philipp Bracher [ 17/May/06 ] |
|
will do it |
| Comment by Magnolia International [ 12/Apr/11 ] |
|
Andreas, I'm assuming the above as long been digested into the new ui concepts going into 5.0; feel free to edit/schedule/close as appropriate. |
| Comment by Andreas Weder [ 29/Nov/12 ] |
|
I'm closing this as we won't fix it for the 4.x family, but there will be a fix for this in 5.0, which features a new UI and deals with such issues clearly. |