Wednesday, March 31, 2021

Planning Your No-Code App


Some years ago I read an article that stated that a successful app consisted of 50 percent planning and 50 percent execution. Based on my own experience I firmly believe that's true. Of course, just like in the military, plans never survive intact once the coding and testing phase begins, but having a clear road map in mind from the start helps you avoid a lot of grief.

So, what's involved in developing a plan for building your app? Here are a few ideas for creating a solid software design:

  • Define your app in as much detail as possible. 
    • For example, "I want to create a game app" needs a lot of refinement. You might break that down into "I want a game app where you're being chased by a bunch of cut-throat thieves", or "I want a game app where you're being chased by cut-throat thieves in the jungle and there are supernatural creatures that may or may not help you".
    • If it's a business app you might be creating an inventory app to handle inventory tracking, costing and stock alerts. But you might also want the app to handle barcoding and forecasting.
  • Investigate any similar apps you can find to make sure you're not leaving out any important features that you might need and to see how others have designed their programs. It's not cheating to explore different ways to structure your app.
  • Try to find potential users for your app and ask them what features they would expect or hope to find in that type of application. It's also a good idea to attempt to recruit a few people who would be willing to provide feedback while you're building your app and to act as beta testers for the completed application.
  • List the main features for your app. In fact, sketch drawings of the basic pieces that make up the app and assemble them in a workflow showing user inputs, including possible user actions and resulting responses. input validation, error trapping, recovery procedures, data storage, integration and reporting. 
  • If your app involves communication between multiple users, make sure to add that in your planning including whether that communication will be done directly in the app or externally via email, text, or notification software.
  • Be sure to take timing into account. How much time do you have to create your app? Is there a deadline you have to meet? Time constraints can force you to prioritize certain features in your app and leave out some "nice to have but not essential" features.
  • Decide which platform to use to build your app. Different platforms may be better for standard business apps, social apps, games, process management, etc. Also, check on the templates available to you. It's possible that you may find one that you can modify to do what you want with a minimum of modification. However, research templates carefully, because a template that's only slightly similar to what you want can end up taking more time and effort to change than if you create your app from scratch.
  • Beta test your app. Get family, friends or anyone you can recruit to test your app as you're building it in order to get feedback on what you may need to change or improve. One big advantage you have by working with no-code is that with standard app development you end up spending a lot of time uncovering and chasing down program bugs - with no-code you may uncover some logic errors but (if the platform is reliable) you won't be exterminating bugs.
  • If you want your app to be available to others, plan for how you're going to distribute or market your app. Your choice of development platform may affect the distribution methods available to you, so take that into account up front when you're deciding which platform to use.
Oh, and one final thing to include in your planning - document your app. Keep notes as you go so you or someone else can follow the purpose and structure of your program later on. Since you can't include remarks in the program coding, add documentation wherever you can so the app doesn't look like a mystery wrapped in an enigma six months after you finish it. 

Okay, that's it for planning your app. The only other advice I have is to actually take the time to do some detailed planning - you won't regret it.

Monday, March 29, 2021

How API Connectors Work


What is an Application Programming interface? It's exactly what it says - an interface between two application programs, a piece of software that allows different apps to communicate with each other. In the same way that you use the black box pieces of code on a no-code platform to build an app, your app can use an API to create a connection to another application like Stripe or Facebook and exchange information with that service. The API itself is simply a piece of software installed on the server you want to access. 

When the two computers connect or "integrate" via the API, they have to agree on the set of rules (or "protocol") they're going to use to communicate with each other (similar to two people deciding what language to use to carry on a conversation). Since Hyper-Text Transfer Protocol (HTTP) is the most common protocol on the Internet, many APIs use it as their communication protocol.

Once a connection is established, the client (your app) sends a request to the other computer (the server) and receives one of three responses (an acknowledgment that the request was handled successfully, an error message explaining that the request failed, or the data requested by your app). The request sent by your app is made up of four parts:

  • A URL that provides the location you want to connect to on the server. The URL itself consists of three parts:
    • The address of the server (www.youtube.com).
    • The specific location you want to reach on the server (/results).
    • The query string parameters (?search_query=bubble.io).
  • The HTTP method:
    • GET request - Asks the server to retrieve a resource (a webpage, product, image, etc.).
    • PUT request - Asks the server to update a resource (change the address in a customer record for example).
    • POST request - Asks the server to create a new resource (e.g. create a new customer record with the data in the body of the request).
    • DELETE request - Asks the server to remove a resource (e.g. delete an inactive customer record).
  • Header records: Additional information to pass on to the server, such as the time of the request, the request authorization, type of content, and response cookies. 
  • The Body: The body of an API request contains the data that your app wants to send to the server and that data has to follow a specific format that the server can understand. A typical API connector encodes the data in a text-based format called JSON (JavaScript Object Notation). Here's an example of data in JSON format:  { “First name”:”Gary”, "Last name":"Morrison", ”Company”:”Global Imports”, "Email": "GaryM@global.com", “Primary contact”:true}.
