With Open Source projects like Android, Apache and Linux enjoying high profiles and large user bases, companies and organisations are increasingly benefiting from Open Source software and ustwo™ is no exception.
We use Open Source software everyday and knowing it plays an important part in our industry, we promote and participate in Open Source projects whenever we can—by reporting bugs and contributing code and also by publishing and maintaining our own Open Source projects.
That’s why we’ve released the US2FormValidator!
What is US2FormValidator?
Since more apps are using forms to receive data from users we thought it worthwhile to create a framework for this to save time on future projects.
However, any framework to gather this information shouldn’t only save time on the developer’s side. First and foremost it has to save the user’s time, for better user experiences reflect better on the app and thus the brand (and client) providing it.
As just about every app these days is social, we need to gather information so we can connect the user to their friends. So one important use case for this framework is the registration form and as we all know filling out forms on a mobile can be a UX disaster.
Submitting a form can bring back errors like “Please review your entered data” and you do not know what you did wrong. Here is the point where the form validation framework should help by giving concrete messages, visual highlights on the right place and at the right time.
But how do we know when it is the right time to show these messages? To know this we need to take a look into the psychology of a human being in the second millennium.
Understand the Psychology
From a UX perspective it is important to guide the user through such a time intensive process. To save time and thus effort on the user’s side, it’s advisable to forgo server side validation where possible. Of course it is not possible to verify whether a user name is already taken but here we should go for validation after a time interval or when the user leaves the user name text field. It has to be clear to the user that the app is asking a service for validating this text field by showing a loader animation or similar. When working with validation there are three states.
- Initial status
- Valid status
- Invalid status
The user needs to know the status of the current entry. As humans are conditioned to connect red colours with bad and green with good things so it’s obvious to use those colours associated to the text field by framing it or showing status icons next to it. The initial status is the status when the user did not do anything wrong but neither anything correct, so the user did not focus the text field once. The colour used in this case has to be a neutral one.
After reading convincing articles on web form validation it was time to create a prototype to give it some serious user testing. We came up with the following final result.
After testing we came up with some conclusions. Some text fields need to be validated immediately and others should be validated after they are completely filled out.
For example the telephone number must not accept any letters so it is necessary to tell this to the user as early as possible. In comparison the email text field is incorrect from start until you enter the domain ending.
To avoid irritating the user the text field should not flag an error while entering the email address. In this case, leaving the email address text field is the right time to validate it.
Helping non-advanced users can be achieved by giving additional contextual information like a permanent tooltip next to the input area. Alerts would interrupt the process too much and the user has to remember what was mentioned in the alert after closing.
Before coding I was chasing existing frameworks or easy to use code, without much success. Until version five of Apple’s mobile operating system there is not much which could make the developer’s life easier to validate form inputs.
Not much means there is something. Regular expressions can help setting up rules for strings and check for them. Starting from iOS 4.0 it is possible to use regular expressions without using third party libraries.
Furthermore Apple provides “NSDataDetectors”. These can be used to find specific type of data within a text. The data detectors are used almost everywhere in Apple’s Mac OS X software such as Mail. When moving the mouse over a date, a telephone number or an address you are able to interact with this kind of data—such as adding it to your address book or calendar. Starting from iOS 4.0 they can be used as well.
Due to us wanting to Open Source this framework it was important to create easily extendable code. Everybody should be able to contribute types of validations by simply adding a class without interfering with the core.
The following scheme shows the high level principle.
On the other hand the coder who wants to simply implement the framework should not need to do very much. Thus the UITextField and the UITextView was overridden what saves some additional classes to implement. Legacy code can be changed quite easy with this approach by replacing the text inputs with the validator text inputs. A thorn in my side are the delegate methods of Apple’s text inputs.
- Both, UITextFieldDelegate and UITextViewDelegate, must be served
- Redundancy when validating a lot of forms unless you are writing a kind of central controller
- Not convenient for the purpose of validation
To fix the first issue the form validator framework text inputs are using one protocol. The second issue is partially fixed by the first one and completely fixed by decentralising the validation process into validators connected to the input field.
Those validators are queried after every changed input or after the text field loses focus. The developer does not need to worry about this process which will lead to fix the third point. Basically I only want to know whether the input was correct or not. Furthermore, I want to know what went wrong. I do not need to know whether something changed or other unnecessary information for the sake of validation.
Tells whether a text input changed from valid to invalid status or the other way around.
Tells what went wrong. The framework provides a list of mistakes in form of violated conditions. The list is empty if everything is fine.
Using the validator text field is fairly easy, simply use it as a UITextField and add a preset validator to it or create your own. Each validator contains one or more conditions. Because the order of conditions matters, you are able to create a validator with priorities which is quite powerful.
Feel free to try the example and read further detailed instructions on GitHub and as always, feel free to contribute.