conversational-form
conversational-form copied to clipboard
space10-community
[question] prevent every answer keyboard open/close on mobile
Hi, thank you for your library, it's a great idea!
I've tried your sample on mobile (https://codepen.io/jenssog/pen/mqXMQW), it's possible prevent keyboard open/close for every answer? If we want emulate chat, the keyboard remain open for the entire conversation.
Here's a sample:
Hi @menteora. I see your point, but sometimes the keyboard might take up too much space?
Sorry for my english @jenssogaard, I mean that once the conversation has started it's a bit annoying to see the keyboard going up and down every time the field change. It could be better to leave the keypad always open until the form ends.
@menteora I totally understand what you mean. And it might be something that I can look into.
A persistent textarea if option is set perhaps?
options:{ forceKeyboardAlwaysOn: true }
Could then render another textarea over the top of everything else which captures input and feeds it back? I can see why this would be annoying on mobile.
@menteora @MadhuNandi I like the idea of utilizing a persistent input area enabled through an option like forceKeyboardAlwaysOn or persistentInputArea. My greatest concern is the amount of space it takes up and how this pattern is very different from the standard messaging pattern where keyboard show/hides all the time.
Hi @jenssogaard, thank you evaluating this enhancement.
WhatsApp, for example, has fixed input and keyboard always open (after first tap on input field). To explain better, this is a gif I found around the web.
and yes... the space could be a problem, require a bit css optimization (in particular, reduce margins, I think)
If you think about the context here though: like whatsapp designers have, they've realised their app has only one purpose and that's to collect input from the user and send it to other parties. The previous responses or new responses from a friend or contact can appear even on a small device like an iPhone 4: but in reality when you're writing multiple responses the only task being carried out is multiresponse, not usually two way chat or in the case of this project I guess you're not really reviewing multiple answers at a time you're actually going to provide a few answers then review at the end. So Whatsapp have it absolutely right here
Actually It makes more sense to track the next question - if the next question has persistKeybord as well as the current then create a virtual textarea focus it and capture When the next question no longer has persistKeyboard or the end of questions remove textarea and focus the page; that should result in a smooth transition between input types - keyboard is only open when it needs to be- for a multiple choice input it closes and the same for radio buttons..?
@menteora @TakesTheBiscuit thanks guys. Very good input and observations. Does any of you want to contribute with a PR?
Hello everybody, so I found this thread just now and was wondering what the current status is on such an option? I believe from an experience point-of-view it seems clunky that the keyboard disappears and appears again within one second.
Hi, I think version 1.0 solve this issue, see demo on home page of project.
it would be so nice to get this functionality, I'm down to work on it with someone
@jonrrivera I agree, but I wouldn't say my skills are to that level yet...
I'd love to chat with anyone who wants to work on a solution for this with me. It is really impeding this otherwise excellent library.
temp fix for anyone who stills needs it: inside the option flowStepCallback get the input with query selector ".inputWrapper > input" and input.focus() also inside flowStepCallback.
