barnsworthburning.net
- What this site is
- Colophon
- Contact me
- Shortlist of interesting spaces
- Behind the scenes
Your Brain, Your Notes: A clean and powerful notes app for Mac & Windows.
Directories aren’t surging. There isn’t this nascent directory movement fomenting - ready to take on the world. Directories aren’t trending.
But there is a certainly really sweet little directory community now. From the Marijn-inspired stuff listed in Directory Uprising to the link-sharing ‘yesterweb’ collected around sadgrl.online - or the originals at Indieseek and i.webthings.
Barnsworthburning (by Nick Trombley) is a very formidable addition to this community - a clean, multilayered design and an innovative bidirectional index.
One of the best (and easiest) ways to start making sense of a document is to highlight its “important” words, or the words that appear within that document more often than chance would predict. That’s the idea behind Amazon.com’s “Statistically Improbable Phrases”:
Amazon.com’s Statistically Improbable Phrases, or “SIPs”, are the most distinctive phrases in the text of books in the Search Inside!™ program. To identify SIPs, our computers scan the text of all books in the Search Inside! program. If they find a phrase that occurs a large number of times in a particular book relative to all Search Inside! books, that phrase is a SIP in that book.
Highlighter is a personal knowledge bank and collaborative learning network designed to feed your curiosity and help you examine new ideas.
Build ideas mindfully.
Save content, create collections, and connect ideas with other people.
An open collection of notes, resources, sketches, and explorations I'm currently cultivating. Some notes are Seedlings, some are budding, and some are fully grown Evergreen.
Technology is seeing a little return to complexity. Dreamweaver gave way to hand-coding websites, which is now leading into Webflow, which is a lot like Dreamweaver. Evernote give way to minimal Markdown notes, which are now becoming Notion, Coda, or Craft. Visual Studio was “disrupted” by Sublime Text and TextMate, which are now getting replaced by Visual Studio Code. JIRA was replaced by GitHub issues, which is getting outmoded by Linear. The pendulum swings back and forth, which isn’t a bad thing
A meta note, inspired both by Proust and by this book about Proust: after reading a book, when you're making notes, don't refer to the book; just write down the most interesting things that come to mind. This is a better way of digging out what actually struck you about the book; as soon as you have the book to reference, you will start looking up the bits you "should" write about, and end up aiming at comprehensiveness rather than interestingness. Your actual criterion should be whatever interested you. Later, you can fill in quotations & references.
The visual workspace for notes. Humans have incredible visual-spatial memory. Leverage that with Nototo.
- Pause at the end of each chapter and try to recall it (Recall)
- Highlight relevant passages for later comparative reading
- Analyze the book once I’m finished
- Explain it to unfamiliar audiences (The Feynman technique)
- Review topics I care about at regular intervals (Space repetition)
A note-taking tool for networked thought.
A zettelkasten consists of many individual notes with ideas and other short pieces of information that are taken down as they occur or are acquired. The notes are numbered hierarchically, so that new notes may be inserted at the appropriate place, and contain metadata to allow the note-taker to associate notes with each other. For example, notes may contain tags that describe key aspects of the note, and they may reference other notes. The numbering, metadata, format and structure of the notes is subject to variation depending on the specific method employed.
Evergreen notes are written and organized to evolve, contribute, and accumulate over time, across projects. This is an unusual way to think about writing notes: Most people take only transient notes.
- Evergreen notes should be atomic
- Evergreen notes should be concept-oriented
- Evergreen notes should be densely linked
- Prefer associative ontologies to hierarchical taxonomies
The problems are solved, not by giving new information, but by arranging what we have known since long.
Intelligent note-taking. Non-linear file management. Ideas and relationships visualized.
In order that the mind may not be taxed, moreover, by the manifold and confused reading of so many such things, and in order to prevent the escape of something valuable that we have read, heard, or discovered through the process of thinking itself, it will be found very useful to entrust to notebooks...those things which seem noteworthy and striking.
How do we choose which level of fidelity is appropriate for a project?
I think about it like this: The purpose of making sketches and mockups before coding is to gain confidence in what we plan to do. I’m trying to remove risk from the decision to build something by somehow “previewing” it in a cheaper form. There’s a trade-off here. The higher the fidelity of the mockup, the more confidence it gives me. But the longer it takes to create that mockup, the more time I’ve wasted on an intermediate step before building the real thing.
I like to look at that trade-off economically. Each method reduces risk by letting me preview the outcome at lower fidelity, at the cost of time spent on it. The cost/benefit of each type of mockup is going to vary depending on the fidelity of the simulation and the work involved in building the real thing.
Suppose we have four levels of fidelity…
- Rough sketch (on paper or an iPad)
- Static mock-up (eg. Photoshop or Sketch)
- Interactive mock-up (eg. Framer, InVision)
- Working code prototype (HTML/CSS, iOS views)
Depending on the feature you’re working on, these levels of fidelity take different amounts of time to create. If you plot them in terms of time to build versus confidence gained, you could imagine something like a per-feature fidelity curve.
Take a simple CRUD web UI, where you’re just navigating between screens. It doesn’t take much more time to build the real version than it does to mock it when the design is simple. If you were to build out an interactive mock first, you would end up spending twice as much time in total without gaining much out of it.
Contrast that with a complicated Javascript interaction. Or a native iOS feature that requires programmer time to build out. If it takes substantially more time to build the real code version, then it may be smart to do an interactive mockup first.