Currently the MUC Configuration form has a field/title
"Complete this form and submit this form to configure the room"
Yes we use a dataform, and yes the client needs to submit it, but thats protocol details.
The user will not submit anything, and this form will be displayed in most clients as a settings dialog.
I would expect it to say something like "Group Chat Configuration" or something in that line. It should not have some call to action. The Client will display this form in a appropriate context so the user knows what to do.
MattJ
on
I 100% agreed with your comment, and I went to fix it, but it looks correct already:
https://hg.prosody.im/0.12/file/tip/plugins/muc/muc.lib.lua#l927
The title should be "Configuration for <MUC JID>".
What you describe as the title ("Complete and submit this form...") is set as the "instructions", which I would expect to be rendered above the form fields, but not as a title.
Can you verify if it's a client/library issue that these fields are being confused, or that you're actually receiving the incorrect title from Prosody?
Thanks!
lovetox
on
Hi, sorry i formulated that imprecise, its indeed the instruction i mean
This is maybe a nitpick, im ware that the protocol is a DataForm, and yes the client fills it out and sends it. But this is just the protocol on the wire.
It feels weird to tell the user to fill out a form in the context of MUC settings
A DataForm was chosen as on the wire format, but a GUI Client will show a normal settings dialog, the user will see no difference to any other settings dialog in the application.
Imagine you open your Browser Settings page, and the first line reads "Fill out this form and submit it", would be weird don’t you think?
My proposal here would be to get rid of the instruction. Especially because this is not something the user requests on his own, its avery specific form defined in a XEP for a very specific purpose, and the client queries it and he does not need any help from the server to make the purpose clear to the user.
Instructions for me, should be used for things the client cannot convey on its own to its user.
Currently the MUC Configuration form has a field/title "Complete this form and submit this form to configure the room" Yes we use a dataform, and yes the client needs to submit it, but thats protocol details. The user will not submit anything, and this form will be displayed in most clients as a settings dialog. I would expect it to say something like "Group Chat Configuration" or something in that line. It should not have some call to action. The Client will display this form in a appropriate context so the user knows what to do.
I 100% agreed with your comment, and I went to fix it, but it looks correct already: https://hg.prosody.im/0.12/file/tip/plugins/muc/muc.lib.lua#l927 The title should be "Configuration for <MUC JID>". What you describe as the title ("Complete and submit this form...") is set as the "instructions", which I would expect to be rendered above the form fields, but not as a title. Can you verify if it's a client/library issue that these fields are being confused, or that you're actually receiving the incorrect title from Prosody? Thanks!
Hi, sorry i formulated that imprecise, its indeed the instruction i mean This is maybe a nitpick, im ware that the protocol is a DataForm, and yes the client fills it out and sends it. But this is just the protocol on the wire. It feels weird to tell the user to fill out a form in the context of MUC settings A DataForm was chosen as on the wire format, but a GUI Client will show a normal settings dialog, the user will see no difference to any other settings dialog in the application. Imagine you open your Browser Settings page, and the first line reads "Fill out this form and submit it", would be weird don’t you think? My proposal here would be to get rid of the instruction. Especially because this is not something the user requests on his own, its avery specific form defined in a XEP for a very specific purpose, and the client queries it and he does not need any help from the server to make the purpose clear to the user. Instructions for me, should be used for things the client cannot convey on its own to its user.