No-Code Websites and Mobile Apps

Of course apps aren't the only thing users can create without knowing how to code. There are a number of popular website hosting platforms like Squarespace, Shopify and Wix that allow you to build a website without doing any coding. You can create an attractive, responsive and feature-rich website with any of them, but your're limited in how you can interact with your users.

With a website, your users have to remember your URL and navigate to it using a web browser. How can you increase your engagement with them? The simplest way is to build a mobile app from your website. Mobile apps have several advantages over websites – they're right there on the user's home page where one click opens up the app, plus you can send them push notifications occasionally to keep them informed about your business.

You can't create a mobile app from your website directly, but there are a number of no-code platforms like Appy Pie or PandaSuite that can do the job for you. They can convert your website into an Android and iOS app which includes features like push notifications, coupons, and the ability to receive in-app payments.

Even if you don't have an app you want to create, no-code platforms can help you to connect with your audience and extend your reach beyond your website. That's another good reason to learn more about the “no-code movement”.

Coming Soon - A New No-Code Book

Coming soon on Amazon - a new guide to no-code app development: Learn “No Code” App Building (Be Your Own Programmer). 

Types of No-Code Applications

There's a wide range of applications that can be built using no-code platforms, but they all fall into the following categories: web apps, mobile web apps, native apps, hybrid apps, and progressive web apps. So, how do you decide which type of app to build? It depends primarily on your target audience and the features you need. In order to give you an idea of how the different categories compare, here a few basic facts about each type of app:

Web Apps

• Web apps are intended primarily for use on desktop computers. They're normally constructed using a combination of HTML, HTML5, CSS, and JavaScript elements and often work in conjunction with an online database.

• The app (and its data) are stored on a web server so you need a browser and an active network connection to access the application. To provide offline access you have to use an SQL-based database API to store data locally and an offline application HTTP cache to make the application available even when the user isn't online. 

• Web apps can be accessed from a mobile device just by directing the device's browser to the app's URL. How the app appears on a particular device and operating system (Android or iOS) depends on how "responsive" the app is - that is, whether it automatically adjusts for different screen sizes and layouts. In some cases a website may provide two versions of a web app - one for desktop viewing and one specially designed for viewing on a mobile device.

• You don't need to worry about whether or not you have the latest version of a web app, since they reside on a web server and everyone accessing the application is automatically using the latest (and only) version of the program.

• If you access a web app from a mobile device, the app isn't going to load and operate as quickly and efficiently as a true mobile version that's installed directly on the device. 

• Web apps don't have to be approved by an app store, so you can launch them faster than mobile apps. However, your app may be harder for potential customers to find since it's not on display in a store.

Native Mobile Apps

• Native apps are built for a specific operating system (Android, iOS or Windows) and are optimized to run as efficiently as possible on that operating system. No-code platforms such as AppyPie, Adalo, GoodBarber, Thunkable, and others let you build mobile apps for Android or Apple and get them into Apple App Store or Google Play Store.

• Because they're installed directly from an app store onto a particular mobile device, mobile apps can access any of that device's built-in functions: GPS, accelerometer, camera, etc.).

• Native apps can work offline since the app lives on the mobile device and doesn't need to connect to a network in order to function.

• Users can feel secure using native apps since the apps have to be checked and approved by the Apple or Google app store before they're made available for download. 

• There is a cost involved in doing business through the app stores.  Google Play Store has a one-time charge of $25 to upload your apps to the store, and they take 30% of whatever price a customer pays for your app as a commission. To use the Apple App Store you have to pay a $99 fee each year, and Apple also takes a commission of 30% of the price the customer pays to buy your app. Note: Apple recently announced that they're cutting their commission rate to 15% for small developers.

Hybrid Apps

• Hybrid apps are basically web apps enclosed in a wrapper that allows them to be installed on mobile devices through an app store, the same as native apps. You can create hybrid mobile apps on no-code and low-code platforms like Appery, AppyPie, and Mendix. 

• Unlike native apps, hybrid apps can run on both Android and Apple operating systems, so you only need to create one version that can be uploaded into both Android and Apple stores.

• Since hybrid apps are actually web apps they generally run slightly slower on mobile devices than native apps.

• While there are a few no-code/low-code platforms that allow you to build hybrid apps, Progressive Web Apps (PWAs) are the becoming the alternative to native mobile apps on many no-code platforms.

Progressive Web Apps

• PWAs, like web apps, are built using elements like HTML, CSS, and JavaScript. More and more no-code development platforms are providing users with the ability to create PWAs.

• Progressive web apps look like native apps but, like regular web applications, they live on web servers rather than being installed directly on a mobile device. PWAs can be installed on your device's home screen by linking the app's icon to its web address.

• Again, like regular web apps, PWAs require a network connection in order to reach the website where they're stored. However, unlike regular web apps, PWAs can operate offline by using a technology called "Service Workers". Service Workers caches data from the website, saves it on your device and displays an icon marking the location where the data is stored.

