This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I'm terrible at making intuitive user interfaces. I could really use some opinions here:
- There is an order table which lists all recent orders
- Each order has an action column listing available actions for that order ... for example: modify, cancel, print, renew, etc.
- Any order can be printed, but other actions vary. Many orders are already fulfilled, and so can't be canceled or modified.
- There's a column of check boxes in the table. If a user wants to cancel a whole group of orders, he/she can check each order and press the Cancel button under the table.
We're trying to decide if the Cancel and other buttons should be enabled or disabled before orders are checked. The options that I can think of are:
1. Leave the buttons always enabled. If there are no orders to cancel when the Cancel button is pressed, inform the user of this.
2. Enable a button only if at least one of the checked orders can have that action performed on it.
3. Enable a button only if every checked order can have that action performed on it.
Honestly, none of those options seems particularly good to me. What should I do?
Personally it annoys me when I click on a button and I get a dialog box which says "Sorry, that button doesn't actually do anything right now".
So if it were me I would only enable components which are going to do something. So I wouldn't enable a check-box unless the order it belonged to could be cancelled, and I wouldn't enable the Cancel button unless at least one check-box was checked. Although if the check-boxes are for a variety of options, then disabling them wouldn't be right. In that case I wouldn't enable the Cancel button unless all of the checked orders could be cancelled.
However that's just my preference. It's very common for buttons to be enabled all the time, but I don't know whether that's because it was more convenient for the programmers or whether Jakob Nielsen said it was a good thing to do.
I am with Paul on this one.
Allowing the user to access some control and then telling him go back and to x and then come back and try again is laziness on the programmers part. Disabled controls are much more clear cut and intuitive.
OK, so you're both against option 1, which is too bad because it would be the easiest.
Paul seems to prefer option 2 to option 3, but Maneesh doesn't say which he prefers. With option 2, we could have this scenario:
No buttons are enabled, no orders are checked
-> User checks one order
Print, Cancel, and Modify buttons become enabled.
-> User checks a second order
Cancel and Modify buttons become disabled
-> User unchecks second order
Cancel and Modify buttons become enabled again
That means the act of checking orders sometimes enables buttons and other times disables buttons and follows a logic that the users might not understand. That makes me squirm a bit, but it might be the best of bad options.
If the 'cancel' button popup was an error message that no orders had been selected, that seems normal to me.
I've seen numerous registration-type forms where 'submit' throws up a message/popup that xxx field needs to be completed,
which, to me, is better than wading through the form again to find out why the submit button is disabled.
on the other hand, if the cancel button relies on certain criteria (even if selections are made) - I'd agree option1 is not the best