On 10/6/2010 11:21 PM, drpartha wrote:
> Why cant interface designers make things a little less enigmatic :{
During grad school I did a few semesters of human-computer interface
(HCI) design, particularly with respect to OpenPGP user interfaces.
It's a fascinating subject but ultimately left me very, very cynical.
Here's why.
[sets the rant switch to ENGAGED]
The reason why user interfaces suck: crypto is hard, making good user
interfaces is hard, the OpenPGP spec is human-unfriendly, and there is
an enormous resistance in the community to newer and better interfaces.
Consider signatures on a user ID. A signature issued by someone you
don't trust is utterly meaningless. It's noise. There are a couple of
possible use cases (e.g., trying to find ways to connect two disjoint
webs of trust, or mapping out a target's social network), but those are
pretty niche when compared to average users and their needs.
So, already, one way to make interfaces simpler: omit all untrusted
signatures. If a signature doesn't contribute to the overall trust
calculation on a key, don't display it -- reduce the cognitive spam.
Another culprit: we've now got about 15 years of experience with a
really awful user interface that should have never been fielded.
Unfortunately, that interface has now become standard, and any attempt
to change it will get pushback from users.
Table-oriented data is principally useful in two conditions:
non-interactive interfaces and contextual views.
In non-interactive interfaces (like printed almanacs), all the data has
to be visible all the time. If I want to look up the population of
Zimbabwe, well, the almanac can't interactively ask me the country I'm
looking for. It has no option but to present all countries, and give me
a user interface that makes it possible to find what I'm looking for.
In contextual views (like Excel spreadsheets), the data in one area is
contextualized with information from another area. When looking at a
business's profit-and-loss statement, it's useful to be able to
immediately see how much each business unit contributed to the bottom
line. Or, in your email client, it's useful to be able to see your
emails in chronological order: the sequence in which they arrived is
contextual information relevant to each email.
So... consider the traditional OpenPGP certificate management interface.
It presents all these certificates in an enormously complex tabular
format. Click on a certificate and it reveals user IDs and subkeys.
Click on a user ID or a subkey and it reveals signatures. Etc., etc., etc.
This interface is user-hostile. There are two compelling reasons to use
tabular data -- noninteractive interfaces and contextual data -- and
neither of them applies to OpenPGP certificates. The key manager is an
interactive interface, and if I'm looking at certificate 0xDEADBEEF I
really don't give half a damn about 0xDECAFBAD, 0xBADD00D5, or
0xBADF00D5... so why am I getting cognitively spammed with information
about them?
Unfortunately, PGP 5.0 presented all certificates to the user in this
tabular format -- and ever since, that's what users have demanded. It's
what they know, it's what they want, and if you seriously suggest
getting rid of a table view people will refuse to use your interface.
At the end of the HCI course I had a prototype key manager that avoided
the table widget and ruthlessly suppressed useless data. It consisted
of pretty much just a search box into which you could type an email
address, a certificate ID, a user name, a comment, whatever. Once you'd
narrowed your certificates under a dozen, a list would pop up showing a
certificate ID, the best-matching user ID on the certificate, and its
trust level. Double-click on an element in the list and bang, a
certificate editor appeared, with helpful wizards to walk you through
the process of validating a key, uploading it to a key server, etc., etc.
Ultimately it was just a prototype: it was never a fully functional
certificate manager. Two things convinced me to let this project die
and not pursue it further. One was there was a strange problem
involving GnuPG refusing to communicate via a pipe with Java. The
problem strongly appeared to be in GnuPG. Ultimately, that's a minor
problem.
The real downer came when I showed long-time GnuPG users this interface.
Opinions ran about five to one, "hey, this is a really sweet interface,
and I like it -- but it'd be even better if there was a big table widget
with all my certificates there. I'd use that instead. I'm familiar
with that user interface!"
... I should point out, BTW, that although being told "don't make a
better interface, make it just like the interfaces we know" is a downer,
I'm not faulting people one bit for it. People have invested a lot of
time and effort in learning these bad, broken, user-hostile interfaces.
It is *absolutely* reasonable for them to want to use an interface they
know, rather than learn yet another interface -- even if I'm immodest
enough to claim these new interfaces would be vastly better. :)
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
