gemini://josipantolis.from.hr/gemlog/devlog-04-re-small-request-to-geminauts.gmi

This devlog is going to be more about my thoughts on navigation UX than progress update for work on the Starfish browser.

Recently JBanana posted¹ a call to Gemini authors to include a back link to our posts. This would make it easier to navigate to index pages (of either entire capsules, or particular gemlogs). The post has since garnered a response² from ew0k, who argued that need for individual back links is remedied by the URI path segments in a well structured capsule.

To all this I'd like to add a reference to a bit older post³ on Gemini navigation UX from Michael; which argues for inclusion of navigation functionality in client apps.

I'll approach this topic from 3 standpoints. Since I labeled this post as a devlog, I'm thinking about this as a developer of a Gemini client. Obviously, I'm writing this in a gemlog of my own, so I am an author too. Lastly, I browse Geminispace and share the reader's frustration with missing navigation.

As a reader I like to have some sort of clickable navigation that takes me "up a level". I wouldn't necessarily call it back, since that sounds chronological which is traditionally handled by the client. Gemini server has no Idea where I'm coming from, so it can't offer to take me back. But "up", "parent", or "index" link sure does sound nice.

Having this functionality integrated in the client seems even nicer. Not only does it make it universally accessible to me, it also allows me to go up at any time. I don't need to hunt for the up link somewhere in the page, I know the button always up there in my header bar.

Having some "next" or "previous" links would also be nice. For example this devlog post could link to my 3rd devlog. That wouldn't be the second to last post I've written on my gemlog, but it would be more semantically appropriate. Providing these kinds of semantic links seems beyond clients' capabilities.

As an author I really don't feel like putting in all the up links. For one it seems repetitive. I admit this is something that could be fixed by some "smarter" Gemini server or by using a static site generator. But part of the joy I get from writing stuff on Gemini is it's simplicity. I write a text file, my server serves it and that's it.

However, the semantic links idea does give me pause. As author I don't care much about copy-pasting up links all over the place. But I might have some ideas on what I'd recommend my visitors to read next, after they're done with the current post.

Introducing a kind of "do you want to know more?" section with links at the end of my posts sounds interesting. At that point I might as well throw in an up link as well.

The most interesting consideration for me is from developer perspective. When working on the Starfish client I focus on features that I personally want in my Geminispace browsing. I've had the basics of rendering gemtext and back & forward history navigation down for couple of weeks now. It's interesting to me that going up (and going to the root of the capsule) was my next pain-point.

The up navigation was relatively simple to define. Where I fell short was in the "sibling" level (next and previous) navigation that Michael called for. That one's both more complicated to implement but also to define on the conceptual level. It may be interesting to try to build a site map on the fly by crawling the capsule the current page belongs to. I'll leave this idea for some later time.

From the implementation perspective there are a few interesting details. First of, how do I navigate one level up? I remove one path segment from the URI and try loading that page. If server returns an error I remove another segment and try loading that. In the end I'll either load a page successfully, or I'll run our of paths in which case I render the last error response I received. This seems simple and I'm fairly certain it matches reader's expectations.

However, servers complicate things. There are those that want all URIs to end with a /, and those that absolutely do not want that. There are those that will redirect one path to the other and those that will just fail with a not found status.

This means that in order to go up from, for example, URI gemini://example.com/index/post.gmi I try loading:

I also need to ignore redirects or I'll get "trapped" by the redirecting kind of servers. All in all, code that implements this ended up more messy than I anticipated. I suspect there's room for improvement, but I didn't bother with it (for now). In the end I'd rather have some hacky code on my side and provide readers with a better experience then have them click a go up button only to land on an error page.

That's it for going up. There's still the go to root action to consider. Again I thought this will be simple, I'd just omit the path part from the URI.

What I forgot about are tilde communities and similar multi-tenant servers. They are harmless for the go up action, but do somewhat break the "omit path to go to root" implementation. In this case root is not at the domain, but at the "~user" level instead. So I worked in a hack for this too.

The semantic navigation feature proved to be a bit more complicated than I expected. There are probably some edge cases I still haven't thought of. However, I'm glad I added this feature to the browser. It already made my browsing experience nicer in one afternoon of its existence.

I think I'll also start adding navigational links to my posts. For the sake of other browsers, but also in order to sneak in some extra links of my own!

Devlog 04: Re: Small request to Geminauts

My three hats 🎩️🧢️⛑️

Reader

Author

Developer

Implementation details

In the end