[Autocrypt] UI prototype next steps

[Oliver Wiese]

Hi,


I like the idea to communicate with the Bot. This would be an interactive tutorial and users can learn how to compose encrypted messages. I think the question shouldn’t be about having a summery or not.  May be technical terms like secure channel etc. is fine but maybe we can find a more practical metaphor. I would be interested in the mental model of the users after they sync the keys. Also difference between a typical tutorial and a communication with a bot would be interesting, too.
For teaching other users you may can take a look on this paper [1]. 
Maybe we can discuss on more IRC.

Cheers
Oliver



[1] S. Ruoti, J. Andersen, S. Heidbrink, M. O’Neill, E. Vaziripour, J. Wu, D. Zappala, K. Seamons. “We’re on the Same Page”: A Usability Study of Secure Email Using Pairs of Novice Users, CHI2016



> On 16. Jun 2017, at 10:45, azul <azul at riseup.net> wrote:
> 
> Hi,
> 
> 
> During the Level 1 hackathon i demoed the current state of the UI Demo
> and asked what people would like as next steps and what could be useful
> to test with it. There was little resonance and at the same time my
> impression is that the actual implementations are progressing nicely. So
> after most people had left Holger and me sat down to talk about next
> steps and what to focus on. Afterwards gorhgorh and me met in irc to
> also discuss this.
> 
> We think we should move towards more of a test setup where a single user
> is given a task (or multiple tasks) and we can test how they perform
> that task.
> 
> For example a test setup could look like this:
> 
> * The user finds an email in their inbox with bob the bot asking them to
> setup autocrypt, describing the steps a bit and linking to a short
> summary of what autocrypt is.
> 
> * If they reply to bob we check for an autocrypt header and whether they
> are using encryption and program the bot to respond accordingly.
> 
> * once they established encrypted communication we ask them to teach
> another person the same.
> 
> For example we could run this test with and without the short summary in
> the beginning. We could also evaluate how people would explain autocrypt
> once they used it and if it matches our expectations.
> 
> It seems like a reduced ui prototype like the one we have could be
> beneficial for this because it has a lot less distraction and also does
> not have to carry the traditional key management interface that some
> real clients would like to keep. This way we hope to test the user work
> flow and find out more about their mental models in a simplified setup.
> 
> This approach also allows us to significantly reduce complexity of the
> prototype because we can drop the switching between users and will only
> introduce switching devices once we are done with the initial tests.
> 
> What do people think about this approach?
> 
> Do you have specific scenarios, ui elements or text snippets you would
> like to test?
> 
> We hope that the prototype can inform decisions in the spec, ui
> recommendations and the actual implementations. So having concrete
> questions to look into would be great!
> 
> Cheers,
> 
> Azul
> 
> 
> <0x20D3457D.asc>_______________________________________________
> Autocrypt mailing list
> 
> Post: Autocrypt at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/autocrypt
> 
> To Unsubscribe
>        Send email to:  Autocrypt-unsubscribe at lists.mayfirst.org
>        Or visit: https://lists.mayfirst.org/mailman/options/autocrypt/oliver.wiese%40fu-berlin.de
> 
> You are subscribed as: oliver.wiese at fu-berlin.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5330 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/autocrypt/attachments/20170617/ab6117aa/attachment.bin>