I'm just trying to find a pattern / best practice to come up with interactive user decisions.
So basically I have a (quite large) form the user has to fill. Once he submits, an AJAX-Post-Request is sent to the server. At first some fault checks are done there but some checks require user interaction e.g. "Is this really correct". As the returned "document" is always XML I thought of returning all questions at once like
bla
bla2
And then iterating through them. Ohh, I'm using JQuery and the Bootstrap' modal therefore. And if all these questions are answered with yes I'll send the form again with a parameter allyes=true or something.
However, I don't feel very happy with that and I'm just wondering if there are some easier ways to code that.
Best regards,
fire
From a users perspective, it's better if the form tells you there is a problem as you go along, rather than having filled it all in. If the checks are field level, I'd be tempted to validate each one as they are filled in.
Related
I am new at the idea of programming algorithms. I can work with simplistic ideas, but my current project requires that I create something a bit more complicated.
I'm trying to create a categorization system based on keywords and subsets of 'general' categories that filter down into more detailed categories that requires as little work as possible from the user.
I.E.
Sports >> Baseball >> Pitching >> Nolan Ryan
So, if a user decides they want to talk about "Baseball" and they filter the search, I would like to also include 'Sports"
User enters: "baseball"
User is then taken to Sports >> Baseball
Now I understand that this would be impossible without a living - breathing dynamic program that connects those two categories in some way. It would also require 'some' user input initially, and many more inputs throughout the lifetime of the software in order to maintain it and keep it up to date.
But Alas, asking for such an algorithm would be frivolous without detailing very concrete specifics about what I'm trying to do. And i'm not trying to ask for a hand out.
Instead, I am curious if people are aware of similar systems that have already been implemented and if there is documentation out there describing how it has been done. Or even some real life examples of your own projects.
In short, I have a 'plan' but it requires more user input than I really want. I feel getting more info on the subject would be the best course of action before jumping head first into developing this program.
Thanks
IMHO It isn't as hard as you think. What you want is called Tagging and you can do it Automatically just by setting the correlation between tags (i.e. a Tag can have its meaningful information plus its reation with other ones. Then, if user select a Tag well, you related that with others via looking your ADT collection (can be as simple as an array).
Tag:
Sport
Related Tags
Football
Soccer
...
I'm hoping this helps!
It sounds like what you want to do is create a tree/menu structure, and then be able to rapidly retrieve the "breadcrumb" for any given key in the tree.
Here's what I would think:
Create the tree with all the branches. It's okay if you want branches to share keys - as long as you can give the user a "choice" of "Multiple found, please choose which one... ?"
For every key in the tree, generate the breadcrumb. This is time-consuming, and if the tree is very large and updating regularly then it may be something better done offline, in the cloud, or via hadoop, etc.
Store the key and the breadcrumb in a key/value store such as redis, or in memory/cached as desired. You'll want every value to have an array if you want to share keys across categories/branches.
When the user selects a key - the key is looked up in the store, and if the resulting value contains only one match, then you simply construct the breadcrumb to take the user where you want them to go. If it has multiple, you give them a choice.
I would even say, if you need something more organic, say a user can create "new topic" dynamically from anywhere else, then you might want to not use a tree at all after the initial import - instead just update your key/value store in real-time.
I'm going to use PHP in my example, but my question applies to any programming language.
Whenever I deal with forms that can be filled out by users who are not logged in (in other words, untrusted users), I do several things to make sure it is safe to store in the database:
Verify that all of the expected fields are present in $_POST (none were removed using a tool such as Firebug)
Verify that there are no unexpected fields in $_POST. This way, a field in the database doesn't accidentally get written over.
Verify that all of the expected fields are of the expected type (almost always "string"). This way, problems don't come up if a malicious user is tinkering with the code and adds "[]" to the end of a field name, thus making PHP consider the field to be an array and then performing checks on it as though it were a string.
Verify that all of the required fields were filled out.
Verify that all of the fields (both required and optional) were filled out correctly (for example, email addresses and phone numbers are in the expected format).
Related to the previous item, but worthy of being its own item: verify that fields that are dropdown menus were submitted with values that are actually in the dropdown menu. Again, a user could tinker with the code and change the dropdown menu to be anything they want.
Sanitize all fields just in case the user intentionally or unintentionally included malicious code.
I don't believe that any of the above things are overkill because, as I mentioned, the user filling out the form is not trusted.
When it comes to admin backends, however, I'm not sure all of those things are necessary. These are the things that I still consider to be necessary:
Verify that all of the required fields were filled out.
Verify that all of the fields (both required and optional) were filled out correctly (for example, email addresses and phone numbers are in the expected format).
Sanitize all fields just in case the user intentionally or unintentionally included malicious code.
I'm considering dropping the remaining items in order to save time and have less code (and, therefore, more readable code). Is that a reasonable thing to do or is it worthwhile to treat all forms equally regardless of whether or not they are being filled out by a trusted user?
These are the only two reasons I can think of for why it might be wise to treat all forms equally:
The trusted user's credentials might be found out by an untrusted user.
The trusted user's machine could be infected with malware that messes with forms. I have never heard of such malware and doubt that this is something to be really be worried about, but it is something to consider anyway.
Thanks!
Without knowing all the details, it's hard to say.
However, in general this feels like a situation where code re-use should be possible. In other words, it feels like this boiler-plate form validation shouldn't need to be re-written for each unique form. Instead, I would aim to create some reusable external class that could be used for any form.
You mentioned PHP and there are already lots of form validation classes available:
http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=form+validation+php+class
Best of luck!
It seems I'm coding contact forms for someone or another every week. I've developed a validate/mail client/mail thankyou/save to DB/thankspage process that's fairly robust but I was wondering what lessons others have for performing this most common of website tasks?
the best hint I would give you is to come up with a good way to prevent spam. We use a honeypot technique which we find very effective and is also very simple to implement. It involves the addition of two extra text fields to each form, hidden by CSS. One of these fields (lets call in input1) will have a set value which you can check for on your processing page, the other field (input2) will have its value left empty. A lot of automated spam will use a bot that will detect the presence of a form and autofill all form fields. With our technique, simply by checking that input1 still has its initial value and that input2 still has a value of "" we can guess the form was not autofilled by a bot or similar. We do have more advanced techniques for checking the content of each field but as a simple trick this one is a real winner and has almost completely eradicated automated contact form spam.
Make sure it works without Javascript (or fails gracefully)
Strip out any nasty characters before sending the email
Use parameterized queries when writing to the database
Be sure the From or Reply-to header is set to the sender's email address
Read this article on form validation.
I'm new with freemarker, I need know about this problem too choose it or not, I will strip XSS by myself but I don't know are other features of freemarker safe when site allow user edit their template?
Oh, goodness no! This is basically equivalent to allowing the user to evaluate arbitrary code. Removing XSS after the fact only removes one potential vulnerability. They'll still be able to do plenty of other things like manipulate POST parameters or perform page redirects.
John is right. And letting the user actually edit freemarker templates themselves seems odd. If you are outputting user input again (like displaying the search term on the results page) I'd suggest using the using the ?html string built-in, it'll save you from the most rudimentary xss attacks (e.g. "you searched for '${term?html}'").
So as others said, it's not safe. However, if those users are employees at your company or something like that (i.e., if they are easily accountable for malevolent actions) then it's not entirely out of question. For more details see: http://freemarker.org/docs/app_faq.html#faq_template_uploading_security
Very simple question: should a dropdown list be used to populate state abbreviations? From my experience, I think most e-commerce sites do this so I would expect that it's acceptable. However, Jakob Nielsen has something to say about this.
I think I disagree; I use the tab key then type the first letter of my state. Heck, even if it wasn't the first entry, I've done this enough times, I would hit the letter repeatedly and get to what I need. I never need the scroll wheel or mouse.
Is there any additional concrete guidance out there on this particular question?
I think this will become less of an issue now that most modern browsers scroll the drop down lists based on each consecutive letter you type, not just reading the first letter as they once did. So, If you type N-Y, the drop down list will scroll directly to NY and you do not have to hit N a bunch of times.
Since a state is a two letter abbreviation, I wouldn't put a drop downlist, I would put a textbox, but I would validate it using AJAX or Javascript to warn the user about an error, right after he entered something wrong.
DropDown / Auto-completion (in my opinion) is useful when the data to enter is longer / more error-prone.
If you insist on using auto-completion or dropdown, you should put long state names, not just the abbrev.
I don't know about concrete guidance, but one alternative I would consider is using an autocomplete text box that forces you to choose from one of the available choices. I agree that a 50-item drop down list is too long and using autocomplete with enforced choice accomplishes the same purpose -- consistent data -- and has the advantage that it is much easier for the user to navigate. If you don't want to limit the choices to just US states you could drop the enforced choice and just let the autocomplete work as a suggestion with the user being able to enter free-form input.
EDIT: As #Martin suggests, I would probably have the autocomplete show the full state name, even if it only entered the abbreviation. This would solve issues of people getting the abbreviation wrong as well, though you could do the same thing in a drop down -- display the name with the abbreviation as the value.
I was going to post NYSystemsAnalyst's answer, but he beat me. I will instead add a caveat... If you use a dropdown list, it must be complete. Do not forget the obvious DC, or the less common but plausible PR or AE/AA/AP, or the rather improbable but still valid AS, FM, MH, MP, PW, and VI.
The official list
I think it depends on if you are asking a user to enter their own address or someone else's address (ship to address). Everyone knows their own state abbreviation, but may know all the state abbreviations.
So for entering your own address a textbox is the quickest and easiest way, but if you are asking the user to potentially enter someone else's address a drop down is probably best.
Of course, if you site has a combination of both types of address, you want your UI to be consistent and use the drop down for both. Also, if you are using a drop down, I would suggest using the state abbreviation and name (AZ - Arizona) when the drop down is expanded (but just show the abbreviation when it is collapsed).
I'm willing to bet that half the users of online e-commerce sites don't know the abbreviations for the states. Think if you're shipping a gift to someone and you can't remember whether its MS, MO or MI. Dropdowns are fine.
I've never had an issue with state drop down boxes (and this is from someone routinely at the bottom in West Virginia). I've gotten into the habit of just tabbing and pressing W and then it will either recognize the "E" and give me the correct state, or it will not recognize the "E" and then I have to hit the down key once or twice (depending on sort order) to get the proper state.
So all in all I am looking at 5 key presses max to get to my state. I don't think it's that bad.
How about a textbox with validation, and a drop-down list if the state abbreviation is invalid?