Most servers require you to send a unique authorization code (referred to as an "API-Key") that identifies you to the server. The third-party service will issue you an API-key (normally a long string of random-looking characters) when you sign up. There are several ways that an HTTP API-key can be included in your request:
  • As part of a query string in the URL (?something+API-key). 
  • In an HTTP header record.
  • A user name and password (which act as the API-key) can be sent as part of each request.
Once the server receives a request it will try to fulfill it, then it will send a response back to the client. Similar to a request, an HTTP response has three parts: a 3-digit status code, headers, and a body. 

Status codes indicate whether the request was handled successfully or not. Common status codes include:
  • 200 - Request succeeded.
  • 404 - The requested resource doesn't exist.
  • 503 - Website is currently unavailable.
There are actually five classes of response:
  • 1xx - Request received, continuing to process.
  • 2xx - Success (requested data delivered or requested action completed).
  • 3xx - Redirection (additional processing needed to complete the request).
  • 4xx - Client errors; the request isn't correctly structured or can't be fulfilled.
  • 5xx - Server errors; the server failed to handle the request correctly.
Once the response is delivered, that round of the request/response cycle is complete. Any further interaction through the API is up to the client. 

That's the general idea of how an API works - but how do you make use of one on your no-code platform? Most no-code platforms have a way to connect to various APIs, either through some function that's an integral part of the platform, or through a plugin or a third-party integration service. For example, Zoho Creator has an easy-to-follow description of how to use its API service at:https://www.zoho.com/creator/help/api/v2/  

I'll go into a little more detail on the mechanics of API connections in a later post. Meanwhile, I hope you get a chance to experiment with including API calls in your app - API integration has become an important part of application planning, whether for traditional, low-code, or no-code apps.

Saturday, March 27, 2021

Google's New No-Code Machine Learning Platform – Teachable Machine


If you're interested in exploring the basics of machine learning (without having to learn complex coding methods), "Teachable Machine" can help you do just that. 
With Google's no-code “Teachable Machine” you can develop machine learning models and make them available to others without having to integrate them into an application. You can train models yourself to recognize certain images, sounds or poses (such as whether you're sitting down or standing up), and use them directly on the Teachable Machine website or in your own website or app.

