Why do webpages with text waste so much of my screen space?

The Arch Wiki changed its design some months ago from text and a sidebar that floats to fill the size of the screen to the content now only being inside a narrow box that takes up only parts of the width of a larger screen. The Arch wiki is not alone in making text-based content visible only inside a narrow box in the middle of the screen. It is a general trend in web-design when the content is text and images and is very common on blogs. It is also used in the Reading mode in Firefox. The idea is that it should somehow be easier to read the text when it is centred and narrow. I do not know exactly why people think this is the case, but many people do. There might be user interface research to suggest people read faster in a narrow column, or it might just be based on how books and newspapers with columns were traditionally laid out. I am not a user interface designer, so my knowledge is limited to my own thoughts and experiences. Even so, I know I am not alone in being annoyed by this trend in web-design, so I thought I'd write a few words about it in the hope that I could convince some people to rethink the use of the max-width attribute in their CSS file.

I think the idea that it is easier to read text in a narrow column is just balderdash. At least to me, the disadvantages of a narrow columns are far greater than any possible advantages and I do not read any faster when the text is laid out like this. The disadvantages of narrow text columns on a wide screen are many. Firstly, you have to jump lines more often which makes it easier to loose where you are in the text. Secondly, you have to scroll more often which interrupts the flow of reading the text with unnecessary movement. For most people, this involves lifting their hands from the keyboard to a trackpad or mouse. For more keyboard-centric users, it involves using arrow keys or PageDown, the middle button and a trackpoint, ctrl-n (Emacs keybindings) or j (Vim keybindings). How this is done depends on the browser and the hardware. More keypresses (or mouse actions) makes digesting the information in the text into a slower process with more interruption from actual reading than necessary and wastes time and energy. I also find it aggrevating to have to scroll more often than necessary. Thirdly, it wastes a lot of space on the screen that could have been used for content but is now just empty background. Fourthly, it disregards the choice of screen size and window size the user has made. Some people like very wide screens with a 21:9 ratio while others like 16:9, 3:2, 16:10, or 4:3. Personally, I feel that for smaller laptop screens like my 12,5 and 14 inch laptops, a less wide aspect ratio like 16:10 or 4:3 is preferable, but for a larger external screen, 16:9 is usable (and much easier to find used at a reasonable price) because you have enough pixels of height with a larger screen at normal pixel densities to avoid too much scrolling even if it is 16:9. Additionally, the width of the screen is not necessarily the width of a window. The user can choose for themselves how wide a window they would like to read the text within. For those of us using tiling window managers, splitting the screen into smaller areas is just a keypress away. I don't need a web designer to choose how narrow my window should be for me when I use a smaller window, and when I want a wide window for the text of a website, I definitely would prefer not to be limited to a narrow strip in the middle to avoid unnecessary scrolling, space waste and moving lines more often. If the content just resized to fit the window, maybe with some small margins to look less cluttered, that would be preferable to me.

I cannot think of any advantages to narrower columns of text on a webpage. Human vision is wider than it is tall and that is the argument many give for widescreens in the first place. It is also why films and pictures usually are wider than they are tall unless shot in the portrait orientation because the human body is in that orientation or because the display medium is going to be a smartphone. You do not need to move your head when reading text filling the width of a wide screen unless the screen is really large and you are really close to it, so that is not an argument against letting the text flow wider. For computer screens, most people use screens small enough that you never need to move your head. At normal computer screen viewing distance (which is different than for instance TV viewing distance and smartphone viewing distance) that means that anything smaller than a 27 inch screen is small enough. I use a 25 inch 1440p external screen often and it is definitely small enough that I never need to move my head to read a long line of text. You do have to move your eyes no matter how wide the column is, so making it narrower does not mean any less eye movement, just more up-down movement to change lines instead of more left-right movement. Smartphones are taller than they are wide when held normally, so maybe mobile-friendly design is the motivation, but if the text would just flow to the width of the screen minus a small margin, that would work just as well on phones as on tablets, two-in-ones, laptops and desktops and not annoy users of any device.

I think narrow columns were initially used in newspapers because newspapers in the past often were not in the tabloid format and therefore a bit of narrowing was useful because usually you would have to fold the paper to be able to hold it, but for webpages today, I just don't get why people want less content, more line breaks and more scrolling. This trend is actually a good reason to use terminal-based web browsers that disregard CSS or use custom CSS in a more mainstream browser. There might be reasons I do not know for making content only fit a narrow strip in the middle of larger screens that do not apply to my use of the web, but for me, this trend is definitely annoying. I have changed the CSS for this website to reflect this view.

