W3M an entirely console-based web browser I mentioned briefly in a previous post, despite a series of limitations in the context of a full web browsing experience, can play just the necessary role in minimizing your workflow to the essential, non-distracting components.
Having reached a point of frustration with fully-featured graphical web browsers, I proceeded to perform serious meta-analysis on how I best operate.
I’ve experienced a series of graphical browsers, from among the heavier traditional variants to the smaller-footprint alternatives. The problem with each is the ease of slipping into the rabbit hole. This is fantastic for ‘web browsing’ in the strict sense of the word, but fatal for single-tasking and content production.
I don’t want pleasantly designed web pages opened in a series of tabs waiting to be consumed with ease. I don’t want attractive visual elements arranged conveniently for ease of navigation and scanning. I don’t want unnecessary images cluttering real estate, and most images across my work contribute to nothing but decoration. I don’t want quick access to email or Youtube. I don’t want any superfluous content to crawl it’s way to my attention.
I don’t like to discipline myself to cultivate or eliminate habits. This has hardly been successful in the past. I prefer to eliminate malignant habits by their roots, and make positive habits essential and irreplaceable.
With respect to web browsers, I needed to regress to the roots of World Wide Web, before the epoch of HTML 5.0 and rich web content. I don’t even know everything that’s out there, and don’t much care; not for lack of value and innovation, but for deviating my attention from the essential.
A series of limited-function text-based browsers exist, with use largely among enthusiasts, or in the case of the less frequently encountered console-only environment. I focused on W3M, but don’t have compelling arguments for why I favored it over Links, Lynx, the Emacs browser, or others.
W3M actually provides support for images in an otherwise entirely terminal-based interface, never mind by what means. The support is not terminal oblivious, and incompatible with my terminal, which I didn’t much object to. Moreover, I entirely disabled image rendering attempts and even the automatic image downloads, which means web page rendering has become a function of pure text. However, image viewing is possible upon demand. The image placeholders still render among the content, and open in an externally configured viewer at the invocation of a proper shortcut.
Web page rendering also becomes largely color oblivious, rendering only the link, image-placeholder, form, and title text color uniquely from the remainder of the document. Otherwise, the default color scheme involves light gray text on black background, consistent with my terminal, and far more forgiving on the eyes. (I utilized a variation of ‘dark reader’ plugins in full web browsers, but found a nuisance having to toggle it’s status between contrastingly lit pages.)
I have not completely eliminated the possibility of distractions and the such. The advantage, however, lies precisely in the lack of appeal to reach superfluous content. I’ll explain how.
The navigation is entirely keystroke based, making content not-entirely text-oriented a bit of a burden to navigate, such as that with frames, forms, tables. Looking at the rendering of such pages, I lose further motivation to explore any but the essential content.
Functions to visualize all accessible links and open them in a new tab are present. The ability to search is handled in a similar way to other Unix text buffers, with partially VIM-like shortcuts. I can also download documents or images via respective shortcuts.
The virtue of such an interface, lies not in the inability to consume unnecessary content, but the sufficient discomfort at carrying out the task. Such a web browser is best suited for pure, simple text content, without rich elements.
W3M doesn’t provide global session support, the ability to save open tabs, and the ability to interface with a running W3M instance externally to the application. This limitation further discourages the urge for tab harvesting. Once the running instance is closed or terminates for any reason, the tab layout is irrecoverable.
W3M does enable the opening of any link in an external web browser, which, by argument, could entirely perturb the text-based workflow. But I rationalize this as less of a danger and more of a backup measure for the infrequent yet critical web content not fitting for a terminal. Once I invest in a particular working environment, I generally refrain from interchanging between multiple alternatives.
This flexibility to pass a URL to an external application I’ve actually leveraged for a useful purpose. I don’t much find the presence of many tabs appealing, but recognize the need to queue necessary (not bookmark-worthy) content for later viewing, not deviating the mind from the task at hand. For this, I created a shortcut to simply append the highlighted URL to an external text file, taking no further action on it. In addition to not cluttering the workspace with provocative tabs, it also serves the benefit of maintaining the URLs externally saved and not subject to loss. I’ve also experimented with passing the URL to a console-based journaling application, adding the appropriate tag, and making the retrieval of such saved URLs equally simple.
I’ll include the relevant bit from my configuration file
~/.w3m/config that dictates this external ‘browser’ behavior:
extbrowser sensible-browser %s & extbrowser2 surf %s & extbrowser3 url=%s out_file=~/saved_links.txt && echo $url >> $out_file && echo $url saved to $out_file && read s extbrowser4 url=%s && jrnl now: @link $url && echo $url saved to journal && read s
Naturally, cases requiring usage of a full web browser will arise on occasion. My hopes lie in the 80/20 rule as always, that such cases will comprise a small minority, yielding room for optimizing the workflow for the common remainder.
I’ve only hovered on the basic W3M functionality. It’s entirely customizable with regard to keystrokes, mime types, rendering, etc. Ultimately, I’ve transitioned from much focus in a rich graphical application to the rendering of pure text in a console. In addition to the potential for a more goal-oriented workflow and a much decreased memory footprint, I find console applications visually minimalist and retroactively appealing. Pure content over visual flourish.
Another huge benefit is the extra step one must take with regard to conducting searches. There is no smart search function incorporated into the URL bar. In fact, there is no URL bar. One must invoke a shortcut to enter a desired URL, but it neither autocompletes nor offers a smart search function. I must resort to traditional methods of loading the search engine page, entering the query into the text form (to which I must navigate via the keyboard), and invoke the submit button.
The above hurdle causes me to reconsider the importance of a search, and less likely to outsource a minor cognitive challenge to a search engine. Alternatively, I’m more likely to bundle multiple searches into one session, rather than interrupting focus for intermittent, and largely distracting search operations.
With regard to email, I also outsourced this element to the console-based neomutt, which interacts with a local Maildir synchronized with Gmail via offlineimap. It may sound convoluted, but I’m finding this workflow subject to less distraction, and reminiscent of the days before heavy reliance on rich web-based email. I might explore Neomutt in a separate post if I have anything exceptional to add. I perceive, however, that the console-based email client userbase far outnumbers the console web client users.
I find that in general, technological innovation, in it’s totality, disproportionally surpasses the respective need, much of which demands a mere application of traditionally available simple tools with a small touch of imagination.