Disabling automatic collection of search engines - followup discussion from bug tracker

[Hubert]

Hello

Because a dev has locked the comments under relevant bug report (https://code.google.com/p/chromium/issues/detail?id=68177) I'm going to attempt to take the discussion here. While understanding that developers are busy people and don't have all day to argue with users, I would hope that he (as well as others) won't turn back on the issue that caused relatively significant number of people - as far as bug reporting goes - to state their problem. So, to start from answering the points from the last comment.

> The bug tracker is a work planner for developers, not a debate forum. Arguing with a decision here rarely makes us more likely to reverse course.

I was about to place here a rant about how nothing can ever get ivory tower developers to reverse course and how the only rationale given is "we know better"... But okay, regardless of how I feel about the attitude here, I understand that this request would need a work put into it that can be put elsewhere. I hope this list will be deemed a better place for attempting to prove the issue's importancy.

> Also, considering Google doesn't log the search engines you have stored locally, I don't see what rationale would explain the conspiracy theory in comment 17.

That was merely a guess stated on my part, based on the fact that the issue clearly affecting a number of users has been shunned so quickly and without any consideration given.

> we don't provide (for example) an options-menu checkbox to disable disk caching or a table where you can list different user agents you want to send to particular sites or a toggle
> between Firefox-style and IE-style GIF animation timings.

I don't know if it's intentional reductio ad absurdum, or if you really think these issues are of the same level. Nontheless, this comparison is faulty. Disk caching and GIF animation timings don't cause a bloat in user interface, auto-adding search engines that user knows from the start he/she doesn't want them does. That's pretty much the point here: the design rationale given is incosistent. The proposition of adding an option is rejected on the basis that options cause bloat. If a multitude of search engines that need to be manually removed are not bloat then I don't know what is. If anything, trading all this bloated space for one switch - even if we agree it's a bloat, too - seems like a huge step forward in actually reducing the UI bloat.

> In general, the route we prefer to go for niche cases is to try and support them via extensions.

I'm curious, what makes you qualify this case as "niche"? There are certainly many more popular ones, but a quick check - didn't find tools in adv. search to make an accurate statistics, sorry - tells me that issues on Chromium bugtracker rarely get starred more than 10 times, almost 20.

> We would probably not be opposed to an extension API to control the search engine database if there were clear and compelling use cases
> for it ("delete all my engines" alone would not be enough).

Okay - so you won't provide an option requested, and the reason for the option isn't compelling enough to enable people to code it themselves. Am I reading this correctly?

Regards,

Hubert

[Peter Kasting]

On Thu, Oct 4, 2012 at 12:19 PM, Hubert <hubert....@gmail.com> wrote:

I hope this list will be deemed a better place for attempting to prove the issue's importancy.

It is.  Thanks!

> Also, considering Google doesn't log the search engines you have stored locally, I don't see what rationale would explain the conspiracy theory in comment 17.

That was merely a guess stated on my part, based on the fact that the issue clearly affecting a number of users has been shunned so quickly and without any consideration given.

There was already more than one comment on the bug about our reactions to different people's comments, and why we were closing the overall bug.  I'm not sure what more we could do to convince you that we did, indeed, give consideration to the bug.

I'd also like to note that we gauge how users are affected in a number of ways, including posts in our help forum, automated metric tracking, user studies, our own UI analysis of how bad a problem is, and yes, eventually, stars on a bug -- though the last is almost always discounted because bug tracker use doesn't tend to correlate to typical user concerns (people on the bug tracker tend to be more technically competent among many other reasons).  None of these metrics indicate this is a serious problem.  Certainly there are multiple people posting on this bug.  But that's not unique to this bug; probably every possible request you could imagine has been levied in some bug or other and there are usually at least a few people who agree.  For better or worse that's a natural result of having hundreds of millions of users.

> we don't provide (for example) an options-menu checkbox to disable disk caching or a table where you can list different user agents you want to send to particular sites or a toggle
> between Firefox-style and IE-style GIF animation timings.

I don't know if it's intentional reductio ad absurdum, or if you really think these issues are of the same level.

Actually, I think the table of different UA strings and maybe the ability to disable disk caching as well would both be more useful than the option requested on than this bug.

 

Nontheless, this comparison is faulty. Disk caching and GIF animation timings don't cause a bloat in user interface, auto-adding search engines that user knows from the start he/she doesn't want them does.

Disk caching fills your filesystem with files you don't necessarily want.  However, it does it in a place that you don't usually care about.  If you want to go peer through the cache file and get annoyed at the things there, that's fine, but we're not going to care much about making you happy.

The search engine list in the options is meant to be a similar place.  We give people rudimentary tools to manage the list but we don't expect or desire people to do tons of curation of that list or even look in it in the first place.  With a few notable exceptions, there is basically no downside of having a large number of items there, other than for folks with OCD tendencies who feel a compulsion to clean up the list once they see it.  I sympathize with this last, since I have OCD tendencies myself.  But it doesn't rise to the level where we're going to add options for this.

 

The proposition of adding an option is rejected on the basis that options cause bloat. If a multitude of search engines that need to be manually removed are not bloat then I don't know what is.

Use the word "bloat" carefully.  The space the list takes in the UI and the cognitive complexity of its use and how it interacts with the surrounding options doesn't change whether the list is empty or full.  Furthermore, there's no additional code complexity, testing burden, string translation, download bytes, etc. incurred -- all of which are costs of adding options.

As I already said on the bug, the cost of a single option is small.  The cost of many options is large.  Saying no to the former is how we avoid being hit by the latter.

> We would probably not be opposed to an extension API to control the search engine database if there were clear and compelling use cases
> for it ("delete all my engines" alone would not be enough).

Okay - so you won't provide an option requested, and the reason for the option isn't compelling enough to enable people to code it themselves. Am I reading this correctly?

Alone, no, this is likely not a sufficiently broad or interesting use case to justify an extension API.  But I don't own extensions so I don't really have a definitive answer there.

I hope you will forgive me if I don't end up contributing much more (if at all) to this thread.  There isn't much beyond what I've said here (and, indeed, was already said on the bug) that is useful to contribute.  I'm sure you will continue to disagree with the decision not to provide this option, which is fine; I suspect there's nothing I could really say to change your mind.

PK

[Hubert]

Thanks for answering anyways. I don't mean to waste your time, so I'll reduce my responce to a necessary minimum.

There was already more than one comment on the bug about our reactions to different people's comments, and why we were closing the overall bug.  I'm not sure what more we could do to convince you that we did, indeed, give consideration to the bug.

If it may be of any help to give a user perspective on this - none of the comments were relevant enough. The issue is: search engines list is bloated with unwanted entries. The anwers:

- state that it's easy to remove a single entry (but not to sort out the custom ones!)

- propose to ease the removal by reducing it to manually selecting one option at the end of each browsing session (and if it's not used, the autoadded search engines can't be automatically distinguished later)

I understand that developers would be at least remotely interested in providing the second resolution from the two above, but that amounts to replacing one troublesome procedure with another, arguably less troublesome, whilist providing additional _option_ anyways.

 

Actually, I think the table of different UA strings and maybe the ability to disable disk caching as well would both be more useful than the option requested on than this bug.

As a user, you would be at least partially satisifed here, cause UA strings are covered by extension API and there are extensions for it (I use one myself).

 

The search engine list in the options is meant to be a similar place.  We give people rudimentary tools to manage the list but we don't expect or desire people to do tons of curation of that list or even look in it in the first place.

I would understand this from the design perspective - if not for the fact that user can add a custom search engine and it's managed in the same list. I mean, someone may certainly don't _want_ disk cache to run, but there is no reason to look at it, least manage it, other than pure curiosity. For the search engine list, user is compelled to go there and use it because he has a reason - he added few entries himself, he knows they are here and knows when he doesn't want them. You may have point that it's a relatively rare case, but it is justified by features already offered in a browser and not just a whim like manually managing disk cache (yeah, I agree it's a whim).

  

I hope you will forgive me if I don't end up contributing much more (if at all) to this thread.  There isn't much beyond what I've said here (and, indeed, was already said on the bug) that is useful to contribute.  I'm sure you will continue to disagree with the decision not to provide this option, which is fine; I suspect there's nothing I could really say to change your mind.

That's most likely correct - I can't imagine how could I like a feature that is so troublesome to me. But on the opposite, I would humbly request that you extend your contribution to stating if there can be anything done to answer the issue. I'm talking about e.g: if proposing a complete patch would change anything, what can be done to justify an extension API etc. Anything that would not involve changing a browser (i'm not making a "threat" or anything, just a qualifier).

Regards,

Hubert

[Peter Kasting]

On Thu, Oct 4, 2012 at 1:48 PM, Hubert <hubert....@gmail.com> wrote:

I'm talking about e.g: if proposing a complete patch would change anything,

We would reject such a patch.

what can be done to justify an extension API etc.

That I don't actually know offhand.  I would start here: http://dev.chromium.org/developers/design-documents/extensions/proposed-changes/apis-under-development .  Once you have a formal proposal that needs review, you might try contacting Aaron Boodman (aa) or Erik Kay (erikkay) about next steps, as the links on that page to "extension review meeting" look to be internal-only.

PK

[Synetech]

On Thursday, October 4, 2012 3:19:08 PM UTC-4, Hubert wrote:

Because a dev has locked the comments under relevant bug report (https://code.google.com/p/chromium/issues/detail?id=68177) I'm going to attempt to take the discussion here.

 

Maybe you should have asked why the made this auto-addition behavior in the first place. I’d love to see the discussion and rationale they came up with for such a meaningless and useless function (I suspect one of the devs thought it would be useful to themselves for some reason and so they forcibly implemented it for the whole world).

Anyway, they closed issue 68177, blaming issue 87685, and then they closed 87685, blaming 68177. Clearly they have no desire or intention of cleaning up this mess they created. They made a mistake and instead of owning it and fixing it, they just stick to their guns and keep stubbornly trying (and failing) to justify it.

I can’t wait until I can export my browsing data and leave Chrome for something else (Opera is now Chrome which rules it out, so probably Firefox though even IE is better than Chrome now).