Hacker News new | past | comments | ask | show | jobs | submit login
Google's new related search box optimizes for the wrong metric (smitop.com)
93 points by smitop 72 days ago | hide | past | favorite | 40 comments



Layout shift. Google has an entire article [0] about why it's bad. But as this is likely never going away, I made a Chrome extension [1] (5 lines of code) that gets rid of the box.

[0]: https://web.dev/cls/

[1]: https://chrome.google.com/webstore/detail/remove-people-also...


For anyone with uBlock Origin already installed these 2 rules should be equivalent to what this extension is doing:

    google.com##div[id^=eob]:nth-ancestor(1):style(height:auto !important;)
    google.com##div[id^=eob]
Though "auto-genned div starts with eob" seems unlikely to last forever as a reliable method (Google News recently changed the div naming structure as an example). has-text():nth-ancestor(n) would be more reliable but a slightly less performant rule.


Still more performant than misclicking your link. We are in the evolutionary battles era of the internet for a long time already. To open an article you usually have to click in a right place, scroll past the image, close the popup, close the popdown, scroll past blocked ads box and click on “read more” wrapper, ignoring that flashing “ask us a question” assistant, and when you move your pointer away from text, close another “wait don’t leave” popup. Worrying about a rule inefficiency is not sensible anymore.


For personal rules probably not important but because you won't have many not because there is an even worse option you could have chosen.


They should've made the example GIF out of Related Search Box if they were serious enough about it.


There you go: https://twitter.com/sephr/status/1286058848063614977 :)

A few months ago I almost rant about the same "people also search for" box on twitter but wanted to do my homework first. So I learned about layout shift, how google itself explains it's bad UX, also that it's not a new issue, complaints were made since at least 2019. In above link, Addy Osmani (from Google) replied he submitted an internal bug report to Google search (July 2020). So obviously Google knows about this but somehow decided not to fix the UX.

Nowadays we start having tools to detect and measure layout shift in the browser. So, when it happens that a layout shift replaces the element under the cursor just before a click is triggered, considering the typical reaction time of the user, it's not so hard to imagine what a good browser could do there. If the layout shift was not initiated by the user and we have a click triggered <100ms later, well, most probably they actually wanted to click on the thing that was previously there but that got displaced. But for the browser to notice this it would need some sort of record of the layout changes to know what was where and when. So another way could be to just ignore any user interaction for like, a second, on the elements affected by a layout shift after it happens. Would it be too harsh, break some websites? I don't know but I bet it would prevent a lot of those "misclicks"...

Also, "misclick" sounds like it's a user mistake but at this point I feel more like it's some sort of click hijacking where some js knowingly replaces your click target with another one once it's too late for you to stop your finger to actually trigger the click. There's no guarantee it will work for one specific user, but at scale, well, do some A/B testing to measure the average time to click on A and then setup B to replace the expected link target 50ms before to the average click happens, done! Pretty sure it wouldn't be so hard to optimize ;) (Ethical you say? Shuuuush!)


> someone at Google is probably looking at the results of their A/B test and thinking “Wow, this new feature is great. Look at how many people are using related searches when they can’t find what they’re looking for!”

I was under the impression that the someone at Google knew full well what they were doing and had no misconceptions about the ratio of unintended to intended feature use, but were also savvy enough to know what their manager or whoever is reviewing their promotion packet would likely just see a high usage rate and not dig into why it existed.


Agreed, this box is really just annoying and I've never found it useful because it shifts everything down after the first paint, so you wind up clicking on a pop-up.

I wish they'd delete it, and also wish the search box would steal the common feature from IDEs like Atom or VS Code, where you can highlight stuff and hit the " quote button to wrap it in quotes, for example. Maybe only a small subset of users would want to treat the search box like an IDE but it could shave a few seconds off searches when you need to wrap stuff in quotes. Just a random unrelated idea!


I have wanted this too, and your comment inspired me to write a script[0]. I plan to submit extensions for chrome and firefox when I find some time.

[0] https://gist.github.com/bearr/05f4b41478acb1fdd3b58583d5e30c...


This box is absolutely infuriating and frequently comes up for me using the repro steps in the article.


