💾 Archived View for mozz.us › journal › 2021-01-01.gmi captured on 2022-03-01 at 15:09:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-09)
-=-=-=-=-=-=-
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.
screenshot of navbar for Castor
screenshot of navbar for Kristall
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
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.
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]
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:
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.
vs
(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...)
