Mockups in your hand
It’s surreal, but effective, to print out mockups and play around with them.
These were used in the authconfig-gtk revamp. I used these to figure out if the sequence of policy kit dialogs would make sense. I walked around the office and bugged a couple folks, explaining the scenario (“You just filled out this UI, and you’d like to apply the changes.”) and pulling out the appropriate dialog and explaining the actions. A dialog pops up asking for your password (via PolicyKit) and I was worried about how that dialog would fit with authconfig’s screen flow.
I had thought the error case where you don’t type the right password was going to be confusing, but it turns out the success case where the changes do check out and your password is correct resulted in some awkward UI flow – you hit apply, the dialog pops up, you authenticate and it works, now you close the success dialog – what happens to the base window? Flat mockups on a wiki don’t typically generate this kind of analysis, so it was a really helpful process to go through, printing them out and cutting them up and giving ‘demos’. 🙂
The mockups and flow were tweaked to address the issue. Let me back up and give you a run-down on what’s happening here, and why I ended up playing with scissors and mockup print-outs:
First off, there’s two different ways you might fill out authconfig incorrectly, with some pretty severe consequences:
- If the system is unable to contact the account database over the network, processes on the system will no longer be able to map usernames to UIDs for network accounts. (Local accounts will be okay.) This means all sorts of processes on the system will fail in weird and unpredictable ways because access control checks will no longer work.
- If the system is unable to authenticate the user because those settings are filled out incorrectly, anyone using that authentication mechanism will be unable to log into the system, change their password, or unlock their screen. If you’re using authconfig-gtk via sudo, then screw up the authentication settings such that you can no longer authenticate, you may lose your sudo privileges and not be able to actually open up the dialog to go back and fix it!
As an interaction designer and user advocate, knowing that any user could easily make an honest mistake and pay quite dearly really depressed me. Complicated settings? Dire consequences? To me, this situation screamed for some kind of automatic error-checking and a full and easy test run on the changes before committing them.
“Wait, wait, wait. Dire? Pay dearly?” you ask. “These are no biggie, because you can simply log out then log back into GNOME as root and go to authconfig-gtk and fix ‘er up, right? Right?” Actually, um, no. In Fedora 13 you can’t log into GNOME as root (kindly note this design constraint is not up for discussion here), so you have to create a local user on the system with sudo privileges and log in as that user in order to fix the problem in the authconfig-gtk UI. Do-able, yes, but quite a pain. So yes, it’s better to spare the users this kind of pain by checking their work before they make a mistake, right?
That’s a pretty tall order, though. There’s quite a few complications to testing the user input before committing it. You’ve got multiple legacy backends, a new hot backend, and network services that can take a while to interact with. For example, one of the legacy backends that drives some of the technology in the UI is ncsd. So you may test a username and password, but if the technologies the user’s choices result in activating use ncsd as a backend, the correct settings may be cached. If the correct settings are cached, ncsd will return a false positive for your new settings, never actually trying the new ones. This is a bad situation, because now the UI would tell the user it checked everything out and it was okay, and then the user would get locked out soon afterwards despite the thumbs up from the UI check. ‘Well then,’ you ask, ‘why not just clear the cache before you check the new settings?’ Nice try, smartypants, but if the new settings are wrong and you clear the cache, you may then lose your root/sudo privileges to be able to run the authconfig-gtk dialog in the first place! Whoopsie. The revert button would then also no longer work, as the previous settings wouldn’t be there to revert to.
Yes, this is indeed a case of legacy technology being broken and pulling the new awesome technology (sssd) down to its level. The theme for Fedora 13’s iteration of authconfig-gtk, if anything, is uniting legacy and new backend technologies, hiding the the thorniness and inconsistencies, and presenting a UI that displays choices to the user based on the authentication and account storage technologies they are running on their network and are familiar with (LDAP, NIS, Active Directory / Winbind, etc.) rather than having to understand our backend technologies for handling those protocols (pam, ncsd, sssd, etc.)
With all these complications for testing user input, and little time to develop a solution and implement it in time for Fedora 13… we decided to shelve the PolicyKit testing flow for authconfig we came up with for the next release. Total bummer, yes. Not totally depressing, though, when you consider that even though we’re not checking the user input, we’re not actually regressing and are actually far surpassing the functionality and quality of the current authconfig-gtk dialog, which not only lets you drive right off the edge of the cliff but actually lights the way with neon arrows! (It lets you select combinations of technology that will not actually ever work together and guaranteed will lock you out of you rmachine.)
And the design we ended up going with for next release, based on the paper prototype testing? When you close the success dialog, the base window closes at the same time. It’s not the most ideal solution. Ideally, I think the settings should be tested both on a field-by-field basis when possible and on a whole-dialog basis when the user submits the form. However, because of the networked nature and varying speeds involved in the different technologies here, it may take over 10 seconds to fully test the settings. You also do need the user to provide their login credentials so you have some credentials that are on the server to test to make sure authentication works. Thus, we came up with the idea of the PolicyKit dialog and closing both the dialog and base window at the same time. (If you have a better solution to this UI dilemma – the awkwardness of closing two windows at once – I would love to hear it!)
Since this part of the UI was just a design and not implemented yet, the paper cutouts were the quickest and easiest way to test out the interaction. That being said, paper mockups like these obviously require you to be co-located with your ‘testers,’ meaning they can’t be used easily in a distributed manner, a pretty major weakness. Does anybody have an idea for an easy (FLOSS please) way to achieve the same effect posting mockups online?
Anyway, I’ve been using ‘we’ a lot in this blog post. Who’s ‘we’? Well, Zack Cerza and Ray Strode tested out my paper prototypes, and Matthias Clasen and Ray Strode both provided a lot of guidance and advice on the mockups. Also, special greets to the brilliant Stephen Gallagher who totally gets authentication and security technologies, and who patiently makes them easy for clueless n00bs like me to understand! And of course Tomaz Mraz who developed the new UI with amazing speed, accurately reflecting the design in the mockups.
Authconfig test day tomorrow!
On the topic of authconfig, actually, James Laska announced a test day for SSSD by default tomorrow, in #fedora-test-day on freenode. The major driver for the authconfig-gtk redesign was because of the new SSSD backend for it that will be in Fedora 13. So pop into #fedora-test-day and try out the authconfig-gtk UI revamp and let us know what issues you find. I’ll be there (my nick is mizmo) to help work through any usability or design issues – please tell me if I got it wrong!
- Date/Time: Tuesday 30 March 2010 / All Day
- Location: #fedora-test-day
- Wiki Page / Additional Information: https://fedoraproject.org/wiki/Test_Day:2010-03-30_SSSDByDefault
What about simply using html link, the "mockup you are the hero" :
"if you click on this button, just go to this page"
"if you click on the cancel button, just go to this page"
You can describe the workflow, but the problem is that quite manual to do.
Of course, you can also use flash, or js, or openoffice impress to achieve the same level of functionnality.
Ouch, those dialog buttons are all wrong, according to the HIG. If it's not instant apply, it really should be Help——-Revert-Apply-Close.
It can't be instant apply, since we're talking network servers here, and some form fields have to be completed together before apply would even have a chance of working.
Missing a 'Help' button I think is hardly 'all wrong' though, right? 🙂 Just one button. There's no help file to go with it, so why have an empty help button?
It can’t be instant apply, since we’re talking network servers here, and some form fields have to be completed together before apply would even have a chance of working.
Missing a ‘Help’ button I think is hardly ‘all wrong’ though, right? 🙂 Just one button. There’s no help file to go with it, so why have an empty help button?
For the devel version, it could have a help button which invites people to contribute some documentation. I did that for PackageKit and GNOME PackageKit that way.
https://fedoraproject.org/wiki/Design/SSSD#Testin…
I noticed one problem with the mock-ups for the authentication verification. In your mock-ups, you only prompt for a password. However, there's no way for authconfig to know your username, because authconfig is always run as root (directly, or via sudo). So those verification dialogs need to specify a username to test against, and the help text should inform them that it should be a valid user and password for the configuration they believe they've set up correctly.
Even if we COULD detect the original username with any degree of accuracy, there would be no guarantees that it was a user from the network anyway (and probably wouldn't be, since you'd presumably not be running authconfig if your network auth was already functional)
Hi Stephen,
I had thought about that, but I thought if we used PolicyKit, then authconfig-gtk wouldn't be run as root, it would run as the user, and only the part that needed root permissions (write out the file) would use the root authentication. So it would know your username, in that case, by who is running the dialog.
I think we had talked about your last point – I vaguely remember you telling me (and I'm sorry if I remember this wrong) that when people have an account on the network vs locally, it's common for them to have the same username.
If that doesn't work – either PolicyKit doesn't work that way and/or the user having the same username locally / remotely and having too narrow a chance of that local username being networked as well – do you think the username field in the PolicyKit auth dialog should be fill-in-the-blank? Or do you think there's a way the server itself could suggest possible valid usernames?
"I think we had talked about your last point – I vaguely remember you telling me (and I’m sorry if I remember this wrong) that when people have an account on the network vs locally, it’s common for them to have the same username."
This is only sort of true. Right now, it's common because the SSSD isn't widely-used. People with laptops NEED to keep a local account, and for compatibility reasons, it will generally be the same username and uid as their network account, but this is not a requirement. (And Joe Average is just as likely to pick their instant messenger name for their local user).
So, even if we come in through PolicyKit, we have zero guarantees that this user also happens to exist on the remote server.
By default (and it's not configurable directly in authconfig) we do not allow full enumeration of all user entries in the SSSD, This is both for performance reasons (if you have many users, looking them all up can take a long time) and information control. (If an attacker doesn't have a list of your users, they can't use a dictionary attack across all of them until they find a weak link). So presenting a list of possible users to try is not available.
I don't think it's beyond the level of the user of this UI to require them to know a valid network username and password in order to verify it; good help-text would go a long way here as well.
If you're having issues with two windows being closed simultaneously, then it sounds to me like they should be one window. Just my two eurocents.
Hey, I'm not sure that will work though because PolicyKit pops up another window…
[…] necessary, we’ll also print out the mockups and do additional user testing on them (likely using a paper cutout method), noting identified […]