Forms in GroupServer
Summary
- There are 21 posts — by 7 authors — in this topic.
- Latest post made by Michael JasonSmith at 2011 Mar 22 00:09 UTC
At some stage I would like to clean up the forms in GroupServer. For the most part they are good, but there are at least three things that can be improved: better validation, preventing multiple submits, and better password masking. A study performed by Yahoo! found that inline validation allowed people to complete forms faster and with fewer mistakes <http://www.alistapart.com/articles/inline-validation-in-web-forms/>. Some forms on GroupServer currently already perform client-side validation. For example the Set Password page checks that the two passwords match. I would like to add more validation, but I have two concerns. First, marking simple fields as valid (such as a person's name) did cause some confusion in the Yahoo! study, even if performance was higher overall. My second concern is the study did not look at required fields. In many cases the required fields on GroupServer *are* simple fields, so more thought needs to go in here. Less problematically, I think we should re-introduce the behaviour where the Submit button was disabled when the user clicks it. This should prevent errors occuring when a user double-clicks the button. (Users double clicking all user-interface elements is very common, and I place the blame entirely on the shoulders of Steve Jobs.) Finally, I am wondering if GroupServer should display passwords as plain-text — rather than hiding them behind a row of bullets as it currently does. The basic problem is that people easily make mistakes with hidden passwords, and hidden passwords are harder to correct. That is why we have to go through the fuss of making members enter a password twice on the Set Password page, to ensure they do not make a mistake with something they cannot see. A storm in a teacup broke out in July when usability guru Jakob Nielsen proposed that sites should stop password masking <http://www.useit.com/alertbox/passwords.html> and security guru Bruce Schnier agreed with him <http://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html>. (For me, Schnier's blog post comes across as more considered than Nielsen's Alertbox article.) I am tempted by the compromise solution of providing a checkbox to hide a password. * On the Set Password page the checkbox would be off, so the member sees what he or she types by default. If the member can turn on masking if he or she is in a high-risk environment. * On the Login page the checkbox would be on, so the member sees the password masked by bullets. However, the member can turn off masking if he or she is having difficulty logging in. Those are my thoughts on the forms in GroupServer. As ever, I would love to hear yours.
On Wed, 2009-09-02 at 13:27 +1200, <email obscured> wrote: > I am tempted by the compromise solution of providing a checkbox to hide a password. > * On the Set Password page the checkbox would be off, > so the member sees what he or she types by default. > If the member can turn on masking if he or she is in > a high-risk environment. > * On the Login page the checkbox would be on, so the > member sees the password masked by bullets. However, > the member can turn off masking if he or she is > having difficulty logging in. It would be a horrid interface though. The current users already ignore the option to stay logged in, generally. Not hiding the password would just lead to complaints. People *believe* that *s make them more secure. Most probably even believe that it has something to do with their password being 'encrypted'. How about a 3rd compromise, that I've never seen suggested: if they get the password wrong *then* we offer them a way to show what they're typing. I'm not convinced that the number of password failures due to simply mistyping the password is all that high anyway. More likely they just totally forget the password. I do that frequently :)
--Richard
An appropriate cartoon with respect to the 'security' side of things: http://imgs.xkcd.com/comics/security.png
--Richard
Thanks for your suggestion, Richard. I like your idea of providing a show-password option only after the member has failed to log in. It would reduce clutter in the interface, allows us to better emphasise the option, and make it look like GroupServer is trying to help the member log in (rather than just being obstructive). I take it you have no objections to showing the password on the Set Password page? That is the one that really bugs me at the moment, as people struggle with that page for many reasons.
On Wed, 2009-09-02 at 11:52 +1000, Michael JasonSmith wrote: > I take it you have no objections to showing the password on the Set > Password page? That is the one that really bugs me at the moment, as > people struggle with that page for many reasons. I still worry it will freak people out, and we'll get complaints about how 'insecure' we are. Is there a way to prevent the browser from caching what was typed into a non-password type field?
--Richard
I agree that not showing the previous entry on the Set Password page
would help a lot with the security theatre. There is a way of preventing
form fields from being cached, but I cannot recall what it is.
The complaints about showing the password on the Set Password page will
come from a tiny part of our user-base, and I am willing to sacrifice
them for the greater good. I suspect that those that complain would be
lulled by implementing HTTPS on the site in question. In addition, I am
proposing that we always provide the password-obfuscation to those that
want it, but they would have to use a check box.
Below is a visualisation of my proposal, using my impressive Unicode-art
skills.
The Default (password shown)
╔════════════════════════════════════════╗
║ Set Password ║
║ ║
║ Password ║
║ ┌────────────────────────────────┐ ║
║ │ farmbake │ ║
║ └────────────────────────────────┘ ║
║ ☑ Show password ║
║ ║
║ ┌─────┐ ║
║ │ Set ┃ ║
║ └━━━━━┛ ║
╚════════════════════════════════════════╝
The Option (password obfuscated)
╔════════════════════════════════════════╗
║ Set Password ║
║ ║
║ Password ║
║ ┌────────────────────────────────┐ ║
║ │ •••••••• │ ║
║ └────────────────────────────────┘ ║
║ ☐ Show password ║
║ ║
║ ┌─────┐ ║
║ │ Set ┃ ║
║ └━━━━━┛ ║
╚════════════════════════════════════════╝
I like Richard's proposal to only give the Show Password option on the login page if the user has already gotten it wrong. I agree that Show Password should be an option on the Set Password page, but I think that the default should be to mask it. Ubuntu's Network Configuration interface does it that way, and I really like it. Lastly, very impressed by the Unicode art :)
Thanks, Alice ☺ I am happy with the modified proposal for the login page that Richard gave, and you agree with. Someone should think of modifying the login page some time… Next time I touch the Set Password page I will remove the confirmation entry and add a "Show password" checkbox that defaults to *off* (obfuscate the password). I suspect I may touch it as part of some other work, but not in the immediate future, sadly. Good to have a plan, however.
My thought on the forms in GroupServer is that the 'submit' button is unavailable when I want to submit a post, or email address that I have pasted, rather than keyed in. I know how to get around this, but suspect that most users who is know enough to use copy and paste may still be baffled by this.
I am in a catch-22 with required fields. * I do not want to allow the user to make a mistake and submit a form that does not have all the required information. That is why there is an interlock on the Submit button, which makes it available once all the required fields are filled out. * My code does not know that a required field has been filled out in the rare case of someone pasting, because there is *no* JavaScript event for "paste". Hitting a key will always get around the problem, because there is a JavaScript event for Key-press. Indeed, if you paste by Ctrl-V then the interlock works fine: it is Edit→Paste and the Context-menu→Paste that have the problem. The only solution is to take off the interlocks on the Login and Post forms, and hit the users with big red error messages ☹ Thankfully the interlocks seem to work fine on most other pages.
Hi Michael, You may have already seen this before, but it also happens on the login page under FF when your browser remembers a username and password combination, completes the relevant form fields, but no javascript event is triggered (which is a bit naughty of FF, really). A. On Mon, 2009-09-07 at 12:39 +1200, <email obscured> wrote: > I am in a catch-22 with required fields. > * I do not want to allow the user to make a mistake and > submit a form that does not have all the required > information. That is why there is an interlock on the > Submit button, which makes it available once all the > required fields are filled out. > * My code does not know that a required field has been > filled out in the rare case of someone pasting, > because there is *no* JavaScript event for "paste". > > Hitting a key will always get around the problem, because there is a JavaScript event for Key-press. Indeed, if you paste by Ctrl-V then the interlock works fine: it is Edit→Paste and the Context-menu→Paste that have the problem. > > The only solution is to take off the interlocks on the Login and Post forms, and hit the users with big red error messages ☹ Thankfully the interlocks seem to work fine on most other pages.
I have coded the change to the Add to Topic and Login forms, so the required-fields are not checked. The change should be deployed in the next day or so.
On Mon, Sep 7, 2009 at 12:39 PM, <email obscured>> wrote: > * My code does not know that a required field has been > filled out in the rare case of someone pasting, > because there is *no* JavaScript event for "paste". The Twitter Direct Message form seems to detect pasting ... e.g. Go to http://twitter.com/direct_messages/create/yjmbo ; the 'send' button is grey. Paste some text in .. it lights up. So somewhere in their JS there's a solution to your question :-)
-jim
On Thu, 2009-09-10 at 12:03 +1200, Jim Cheetham wrote: > On Mon, Sep 7, 2009 at 12:39 PM, <email obscured>> wrote: > > * My code does not know that a required field has been > > filled out in the rare case of someone pasting, > > because there is *no* JavaScript event for "paste". > > The Twitter Direct Message form seems to detect pasting ... > > e.g. Go to http://twitter.com/direct_messages/create/yjmbo ; the > 'send' button is grey. Paste some text in .. it lights up. > > So somewhere in their JS there's a solution to your question :-) I thought pasting just triggered the regular keypress events?
--Richard
I have changed GroupServer so it provides feedback when a user submits a form. Now, when user clicks the submit button, the button will become disabled (greyed out) and its text is changed to “Processing…”. Besides providing feedback to the user, disabling the submission button should prevent problems caused by the user double-clicking on the button, which can submit the form twice. (A problem I entirely blame on Steve Jobs, but that is a rant for another day and another medium.) The process of the disabling the button is a little more complex than I wanted. We use the zope.formlib library for creating and processing forms. It relies on the identifier of the button being sent from the browser as part of the form information. However, disabling the button means that its identifier is omitted from the for data. To get around this I hide the button and put a new (disabled) button in its place. Browsers happily send the ID of a hidden button to Zope, so everything works fine. Thanks to Richard who helped me solve this nasty little problem. Dan, One day I will fix the paste-issue with required widgets in GroupServer forms.
I love it when small changes make things easier for people. Steven Clift - http://stevenclift.com Executive Director - http://E-Democracy.Org Follow me - http://twitter.com/democracy On Mon, Nov 23, 2009 at 9:12 PM, <email obscured>> wrote: > I have changed GroupServer so it provides feedback when a user submits a form. Now, when user clicks the submit button, the button will become disabled (greyed out) and its text is changed to “Processing…”. > > Besides providing feedback to the user, disabling the submission button should prevent problems caused by the user double-clicking on the button, which can submit the form twice. (A problem I entirely blame on Steve Jobs, but that is a rant for another day and another medium.) > > The process of the disabling the button is a little more complex than I wanted. We use the zope.formlib library for creating and processing forms. It relies on the identifier of the button being sent from the browser as part of the form information. However, disabling the button means that its identifier is omitted from the for data. To get around this I hide the button and put a new (disabled) button in its place. Browsers happily send the ID of a hidden button to Zope, so everything works fine. > > Thanks to Richard who helped me solve this nasty little problem. > > Dan, One day I will fix the paste-issue with required widgets in GroupServer forms.
> > ----------------------------------------- > Full text of this topic in GroupServer Development: > http://groupserver.org/r/topic/1LvqdTaUgnscURGReK0qNM > > To leave GroupServer Development, email > <email obscured>?Subject=unsubscribe > > Start your own free groups and site with > OnlineGroups.Net http://onlinegroups.net > > Host your own online groups site with > GroupServer http://groupserver.org >
I finally discovered how Twitter makes the submit button active when someone pastes: it hooks into the non-standard "onpaste" event. I have created a ticket¹ to remind us to look at the paste-problem one day. *Footnotes* 1. Pasting Into a Field does not make the Submit Button Active <https://projects.iopen.net/groupserver/ticket/518>
Question: Should buttons be placed at the bottom left or bottom right of forms? I am thinking that the bottom right is the better place, so the forms have better consistency with dialog boxes.¹ To help you visualise, contrast and compare * <http://groupserver.org/r/img/1844-2011-03-18T035617Z> * <http://groupserver.org/r/img/1715-2011-03-11T051634Z> *Footnotes* 1. There will always be exceptions. For example, The Search button appears in line with the Search entry to save space.
> Question: Should buttons be placed at the bottom left or bottom right > of forms? I am thinking that the bottom right is the better place, so > the forms have better consistency with dialog boxes.¹ To help you > visualise, contrast and compare Consistency is good. If we do not have a guideline to follow for forms, we could use the one for dialogs. As I look around GroupServer, however, most forms seem to have the button on the left. Leaving it there would also be consistent, and would be less work.
I am not too worried about the work. Almost all forms generate the button the same way, so the HTML is all the same. With the same HTML the same CSS can be used to get the buttons in the right place ☺ It is basically a task for doing when I next overhaul the global CSS.
Loading…
Privacy | Acceptable Use | Terms of Service | About OnlineGroups.Net | Contact OnlineGroups.Net
Start an OnlineGroups.Net site for easier email collaboration in your organization.
Powered by GroupServer, the open source web-based mailing list manager.