Building a No-Code Mobile App with Adalo (Part 1)

Adalo has the reputation of being one of the easiest platforms for building mobile apps, so I picked it as my first stop in a series on creating no-code mobile apps.  Adalo's free plan lets you explore the platform and build as many apps as you want, although it limits you to 50 rows of data. You can also share access to your mobile app, but if you want to be able to store a reasonable amount of data, publish your app to the Google and Apple stores, publish to a custom web domain or connect to outside databases, you need to move to the "Pro" plan which costs $50 a month.

In my case, the free plan works fine, especially since the app I'm building is very basic, with just three screens. The app is designed to keep track of projects I'm working on, appointments I have scheduled, or just things that catch my attention that I might want to explore later. There are only five fields for each item: key words (product name, company name, item subject, and so on), date added, "target date" (such as meeting date or due date), item description, and item reference (URL, etc.). If I use this same layout on other platforms I'll probably add an image field too. 

Once you sign up on Adalo you can choose to make a desktop web app or a mobile native app, then you pick whether you want to start with a blank app or one of a half dozen app templates. For my project, I wanted to build the entire app myself so I started with a blank layout. The next step is to name your application (I named mine "Lest-I-Forget") and to pick the color scheme you want to use (green and blue-green in my case).

Adalo takes you straight to the design canvas when your initial setup is complete. At that point you'll see three screens already created for your project, a "signup" screen, a "login" screen, and a blank "Home" screen. Since I wanted my app to be public, I went ahead and removed both the signup and login screens. To do that, I clicked on the "Screens" icon on the left side of the design window, chose the screen I wanted to remove, clicked on the 3 dots up by the screen name, and selected "Delete". Note: If you wanted to restrict who can use your app, these two screens are fully functional and connect to a "Users" database that Adalo supplies automatically.

At that point, I decided to set up my "Items" database or "collection", so I clicked  the "Database" icon on the left side of the design window and selected "+ Add Collection". I named the collection "Items" and added the five fields (key words, date added, target date, item description, and item reference). Note: After you add the first field in your database record you need to click "+ Add Property" to set up each of the remaining fields. 

With the database created, I went back to "Screens" to work on the app design. A quick note at this point: Adalo has some keyboard shortcuts that can be really useful. As you add screen layouts the new ones are going to start disappearing off the right side of the design area. To move them back into view, press the right arrow and the CTRL key (CMD key on a Mac). Later, as you move back and forth between app screens, press the CTRL (or CMD) key and the left or right arrow, depending on which screen you want to bring back into full view. You can also press the CTRL (or CMD) key and the "+" key to zoom in or the "-" key to zoom out.

The only screen I had at this point was the "Home" screen, so I decided to use it as my main menu for the app. I clicked on the "Screen" icon on the left side of the design window, selected the "Home" screen, and clicked on "+ Add Component" to add a button element. Once I dragged and dropped the button onto the home screen, the button properties manager displayed on the left side of the window, with the name "Button 2". I changed the name to "Add Item Button" by clicking on the pencil icon next to "Button 2", then I changed the button's text to "Add Item". Scrolling down further, I selected "+Add Action", clicked on "Link"  and "New Screen", and named the new screen "Add Item".

I'll get into the details of creating the different screens for my app in Part 2 of this post...

The Next Step in No-Code App Building?

Most no-code platforms offer you two choices when you decide to build an app - you can start from scratch or you can use a pre-built "template" app and modify it to fit your needs. And most platforms also provide "plug-ins" to perform specific functions not built into the platform, such as connecting to third-party web services. But what if you create an application, then decide that you want to add a new feature but don't know how to go about building it?

Bubble.io is working on providing a solution for those situations (and a couple of other platforms are starting to move in the same direction). Bubble's answer is "Blocks", self-contained mini-apps that you can drop into your existing app.  For example, maybe you have an app for your hiking club where members can post photos and videos from their latest hiking trip along with information on where they went, where to stay, best places to eat, and so on. Only now you would like to have everyone go on a hike together and you want to do an online survey to get ideas on where to go.

You don't have much time to make changes to your app if you're going to get this trip in before winter and you're not even sure how to set up a survey. If you built your app on Bubble, you could go to Zeroqode (www.zeroqode.com) and buy their "WeVote" block for $35, set up a new page in your app, and drop the WeVote block into that page. With a little modification of your database you could have a survey up and running almost immediately.

You can find a number of other "blocks" on Z eroqode, including a "Projects Board" block (to keep track of personal or team tasks), an FAQ block (to provide users with more information about your products or services), and a Messaging block that includes a login/signup page, a user profile page, and a conversation page.

Note: See the previous post "Blocks withing Blocks" for an example of how Betty Blocks is working on this same concept.

