Make filter list URL configurable in release builds

[mario]

Background

This issue is based on #3241 which introduces the possibility to load a custom filter list via URL. This feature was implemented for usage in development builds only. However, we decided to make this feature public and thus enable it for release builds. In order to make it more accessible, we need to amend the UI.

What to change

1. Remove limitation

• Make the settings item "Configure Filter List" as shown in this screenshot and its settings page available throughout all builds (not only development builds)

2. Amend UI
Within "ABP -> Settings" apply the following changes as shown in this screenshot:

• Change the button Configure Filter Lists to Filter Lists
• Add a iOS default right arrow to the "Filter Lists" button
• If the default filter list is used, display Default as secondary text of the "Filter Lists" button
• If a custom filter list is used, display Custom as secondary text of the "Filter Lists" button

Within "ABP -> Settings -> Filter Lists" apply the following changes as shown in this screenshot:

• Remove the control "Default Filter List"
• Change the Headline OTHER FILTER LISTS to The default filter list used is based on EasyList. You can specify a different iOS content blocking filter list to use below
• Change the label Custom Filter List to Use Custom Filter List
• Add Filter List label in front of the custom filter list input field
• Remove the button Update Filter Lists

3. Amend logic

• "Use Custom Filter List" is turned off by default
• If "Use Custom Filter List" is turned off (as shown in this screenshot)
  • Hide the "Filter List" input field
• If "Switch Filter List" is turned on (as shown in this screenshot)
  • Show the "Filter List" input field

Any other logic as derived from #3241 stays in place

[pavelz]

If i understand the proposal right, without the not yet provided designs, it changes the logic from "or" (both default and custom possible) to "exclusive or" (either default or custom possible). I guess you want to avoid malfunction reports from users mixing up your stable filter list with custom questionable creations "from the wild".

Technically on the backend, it's a simplification of the existing logic, so to close the thought from weekly call: this is still not much effort on our side and could be done fast enough to not inflate ABP release schedule. Detailed design screenshots still needed though.

[mario]

If i understand the proposal right, without the not yet provided designs, it changes the logic from "or" (both default and custom possible) to "exclusive or" (either default or custom possible). I guess you want to avoid malfunction reports from users mixing up your stable filter list with custom questionable creations "from the wild".

Exactly. I'm not so much concerned about mixing filter lists but rather about the fact, that we'd easily exceed the 50k rules when we allow to enable two lists at the same time.

Detailed design screenshots still needed though.

I'll be able to provide screenshots asap.

[pavelz]

Sorry but this design is overcomplicated and breaks several ios design rules.

1. Misuses checkmark element. Applied correctly to "one of many" idiom, but the options are not grouped together AND one option is not even visible all the time, so the idiom is lost. See e.g.

​https://developer.apple.com/ios/human-interface-guidelines/ui-views/tables/

2. Checkmarks are supposed to be active - clickable (it's called "disclosure indicator"). You can expect users clicking it and be confused about it not doing anything. If the switching task is taken by the extra switch, the table rows with checkmarks are technically just labels. Is there a reason for it to be designed as active elements?

3. The switch is called "Switch X" where X does not imply either of the available states. What does it mean when such switch is off? That the switching cannot happen? Why the switch cannot be named "Use Custom Filter List" ? That's what is getting switched, isn't it?

Proposal, default state:
Line 1: The Default Filter List is based ... [plain text label]
Line 2: Last Update: XXX [plain text label]
Line 3: Use Custom Filter List [switch]
Line 4: Update Filter List [clickable]

Upon switching:
Line 1 and 2 greyed out
After line 3 inserted
Line 4: Filter List [textfield entry]
Line 5: Last Update: XXXX [plain text label]
Line 6: Update Filter List [clickable]

[jeen]

Hi, I've modified the design based on your suggestions. Before proceeding I have some questions:

• Configure 1.0.png: Is it possible to add text stating which filter list is active - i.e. 'Default' or 'Custom'?
• Configure 1a.png: @lisabielik can you please review the description text at the top of the screen: 'The default filter list used is based on EasyList. You can specify a different iOS content blocking filter list to use below.'

Some context for you @lisabielik: A user on the ABP content blocker app for Safari can only use one filter list at a time. The default filter list is a based on a version of EasyList. We have added a new feature which allows power users to use a different iOS content blocking filter list (e.g. one from Crystal instead of the one provided by us)

[pavelz]

Configure 1.0.png: Is it possible to add text stating which filter list is active - i.e. 'Default' or 'Custom'?

Sure, that is a common iOS UI pattern.

Two more issues though:

1. The button "Update Filter Lists" and label "Last Filterlist update" is duplicated, in the main menu and in the filterlists submenu. Since there can be only one filterlist at a time now, the two occurences do the same thing and display the same thing. Decide a single place where it should be now. The two places had a purpose previously, when there could be the default list at the same time as the custom one - added together. So the main menu button was updating both, and filterlist submenu just the custom one. This separation is gone now.

2. Regarding custom filterlist URL entry field: do not stuff any additional labels in there. The field needs to be as long as possible. Follow the original design, i.e.

https://issues.adblockplus.org/attachment/ticket/3241/Adblock%20Plus%20iOS%20settings%20configure%20filter%20list%2020-1-1.png
https://issues.adblockplus.org/attachment/ticket/3241/Adblock%20Plus%20iOS%20settings%202%20layers%20step%203%2020-1-1.png
The initial grey hint text is called "placeholder" and is a standard iOS feature.

[jeen]

In that case, I would:

• Remove the update filter list from the "Configure Filter List" screens, and just keep it on the main menu.
• Remove the text label within the custom filterlist URL entry field.

Lisa is still going to review the final version of the text, but the UI elements should now be resolved. The latest designs can be seen here: ​https://invis.io/JS9M6A3TD.

[mario]

Changed the description to reflect the discussed changes and added the new mockups.
@jeen, @pavelz, LGTM?

[pavelz]

@mario @jeen LGTM though i would prefer having the Update button and the timestamp label inside the filterlist dialog - there is enough space, while the main menu is quite long already. But i'm not going to argue over your decision.

Now i'm going to wait for Lisa's approval of the texting.

[mario]

LGTM from Lisa via InVision regarding text changes. Ready from our side. @pavelz, @jand, feel free to mark this issue ready if no further information is missing.

[mario]

Updated the description to reflect further text changes.

[jeen]

I have updated the following elements in the design which can be found here: ​https://invis.io/JS9M6A3TD

Updates:

• Moved 'Update Filter List" and "Last filter update..." to the Filter List screen.
• Separated out BLOCKING and FILTER LIST into 2 sections.
• Included a text description under the BLOCKING setting.
• Still finalising copy for the "Blocking" setting.

[mario]

@Jeen, as separating the filter list section form the BLOCKING group is not necessarily bound to this feature, I'd separate this into a separate issue.

Moved 'Update Filter List" and "Last filter update..." to the Filter List screen.

Updated issue & screenshot. Both options have been available from the settings overview before, so no changes needed there.

Separated out BLOCKING and FILTER LIST into 2 sections
Included a text description under the BLOCKING setting.
Still finalising copy for the "Blocking" setting.

Will be handled in a separate issue as soon as the copy is ready.

[mario]

Ready from our side.