Cognitive aspects of navigation in gemini space

[Ivy Foster]

On 17 May 2020, at  5:19 pm +0200, Brian Evans wrote:
> _jan6 writes:_
> > I'm not a fan of the ending part having text too, slightly harder
> > parser, and noticeably harder to read for humans, especially if
> > there are several blocks back-to-back

> I'm not sure about this. It seems to me that someone parsing by line can
> just set a flag for `in_pre_block`.  When they get to a line beginning
> with ``` they know the pre block has ended. Sounds dead simple to me.

> As to harder for humans, the whole point is to make it easier for
> humans. The ``` and text should not appear to most users. It is not
> for them, it is for the client. Having the opening ``` with a type of
> some form allows a client to offer options such as "show ascii art"
> and "show pre text" as boolean options. If someone chose to set "show
> ascii art" to to false for the below:

> ``` art
> :-)
> ``` A simple smiley
> The client could display:

> [art: A simple smiley]

> I would go so far as to recommend this be a requirement for preformatted
> blocks in accessibility merits alone.  I think there should be three
> types: Art, Text, Code and that descriptions on the end blocks should
> be compulsory.

I like the idea of severely limiting the available block-type options.

How about this for block syntax, with the understanding that the alt
text is highly recommended for accessibility. Specifying the block
type and the programming language or written language (as appropriate)
would be strictly optional: those that wanted to make use of them
could, those who did not want to make use of them would not have to.

For the purposes of this proposal, there would be *no space* between
the backticks and the optional content-type field, which field may not
contain spaces. There must be at least one space on the line before
the (recommended) alt text. That way, the client doesn't need to try
and figure out where one ends and one begins: the instant the client
sees a space, we're into alt-text territory for the rest of the line.

```[art | code[:programming language] | text[:written language]] [alt text]
...
```

So, e.g.,

```code:c The Laziest Hello World
#include "real_hello_world.h"
```

```text:fr_FR Antoine de Saint-Exupéry on perfection
	Il semble que la perfection soit atteinte non quand il n'y a
	plus rien à ajouter, mais quand il n'y a plus rien à
	retrancher.
		-- Terre des Hommes, 1939
```

``` This is a block with just alt text.
You know, I think the alt text is better than the content this time.
```

What the client does with the alt text and the block type, if
anything, is up to the author.

I think this way, it would be both nicely readable to a human reading
the source text/gemini, without sacrificing ease of parsing. Just
throwing an idea at the wall to see whether it sticks.

Cheers,
Ivy Foster
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200517/d7fa247d/attachment.sig>