Visual indicator for temporary rules in the menu

[msxfm]

Issue by jsamuel
Thursday Dec 22, 2011 at 18:57 GMT
Originally opened as RequestPolicy/requestpolicy#167

---

imported trac ticket
created: 2011-01-25 07:01:08
reporter: farp

Currently there is no way to tell the policy for an allowed request (e.g. is it temporary/permanent, destination/source/or point-to-point based).

In case of temporary vs. permanent, I would suggest to write the //domain in italic// in the main menu for temporary policies. (I wrote this also here: ticket:64#comment:4)

In order to distinguish destination/source/point-to-point based policies, I would suggest to use symbols or simple ASCII characters which should be arranged in front/behind of the domain name (in the main menu):

• •> : request is source based (e.g. all requests from example1.com are allowed)

• • : request is destination based (e.g. all requests to example2.com are allowed)

• •>• : request is point-to-point based (e.g. all requests from example1.com to example2.com are allowed)

[msxfm]

Comment by jsamuel
Thursday Dec 22, 2011 at 18:57 GMT

---

imported trac comment
created: 2011-02-05 12:57:01
author: eibwen

See #100 (and other bugs mentioned in that thread) for various policy menu deficiencies and proposals...

[msxfm]

Comment by jsamuel
Thursday Dec 22, 2011 at 18:57 GMT

---

imported trac comment
created: 2011-02-05 13:05:41
author: eibwen

With regard to this proposal, it seems that it would fail accessibility concerns. Further, it is highly abstract. There is no correlation between "Where's the dot/symbol" and "What is the Policy".

Agree that the menu needs improvement; however, there are usability and accessibility concerns here as noted in #100. There are at least two use cases: (1) identify current policy, and (2) change current policy.

This would not address (2).

[msxfm]

Comment by jsamuel
Thursday Dec 22, 2011 at 18:57 GMT

---

imported trac comment
created: 2011-02-07 05:13:32
author: farp

Replying to [comment:2 eibwen]:

With regard to this proposal, it seems that it would fail accessibility concerns. Further, it is highly abstract. There is no correlation between "Where's the dot/symbol" and "What is the Policy".
"highly abstract" is a little exaggerated here. Since it is a symbol and not written text, of course some abstraction is necessary (i.e. as it is with the colors of the RP status icon).
Ideally the symbols should be explained in the FAQ. But even if not, I guess the average user would figure it out quite fast during normal use, since the symbols are quite intuitive (IMO).

Please elaborate more what you mean by "fail accessibility concerns".

Agree that the menu needs improvement; however, there are usability and accessibility concerns here as noted in #100. There are at least two use cases: (1) identify current policy, and (2) change current policy.

This would not address (2).
That is correct.

Regarding to #100, the main goal of this issue is to improve the '''current''' menu, whereas you focus on (complete) new menu. Maybe there is usage for both of the proposals. I'll also comment on #100.

[msxfm]

Comment by jsamuel
Thursday Dec 22, 2011 at 18:57 GMT

---

imported trac comment
created: 2011-02-11 01:44:10
author: eibwen

Replying to [ticket:167 farp]:

In order to distinguish destination/source/point-to-point based policies, I would suggest to use symbols or simple ASCII characters which should be arranged in front/behind of the domain name (in the main menu):

• •> : request is source based (e.g. all requests from example1.com are allowed)

• • : request is destination based (e.g. all requests to example2.com are allowed)

• •>• : request is point-to-point based (e.g. all requests from example1.com to example2.com are allowed)

This is insufficient to clearly and unambiguously indicate policy.

|||||| '''Instance''' ||'''Evaluation''' (per legend)||
|| || site || ||unambiguously denied by all policies||
|| * || site || ||unambiguously permitted by src policy||
|| || site || * ||unambiguously permitted by dest policy||
|| * || site || * ||'''ambiguously''' permitted by any of: (a) src AND dest policies; (b) src->dest policy; (c) src AND src->dest policies; (d) dest AND src->dest policies; (e) src AND dest AND src->dest policies||

Replying to [comment:3 farp]:

