๐พ Archived View for gemi.dev โบ gemini-mailing-list โบ 000904.gmi captured on 2024-08-19 at 02:30:59. Gemini links have been rewritten to link to archived content
โฌ ๏ธ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hi all, I have a question on a common design pattern in gemini. Say we have a guestbook, message board, etc. that accepts user comments via an input query. A normal session with a client might look like this: ``` C: / S: 20 text/gemini (display the home page) C: /guestbook S: 20 text/gemini (display the guestbook page) C: /guestbook/input S: 10 enter your message C: /guestbook/input?hello%20world S: 30 /guestbook (submit the user's message and redirect) C: /guestbook S: 20 text/gemini (display the guestbook page) ``` Now, what should happen at this point when the user clicks the "back" button in their client? A. The client resubmits "/guestbook/input?hello%20world". This is not desired because it will result in double posting the message. This same problem is solved on the web using the Post/Redirect/Get pattern [1]. I suppose the gemini equivalent would be "don't store requests that return 3x in the client's history". With this rule, queries like GUS searches would still be cached because "gemini://geminispace.info/search?hello" returns a 20 response. B. The client re-prompts the user with "enter your message". I've seen a few (most?) clients do this and it's a pretty jarring experience as a user, because I did not click on a link first to prime the input prompt. IMO we should also make a rule "don't store requests that return a 1x in the client's history". There's no web equivalent for this that I could find. C. The client loads "/", which is the latest cached request before the current page. This seems like the desired behavior to me. Thoughts? - Michael [1] https://en.wikipedia.org/wiki/Post/Redirect/Get
Hi Michael, first thing is that every gemini-site should avoid to put the user into a situation where the "back" button is the only way out, by providing arbitrary links. And i agree with you, option "c" looks like what i would expect to see when clicking on the "back" button. Another option is to give the end-user the choice of where back in the history to go, like if you right-click on the "back" button in the chromium browser. Best regards from Charleston (WV), ย ย ย ย Frank/2 On 2021-05-17 12:49, Michael Lazar wrote: > Hi all, > > I have a question on a common design pattern in gemini. Say we have > a guestbook, message board, etc. that accepts user comments via an > input query. A normal session with a client might look like this: > > ``` > C: / > S: 20 text/gemini (display the home page) > > C: /guestbook > S: 20 text/gemini (display the guestbook page) > > C: /guestbook/input > S: 10 enter your message > > C: /guestbook/input?hello%20world > S: 30 /guestbook (submit the user's message and redirect) > > C: /guestbook > S: 20 text/gemini (display the guestbook page) > ``` > > Now, what should happen at this point when the user clicks the > "back" button in their client? > > A. The client resubmits "/guestbook/input?hello%20world". This is not > desired because it will result in double posting the message. This > same problem is solved on the web using the Post/Redirect/Get > pattern [1]. I suppose the gemini equivalent would be "don't store > requests that return 3x in the client's history". With this rule, > queries like GUS searches would still be cached because > "gemini://geminispace.info/search?hello" returns a 20 response. > > B. The client re-prompts the user with "enter your message". I've > seen a few (most?) clients do this and it's a pretty jarring > experience as a user, because I did not click on a link first > to prime the input prompt. IMO we should also make a rule "don't > store requests that return a 1x in the client's history". There's > no web equivalent for this that I could find. > > C. The client loads "/", which is the latest cached request before > the current page. This seems like the desired behavior to me. > > Thoughts? > > - Michael > > [1] https://en.wikipedia.org/wiki/Post/Redirect/Get -- ------------------------------------------------------------------------ My Gemini Capsule's orbit is gemini://h2903872.stratoserver.net ------------------------------------------------------------------------
On Mon, 17 May 2021 at 18:02, Frank Jรผdes <Frank.Juedes@linux4specialists.com> wrote: > > Hi Michael, > > first thing is that every gemini-site should avoid to put the user into a situation where the "back" button is the only way out, by providing arbitrary links. > I disagree with this, there are many times I don't want to add a back link, and it's not always possible if you have non-gemtext content. A hard-coded "back" link is flawed anyways, as the server has no clue where the user came from. It can only be an "up" link or go to the most common place that this page is linked from. -Oliver Simmons
On Mon, 17 May 2021 at 17:50, Michael Lazar <lazar.michael22@gmail.com> wrote: > > Hi all, > > I have a question on a common design pattern in gemini. Say we have > a guestbook, message board, etc. that accepts user comments via an > input query. A normal session with a client might look like this: > > ``` > C: / > S: 20 text/gemini (display the home page) > > C: /guestbook > S: 20 text/gemini (display the guestbook page) > > C: /guestbook/input > S: 10 enter your message > > C: /guestbook/input?hello%20world > S: 30 /guestbook (submit the user's message and redirect) > > C: /guestbook > S: 20 text/gemini (display the guestbook page) > ``` > > Now, what should happen at this point when the user clicks the > "back" button in their client? > > โsnipโ The way I would like it is: ``` C: / S: 20 text/gemini (display the home page) Stored in history C: /guestbook S: 20 text/gemini (display the guestbook page) Stored in history C: /guestbook/input S: 10 enter your message Not stored due to it being an input (resp. code 1x) C: /guestbook/input?hello%20world S: 30 /guestbook (submit the user's message and redirect) Redirect not stored, the page redirected to should be stored (resp. code 3x) C: /guestbook S: 20 text/gemini (display the guestbook page) Stored in history. It's a duplicate of the previous page in history though, so it should probably be removed. ``` That is, response codes 1x and 3x aren't stored in history, and duplicates of the same URI (including query!) in history are merged into one. It's not the query that makes it not store, it'd be the response code. So if /guestbook/input?hello%20world gave a 20 response code instead it would be stored, as that's likely a unique page e.g. search results or generated content. This shouldn't be required behaviour, it'd be a "best practice" recommendation instead. Different browsers have different preferences and in an ideal world this would be configurable by settings. -Oliver Simmons
On Mon, May 17, 2021 at 12:49:43PM -0400, Michael Lazar <lazar.michael22@gmail.com> wrote a message of 49 lines which said: > B. The client re-prompts the user with "enter your message". I've > seen a few (most?) clients do this and it's a pretty jarring > experience as a user, because I did not click on a link first > to prime the input prompt. IMO we should also make a rule "don't > store requests that return a 1x in the client's history". There's > no web equivalent for this that I could find. I just tested with Lagrange and the bulletin board <gemini://station.martinrue.com/> and this is the behaviour I get and I'm fine with it.
---