What Are Cards in the ACENji NoCode Platform
How do you build a Web site today that is also Progressive Web App (PWA) and work and looks great on mobile and then how do you do “Mobile First” development? - not so easy, right?
Or shall we say, not so cheap!
Like with everything else, the software industry is also evolving and Low-Code and NoCode providers are trying very hard to fill any gap left in the traditional custom software development.?
NOCode is in its early stages and a lot of it is yet to be formalized in books and educational culture but so far most NoCode providers out there are just building more and more sophisticated solutions with an eye on the ultimate goal:?
So far the software industry had been focused on creating Web pages that form something the public knows as sites based on their domain and then the different variations that are built around PWA or native apps that replicate that Web site.
At Acenji’s we thought, why not give a try something little different as an approach. Why not create the formation of containers at the native mobile level that will automatically act as components for the Web site pages.? The idea of this approach is to provide very fast development of native mobile apps and scalable Web pages driven by API and web services.??
In order to do that we have to solve a few simple architectural questions. One of these questions is what is the formation of the container that creates Web/ mobile apps and is 100% NOCode driven?
Well, meet ACENji’s NoCode approach called Cards.
For the audience to understand what Cards are, maybe we can go over what Cards are not?
Cards are not Forms. Forms are those structures where you fill in some data and click submit. They are used for surveys, assessments, or just contact. They even have an HTML tag defined as <Form> and user input and interaction are the targeted outcome. Forms are used today to fill servers with appropriate data like credit card transactions, user input data, etc...
Form have some limitations like users cannot edit the actual record at run time, they have requested that same record after the server processes it, data do not know each ether between forms as their lifetime is to deliver data to the server only via POST or use Get to grab in read-only approach data. The form can also use other protocols like emails.
领英推荐
Cards on another hand are defined inside ACENji as individual apps. Basically, each Card represents what a Web page is historically but acts like a mobile app used by mobile devices. They could be 100% client-based or hybrid client/server formations.
The coll thing is that Cards can blend together and work as one app so users would never understand that these are separate apps. Historically, this had been difficult to construct out of the box and keep all together.
The cool thing about that approach is the ability to share information. ACENji’s patent talks about a gateway to the Metaverse for a reason. We believe that our approach gives users the ability to share information in real-time with millions of other users not just inside the same app but across other apps and in between. The information that is shared can travel up and down the grid and can be shared for a specific time period, by geolocation, or other rules utilizing blockchain or other public or private databases.
By design, Cards can have a hierarchy and one Card can control another Card, and so on.
Because of that, a complex workflow can be created that currently requires custom software development and a tin of logistics and special tooling.
Each Card comes by default with its own report system attached to it, and if that Card is in a graph relation with other Cards, so be it: the report contains all the data anyway and can be viewed and shared using PDF or CSV formatting. Usually, users can designate one Card to become the collector of all information and be the gateway to reporting.
Now Businesses can just build Cards together and only specify in design time what to appear on a report and it is done.
Cards also give a reverse design approach to users today: instead of doing all of the development for websites first and calling it “Mobile-First”, “Progressive Web Apps (PWA)”, etc… Cards actually are Mobile First – Everything Created by Cards instantly appears on Mobile stores first and is ready for consumption, then the Web version is provided with an interface to feed the Web pages with Cards data via API.
Another interesting approach is that Cards can be used to create one app that works on mobile but actually will never be used on mobile if the desired target is to provide non-programmers the ability to create for example an inventory and relationship of items that automatically get API to be exposed and fetch it to Third-party Web site to display that information. This way nonprogrammers can supply at run time the connection to the Web site without rebuilding it but with significantly faster load time compared to WordPress for example.?
All of this is happening thanks to ACENji’s built-in declarative language that shares information with the Web pages via Web Services.
Cards can be used to be combined as widgets and libraries and add a construction industry almost around the idea that now, a Non Programmers or machines are not restricted to building connected apps for any purpose.
What to learn more? Reach out to me and share your vision of how software should be built. At ACENji we are constantly looking to collaborate or provide use of the software for those in need.