Non-free firmware in Debian 12 Bookworm

I have spent a bit of time trying to find the firmware-iwlwifi package with the Intel Wifi driver for Debian 12 Bookworm (the next Debian release, currently in testing). I tried all the usual things like enabling the contrib and non-free repos, but could not get it installed. I looked at the Debian Wiki and it gave me a link to packages.debian.org that led me to the package, but only in older versions of Debian. When I tried to go to the same package in Bookworm, I found nothing. I thought maybe the files had moved to another package and tried apt-file, but with no success. After a lot of searching on the internet, I finally found out that non-free firmware files have been removed from non-free and a new repo called non-free-firmware is where they now live. After adding that repo, I could install the firmware-iwlwifi package. This information should be added to the Debian Wiki in the articles about firmware-iwlwifi and firmware, but I was unable to make a user profile on the wiki to add this information myself which is why I wrote this blog post.

Edit March 9th, 2023: From the Alpha 2 release of the installers, this non-free-firmware repository is added by default to your install, so my previous explanation here of how to enable that repo for new users is no longer needed. If you have hardware that does not need non-free software drivers, then there is no harm in removing this repo from the etc/apt/sources.list file and just use the main repo for a fully free software experience.

I Love Free Software Day

I want to thank all the developers, contributors, translators, designers and project leaders who have given me so much great software on I Love Free Software Day! I also want to thank a harpsichordist from Bergen who many years ago showed me that GNU/Linux was a good alternative to Windows or MacOS. Even though I did not do anything about it at the time, some years later, curiosity led me to try out various GNU/Linux distros in VirtualBox on my Mac and that was the start of a gradual transition from Mac OS to GNU/Linux. I already used some free software like LibreOffice, Firefox and Thunderbird on my Mac and that helped ease the transition.

Free Software is about freedom. In practical terms for a normal user, it is very obvious how the users' interests is important for free software projects while non-free software often is more about forcing the users into usage patterns that strengthen the corporate interests of their creators even if it makes for a worse user experience. An example is how Microsoft tries to force people to use Bing, Edge and MSN by not respecting the user's browser and search engine settings when doing a web search from the start button in Windows 11. It makes advertising money for Microsoft, but it is very user-hostile, especially since the users already paid for Windows as part of the cost of their machine. This is just one small example, but there are many more.

I also like how I can help improve free software by contributing to projects I like. I have contributed money, bug reports, translations, feature requests and a bit of very simple code, and hope to do more of this in the future. It is also possible to influence the direction of a free software project by contributing to it. This puts the most active users in the driving seat. In a worst case scenario where a project goes in a direction people dislike, it is possible to create a fork since free software licenses give the freedom to modify a program and distribute your changes. A famous example is how OpenOffice was forked to create LibreOffice which is now the default Offie suite on most GNU/Linux distributions. (OpenOffice is no longer actively maintained.)

I also like how Free Software empowers me as a user to customize it to my liking and learn how to programme in the process. With Free Software, my computer is personal again. Not only can I choose between a lot of desktop environments or window managers to match my preferred workflow, I can also customize these further to my liking. While I prefer a tiling window manager with a keyboard-centric workflow without any panel or bar for maximum screen real estate for my programmes and a minimum of mouse clicks and movement to get things done, other people prefer a full desktop environment either of the more traditional type or a reimagination with new user interfaces like Gnome. GNU/Linux is modular enough to give us those choices by design. GNU Emacs is another piece of software that is very customizable and when you customize it, you also learn how the code of the program itself works since you customize it in the same language as it is made with by adding your own functions and modifying built-in variables. The documentation of the program is very helpful for learning how to do this. It was the first programme made by the GNU project and a prime example of the freedoms of free software put into practice. The numerous forks of it attests to the importance of those freedoms for people wanting to use parts of it or change it more to their liking.

Happy I Love Free Software Day!

Elfeed with useful scripts

Elfeed is an RSS feed reader package for GNU Emacs. RSS is a standard for getting content like podcasts, video channels from LBRY and Youtube, Mastodon and Twitter, blog entries, news articles etc from the web without using a browser. Before I started using elfeed, I used Newsboat, a terminal program, as my RSS reader. I was inspired by Napoleon Wils0n to add scripts to Newsboat so I could launch videos from RSS feeds directly in mpv or download them with youtube-dl (and later yt-dlp). After I started using Emacs, I wanted to try to integrate most of my computing into it and I looked at the two built in feed readers before trying the highly recommended elfeed package. I liked it, so the next step was to find a way to get the same functionality I had in Newsboat in elfeed.

