-- Leo's gemini proxy
-- Connecting to mozz.us:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; lang=en
Published 2021-01-01
(2021-01-04: fixed a couple of typos regarding lagrange - thanks solene)
Most GUI clients for gemini/gopher copy their navigation toolbar from standard web browsers:
[back] [forward] [refresh] [--- address bar ---] [go]
Some of the fancier ones add extra buttons for shortcuts or certificate management, but this is more-or-less the template. It makes sense... I mean you've got to start from somewhere. And web is the standard. Here are my unorganized and rambling thoughts on this.
=>/files/journal/castor_navbar.png screenshot of navbar for Castor
=>/files/journal/kristall_navbar.png screenshot of navbar for Kristall
=>/files/journal/lagrange_navbar.png screenshot of navbar for Lagrange
The [back] and [forward] buttons are essential because browser history is such a powerful concept. Everyone understands this from the web at least. The implementation for keeping track of history is pretty straightforward, too. Every time you open a new window you initialize two stacks: one for backwards history and one for forwards history. Then just push and pop from them as the [back] and [forward] buttons are clicked. If the user clicks on a link inside the page, push it to the backwards stack and wipe out anything in the forwards stack. Easy!
The page response should be cached alongside the request URL on the stack to prevent refreshing when using the [back] and [forward] buttons. IMO this is the *only* time that responses should ever be cached. The gopher app on iOS by Charles Childers doesn't cache forwards/backwards navigation and it pains me every time I use it. History navigation should be 100% instant and reliable.
Being able to load a URL is obviously required functionality for any client. Some clients will hide [go] in favor of just typing "Enter" into the URL bar. I don't particularly mind this on desktop clients, but it's quite annoying on mobile when I have to open up my phone keyboard widget to hit "Go".
Refreshing the page is useful if an error is returned from the server. Or to reload a page with dynamic content. Some clients (although fewer than above) will also omit the refresh button from the navigation bar. I guess the thinking is that the URL is already pre-populated in the address bar so you can just hit "[go]" instead. But sometimes I'll mess with that URL without loading it - cut it to my clipboard, delete parts of it, etc. For that reason I still prefer to have the dedicated button for refreshing.
Some clients will include other buttons in their navigation bar such as
[home] - Open a preconfigured homepage.
[favorite] - Mark the current page as a favorite.
[certificate] - View the server's TLS certificate details.
These are welcome additions as far as I'm concerned. The more buttons you can squeeze in, the better. Bonus points if they can be toggled on/off by the client settings. Horizontal space is going to be a bigger factor on mobile clients.
What's missing is inter-site navigation.
Most HTML pages will stick their own little navbar on the top of the page. The good ol' hamburger menu. Click the logo in the top left to jump to the site's home page. Click the "blog" link to jump to the site's blog directory. Sometimes there will even be a second navbar on a blog page that looks something like this:
[previous post] [next post] [back to listing]
We've somehow accepted that everyone on the web must reimplement these common links inside of their HTML pages. I'm pretty sure this is the reason that like 90% of static site generators exist in the first place. Nobody wants to edit navigation links by hand across hundreds of files. It's a pain in the ass.
I don't want to do this in gemini. I added [go back] and [home] links in Astrobotany for site navigation and I kind of hate myself for doing it. They look out of place and they don't fit the rest of the document's structure.
=>. 🚶 Go back
=>/ 🏠 Home
I want my gemini client to have site navigation buttons instead of me jamming links onto every text/gemini page that I publish.
We already have a structured path hierarchy for gemini URLs. Let's use it!
My ideal gemini client would look like this:
[back] [forward] [refresh] [--- address bar ---] [go] [root] [parent] [previous] [next]
line 1 - retain the functionality as described in the first section
[root] - go to the root directory for the current URL, i.e. "/"
[parent] - go up one directory from the current URL, i.e. ".."
[previous] - go to the previous "sibling" page
[next] - go to the next "sibling" page
I already have [root] and [parent] built into my gemini proxy at portal.mozz.us and I use them quite frequently. It's actually one of the features that keeps me from using a native gemini client all the time.
I'm thinking that [previous] and [next] would work something like vf-1's "tour" command. Admittedly I haven't totally nailed this down yet. "sibling" could refer to either the next file in current directory (i.e. fetch the [parent] page and parse that to find the next link), or it could refer to the next file from the previously viewed page (e.g. If you click on a link in CAPCOM, the next sibling would be the next gemlog entry listed in CAPCOM).
I'm leaning towards the latter approach (the CAPCOM style approach) for a couple of reasons:
The previous page should already be cached in the client history anyway, so the sibling URLs can be generated without making a separate gemini request.
The current URL is guaranteed to exist as a link on the previous page (since you clicked it to get here) so you can calculate it's position relative to the other links on the page.
You could always emulate the former approach by clicking on [parent] first to prime the client history, and then clicking on the link again.
Perhaps instead of just showing [next] and [previous], the client could display the URL inside of the button so the user can see where it would take them.
Heck, take it a step further. Why limit options to just [next] and [previous]? The client could put a window on the left-hand side of the screen with a scrollable list of *all* the links from the previous page. As a bonus, it might help nudge gemini document authors towards using descriptive names for their links.
=>. <go back>
vs
=>. mozz.us gemlog directory
(quiz: which is these links is better UX?)
This is why gemini and gopher are so fun for me to think about. There's limitless opportunity for better UX design outside of the rigid boundaries of the web. Unfortunately I couldn't ever add this to portal.mozz.us without using cookies to track browsing history. I really don't want to do that. Maybe I should write a real gemini client (I say, as if I doesn't have a dozen other projects taking up my time already...)
-- Response ended
-- Page fetched on Fri Apr 26 12:57:33 2024