During the last months we have been working on switching the solar powered website from one static site generator (Pelican) to another (Hugo). Many readers will not notice the changes right away, as we have not made any major adjustments to the design. Nevertheless, the new platform has allowed us to address some issues based on the feedback we received over the years.
The new solar website was designed by Marie Otsuka and Roel Roscam Abbing, the same people who were behind the first solar design. Marie Verdeil assisted throughout the process and coordinated the migration of the website.
Switching Platforms
The original solar website, launched in 2018, ran on a static site generator called Pelican. While this remains a good choice for a relatively small website, the solar-powered version of Low-tech Magazine has grown significantly over time. Initially it featured only a selection of the English language website, but has expanded over time to contain not only more English language articles, but translations in five other languages as well. Organizing articles and publishing changes on such a large website became a cumbersome process. For example, it took more than an hour to regenerate the site on changes – even if we only added one comment.
Hugo is a static site generator written in a faster programming language. In Pelican, much of the functionality we needed for the website such as support for multiple languages and image compression came as plugins of varying quality. This lead to limitations over time. In Hugo, these features are better supported from the start as they are core to the project. As a consequence of switching to Hugo we managed to reduce the generation time on the server from over an hour to approximately twelve minutes. On a modern laptop the difference is between several minutes and several seconds of generation.1 This difference in time also means a difference in energy use on the server.
Aside from faster website builds, Hugo allows for a better organisation of content and is more flexible in defining categories for displaying that content. This allowed us, for example, to create dedicated pages highlighting the different contributors and translators to the magazine. However, despite both projects using posts written in Markdown, migrating all content from Pelican to Hugo was a time-consuming task. Both because of subtle differences in the post metadata format and because our Hugo setup requires its own shortcodes to allow the display of images, captions, and links. We converted the majority of articles from one platform to another using a custom script, but it still took another two months to iron out and manually repair inconsistencies in the content.
Design changes
Battery meter
The new platform allowed us to address two design issues that regularly came up in the feedback over the last years. The first concerns the battery meter, which reflects the battery status of our off-the-grid website configuration. Some people found that it interfered with the reading process, especially when it’s halfway the page. The battery meter remains an elementary part of our design, revealing the material infrastructure that supports the website. However, it now remains at the top of the document, and no longer moves along as one scrolls down an article to interfere with the text.
Images
The second and major design improvement concerns the images. Dithered image compression works great for many images, and even makes black and white images more attractive. However, some images become unclear. This is especially so for graphs, which can become unreadable if they are not designed with dithering in mind. For some other images, the colors convey information that is lost in the dithering process.
The new design allows the visitor to turn off the dithering compression for individual images, revealing the original photo or illustration. The original images we show are compressed in a conventional way and are slightly heavier than the dithered images. Revealing them thus increases the load on our server. It remains to be seen how this will influence the energy use and uptime of the solar website.
Furthermore, the images are no longer full screen, which is especially advantageous when the website is viewed on a large computer screen.
Source Code
As was the case with the original Pelican theme, we release the Hugo theme as open source software. The original solar web theme and plugins remain available, but are no longer updated nor maintained.
Running Low-tech Magazine on 1 website
This major redesign is the penultimate step towards running Low-tech Magazine on just one (solar-powered) website. Ever since the launch of the solar powered website in 2018, the old (English language) website has remained online and up-to-date. This is troublesome, for several reasons.
First, running two similar websites is not consistent with our aim to lower the ecological footprint of the publication. The more so because the original website – a dynamic website hosted on blogging platform TypePad – is not lightweight. A second website running on grid power also defeats the purpose of going offline when the weather is bad – the old website remains online no matter the weather. Second, the need to update two websites involves a lot of extra work that would better be dedicated to writing and researching. The layout for every article has to be made twice, on different platforms. Comments and changes to the articles also have to be updated on two platforms.
The higher quality of the images was one of the main reasons to keep the old website up-to-date. Now that the original images can be viewed on the solar powered website, we will no longer update the old website. From now on, new content (including comments on older articles) only appears on the solar powered website. The TypePad website will remain online until summer, when we plan to move the part of the archive that has still not been converted to the static web format. It concerns mostly articles and pages from the early days.
For most other languages, the switch to the solar powered website has been completed already and the original websites have been shut down. The only exception is the original Dutch language website, which is no longer updated but remains online (also hosted at TypePad) to keep the older articles accessible. Due to the high number of original articles on that website, it will be the last original website to disappear, if ever. It still has the original design from 2007.
User-friendliness
The new solar design brings nothing but advantages to the readers of Low-tech Magazine. However, on the publishing side, the balance is less positive. A greater usability for the visitors has gone (partly) at the expense of a lower usability for the author. The shortcodes used by Hugo are much clunkier than the syntax used by Pelican, and that adds to the time that it takes to make the layout for an article. This partly negates the time that is won by no longer having to update the second website.
Static websites are much more energy efficient than dynamic websites. However, static site generators still have a long way to go in terms of usability before they can become more mainstream and compete with tools such as WordPress. In the five years between our initial release and this one, to our surprise, no robust and user-friendly application for static site generators has appeared that could replace our current workflow. Several projects exist, but these are all dependent on proprietary cloud services. A usable graphical interface for static site generators is still where key contributions to this field can be made. In the upcoming months, we will try to improve things on the publishing side, and as always, we welcome your feedback and suggestions. Please also share bugs or inconsistencies that we have missed in the migration. Thanks to everyone who has supported this project over the years.
Reactions
To make a comment, please send an e-mail to solar (at) lowtechmagazine (dot) com. Your e-mail address is not used for other purposes, and will be deleted after the comment is published. If you don’t want your real name to be published, sign the e-mail with the name you want to appear.
Reactions
Tobias
Hi Kris!
I read in the article on your new Solar site that you solicited a easy-to-use graphical interface for static site generators. I am a developer and felt that it sounded like a quite interesting project. I have been using static site generators a bit for my own sites and also contributed to one (https://github.com/greghendershott/frog).
Having a developer background I didn’t think so much about graphical user interfaces (I usually settle for some home-grown Emacs integration), but I admit that this probably narrows the target user group for this kind of (in my opinion under-utilized) technology. So am I curious to know what kind of requirements you had in mind for such a graphical interface? Something that is tool agnostic, i.e. you could call out to any [supported] static site generator? Desktop app? Should it feature a page authoring component? (Markdown or such) Interested to hear any thoughts you have about this.
Thanks a bunch for the magazine. I enjoy the articles a lot, and dare I say they also strike a deeper chord in me (probably because I think that the information that is conveyed is actually very valuable, and will probably become only more so in the future). I had an idea myself for an article a while back actually, is it possible to contribute articles?
Warm regards,
Tobias
Jonas
Which user-friendly application for static website generation would you like? Do you have a requirments/whishes list?
Marie Verdeil
Hi @Tobias & @Jonas!
I am Marie Verdeil, and I assisted the rebuild both as a designer and web-developer. I am glad to see some developers picking up the topic of a static-site generator GUI and would love to bounce some ideas with you. Currently, we use Hugo and a self-hosted server administarted by @Roel Roscam Abbing (more detais here) that pulls from a Gitlab repository.
While there exists some static-site generator CMS like Netlify CMS (now called Decap) and Static CMS and even Hugo desktop apps (like Buho CMS), none of them seem to match our requirments
Currently the biggest problem lies with writing markdown. Since we don’t have a user-interface, all writers and translators write markdown locally or on gitlab. This is both uncomfortable and prone to many errors (wrong metadata, wrong spelling for tags or categories, wrong shortcode syntax, incorrect internal links leading to 404 errors, etc.). Another issue lies with the lack of preview, for people (not familiar with the terminal and therefore unable to run a local server). The current setup is that I preview articles locally, make a screenshot and send it back to Kris…
My current GUI / wishlist would be:
*We are maybe missing some other tools and haven’t started testing any of these on this project, so feedback on your favorite CMS is welcome.
Mark Schultz
I am in the process of developing a global static site for community groups. Similar problems include i18n (for new language sourcing and translations of existing pages into new languages), and the “power user” requirement for markdown content.
Our current Buddhist practice community website (https://fallingrain.org/en/) is a gitlab-to-netlify build. All free, but not solar (yet :). VS Code for website management and GIMP for image work.
Thanks for posting the CMS that you have already reviewed. Might be a nice option for some of my work. However, I am thinking that a lightweight API and some javascript would allow in-place translation. Poepole granted editor access could simply modify navigation/front-end phrases, or use a JS editor for larger posts; these would be stored in a temporary “updates” table. We would have a build team pull in those translations using a little build utility – it would populate the local JSON or whatever language files and even generate the .md for posts. Since I will know exactly where “update” came from, I can target my build utility to create a backup, and then write to the correct files…
I considered having those tables be the source for all i18n detail… but then you have to have that darned API listening and answering all the time… good-bye solar site, hello weight of services again. So if the API is called once for authorization (authentication would be OAuth2 or some such? if I can get it free-ish?), that would be reasonably light on our poor little planet…
Visual Studio Code is really a pretty fine platform. I assume you use this or similar already…. If not, extensions provide markdown previews and syntax, as well as .YMAL or .TOML or all the other flavors of everything you need. I also created very simple command line actions to create new posts, creating the front matter for me – I might change some of the details for a given post or page. This really reduces the problems remembering what should be where.
“hugo serve” allows local preview and real time changes.
VSCode is a developer IDE, but packaging the extensions you use and the few helper commands can go a long way to lessening the tech shock. If you have questions about what I have done these past several years, I’m happy to get on some flavor of media call. I live in Catalunya as well, north of Barcelona (Sant Feliu de Pallerols, La Garrotxa).
Thanks for your geeky inspiring work!
Mark Schultz
Mark Schultz
You could use the same lightweight API structure for receiving comments in-line. You would probably add a CAPTCHA interface to avoid getting spammed, and require some sort of email address or other identification to be allowed to post. The service could also grab the IP address of the poster, and allow only a few uploads per day, or something like that…
The API would save comments in a temporary table, which would then be pulled down and added to your Hugo folders during the build process. I do all my personal work in Linux, while my work-for-pay is Windows, so I could develop that pull utility in a Windows desktop application. This two-step process means that changes to the website are not real-time – which I am happy about, actually; this isn’t social media – and involve someone pushing a button.
Question:
We were refugees from BCN, moving to our fix-up home one day before the Covid lockdown. We had no electricity (due to an electrician who was a Covid Denier, and wouldn’t listen to me), so I did my development work with a tethered cellphone, a solar panel, and a 166Wh Beaudens battery. Amazing. I kept up my consulting business from a 200AD mill, heated with a little french wood burning stove. Still using the tethered phone for all my internet needs.
The real question: I still have this panel and the battery, and am considering playing with a solar site myself. Would you still recommend the same OLinuXino? Have you learned any tricks since your original hardware posting?
Thanks!
Mark Schultz
Florimond
Hi,
I work at a worker-owned business named Fairness 0. We use Hugo for our public site and blog. I personally share some of the usability concerns about Hugo that you mention at the end of the post. So the idea of improving the usability resonated with me.
I’d have a few more questions to help clarify what direction would best fit a community effort towards a free and open source “Hugo GUI” (or other non-technical-user-friendly interface for Hugo).
Thanks a lot for your inspiring piece and the ongoing work with the Low Tech Magazine. Looking forward to reading you back. For what it’s worth, I am probably going to submit the problem of “usable Hugo GUI” as a discussion topic at Fairness. Perhaps we’ll be interested in collaborating with you or other interested folks (such as fellow commenters!) on a solution that moves the ecosystem forward. Happy to discuss!
Best,
Florimond
Amadeus
Hi there!
I got pointed towards your article on Mastodon and enjoyed reading it. Congratulations on the re-launch!
I’m the developer of Mattrbld (https://mattrbld.com) a headless CMS built specifically for statically generated sites (it is itself a statically generated app). It functions similar to other Git-based headless content management systems, but it runs entirely as a PWA in a browser and only needs a connection when synching changes to and from the Git repository. It is also focussed on providing an easy and intuitive interface (including previews!) for content editors, while allowing a high degree of control and customisation regarding the underlying data structures.
As you can imagine, building such a tool is a challenge and there is still a lot to do, but it’s already being used on some production websites. I am not sure if it is a great fit for your project, but perhaps you could take a look and decide for yourselves. Since other users here in the comments have expressed interest in such a system, I figured I’d let all of you know.
Maybe it could even run on a solar-powered webserver one day, since all the heavy lifting happens on the user’s device anyway.
I am working towards open-sourcing it so users can contribute and have peace of mind, but as I’m still cleaning things up for the initial release, you can also try it out for free at https://app.mattrbld.com.
Keep up the great work!
Cheers, Amadeus
Anonymous
What’s missing on every article page in my opinion is the date of publication. The only way to know it is to look at the url.
Anonymous