I have to build a large form for users to fill out in order to apply for graduate study at the college I work for. There will be a large amount of information to collect (multiple addresses, personal information, business information, past school information, experience, etc...) and I want to know the best way to handle all this. I'm going to be using PHP and Javascript.
Are there any helpers or pieces of frameworks that I can use to help with the building/validation of the form, something I can just pop into my existing project?
Also would like any advice as far as keeping track of a large form and the resulting data.
You need to use multiple pages, and you need to include a mechanism whereby users can leave, and come back and fill out the rest of the form later (or if they're accidentally disconnected). Otherwise you're going to have all sorts of user issues, not due to your service, but because they're using computers and internet connections that are flaky, etc.
Survey software is probably a reasonable approximation of what you're doing, and there are survey packages for most PHP CMS's. Are you building this from scratch, or do you have an existing CMS underneath?
-Adam
A few tips, without knowing all the specifics of your form:
Don't show the user everything at once - this can be accomplished by multiple pages, or by selectively showing/hiding elements on the form as the user progresses through it. Provide contextual navigation that says "You're on step 3 of 10" so the user can get a sense of where they are in the form and how much effort is required to finish it.
Providing a mechanism to save and return later is a fantastic idea. If possible, provide a link to an email account of their choosing - you want to make this component as easy to use as possible, and requiring them to fill out an additional username/password to retrieve their data is just another barrier to completion.
Only ask for what you absolutely need. Yes, you're going to have to fight some political battles here - everyone wants as much as they can get. One way to combat this (especially effective when you have pressure from multiple groups) is to build out some prototypes: 1 with EVERYTHING and one with several sections reduced or removed. Have stakeholders from each group fill out both of them and measure their time to completion or roll-throughput yield. When you've got completion data, and they realize how much every other group is asking for (in addition to their group) they are easier to work with. In short, remove as much as possible - let the user go back later to provide more details if they wish.
Write down all your inputs on index cards and see how they logically fit together. More often than not you will find more efficient groupings or orderings. More than likely you will come up with much more usable ideas. This is extremely important when converting paper forms to online forms. Usability.gov has a fantastic case study on this topic.
A List Apart have an article on building sensible forms that is a good read
Why does the form need to be large on the first instance? Can't you trim it down to the bare essentials for the account and provide a way for them to come back later to flesh out the rest of the details?
For form validation, pop a gander on the jQuery validation plugin, Validation
Well I agree with Adam but I have some advise for you.
If I were you, I would create some virtual hidden tabs instaed of multiple forms with a next button.
You can create some which can control by javascript. First show the first one which will collect personal information like Name,Birthday,email, and etc... .
Once user filled them out and clicked on next button,hid this and show the other which will ask for other information like address and so on.
Once the whole dive compeleted, at the last div put a submit button which will submite the whole information to the server at once.
By why do so?
User will not get shocked becuase will not see a long form at each time and will fill out with patient.
You hit server at once;usually universtites and college's servers are too busy, you better design a form which hit the server least. This could count as performance tip.
Since you will submit the whole data at once, you would not worry about the issue that user will continue to fill out the other pages or not,so you will use less session which still will count as a performance tip.
This way makes your form more interesting and you can called you did something like Ajax.
You can add Javascript form validation to make it more user-friendly, but one thing you should never skimp on is the server-side validation... which has historically been awful in PHP.
One thing that'll make your life a million times easier here is the filter library, especially filter_input_array() since you can build the input validation programmatically instead of having to copy and paste a lot of checks. It takes some getting used to, but it's much, much better than the old way of doing things.
Related
I am contemplating building a website for my wedding next year. It would contain information about the event, photos and blogs from my fiancee and I.... you get the picture.
One feature i'd like if possible would be a way of letting my guests RSVP online. I envision that their physical invite has a passcode, which they enter into a text field on the site and tick whether they can or can't attend.
The passcode they entered will be compared against a secure guest-list containing names and passcodes. If it doesn't match, they receive an error message, if there is match however, the information is then relayed to me via email. I will probably build the site using Wordpress, so I would be dealing with PHP.
Can anyone recommend how i might approach this project, as being a front-end dev I have absolutely no idea and my ambition exceeds my limited PHP knowledge.
Would love to hear your ideas or suggestions.
Speaking in generalities, for this sort of thing I find it useful to start by outlining the various components of the system.
While the info pages can be static, you'll need a database to which you can persist your invite data, so I'd start by thinking about the data entities. Devise a list of entities that will exist in the system that might need data tables. E.g. invite, blog post etc.
Then think about the operations that need to be performed on those entities. Are they read-only? Do you need to create new ones, or modify existing ones? You'll need to write code to perform those operations at some point.
Then think about the various ways information from those entities might need to be presented to the user. This gives you an idea of what templates you'll need to build.
If you're thinking of using Wordpress, you can cover off the blog functionality and static page stuff using that application alone. You'd then need to think about how the RSVP functionality might be implemented separately to Wordpress, or within it as a plugin. If you're really lucky, there might be a plugin out there already that will do what you need - or something similar that you can augment yourself.
If you're new to the backend side of things I'd recommend building a blog + static page site using Wordpress, getting it "done" and then looking at the RSVP stuff as a second phase. At least then if it proves unfeasible you still have a useful working site.
Hope that helps!
I'd build this as a simple plugin for WordPress and create an additional DB table that would hold the name against the passcode (this could be auto-generated based on the ID or otherwise).
You could then make a simple admin page when you can add new guests and check the response of guests.
First: congratulations with your marriage. From what I understand you have very little knowledge of PHP so start with reading a few books or articles about basic PHP/MySql. Then, put your ideas in a drawing or flowchart and just go for it. Make lots of mistakes, learn from them, ask for help on SO or a PHP colleague or friend. And above all, have fun doing it.
If I were in your shoes I would install the contact 7 plugin. In the contact form, add passcode as a required text input. Have the results emailed to you and to them. They could make up the passcode which is the downside.
This doesn't have all the options you are wanting but you can either spend several hours writing your own php code and then trouble shoot it, or just install the plugin and be done in 30 minutes.
i have made a simple php contact form following this tutorial:
http://www.catswhocode.com/blog/how-to-create-a-built-in-contact-form-for-your-wordpress-theme
The big problem is that this form processing is not safe, I have heard people can use it to send spam and/or hack my server.
What are the basic steps needed to make this form more secure?
Ps: I don't want to use re-captcha if it can be avoided...
Edit: I need suggestions to what php functions are used to filter and secure that the form is submitted "the right way" and not altered and/or used to hack my site or send email to other people (using the site to send spam to other people). Do i just need to use strip_slashes? or is there a better way?
One way: If you're not a huge site, it's not likely anyone is going to figure this out/take the time to.
You could use some tricky JS to handle tokens on click. So your server issues token-id's to clickable/focus-able elements on the page during the backend render phase. Log these in a database or data file. Then, when users click around and submit, you can compare the id's sent via the onclick() function. You could also apply some heuristics to determine if the history of clicks is reasonably paced. Posts are too fast to be a human or not, that is, even if they scripted the hijacking of the token-ids and auto submitted, you could check that the time between click events appears automated. Signed up for a twitter account lately? They use passive human detection that while not 100% foolproof, it is slower and more difficult to break. Somebody would REALLY want to hack/spam your site.
Important Step 2: strip out/URLEncode strange characters if you think this will break your page. common ones that break things are " and ' and :
Another Way: http://areyouahuman.com/
As long as you are using encrypted methods verifying humanity without crappy CAPTCHA is possible.I mean, don't ignore your headers either. These are complimentary ways.
The key is to have enough complexity to make for an NP-Complete problem. http://en.wikipedia.org/wiki/NP-complete
When the day comes when AI can solve multiple complex Human problems on their own, we will have other things to worry about than request tampering.
http://louisville.academia.edu/RomanYampolskiy/Papers/1467394/AI-Complete_AI-Hard_or_AI-Easy_Classification_of_Problems_in_Artificial
Another company doing interesting research is http://www.vouchsafe.com/play-games they actually use games designed to trick the RTT into training the RTT how to be more solvable by only humans!
Here's a great article on NP-Hard problems. I can see a huge possibility here: http://www.i-programmer.info/news/112-theory/3896-classic-nintendo-games-are-np-hard.html
What is the point in validating your HTML forms using Javascript, if you are always going to need to validate the forms using PHP anyway? I realize that you get a speed boost from this, and its more convenient to the user, but beyond that, is the time spent on it worth it? If anyone has any good evidence on this I would love to hear it.
Thanks for any help!Metropolis
UPDATE
After receiving numerous answers I would like to change the question a little. We all know that javascript is much more convenient for the user and it gives faster feedback. What I am wondering is: Has anyone ever seen any "evidence" that its worth it? Or do we just do it because it makes things a little better and everyone says we should? The speed difference is not that significant, and as the internet gets faster javascript validation will become even more obsolete I would think.
I am starting to wonder if the time spent validating a page using javascript could be better spent.
Ideally, you validate through javascript and (in your case) PHP.
Both validation methods will work in-tandem to ensure you get the most robust and user friendly functionality possible for your end user.
You will use client-side validation to ensure that all fields are filled in, email addresses are valid, etc.. this will provide instant feedback and won't burden your servers or the user's internet connection.
you validate server-side for security. You can control everything on the server and nothing on the client machine. It's here that you ensure that all entered data is non-malicious and correct.
Keep this in mind: if you are only going to go with one type of validation, choose server-side validation because it is more secure. You should never rely on client-side code for any kind of security.
Using both types of validation gives you the best of both worlds (responsiveness and security) while having none of the downsides. Of course, this means you have to write more code, but in my opinion, it's worth it.
EDIT: In response to the comments
Yes, you have to write more code this way... As a rule of thumb, if it's harder for the programmer, it's easier on the user. It might not make sense in some budgets to do both types of validation and that's a call you're going to have to make. Just make sure your server side validation is rock-solid regardless.
Yes, time is money, and time invested in improving the user's experience is time well spent. If you can't afford to do it now (deadlines/schedule/budget) then do it when you can.
It's all about usability. It is much more convenient for the user to read what errors they have made before the page reloads, rather than continuously submit and reload the page. It can also give a nicer look with some AJAX and the likes, rather than a reload of the page and the very ugly looking red error messages, I think. So the advantage? Much more usable than having server side validation alone.
To provide a better user experience.
The feedback on JS validation is faster, and therefore better than server-side validation on form submit.
The main point of JavaScript validation (when available) is that it improves the user experience. A round-trip to the server requires a page load and the associated annoying flicker as it redraws. Validating in JavaScript code allows you to display a message without all that.
That being said, server-side validation is still required since JavaScript isn't always available (NoScript is quite popular) and because a malicious user will bypass the JavaScript.
Particularly for database backed websites, it tends to be that you need to do server side validation anyway. e.g. to make sure you're inputting valid data into a database or other system. Depending on what the website is updating this could be absolutely critical.
However, client side validation can provide a better user experience. It can be used to provide instant feedback. e.g. when you move focus away from a text box a validator can provide instant feedback which is great when you're filling in a long complicated form.
The bottom line is that you will still need to input good data into your database. And the more correct the information stored in there, the less problems with the system you'll have later. You need both.
e.g. What if someone updates the website code in the future and breaks the validation? or someone writes a script to automate inputting data, bypassing your web front end all it's validation?
I'll say it again. You need both.
...i think you're also keeping your karma cleaner, when hundreds or thousands of your users don't wish you burn in hell for making them fill in 5-7 fields (with textarea) to be informed on the next page they mistyped their email so they have to start all over again :D
it doesn't eat up much of my time to incorporate javascript, id say 1-2 minutes maximum for 1 form. and it saves lots of nerve cells of my users. be a humanist! love ur neighbour!))
Client-side validation allows for an increased user experience. The feedback you give to the user leads to less frustration, less errors, more conversion, more money.
You generally have a better response rate with this kind of validation, which is very valuable.
An high quality software needs this. Users feels happy, and they will spread their joy. A user who has a bad experience won't come came and won't tell his friend.
It's not only decoration when you get to business and sales. ;) The return on investment is worth it.
Easy.
Javascript to help the user enter correctly formatted data.
PHP to make sure whatever enters your script gets cleansed before further processing.
Ofcourse you'll have to do both. Users want it, your customers want it and frankly, you think it's fugly getting php errormessages after submit aswell.
I don't think the argument of having to code extra .js which presumably would eat up your time/budget holds any thruth. There's so many libs and scripts outthere, either one will enable you setting up disco validation in no time at all. However, don't get carried away with dealing out eye candy. .js validation is just there to help. Not to impress.
PHP runs serverside, javascript runs clientside. You don't want your server crunching form validation when you can get the clients computer to do so. Plus it saves bandwidth.
i have a large form with a lot of fields. I used fieldset on it. How could I create a better experience to user/accessibility with this large form?
I think about split it. What do you think about it?
Don't re-invent the wheel and confuse the user. Keep it simple. You could break the form down into separate parts, either into separate steps or pages and even with a progress indicator to keep the user informed of where they are.
Form design patterns:
http://patterntap.com/tap/collection/forms
It would be much easier to answer this if I knew a little bit more about the form and what kinds of users you want to be accessible for (ie - you would want to use different techniques if you are trying to be accessible for seniors than you would use if you want to be fully accessible for sight impaired users). Rbaker gave you a tremendous answer and I encourage you to follow his advice/read the link he provided.
However, I would like to add one thing. There is no rule that says that a form has to appear on one page. There is also no rule that says that a 'form' cannot consist of a number of individual questions. Depending on who you want to be able to use your form, a system flow like:
Do you accept our privacy policy? (Click 'yes'/'no)
What is your full name? (Click 'ok')
Would you like to register? (Click 'yes'/no')
You wouldn't have to refresh the page after each question, but if you gave users some idea of how close they are to being finished the form, an individual question approach might be less intimidating and more accessible for your users.
Finally, be proud of yourself for being concerned with accessibility! Best of luck!
i think better if you can post screenshot of that form. from my experience you can tryout some of the steps
1. Keep only fields which you need for uyour system rest take out.
2. Divide into different section
3. if needed can have accordion kind of panels
4. please have proper feedback system, better if you can prompt feedback while filling the form itself instead of waiting for submit or finish button.
5. from the visual, great to have white/gray kind of interface
6. have proper instruction for fields if needed
7. button with affordance
artsrajesh
You need to check out the information on this guys site. Most amazing I have seen anywhere on the net
http://www.lukew.com/presos/
there are many videos, pdf's, power points on form best practices
here is a good start on the site.
http://www.lukew.com/resources/articles/EventApart_WebForms_120809.pdf
and here
http://www.lukew.com/resources/articles/web_forms.html
I am quite new to web development and have a task to develop a web application that will basically show the user 5-15 pull down lists on one page, where each selection will limit the choices in all other lists. The user should be able to start with any one of the lists (so no set selection order) and when the user have selected something in each list or all parameters are otherwise locked by previous choices the user has to press the GO button and some calculations will take place, presenting a database selection. Basically it is a muliple parameter product selector application.
The relations between the lists are not simple, and could need calculated fields etc, and one list could affect the content of several others. The database behind will be MYSQL, probably a single large table, with perhaps 30 fields and 500-5000 rows. I will be using PHP, JavaScript and perhaps AJAX unless you have a strong reason not to.
I have done some research and found three ways to do this:
Send all data to the browser and handle the filtering etc client side with Javascript.
Send parameters back to the server after each selection and reload the whole form after each selection. Probably a littebit Javascript and most code in PHP.
Use AJAX to change all list content dynamically without reloading the whole form.
Since I am so new to this I have a hard time telling which way to go, what pitfalls there are etc...
I have some conserns:
A. Slow initial loading. Worst for #1?
B. Slow dynamic response. Worst for #2?
C. Complicated programming. Worst for #3?
D. Compatibility issues for different browsers and plattforms. Have no idea of which method is most likely to create problems...better if I use some Framework?
E. Could I even try to make something at least part-working for people with javascript turned off? (like selecting each list on a new page and having to press GO button each time)? (I think I can tell my users they must have Javascript on so no big issue....) Perhaps #2 is best here?
F. I think the specification of "free selection order" means I have to download most of the database initially, so perhaps I should try to avoid that option.....if I keep it I might as well use method #1, or???
G. It would be best to do as much as possible of the selction/filtering in SQL to allow future extensions by building custom SQL code, so that gives a big minus to #1...
H. Other pitfalls etc???
I have found tutorials etc for all three methods, but if you can point to good resources like this I would appreciate it, especially so I dont base my code on examples that are not smart/good/compatible....
1:
http://www.bobbyvandersluis.com/articles/unobtrusivedynamicselect.php
http://javascript.about.com/library/bl3drop.htm
http://www.experts-exchange.com/Programming/Languages/Scripting/JavaScript/Q_20523133.html
2:
http://www.plus2net.com/php_tutorial/php_drop_down_list.php
http://www.plus2net.com/php_tutorial/php_drop_down_list3.php
3:
http://techinitiatives.blogspot.com/2007/01/dynamic-dropdown-list-using-ajax_29.html
http://www.webmonkey.com/tutorial/Build_an_Ajax_Dropdown_Menu
http://www.noboxmedia.com/massive-ajax-countryarea-drop-down-list/
http://freeajaxscripts.net/tutorials/Tutorials/ajax/view/Create_AJAX_Dynamic_Drop_Down_List_using_PHP_-_xajax.html
3+jQuery:
http://remysharp.com/2007/01/20/auto-populating-select-boxes-using-jquery-ajax/
Now to the question: Could anyone experienced in all these methods help me out a bit, with the evaluation of methods 1-3 above so I can choose one and get started on the right track? Also, will I be helped by learning/unsing a framework like jQuery+jSON for this?
Rgds
PM
I'd definitely recommend using AJAX with jQuery its tested in all of the major browsers and has simple calls that will make it a lot faster to code and you wouldn't have the browsers compatibility problems of normal JavaScript.
Send all data to the browser and handle the filtering etc client side
with Javascript.
You mentioned that your table has 30 columns and 500-5000 rows potentially? In that case it would not be a good idea to send that much data when the page loads as: 1. It will make the page slower to load and 2. It is likely to make the browser hang (think IE).
Send parameters back to the server after each selection and reload the
whole form after each selection.
Probably a littebit Javascript and
most code in PHP.
I'm not sure how this differs much from the third approach, but probably you mean that you need to reload the page? In that case it isn't likely to be a good user experience if they need wait for the page to refresh every time a drop down selection is changed..
Use AJAX to change all list content
dynamically without reloading the
whole form.
By far the best approach from a user's perspective as it makes filling out the form simple. Perhaps slightly harder to implement from your end, but as you would likely need to perform the same calculations with each of the solutions - might as well move them to a separate page that can be called by AJAX to retrieve your data. As others have mentioned, using jQuery for all your JavaScript/AJAX stuff is going to make things a hell of a lot easier ;)
My personal recommendation is to go with AJAX.
Raw SQL or not is really a question of what backend you are using.
You need to be able to set the relationships between the different selections. The population of the lists must be able to communicate with your backend.
The real issue here is how you implement the relationships between selections. I have no good answer here, it depends heavily on the backend and your administrative needs. It can be hard coded in PHP or configured via XML or via administrative interfaces and persisted to your database solution.
It's no easy task to make it fully customizable.
The reason why i suggest using AJAX is basically because you need to filter upon any change in any selection. That would mean either download a lot of unused information or a lot of page refresh. Going with ajax gives the user a smooth experience all the way.
jquery is a simpple way to use... You can also try a particular class called xajax..! These will make stuff easier.