Since it is a symbol and not written text, of course some abstraction is necessary
Yes, symbols are abstractions; however, an abstraction (symbol or otherwise) is '''not''' necessary to convey the desired information.

Use of text is neither precluded nor any less of a viable alternative. In fact, in certain contexts, it may be preferable. There are a number of ways to convey information, including but not limited to, text, color, and symbols.

some abstraction is necessary (i.e. as it is with the colors of the RP status icon).

Colors have established, albeit often connotated, relationships with various states. A classic example is the association of red with danger, stop, etc. Agreed that this is often insufficient to convey complex information, such as context-based states (eg blocked, but only from non-same-origin).

Using symbols in a new context -- however sensibly and consistently structured -- is an abstraction without the benefit of established connotations. Yes, the proposal does add additional information to the menu; however, this does not improve the clarity of the menu but rather increases the amount of information shown. As such, the potential for users to suffer "information overload" is equivalently higher.

Granted if a user wants to know the status of everything as a dashboard, it may help in that regard; however, if a user wants to know a specific piece of information, the metaphorical "haystack" would be larger while the "needle" would remain unchanged.

Ideally the symbols should be explained in the FAQ. But even if not, I guess the average user would figure it out quite fast during normal use, since the symbols are quite intuitive (IMO).

There are numerous aspects to usability and accessibility, and showing all (or in this case, more) of the information all at once is not necessarily a practical answer...

Presuming that average users would intuitively discover the meaning of the symbols based on correlations over time is likely very generous. In fact, I would assert that many users would never come to determine what the symbols represented. The average user would probably complain about random dots appearing on their menu, if they weren't privy to the legend. Users, including those aware of the legend, who don't "grok" the symbols would likely find them more annoying than useful...

Ideally the information should be displayed in a transparently self-evident format, mitigating the need for a FAQ. Granted, the current menu does not quite meet that requirement either; however, its use of text is much more readily understood by all.

Please elaborate more what you mean by "fail accessibility concerns".

For example, how would this be handled by a screen-reader for a blind user? Would you expect the screen-reader to orate "dot site no-dot"?

How would this be technically implemented? Adding a unicode symbol prefix or suffix to the menuitem label? What about consistency of vertical alignment? What about overflow -- would the site be ellipsized to show the trailing dot? If the symbol was not appended to the item label, how would the screen reader know to orate it and in the expected context?

(Note that not appending to the label would likely require significant XUL/XBL coding to the point of creating a custom dialog. Similarly, ellipsizing the label up to the trailing dot if present would require significant code.)

I'd surmise that screen-readers do not orate "File menu, imagemenuitem '''image removable media''' Underlined S-ave ellipse Keyboard Shortcut Ctrl+S"...

What symbols are audibly transcribed by screen-readers? Is the behavior standard across all screen-readers? How are symbols transcribed? "dot", "glyph", "middle dot", "cross product", etc? How does rtl vs ltr factor into the proposal -- even for sighted users?

I'm sure I'm missing many more significant examples; however, the point is that there is a significant accessibility aspect that should be considered in addition to the usability concerns.

[nodiscc]

Copying @Eibwen's most important points regarding that issue:

Yes, the proposal does add additional information to the menu; however, this does not improve the clarity of the menu but rather increases the amount of information shown. As such, the potential for users to suffer "information overload" is equivalently higher.

There are numerous aspects to usability and accessibility, and showing all (or in this case, more) of the information all at once is not necessarily a practical answer...

IMHO the risk of information overload is real. You can already know about the origin of a rule by clicking the destination and check for Stop blocking requests from a to b or Stop allowing requests to x to know more about the reason for an allow/deny action. Or check the rules list in the prefs.

So the only valid point here is IMHO an indicator for temporary rules (timer icon on the right side of destination). This will also be useful for #294. I'll change the issue title.

[myrdd]

Whether it will be a timer icon or something else, we need to be aware of the three cases:

1. Only permanent rules have applied.
2. Only temporary rules have applied.
3. Both permanent and temporary rules have applied.

In case of the „timer“, we also need an icon for the third case. Maybe a clock that is only partly visible?