Pondering interfaces over the Gemini 1x responses (was: CGI)

Hi! On Sat, 18 Jul 2020 at 16:47, Paul Boyd <boyd.paul2 at gmail.com> wrote: > Anyway, I'm probably not going to write something like this again. The guestbook is kind of fun (Hello K?vin and Timur!), so I'll leave it up. But I'll stick to things that fit better in the future. I think it's really valuable to *try* all kinds of things and different approaches to see *what* fits well. IMHO we have only scratched the surface of what is possible with the Gemini protocol (and what makes for good UX). To summarize what has been discussed here: 1. Filling in multiple values is not trivial with the input response type 2. One way is to generate a session id on the server. (This is stateful, which has some downsides but avoids replay issues.) 3. Another way is to embed all the responses in the URL. Some ideas that haven't been mentioned: a. If you include all the fields at once, you could just ask for them in one request. Eg. "10 name;location;link;comment" which the user is smart enough to parse and respond with "Hannu;;;This is cool!". Or for a better UX, make the fields newline-separated (ie. %0A in the URL) and have multiline-capable input fields in browsers. Note: this is against a strict interpretation of the spec but hasn't been discussed AFAIK. b. Instead of having different links for different fields, you could ask for the fields in succession (but this only works well for the session id based approach). Eg. /guestbook/sign responds with "30 /guestbook/sign/aF3d", then /guestbook/sign/aF3d responds with "10 Name", /guestbook/sign/aF3d?Hannu with "10 Location (optional)", then "10 Link (optional)" and "10 Comment" in sequence, saving each query string to the server-side session. After the final response either save the comment or show the responses with a link to save. I personally think the Gemini protocol (as it currently is) can be as powerful as the UNIX command line (note: only CLI, not TUI). In fact, you could serve a remote shell over Gemini. Of course we're all spoiled by interactive software even in a terminal so Gemini feels quite limited. -Hannu

I did consider a succession of inputs. I think we can all agree that a succession of modal inputs is irritating, and the UI would be exactly that on most clients. Asking the user to use a separator seemed error prone, so I didn't want to do that either. I know it can work. makeworld's gemlikes has a prompt of: > Enter your username, a space, and your comment Usernames don't have spaces, and comments do, so this works great here. I'm just not sure people are going to get "name;location;link;comment" right consistently. I certainly wouldn't, I'd end up with "paul;;my comment" instead of "paul;;;my comment" and get my comment in the link field. Your UNIX command-line comment is interesting. One set of input args is enough for UNIX, so maybe getopt style flags? --name John --location "From Beyond" --comment "This is what I have to say" A form still seems right for a guestbook (the real-life version is a form after all). But there ought to be something interesting we can do with flags on the input line. Maybe an ASCII art drawing program? With inputs like "line --from 0,0 --to 10,10". Paul On Sun, Jul 19, 2020 at 5:28 AM Hannu Hartikainen < hannu.hartikainen+gemini at gmail.com> wrote: > Hi! > > On Sat, 18 Jul 2020 at 16:47, Paul Boyd <boyd.paul2 at gmail.com> wrote: > > Anyway, I'm probably not going to write something like this again. The > guestbook is kind of fun (Hello K?vin and Timur!), so I'll leave it up. But > I'll stick to things that fit better in the future. > > I think it's really valuable to *try* all kinds of things and > different approaches to see *what* fits well. IMHO we have only > scratched the surface of what is possible with the Gemini protocol > (and what makes for good UX). > > To summarize what has been discussed here: > 1. Filling in multiple values is not trivial with the input response type > 2. One way is to generate a session id on the server. (This is > stateful, which has some downsides but avoids replay issues.) > 3. Another way is to embed all the responses in the URL. > > Some ideas that haven't been mentioned: > > a. If you include all the fields at once, you could just ask for them > in one request. Eg. "10 name;location;link;comment" which the user is > smart enough to parse and respond with "Hannu;;;This is cool!". Or for > a better UX, make the fields newline-separated (ie. %0A in the URL) > and have multiline-capable input fields in browsers. Note: this is > against a strict interpretation of the spec but hasn't been discussed > AFAIK. > > b. Instead of having different links for different fields, you could > ask for the fields in succession (but this only works well for the > session id based approach). Eg. /guestbook/sign responds with "30 > /guestbook/sign/aF3d", then /guestbook/sign/aF3d responds with "10 > Name", /guestbook/sign/aF3d?Hannu with "10 Location (optional)", then > "10 Link (optional)" and "10 Comment" in sequence, saving each query > string to the server-side session. After the final response either > save the comment or show the responses with a link to save. > > I personally think the Gemini protocol (as it currently is) can be as > powerful as the UNIX command line (note: only CLI, not TUI). In fact, > you could serve a remote shell over Gemini. Of course we're all > spoiled by interactive software even in a terminal so Gemini feels > quite limited. > > -Hannu > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200719/840f7d8a/attachment.htm>

On Sun Jul 19, 2020 at 2:59 PM CEST, Paul Boyd wrote: > I did consider a succession of inputs. I think we can all agree that a > succession of modal inputs is irritating, and the UI would be exactly > that > on most clients. To my mind this is the canonical way of getting multi-part input: use client certificates to establish a persistent session and then just have the server send successive responses with status code 10. I agree this would be irritating in a GUI client that pops up a box akin to a HTTP basic auth login box every time, but that's more an argument against that being a good UI design than against this being a good way to handle this kind of input. This approach is what the protocol makes natural/obvious, and so it makes sense to design UIs to match it. In an UI like AV-98, this approach works exceptionally well and provides a look and feel that's almost indistinguishable from using a shell, or a terminal application with a REPL interface. That's a very powerful thing which we still haven't even begun to experiment with the power of. I realise something like AV-98 is not a comfortable "daily reading" interface for most people. Of course, there are probably ways to make this approach pleasant to use in a GUI client - people are very welcome to work on that. I also still think that having separate clients for reading static text and using remote applications makes a lot of sense. It's not necessarily a good match to quick and easy, low-effort interactivity - but then, that was never the goal. Cheers, Solderpunk

