Tails

#2 Updated by kytv 2015-08-06 10:52:33

I created Bug #9932 for the general UX issues with the search bar.

I wouldn’t have created it if I had seen this one beforehand (I didn’t see it arrive in my email). Maybe my ticket should be closed as a duplicate but I’ll let someone else make that call as it’s slightly different.

#4 Updated by mercedes508 2015-08-07 05:48:29

kytv wrote:
> The UX is especially bad in non-EN locales. For example, in French you’ll have two identical icons for Wikipedia. You can hover over the icon to get a tooltip to distinguish between identical icons but that’s not very nice.
>
> Perhaps we should set the option browser.search.showOneOffButtons to False in Tor Browser and/or convince upstream (TBB or Firefox) to do it.

#5 Updated by anonym 2015-08-07 11:46:43

kytv’s fix, browser.search.showOneOffButtons = False looks like tempting, easy fix to me since it reverts back to what has been working for us until now. While the new search engine selection tool looks prettier, it sacrifices usability since it requires you to know the logos of the search engine. Icon + text is simply more helpful.

#6 Updated by anonym 2015-08-07 11:55:15

Ah, I just noticed another bad thing with the new search bar: The selected search engines is actually not changed by one of those icons, instead a one-off search is made using the clicked search engine. The next one will be made with the default one (i.e. localized Disconnect in Tails) again. To change this, one must go through the options and change the default. I think this is especially awkward in Tails, where users probably quite often switch from their localized Disconnect to the English one, or to DuckDuckGo,

#9 Updated by intrigeri 2015-08-08 01:38:46

> Ah, I just noticed another bad thing with the new search bar: The selected search engines is actually not changed by one of those icons, instead a one-off search is made using the clicked search engine. The next one will be made with the default one (i.e. localized Disconnect in Tails) again.

I like it very much to be able to do a one-time specialized search without replacing my default, general purpose search engine, with a specialized one. The lack of this behavior has made me refrain from using non-default search engines in Firefox for ages. For me it’s an improvement that is almost worth the regression this ticket is about.

> I think this is especially awkward in Tails, where users probably quite often switch from their localized Disconnect to the English one, or to DuckDuckGo,

I understand that this new behavior in Tails is problematic for those who prefer to use a non-default search engine by default. But perhaps that’s a corner case, while the vast majority of users would be happy as I am with the new behavior.

Perhaps we should try disconnecting these two problems from each other: we can perhaps fix this ticket without diverging from Tor Browser by reverting to FF31 behavior. I mean: these icons come from somewhere, and in FF31 there were localized icons with flags. Were did they come from (Tor Browser localization packs? iceweasel-l10n-*)? Why was the flag removed in their source? (Even though national flags are a poor indication for language, and would be better replaced by the N-letters code that’s before .wikipedia.org.)

I suspect that this all comes from the fact that we’re injecting stuff from FF31 (via iceweasel-l10n-*) into FF38. I wonder what would happen if we fetched these iceweasel-l10n-* localization pack from current sid, that has FF38.

#10 Updated by sajolida 2015-08-08 07:34:33

For what it’s worth, I follow intrigeri on the UX of the new search bar (one-time specialized search). But yes, in the context of Tails it has rough edges as it will piss of people who prefer DuckDuckGo by default.

#11 Updated by anonym 2015-08-08 07:40:10

intrigeri wrote:
> > Ah, I just noticed another bad thing with the new search bar: The selected search engines is actually not changed by one of those icons, instead a one-off search is made using the clicked search engine. The next one will be made with the default one (i.e. localized Disconnect in Tails) again.
>
> I like it very much to be able to do a one-time specialized search without replacing my default, general purpose search engine, with a specialized one. The lack of this behavior has made me refrain from using non-default search engines in Firefox for ages. For me it’s an improvement that is almost worth the regression this ticket is about.

Fair enough…

> > I think this is especially awkward in Tails, where users probably quite often switch from their localized Disconnect to the English one, or to DuckDuckGo,
>
> I understand that this new behavior in Tails is problematic for those who prefer to use a non-default search engine by default. But perhaps that’s a corner case, while the vast majority of users would be happy as I am with the new behavior.

Perhaps. I suppose we can only speculate.

> Perhaps we should try disconnecting these two problems from each other: we can perhaps fix this ticket without diverging from Tor Browser by reverting to FF31 behavior. I mean: these icons come from somewhere, and in FF31 there were localized icons with flags.

Really? I just booted 1.4.1, and for German there’s no localized icons. The only localization is in the text next to the icon, e.g. “Wikipedia (de)”, and the issue is that in ESR38 there’s no such text (but the same text is in the tool-tip, but that’s too awkward IMHO). Or am I misunderstanding you completely?

