Home > AI > Backend > SpringBoot >

Form’s design considerations

We have refined our login and registration forms, and below are some considerations we’ve taken into account:

Policy

Every business is required to have three legal documents – Cookie Policy, Privacy Policy, and Terms of Service. The Cookie Policy typically pops up when the page loads, offering users options to customize. Privacy Policy and Terms of Service are usually attached to the form. We avoided hard-coding the links for these legal documents and instead configured them as system settings, allowing for easy adjustments in the dashboard. Similar to WordPress wp_option table, we created a table mn_option with key and value pairs to store system settings. System pre-defined settings are coded as enums and populated whenever the system starts. In MySQL, ‘key’ is a reserved word, so the fields for mn_option are name, value, and description.

Form validation through Google reCAPTCHA v2-invisible

Google offers three options – V3, V2-checkbox, and V2-invisible. V3 uses a score to judge user suspicion based on Google’s algorithm, but we found it less reliable. V2-checkbox forces users to check the box every time, resulting in a less smooth user experience and undesired page look. Hence, we opted for V2-invisible, which prompts users to validate only when the system suspects suspicious actions.

A unified form instead of separate forms

To ensure users validate their email, some businesses divide the registration process into multiple steps. For instance, Form one collects the email address, moves to a validation stage, and then prompts users to provide password to complete the entire flow.

While this approach guarantees 100% email validation, it comes with drawbacks such as a more complicated workflow, higher development costs, longer delivery times, and more complex testing. Alternatively, a single form with straightforward required information appears more convenient, even though it may compromise some aspects of information verification. We decided to keep this way.

Thymeleaf template

Several features span across all Thymeleaf forms, prompting us to group common JavaScript functions, CSS styles, and HTML templates into a template style. This approach brings benefits such as unified management.”

Form field – username

We aimed to concise form fields for a better user experience and increased completion rates. For instance, we tried to remove the username field since email and password might suffice for certain businesses, especially considering that in China, a phone number could be sufficient. However, eliminating the username field would entail a significant code refactoring workload and unnecessary debugging costs. Spring Security offers better support for username field. Upon further observation, we noted that for standalone services like ChatGPT, a username will be necessary. Still, for services with community functions, a username becomes essential to distinguish users. Given our platform’s features such as community, discussions, comments, and more, having a username remains necessary.

Share this post:
Shared platforms
Facebook Twitter LinkedIn Quora Reddit Weibo Zhihu Youtube Medium
Relevant tags:

Leave a Reply