Skip to content
Snippets Groups Projects

OoniUiDesign

Last edited by Alexander Færøy

PageOutline

= Designing OONI UI =

OONI detects censorship, surveillance, and traffic manipulation on the internet.

Mac OS and Linux users can run ooniprobe via the command line or via OONI's web UI. Alternatively, users can run ooniprobe through its distribution for Raspberry Pis.

Installation instructions can be found here.

This project improves on web and mobile UI designs to ready them for launch.

People:

  • Arturo, OONI Team
  • Linda, UX Team
  • Adarsh, contracted
  • Maria, OONI Team

Timeline:

  • Nov 2016: scoping the project, hiring Adarsh, identifying deliverables
  • Dec 2016: usability audit, identifying user personas, designing features, interviewing users
  • Jan 2016: deliver a web and mobile UI with appropriate changes

A more detailed timeline is kept and updated here.

Goals

Having a good user interface that on one hand incentives users to run ooniprobe tests, but at the same time ensures they are not putting themselves at risk by not understanding what this entails. We also want to make it easier to people to understand what OONI does and what they are contributing to by running measurements.

As such we want to:

  • Make the mobile and web based user interfaces more cohesive.

  • Ensure risks are communicated effectively and appropriately to users.

  • Improve the mobile and web based UIs that allow users to run tests, view test results and schedule tests (only in web based UI)

The activities that are going be carried out to achieve such goals are:

  • Analyse the current interface formally and provide feedback on what we currently have (ooniprobe mobile and web UI). (XXX add link the initial pdf UI breakdown)

  • Redesign of the mobile and web ui: going screen by screen and proposing the changes to be made.

  • High-fi mockups for the suggested changes to the views.

  • Graphical design work: for example stylistic changes (i.e. spacing, fonts, colors, etc.).

  • Documentation of the work: describing why you changed what you changed, what you didn't change and why. Similar to what has been done in redesigning metrics (https://trac.torproject.org/projects/tor/wiki/doc/UX/MetricsRedesign).

  • Test implementation of UI/UX, and review platforms for usability

=== Quick Links ===

= Background =

Communicating risks to users

OONI's software tests, called ooniprobe, serve as an investigatory tool for examining and uncovering internet censorship. As such, the use of ooniprobe can be associated with different types of risks, depending on the country that the tests are being run from.

The main risks associated with the use of ooniprobe include:

  • Anyone monitoring your internet activity (e.g. ISP, government, employer) will know that you are running ooniprobe;

  • The tested URLs include provocative or objectionable sites (e.g. pornography, hate speech);

  • Some ooniprobe tests might trigger the suspicion of your ISP if they are viewed as a form of "hacking";

  • The use of ooniprobe and/or its dependencies (such as circumvention software for relevant tests) might be illegal or viewed as such in certain countries;

  • The use of ooniprobe might be viewed as a form of espionage or condemned under broad national security laws in certain countries.

However, it's worth highlighting that, to our knowledge, no ooniprobe user has ever gotten into any trouble as a result of using this software or generally engaging with the OONI project.

While the risks outlined here are quite speculative, we have an ethical obligation to inform our users of potential risks. To this end, we have developed documentation, in consultation with lawyers, that explains in detail the risks associated to installing and running ooniprobe, and in regards to publishing measurements. This documentation is published on OONI's website and can be found here.

Initially, this documentation was also included in OONI's desktop and mobile clients. However, as this documentation is far too long, there is the concern that users will likely not read it and feel dis-encouraged from using the clients.

To address this, we are revising the Risks documentation so that it conveys the information in a concise and "user friendly" way through the desktop and mobile clients. As part of this process, we are aiming to strike a balance between informing users adequately of potential risks, while not dis-encouraging them from using ooniprobe.

Quiz

To acquire consent from our users, we have created a quiz that they are required to answer correctly as a prerequisite to using ooniprobe.

This quiz attempts to ensure that users understand that:

  • Anyone monitoring their internet activity will be able to identify them as an ooniprobe user;

  • Unless they opt-out, their measurements will automatically be published by OONI.

As part of the review process, we aim to revise the quiz to improve upon consent acquisition.

History of the OONI UIs

This is how the OONI desktop UI used to look like in it's first iteration: https://github.com/TheTorProject/ooni-wui/issues/4#issuecomment-252314702

This is how the OONI mobile UIs used to look like in their first iteration: https://github.com/measurement-kit/ooniprobe-ios/issues/43

UX Audit

Overall

  • ooniprobe needs to do a better job of communicating its purpose, and showing users where and how using the platform adds value.
  • The onboarding disclaimers are severe, and while OONI does have a responsibility to inform users, the disclaimer does not need to be as “scary” as it currently is.
  • Rather than overwhelming users with “possible risks,” help users manage their risk by walking them through what different settings do.
  • The defaults should be to the “safest” risk profile, and accepting more risk should be an opt-in process (as opposed to now where most configs seem to sway in the direction of maximizing usefulness of measurements).
  • The “at risk, doesn’t understand ooni functionality and risk” persona (Persona 4) is the most important user type to design for, as they are the largest user group.

