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.

AppSheet Automation now Available to Everyone

The pandemic and the need to work remotely has forced a lot of companies to automate more of the tasks that were being done manually. And the need to develop apps to create those automations has convinced more and more no-code platforms to add the ability to build those automated workflows. The latest to join the trend is AppSheet, which just made their enterprise level automation product available to all users.

Why should you care about all this? A recent survey by McKinsey determined that at least a third of business activities could be automated in about 60% of occupations. Automating those processes produces a clearly defined set of steps to accomplish the tasks involved, clarifies who is responsible for carrying out the tasks in each step of the process, and provides for automatic notifications or 3rd party requests to be sent at any stage in the workflow. That in turn produces a leaner, faster, more manageable way to carry out the various processes like payroll, accounts payable, inventory control and marketing that every organization has to deal with.

So, how do you use AppSheet Automation to actually create automated workflows? The concept is pretty straight forward. First you configure a "bot" that connects events with an associated process. For example, if someone marks a task in the process as completed, the bot can change the status of that process and send an email to a manager notifying them of the change. When you select to create a bot AppSheet will offer you a choice of "pre-defined" bots (based on your app) that are designed to carry out specific types of processes. You can either choose one of these "pre-built" bots or select to create a custom bot.

If you choose to create a new bot, then you begin creating the workflow for that bot by choosing an event (such as inputting a start date for a job), then adding a step that includes the tasks that need to be carried out once a start date is entered. The step may include branching conditions (such as whether or not the job has a high priority) along with the tasks involved in completing that step (such as sending an email to the person responsible for completing the job).

Once you've added the step(s) necessary to complete the workflow, that process will run automatically whenever the event you selected takes place. Following the same procedure you can create as many automated workflows for your app as necessary.

Note: The system allows you to create four types of task:

• Sending notifications such as texts or emails.
• Making a data change such as adding, modifying or deleting a record.
• Using a webhook to connect to an outside third party service.
• Creating a template-based Google Docs file.

Zoho Launches New Workflow Automation Product

Workflow automation (automating manual business processes) is getting a great deal of attention lately and Zoho is joining the list of platforms offering an automation product. Zoho just introduced "Qntrl" (pronounced "control") aimed at mid-size companies that are looking to upgrade their workflows.

Like their other visual programming offerings, Qntrl will allow the user to drag and drop components onto a screen in order to build an automated workflow. Some additional help may be needed to connect that workflow to other background systems, but anyone with minimal technical expertise can use Qntrl. You simply choose a component to add the workflow and then select which actions are to take place at that point in the process.

Watch for more about Qntrl in the near future ...

Make Your No-Code App More App-ealing

Apologies for the title, but the appearance of your app can definitely make a  difference in how people respond to it. Having been a programmer years ago, working on business apps, I still tend to feel like I've done my job when the software is well-designed and works the way it was intended to work. However, it takes more than that these days - the app should also provide a great user experience, both functionally and visually.

There are a number of factors that go into making your app visually appealing:

• Don't settle for default shapes and colors. Do some exploring and see how others have used color combinations effectively in their app or website. Plus there are websites that can help you figure out which color combinations work best together. Changing the default shape of elements in your app can also help to make your screen layouts more interesting. For example, using larger or unusual shapes for some elements can help draw attention to them (which can help guide the user).
• Images are another important factor in making a webpage or app screen stand out. There are a number of websites (like Unsplash or Pexels) where you can find a variety of free images to use in your app. It also helps if you learn a few photo editing skills. You don't have to master Photoshop, just learning to make use of some basic editing techniques can make your images more interesting.
• Keep your screen layouts as simple and uncluttered as possible. Nothing turns users off like a messy and confusing screen and complicated screens also take longer to load. And don't try to pack too much into one screen - people absorb information best when it's presented in small amounts and the same principle applies for data presented on an app screen.
• Make navigation easy with a simple, straight-forward menu. Users hate to wind up at some screen on your app with no idea how to get back to where they started aside from trying to back up screen by screen. Or get to your landing page and not see a way to go to the part of the app they want to use.
• Finally, if your app runs on both the web and mobile devices, test your design on each type of device. A great looking web app can be anything but that when you look at it on a tablet or phone.