re: experimenting with ways to format documents on gemini

the original post by nytpu

Introduction

Reading nytpu's post on formatting definitely got me thinking about formatting my gemlog and gemini site. When first building it, I realized how much there is to think about (even in a simple system like gemini).

How do I handle navigation? A menu system? Do I need a back link?

This looks great on bombadillo, but how does it look on other clients?

Then of course after reading nytpu's article, how do I handle links?

Are there any courtesies we could do w/ links? Should we hide the URL? Should we show it? Should we specify the protocol or leave that up to the browser?

What about if the author specified the client used to design their site for a "best viewing experience"?

My Thoughts

When building my site, I decided to go with a menu system that sits at the bottom of every page. I kept it at the bottom to keep the main content first and easily accessible. I chose links for the tabs you can go to, and h3 for the current tab. Of course, this looked fine on a pure text based browser, but when you start using other browsers, h3 renders differently and can look terrible. I'm definitely rethinking the navigation system.

In regards to links, I think nytpu has it right. Basically group the links as footnotes at the bottom of a section.

The option for headers is nice. I tend to keep h1 as the title, while using h2 as my section headers. If I need to use subsections, h3 is it.

This is all building up and becoming a lot to keep track of when writing, and this leads me to my next point: maybe there should be a new standard[1] or style guide that people can use to help keep geminispace easier to read and less messy.

[1] https://xkcd.com/927 (no, we don't need another standard)

Why a style guide?

Design & Consistency

So a style guide is somewhat enforced by the limited tools available to formatting text in a gmi file. It's awesome. But, if I wanted to write this article as one long h1 sentence, I could, and that would be awful. Also, it keeps consistency across a website and if multiple people use it, across the geminispace.

A system allows automation

Since gemini does have a specification, one could create frameworks or templates for generating content more easily. Something like bb[2] could be setup to export gmi files translated from Markdown or HTML. Now, this could technically be done without an additional style guide, but a style guide would make it a bit easier. i.e. by denoting # as the title for instance. Or, some kind of tool could be developed to parse files and insert "components" (i.e. a menu component everywhere there is a $menu).

[2] https://tildegit.org/team/bashblog

Conclusion

I'm going to begin developing a style guide and possibly other tools to aid in building my gemini site and gemlog. I'd love to work with others on this so I will be hosting this on tildegit[3]. Please feel free to open PRs and contribute to the discussion! Of course this should never amount to anyting more than a guide for users to pick and choose from or some kind of framework to start with.

[3] https://tildegit.org/swiftmandolin/gemini-style-guide