Full tour of App Maker’s interface

PART 4 OF 4 APP MAKER MINI ARTICLES

In article #3, I reviewed how to build a basic app quickly, and with no code on G Suite’s App Maker. In this article I will show you a bit more of the interface used for building apps.

First step is visiting http://appmaker.google.com after my G Suite admin has already turned App Maker on and enabled a default Cloud SQL server, so when I visit that link, App Maker is activated for me within G Suite.

Upon logging in with your G Suite account, one has the option to create a blank app or leverage any of the templates. If you select “blank app” it takes you to the typical App Maker canvas where all the magic happens called “the data model.”

Let’s start the tour from the top left. First you give your app a name by entering it into the text box above and all changes are autosaved.

The 3 lined hamburger menu (left corner next to the name of your app) allows you to do things like “open” or create a project, as well as “delete” your project.

On the immediate left sidebar there are 3 headers “data, pages, and scripts” if you hover over any of them, a “+” sign appears in order to create a new record.

In this case let’s click the plus sign on “DATA”, where you can create your fields, that will automatically sync with a Cloud SQL instance automatically assigned to your app (a product of having the G Suite admin setup a default Cloud SQL).

Each table created in the database is called a data model. You can optionally import your data columns from a Google spreadsheet.

The next section called “PAGES” is where you will design how users will interact with the app.

You will create a different page for every user journey. For example you may want to create 3 pages for your app because you want one page for end users to enter items into a form, another one for admins so they can take action on user requests, and a third page that both admins and end users can see a summary of all the requests made by the end users.

Note, if you will use the same widgets or design for multiple pages — like let’s say you want to have the same banner across all pages, then you could choose to make a “page fragment.” This saves a page’s design with the banner design as a template that can later be dragged into data model editor as a custom widget to save you time in having to recreate that design over and over again.

Then there are “pop-ups” which are dialogue boxes displaying important information you would like to inform users such as showing a transaction is in progress or confirming a request was deleted.

An app is basically a series of “widgets” put together on each page by dragging and dropping them onto the page’s data model editor.

You can find widgets by clicking the “4 squared icon” (below the name of the app) and scrolling or typing in its search box for a particular widget.

Widgets bring in specific functionality to your app such as creating a form that collects data from users, and you can “bind” these entries to your Cloud SQL database.

Just to name a few main widgets, you can add star ratings, tables, buttons, multi-picklists, a user directory, a Drive file picker, or make your own custom widget.

One can make app interfaces beautiful by using the images widget, html box, headers, and can even import icons from the material design gallery by giving it the name it has in the gallery and selecting its “style” to be an icon. For those newer to Material design, it is a library of responsive icons and cards that are becoming the norm for standardizing website and application design.

Out of the box, one can change the color or the style of icons by selecting a widget and then choosing an option from the “styles drop-down,” which is located to the right of the widgets library icon.

Here I provided an exampled where I inserted a “label” widget and converted it into a star icon.

This is possible because of App Maker’s seamless connection to the material design library. As long as I select the option “icon” from the style editor’s drop down and then change its “name” to “Star” in the property editor to the right, it automatically turns my label into a star icon.

The drop-down next to the style editor allows one to change the data model editor’s canvas size in case one wishes to build an app for a very specific device screen (ex: small mobile). Otherwise the default “customize” is recommended.

The button next to the device display, creates a grid on your data model editor canvas for more precise alignment during the UI build.

The undo and redo buttons on the top right, help do just that, or you can use keyboard shortcuts like “CTRL + Z” to undo.

The last and third section of the sidebar on the left is called “SCRIPTS” which allows users comfortable with using code to add customizations such as sending email notifications via a client or server script.

Heres a link to scripting in App Maker and scripting with Apps Script (which is its underlying platform similar to JavaScript and can connect to an array of Google APIs ex: Google Calendar or Drive).

Moving on to the sidebar on the right is the “Property Editor.”

When you finally drag and drop widgets on a page , and you have a widget selected, this property editor sidebar lets you bind your data to the widget.

At the bottom of the editor is a section called “security” which allows you to configure “page-level” permissions in case you would like admins of the app to have access to different pages than end users for example.

You can also create custom role permissions. This article on security best practices is also very helpful to plan how you would like to setup your settings (ex: who has access to the database’s data in Cloud SQL, access to the actual app, access to a specific page, etc).

If comfortable, one can optionally use custom CSS and HTML if desired, but this is not required by clicking the “art palette” icon in the “Property Editor” which has code completion for easy styling.

And finally, at the top of the “Property Editor” sidebar there are a few buttons.

From right to left is the “Preview” button which lets you see how your final app will look like without publishing it.

TIP: I find it helpful to preview my app for every page I create. When in preview mode, it also has a logs section at the bottom which allows you to see if there are any errors happening if you wrote a script to automate events.

The next button is to “Publish” your app when you are ready to make it available to users. You can “deploy” multiple instances of your app with completely different data for different departments or clone the same exact data and “name” each version “test sandbox version” or “production version” for example.

If you click the drop-down icon by each deployment’s name, it offers more editing options, however you cannot change the name of your deployment once published, you would need to launch a new deployment to do so.

In this case I want the link for the 3rd version of my app called “Urban planting 3.” By selecting that deployed version, I can copy the URL listed and then paste that link to share it in an email, in a chat, or embed into a Google Site for people to visit or any existing project site setup for your department or organization.

And there you have it, this completes our in-depth tour of App Maker’s UI.

To get started with your app, work with your G Suite admin and try out this codelab. Then think of a process that presently lives in a spreadsheet and plan how to map it out into App Maker.