How are you able to reproduce this? I didn't see steps in the article and I haven't seen this appear, but now I'm curious.


The first paragraph of the article:

> When using Google, I sometimes look at a result, then go back to the results page to check another result. When I go back, Google sometimes pops up a box with related searches around the result:

1) Search something

2) Click on a result

3) Press the back button

4) Go to click on the next result, only to have it pushed out of the way at exactly the perfect time.


Ah thanks, for some reason I didn't parse that properly.

Able to replicate it reliably now.


After repeatedly updating user styles to remove that box from my google search results, I gave up and moved to Bing. The result quality has been great and the result pages are much better (less wikipedia-link-hiding than google). Plus I get tens of dollars in gift cards a year.


Yeah. I swear Google has been burying Wikipedia as hard as it possibly can. Most of the top so-called "organic" results nowadays are commercial sites full of ads. Every year, Google squeezes more value out of their search engine at the expense of users. In the long run this should open the door for competitors to build a better product.

Personally, I want to see an open source search engine. The world desperately needs community-run search that helps users find real information and real communities while filtering out all of the spam and other commercial garbage that has been gradually strangling the web over the past two decades and a bit.

I think some of the pieces are already in place to do this. Community-run blacklists for plugins like uBlock Origin are comprehensive and well-maintained. A repository of crawled pages is already available from Common Crawl [1]. What we need is a search engine that makes use of these resources to index and rank results so that pages without ads and without obnoxious heavy Javascript are pushed to the top of the results page. Ideally, this engine would allow users to run NoScript and have a really smooth experience searching for and browsing clean sites without having to add stuff to their whitelist all the time.

[1] https://commoncrawl.org


If you're on chrome and have visited wikipedia before, it will let you search it directly. In a new tab, I type "en", which autocompletes to "http://en.wikipedia.org/", then press tab to move forward one UI element, highlighting "Search Wikipedia (en)" then type my search string.

I have a bunch of the autosuggest and omnibar stuff turned off though, I don't know how well this works on a stock install.


Whereas on firefox I just added a search shortcut for "wp" that sends the rest of what I type into Wikipedia's _own_ search. I used wp since I don't care about Wordpress, but you could always do just w, wiki, or whatever.


That undiscoverable, hard to learn behavior is a poor excuse for search engines hiding what should be the first and most prominent result.


Community-run blacklists for plugins like uBlock Origin are comprehensive and well-maintained

I think that blacklists are opposite to search in a sense. Naive search is an easy target for those who try to game its results in an endless arms war. Ads and annoyance listings are not, because those who want to game it would a) delete the specific rules and get catched by feedback, b) add rules to downplay the opponents and also get reported. In a search, there is hard to say who played low, because everyone will do that.

I think “we” should resurrect directories instead of a search, which already presented itself as nonsense in a long run for too many times.

A directory is a categorized collection of links with a meaningful description (opposed to in-site bs marketing claims which these sites have to do no matter what) and few curated comments. E.g. awesome lists out there:

https://github.com/vinta/awesome-python

https://github.com/quozd/awesome-dotnet

https://github.com/avelino/awesome-go

https://github.com/awesome-selfhosted/awesome-selfhosted

… think awesome cars, awesome appliances, awesome socks, awesome instruments, awesome food etc. Every area has some interned knowledge which waits for a platform to post it on. There will be ads push force just like with search, but at least it would be controlled by community, not by faceless moremoney entity. The difference with search is that search is automated and thus is much more vulnerable to ranking tricks. You can then run very naive search over this curated data and get good results.

Also it would shift trust from sites (which you want to find out to trust or not in the first place) to people who pull-request links into a directory. You never know which of SERP results made by whom. In a directory, you can see who posted what and what their rating or age of participation is. This is inevitable because in a modern world trust can only be built with time to a person, and there is no good will except of someone real who got tired of the shit so much that they are ready to go to lengths to explain/advise/help others and get it back eventually (that’s the core of the foss idea). No corp can align with what we want anymore, because their competition is always better at money, and at SERP. There is simply no other way, in my view.