I don't know Elisp well enough to script this myself yet, so I looked online. I read up on the documentation for elfeed on GitHub and also found some inspiration on Reddit that I tweaked to make some elisp scripts to be able to hit m if I want to watch a video in mpv and M if I want to download it with yt-dlp to my "Nedlastinger" (Downloads in Norwegian) folder. I tried a couple of different solutions before I was able to get what I wanted. The suggestion from Reddit was to use start-process to launch an external process with the url from the entry as its argument. That worked well with mpv. For yt-dlp that was less successful and I also wanted to change directory to ~/Nedlastinger before launching the yt-dlp process so I read up on how to run shell-commands asyncronously and used that functionality instead. I also made certain that any shell command run asyncronously doesn't display a new window. (A "window" is a split within an Emacs "frame" (an X11 window) in Emacs parlance. Emacs is from before the Macintosh introduced the desktop metaphor's now common vocabulary (that Microsoft later copied in Windows), so it uses its own vocab for these concepts.) The reason why there are two scripts for each functionality is that I can use those keyboard shortucts both inside the view where you show the specific entry and in the view where you see all entries while one is selected.

;; Dette gjør at Async Shell Command ikke vises hver gang man kjører en shell kommando med & fra inne i Emacs 
(add-to-list 'display-buffer-alist
  (cons "\\*Async Shell Command\\*.*" (cons #'display-buffer-no-window nil)))

;; Gir meg muligheten til å bruke m i elfeed for å åpne en rss entry i mpv
(defun browse-url-mpv (url &optional single)
  (start-process "mpv" "*mpv*" "mpv" url))

(defun elfeed-show-mpv-open (&optional use-generic-p)
  "open with mpv"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-mpv))
    (elfeed-show-visit use-generic-p)))

(defun elfeed-search-mpv-open (&optional use-generic-p)
  "open with mpv"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-mpv))
    (elfeed-search-browse-url use-generic-p)))

(define-key elfeed-show-mode-map (kbd "m") 'elfeed-show-mpv-open)
(define-key elfeed-search-mode-map (kbd "m") 'elfeed-search-mpv-open)

;; Gir meg muligheten til å bruke M i elfeed for å åpne en rss entry i yt-dlp
(defun browse-url-ytdlp (url &optional single)
  (shell-command (concat "cd ~/Nedlastinger &&" "yt-dlp -f 'bestvideo[height<=720]+bestaudio/best' " url " &")))

(defun elfeed-show-ytdlp-open (&optional use-generic-p)
  "open with ytdlp"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-ytdlp))
    (elfeed-show-visit use-generic-p)))

(defun elfeed-search-ytdlp-open (&optional use-generic-p)
  "open with ytdlp"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-ytdlp))
    (elfeed-search-browse-url use-generic-p)))