• Although PWAs share many of the characteristics of a native app, they can only make use of those functions on the mobile device that are supported by web browsers (such as video or audio recording).

Push Notifications: Using Them in Your No-Code App

To be clear, push notifications are messages that pop up on a mobile device. They look like SMS text messages and mobile alerts, but they only go out to users who have installed your app. Push notifications differ from in-app messages in that the user sees push notifications even if your app isn't open on their device (they typically pop up on the user's lock screen), while users only see in-app messages once they open your app.

Why use them in your app? For a couple of reasons. If you're a developer looking to sell your apps, push notifications give you a chance to communicate directly with your customers. Let them know about special features in your app, upcoming events, or new products and thank them for choosing your app. Or if you're part of a development team or you're using the app in a company setting and you need to send and receive messages from other team members or other people in the company, push notifications can handle that too. 

So, what do the notifications sent to customers or other users look like? Web push notifications normally include these elements:

• Title (such as your company or app name).
• Message (brief text).
• An icon, emoji, or image (often used to supplement the message).
• A Call To Action (such as a clickable link or button).

For example, the title might be "Mastering No-Code", with a message "Check out our new universal mobile app template", an image of a cell phone screen with an app running, and a CTA consisting of a link to this blog. 

How you create and manage push notifications depends on the platform you're using and the process can be fairly complicated. In most cases, implementing push notifications is going to require using a plug-in (or "add-on") specifically designed for the job. For example, if you built your app on Bubble you can use the "Firebase Cloud Messaging" plug-in (which costs $12 per application). Most other no-code platforms will have one or more similar plug-ins available and a few may even have push notifications integrated into the platform.

Caspio's Free Patient Portal Template

If you have a need for a comprehensive online patient management app, Caspio has a no-code template that could be your answer. The free template includes a public view, a patient view, and a physician view, and a customizable database that can be stored on Caspio's platform, which is HIPAA (Health Insurance Portability and Accountability Act) compliant. 

Features include:

• New patients can fill out a medical history form online.
• Patients are able to view a list of their prior visits to the facility, along with the results of that visit.
• Patients are able to view messages sent by their doctor or the medical staff.
• Patients are also able to update their profile information at any time.
• Physicians and staff can view a list of the patients (active or inactive) by doctor, including their medical status, insurance carrier and policy number,  and email address, along with details of their medical history, previous visits, and vital signs taken during each visit.
• Physicians and staff members can leave messages for patients, regarding scheduled appointments, medication, advice on treatment, or other information relating to patient care. 

Caspio even suggests some enhancements you could add to the template,  such as email alerts to patients (regarding test results, changes in medicine, etc.) and an appointment calendar that would allow patients to sign up for an appointment on their own. 

One other thing I like about this template is its flexibility. With a few changes you could make this work for a number of situations where you have visitors, members, and administrators. For example, if you need an app to manage a volunteer organization, you could modify the template to handle visitors who might be interested in volunteering, actual volunteers, and supervisors or project managers. Messages could be sent to specific volunteers regarding the projects they're working on, and you could keep a history of which projects each volunteer has worked on and how many hours each one has contributed.

If you're interested, there's a six part tutorial on building the template available on YouTube:

https://www.youtube.com/results?search_query=caspio+patient+portal 

Building a Simple Mobile App on Glide

Glide (www.glideapps.com) specializes in providing users with a quick and easy way to turn their Google Sheets spreadsheet into a mobile app. I should mention that Glide has now added the option to use their internal data tables instead of Sheets, but I decided to go ahead and build my app with Google Sheets as my data source. The app itself is a basic reminder application, to keep track of appointments, projects, articles, or anything that I might want to explore further. Creating the app went like this: 

• I went to my Google Sheets account, created a blank spreadsheet, and added six fields: Keywords, date added, target date, description, location/source, and image. The "keywords" field contains words that relate to specific types of items in the database: blog posts, no-code platforms and tools, sports, space exploration, medical technology, volunteer projects, animal rescue, and so on. The "date added" is self-explanatory, "target date" refers to something like a deadline date or the date of an appointment, "location/source" could be a URL, business address, or the name of a contact, and the "image" field could be a picture of a product, a map, or a screenshot of an app.
• Once the spreadsheet was set up, I entered several sample records in order to have some data for Glide to work with: 
  
  
  
• Next, I signed up for a free account on Glide. A free account allows you to create mobile apps, but you're limited to 500 rows of data and 1,000 sheet updates (changes to your Google Sheets spreadsheet), plus your app is public (open to everyone).
• After I signed up the "new app" screen displayed (you can either click the "+" sign to start from scratch or you can choose to start from a template): 
  
  
  
• I clicked the plus sign, which brought up the option to use Google Sheets as my data source or use Glide's new internal tables: 

