Google's new related search box optimizes for the wrong metric
smitop.com
smitop.com
[0]: https://web.dev/cls/
[1]: https://chrome.google.com/webstore/detail/remove-people-also...
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.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!)
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.
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!
[0] https://gist.github.com/bearr/05f4b41478acb1fdd3b58583d5e30c...
> 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.
Able to replicate it reliably now.
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.
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.
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.
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.
I assumed it was intentional, could it really be accidental?
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.
I found combining both the shimmer UI approach and this usually makes the injection of dynamic content less disruptive to user flow.
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.
! 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; }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.