User Interface: figuring it out
In reviewing part of the interface for the design of a testing program, the client designed a function for the system-administrator that looked like this:
The left hand link opens a window that displays the test, while the right hand link assigns (or unassigns) the test to all of the users. Clicking “Assign” releases the test to all users, and changes the state of the item to “Unassign”
First things first, a link that opens another window seems fine, but having a link that actually changes the state of data in the system seems counter-intuitive. Especially when these items are side by side.
When you get into the actual functionality of this item, things gets even hairier.
What does that thing do?
Remember that this is a system-admin function that assigns tests to other users. Now the system-admin can go in and individually choose to assign these tests to the other users (through another screen), but this function is supposed to assign the test to everyone. And once you’ve assigned the test to everyone, it can then be used to unassign the test as well.
This immediately provoked questions like:
The answer to 2 is most important, because it became apparent that the data shouldn’t be lost (just the users access temporarily disabled.)
First redesign
My first thought was to change the test so that there was an Auto Assign mode, and if it was on, then users could access the test, and if it was off, they couldn’t.
That certainly looked prettier than the first design, and a little more obvious what was going on too. But, it turned out to not really offer the functionality that was wanted any more than the first design.
Second redesign
The second redesign seems to get closer to the desired functionality. It splits the function into two options; one that turns the testing mode on and off (i.e. you don’t unassign things, you disable the testing) and an Assign All button.
Note that the Assign All button does not change to an Unassign All button; it remains an Assign All button after you use it.
This design solves all but one problem: what if you actually want to disable the test rather than just turn it off? We could add a third button “Unassign” – and for the sake of completeness, maybe we should – but it comes down to: how are system admins going to use the system? In most cases, they aren’t going to want to unassign everyone. But they may want to turn off the testing temporarily, and they could want to assign everything to all the users. Leaving the unassignment function a manual process (i.e. you use the separate function for individually assigning and unassigning tests) simplifies the UI, but shouldn’t actually cause most users any more work.
The left hand link opens a window that displays the test, while the right hand link assigns (or unassigns) the test to all of the users. Clicking “Assign” releases the test to all users, and changes the state of the item to “Unassign”
First things first, a link that opens another window seems fine, but having a link that actually changes the state of data in the system seems counter-intuitive. Especially when these items are side by side.
When you get into the actual functionality of this item, things gets even hairier.
What does that thing do?
Remember that this is a system-admin function that assigns tests to other users. Now the system-admin can go in and individually choose to assign these tests to the other users (through another screen), but this function is supposed to assign the test to everyone. And once you’ve assigned the test to everyone, it can then be used to unassign the test as well.
This immediately provoked questions like:
1. What happens if you assign the test individually to several users, and want to unassign everyone that’s so far been assigned the test? Do you click once to assign it, and then click again to unassign it?
2. If a student is half way through a test and you unassign it, is data lost?
3. What if you assign the test to all users (the item changes to unassign) and then several more users are added? Can you use the function to assign the test to those users?
The answer to 2 is most important, because it became apparent that the data shouldn’t be lost (just the users access temporarily disabled.)
First redesign
My first thought was to change the test so that there was an Auto Assign mode, and if it was on, then users could access the test, and if it was off, they couldn’t.
That certainly looked prettier than the first design, and a little more obvious what was going on too. But, it turned out to not really offer the functionality that was wanted any more than the first design.
Second redesign
The second redesign seems to get closer to the desired functionality. It splits the function into two options; one that turns the testing mode on and off (i.e. you don’t unassign things, you disable the testing) and an Assign All button.
Note that the Assign All button does not change to an Unassign All button; it remains an Assign All button after you use it.
This design solves all but one problem: what if you actually want to disable the test rather than just turn it off? We could add a third button “Unassign” – and for the sake of completeness, maybe we should – but it comes down to: how are system admins going to use the system? In most cases, they aren’t going to want to unassign everyone. But they may want to turn off the testing temporarily, and they could want to assign everything to all the users. Leaving the unassignment function a manual process (i.e. you use the separate function for individually assigning and unassigning tests) simplifies the UI, but shouldn’t actually cause most users any more work.
0 Comments:
Post a Comment
<< Home