You could have a sort of landing page for the form, using client certificates, that looks something like Foo: $foo => /form/foo Enter Foo Bar: $bar => /form/bar Enter Bar => /form/submit Submit Form where it displays the current value (if it exists), each associated link allows that value to be input/changed, and then the submit link marks the whole form as ready to be processed. You could even substitute "Please fill out all fields" or something for the last link until the required information is all available. On July 19, 2020 10:01:51 AM EDT, Solderpunk <solderpunk at posteo.net> wrote: >On Sun Jul 19, 2020 at 2:59 PM CEST, Paul Boyd wrote: >> I did consider a succession of inputs. I think we can all agree that >a >> succession of modal inputs is irritating, and the UI would be exactly >> that >> on most clients. > >To my mind this is the canonical way of getting multi-part input: use >client certificates to establish a persistent session and then just >have >the server send successive responses with status code 10. > >I agree this would be irritating in a GUI client that pops up a box >akin >to a HTTP basic auth login box every time, but that's more an argument >against that being a good UI design than against this being a good way >to handle this kind of input. This approach is what the protocol makes >natural/obvious, and so it makes sense to design UIs to match it. > >In an UI like AV-98, this approach works exceptionally well and >provides >a look and feel that's almost indistinguishable from using a shell, or >a >terminal application with a REPL interface. That's a very powerful >thing which we still haven't even begun to experiment with the power >of. > >I realise something like AV-98 is not a comfortable "daily reading" >interface for most people. Of course, there are probably ways to make >this approach pleasant to use in a GUI client - people are very welcome >to work on that. I also still think that having separate clients for >reading static text and using remote applications makes a lot of sense. >It's not necessarily a good match to quick and easy, low-effort >interactivity - but then, that was never the goal. > >Cheers, >Solderpunk -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200719/b5c54698/attachment.htm>

On Sun, 19 Jul 2020 at 17:08, Solderpunk <solderpunk at posteo.net> wrote: > In an UI like AV-98, this approach works exceptionally well and provides > a look and feel that's almost indistinguishable from using a shell, or a > terminal application with a REPL interface. That's a very powerful > thing which we still haven't even begun to experiment with the power of. I was going to post something like this. The paradigm chosen by Gemini basically prevents GUI or TUI like applications, but it's great for console use. The web is already a universal GUI application platform, so Gemini can be something else. An interaction method like the one in AV-98 would be impossible for the web but it's amazing for Gemini. I believe this is a strength we're only beginning to understand. For example, consider the huge rise of podcasts and audiobooks: people love to listen to information. With Gemini it would be trivial to browse with a headset while commuting. The web, on the other hand, is horrible for screen reader use (ask any blind person). On Sun, 19 Jul 2020 at 15:59, Paul Boyd <boyd.paul2 at gmail.com> wrote: > Your UNIX command-line comment is interesting. One set of input args is enough for UNIX, so maybe getopt style flags? > > --name John --location "From Beyond" --comment "This is what I have to say" I like this idea! It also makes me wonder if single-line-capable data formats would be useful. Eg. edn {:name "Hannu" :comment "Hello world!"} and YAML {name: Hannu, comment: Hello world!}. (Both do suffer from unfamiliarity, though.) There must be a huge array of alternatives, most of them better than my CSV idea. -Hannu

* Sunday, 2020-07-19 at 16:01 +0200 - Solderpunk <solderpunk at posteo.net>: >To my mind this is the canonical way of getting multi-part input: use >client certificates to establish a persistent session and then just >have the server send successive responses with status code 10. > >In an UI like AV-98, this approach works exceptionally well and provides >a look and feel that's almost indistinguishable from using a shell *Except* that you can only have one line of output between each line of input, because 10 doesn't allow a body. This is rather limiting. Other than adding a new response code, the nicest way I see around this is a convention that clients should make it easy to rerequest the last URI with a new query parameter. This could be done for example with a user-enabled "REPL mode" in which the client repeatedly accepts a line of input from the user and uses it as a query parameter in a new request based on the current URI. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200719/343029d9/attachment.sig>

On Sun, 2020-07-19 at 17:50 +0200, mbays at sdf.org wrote: > *Except* that you can only have one line of output between each line > of > input, because 10 doesn't allow a body. This is rather limiting. > I think this can work because you use redirects in between (which is also what you need to do if you want to encode the answers in the URL). /story/123/comment/add 20 text/gemini\r Hello! We're going to ask you for a temporary certificate to establish a session, your name, and the comment, OK? If you're ready, click the link below! => ready /story/123/comment/ready 60 Please tell your client to generate a temporary certificate\r /story/123/comment/ready 20 text/gemini\r Excellent! First your name, then the comment, OK? If you're ready, follow the link below. => name /story/123/comment/name 10 Your name? \r 30 gemini://example.org/story/123/comment/name-ok /story/123/comment/name-ok 20 text/gemini\r Excellent, Alex. Thanks! Now for the comment. Please remember that you have about 900 characters. Follow the link below when you're ready. => comment 10 Let's have that comment!\r 30 gemini://example.org/story/123/comment/comment-ok /story/123/comment/comment-ok All-right! Got your comment. This is what we're going to save: "I love your post. Viagra cheap! -- Alex" Click the link below to save. => save 30 gemini://example.org/story/123 20 text/gemini\r Bla bla bla...