This is the third week check-in on my work with L5 this summer. This week implemented a bunch of the design with focus on bandwidth constraints!
Recap
If you missed the last post:
Based on the schedule outline
Analyze survey responses and set up meetings to see what other changes could be made.
Start with quick wins on documentation updates from week 1 issues. This will likely focus most on “getting started” changes.
Get early community feedback on changes so far.
TLDR;
Small permacomputing meetup to work on self-hosting; transitioning away from Google for surveying
Installed some alternative browsers to test low-bandwidth
Huge navigation overhaul and updates on the live website!
University of Washington has a UX summer program where graduate students work on a UX project for the summer and L5 will be one of them!
On Self-Hosting
I've been on the self-hosting bandwagon this summer and during this last week we had a low-key permacomputing hacking session.
I set up Coolify on a Raspberry Pi and will have an Obsidian, Calibre, and my own Bluesky PDS soon! Coolify is a self-hosted PaaS that allows quick installation of different Docker images1.
I went through the Raspberry Pi setup guide which was pretty straightforward, although they did not mention any specific firewall settings. They did mention using ufw-docker which......is fine.
We will likely be using Yakforms going forward and I will probably add this to my self-hosted installation!
Alternative Browsers
There are a couple of alternative browsers that we are testing on to ensure that L5 is accessible on a variety of devices.
Browsers with GUI
The first I tested was Dillo:
Fortunately they have a homebrew package, but I didn't know this and tried to build from source which was much more difficult. It also requires using fltk!
brew install fltk@1.3
brew install dilloNext up was NetSurf, which I actually had a lot of difficulty installing and wasn't successful.
Their installation documentation is goofy. They say it works for MacOS, but nowhere is there instructions on the compile page on how to actually compile from source2.
Browsers without GUI
There are a few of these CLI browsers that Lee suggested I test:
Links
w3m
Offpunk (which uses gemini:// protocol instead of https://)
I only was able to install Links (fortunately with a homebrew install).
Huge Website Navigation Overhaul
Check it out!
Right now it is built using Mkdocs
And the Material theme
Which has some weird limitations around customizing navigation. A big point of feedback was the navigation on the left vs. the table of contents on the right was confusing for users in understanding the flow of the webpage. You can pretty easily integrate the table-of-contents into the navigation, but we had some pages that we didn't want that integration. I also enabled a couple of navigation features, which we were worried if it blew up the website size.
features:
- navigation.tracking # URL address bar
- navigation.prune # Render only visible navigation
- navigation.path # Breadcrumbs for beginning of filename
- toc.follow # Follow navigation
- toc.integrate # rendering nav bar to the leftIt basically distilled down to some very specific CSS for the pages we did or did not want to display the table-of-contents.
#__nav_5_label + nav.md-nav >
.md-nav__list >
.md-nav__item >
.md-nav.md-nav--secondary {
display: none;
}There were also pages that were "orphaned", or after clicking a link within a page you would lose where you were in the navigation. So this required to hide / show the page in the navigation only when it was the active page.
#__nav_4_2_1_label + nav.md-nav
> ul.md-nav__list
> .md-nav__item:not(:first-child){
display: none;
}
#__nav_4_2_1_label + nav.md-nav
> ul.md-nav__list
> .md-nav__item.md-nav__item--active{
display: block;
}Which looks like this:
Upon clicking "Shape Primitives":
Resource Bandwidth
There were a few issues testing the bandwidth of a site. The first was reading the Inspector wrong.
When looking at the Network tab in Firefox, you can see the actual consumption of a page.
On the bottom there are two numbers: 1.63MB and 803.73 kb. The left is the total size of the page whereas the right is transferred bytes over the network. We are focusing on keeping the transferred bytes number as low as possible. This is a screenshot of the largest page currently on the site.
Okay so first problem was looking at the wrong number.
The second and larger issue was that the navigation features implementation appeared like it blew up the page size.
We had already enabled lazy-loading and weren't sure if it was somehow disabling or if enabling different features in mkdocs was actually way bigger than we thought.
1.15MB transferred was way bigger than the live site at the time; however I also checked out the main branch and tested the size locally.
Which was...the same.
Basically there is no compression that ends up happening on local development, because it will always be the fastest on the machine that is serving the files.
But, if we look at the live site now:
Woohoo! Compression is working and the site is actually small!
So go look at the site and tell me your thoughts via DM or make an issue on Github!
Anyway
It was Lee's birthday last Thursday and Gemini season is almost over! Happy birthday Lee!
xx smh