1289177 - Tracking Protection's "Change blocklist" dialog has a poor and misleading interface

Status: RESOLVED INVALID

(Firefox :: Protections UI, defect)

Description

[Ed]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

In Menu go to Tools|Options then Privacy|Change Blocl list. 


Actual results:

We see a non-standard window with unclear/misleading interface:
- the name of the 1st column is empty 
- check mark cannot be removed
- placeholder of the unchecked mark is invisible



Expected results:

- If you show a window, it should have a title bar and style according to my (Windows) preferences.
- It should be movable (drag title bar)
- Table is confusing here. Why do I need it? can I sort columns or what???
- The placeholder of controls should be visible
- After playing for some time I think that the functionality should be like by radio-buttons. Then make it obvious for users. Radio-buttons do NOT look like check marks.
-  fire game-changers

Comment 1

[Markus Stange [:mstange]]

I agree, this is really confusing UI. I think it's supposed to be two radio buttons (i.e. exclusive selections), not checkboxes. Not sure why it's not using regular radio controls. Has there been UX input on this dialog?

Comment 2

[François Marier [:francois]]

Once bug 1258041 lands, it will be possible to change this UI so that the list selection is based on multiple selection.

Clearing the regression keyword because that's not a regression, that UI has always been like that.

Comment 3

[Ed]

(In reply to François Marier [:francois] from comment #2)
> Once bug 1258041 lands, it will be possible to change this UI so that the
> list selection is based on multiple selection.
> 
> Clearing the regression keyword because that's not a regression, that UI has
> always been like that.

I dont think it is a multiple selection, it is "one of" selection, i.e. can be a combo box as well.

Comment 4

[François Marier [:francois]]

(In reply to Ed from comment #3)
> I dont think it is a multiple selection, it is "one of" selection, i.e. can
> be a combo box as well.

It's currently not a multiple selection because the lists were not additive, you had to set "urlclassififer.trackingTable" (in about:config) to one of these:

- mozstd-track-digest256 (basic list) or
- mozfull-track-digest256 (strict list)

but that will change once the bug has landed we'll have two lists:

- base-track-digest256 (same as the basic list)
- content-track-digest256 (only the extra entries that were in the strict list but not in the basic list)

So at that point, we could change the UI to make it a multiple selection and therefore support any number of lists at the same time.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

This dialog was designed per the spec from the UX team. The in-content preferences page doesn't use native dialogs, so many things are different than what one may expect in such a case, but it closely resembles popups in web sites. There are many similar dialogs in preferences, this one is not special.

Since native dialogs were ruled out, using a radio button was limited by the tree widget we use for these tables, but IIRC also to provide a better visual experience for potential add-ons that added blocklists. At least that is what UX decided to use for consistency.

I don't see anything actionable to do in this bug, so I'm going to resolve it. Once the service changes François mentioned are deployed we can ask UX to consider a multiple choice approach, but that is a separate question, better served by a new bug.

Comment 6

[Markus Stange [:mstange]]

Thank you for the explanation. My main concern was "why use a tree widget at all?", but if we plan to extend the list, it somewhat makes sense.

Comment 7

[Ed]

(In reply to Panos Astithas [:past] from comment #5)

Oh! UX team! I was asking myself who has decided to spoiled the normal interface some version ago.

Panos, can you, please, give me contacts of this UX team? 

> This dialog was designed per the spec from the UX team. The in-content
> preferences page doesn't use native dialogs, so many things are different
> than what one may expect in such a case, but it closely resembles popups in
> web sites. There are many similar dialogs in preferences, this one is not
> special.

I see several problems here: 
(a) page doesn't use native dialogs. Guys (in UX team, I guess), we do not need a handicap substitution for standard controls/dialogs because native control/dialogs are faster and take no space (my Firefox is SLOW because there not enough RAM) 
(b) pop-ups. The whole world was fighting against pop-ups for a decade by now, but some UX "specialists" still consider this as tolerable interface element. 

> Since native dialogs were ruled out, using a radio button was limited by the
> tree widget we use for these tables, but IIRC also to provide a better
> visual experience for potential add-ons that added blocklists. At least that
> is what UX decided to use for consistency.

I don't know (yet) what is IIRC, but the current visual experience is miserable: (a) one even does not see a placeholder of the check mark; (b) the check marks in the WHOLE options subsystem a huge and completely do not follow the system-wide settings chosen, probably because UX team think that Firefox is a special application, which is allowed to break the rules.

> I don't see anything actionable to do in this bug, so I'm going to resolve
> it. Once the service changes François mentioned are deployed we can ask UX
> to consider a multiple choice approach, but that is a separate question,
> better served by a new bug.

I see. 
Return native controls/dialogs, thus making Firefox smaller, faster and more functional.

BTW, native dialogs, especially such as options, can be totally data-driven. You do not have to write a dialog-function for each dialog, just one universal function, which will work with ANY options dialog by using a given data-structure describing which controls correspond to which variables/objects and, may be, how controls depend on each other. You will be amazed how compact your code will become.

Feel free to forward this message to UX team.

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

I understand that you don't like the design of the new in-content preferences. That's fair, we can't have unanimous agreement on every feature of a large application like a browser.

I don't think it would be constructive to go over every single point you make, but if you think that these were not considered in the implementation of the preferences page, you are mistaken. I am sure that you would come to the same conclusions if you tried to create patches that implement your proposal. If you do and get measurements that say otherwise, I'd be happy to review.