1130527 - [META] IOS-101 - Settings - Choose from the list of search providers loaded

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect, P2)

Comment 1

[Nick Alexander :nalexander [he/him]]

I am interpreting this as implementing the mock at [1], where the total set of search engines is the set that ships with the product.  That is, this ticket tracks letting the user select a default search engine, reorder the non-default search engines, and optionally disable the non-default search engines.

I am interpreting Bug 1130528 as tracking allowing the user to add /additional/ search engines (and to then allow reordering, disabling, and possibly customization of those additional search engines).

[1] https://mozilla.invisionapp.com/share/HA254M642#/screens/64313421?maintainScrollPosition=false

Comment 2

[Nick Alexander :nalexander [he/him]]

darrin: there is an interaction between the default search engine and the ordering/disabling search engine list.  You can even see it in your mock above: is it sensible to allow the default search engine to be disabled?  I believe no -- it is going to be very convenient to assume that the user has a default search engine that is not disabled.

I can imagine addressing this in a few ways:

* disable the toggle for the default search engine; or
* don't show the default search engine in the list of orderable search engines; or ...

If we go for the second option, we should reconsider the chevron that shows a list for setting the default search engine.  We can allow the user to drag a search engine between list sections; we might use this to allow the user to drag their preferred engine to the default slot (which does not show the disabled toggle).

darrin: what say you?

Comment 3

[Darrin Henein [:darrin]]

(In reply to Nick Alexander :nalexander from comment #2)
> darrin: there is an interaction between the default search engine and the
> ordering/disabling search engine list.  You can even see it in your mock
> above: is it sensible to allow the default search engine to be disabled?  I
> believe no -- it is going to be very convenient to assume that the user has
> a default search engine that is not disabled.
> 
> I can imagine addressing this in a few ways:
> 
> * disable the toggle for the default search engine; or
> * don't show the default search engine in the list of orderable search
> engines; or ...
> 
> If we go for the second option, we should reconsider the chevron that shows
> a list for setting the default search engine.  We can allow the user to drag
> a search engine between list sections; we might use this to allow the user
> to drag their preferred engine to the default slot (which does not show the
> disabled toggle).
> 
> darrin: what say you?

I originally thought about this interaction and love its simplicity, but aside from it being more complex technically, I wasn't confident that users would know to drag to another list/area to set a default. 

I think we should follow what desktop has done... a separate selection list for the default, and we should re-label the toggle list to "Quick Search Engines" or "One-touch Search Engines" (where you may in fact want to turn off the default in the quick-search bar).

Does that make sense?

Comment 4

[Nick Alexander :nalexander [he/him]]

Attachment: Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/187

I'm quite confident this won't be the final form for the UI, so I'm not going to write UI tests quite yet.

This allows to:

* Set the default search engine;
* Disable non-default search engines;
* Re-order non-default search engines.

The search engine state is persisted.

Comment 5

[Darrin Henein [:darrin]]

Comment on attachment 8570193 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/187

This is a nice combination! I noticed you can still drag from the bottom list to the top, which is a nice touch. A couple suggestions:

- set a background on the table cells, so you don't see through them when dragging (need this 100%)
- maybe highlight the cell in some way (we can set the background blue and text white) when hovering over the top "drop area", to indicate that an action occurs if you drop it there

I've attached two sketches, probably don't need them for launch but would be nice details.

Comment 6

[Darrin Henein [:darrin]]

Attachment: search settings - highlight.png

Comment 7

[Darrin Henein [:darrin]]

Attachment: search settings - dropzone.png

Comment 8

[Brian Nicholson (:bnicholson)]

Comment on attachment 8570193 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/187

Looks fine codewise.

Comment 9

[Nick Alexander :nalexander [he/him]]

Darrin -- love the design.  Unfortunately, it's really quite challenging to implement :/

(In reply to Darrin Henein [:darrin] from comment #5)
> Comment on attachment 8570193 [details] [review]
> Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/187
> 
> This is a nice combination! I noticed you can still drag from the bottom
> list to the top, which is a nice touch. A couple suggestions:
> 
> - set a background on the table cells, so you don't see through them when
> dragging (need this 100%)

Apple, in their magnificent wisdom, makes this challenging.  See http://stackoverflow.com/a/24687298 and http://stackoverflow.com/a/21041704.  I think we can do it, but I question whether we should subvert the standard UI paradigm on the device.

> - maybe highlight the cell in some way (we can set the background blue and
> text white) when hovering over the top "drop area", to indicate that an
> action occurs if you drop it there

Again, this is challenging.  There's little way to determine that re-ordering has started.  There are some undocumented but not private APIs, in theory -- see http://stackoverflow.com/a/10854018 -- or you can get a delayed event using http://stackoverflow.com/a/2014707.

> I've attached two sketches, probably don't need them for launch but would be
> nice details.

Comment 10

[Nick Alexander :nalexander [he/him]]

I landed this with review comments addressed, but without the tweaks darrin requested.  Those can be follow-up, although I'm not sure we want to do them at all.

https://github.com/mozilla/firefox-ios/commit/1921b566c3ca9a9486234c89ce6cc3ac6a146f6b