Finda

← Back to Kevin's homepagePublished: 2017 December 30Last updated: 2018 Feb 22

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:

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:

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:

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:


← Back to Kevin's homepage