Template of the Week (April 12 - April 18)

If you love online learning sites like Udemy and would like to run your own, Zeroqode has just the template for you. Their "Learny" template includes everything you need to start your online learning school, including subscription plans, unlimited courses, student discussions, and online billing and payments. Plus it's customizable so you can give it the look and feel you want. 

Zeroqode describes Learny this way:  

Learny SaaS Online Learning Platform is a no-code platform that is designed for running your online school.

It allows you to add an unlimited number of courses, each of which can have its own curriculum organized around sections and classes. The platform comes with Wistia integration as a hosting solution for all video lectures.

The platform suggests the subscription model access to the course content and the payment gateway used to achieve that is Stripe. There are 3 subscription plans configured. Users in the platform area are able to have discussions under each course which will increase community engagement.

The powerful admin panel offers a lot of impressive features including the ability to check logs and statistics, manage users, FAQs, courses, and much more! This template was used to build ‘The Lab’, You can see this template in action by visiting and registering in the Zeroqode Lab (it’s Free! ), the Lab is an online learning platform to teach you how to build apps without code.  

FEATURES:

- Landing page

- Responsive design

- Wistia video hosting integration

- Subscription plans

- Payment via Stripe

- Powerful admin dashboard to manage the platform

- URL sharing

- Comments and replies section

- Google and Facebook Logins

- Logs and Statistics

You can purchase a standard license for $399, which entitles you to create apps from this template for your own use (business or personal). To create apps for clients you need to purchase the developer license, which is a little more pricey at $1197. Find more information about Learny at https://zeroqode.com/templates.

Google's new Web Page Rating System

Google's "Core Web Vitals" system for ranking web pages is set to take over in June and it's already making waves according to this article from TechRadar.com: 

Popular websites fail to meet basic Google SEO requirements

By Abigail Opiah (4-21-2021)

