When first tasked with creating a new QuickBase App, it is easy to jump right in and begin the build. The creation of a new QuickBase App can be exciting; however the desire to start the build immediately is wrought with danger. Prior to beginning a new QuickBase App, the first five common mistakes made by App developers needs to be considered to ensure a successful App is created.
(1). Purpose, Necessity and Use
Before any planning and development for a QuickBase App begins, it is essential to understand the purpose of the new QuickBase App, and if there is already any other QuickBase Apps within the current account which already fulfil the needs of either yourself or its current users.
What is the purpose of this App?
As a developer you need to ask yourself, and others who plan on utilising your new App, what is the purpose of the QuickBase App. It’s a simple question, but sometimes the answer between a developer and the end users varies greatly.
Is it necessary?
Is there already an App available within your QuickBase account which completes the functions that you’re after, or close to it? Building an App for the sake of it isn’t always the answer. It may be necessary to just make alterations to a current QuickBase App being utilised within your account.
Will it be utilised?
Ask yourself, will the end users accept and utilise the App your building. If there is resistance to the work you are undertaking, it’s use will either be minimal, or have a negative impact on both the quality of information collected in the database, and the sentiment towards your new QuickBase App.
Although as a developer of a new QuickBase App, you have an understanding of what it is you are planning to build, it is often the case that the plan is in your head.
As painful as it can sometimes be, getting the plan of a database documented on paper, or in a design software package is important. Being able to see the relationships that each table has to one another is important. It allows you as a developer to sometimes see where issues may arise or where modifications to the design need to be made. For example does a field need to be referencing to a relating table, or is it okay to be a Text field with multiple choice?
(3). User Input
If you are the only person utilising the QuickBase App. Collating user input as to its build will not be necessary. However if others are expected to utilise the App, collating their input during the planning point is essential.
The expectations of others who may be required to utilise the QuickBase App, may vary greatly from you as a developer. If end users have a different understanding of the QuickBase App and its purpose, as well as the processes they are required to complete the forms and fields, the build may have a negative impact of others who either have high expectations for the project, or are expected to utilise it on a daily basis.
Getting user input into the build, will also assist end users with getting an understanding of the logic behind some of the decisions and design processes necessary for a developer to go through. Their understanding of this can make the job easier.
(4). Roles and Permissions
Getting the Roles and Permissions set up correctly, then tested thoroughly is essential. Nothing is more frustrating for an end user to discover they are unable to undertake their set tasks due to the roles and permissions not being set up correctly. Whilst nothing could be more dangerous in an App, where private or confidential information is able to be accessed due to an oversight in permissions, or lack of testing.
Plan the Roles and permissions, document them and test them repeatedly. It is recommended to use the function Test this App as another role available within any QuickBase App to ensure that there are no oversights. It is also important to attempt to be mischievous during the testing too, by this I mean attempt to be someone who is deliberately attempting to skirt the rules of the App and access information they should not be able to see. Nothing can be more damaging to the reputation of a builder or the App if data is misused due to an oversight in permissions.
Reports tend to be the last task on a build by a developer in a QuickBase App build. This doesn’t always mean their importance is the lowest. In many cases the reports are of high importance, being the end result of all work and data collection, and in many cases the initial justification for a new QuickBase App is to get better reporting.
Reports often become forgotten, and Apps are often released with the reports incomplete, as a way of starting the data entry process quickly. The result of this can be that users often are entering information, with the inability to see the result of their hard work instantly. This can often cause disillusion or negativity by the end users.
Including the Reports functionality into the planning stage of a build for a new QuickBase App is important, this will help to ensure that the reports are not the last thought as part of the build and their importance is kept at the forefront of the project.
Review Common QuickBase App Mistakes
In summary, plan your new QuickBase App thoroughly, document the process and ensure that all end users provide you with their input. Ensure that you know why you are building the QuickBase App. Make sure that the security is thoroughly tested and reporting functions are complete at the time of release. Failing to take these simple steps can result in a database which for end users can be clunky and incomplete, creating more work for themselves, and a possible security or confidentiality threat.