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