Finda

Finda (formerly “Datatron”) is a uniform, search-based interface for quickly accessing your digital information, regardless of “where” it is.

The goal is to eliminate tedious mental recall and navigation of:

• Files and folders
• Open windows
• Browser tabs, bookmarks, and history
• Editor buffers
• Screen / Tmux terminal sessions

AKA: “Stop mousing around windows and tabs.”

Here’s a 5-minute demo:

2018 Feb 16 Update: Soft launch

I’ve renamed Datatron to “Finda” and soft launched it. Still working on marketing copy, but you can grab a copy now on the Finda product page.

Development log

Everything below here are my rough thoughts / questions / notes.

If you have any thoughts or suggestions, please email me.

Feb 1: Core rewrite

The original prototype was written in ClojureScript with Rust hooks for the OS X window APIs. However, I decided to rewrite the core application logic in Rust because:

• It’s a good excuse to learn more Rust.
• It gets Datatron closer to dropping the Electron-based frontend in favor of something less resource intensive and closer to the GPU.

As part of this rewrite, I decided to remove some features:

Results are no longer ordered by recency. The idea with recency was to allow Datatron to replace Command-Tab for quick switching. However, that requires Datatron always know what “thing” — browser tab, Emacs buffer, OS X Window, etc. — is active. This would be easy if Datatron was the only way to switch between things, but it’s not — it’s common to create new tabs within a browser or switch between buffers within Emacs. So either Datatron would need to poll running applications to keep track of what’s active or we risk the result order not always being accurate. Neither option is good, so I decided to scrap that use case.

Filesystem search dropped. During interviews, folks were much more excited about the switching than they were about filesystem search. Most people reported that Spotlight worked just fine for their hard disk searching needs.

That index was a prototype, in any case — Datatron scanned your hard disk only on startup (so it wouldn’t see subsequent file creations/deletions), and stored the index uncompressed in RAM.

While it’s possible for Datatron to hook into the Spotlight index, early tests indicate that it might take ~100–500ms for arbitrary file searches, which is far too long.

I would like to revisit the question of file search / manipulation, but that may be best tackled in a separate project.

Results are no longer visually grouped into “open” and “recent” categories; open results (windows, tabs, and buffers) simply come before the others.

Datatron commands have been removed from the results in favor of an overlay pseudomode that shows all commands and hotkeys when the Command key is held down.

As to the query question from the last update, I settled on two options:

• Sources can be toggled on/off, which also addresses the needs of testers who absolutely did not want their browser history showing up in the results.

• Matches are ranked according to how many times they match the query, with bonuses given for matches that begin at word boundaries. Thanks to @garybernhardt for discussion on this and reference to his Selecta tool.

Next steps from here are to tidy up the visual design, look into a few more integrations (probably Visual Studio Code and iTerm), and come up with a decent name/icon.

Dec 31: Too many query results

Some queries yield too many results to filter via textual query. For example, the ClojureScript compiler has a “twitterbuzz” demo project, so when I search for “twi” I get 50+ results like:

~/software/clojurescript/samples/twitterbuzz/readme.md
~/software/clojurescript/samples/twitterbuzz/style.css
...

which obscure the actual result that I want — to open twitter.com in a new browser tab.

Showing browser history results before local filesystem results just flips the problem around for when I actually do want to open twitterbuzz/readme.md or whatever.

Possible solutions I’ve considered, none of which seem obviously correct:

• Explicit control over results via hotkeys: Press “Shift-H” to specify that you only want to search browser history. This is understandable, and enables quick refinement, at the cost of either memorizing hotkeys for each source or dedicating UI real estate to showing those hotkeys at all times.

• Magical sorting: You’ve visited “twitter.com” many times, so that browser history result is ranked higher than twitterbuzz/. Great when when it works, but risks making search mechanics un-knowable (“why these results, in this order?”), which is disempowering and prevents mastery.

• More advanced view control: You can toggle a “hierarchical results” view so that all of the browser history results are grouped under “twitter.com” and all of your files are grouped under twitterbuzz/; additional commands would then be used to navigate into specific subtrees. Such a mechanism may be useful for refining search in other contexts (e.g., searching for files only within a specific folder). Downside is learnability and complexity — the whole point of this project is to do away with fiddly navigation