I?m a bit afraid to open the lightning-bottle of this list, but feel compelled to bring my design day job to my geek hobbies. So, let me step onto the metaphorical slope with my three wishes for the UX of Geminispace: ## Capsule branding It?s important for users to experience a sense of place as they navigate (as per Luke Emmet?s ?cognitive aspects? thread from May 2020) but also important to give content creators some control over the presentation of their text. Already we see extensive use of ASCII art. This is retro-cool but I would argue favicons or theme colors are actually *more* minimal, and also more attractive to 21st century users. Personally, I would be happy if this was hostname-level metadata. But I don?t feel strongly enough about this to argue over favicon.txt. ;-) ## Line orientation The spec is already clear about this but let me add a new rationale: the line-by-line orientation of gemtext is a huge strength. It will enable a vibrant ecosystem of clients and also UI models: I?m experimenting with a few ideas that simply wouldn?t work with HTML. Thus, I hope to see no more additions with modes like preformatting. This means I would twist Oliver Simmons?s proposal for appended metadata to something more like: ^^^ author: Hans Gerwitz ^^^ color: #00FF00 ## Inline images I appreciate the need to avoid spurious network requests, especially across servers. But rules like ?user takes action? are impossible to enforce (and scrolling is an action). I?d like to recognize the inevitability of inline media display and specify some clear rules before we end up with unpredictable behaviors across clients. E.g. clients MAY fetch linked content for inline rendering IF the link URL points to the same server (no scheme or hostname). Clients MUST allow users to disable this auto-fetching. Clients MUST NOT fetch content of unrecognized type. [Unaddressed: how to recognize type? Mime type parameter? ?File extensions? on the URL?] Thanks for reading! ? Hans Gerwitz gemini://tilde.club/~gerwitz
On Mon, Feb 22, 2021 at 09:07:20PM +0100, Hans Gerwitz wrote: >It?s important for users to experience a sense of place as they >navigate (as per Luke Emmet?s ?cognitive aspects? thread from May 2020) >but also important to give content creators some control over the >presentation of their text. > >Already we see extensive use of ASCII art. This is retro-cool but I >would argue favicons or theme colors are actually *more* minimal, and >also more attractive to 21st century users. I think that the lack of aesthetic branding is one of the best parts of the Gemini space. Capsules should be distinguished by content, not appearance. Presentation should be up to the user-agent, not the authors. If branding is important for a site, then the Web is probably a better fit for it than Gemini or Gopher. >I appreciate the need to avoid spurious network requests, especially >across servers. But rules like ?user takes action? are impossible to >enforce (and scrolling is an action). Actions equivalent to navigation should work. When navigating to a link pointing to an image, displaying that image inline should suffice. Scrolling isn't sufficient because users can't see what's "below the fold" and therefore can't consent to sending a network request to an unknown resource. This could also be used for tracking; authors could "measure" how far a reader as scrolled by seeing which images got loaded. Inline images should only be used if they're a necessary part of the content and alt-text won't suffice. Readers should be able to decide if this is the case from the context and make a decision; the decision should not be made by authors. -- /Seirdy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210222/928a aa60/attachment.sig>
On 2/22/21 9:07 PM, Hans Gerwitz wrote: > I appreciate the need to avoid spurious network requests, especially > across servers. But rules like ?user takes action? are impossible to > enforce (and scrolling is an action). I?d like to recognize the > inevitability of inline media display Firstly, "[when the] user takes [an] action" is a misrepresentation of the consensus about making additional network connections, which I'd summarise instead as "when the user explicitly requests that specific additional network connection". Secondly, this is currently not a 'rule' - the actual rule in the spec (?5.4.2) is: > however clients MUST NOT automatically make any network connections > as part of displaying links whose scheme corresponds to a network > protocol ...which is technically much more permissive. However, the intent behind this rule is clearly to improve privacy and reduce waste of bandwidth, so the practical interpretation of the rule is a lot stricter than just the "not automatically" in the spec. The 'rules' in Geminispace are not just determined by the spec, but also by the culture around Gemini, and they not "enforced" by some official authority, but rather through interactions between people. That alone means that auto-fetching inline media is clearly not "inevitable". In general, it makes for unpleasant discussion when you assert something without sufficient reasoning as a /fait accompli/, as an "inevitability" that you are just "recognising". -- pjvm
On 22-Feb-2021 20:32, Rohan Kumar wrote: > On Mon, Feb 22, 2021 at 09:07:20PM +0100, Hans Gerwitz wrote: >> It?s important for users to experience a sense of place as they >> navigate (as per Luke Emmet?s ?cognitive aspects? thread from May >> 2020) but also important to give content creators some control over >> the presentation of their text. >> >> Already we see extensive use of ASCII art. This is retro-cool but I >> would argue favicons or theme colors are actually *more* minimal, and >> also more attractive to 21st century users. > > I think that the lack of aesthetic branding is one of the best parts > of the Gemini space. Capsules should be distinguished by content, not > appearance. Presentation should be up to the user-agent, not the > authors. If branding is important for a site, then the Web is probably > a better fit for it than Gemini or Gopher. Hello This is not an either-or as I see it. We can have both a sense of place to assist navigation and memory AND at the same time avoid server side branding and attempts at aesthetic control. My investigations in this direction led me to implement auto-theming in the client. The server has to specify nothing, but the client creates an automatic theme based on the site identity derived from the URL. For details see the auto "fabric" theme for GemiNaut client: gemini://gemini.marmaladefoo.com/geminaut/ To my mind this is sufficient to demonstrate that there is no need for any server controlled colours, fonts, favicons or the like - and at the same time we can build attractive UI experiences for the end user that are content-focussed and can assist the user in finding their way around. ?- Luke
Hans Gerwitz writes:
> ## Capsule branding
Branding and brand-building are the banes of modern society, and only
useful to the vectorialist class, never the hacker class.
> It?s important for users to experience a sense of place as they
> navigate (as per Luke Emmet?s ?cognitive aspects? thread from May
> 2020) but also important to give content creators some control over
> the presentation of their text.
If you want control over the presentation of your text, serve a PDF. The
uniformity of Gemini pages is a feature. The way Lagrange and Geminaut
auto-style pages is a good way of providing a sense of place without
giving the author another lever to abuse.
>
> I appreciate the need to avoid spurious network requests, especially
> across servers. But rules like ?user takes action? are impossible to
> enforce (and scrolling is an action).
Note that loading images on scrolling allows a particularly nasty kind
of behavioral tracking ? you can know how far the user scrolled down the
page, and how long it took them to get to that point.
I do think that "display inline, on click" is a reasonable behavior in a
graphical browser, though I personally would rather images load in a
dedicated image viewing tool.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
On Mon, Feb 22, 2021 at 5:40 PM Luke Emmet <luke at marmaladefoo.com> wrote:
> My investigations in this direction led me to implement auto-theming in
> the client. The server has to specify nothing, but the client creates an
> automatic theme based on the site identity derived from the URL. For
> details see the auto "fabric" theme for GemiNaut client:
>
Lagrange does this too: it chooses a Unicode character and a color when you
load a document from a new host, and remembers it.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
You know, you haven't stopped talking since I came here. You must
have been vaccinated with a phonograph needle.
--Rufus T. Firefly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210222/62f2
8554/attachment.htm>
On 23. Feb 21, at 5.50, John Cowan <cowan at ccil.org> wrote: > Lagrange does this too: it chooses a Unicode character and a color when you load a document from a new host, and remembers it. And in the upcoming v1.2, you get to change the icon to whatever character you want via the GUI. There is a simple input field that accepts a single character. => https://github.com/skyjake/lagrange/issues/140#issuecomment-783864956 Adventurous users might even write a script that goes through the bookmarks.txt file and attempts to fetch the favicon.txt of each bookmark, if that is something one finds useful. I don't currently have plans to implement automated or manual fetching of these via the app. As I mention in the linked comment, IMO the user should ultimately be in control of bookmark (site) icons so that they can be used to convey a personal meaning. Unicode characters / Emoji can be open to interpretation; when selecting the set of random icons that Lagrange uses I tried to keep them somewhat neutral, with varying levels of success. My longer term plan is to allow further customization for site theming, including setting per-site color themes. --jaakko
On 2/22/2021 10:08 PM, skyjake wrote: > On 23. Feb 21, at 5.50, John Cowan <cowan at ccil.org> wrote: > >> Lagrange does this too: it chooses a Unicode character and a color when you load a document from a new host, and remembers it. > > And in the upcoming v1.2, you get to change the icon to whatever character you want via the GUI. There is a simple input field that accepts a single character. > > => https://github.com/skyjake/lagrange/issues/140#issuecomment-783864956 > Good! Coz I like the little horsey it picked for Vger :) > --jaakko > -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
---