Over at mozz.us there's a nice Gemlog post on navigation interface design (and perhaps interface design in general) for Gemini clients.
"Gemini Client Design - Navigation" at mozz.us
Really good navigation tools make a world of difference to use experience, at least in my experience/opinion. Part of the reason I use AV-98 as my daily driver despite the fact that there are lots of other great clients out there is that I am so used to and reliant on some of it's navigational niceties which are rarely found elsewhere. In fact (and, yeah, okay, this is a bit of a not-so-humble brag), *all* of the navigational niceties mentioned in the mozz.us post already exist in some form in VF-1 and/or AV-98 - although AV-98 could definitely be improved and I think I'll try to make some changes influenced by the mozz.us post soonish.
Both VF-1 and AV-98 have a `root` command which will instantly take you from wherever you are to the "/" path of the current host. They also both support the proposed "parent" feature, with the `up` command. You can also use `..`, which is an alias for `up` - maybe I'll add a `parent` alias, too. I actually don't use the `..` alias much myself, I sometimes found myself doing `cd ..` out of habit! I find both of these commands very useful and use them regularly. I'd find a client without them frustrating (although certainly not unusable).
The mozz.us post says:
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.
In fact, VF-1 *has* `previous` and `next` commands, and I love them. They are inherited by AV-98, but sadly they're kind of broken there, because of differences between Gopher and Gemini. I have had it in the back of my head for a long time to remove them from AV-98 to avoid confusion, but I've now been inspired to actually just fix them, because it's not *that* difficult. Let me explain.
In Gopher, there is a strict dichotomy between whether a given URL is a plain text document (item type 0) or a menu/directory (item type 1). Plain text documents cannot have any links in them, you just have to include the URL in your post somewhere and your readers need to use the mouse to copy and paste it - on a machine with only a keyboard and no mouse, Gopher documents are hypertext dead ends, unless you feel like typing a URL out manually by hand (in Gopher's defence, URLs literally didn't exist at the time it was designed, so this shortcoming would not have been obvious!).
Anyway, VF-1 always has in memory all of the links in the most recently encountered menu. When you follow a link from a menu to a text document, VF-1 also remembers that document's position in the menu (it's the same numeric index you use to actually follow the link in VF-1's interface). When you've finished reading that text document, you can type `previous` or `next` to load whatever came before or after it in the menu from which you arrived at it. If all the items in a menu are documents, the menu structure never gets overwritten and you can use these commands repeatedly. This means if you open a menu which is just a bunch of links to type 0 phlog posts, you can navigate to the first post in the menu and then just type `n` (which is an alias for `next`) over and over again to sequentially read all the posts until you hit one you've already read. There is no need to constantly go back to the menu page to get a link to the next post. This makes for *much* more streamlined phlog reading. Once you're used to VF-1, surfing Gopherspace with something like lynx feels unbearably clunky. One of the reasons I really dislike Gopherholes which shoehorn working links into phlog posts by serving them as menus (where almost all the lines are of item type i so they just render as text) is that they break this lovely navigation tool. The first time you follow a link from the genuine menu listing all phlog posts to a faux menu phlog post, the in-memory copy of the genuine menu gets clobbered by the faux menu and VF-1 no longer knows what was listed before or after it.
Gemini does away with Gopher's strict document/menu dichotomy, so that you can insert functioning links into your posts the way everybody wants/expects to be able to these days. I think this is a real improvement on Gopher, but it has the unfortunate side-effect that the aberrant behaviour of faux menu phlogs in Gopher is the default behaviour of all gemlog posts, since parsing a text/gemini response always rebuilds the single in-memory menu structure. This means the `previous` and `next` commands in AV-98 work in bizarre, mysterious ways, applying index arithmetic for one menu to a different menu. They are basically impossible to use meaningfully, but they still cause something to happen some of the time, which must be incredibly confusing for people trying to figure out how they work. I feel bad about this, and it's why I've been meaning to remove them.
But functioning previous/next navigation is so nice, maybe it's worth salvaging. This would only require altering AV-98 to maintain two menu structures in memory: one for the current page, and one for the page from which you arrived at it, with previous/next applying to the latter. This shouldn't be too hard.
Finally, a bit of shameless promotion for the `tour` command, which works identically in VF-1 and AV-98. This is my favourite advanced navigation tool, and I'm constantly confused that it hasn't been widely imitated. It's nothing but a FIFO queue of links. When you arrive at a menu, you can queue up links using their indices. Let's say you load up CAPCOM or Bongusta, and you look over the most recent updates. You decide you're interested in reading some but not all of the recent posts, say those with indices 1, 2, 4 and 6. You just type the following (`t` is an alias for `tour`):
t 1 2 4 6
And then each time you just type `t` without an argument, VF-1/AV-98 will navigate to the next URL in the queue. This works kind of like repeatedly using `next` to move sequentially through log posts, except it lets you easily skip positions in a menu sequence, and it works no matter how far you roam from one of the "waypoints" on your tour. Say you read the second log post you queued up, and you enjoy it a lot and want to see what else the author has done. You can use `root` to get to their homepage, and have a look around, and then later use `t` to move to the third log post you queued up, even though you've possibly parsed a great many menus since you set up the tour, which would break your ability to use `previous` or `next`. Alternatively, you could use an RC file to setup a tour of your favourite Gopher/Gemini sites automatically upon start up, making it quick and easy to "do the rounds". It's a very powerful and flexible tool, and I wouldn't want to be without it.
That's not to say it couldn't still be improved. You can append new waypoints to a tour while it's in progress, and I often do, but they always get appended to the end of the queue. Sometimes I'd like the power to decide whether a new waypoint gets added to the end or the start of the queue. Especially in Gopherspace. For various reasons, when you follow a link from Bongusta or a moku-pona update page, you usually don't end up at an actual post, but rather a menu of posts. Sometimes when you do so you'll find that the author has written more than one thing since you were last there. If you use `tour` to queue up all the unread posts, you don't actually get to see them until you've visited *all* the sites you queued up at Bongusta. It still works, but it's kind of disorienting. I'd like to be able to fully explore a single site and then move on to the next one. It's true that using `next` would actually work quite nicely here, and maybe I should try to make a habit of that, but I still pine for a more flexible `tour`.
But this post is, ultimately, not really about how neat AV-98 and/or VF-1 are. It's a hearty endorsement of the idea that we should think outside of the box and experiment when it comes to navigation in Geminispace, and in particular try really hard to leverage the fact that, unlike the web, Gemini allows and in fact strongly encourages links to be structured as logically related lists, and for links to have descriptive labels which don't need to fit smoothly into the flow of written text and which make sense when they standalone. One could, for example, build a graphical or curses-based Gemini client which used Miller columns to simultaneously display all outgoing links from the previous n pages in the history. I don't know how nice an experience this would necessarily provide, but it seems worth a shot. It's not something which would work at all on the web, and that's exactly the kind of option we should explore.