UX and defaults; was Re: Why 2.1 is delayed for so long

[Ximin Luo]

On 22/09/14 15:17, Robert J. Hansen wrote:
>> I agree with these principles, but I think you are not applying them 
>> in the right way. The fact that the user is doing gpg --gen-key 
>> already means the choice is relevant...
> 
> Emphatically not!
> 
> I can count on one hand with fingers leftover the number of times I've
> cared over the last 15 years of using GnuPG whether the key I'm
> generating used RSA or DSA/Elg.  (Three fingers leftover; twice I had a
> specific need for RSA, for compatibility with stuff further down the
> toolchain that's outside of GnuPG's control.)  The rest of the time the
> choice was completely irrelevant
> 
> Some users enjoy tweaking with the knobs and dials.  There's nothing
> wrong with that, and I think GnuPG should support that.  But I also
> think that irrelevant knobs and dials should be hidden from the user.
> Algorithm choice and key size are two such things.  Pick sane defaults,
> make it easy to override them with --expert, and don't reveal them to
> the casual user.
> 

An optionless way to generate keys makes sense. I mostly take issue with your other suggestion, that a more precisely-worded options list is inappropriate, *given* that an options list is appropriate for the usage (in whatever --expert mode you care to put the options list in).

As for the defaults issue, I agree that this is a UX issue, but I disagree with your narrative that it is to do with cutting down "irrelevant" options. I extremely dislike UX design approaches that assert 99% of people have a particular use-case, implying that everything else is "irrelevant", then using this to justify sacrificing features that are useful to the 1% of people who actually know what is happening. (You don't suggest the latter, thankfully, but I have seen plenty of other non-general-purpose UX acolytes use the narrative you mention, to justify doing so.)

It is not a matter of "irrelevant" options. Instead, I think it is more to do with being able to *perform your preferences quicker*.

It just so happens you're personally happy with the existing GPG defaults, so you don't want to bother with the options list. I don't like the GPG defaults (which is why I wrote the script I mentioned in a previous email), but actually I don't want to bother with the options list either, I just want GPG to generate my preferred key in one simple command. 

One way to accomplish this is to improve "batch mode". Then, I can store my preferred key settings in a config file, like ~/.gnupg/genkey.conf, and --gen-key would use those settings automatically. GPG could place a default file for the user to edit.

>> There are lots of other point-and-click interfaces for GPG for users
>> that "don't care".
> 
> There are also a lot of people who look at GnuPG's FAQ for advice on how
> to begin using GnuPG.  Those instructions currently amount to "--gen-key
> and trust the defaults."
> 
>> * Never present to the user a false model of what actually happens.
> 
> How is hiding irrelevant choices, or choices the user cannot understand,
> presenting a "false model," especially when I've explicitly said that
> with --expert the choices should return?
> 

The choices make no mention of master/subkey structure, nor the actual "Use Flags". "Sign" actually means "Sign and Certify". "X and Y" actually means "X master key and Y subkey".

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140922/e41362bd/attachment.sig>