Institutional Web Management Workshop 2008: The Great Debate

1. Institutional Web Management Workshop 2008: The Great Debate Coping with Forms: Implementing a Web Form Management Application Dan Jackson, City University

2. “FORMS SUCK. WE SHOULD ACT ACCORDINGLY.” ‘Web Form Design: Filling in the Blanks’, Luke Wroblewski, Rosenfeld Media, 2008

3. ...can’t we do better?

4. What about forms?

5. Improving your forms CAN make a difference. Jared Spool. One form. - Increased the number of customers making purchases by 45%. - Boosted revenue by $300m over the first year.

6. Forms can have a BIG impact, both positive & negative. We need to pay more attention to how we develop and manage our forms.

7. Problems: There are lots of forms. Form development is time-consuming. Form development is difficult. Sometimes our clients aren’t sure what they want! http://www.flickr.com/photos/b-tal/163450213/

8. Let’s think about.... • Security • What measures do you employ to secure your forms? Are you aware of any • vulnerable forms on your website? • SPAM • What, if any, measures do you take to prevent spam? • What problems with CAPTCHA are you aware of? • Accessibility, Usability, Design • What annoys you most about bad forms? What makes a form easy to use? • Legal • What are the legal issues we need to be aware of when developing forms? • ‘The Process’ • What political / institutional issues prevent a smooth development process? • What, if any, workflows do you have in place to manage form development?

9. Security problems It’s EASY to make an insecure form, & there are LOTS of vulnerabilities out there. Reproduced with permission of WASC, http://www.webappsec.org/projects/statistics/

10. Security strategies Don’t assume that… …you can trust your users. …client-side (JavaScript) validation is enough. …hackers will test for vulnerabilities using a browser. Validate data. Both on the client-side AND server-side. Use a white-list approach to data filtering. Assume that all received data is invalid until it can be proven valid. Educate yourselves about vulnerabilities.

11. Security strategies Scan your existing forms. Test forms for vulnerabilities while in development. Employ a reusable library or framework of server-side code. Build security into your development lifecycle.

12. Spam: the CAPTCHA conundrum Most people use CAPTCHA to prevent spam. BUT... CAPTCHA is notoriously inaccessible. CAPTCHA can be circumvented. CAPTCHA has been discredited. “Just like DRM, CAPTCHA systems ultimately fail to protect against the original threat, while simultaneously inconveniencing ordinary users.” ‘Beyond CAPTCHA: No Bots Allowed!’, http://www.sitepoint.com/article/captcha-problems-alternatives, viewed 04/07/08)

13. Spam strategies 1. Authentication. 2. Centralised sign-on. 3. Sessions. 4. Spam filtering & heuristic testing.

14. Accessibility, Usability, Design problems Forms are often long, confusing, badly designed AND painful to complete. There are LOTS of design questions to tackle. How should I chunk up my form? What are the right field types to use? Where do I place my input field labels? Should I provide field hints? Where do I place primary & secondary actions? Where do I place error messages?

15. Accessibility, Usability, Design strategies You Must Buy This Book. Web Form Design: Filling in the Blanks Luke Wroblewski; Rosenfeld Media, 2008.

16. Accessibility, Usability, Design strategies Forms should be: Clear Is the purpose of the form obvious? Are the labels helpful? Are error messages clear? Is the layout good? etc. Concise ‘Do we really need to ask this question?’ Clever Help direct users around the form; skip irrelevant questions. Contextual Tell users why certain questions are asked, especially when you’re asking for personal data. http://formulate.com.au/articles/what-makes-a-good-form/, visited 15/07/08

17. Accessibility, Usability, Design strategies Be nice! Use natural language. Try to organise your form as a conversation rather than an interrogation. Design from the ‘outside in’, not ‘inside out’. Forms shouldn’t be a simple mirror of the fields in our database records; we need to look at our forms from the perspective of our users. Don’t construct unnecessary barriers. If a student wants a prospectus, why make her register? http://www.flickr.com/photos/martigras/2383422487/

18. Accessibility, Usability, Design strategies Visual Clarity Visual path to completion. Make your forms easily scannable. Fieldsets are your friend. Organising your forms into logical groups aids scanning & completion. Communicate error & success messages clearly. Hide irrelevant form controls. Figure 3.4 from Web Form Design: Filling in the Blanks by Luke Wroblewski; Rosenfeld Media, 2008. http://www.rosenfeldmedia.com/books/webforms/

19. Accessibility, Usability, Design strategies Coding Careful with that JavaScript. DO use for data validation, enhancing the user experience, providing users with information. DON’T make the completion or submission of a form dependent on JavaScript. Test your forms as you would a site redesign. Think about bug fixing, site analytics, usability testing. Centralise your code. Maintain a central repository of reusable form components. Accessible XHTML templates/snippets, CSS, JavaScript, server-side functions.

20. Legal problems • Data Protection. • Data Protection Act 1998 governs the protection of personal data. • PECR. • Privacy and Electronic Communications Regulations. • Unsolicited marketing material by electronic mail (includes email, text and messaging) • should only be sent if the individual has consented to receive them.

21. Legal strategies Transparency is key. Tell your users what your policies are & what you plan to do with their data. Provide them with the chance to opt-in/out of mailings where relevant. Control. Control how your form data is stored, accessed and used. Don’t store data for longer than required. Draw up standard notices “Personal data in this form may be used only in accordance with City University’s notification under the Data Protection Act 1998 and in compliance with the Freedom of Information Act 2000. Further details in relation to the use of personal data can be found on the University’s web site www.city.ac.uk/dataprotection. Any queries concerning Data Protection and Freedom of Information should be addressed to the Head of Information Compliance and Policy.” Get advice.

22. http://www.flickr.com/photos/colbycosh/2266583598 The Process: problems Agreeing on the contents of a form can be difficult. Everyone wants a say (marketing, technical, legal, departmental, etc). “What’s this form for?” It can be hard to establish what the organisational goals of the form are. Why is this form needed? What information do we need?

23. The Process: strategies • 1. What’s the competition up to? • For important forms, a web convention survey can help kick-start the scoping process. • 2. Document the information needs, & get sign-off. • - Who needs what, and how? • - Ensure that the form fits its purpose. Figure 2.1 from Web Form Design: Filling in the Blanks by Luke Wroblewski; Rosenfeld Media, 2008. http://www.rosenfeldmedia.com/books/webforms/)

24. The Process: strategies cont. 3. Design / development. 4. Testing checkpoint. Security, usability, accessibility. 5. Information Compliance. 6. Manage data.

25. Q&A

26. Useful links http://phpsecurity.org/ch02.pdf - Essential PHP Security Chapter 2 – Forms and URLs http://formulate.com.au/ - Formulate Information Design. Useful articles about form design. http://www.sitepoint.com/article/captcha-problems-alternatives - Excellent summary of CAPCTHA debate. http://www.lukew.com/ff/index.asp - Luke Wroblewski’s form & general usability site.