I'm sure a thousand engineers at Google can figure this out.
I fully understand the scale of the problem. I also think this is a very approachable problem for a thousand Google engineers who have done a lot harder things.
Filters, refinement, user preferences. etc etc. Search is a powerful tool, and the power has been growing exponentially since 1995. But, almost all of that power is channeled into instant results, intuitiveness, "sane defaults" and such. All the capabilities are in the background and the assumed user is lowest denominator on all fronts. The low effort, low technical capabilities, low understanding, etc. This is most people (me included) most of the time, but not all of the time. Maybe I want to filter seo spam (like pinterest) more aggressively. Etc.
This isn't a slam on google really. One thing can't do everything and the thing google search does is what most people need most of the time. It's definitely the thing that makes the most money. But... none of a search engines power has been channeled into making search a power tool. It's a tool that everyone uses many times per day, but there is no learning curve. No getting better. You can't really invest effort and get rewarded for that effort.
Pity really, all this power is there. It's right under the surface. Let us be more than the lazy, dumb user sometimes.
Google have reversed the User Interface paradigm. Instead of users learning the software and telling it what to do, the software learns the user. I don't necessarily mean NNs or personalisation. I mean that the paraign is software-centric. "If the user does X, how should the software respond?" instead of "If the user user wants Y, how does she make the software do it?" That's great for intuitiveness, but it also creates a frame where the software gets better over time but the user never does.
And I want it to be social - I want to search using the same filters that Tim Bray uses.
Or I want to use the filters that the people use who in aggregate tend to click through to the same results pages that I visit.
So much amazing stuff could be done, but here we are controlled by algorithms that treat us all as brain dead sheep who only want to know about what the Kardashians are up to.
I suspect that Google knows about these desires, but would prefer the world where everyone is a sheep.
I agree, we need more power to control. There should be more than one recipe for ranking and filtering, and we should have more to say about what information is being hidden from us. Society is diverse, a single formula automatically discriminates some groups. Let people make the choice.
May I quote you on this?
It is a great description of the 3rd premise in a talk proposal I submitted to LibrePlanet 2021, which goes something like:
- Software freedom is predicated on the notion that users ought to be in control of what runs on their computers.
- I claim that tech literacy is necessary to exercise this control.
- "Google Design" presumes that "nontechnical users" are not and will never be capable of tech literacy.
If all of these are true, then "Google Design" is incompatible with the idea that Software Freedom is for everyone. And indeed, we see this borne out in many people's disdain for copyleft licenses, which impose restrictions on developers in order to guarantee freedoms for end users. That's a logical viewpoint, if you believe that end users wouldn't benefit from software freedom, anyway.
"Google Design" does make software more accessible to end users… at the cost of turning your computer into an appliance. Which makes it a self-fulfilling prophecy. People don't magically become tech literate; they intentionally learn the skills so they can achieve something. Remove the power from the tools, and you take away their motivation to become tech literate. I have a great story about my grandma to illustrate this point.
If our goal is to make computing (and, by extension, software freedom) more accessible to everyone, then we need to change our approach. We need to prioritize education and teaching tech literacy. And most of all, we need to write software that is powerful enough that users will see the benefit in learning to use it.
That's they key points from the first half of the talk. The second half is about how we can create software that is powerful without sacrificing usability. It basically boils down to "make simple things easy and hard things possible" — creating software that Just Works™ without configuration, but allows you to customize its behavior if/when you want to. In particular, I'm a fan of embedded scripting interfaces (e.g. spreadsheets), which allow a vast amount of customization without creating "settings overload" that is typical of many FLO[1] programs.
The problem with this model, though, is support. A service with 100 million untrained end users each paying a dollar will need to provide quality customer service to 100 million untrained end users. It is much easier to sell ads to 10,000 "affiliates" who feel that they have some special arrangement and thus accept some responsibility of their own, and make $10,000 off each of those.
I would definitely pay Google just to be able to remove some sites permanently from my results. They're just spam to me, even if Google thinks they are legitimate.
Then on top of that the skimming the payment processors do makes a large percentage of that $1/month go to transaction fees. Charging yearly helps with that but many people won't want to do that.
$10 per month is probably more realistic.
I guess we need wildcard domain exlclusion.
Additionally, for those, who likes to add reddit in the search query, i'd also like to recommend " inurl:forum OR inurl:board " (note also that forum and forums gives different results for some reason).
Personally, I like to do broad searches on google to discover new stuff, but for the past 7 or 8 years, google often returns ~100 result instead of the usual 1000000+. And, contrary to the logic, adding various inurl: commands actualy gives you more results instead of limiting them and thus significantly improves searching capabilities.
https://greasyfork.org/en/scripts/1682-google-hit-hider-by-d...
This is really the precedent that mattered, I think. Remember one line of a poem? You can probably find the rest. Recall a Douglas Adams piece about rice farming in Bali or Java or something... you can find it. As you say, it took boolean gymnastics. But, that really just means modifying your search terms and scrolling through some results.
Being less powerful than 2020 google kind of put more power/responsibility in users' hands. A user needed to use a search engine like a tool.
I want what you want too... Everything google (mail/search/youtube, etc)... but designed for more user effort. Finding the best-for-most result instantly is great, but sometimes you want the tool to help you find a result on page 112 within a few minutes.
Bring back a little bit of a directory feel even. Let me narrow down, refine and shape results gradually. Assume that I will rummage through a bunch of crap to find what I want.
Unfortunately that didn't scale with the size of the web; at one point the amount of pages got large enough that doing a smart ranking like Google did became more effective than the "look at all pages of results" usage required for AltaVista. It felt like a monumental transition, like when a program gets too big for main memory and causes the computer to start swapping to disk.
That reminded me of Architext, and EWS (Excite for Web Servers)[2], but a good bit of Googling (ahem) later, seems difficult to find much about most of the mid to late 90s standalone local search engines any more, except perhaps Inktomi. Most are not mentioned in Wikipedia search engine timeline[3].
1. https://en.wikipedia.org/wiki/Microsoft_Development_Center_N...
2. https://www.wired.com/1998/01/excite-moves-to-patch-search-s...
3. https://en.wikipedia.org/wiki/Timeline_of_web_search_engines
EDIT:
Using the search engine Qwant, I was able to find an original EWS (Excite for Web Servers) help page:
http://www1.udel.edu/Excite/AT-helpdoc.html
At the time, it was amazingly out of the box:
Excite for Web Servers makes it easy for you to add searching -- Excite, Inc.'s advanced concept-based searching -- to your Web site.
Excite for Web Servers provides a simple Web-browser interface for doing all the things necessary to enable concept-based searching of collections of documents -- administering, indexing, and searching over the collections.
In particular, one can:
- define a document collection -- that is, specify a set of documents to be considered a single collection over which one can search,
- design customized pages for displaying to users who wish to search over that collection,
- index that collection, monitoring the progress, and search the collection.
With Excite for Web Servers, it's easy to set up concept-based-searchable Web sites in minutes.
I almost wish there were less precise and more obscure options out there today. A search engine that purposefully didn't index mainstream news, social media, nor shopping/product sites.