Cognitive aspects of navigation in gemini space

[Luke Emmet]

Hello
> I understand entirely where you are coming from.  An idea I've had for
> a while now (I don't remember if I've mentioned it here before) is that
> it would be nice if a graphical Gemini browser used a different
> foreground and background colour (and perhaps even a different font?)
> for different domains (subdomains)?  This would be something the client
> would do itself, with no possibility of control or influence from the
> server - it would just use the domain as the seed to a PRNG which chose
> a new scheme.  This would then give different sites their own subtly
> distinct look and feel, which a user could learn to recognise in time.
> I have no idea how feasible this is: programmatically generating
> genuinely pleasant colour schemes is certainly not straightforward.

This is interesting, something like the sigils in Urbit, or Gravitar 
that are automatically generated from
some identifier?

https://urbit.org/blog/creating-sigils/

https://en.gravatar.com/site/implement/

And so when you were on a "site" the content would be labelled/decorated 
in a simple yet consistent way

I think that could work.

If it is for the client to decide, how do we determine the "scope" of a 
site:

1.  If it is one per domain then that works, but I suppose that is not a 
universal
     assumption a client can make as many gemini spaces might be hosted 
on the same domain.

2. Full path - is very specific, but it would mean the placemarker would 
change with every request.

3. The author indicates it somehow

4. ?

It would be good perhaps if the author could optionally provide a seed 
site id as part of the content.

e.g. "site-name: Mysite" or other such pre-defined, not extensible 
syntax (we have headings, bullets, links...). Maybe the @symbol is 
awaiting such a role

"@ MySite"

This can be ignored by any disinterested client and is just text in the 
document that CLI readers can read without polluting the content with 
metadata.

> The idea of favicons has been mentioned before in a gemlog post:
>
> gemini://mozz.us/journal/2020-04-17.gmi
>
> I have a couple of big concerns here:
>
> One is that right now Gemini is strictly one-request-per-resource and a
> lot of people, myself included, consider that a really desirable
> property.  Anything like favicons or CSS would remove that property, no
> matter how light weight they were.  It's true that at least the second
> request would go to the same server as the first so this doesn't
> actually destroy predictability or control of which servers your client
> connects to, which is one of the arguments in favour of the one request
> thing.

I don't see the single request per resource is really violated here, 
since it is optional and not required to understand the content. But if 
that is really a worry
the client side option might work.

Maybe the favicon thing is just a convention that authors could include 
or not. The client could search up the url path and show the first one 
it finds, or none


> Another is that, philosophically, I kind of feel like styling *should*
> be under the control of the client and not the server.
That is OK, but maybe the server can hint.
>   Some people have
> strong preferences for light text on dark backgrounds, for example,
> because they have problems with eye strain the other way around.
Agree
> Right
> now on the web this is really only possible if the author deigns to
> provide the option (as Stack Overflow recently did, to much fanfare).  I
> think that's totally backwards.  Give the power over styling to the
> people who actually have to read the content, let them read your stuff
> in the way that works best for their eyesight and that *they* find
> aesthetically pleasing.  I realise this reduces some of the scope for
> self-expression on the part of Gemini content authors, but there's more
> than enough scope for that in the actual *content* they produce (if not,
> there are bigger problems...).
>
> <snip>
> I'd be much more interested in us exploring innovative possibilities
> which are strictly under the control of the client, like keying the
> styling to the domain as I mentioned earlier.  I'm not saying that exact
> approach necessarily is the best way to do it, or even a good way.  But
> it's *a* way to do it which doesn't run afoul of any of the issues above
> and that kind of out-of-the-box thinking is a good direction to take,
> IMHO.

-- 
______________________________________

Orlando Lutes
http://www.orlando-lutes.com