In our last post we hooked all of our data tables together in order to create a cohesive application for our GTA HVAC service crew.
Thinking about and structuring our data effectively is extremely important. It lays the foundation for the eventual roll out of an AppSheet application that will help us streamline our operations.
Likely more important to the actual users of the application is the look, feel and flow of the application. And so we come now to creating our app’s user interface.
All of the user interface tweaks and adjustments are made from the UX menu in AppSheet. There are 3 types of views: primary, menu and reference.
Primary views are the views most often used within the app. An icon for each is located on the bottom bar of the phone or tablet screen. You can see an example in the emulator in the bottom right corner of the picture above.
Menu views are located in the drop down menu which is always accessible from the top left hand corner of the screen. Views that are used occasionally are best created as menu views.
Finally, reference views are usually system created although it is possible to create your own. They are views within views. So for example, if you have a customer view and a work order view, could have a reference view of all service tickets pertinent to a specific customer from within your work order view.
Within the three views are eight view types: Deck, Table, Gallery, Detail, Map, Chart, Form and Dashboard. The AppSheet website has great documentation explaining use cases for each view type.
Now that we know the essentials, we can start to think about how we’d like our GTA HVAC Services work order app to look.
If we start from the beginning of the work order process, we should consider the dispatcher/coordinator position first. Ideally that person should be able to see everything. All customers, parts, technicians, work orders and purchase orders. One of the best views for a comprehensive view of everything is the Dashboard view type.
Let’s try to build a Dashboard view for our dispatcher. We’ll assume our dispatcher works from a desktop computer and will access the view through a browser rather than a phone/tablet app. She’ll have plenty of screen real estate to be able to view everything.
We’ll want to make this a primary view as our dispatcher will be using the view constantly.
The first step will be to click the Add New View icon in the UX menu of AppSheet. See the icon circled in yellow below.
Clicking the Add New View icon will open a New View dropdown with a whack of configuration options. You can see what it looks like in the images below. We’ll name the view GTA HVAC Service Dashboard.
Initially you’ll see a “For this data” pull down immediately below the View name. When you click the dashboard view type, this menu will disappear in keeping with the fact the Dashboard view can pull in multiple pieces of data from your tables.
The sizing and orientation of each view within the dashboard can be adjusted within the View Options in the UX menu. One great feature is the ability for the end user to move the views around within their browser. Gives a bit of customization to those who might not have access to the back end of the app.
So this is great, one of the most useful views for sure.
But what about the technicians? It wouldn’t be beneficial for them to try to see a dashboard view on a mobile phone or tablet. It would be distracting if anything.
In my opinion one of the best views for a field tech is the Table View. So let’s set up a view for our technicians to see and fill out work orders in Table View. Furthermore, let’s split up the work orders by the Status field with options Open and Closed.
So let’s look at the data first. We have a variety of tables but GTA HVAC Services wants the technicians to focus on customer facing and billable work. We should keep the technician interface as uncluttered and streamlined as possible. A technician should be able to see open jobs to be completed, previously completed jobs for reference and a parts list.
So how can we accomplish this?
If you recall in our Work Orders table, we have a Status column with the Enum values Open and Closed. There is a nice feature called Slices that allows you to create slices of tables to filter down info.
Looking at the image above, you see we can make a slice of Work order table rows that have the Status of Open based on a row filter condition we incorporate. We can do the same with Closed.
Once we have these Slices in place, we can then create interfaces that show open and closed work orders instead of all. Based on what we know about views, the technicians should be able to see Open and Closed views from the bottom navigation bar. But should not be able to see the views the dispatcher can.
So first we’ll add the Open and Closed slices as primary views.
Looking at the image above, you can see that you’ll give the view a name which is what the tech will see on his or her navigation bar. Pick the Open slice for your data source and the Table view type is a nice tidy way to display the work order rows. Picking the left position will show the Open tab on the left side of the navigation bar. We followed the same process with the Closed slice with the exception of picking the right position.
We have all of these views now. But we want our dispatcher to see the overall dashboard and some views the technicians don’t need to see.
The best way to determine which user sees what view is to use the Show if field of the view. This allows you to show the view based on an if statement that gives a yes/no value. An easy way to accomplish our goal is to show view based on login email. Each technician will have a login email and the dispatcher will have her own as well. So, for instance, you could only show the Dashboard view to the dispatcher by showing if the login email is the dispatcher’s. See the image below for an example.
If you look at the image on the right, you can see that the bottom navigation bar is tailored to a technician on a mobile phone now, with access to the Open and Closed tickets.
You’ve learned how to create a basic AppSheet interface now. The options you have to customize are far beyond what we’ve covered in this post but this gives you an idea specific to building a work order application.
In the final two posts of this series, we’ll cover some of the small details like filtering tickets by user and rolling out the application. The final post will cover how to create a workflow that automatically sends a completed work order to a customer.