Closed Bug 690161 Opened 13 years ago Closed 6 years ago

Redesign Plugin and Addon blocklisting UX for users

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED INACTIVE

People

(Reporter: briansmith, Unassigned)

References

()

Details

(Keywords: sec-want, ux-error-prevention, ux-interruption, Whiteboard: [sg:want])

Attachments

(2 files)

The current UX is illustrated at https://wiki.mozilla.org/Blocklisting.

During the meeting about blocklisting the Java Plugin, we identified several confusing aspects of the blocklisting UX. For example, when we left the meeting, we all were thoroughly confused as to what the "Cancel" button in the UI did and we had to inspect the code to find out.

We also all seemed to agree that the blocklisting UI is very disruptive to the user. We would like to find a way to make the blocklisting less disruptive, so that we don't have to make a "this annoys users vs security" tradeoff. One option would be to show an infobar or similar when the user visits a page that requests a plugin that has been blocked, instead of showing them this dialog box every time we blocklist an plugin that they happen to have installed.

We (secteam) also seem to be in agreement that we must remove the "no, don't block this for me" checkbox in the dialog box for soft-blocked items.

Also, we should reconsider the distinction and semantics of softblocking and hardblocking in general. IMO, security team, UX team, and the plugin team should try to find simpler mental model for this, that supports useful semantics that we need in real-world situations, and which provides an appropriate level of control to the user based on the likelihood of the user being able to understand the issues involved.
We have in general never been happy with the blocklisting service (not just the UX of it) and in recent weeks I've seen a number of bugs filed with proposed changes to the service and the UI for the service. I think we need to stop making incremental changes here, step back and create a feature page for a redesign of the blocklist service as a whole, it clearly isn't doing what we need of it.
Geo has just completed a thorough inspection of the current UI and behavior. I'm sure he's super-busy or super-otherwise-occupied but it would be good if we could get his screenshots and workflow as-is spec into a wiki page or this bug so we know precisely what does and does not work today.
(In reply to Asa Dotzler [:asa] from comment #2)
> Geo has just completed a thorough inspection of the current UI and behavior.
> I'm sure he's super-busy or super-otherwise-occupied but it would be good if
> we could get his screenshots and workflow as-is spec into a wiki page or
> this bug so we know precisely what does and does not work today.

That's useful though we've done this numerous times before. Bug 455906 has the initial designs and I recall morgamic doing a run through of I think the soft blocking experience that I can't find right now.

I'm really more interested in completely ignoring the current design and sitting down to figure out what we actually need to be able to do with blocklisting and how it would ideally look. If that ends up being close to what we have now then great, we make incremental improvements to meet it, but working what we have now as a basis constrains us more than we want I think.
This time of night it's mostly just super-tired. :) 

I put a pretty explicit workflow into bug 690205 re: handling of plugins that are already blocked before installation. Sounds like this discussion overlaps that one, and that flow would be a great place to start.

I only took a couple of screenshots today because I was largely just addressing your initial concern re: the cancel button (which turned out not to be the UI I encountered in FF7). I've attached them. 

The smaller one is the UI in question on Mac; Windows was very similar. The larger is an unexciting screen shot of the disabled plugins in about:addons, but since you asked I attached it.

I wasn't particularly meticulous today in my record-keeping since I wanted to get your concern addressed quickly. If you need something more comprehensive than this, we can talk about the requirements of what you're looking for and I'll either find time or person-with-time to satisfy them.
Depends on: 463374
Depends on: 690205
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: