[ux] Proposal: Shared language to empower our efforts

Greg Norcie greg at norcie.com
Sat Mar 27 18:56:05 UTC 2021


Thanks for this, I am going to unsubscribe, have a great weekend folks

- Greg (he/him)


On Sat, Mar 27, 2021 at 1:19 PM José René Gutiérrez <hola at josernitos.com>
wrote:

> Hello list, in this email I want to share a way of thinking that can help
> us discuss and define a roadmap in Strategy, Design, Tech and Research.
>
> First of all, I think it is difficult to have discussions around the
> impact we have in users' lives. But moreso, the ethical decisions we make
> each time: (i) we release a version of TB (ii) or create a roadmap for the
> next release (iii) or plan a new feature to build, as there are many ways
> we could materialize each feature, (iv) and most importantly how should we
> research if our intentions are met in real life scenarios.
>
> Having said that, I believe it would be* extremely useful to share the
> same language across the team* and that this language be part of the
> process of planning, designing, building and researching. I'm not saying
> that it is impossible to create Tor Browser without a shared language, nor
> that there isn't one already. But I think it could be useful to think how
> we might categorize the influence we want to have in users and how they
> access the Internet as this is a high-level discussion that is shared
> throughout the process by everyone in the team.
>
> *Shared language*
>
> In 2011 *Tromp, Hekkert, and Verbeek* published an article* on "A
> Classification of Influence Based on Intended User Experience
> <https://direct.mit.edu/desi/article/27/3/3/69045/Design-for-Socially-Responsible-Behavior-A>"
> which I think can help us get started and test if this language model
> actually works for us. In it, they define two dimensions: force and
> salience. *Force* being how strong is the influence of the design to the
> user's behaviour. *Salience* being how explicit this is for them.
>
> *Testing the model.* I went back in time to see how we might have used
> this shared language in features that were shipped.
>
> For example, before TB 9.0 if the user resized their browser, there was a
> small warning advising users how that might expose them, as they could
> reveal their fingerprint. So, we are faced with this problem: people are
> being tracked because they resize their browser. And they are either not
> aware of it or just dismiss it as something absurd to worry about.
>
> How do we assess this feature (the warning)? Using this shared language we
> could discuss what type of category it belongs to. I could argue that is a
> persuasive influence as people can be aware of it and it's influence is
> weak. But then, if users are dismissing such an important warning that
> might expose them to trackers, what should we do? Should we have a stronger
> influence?
>
> This shared language could be a valuable tool for designers and engineers
> to think how might we encourage/discourage certain behaviours and to
> imagine beforehand how to assess the impact it would have on the user's
> influence. It's clear, looking back, how Letterboxing
> <https://blog.torproject.org/new-release-tor-browser-90> is a great
> solution for this problem (making the decision for them) or why it was a
> good idea to get rid of the Onion Button
> <https://securityinabox.org/media/torbrowser-osx-en-v01-323-network-settings-via-onion.png>
> (separating it's functionality: making visible the circuit and creating a
> New Identity button), but when we are faced with the problem it could be
> very messy.
>
> And finally is also useful for research purposes as we can try to
> categorize our findings on each feature and build a shared understanding of
> what is the actual impact that has in the user's behaviour. This would
> inform what's important to work on, it provides context to the team as to
> what to do about it and it helps us navigate clearly the decision-making
> process.
>
> *Back to the present moment*
>
> Last week I ran a small exploratory study (here's the report
> <https://gitlab.torproject.org/tpo/ux/research/-/blob/master/reports/2021/UR-Tor-CostaRica.md>).
> In it, two patterns clearly emerged: (i) most participants didn't
> understand the main differences of TB with other browsers, (ii) most
> participants are not heavy technical users. And so, to try to use the
> framework of this language with the findings of the study, I will explain
> two specific issues identified.
>
> *First*, it's clear (in the study) that users were not completely aware
> of how TB works and thus they didn't understand the increased loading time,
> or why they couldn't access certain websites, and when they were asked how
> different it's from other browsers they mainly focused on the appearance.
>
> *This is a huge problem*, as our underlying design is decisive: as in,
> users must connect to at least 3 relays to work. But is somewhat "hidden"
> to users and so they don't understand the implications that this design
> choice has in their experience. Thus our challenge becomes much clearer
> given these facts: how do we make the design much more apparent so that
> users understand the inner workings of Tor Browser? We could think of
> different solutions, but just on top of my head:
>
>    -
>
>    show the Tor Circuit in the about page and not show it (only) inside
>    the TLS/Certification information.
>    -
>
>    show a diagram while they are configuring the browser, or in the
>    actual connection screen.
>
> *Last*, another issue that I stumbled upon during the session, is that a
> user wanted to change the language of the Browser. And when you try to do
> that, it shows this warning
> <https://archive.org/download/warning-language-privacy-tor/warning-language-privacy-tor.png>,
> which confused the user. Using the model described above, we could
> categorize this warning as a coercive influence. As it needs the user's
> input to get out of that screen.
>
> Context: This screen has two goals: (i) to know if the user wants to
> solicit the English version of websites, (ii) and to warn them that they
> could expose their privacy by not doing so.
>
> Without the influence categories we could discuss how we might improve the
> writing so that users are not confused by it (and keep it as a coercive
> influence). But we could ask ourselves if we should even allow the user to
> make this choice and make the decision for them.
>
>    -
>
>    If we decide for them, and make the default option to continue to ask
>    for the websites in English (decisive influence), then we would prevent
>    users from making a possible mistake and provide them with our best efforts
>    to keep their privacy.
>
> We could still make our best arguments regarding if we should make the
> decision for them and not even present the choice. But these are
> discussions we could all be a part of and the language provides a great
> deal of shared understanding within the team and the choice we end up
> shipping to users.
>
> --
>
> Sorry about the long email. I'm more than happy to know your opinion
> regarding this, either by email or at the next IRC team meeting on
> 06-04-2021.
>
> Thanks for reading :)
>
>
> **Tromp, N., P. Hekkert, and P.-P. Verbeek. 2011. “Design for Socially
> Responsible Behavior: A Classification of Influence Based on Intended User
> Experience.” Design Issues 27 (3): 3–19. doi:10.1162/DESI_a_00087
> <https://direct.mit.edu/desi/article/27/3/3/69045/Design-for-Socially-Responsible-Behavior-A>.*
> _______________________________________________
> UX mailing list
> UX at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/ux
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/ux/attachments/20210327/77c51447/attachment-0001.htm>


More information about the UX mailing list