(define-key elfeed-show-mode-map (kbd "M") 'elfeed-show-ytdlp-open)
(define-key elfeed-search-mode-map (kbd "M") 'elfeed-search-ytdlp-open)

Those scripts worked fine for video channels from LBRY and Youtube, but not for podcasts which use an enclosure url to give the url to the actual episode's video or audio while the general url field in the RSS entry is used for show notes. I tried searching for variables within elfeed with the built in self-documenting features of Emacs, but did not fully understand how to find the enclosure url. After some searching aorund the internet, I found a way to get the enclosure-url and recycled most of my previous code again with the new url to make two functions making it possible for me to listen/watch a podcast with mpv by hitting P and downloading it with yt-dlp with K. I only implemented this for one of the two views.

;; Gir meg muligheten til å bruke P i elfeed for å åpne en podcast (enclosure) i mpv
(defun elfeed-show-play-enclosure (enclosure-index)
  (interactive (list (elfeed--enclosure-maybe-prompt-index elfeed-show-entry)))
  (let ((url (car
	      (elt
	       (elfeed-entry-enclosures elfeed-show-entry)
	       (- enclosure-index 1)))))
    (start-process "mpv" "*mpv*" "mpv" url)))

(define-key elfeed-show-mode-map (kbd "P") 'elfeed-show-play-enclosure)

;; Gir meg muligheten til å bruke K i elfeed for å laste ned en podcast (enclosure) med yt-dlp
(defun elfeed-show-dl-enclosure (enclosure-index)
  (interactive (list (elfeed--enclosure-maybe-prompt-index elfeed-show-entry)))
  (let ((url (car
	      (elt
	       (elfeed-entry-enclosures elfeed-show-entry)
	       (- enclosure-index 1)))))
    (shell-command (concat "cd ~/Nedlastinger &&" "yt-dlp -f 'bestvideo[height<=720]+bestaudio/best' " url " &"))))

(define-key elfeed-show-mode-map (kbd "K") 'elfeed-show-dl-enclosure)

I have set my default browser with my environment variables to Firefox and even though I like Emacs' built in browser eww a lot for text-based content with the occasional picture, I want to keep Firefox as my default browser for now. However, when I read an RSS entry in elfeed and it does not supply the full blog post, it is nice to stay within Emacs and read the linked blog post with eww instead of launching a heavy external browser. So I had to make two functions for the two view modes for that as well. So for those RSS feeds that do not supply the full content, I just hit B and the content opens up in eww. There is built in functionality to open the linked content in the default browser by hitting b in elfeed, so whenever I want or need to open the content in Firefox, I just hit b. For some content that is dependent on JavaScript or is full of media, I sometimes use that built in function, but usually, I use B instead.

;; Gir meg muligheten til å bruk B i elfeed for å åpne en rss entry i eww
(defun elfeed-show-eww-open (&optional use-generic-p)
  "open with eww"
  (interactive "P")
  (let ((browse-url-browser-function #'eww-browse-url))
    (elfeed-show-visit use-generic-p)))

(defun elfeed-search-eww-open (&optional use-generic-p)
  "open with eww"
  (interactive "P")
  (let ((browse-url-browser-function #'eww-browse-url))
    (elfeed-search-browse-url use-generic-p)))

(define-key elfeed-show-mode-map (kbd "B") 'elfeed-show-eww-open)
(define-key elfeed-search-mode-map (kbd "B") 'elfeed-search-eww-open)

Comparing my present elfeed setup with my former Newsboat setup, one thing that is much nicer with these scripts and elfeed is that I don't have to use an external program for podcasts. Newsboat comes with podboat which is intended for use as a podcatcher after you have qued up the content within Newsboat. That process always felt cumbersome and I actually didn't use it because of that. With elfeed and a few scripts, I have all kinds of feeds within the one reader and use a few different keyboard shortcuts to get everything done that I want. Another nice thing with elfeed is its search functionality which is very powerful.

My Emacs journey is still in its infancy, but the more I delve into Emacs, the more I like it. It's powerful, personal and pleasant. Emacs extends the hackability of GNU/Linux further by allowing you to tweak not only your DE or WM through configuration and shell scripts, but also the program you do most of your tasks inside. Integrating more functionality into Emacs means less friction and context switching between different tasks. Thus far, I have only integrated RSS reader, email, pdf document creation (org mode with latex export to pdf), blogging (org mode and org-static-blog), some web browsing (Firefox is still my default browser, but I use eww more and more), note-taking in org mode (I used to use vim and markdown) and of course general text-editing.

It's interesting how much faster for instance navigating around my emails is in mu4e within Emacs than in Thunderbird which was my previous email program. I think the reason is that Emacs is both text and keybord-centric (while also allowing for mouse use if you are so inclined). Elfeed has also become more useful than Newsboat used to be for me since I now also use it for podcasts. The hackability of Emacs means you can add functionality you want or customize things to your own preferences easily. Emacs also uses less system resources than other programs while doing more. Fewer resources means less power use and longer battery life on laptops. You can save money and possibly also CO2 emissions if your electicity is produced in environmentally unfriendly ways.

I see Emacs as the ultimate step in my gradual move towards less resource usage for my computing that started when I switched from Mac OS X to GNU/Linux in 2011, moved to a light-weight desktop environment (LXDE and later LXQt), then to even lighter weight window managers, gradually switched some GUI programs with terminal programs and scripts and then in the end the gradual integration of many tasks into Emacs. (I did this mainly out of curiosity, but I have reaped other rewards like less resource usage and more freedom as well.) If you see Emacs as only a text editor, then it is more resource hungry than vim (but less than VSCode), but if you see it as what it is: an integrated, hackable computing environment, then it is less resource hungry than the combination of programs you would use to do the same tasks. It is also the ultimate expression of the FSF's ideal of empowering users through the use of free software. I am definitively going to delve deeper into Emacs in the months to come.

Vim vs Emacs for fast text editing