Re: GUI design ideas

[Giorgio Maone]

All right, I'm inside now :)

It seems if you connect when nobody is there yet, it says "you'll be
connected when the meeting start", but it doesn't actually happen.

Cheers
-- G

On 21/05/21 16:08, Giorgio Maone wrote:
> Hi Ruben,
>
> thanks for this draft: it looks like a good starting point I'm looking
> forward to discussing.
>
> Just to be sure: is the design meeting at 16 on
> https://testgreenlight.fsf.org/qui-udh-d6u (I can see nobody there) or
> is it at a different time/place than the development one?
>
> Best
>
> -- G
>
>
> On 21/05/21 14:41, Ruben wrote:
>> I've taken a look into the UI design of a few well-known privacy
>> extensions. Based on the main user interface (the drop-down menu), they
>> can generally be grouped into 3 categories:
>>
>>  - Global: simple configuration method where a target level of
>> protection is selected. This is the current design on JSR, and can also
>> be seen on others like uBlock, HTTPSEverywhere, DDG, Disconnect. The
>> pros are that it is less cluttered and friendlier for newcomers. The
>> cons are that finer tuning require opening an advanced settings interface.
>>  - One dimension: the UI allows to fine-tune the behavior on one
>> dimension of its range of application, that is, which features are
>> blocked, or which visited sites are protected, or which services loaded
>> by those sites will be blocked. Some examples are NoScript, Ghostery,
>> Privacy Badger, LibreJS. Pros are that it allows for more customization
>> and it informs the user about the actions being taken, so it can be more
>> didactic. Cons are a more complicated interface.
>>  - Two dimension: the UI allows to fine tune on a table of features X
>> domains. An example of this is uMatrix, which lists all the domains from
>> where resources are being fetched by a site, and which type of resource
>> is coming from each, allowing to choose the type of response for each
>> combination in a 2 dimension matrix (thus, the program name). This gives
>> the highest level of control at the expense of a more intimidating
>> interface. This level of detail may be available in the other
>> extensions, on an advanced configuration page.
>>
>> In the examples listed, some extensions focus their use case on either
>> domains of application or features, so their GUI design reflects the
>> problem they are targeting. In our case, our application focuses on
>> features, and the domain of origin is (although important) secondary, so
>> we should have this in mind on the interface design. I believe that more
>> important than which domain is triggering a feature, is whether the
>> request is 1st or 3rd party.
>>
>> I propose this hybrid design type:
>>
>>  - A global setting, that applies a default starting point and a method
>> to increase or decrease the protection-level vs disruption trade-off
>> with one click, suitable for newcomers.
>>  - Underneath, a list of each feature that has been triggered by this
>> site, with a link to the documentation page for that problem/solution,
>> and buttons to chose the desired behavior for this, any, or 3rd party
>> domains:
>>
>>                    ACTION                      SITE
>>   - Feature 1: [x]allow []replace []block  |  []this [x]any []3rd party
>>   - Feature 2: []allow [x]replace []block  |  []this []any [x]3rd party
>>   - ...
>>   - Other features (not triggered by this site, opens advanced settings)
>>
>> If the graphical structure is found to be adequate, we can then decide
>> what is a sane default setting for each protection level, and how is it
>> reflected on the way this entries are displayed. An example of possible
>> choices:
>>
>>   - Default level: action=replace, site=any
>>   - Permissive level: action=replace, site=3rd party
>>   - Hardened level: action=block, site=any
>>
>> The extension icon counter should show the number of events triggered by
>> the site on the active tab, and the color could indicate the action
>> taken. It could also reflect a value for how potentially dangerous a JS
>> feature may be, which we would codify in the wrappers. Care should be
>> taken for color to convey an intuitive concept, and for preserving
>> accessibility.
>>
>> Attached are some of the examples mentioned.
>>
>> Some questions that popped up while thinking of this:
>>  - Should there be a "block" action for features, or just allow/replace?
>>  - Should CSP be trusted by the extension, or be strict on 1st/3rd
>> domain separation?
>>  - Should color be used to indicate the action taken, or the level of
>> risk of a feature, or neither?
>>
>> Let's start by discussing this and coming up with a mockup. As a next
>> step we should also discuss what to include in the advanced config page
>> (e.g. whether to list things by domain or by feature).
>>
>> Cheers,
>

-- 
Giorgio Maone
https://maone.net