A web form acts as a communication bridge that allows a user to communicate with the organisation and vice versa. In the Open Event project, we need forms so users can contact the organisation, to register themselves, to log into the website, to order a ticket or to query for some information. Here are a few things which were kept in mind before we designed forms in the Open Event Frontend Project:
- The forms were designed on the principle of keeping it simple which means that it should ask only for the relevant information which is required in actual.
- They contained the relevant fields ordered in a logical way according to their importance.
- They offered clear error messages instantly to give direct feedback and allow users to make instant corrections.
- The clear examples were shown in the front of the field.
- Proper spacing among the fields was maintained to display proper error messages to the respective form fields.
- The mandatory fields are highlighted using ‘*’ to avoid confusion.
- Proper colour combinations have been used to inform the user about the progress while filling the form. For eg. red for any ‘error or incomplete’ information while green signifies ‘correct’.
- Saving the current data in case the user has to go back to make any corrections later.
- Allowing to toggle through the form using the keyboard.
The above designing principles helped in avoiding the negative user experience while using the forms.
Creating a form
Let’s start by writing some HTML for the form:
The complete code for the form can be seen here.
The form is created using the Semantic markup. Along with semantic UI collection “form”, the segment element has been used to create the grouping of similar content like we have a timer and its related description that after 10 minutes the reservation will no longer be held are put together in a segment where they are arranged using semantic UI view “statistic”. Due to the vastness of semantic UI, all the styling has been done using it like fields inlining, button styling, segment background coloring etc.
The form is created using the Semantic markup. Along with semantic UI collection “form”, the segment element has been used to create the grouping of similar content like we have a timer and its related description that after 10 minutes the reservation will no longer be held are put together in a segment where they are arranged using semantic UI view “statistic”. Semantic UI elements like button, input, label, icon, header and modules like dropdown, checkbox have been used. Due to the vastness of semantic UI, all the styling has been done using it like fields inlining, button styling, segment background colouring etc.
The page for the above HTML code looks like this:
Fig. 1: Order Form to purchase a ticket
The complete form can be seen on this link.
Adding form validations
Let’s break this up, first, we have an array of validation rules.
The first part zipcode is the identifier in Semantic.
The next bit of the identifier, this can match against either id, name or data-validate attributes on the element. We have here picked up the name which we’re using on our labels.
Next bit of the rules, which is an array of objects defining the type of validation, and the message to prompt the user with.
The second part is the settings:
This part says we want validation to occur on blur, delayed and to be inline. This gives us the following effect:
Fig. 2: Order Form after validation
To summarise the post, one can say we have seen here how the form to purchase the event ticket has been designed, coded and styled. The complete form can be seen on this link and the complete code can be seen here. The entire form has been designed in such a way to keep it simple, clear and trustworthy without losing the user interaction.