💾 Archived View for bbs.geminispace.org › s › Gemini › 352 captured on 2023-06-14 at 14:23:59. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
I'm not proposing a spec update or anything like that, yet (as that seems unlikely). This is just more of a question.
Is there anything that can be to tell a browser that an input field is long and should be displayed like a textarea preferably? For a search box or for simple question/answer type inputs the current input is appropriate.
But for longer fields, such a when posting on Bubble, it should be displayed more like the tweet box on Twitter.
The other solution to this problem is maybe browsers should just always treat an input as potentially long. I'm not sure what the max characters are for input, but it's pretty long, so you have to assume that some people will write a lot there.
2023-05-17 · 4 weeks ago
The Gemini protocol has no way of specifying if the expected input is long or not. There are only the response codes 10 and 11 that are specified for input prompts, and they only come with a human-readable label to show.
IMO the only reasonable way for a client to handle this is to allow input up to the max length of a Gemini request, which is 1024 bytes of percent-encoded UTF-8. Depending on which characters are being used and how long the URL path is, the actual maximum length is something like 600-700 characters.
@skyjake Yes, I know Gemini has no way to specify this, that's why I bring it up for discussion. Do people agree it's a problem (maybe some don't!) and if so, what should/can be done about it?
A client allowing input up to the max length is a good idea, does that mean that they should show a textarea like field by default? Does this make the UX of something like a search field worse if so?
Ah, so basically this is about UI design best practices.
I think there are two approaches that a client can take:
Much depends on the used GUI framework as it dictates what is feasible in practice. Personally I prefer the dynamic approach.
I think ideal would be the way Lagrange currently does it (dynamic) but with an option to go full screen/expand into a new tab. Not sure if that’s feasible but it would be nice.
This is because when writing for long periods of time it gets annoying to be stuck in a small part of the screen.
I like how qutebrowser (a web browser) does it: if you have focus on a input you write normally, but if you press a special shortcut then your favorite editor (configurable) opens up with whatever text you had already written, you write more, and then you save the file which triggers qutebrowser to read it and insert it into the original input. Basically, delegate the task of editing text to a text editor.
@satch Now that you mention it, I wouldn't mind an expanded input prompt with a larger size myself. The default dialog font that is used in Lagrange can be a bit tiny for actually composing a longer piece of text.
Maybe a nice solution would be for the Zoom In/Out keys to work in the input prompt to resize the dialog and the font.
@lufte Delegating to another app that does the job better is usually a great choice, however with Gemini in particular there is that maximum length limitation that is difficult to enforce in the external text editor...
My thoughts are that if the client can auto size in a fluid way, then it’s not good to try to make the server be in charge of it. I didn’t remember or notice that Lagrange handles this smoothly until @satch mentioned it.
2023-05-18 · 4 weeks ago
It would be great to have shortcut/button to expand the input area to half the page/full page.
2023-05-21 · 4 weeks ago
@shtirlic This is more of a client thing, for me that's Lagrange. If there was a "big-input" button, the type-in panel could get bigger and the insert-line-break key could change from "shift enter" to "enter".
2023-05-25 · 3 weeks ago
@cquenelle One option for that would be to repurpose the Titan upload UI for a "big input" mode. It might motivate me to improve the in-app text editing capabilities. 🙂
@cquenelle @skyjake I really like this idea of having the line break key change from enter to shift+enter when the user switches to big input mode. It would be very convenient.