(https://www.techradar.com/news/leading-websites-fail-to-meet-seo-requirements-for-imminent-google-update)

If you scroll down a way into the article you'll find this statement, which may be of interest to those of us who build websites on Wix, Wordpress, Webflow and other no-code website providers:

Google's Core Web Vitals will assess how quickly the content on a page loads, its responsiveness and its visual stability. 

In conjunction with the factors highlighted by the study, Core Web Vitals will also penalize unnecessary code on web pages built using website builder templates from the likes of WordPress and Wix.

I don't claim to be an SEO expert - in fact I tend to get lost in the complexities of Search Engine Optimization. However, that statement sounds like the new ranking system is penalizing no-code sites right off the bat. If I'm misinterpreting this I apologize, but my impression is that people who can't afford to have their website built by professionals are automatically going to take a ratings hit.

Testing No-Code Apps

 Why should you worry about testing your no-code app (other than making sure it does what it's supposed to do? After all, you assembled it from pre-built components that were created by expert programmers using best practices, right? And there are probably hundreds, maybe thousands, of other users working on that same development platform creating applications using those same components. In effect, all those other users are beta testers and would have uncovered any significant flaws in the coding.

All that's true, but there is more to app testing than just confirming that the program produces the correct output for the input fed to it. To make sure your app performs as well as possible you need to test it to see if it:

• Provides a good user experience, with a UI that is simple, uncluttered and easy to navigate. In addition, the user interface should conform to general standards - for example, on a mobile app, if the user pushes outward with both thumbs from a portion of the screen that part of the screen should expand, providing an enlarged view.
• Works properly on different devices. If your app is designed to run both on the web and on mobile devices, you should either have two separate designs (one for the web and one for phones, tablets, etc.) or your screen designs should be "responsive" so that they display properly on any device.
• Does the app integrate properly with other functions if it's running on a phone? Does it minimize when there's an incoming phone call? Are incoming texts or notifications processed properly while the app is running and does it interfere with other apps that are running at the same time? How much drain does it put on the battery? 
• Can stand up to an increasing number of users. Does the app slow down noticeably as the number of users starts to climb? 
• Struggles as the size of user databases grow. As the total number of data records among all your users increases, does record retrieval speed take a hit? 
• Recovers successfully from unexpected shutdowns. Does your app lose or corrupt data if it terminates abnormally? 
• Provides adequate input validation. Some of the hardest bugs to track down are due to user input, such as managing to enter a control character in the middle of a data field or creating a situation that involves dividing by zero.
• Provides adequate security. Even if the platform you're using includes built-in security features, it's possible that you failed to take advantage of them or introduced elements (like images) that can be hacked. The last thing you want is an app you built to have a security issue - that can turn off potential users in a hurry.
• Functions properly with any APIs you're using. If you're using one or more APIs (Application Programming Interfaces) in your app you need to test those connections to make sure they're working correctly.
• Works properly with any available deployment option. If your app can be deployed in multiple ways you need to verify that it can be set up successfully under each environment.
• Provides necessary guidance for users. If a user needs information on how to operate the app, is there a question and answer or help file of some type available to the user?

There are a multitude of tools you can use to test the different areas of your app, but most of them are expensive and/or somewhat complicated to use. Coaching No-Code Apps (https://coachingnocodeapps.com/) has an article covering a number of free or inexpensive testing tools including:

• A Chrome extension called Mobile/Responsive Web Design Tester, which allows you to test the responsiveness of your app on multiple devices with different screen orientations and screen resolutions.
• Loader.io is a free tool that lets you test the scalability of your app by simulating thousands of simultaneous connections.
• Neil Patel’s SEO Analyzer is another free tool that analyzes your app for  Search Engine Optimization, tells you where your app is weak on SEO and tells you how to fix it.
• Postman offers a free plan that lets you test APIs under multiple variables and environments and even allows you to automate testing.
• SSL Check is a free tool to scan your app for non-secure content by crawling for images, scripts, and files that will trigger warning messages to visitors. 

For more testing options and details on how to test your app go to:

https://coachingnocodeapps.com/application-testing-tools 

Microsoft Power Apps: Model Driven Applications vs Canvas Applications

There are actually two types of Power Apps - model-driven and canvas apps.  Canvas apps are primarily concerned with the user interface and are created by dragging and dropping various components (text boxes, drop-down lists, images, formulas, etc.) onto a blank design screen or "canvas". The developer has full control over every aspect of the design, including the type, size, and formatting of the components. In addition, canvas apps aren't restricted to a single data source. You can attach multiple sources to your app, ranging from Excel spreadsheets to SQL databases. 

So, what is a model-driven application? Here's a definition from Wikipedia:

A model-driven application is a software application that the functions or behaviors are based on, or in control of, some evolutionary applied models of the target things to the application.

If that didn't entirely clear it up for you, model-driven apps are based on the data connected to them. Rather than the person creating the app having control over the design the user interface elements are selected based on the underlying data. You can see the same approach in some other platforms (such as AppSheets or Mendix) where the entire app is built by the platform according to the data being fed to it with very little room for changes in the overall design. 

While canvas apps tend to be built for a specific task (helpdesk ticketing, event scheduling, employee timesheet management, etc.), model-driven apps are more generalized and can be adapted to various purposes, such as customer service management or business process management. Model-driven apps can also be used as a backend by embedding canvas apps inside them. 

In addition, model-driven software isn't composed of program code like canvas apps. Model-driven apps are basically a set of particular options chosen from those available with the design model itself and at runtime the platform simply executes a modified version of the model rather than a series of custom program codes.

So, when do you use each type of app? Basically, you would use a canvas application when you want to create a program for a specific purpose and you want the user to be able to control the different functions in the application. On the other hand, if you want to have the users' actions to be guided by a certain procedure or process, that's when you would use a model-driven application. 

Make Planning your App a Team Project

If you're building an app that's going to involve a number of people (a business process automation app for example) it's a good idea to get everyone to help work out the app's design, right from the start. There's a great scene in the movie The Founder where the main characters are trying to design the perfect layout for a kitchen at McDonald's. After some discussion they decide to take the restaurant kitchen staff to a tennis court, draw a chalk outline of the kitchen design on the court and then have everyone go through the motions of actually working within that chalk layout. After a number of failures and redrawing of the chalk design they're finally able to find a workable layout.

You can apply the same idea to developing a prototype for an app that's going to require the coordinated actions of a number of users. First, gather information from the users as to how the work is being done currently and how they think it should work with the new app you're building. Then create a detailed mock-up of the process (a flowchart, diagram or model of some kind) and have everybody walk through it together, step by step. 

This is the point where the details that slipped through the cracks initially start to show up. "Jane is supposed to get that information from Fred on Thursday morning, but Jane's in a manager's meeting at that time on Thursday", or "Tom can't update those records at that point because he won't have all the sales data". Or maybe someone mentions that revisions are made to the payroll data occasionally after it's been sent to Carla and there's nothing in the workflow to handle a situation like that.

Changes are going to need to be made to the design of the app as it's being developed, but a "test drive" of the design during the initial planning stage can often uncover some of the biggest "oops's". There's nothing that causes greater friction between developers and users than the "WHY DIDN'T YOU TELL ME THAT IN THE FIRST PLACE?" moment. There's a good chance you can avoid some of those moments simply by doing what the McDonald brothers did in the movie - get everyone to walk through the workflow you've designed before you even begin to build the software.