Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
Today we jump back a little bit in time as it was several weeks ago when we introduced our “ToDo” case. Remember it?
…There was a ‘project’ and our project had a lot of to-do items in it. These items start in a ‘Draft’ state and progress through several state definitions till the to-do item is ‘Done’ and all members in our project are very happy as the project can be ‘Closed’ when all the to-do items are in ‘Done’ state.
There is nothing better to do some review work on all the to-do items so tasks will be sent to the correct members in our project to make all the hard work happen.
And you probably also remembered the ERD that we created in that time.
The entities are created and we continue our journey on implementing the building blocks for these entities, but before we start with this let’s give a small overview of the several categories of building blocks we have.
Let get right into it…
After starting the VM and login into the AppWorks Explorer with the ‘awdev’ developer user its again entering our workspace with the corresponding project. In that project we created the ‘entities’ folder and there we can open an entity. It’s not important which one as we want to look at the several categories available for this post.
In this screenshot you see some building blocks are grayed out. That is because they are already used by the entity (as they might only be used once) or that building block is related to another building block that is not yet used on the entity.
Structure
The basics (or fundamentals) of the entity. Here we define all kind of attributes/properties for our entity. Together with the relationships it defines the structure for our ERD that we saw in the introduction of this post.
Having a good steady structure is important for a best start of your solution as all the other building blocks are depending on this. Changes in this structure can happen but will probably let you change other building blocks also as configurations might break. It’s the same with a chair from which you would like to shorten a leg while somebody is setting on it…Watch what happens. 😊
Presentation
When our structure is ready, it is a good time to start thinking of a UI and how things are represented to the user, how they can find back the created instances of the entities and what actions can be applied on a specific moment in state of that entity.
UI must be created from scratch and from my experience it is good to have someone in the team who has a UI-design background. This person ‘understands’ why a button must be placed on a certain spot to have the best interaction with an end-user. It’s all about naming, coloring and making it all recognizable for our beloved end-users. This design is not only the input on how to create the best look and feel for the solution, but it also triggers discussions for a best-for-all design in User eXperience.
A good tool and widely used is called Balsamiq
I know we live in an ‘Agile’ world these days, but it is always good to start a discussion with a quick draft before you create it in real life. Trust me…That is my experience!
Business logic
After the UI creation it’s time to think about the business restriction and ‘secret’ actions that should be applied on certain event. The most common things in this category is the ‘lifecycle’ and the ‘rules’ that can be applied. We take a deeper look on these 2 in other posts.
All the business rules within the company for the solution can be applied in this category. It’s good to have a proper list defined by your ‘Analyst’ guy that can be fitted into this category. Sit together with this person on what the possibilities/restriction are for the low-coding part. As you might have seen, this can get complex and it’s the trick to keep it as simple as possible so everyone has a good understanding what happens in the solution. Good naming and labeling for the building blocks are crucial here.
Functional
The last category…It’s also a bit the ‘extension’ category. Here you can add all kinds of non-required features to an entity. Most important are the file/content, email and webservices parts. All not needed by default, but options to use when implementing a certain functionality. Most of the time they will ‘help’ to expose the functionality to other building blocks so they can reuse them.
Also, this is a task for the ‘Analyst’ guy to figure out if any functionality is needed to expose for that entity.
A last thought
Maybe as a ‘developer’ person you might have noticed something. Well, I noticed something after reading back what was written down and especially the order.
As a ‘developer’ you normally learn to not think in UI/UX/GUI (yeah…it’s all the same from my point of view…we can discuss if you like) and don’t think in ways to save things! So, databases and UI is the last thing of your concern.
And now we are in the ‘low-code vibe’…and what do we see?…The structure part is still in place (although a database is already in place), but now UI is in front of the business logic as well as the extra functional requirements.
I understand this is happening now, because it’s a bit hard to test you work from a front-end perspective when there is nothing to click on. For AppWorks this works pretty straight forward at the moment when you work in small iterations, but maybe in the future we will get some kind of ‘UnitTest’ building block where we can only test the created back-end business logic and functionality without the use of a front-end…It’s just a thought…?
Well, that gives as a ‘DONE’ for this post. Not a large post this time, but it gives us a good overview of the available building blocks categories. This overview gives us good ‘header’ to our next step where we start implementing the building blocks for our entities. So, keep your focus on the site where we continue our journey for AppWorks. Don’t forget to subscribe to get updates on the activities happening on this site.