• Next, I selected "Google Sheets" as my data source, clicked "Continue", and chose "ReminderDB" as the spreadsheet I wanted to use. Glide connected to my spreadsheet, formatted my app to fit the sample data, and displayed the  result on the design canvas: 
  
  
  
• Clicking on any of the 3 reminders on this screen (the "List" screen), automatically displayed the "Details" screen for that reminder: 
  
  
  
• Glide added basic navigation automatically (note the back arrow on the details screen), along with a search box. And by checking a couple of boxes you can allow users to edit and/or delete entries. Clicking the pencil icon on the details screen brings up the "edit" screen, which also has a button that lets you delete the item being edited: 
  
  
  
• In addition, there were some other options that could be added easily, such as grouping the list items by a particular data field. 
• You can also add various "actions" to the app, such as composing an email, opening a hyperlink, playing a sound, and so on.

Overall, it was easy to build a simple app with Glide, and there were a number of other things I could have done with it. However, I stopped at this point for two reasons: 

•  One, the responsiveness of the app isn't great at times (which is understandable since it's constantly accessing an outside source in Google Sheets).
• Two, using Glide's internal tables would avoid the responsiveness problem, but if you have a considerable amount of existing data there's no straight-forward way (at least that I could find) to import that data into Glide's tables.

I did like working with Glide though, and once they address the import problem it would be one of my top choices for building mobile apps.

How to Market Your App in the App Stores

Once you've placed your new application in the Google Play Store or the Apple App Store, it's time to concentrate on developing your ASO (App Store Optimization) plan. The basic purpose of your ASO is simple - draw as many buyers as possible to your app page. OK, but how do you accomplish that? 

The answer involves a number of factors, including:

• Keywords. Google estimates that 40 percent of apps are discovered through app store searches - which tells you how important it is to make use of the particular keywords that turn up in searches for your type of app. 

• App descriptions (long & short). Keywords also play a part here (even though the Apple store doesn't take them into account in establishing keyword ratings) but the description for your app has to be more than keywords, it has to catch the attention of prospective buyers. Your app needs to offer to solve a problem for them, entertain them, or inform them in some way, and the description is where you need to convince buyers that your app can do that better than your competitors. You're also limited in the number of characters in your description that the potential customer will see on your page, so you need to be concise and make every word count.

Items to include in your description: 

• The purpose of your app.
• A list of the different functions available in your app.
• The types of users who could benefit from using your app.
• Screen shots/Videos.
• Note: Do not include user reviews in your description in the Apple store - they're not allowed.

• App Icon - You may not be aware of it but your app's icon can also influence potential buyers. An icon that's simple and projects the theme of your app helps reinforce the message you're presenting to anyone who lands on your app page. An effective icon can be like the road signs in Europe and elsewhere that get their message across with just a picture.

• Sales (downloads). A large number of downloads shows your app is popular and reassures viewers looking at your page that a good many other people were impressed enough to try it. 

• Reviews. Customer reviews and ratings can have a major effect on how well your app sells - poor reviews can kill your app in a hurry. There are a number of ways to go about asking for reviews:
• Ask readers while they're actually using your app (there are plugins that make it dead simple to do that).
• Offer to activate an extra feature in the app to any reader who leaves a review.
• Take the time to respond to both positive and negative reviews - let your readers know that you care about their opinions.

• Additional resources. Maintain contact with your followers on social media and continue to request reviews from websites and YouTube channels that specialize in discussing new apps.

Keywords are vitally important to getting your app noticed - so how do you include them in your ASO planning?  To begin with, the title of your app should contain the word or phrase most commonly used in searches for apps like yours, which means you need to do a little research to identify that word or phrase. The easiest way to do that is to use Google Keyword Planner (you'll need a Google Adwords account).  Go to the Keyword Planner, enter the keywords you've brainstormed, and check to see which are the most popular. You can also go to websites like Sensor Tower or App Annie, enter the names of some of your competitor's apps, then look to see which keywords they're using to draw traffic to their pages. 

Feedback from your customers can also be key to the success of your app in the Play Store or App Store. Let customers tell you what they like or don't like about the program, whether or not they had problems using it, and what they would like to see added to it. Years ago I had a shareware program on the market and customer comments allowed me to short-circuit a potential problem with a program bug and also led me to add a new feature that greatly improved the application. Listening to your customers not only avoids bad reviews, it provides you with new ideas for your app. 

In addition, along with your contact information, be sure to ask politely for users to leave a positive review if they like the app. Don't be pushy about it, just let them know how much you would appreciate their comments or rating.

That covers the main points about marketing your app on the marketplace. Be sure to spend some time planning your marketing approach (keywords, app description, etc.) before you put your application in the Apple or Android store - and be ready to make changes at any time, depending on how sales are trending.

Note: Look at How to Find Great ASO Keywords for Your App by Kimberly de Silva for more tips on how to find the best keywords for your app.