> Were did they come from (Tor Browser localization packs? iceweasel-l10n-*)? Why was the flag removed in their source? (Even though national flags are a poor indication for language, and would be better replaced by the N-letters code that’s before .wikipedia.org.)
>
> I suspect that this all comes from the fact that we’re injecting stuff from FF31 (via iceweasel-l10n-*) into FF38. I wonder what would happen if we fetched these iceweasel-l10n-* localization pack from current sid, that has FF38.

Just to be sure I checked the sid package for the de locale/language, and the icons are not localized there either. In fact, the icon is changed to a huge one spelling out “Wikipedia” completely. I’m not sure how that will look… :S

I’m not sure where this puts us vs resolving this ticket. I kind of still feel like reverting back to ESR31’s search plugin bar is preferable. I don’t think it matters too much that we deviate from the normal Tor Browser here, especially since this was the behaviour in both their and our Tor Browser until now.

#12 Updated by anonym 2015-08-08 07:41:52

Crazy idea: we could generate localized icons ourselves using imagemagick… yay. :)

#13 Updated by kytv 2015-08-08 07:52:04

intrigeri wrote:

> I like it very much to be able to do a one-time specialized search without replacing my default, general purpose search engine, with a specialized one. The lack of this behavior has made me refrain from using non-default search engines in Firefox for ages. For me it’s an improvement that is almost worth the regression this ticket is about.

An extra data point: xul-ext-searchload-options is a way to achieve this but of course that would increase the delta with TBB.

#15 Updated by BitingBird 2015-08-08 09:03:41

Could we suggest upstream to improve the localized icons instead ?

#16 Updated by intrigeri 2015-08-08 09:10:02

> Still, this will be quite complex as we’ll have to base64 encode them and somehow stick them back into the .xml:s at the correct places. Urgh. Instead we should probably should just generate the wikipedia plugins ourselves from scratch and skip the ones from the iceweasel localization packages.

I like these icons, good job! However, it sounds like there’s more work remaining to do to make use of them than what this minor regression is worth.

So if someone is excited at the idea of completing this work with whatever milestone they want, fine. Otherwise, I say it’s low priority, patches welcome, and the status quo is good enough.

To end with, given anonym proposed on IRC to go back to ESR31 behavior for 1.5: I beg to disagree. This specific regression comes with something that sajolida and I see as a UX improvement; I’m very much unconvinced that fixing this regression is worth getting rid of the improvement.

#17 Updated by intrigeri 2015-08-08 09:10:33

> Could we suggest upstream to improve the localized icons instead ?

This would be the best, I think, indeed. anonym what’s the upstream we use for these search engines?

#18 Updated by anonym 2015-08-08 09:19:29

intrigeri wrote:
> > Still, this will be quite complex as we’ll have to base64 encode them and somehow stick them back into the .xml:s at the correct places. Urgh. Instead we should probably should just generate the wikipedia plugins ourselves from scratch and skip the ones from the iceweasel localization packages.
>
> I like these icons, good job! However, it sounds like there’s more work remaining to do to make use of them than what this minor regression is worth.

Perhaps, but…

> So if someone is excited at the idea of completing this work with whatever milestone they want, fine. Otherwise, I say it’s low priority, patches welcome, and the status quo is good enough.

I’m not really, but…

> To end with, given anonym proposed on IRC to go back to ESR31 behavior for 1.5: I beg to disagree. This specific regression comes with something that sajolida and I see as a UX improvement; I’m very much unconvinced that fixing this regression is worth getting rid of the improvement.

Ok. I still disagree. I’ll try to implement the generation of localized icons to make this disagreement moot.

> > Could we suggest upstream to improve the localized icons instead ?

Definitely, but it won’t help us now, for the 1.5 release. :/

> This would be the best, I think, indeed. anonym what’s the upstream we use for these search engines?

They come from the iceweasel-l10n-* packages. I’m sure whatever code I come up with for Tails can be contributed upstream with just a bit of massaging.

#19 Updated by anonym 2015-08-08 11:07:30

I got my way. We’ll revert to ESR31’s search bar for Tails 1.5 (via browser.search.showOneOffButtons = False) and make sure to reintroduce the ESR38 search bar in Tails 1.6 together with localized Wikipedia search engine plugin icons => Feature #9951, Feature #9955

#27 Updated by anonym 2015-08-09 05:40:31

Due to the extensive positive testing of Feature #9955, we’ll go that way immediately in Tails 1.5, so the ESR38 search bar will not be disabled (which was Feature #9951, and we skip merging bugfix/9931-revert-to-old-search-bar).