I have been using GAS (google apps script) for several years to automate tasks. In fact, those of you who follow the blog will know different plugins I have published for spreadsheets: CoRubrics, CLASS-MON and ImExClass. But, until now, I had rarely used the GAS option to create web applications. Some limitations that they have, had made me not dive much into it.
In this first article, I will only present what these web apps are and what they can be useful for. In a second part, we will see how to create one.
Increasingly, teachers are accustomed to using web applications. They connect to an address and intuitively use the application there: EDPuzzle, GENIALLY, Kahoot, Google docs or Gmail itself, and a very long etcetera. On the other hand, many teachers find it difficult to use a spreadsheet add-on. Opening the spreadsheet, configuring it and using the menu is much less intuitive.
Simple web applications can be made with the same GAS, but, as I said, they have some important limitations. Some can be circumvented. Others have to be assumed. The most important one, without going into programming, is that they are limited to 30 concurrent users. This limitation can be important if you create a web app to be used by students. If it is for school management, either the faculty is very large, or it will be difficult to reach this figure.
But what can we do with web apps? In fact, we can do the same as with any script we create in a spreadsheet or document. The only thing that changes is the environment. Instead of using them from the spreadsheet or document, they are used from a web page. Many of the web apps that come to mind can be made with Google forms and a script to process the data, but the forms have a very rigid format: one question under the other and the results go into a spreadsheet.
In recent months, I have made a couple of web apps. The first one, to collect data. More than 50, to be precise. A lot only Yes or No. With Google forms, it would be very long. With web app, you put the fields side by side, with buttons for categories, making it much more presentable.
If you look at the image, 13 data are requested, from one of the 6 categories. If we do this with a form, it would take up several screens of this category alone.
A second application I have made is to access different spreadsheets. Each teacher has a spreadsheet to store the attendance of the students. Through a web app, any teacher can record attendance on a colleague’s spreadsheet without even having read access. With the web app you choose group, day and time, and the web app accesses the corresponding sheet and saves the attendance (ok, I admit that I have not tried too hard, and I have used the same design of the header 😉).
Some time ago I had already made another web app. Specifically, to show families the attendance data of their children. In a spreadsheet were all the data, and the web app, from the user accessing, shows only the data of the corresponding student.
Basically, what these web apps do is collect and display data from spreadsheets, filtering by the user accessing them. But, as I said, they can also perform many other actions. Send emails, create forms, create documents, etc. In fact, if it weren’t for this limitation of 30 concurrent users, an add-on like CoRubrics would be much more intuitive if it were made with a web app. The interface, instead of being the spreadsheet, would be a web page, where the rubric, the students and the teachers would be indicated. The chance of the teacher using it “messing up” something, modifying formulas, deleting rows, etc., would be much lower.