Best-Practice App Building Part 2 - How Are You Going To Do It?

So, you now know what you need the App to do, and what data you need to collect. Well, how are you going to do it? 

As with the poet laureate and the child, it’s possible for you to put one Longtext Field on a page, allow the user to write everything they want to write; date, time, name, case number, etc, into the Field, and be done with it.

That would work.

Although it would work much in the same way flooding your house from floor to ceiling would allow you to have a bath. It’d work. We don’t recommend it. 

There are four considerations when creating your user inputs:

1. The data to be collected

2. The format in which the data needs to be collected in order to be useful to you

3. The process, and

4. The user experience

We’ll begin with the data to be collected.

This, in principle, is fairly straightforward - as with reforesting the Bismarck last week, the Fields in an App should be relevant to the purpose of the App. The lowest number of Fields necessary to gather all the information you require should be used; this reduces clutter on the page (user experience) and avoids overcomplication when building the flow of data (protecting your own sanity). Trying to remember whether a Field is superfluous or not should never occur.

                Now that the Bismarck has enough foliage, how do you plan to have a bath?

Do you plan to fill the house from floor to ceiling? That would still work. Or, would you prefer to luxuriate in a candlelit bubble bath, to the melancholy serenity of the lonely 52-hertz whale?

By which, naturally, I mean matching the data you need to the type of Field you use.

Naturally.

An example of matching the data required to the data input method would be logging the date, using the ubiquitous Text Field; you can do just about anything with a Text Field. The Swiss-army knife of Fields. You can input letters, numbers, and special characters. So, if you need to use a Field to collect the date from a user, for example, you can just use a Text Field for it.

The user is free to write the date in any format they choose:

• dd/mm/yy

• mm/dd/yy

• “The twelfth day of February, the year of our lord two thousand, twenty and one”

• or dd/mm/yyyy, if the user is feeling whimsical.

Entirely freeform, a user has the freedom to enter the date into a Text Field in whichever format is most natural and comfortable to them.

                                                                                   That is a problem.

Freedom to enter data in whichever way comes to the user’s mind can be not only impractical but often almost unusable for the data managers. When you have ten users submit the same data in ten different formats, you can’t use this data as a single metric - it becomes ten different metrics. For example, if you needed this data to create a graph with the date along the X axis, you would have ten individual entries, rather than 10 entries for the same axis.

What one needs is Field Validation - it’s not enough to simply know what data you want to collect. You must enforce a standardised format for collection of data wherever possible. Therefore, in our example, you would use a Date Field instead of a Text Field; this forces all users to select data of the same format, making it uniform across all users.

2) Inputs

In summary, where possible, match the Field you’re using to the type of data you want to collect. If you need lots of text from a user, use a Long Text Field. If you only need a small amount, or a few words, use a Text Field. Need a number-only response? A Number Field. Softools offers a long list of Field types, all of which can be configured in a variety of ways. The Support Articles section of our website has information on every aspect of the platform, including all Fields and their more advanced functions. 

Using these options you can restrict (I prefer “guide”) user data to come in the format you require. Even if you don’t think this is necessary, you’ll thank yourself down the line for doing it. 

An example of some validation you might make use of is adding a maximum number of characters that a Field can contain, or a maximum numeric value for a Number Field. You can also use sliders (Range Fields) to add more visually interesting elements to the page (again, user experience) and often serve a more robust purpose in adding a visual representation to what is, in fact, a scale - eg assessing the likelihood of a risk occurring on a scale of 1 - 10.

Inputs means two things: the actual inputs (users typing away on their keyboards), and the intended purpose of those inputs. Inputs don’t exist in isolation, they’re part of a process. A grand scheme. That is, assuming you’ve planned your process properly. If not, you’re not quite ready for underground lairs with waterfall entrances (or whatever the no-code equivalent of that may be).

For example, you may require some information from a user. This information is part of some greater system of information - let’s say there was a minor incident at the office, and you have an App to log these incidents. You may also have a second App to log the actions for these incidents, so you can actively improve the safety of the work environment and prove you are doing so.

Entering a name for this incident is good, but having a name and an automatically-generated incident ID is better. Therefore, as part of the process of logging an action for this incident, the action must be created after an incident. This means that the action will pull information from the incident in order to show the user that they’re associated - otherwise you are left with a jumble of documents with no association except those that can be remembered. 

Is there more to the process than that? Is the ID generated using information that the user has to input first? For example, a unique ID generated using the first two letters of the first name, the first two letters of the last name, first two letters of a location, and then a 4 digit number? If so, this ID can only be created after other information has been acquired - there is a process to follow. You cannot generate the ID before you know their name and location.

A simple example, but can be extrapolated to myriad other situations, and any complexity you need, or want.

Always plan your flow of information - steps will often have sub-steps. Knowing how your App works before you start building it will bring down the build time considerably, and reduce the chance for mistakes to creep into your work. As always, we recommend considered, thorough planning with anyone you can benefit planning with. 

You may notice a trend, by this point - plan, plan, plan. In the next entry we’ll discuss how to handle the other end of planning an App - avoiding soggy deckchairs.