UI terminology for calculated validities

[Arne Renkema-Padmos]

I'd also like to thank Nicolai for spawning the interesting thread.

> On 25 apr. 2014, at 13:43, Bernard Tyers <ei8fdb at ei8fdb.org> wrote:
> 
> At the risk of being flamed, can I suggest asking the users what they
> think?

A very good suggestion.

> I have read some HCI research into non-expert user understanding of PGP.

A nice listing of relevant literature here:
http://lists.gnupg.org/pipermail/gnupg-users/2012-August/045271.html

Additionally, here is a preprint version of a paper that I coauthored that will be presented at PETS2014: https://www.dropbox.com/s/ziej0q4q4r29xnj/pets-preprint.pdf

It turns out that many people don't even understand the infrastructure behind email transmission, let alone end-to-end encryption. Additionally, as also noted in some of the literature above it's not just a usability issue, but also a socio-technical problem (issues around availability, network effects, unconcerned users, "nothing to hide", unclear consequences of plaintext transmission, etc). However, that isn't an excuse not to have technology available that is usable to end-users in case people do flock to E2E encryption technologies.

> With the utmost respect to the list members, you (we) are not
> non-expert users, and so our opinions really don't matter.

Indeed. There are other concerns besides usability though, one being backward compatibility with documentation / expert understanding. I don't see why we cannot stick with the existing, ingrained terminology for experts, and standardise a set of term, metaphors, and even icons for the user-interface, which are built on experimentally verified findings (i.e. user studies).

Having one list of terms/icons isn't the whole equation though:

- How do you get all GPG UI projects to agree to using them? (And what about knowledge transfer to and from other crypto products?)
- How do you keep the terms/icons updated?
- How do you deal with different languages and cultures? Is a global standard possible? (See the failure of Isotype and Esperanto, but the success of icons on music players, i.e. start/stop/rewind, and the widespread use of the padlock.)

An interesting project that may serve as inspiration, but which doesn't seem to have had lasting impact (especially not in the hodge pot of mobile browser security indicators), is the W3C's finished Web Security Context Working Group: http://www.w3.org/2006/WSC/ and especially the user interface guidelines at http://www.w3.org/TR/wsc-ui/

Some initial actions/ideas from my side:

I've asked Tankred Hase (whiteout.io) about standardisation, and he mentioned that he didn't think it was very likely that email clients would standardise on terminology and icons. The reasoning behind this was that products want to have their own design/brand. This was argued to not be a problem as long as products are internally consistent and understandable.

An idea I presented at 30C3: Maybe we can use an approach similar to what OSI is doing with their OSI trademark. There are many encryption tools being built in people's garages, but how does the end user know they can trust/use these? We could come up with "trusted icons", i.e. trademarked logos that can serve as an icon / icons in an email interface. Only the software that meets a certain quality standard would be able to use the logo icons (similar to the OSI requirements).

Slides: https://www.dropbox.com/s/urf3flbhswrxipi/slides-v2.pdf
Recording: https://www.dropbox.com/s/r6qux6ql8idu55k/30c3-arne.mp4

> The focus of Nicolai's question is *non-expert*, so we need to get
> their opinions.
> 
> Suggestions? Arguments?

I think we shouldn't just get their opinions (self-report can be pretty unreliable), but instead actively try out different approaches. I.E. A user study, but maybe first an ideation session with users to tease out mental models, metaphors, (mis)conceptions, etc.

Finally, and probably most importantly, if we want to start a project to deal with any of the above problems then we should have a very clear scope if we want to get anything done. (Interesting read: Simple Sabotage Field Manual of the CIA, page 28. To derail a project/meeting, one very effective way is continually expanding scope / bringing up irrelevant issues.)

Cheers,
arne

--
Arne Renkema-Padmos
PhD student, TU Darmstadt
arne at secuso.org, @hcisec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140427/67181700/attachment-0001.html>