(You can find Teachable Machine at: https://teachablemachine.withgoogle.com/ ).

To create a model on Teachable Machine start by gathering your samples and grouping them into classes or categories. Once you've done that you're ready to begin developing your machine learning model.

What can I train my machine learning model to do? By following the tutorials and examples on the website you can train your model to:

  • Classify images, either from files or live, from a webcam.
  • Classify sounds from short sound samples (WAV, MP3 file support coming soon).
  • Classify body positions, using files or images from a web-cam.

Before you get started though, you may want to look through these frequently asked questions about “Teachable Machine”:

  • What does Teachable Machine use to create the models? The models are built using TensorFlow.js, a Javascript library for machine learning.
  • What method is used to train the models? The models are trained using a method called “transfer learning”. The image and pose models are taught from pre-trained mobilenet models, and the sound model is built on Speech Command Recognizer. In each case models that have already been trained “transfer” their knowledge to your model.
  • Do I have to upload all my training data to the Internet? The training is done in your browser – your images, sound bites or other data stays on your computer.
  • What if my model's predictions aren't very accurate after I finish training it? You can add additional samples and retrain the model in order to improve its accuracy. 
  • What can you make with Teachable Machine? You can find a wide range of Teachable Machine projects (over 15,000 of them) at: https://experiments.withgoogle.com/experiments 
  • How can I make my model available to others? Since Teachable Machine models are built with Tensorflow.js, they can be hosted on Teachable Machine for free or exported to any website, server, or machine that can run Javascript. You can also convert your model to TensorFlow or TensorFlow Lite and download it for local use.

To see a detailed step-by-step tutorial on how to train your model, do an Internet search for: “Teachable Machine Tutorial: Bananameter” by Barron Webster (November 7, 2019). The tutorial shows you how to use Teachable Machine to identify images of bananas that aren't ripe yet, bananas that are ripe, and bananas that are past their prime. Note: The same basic steps would work with any three objects.

One of the important points brought out in the tutorial is how much the model can be affected by using some images with a different lighting or background, images where the banana is between stages of ripeness, or images with a just drawing or photo of a banana, rather than the real thing. In general, the more types of images you include in your training the better the model will perform with real-life data. 

Barron Webster's tutorial should give you a pretty good idea of how to use Teachable Machine to train image classification models. In addition, if you're interested, the author has also created tutorials on how to make a audio model (“Teachable Machine Tutorial: Snap, Clap, Whistle”) and how to make a body position model (“Teachable Machine Tutorial: Head Tilt”).

And if you want to see additional tutorials, here are two more suggestions:

“An introduction to Teachable Machine — AI for dummies”, by Rafael Etereo, February 17, 2020. Creating a model to identify people's hand gestures.

“Teachable Machine 1: Image Classification”, The Coding Train, Nov 7, 2019 https://www.youtube.com/watch?v=kwcillcWOg0 

Finally, for a more in-depth look at how Teachable Machine works, take a look at: “How to build a Teachable Machine with TensorFlow.js”, Nikhil Thorat – deeplearnjs.org. Taken together, these tutorials should give you a basic understanding of what machine learning models are and how to build and train them.

Friday, March 26, 2021

Use a Simple To-Do List to Evaluate No-Code Platforms


A while back I posted about a simple to-do list built on Bubble and mentioned that it might be worthwhile attempting to add more features to it. In playing around with that app I learned a good bit about how to accomplish different things on Bubble, and it occurred to me that I could use the same approach to learn more about other no-code platforms.

You can build a simple to-do list application in a hurry on any no-code development site. Once that's done you can try adding some of the features Bubble suggests including in their to-do app (obviously not all of these suggestions will apply to every to-do app): 

  • Highlight to-dos that aren't completed yet and those that are past their due date.
  • Add the ability to edit to-dos - their title, description, due date, etc.
  • Add a "completed date" to the to-dos if you don't have one.
  • Add a "remarks" field.
  • Include a search function so users can search for a specific to-do.
  • The original app often shows just the current "to-dos". If so, try adding the ability to display completed to-dos with a create date that lies within a certain date range.
  • Let the user set up recurring "to-do" items for regularly scheduled tasks.
There are also a couple of more complicated features that might be worth experimenting with:

  • Add "Projects" to the app. Nest to-do tasks inside projects to turn your app into a project manager. That means modifying the existing to-do report or adding a new report to show tasks by project. It may also involve adding new fields like a project due date, project beginning and ending dates, and the person or persons assigned to the project.
  • Modify the to-do app so that outsiders can use it too. Add a landing page, a login screen, and permissions so that a user can only see their own entries. All that will

    require a user table as well, where the user's id and password are stored.
OK, that's about it for my suggestions about an enhanced to-do list. It can be frustrating figuring out how to add features like these without a tutorial to follow, but you'll have a much better understanding of what you can and can't do on a particular development platform.

Wednesday, March 24, 2021

The Ongoing No-code vs. Low -code Debate

For some time now there has been a continuing debate about whether the future of programming lies with low-code platforms or no-code platforms. Right now the edge seems to belong to low-code development since it allows the programmer to add custom code directly in the app, which provides more flexibility than a strictly no-code platform.

However, there's an interesting statistic that may be a clue to why no-code will eventually overtake low-code. From 1980 to 2010 enterprise development times steadily declined as programming techniques and resources helped developers turn out software faster and faster. From 2010 to the present though, enterprise development times have trended in the opposite direction, even with the boost provided by low-code platforms.

Why is it taking longer to build new enterprise solutions? Part of the problem is the need to integrate new software with an increasing amount of legacy code and to maintain that legacy code. Low code platforms have helped relieve some of that pressure by proving applications that are largely composed of "black box" building blocks that require less maintenance and testing. However, low code software still includes custom code and that code has to be tested and possibly modified whenever changes are made to the application or to the programming language used in the application. 

No-code on the other hand is entirely (except in very special cases) "black box" which means that maintenance normally just consists of changing a few components or modifying the options associated with some elements in the software. in the long run that means that using no-code will be faster, more efficient, and require less effort than using low-code.

But what about very complex applications that can't be handled without coding? No-code supporters will argue that 10 or even 5 years ago no-code platforms couldn't produce software nearly as sophisticated as they can today - and it's only a matter of time until they develop to the point where you can build even the most complicated pieces of software.

So there's where the debate stands at the moment - what's your opinion?

Sunday, March 21, 2021

Get Better Performance from Your Bubble App

Echo Lake Tech has a neat tip on how to speed up user response times for an app created on Bubble.io. The idea involves replacing pages that a user moves between frequently with "group" elements.

Every time you switch to a different page in your app you're accessing Bubble's infrastructure which slows things down slightly. If the user has to switch between certain pages often enough that slight delay can add up, slowing down the user's response time. Creating two or more "virtual pages" on a single page will avoid that interaction and help avoid any slowdown.

Go to https://echolaketech.com/2020/11/02/one-strategy-to-improve-your-bubble-io-no-code-web-apps-performance/ for a full explanation and video of how to implement "group pages". You most likely don't need to do this for all your pages, but it could be worth a look in order to make your app as efficient as possible.

Saturday, March 20, 2021

Amazon Honeycode

In June 2020 Amazon introduced its no-code product, Honeycode. Recently we took another look at Honeycode and I would  recommend waiting for Amazon to add more features before spending much time on it. At this point you still have to use a work-around in order to simulate checkbox and radio button inputs. 

Anything associated with Amazon commands some attention, but Honeycode continues to feel like an unfinished product. Hopefully, the platform will get some much needed upgrades in the near future.