NSWI142: Web Applications
HTML Form
Preliminaries
Please read this section at least one day prior to the seminar. This section outlines what you are expected to know, be able to do, or prepare in advance. Following these instructions will help you get the most out of the seminar and ensure smooth participation.
Preliminaries 1 / 1
Before the start of the practical, you should be able to:
- Explain a difference between HTTP GET and HTTP POST.
- Create a static website.
- Set font using CSS.
- Create a simple HTML form with a text input and a submit button.
- Explain and use CSS pseudo-class selectors.
Agenda
- Exercise: HTML Form
- Demonstration: Event registration form
- Exercise: First iteration
- Demonstration: Towards a better form
- Demonstration: Testing and evaluation
Exercise: HTML Form
Create a simple HTML form.
Simple HTML form
Create a simple HTML form to create a reservation for today's practical. The form must contain input fields for:
- first name
- second name
- number of reservations
Submit the form to this URL.
You can also utilize services such as echo.free.beeceptor.com to see the payload.
Continue to the next slide once you are done.
Task Complete
Congratulations, if you have followed the instructions, you have just reached the end of this exercise.
Debriefing
- Any issues?
- Why do we need a form?
- Have you validated the website?
- What is the difference between GET and POST?
- What was missing?
Demonstration: Event registration form
There is more then meets the eye when it comes to properly designing a from. In this part we try to take a look at some of the steps and issues along the way.
Design phase
I plan to have a practical about LLM, AI agents, and application development. I need a website with a registration form. Can you help me?
Exercise: First iteration
Using iteration is a development approach where software is built and refined in small, manageable increments. This method allows developers to prototype quickly, gather user feedback, and make improvements in subsequent iterations. It aligns well with agile methodologies, emphasizing adaptability, collaboration, and delivering value to users early and often.
By GTP-4o, 2025.
Implementation
Implement the form based on the design from the last demonstration.
Continue to the next slide once you are done.
Task Complete
Congratulations, if you have followed the instructions, you have just reached the end of this exercise.
Debriefing
- Any issues?
Demonstration: Towards a better form
The "bad" ...
Improving: Basics controls
List of basic controls you should know:
- Password input
- File input
- Checkbox
- Radio
- Select
- Datetime
- Color
- Textarea
- ...
Improving: File upload
Improving: Accessibility (a11y) and semantic
Basic:
- <label> - It represents a caption in a user interface.
- <fieldset>, <legend>, - Grouped set of controls, or other content.
- Ensure proper tab order and keyboard navigation (tabindex)
- Use appropriate types for <input>.
- Provide clear instructions.
- Use aria-label and aria-describedby when there is not readable label on screen. Techniques and Failures for Web Content Accessibility Guidelines
Improving: Validation
Basic:
- required - Field must be non-empty, whitespaces are fine.
- max and min - Set allowed range of values for the element. Can be used with number, range, time, ...
- pattern - Field must match the given regular expression. Use with caution!
When life gives you lemons, write better error messages, Wix UX, Jenni Nadler, Medium
Improving: Wizard / Multi-step forms
Improving: ...
- (Requires JS) Disable submit button until validation is passed.
Demonstration: Towards a better visual
Improving: Basics
- Harmonize a font used by the browser. Not all inputs may use the same font by default.
- Font size at least 16px or higher.
- Try to match field length and structure to the intended input size.
- Prefer one column forums, with labels above the inputs.
Improving: Responsive design
Improving: Valid, invalid, focus, ...
We can style the form using CSS to enhance the notion of valid and invalid state.
You can use :valid, :invalid, :focus, :autofill
:user-valid, :user-invalid pseudo-classes.
There are also other more specific one.
We need JavaScript for more advanced functionality.
Demonstration: Testing and evaluation
Have we created a functional form?
Have we created a good form?
Have we created a ....
Measuring the "goodness"
In oder to measure we need a metric.
- Usability: Is the form easy to understand and fill out? Are the labels clear and inputs intuitive?
- Accessibility: Can users with disabilities interact with the form? Does it support screen readers and keyboard navigation?
- Validation: Are there proper validations in place to prevent incorrect or incomplete submissions?
- Feedback: Does the form provide clear feedback for errors or successful submissions?
- Performance: Does the form load quickly and work seamlessly across different devices and browsers?
- Security: Are user inputs sanitized and protected against common vulnerabilities like XSS or SQL injection?
- ...
Evaluation
Full and proper evaluation is out of scope of this practical and even subject. Plese consider this slide to be a very brief introduction.
The System Usability Scale (SUS) is often used to evaluate after the implementation phase. The method is based on a simple questionnaire and provide a number representing usability. You can find a lot of resources on the internet about SUS. E.g. SUS by uxtweak.
Yet, evaluating after implementation may be too late! In fact, we would like to test at every phase, not only after the implementation. Baseline phases are analysis, design, and implementation. In the analytical phase we can use story boards. In the design phase we can use paper mockups or low fidelity prototypes
We can also use A/B testing to compare alternatives.
There is much more when it comes to user interface design and evaluation. If you find this topic interesting you can check out User Interface Design and Evaluation (Interactive Technologies) book.