Why do I believe we do not know how to solve the problem? As the article inadvertently points out, the unorganized data they want is not accessible and Mac Spotlight, a tool that operates on unorganized data, does an "OK Job, but not a miraculous one". If Apple knew how to super search the vast trove of unorganized data and file formats for content-specific data and always get it right would there be any reason they would not do so? It would clearly be strictly superior to their existing offering. For that matter, they bring up browsing history in Safari which is an even easier problem and also claim it hardly works. For evidence outside of Apple, think of all the in-app search systems that can barely even search plaintext for things you know exist. I frequently have problems with Gmail not finding emails despite giving exact string matches. These problems are all subsets of the proposed problem, which must be solved to solve the harder problem, and which would offer immediate material benefits for their solution yet do not or barely exist.
The problem is not a mismatch between solution and user workflow. The problem is that we do not know how to solve the problem for all meaningful workflows. The best we have achieved is creating and supporting a workflow that allows the problem to be solved in many useful cases. Luckily, if the problem can actually be solved in the future, it can easily be bolted onto the existing solution to test viability before going all-in.
For evidence outside of Apple, just try to use browser history in Chrome or Firefox. They're completely unreliable, entirely useless. For me, it's 50/50 chance I'll get a result when searching for a site that I visited few days earlier.
> think of all the in-app search systems that can barely even search plaintext for things you know exist
Exactly.
Most of the search systems I've worked with have one, big problem: they don't feel reliable. You type in a query, a system starts a search. You get some indicator of progress, which eventually expires. Typically, search systems don't tell you if the search was exhaustive - did it check every possible thing that could match, or did it bail out after hitting some time limit? They also often meddle with the query, modifying it or doing fuzzy matches, in ways not communicated to you in the user interface. With such systems, if the thing I'm looking for isn't in the result set, I don't feel confident it isn't there.
Manual file organization (or any direct data access) has this property of being exhaustive: a file is either there or it isn't. Direct file access means that if you don't trust your file searcher, you can always look for yourself.
There are many other challenges ahead if we want "universal search" to work, but a big step forward would be addressing these trust issues. It's entirely an UI issue. Instead of "0 results found", say "0 results found after searching contents of all text files in Documents folder (symbolic links not followed)". Instead of "about 123 results", say "123 results found, there may be more matches, [click here] to read about limitations of the search method".
(And on a general point: users aren't as dumb as the common claim is. Our industry is treating them as dumb, taking away every opportunity to learn and build mental models - and then complains that users "are dumb".)
And as you imply, when you have a lot of files that you need to organise, you tend to start compiling them into directories.
Tags are very powerful if used properly. They describe sets by definition and allow quick filtering with intersections and other set operations. If the filtering is a bit smarter it can support boolean operators, or use tag distance and order as a meaningful data point so that e.g. "discussion board" doesn't return the same results as "discussion snow board".
They're a more flexible way to organize data than hierarchical directories. Hierarchy can easily be expressed with tags (use any character as separator, e.g. "os.linux"), but files and directories are not nearly as expressive enough for all the use cases tags can be used for.
You could put the same file in multiple directories. You could have a file in ~/vat and symlink it to ~/urgent and ~/accountant.
I'm really addressing the argument that tags are a revolutionary change that should replace the directory-based filesystem entirely. The cost seems too high to justify the benefit.
I'm not actually interested in building such a system, it's been done before[1,2]. Though I haven't actually used any extensively, since it does require a shift in how file management is done, and I'm quite familiar with filesystems to bother to change, but it's on my list. :)
[1]: https://tmsu.org/
Most people, in their jobs, every day.
Just as they did before the advent of computers, too.
The real question is what is effective for individuals and business trying to accomplish real work, who are at least somewhat capable of learning or training staff.
I don't disagree that interfaces should be designed for users, but they should be designed to EMPOWER and teach users, not to just dumb everything down to the lowest common denominator. Because, let's face it, most people are awful at organizing stuff that materially matters a lot to their lives and well-being.
No, if a commercial for profit system doesn't work for the vast majority of users, then it does deserve rethinking. Linux is a great example of an operating system that was not written for the highest profitable denominator until recently.