A CSS stylesheet to mute distracting links for focused reading.
If you have a monkey brain like me you’ve probably fallen down the Wikipedia rabbit hole more often than you like. Sometimes I set out to research a specific topic and don’t even finish reading the first paragraph before being sucked into all those links. Or I find a tutorial on Google and end up opening a new browser tab for every blog post the author has ever written.
If you are not plagued by this “problem”, try not to roll your eyes too much at the rest of this post.
The obvious solution is to just not open those links. Self-control as they say. I’m working on that. In the meantime, it’s nice having a little bit of help and I got you covered.
Here’s what I came up with. A stylesheet to mute distracting links:
The links are still there and you can still click them if you need to, you just can’t see them.1 Doesn’t it feel quieter?
If this is not enough, use hard mode and disable links completely:
Try getting distracted now.
Throw the stylesheet into your stylesheet manager and enable it when you need it on a per-site basis. You could also whitelist or blacklist specific sites for it to work automatically. I personally use it as a userscript which you can find here.
When I first made this stylesheet I thought it would just be a silly experiment. I actually ended up using it regurlarly and found it to be quite effective for focused reading. The interesting part is that I could still quite accurately guess which words and phrases would bear links. If I needed more information I would seek out those links on my own accord. The other irrelevant ones would be kept muted instead of being highlighted and screaming “give me your attention!” at my face.
A little bit of peace.
Of course, this intended to be used on blocks of text such as articles or blog posts. On other sites like web apps it looks weird. ↩
Every time I land on a single comment page deep in a Hacker News thread, I wonder how to get back to the full thread. There is no way of doing that short of repeatedly clicking the parent link until you reach the top. Um?
Worse, comment pages contain neither thread title nor a link to the submitted article. There is no context whatsoever besides the comment itself. This is fine if you navigated to the comment from the full thread. In that case, you probably know which topic you came from on. However, I often land on a single comment from a Google search and end up being stranded.
After being slightly annoyed by this problem one too many times, I had think something up. The solution was a userscript that adds a simple all comments button. Click it and you’re back on the full thread.
The first iteration of the script did pretty much what I described above. It repeatedly scraped the parent page of the current comment until it reached the full thread. Only later did I learn about the Hacker News API. But even with the API, there is no way of requesting the containing thread for a single comment. So the process remains pretty much the same.
Automating lifting my mood with IFTTT, Workflow and cats.
This is a silly one.
For a quick pick-me-up, I sometimes browse the catloaf forum on reddit. What is a catloaf, you ask? Well, let me tell you: It is a cat that looks like…a loaf of bread. There is just something about those goofy loafing cats that instantly lifts my spirits.
The problem is the catloaf forum’s post volume is rather low which means I’ve most likely seen the most recent posts. Also, there’s just the general hassle of opening the website or a client and navigating the forum. Too slow. When I’m in a slump I need loaves and I need them instantly!
The solution is to set up an instant catloaf delivery system.
This IFTTT recipe grabs any new image from the catloaf forum and saves it to a specified folder in Dropbox.
This workflow fetches those images from Dropbox and displays them in random order.
In the end, I just open the workflow and boom: catloaf. To make it even quicker, I usually launch the workflow from Spotlight. Open Spotlight, type “catloaf”, off they go. And since it’s randomized, it never gets boring.
It’s a silly workflow but it makes me happy. Why not have a little fun with automation?
Currently, only the images without any context are saved to Dropbox. It would be nice if I could see the title and maybe a link back to the reddit thread.
You could also modify the recipe to only add new hot or top posts instead of all new posts.
Reflecting on the Table of Contents for GitHub browser extension.
Even though it was a tiny project, I thought I’d take the time to reflect a bit on making Table of Contents for GitHub while it’s still fresh in my mind. I’ve got to use this blog for something right?
What and Why
In short, I made a browser extension that adds a table of contents to GitHub readmes, wikis, gists and basically any other structured text file on GitHub. As readmes and documentation grow bigger it is supposed to help you quickly find the information you are looking for. I found myself skimming and scrolling all over readmes and wikis when I decided I want this to happen.
Most related projects solve the “GitHub table of contents problem” by requiring project maintainers to hard-code tables of contents right into the source files, either manually or semi-automatically. Usually this is done by adding special markup to the file that, in a separate step, is rendered into a table of contents.
This has several drawbacks:
It requires work: from project maintainers.
It is not automatic: It requires a separate step to build the table of contents. And it needs to be kept up to date with changes.
Nobody does it: Well, almost. For you as a user this means that you don’t get to enjoy a table of contents for the vast majority of projects.
Individual files only: Each file that should have a table of contents needs to be marked as such. But there are many other places on GitHub where a table would be desirable, such as wikis, gists and basically any other text file.
This project has a different premise: Instead of putting the onus on project maintainers, it’s a browser extension that is installed by the user. It lives inside the GitHub website and is fully automatic. Whenever you land on structured text such as a readme, boom there’s your table of contents.
I had a few requirements for what to build. A solution should:
be a browser extension.
generate a table of contents fully automatically and require no work.
provide the table not only for readmes, but for wikis, gists and any text file.
be simple, easy to use and visually unobtrusive.
be readily available for most browsers.
I started with making a Google Chrome extension first since Chrome offers the most straightforward and best documented extension API.
Whenever GitHub’s HTML/CSS changes we need to adapt. This is the nature of living inside the website. This has happened a few times already.
The code assumes there is only ever one table of contents on the page. Makes sense: There is only ever one readme, one text file, one wiki displayed at a time. However, I have had users requesting I add a table of contents to any structured text on GitHub, including comments on issues and pull requests. To do that there would have to be a table of contents for each comment on a page of which there can be many. This requires a bit of restructuring. At this point I’m not sure if this exceeds the scope of the project.
There are any number of things that can be changed and added to the project. For one, I would like a search feature that would allow you to filter the table of contents.
Finally, I plan to rework the code so as to lift the restriction of only one table of contents per page.
In the near future though, I don’t have too much time to dedicate to the project. For now, I’m pleased with it and will keep it mostly in maintenance mode.
What I Learned
Again, this was a really small and simple project. Still, I learned a bunch:
Dipping my toes into JS tooling, specifically npm and gulp.
Building a product for different targets (browsers).
Limiting the scope of a project.
Publishing extensions to Chrome Web Store and Mozilla Add-ons.
Dealing with feedback and interacting with users.
A browser extension that adds a table of contents to GitHub readmes, wikis and gists.
A readme is the first thing you see when you open a repository on GitHub. It tells you all about how to install, build or troubleshoot the project. For bigger projects, readmes can grow quite big and it becomes hard quickly finding what you are looking for. I often end up scrolling all over the place.
Some project maintainers manually add a table of contents to their readmes but most don’t. And these aren’t just readmes where I’d like to see a content summary on GitHub. There are wikis, gists and basically any other structured text file. That’s a lot of work for maintainers to keep their table of contents up to date with changes.
Of course, I’m not the only one to have recognized this problem. This issue on this very topic has hundreds of enthusiastic comments calling for various solutions for a GitHub native table of contents feature. Most of them are variations of the same semi-automatic idea: You add a special markup inside the readme which, in a separate step, is rendered to a table of contents.
I decided to be proactive and implement a solution I would like myself. Instead of putting the onus on the project maintainers to insert a table of contents into each and every file, my solution would work automatically with any readme, text file, wiki, gist and what have you. Provided you install the small browser extension I made for you ❤️.
The extension, creatively named Table of Contents for GitHub, lives insides the GitHub website and dynamically adds a table of contents whenever it detects you’re visiting a readme or other structured text. The table hides behind a small button so it only appears when you tell it to. A click on an individual entry brings you right to the corresponding section in the readme.
There are a few other details. To avoid having to scroll back to the table of contents if you want to look for something else, I added a small button to each heading that brings you right to it. You can even use the extension to create and edit files, wikis and gists right in your browser. The table keeps updated as you make changes.
I’m really happy with how it turned out. It’s simple, unobtrusive and effective. For my needs, the extension completely resolves the issue of finding information in readmes. So far it has been received well. I have had several users write in saying they enjoy it.
Get the Extension
Table of Contents for GitHub is available for the most common browsers:
A browser extension to collapse comments on Hacker News.
Update December 2016: I’m happy to see that this feature has finally been added natively to Hacker News. And it pretty much works exactly like my extension. The extension is now obsolete.
The Hacker News site is as plain as it gets. One thing that irks me is that there is no option to collapse comment trees. Long threads can be quite hard to read and it is easy to lose your place. Compare this with sites like reddit where collapsing comments is an intricate part of the comment section.
I implemented a Safari extension and a userscript that adds this missing functionality. There’s now a collapse button on each comment header. Click it and the comments are gone.
Before getting to work, I looked around to see if this had already been done. I found an old bookmarklet by Alexander Kirk. It had several bugs and did not quite work as I intended. For one thing, it is a bookmarklet, so you have to manually activate it on every thread you visit. Extensions and userscripts would work automatically.
Instead of starting from scratch, I decided to use Alexander’s bookmarklet as a starting point. I made many changes to it and fixed several bugs. I still kept a lot of the old code so it may be a bit ugly.
I’m really satisfied with this extension. I use it to collapse comments pretty much every time I visit Hacker News.
A Safari extension for Pinboard to bookmark the current website.
I have been looking for a simple Pinboard browser extension for Safari but couldn’t find one that I liked. The ones I did find were a tad too clunky and complex. The ideal extension would allow me to bookmark the current website in Pinboard and nothing more. It would open the default Pinboard bookmarking form and place the current mouse selection into the description field.
I stumbled on this when I wanted to make the feature to use the current mouse selection in the bookmarking form a user preference. Injected scripts—those parts that can read webpage content such as the mouse selection—cannot access preferences. Only the global HTML page can, which in return is blind towards webpage content. To bring this together, the injected script needs to request the user’s preferences from the global page via asynchronous messaging.
In the end, this was a simple process but it still needed to be understood first.
I’ve been using the extension for a while now and am really pleased with it.