solderpunk solderpunk at SDF.ORG
Thu May 14 19:21:04 BST 2020
- - - - - - - - - - - - - - - - - - - ``` Howdy, On Thu, May 14, 2020 at 04:55:56PM +0100, Luke Emmet wrote: > And I particularly have enjoyed reading the discussion about > text formatting and bullets... no, seriously. Seek help! :p Just kidding, welcome to Gemini! > My question is really about how we can support cognitive aspects of user > navigation through gemini-space. I understand and largely endorse the > reasons for the simple text based protocol and format. However at the > moment, browsing gemini-space is a very homogenous experience (each page > looks the same as others). So it is not so clear to the user whose page you > are on. I understand entirely where you are coming from. An idea I've had fora while now (I don't remember if I've mentioned it here before) is thatit would be nice if a graphical Gemini browser used a differentforeground and background colour (and perhaps even a different font?)for different domains (subdomains)? This would be something the clientwould do itself, with no possibility of control or influence from theserver - it would just use the domain as the seed to a PRNG which chosea new scheme. This would then give different sites their own subtlydistinct look and feel, which a user could learn to recognise in time.I have no idea how feasible this is: programmatically generatinggenuinely pleasant colour schemes is certainly not straightforward. > Is there a simple and gemini-friendly way for us to (optionally!) convey > this sense of place. For example, to set a simple global favicon or > background colour for pages on a certain site. It could help with user's > task of navigation and understanding exactly where they are. I know there > are lots of CLI junkies around here, so maybe this hasn't been a priority so > far. 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 alot of people, myself included, consider that a really desirableproperty. Anything like favicons or CSS would remove that property, nomatter how light weight they were. It's true that at least the secondrequest would go to the same server as the first so this doesn'tactually destroy predictability or control of which servers your clientconnects to, which is one of the arguments in favour of the one requestthing. Another is that, philosophically, I kind of feel like styling *should*be under the control of the client and not the server. Some people havestrong preferences for light text on dark backgrounds, for example,because they have problems with eye strain the other way around. Rightnow on the web this is really only possible if the author deigns toprovide the option (as Stack Overflow recently did, to much fanfare). Ithink that's totally backwards. Give the power over styling to thepeople who actually have to read the content, let them read your stuffin the way that works best for their eyesight and that *they* findaesthetically pleasing. I realise this reduces some of the scope forself-expression on the part of Gemini content authors, but there's morethan enough scope for that in the actual *content* they produce (if not,there are bigger problems...). (of course, this is kind of a weak argument against CSS-light in Gemini,because actually honouring the settings would be optional and clients could ignore them and use the user's preferences instead) The biggest concern is (no surprises to regular readers here!) is thatit's really hard to do this in a way that's not extensible. With thebest of intentions we'll specify a strictly optional CSS-ultralightthing which can only choose background and foreground colours from asmall fixed pallette...and then some client will implement one extraoptional feature, and it'll be popular, so then other clients will copyit, and the whole thing snowballs until people start to think of theseunofficial extensions as a real part of Gemini, and strictlyspec-adherent clients which don't support them as "broken". This exactstory happened many times over with the web and I'm terrified of thesame things happening to Gemini. It's why I've tried at every turn inthis project to avoid adding in anything that feels like it will bereally easy to extend in new directions. I'm not opposed to hearing ideas, but I have a hard time imagining muchcan be done in the way of ultralight optional styling which doesn'tviolate the non-extensibility principle. I'd be much more interested in us exploring innovative possibilitieswhich are strictly under the control of the client, like keying thestyling to the domain as I mentioned earlier. I'm not saying that exactapproach necessarily is the best way to do it, or even a good way. Butit's *a* way to do it which doesn't run afoul of any of the issues aboveand that kind of out-of-the-box thinking is a good direction to take,IMHO. Hope you're not too disappointed by this response, feel free to(politely, constuctively!) argue back against any of this. Thanks foryour interest and welcome to Gemini! Cheers,Solderpunk