Open Bug 1701050 Opened 3 years ago Updated 3 months ago

Change "Blocked Temporarily" and "Allows Temporarily" strings to just be "Blocked" and "Allowed"

Categories

(Firefox :: Site Permissions, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: mconley, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [proton-door-hangers][priority:2c])

Attachments

(1 file)

UX has requested that we shorten these strings. Any issues with this change, pbz?

Flags: needinfo?(pbz)

To clarify: Is this bug about changing the labels in the permission panel for temporary permissions to match permanent permission state labels?

There might be a UX issue here, where users can't differentiate between temporary and permanent permissions anymore. This could be confusing for the WebRTC grace periods, where we currently show "Allowed Temporarily". Users may think the website has as permanent grant.
It could also be confusing for other prompts where users can check "Remember this decision". No matter if they check the box or not, the UI state will be the same.

From a privacy perspective, showing the "stronger" permission grant seems fine. However, for "blocked" we might give the user a false sense of security. They might think it's a permanent block, but we remove it on page refresh / tab close.

Flags: needinfo?(pbz)

Betsy, I see pbz's point here, are you OK to close this one or perhaps you have more thoughts?

Flags: needinfo?(bmikel)
Attached image Blocked-Allowed.png
Flags: needinfo?(bmikel)

Yes, there is certainly nuance in how long the block/allow period lasts depending on the specific permission and if they've selected Remember this decision or not. The content recommendation remains the same.

Our position is that surfacing this technical complexity in the product introduces the possibility of even more confusion instead of clarity. When a user sees Blocked Temporarily / Allowed Temporarily, that introduces the question, "Huh, what? How long is temporary?" If the permission is Blocked/Allow right now, the moment they check it, the Blocked/Allowed label (without the temporary) is accurate and communicates what it needs to.

In addition, this little UI is quite dense and this extra word in the label is not doing us any favors. If you have several permissions as once, the text wraps in strange ways and begins to expand, covering the page content.

This is EN-US, not sure about other locales, some of which are 30% longer in length.

Thanks for elaborating on the reasoning behind this change!

(In reply to Betsy Mikel [:betsymi] from comment #4)

When a user sees Blocked Temporarily / Allowed Temporarily, that introduces the question, "Huh, what? How long is temporary?"

I agree that a "temporary" label without an explanation can be confusing. Temporary usually means for the lifetime of that particular tab / until the user refreshes the page. I think that's a concept many of our users understand. They grant a permission, (not checking "remember") and expect the permission to be gone the next time they visit the site. The newly added WebRTC grace period grants for Proton are an exception to that.

In addition, this little UI is quite dense and this extra word in the label is not doing us any favors. If you have several permissions as once, the text wraps in strange ways and begins to expand, covering the page content.

Yes, that seems problematic. So, the idea is that we have a shorter state label and the permission label has more space so it fits in the same line? I'm wondering if shortening the state label is enough in all cases, especially for other locales, as you mentioned.
Have we considered making the permission panel wider?

I don't want to block the Proton work and I can see how the current UX isn't ideal. I'd like to hear Johann's opinion, specifically on the privacy aspect of this change.

Flags: needinfo?(jhofmann)

Yes, let's get Johann's perspective for sure!

Temporary usually means for the lifetime of that particular tab / until the user refreshes the page. I think that's a concept many of our users understand.

I am not confident we can say that. I would say that is an assumption.

(In reply to Betsy Mikel [:betsymi] from comment #6)

Yes, let's get Johann's perspective for sure!

Temporary usually means for the lifetime of that particular tab / until the user refreshes the page. I think that's a concept many of our users understand.

I am not confident we can say that. I would say that is an assumption.

While I'm also not sure this is clear to users you have to admit that we're all arguing based on assumptions here, if we wanted to make data-driven decisions then this bug would be stalled on collecting more data. :)

In addition, this little UI is quite dense and this extra word in the label is not doing us any favors.

I agree that the extra text is crowding the panel.

If you have several permissions as once, the text wraps in strange ways

To be more accurate, it's independent of the amount of permissions and, in English, only happens for the persistent storage permission because that also has a long permission name. So yes, it could potentially happen in other languages. Whether that wrapping is strange or unexpected is up for debate, I guess.

and begins to expand, covering the page content.

What? I'm not sure what you mean by that. The text is going outside of the panel?

So, overall I can see both sides here. On one hand, I think it would be nice to have a cleaner layout for this dialog with more space and less information for the user. On the other, I agree it is pretty important to make the distinction between a permanent and temporary permission visible, especially since it serves as feedback to the actions the user took in the permission dialog (and a few more advanced users will also expect this). This is especially important for Camera/Mic access, where this indicator serves two different purposes:

  • While recording, the user has no other means of ensuring that the given camera access is actually one-off, not permanent. If they wanted to remove the permission to be sure, they'd stop the recording as a side effect. We should not motivate that.
  • The temporary compatibility grants that Paul mentioned are not associated with a user action. By stating that that grant is temporary we can hopefully hint to the user that this isn't something to worry about.

Nonetheless, I totally see your point about specifically the word "temporarily" being too ambiguous.

My suggestion would be to change the text to something like "Allowed for this Tab" to help reduce confusion and slightly widening the panel to help with the layout issues. I don't think we can perfectly solve one unless we're willing to stop caring about the other, but maybe this brings us closer to a good compromise.

Flags: needinfo?(jhofmann)
Priority: -- → P2
Whiteboard: [proton-door-hangers] → [proton-door-hangers][priority:2c]

(In reply to Johann Hofmann [:johannh] from comment #7)

My suggestion would be to change the text to something like "Allowed for this Tab" to help reduce confusion and slightly widening the panel to help with the layout issues.

That works for me. Could also be a different copy, as long as it somehow communicates to the user that the permission has limited lifetime.

This change will be unlikely to make it into what we ship in 89 given our body of remaining work and timelines. That said, I don't think moving from a string that has 19 characters and 2 words to one with 20 characters and 4 words helps the user experience, even if it would be more technically accurate. I'm not sure what the right path is here, exactly, but I would err on the side of not doing anything which would force us to widen the panel, especially in non-English locales. Given the i18n considerations for our UX, we should strive to find strings which are as easy to localize as possible.

Type: task → enhancement
Priority: P2 → --
Severity: -- → N/A
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: