On 5/29/12 3:23 PM, Werner Koch wrote:
> However, changing such a common UI might result in a
> lot of negative comments - people love what they once learned.
Absolutely. The good news, though, is that (at least in the Free
Software world) the 'market' is fragmented. No one particular key
manager holds a dominant position. Off the top of my head there's
Seahorse, Kgpg, GPA, the Enigmail key manager, and more. It's possible
for a new entry to exist without offending the users who are already
happy with the existing/dominant certificate management UI. They just
won't use the new thing, that's all -- but new users may decide to use
the better-designed interface.
> Yes, I am interested in your findings.
The code we put together was a fairly straightforward UI mockup. One
version was in Java (in a vain, misguided attempt at cross-platform
support); after that I put together one in Python that directly targeted
GNOME 2. It would need some work to overhaul it for GNOME 3 (and
possibly a lot of work, given PyGTK has been deprecated in favor of a
different kind of binding). That said, if you'll forgive me not having
a mockup ready --
1. The window was almost comically blank:
._________________________________________.
| Search for: | |
+-----------------------------------------+
| (room for a line of text, begins blank) |
+-----------------------------------------+
| (checkbox for 'Show all matches') |
+-----------------------------------------+
| |
| |
| (completely blank |
| tabular widget) |
| |
+-----------------------------------------+
In usability tests, people who already had experience with conventional
key managers absolutely hated this arrangement. They wanted to see all
the information at once. People who were new to OpenPGP were a little
confused: they weren't accustomed to windows that were mostly blank, but
they had no difficulty understanding that they needed to interact with
the search box first. An early version of this allowed users to view
all 1000+ certificates on the keyring by clicking the 'Show all matches'
checkbox immediately. This turned out to be a negative experience for
some users, who immediately felt overwhelmed by data. For this reason,
the checkbox was originally set as insensitive: only once data was
entered in the search box and the number of matches ranged between 1 and
50 did the checkbox become active.
2. As users typed things into the searchbox, the line of text would
update. For instance, if the user typed 'T' the text would say
something like, "55 certificates contain 'T'". At this point the user
could click on the checkbox if he/she wished. People seemed to
understand that they should keep typing, though. Once enough letters
were entered to reduce the matches to under seven certs, the checkbox
selected itself and the matching UIDs populated in the widget. And, of
course, as soon as the matches went <50 the user could manually select
the checkbox.
3. Typing 'RSA', 'DSA' and/or 'ELG' would further restrict keys.
Nobody cared about this feature: it was completely unused. Likewise
with ">=xxxx" and/or "<=xxxx" to restrict by key length. Nobody cared.
In hindsight, this was a horrible misfeature -- what if someone's name
contained 'rsa', 'dsa' or 'elg'? For instance, one of my classmates'
email addresses was @thetiredsaint.com; had we used his certificate as
one of our tests, I suspect people would have been driven up the wall by
this misfeature (note the "dsa" in "thetiredsaint").
4. Searching by a hex string was supported, so long as it was prefixed
with 0x.
5. Multiple search terms were treated as logical-ANDs, not logical-ORs.
People didn't want/use ORs: nobody wanted "UIDs matching 'John' or
'Smith'", they wanted "UIDs matching 'John' and 'Smith'" -- e.g., Bob
Smith would match the first but not the second.
6. Once the tabular widget was displaying UIDs, clicking on a row in
the UID would populate its key ID field. This further reduced the
cognitive load on people: rather than see 10 UIDs and 10 key IDs (a
widget count of 20 spread across two columns), there was a single column
of 10 UIDs and, *if a row was selected*, a single key ID shown -- a
widget count of 11. Some people liked this, some people absolutely
hated it. The ones who hated it tended to be the more experienced
computer users.
7. Upon clicking a UID, not only would the key ID field populate, but
the line of text would instruct the user "Double-click to view or edit
this certificate." Upon double-clicking, congratulations, the mock-up
ended -- the mock-up was only meant to test the ease of finding and
selecting the desired certificate.
Our testing was pretty rough. We had seven test subjects (a very small
sample), one of whom was very tech-savvy and the others were a fairly
normal cross-section of the undergraduates who were shambling around
through the building that day on their way to a university-required math
class. The surveys showed that they all considered themselves to be
competent with computer interfaces, but only the one considered himself
expert. They were tested on both GPA 0.3 (the latest version available
at the time) and this mock-up. From a keyring containing 1000+
certificates, we asked them to find some certificates by email address,
some by name, some by "a name like, but spelled a little differently"
(e.g., "like Bob Johnson, but the spelling of the last name may be
wrong"), and by key ID.
The results were a mixed bag but on balance positive. The very
tech-savvy subject immediately recognized the column headers in GPA
controlled per-column sorting, and used this to find desired
certificates in approximately the same time as our mock-up. The others
generally found the mock-up interface to be much faster than GPA's
interface. One subject could not complete the tasks at all with GPA; he
didn't see GPA's search box (telling us later that it was just one more
widget in a screen full of them), did not know the headers were
clickable, and so forth. After spending six minutes trying to find just
one certificate, this subject gave up on GPA.
The subject who gave up on GPA began his session by maximizing GPA to
fill the screen. He was the only subject to do so. He said he thought
it would be faster if he could look over more entries at a time, but it
appears that all that additional data was more of a cognitive burden
than a blessing.
After these trials with complete newcomers to OpenPGP, I of course
showed the user interface to some veteran OpenPGP users. A few had some
mild praise for it, but the overwhelming response was a giant "yech" and
a "I hate this interface, it feels so dumbed-down."
So, I guess you could say that we came up with an improved user
interface for newcomers, but hardly anyone who's invested time in
learning the big-tabular-widget style of manager is going to find it an
improvement. Proof positive that you can't win 'em all, I guess. :)
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