Web Recommendations

  1. Split up onboarding information
  2. Convert current “Home” screen into a dashboard
  3. Consolidate “Decks” + “nettests”

Mobile Recommendations

  1. Swipes for onboarding
  2. Use design cues to make tests screen more user-friendly
  3. Micro-interactions as aids

= Strategy for Redesign =

  • Focus on Persona 4 and “The Lawyer” (“Persona 2.5”) as primary target user
  • Make the "Risks" section more accessible by using less scary language, splitting it up, and nesting relevant settings in-line with each risk section
  • Consolidate pages, and use modals to provide non-essential/"nice-to-know" information
  • Show users the value they are adding by converting "Home" into a dashboard
  • Implement micro-interactions and gestures as necessary to aid mobile usability

Design Timeline

  1. New designs were submitted on Thursday, December 8th
  2. Group meeting to discuss the designs on Friday, December 9th at 1600 UTC, @Arturo gave the green light for finalizing the web UI and beginning work with the mobile UIs
  3. Revisions were made and submitted on Friday December 9th
  4. Web UI Assets were approved by Maria on Friday, December 9th, which means I can get started on the Mobile UI next week!
  5. Mobile UI Assets were approved by the group on Wednesday, December 21st
  6. Spec was submitted on Thursday, December 22nd
  7. Designs were discussed and locked in on Friday, December 23rd

User Interview

8 stakeholders were interviewed:

  1. Two from persona 4 (target persona)
  2. Two from persona 3 (one interviewee fit both persona 2 and persona 3)
  3. Four from persona 2 (most popular current user)
  4. One from persona 1

Top 3 Takeaways:

  1. Biggest worry with regard to risk is informed consent, second to technical complexity a. While we didn’t re-invent our existing solution to this concern (i.e. the quiz), we did adjust the copy and content to improve risk comprehension
  2. All users interviewed found the new Web UI designs to be intuitive and aesthetically pleasing (less words = better) a. This validated that the web UI was something that users across multiple disciplines could pick up and use with a relatively low barrier to entry.
  3. The biggest “dream feature” request was a better way to see results, second to a mobile app a. Mobile app is on the way, and the new designs present past measurements in a much more useful/presentable manner

= Iteration and Decision =

Web UI

  • The first iteration of the Web UI captured the overall design aesthetic and established the design hierarchy. a. Overall positive reaction to the screens b. Some changes to the positioning of buttons and layout of content c. Measurements page was streamlined to present data more effectively d. Quiz was re-introduced into the onboarding process. While this is not a strong design decision, questions had to be included to satisfy external organizations which monitor OONI
  • The second iteration of the Web UI tweaked some of the processes, and focused on making minor adjustments to the UI elements. It also re-introduced the Quiz as a modal, and consolidated some functionalities into the footer.
  • The final iteration introduced modals for running each test within a deck, smoothed some UI elements with the mobile UI for consistency, and cleaned up the overall layout.

=== Mobile UI ===

  • First iteration of the Mobile UI aimed to translate the Web UI onboarding experience, and update the existing Mobile UI to be more user friendly.
  • The second iteration of the mobile UI cleaned up the dashboard, implemented more consistency in headers and other elements, and established a set of “green dot” cues to guide users towards the results of a freshly run test.

Project Retrospective

  • I’m very happy with the onboarding experiences for both Web and Mobile
  • I think that the Mobile “home” screen is stronger than the Web “home” screen, but that is also a function of the platform.
  • Viewing the results of a test are still messy on both platforms. In future versions, I would like to further streamline this process, and possibly hide some of the data shown from end users unless they opt-in to see it.
  • When measuring user behaviors on the live versions of both the Mobile and Web platforms, I would be interested to see how many users view reports. I would also want to pin-point the “ledges” where users leave the platform.
  • I would like to see the rest of the OONI website updated to match these UIs, both for consistency and to implement a stronger user journey (which always starts at the landing page).
  • In future iterations, I would suggest incorporating more of the brand identity. I have consolidated all brand assets for OONI, so I suggest publishing these on the main page for future designers to use.
  • I’d really like to find a more UX-friendly way to collect proof of informed consent.

Next Steps

  • I will re-engage with the team in Q1 2017 to help test the Mobile and Web UIs once they have been implemented
  • I will work with @Maria to finalize the copy and get that to the team. Part of my Q1 re-engagement will include making sure that the copy has been properly implemented
  • @Maria had an idea about an onboarding tutorial (a la introjs.com) and a GIF-help docs

Comments

    Please register or sign in to add a comment.