Setting my Firefox to search via DuckDuckGo years ago now leaves me just to read about these new dark patterns, rather than having to experience them in person. There is often much discussion about 'the quality of results od DDG' but back then after a few days I had no issues with DDG and now after a few years I find Google search results and layout just strange. Fully recommend.


The great irony is that Google of all companies should know this is poor UI design.


Of course they know this is poor UI design. It's on purpose because it makes mega bucks and hundreds of millions of dollars at google scale

Bad UI makes money by tricking people into clicking on links. It's a well know fact, and Google would not be as big of a company as it is now without the poor ui design that makes them money.


Look boss, we have amazing click through on our new related search box - huge success!


Exactly. Post title is wrong, it optimizes for more clicks and ads served, which is Google’s incentive.


They manifestly don’t care. Their UIs tend to be poor. If they cared the UIs would improve.


I've also had this experience with Google Ads- they pop up a second after all results right where I'm about to click. And someone's paying for that click somewhere


This actually pisses me off so much. It's one of the cardinal sins of UI/UX as far as I'm concerned.

I assumed it was intentional, could it really be accidental?


Doubly annoying as they have gone out of their way to penalize sites they index for layout shift.


Don't find it very intrusive, it might be useful to someone who clicked back on specific searches that turned up a result the person wasn't looking for. I see what they're going for. Also, barely noticable when runs smoothly/loads fast. It will be removed when they see it not getting that much use, I'm fine with them A/B testing something new. Overreactions and anti-google/ublock paranoia.


> It seems like the box is perfectly timed to come up at just the right time to get me to accidentally click it while trying to click on the result below.

I wonder if it's intentional, since the timing is so perfect. I poked around with inspect element, but the JS is both obfuscated & beyond my skill level.


In my products one way I've tried to fix the UI jumping around when a separate network call responds is to add a facebook-style "shimmer" view while it loads. But that doesn't work when the box might be hidden based on the network response.


Another approach is to show the box further down the page (the part of the page that is not yet visible on the view port). Assuming that the request latency is low, the box will be fully loaded when user scrolls to it.

I found combining both the shimmer UI approach and this usually makes the injection of dynamic content less disruptive to user flow.


Or just leave it empty and never change its size. It may look strange, but our fear of technically correct “nothing wrong” ways is irrational. Many useful services are so much more broken than that, but still are used because of the value they provide.

And we tend to ignore this in real world, so it’s really just the designer’s OCD. When an information/ads stand is half-empty, when roads are padded with safety zones, when spatial configuration of anything real is technical, then nobody notices. But when the same happens on a site, every figma guy goes mad about the extra space it takes.


I remember a previous comment here on HN with a filter for ublock (or a similar blocker) that removes that suggestion box. I now use DDG but when I need to switch to Google you notice really quickly if the script is there or not.


The longer uBlock Origin rule in https://gist.github.com/mmazzarolo/34e5418aade64abe7618885e0... takes care of it, currently

  ! Hide the 'People also search for' slide-in box when going back on Google Search.
  ! We require the other attributes here to reduce the risk of false positives.
  www.google.com#$#div[id^=eob_][jscontroller][jsdata][jsaction][data-ved] { display: none !important; }


When you do this (and I highly recommend doing it! using ad-blockers as crap-blockers is one of my favorite things about browsers!), please leave feedback somewhere! Otherwise you're nothing more someone that simply doesn't engage with a feature. That's unlikely to do much to help shift behavior away from building crap, as it's not negative feedback in most cases - unused things are generally assumed to be harmless.


I think 'give negative feedback to google' is easier said than done?


Getting a result: definitely.

But there are free-form feedback fields all over nearly every Google product. Submitting feedback is generally very easy. E.g. on my phone, going to https://google.com -> scroll to the bottom of the page -> feedback link which gives me a text field. On search result pages I don't get a feedback link on mobile, but it's down there at the bottom on desktop.

The same is true on Gmail, Google play, YouTube, Drive, basically everything. In less common cases, it's on the first page of the "help" link. On mobile apps, it's often in the hamburger menu.


Thank you


They are likely to get penalized, thanks to the CLS metric.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: