|
FEATURE
MyICPL: How to Create and Deploy Progressive Web Apps
by Alyssa Hanson
| [P]rogressive web apps are browser-based, have a more familiar syntax, and don’t require special software to run or test them. |
When smartphones were first introduced and people were looking to add functionality to their devices, native apps were the first to fill this need. Built specifically for the phone’s OS—Apple or Android, for example—this became the typical route for app development. Building a feature-rich native app could be time-consuming to do yourself or potentially expensive for someone else to build, since they require knowledge of a programming language specific to an OS.
Alternatively, progressive web apps take a different approach. Instead of being tied to an OS, they are browser-based and can work on any OS. The idea was introduced in 2015 by Chrome developers, and progressive web apps have slowly been growing in popularity.
Our Native App
When Iowa City Public Library (ICPL) first built MyICPL, it was a native app. We’d been getting an increasing number of requests from people who were interested in a library app. Todd, our ILS administrator, began exploring options. At this point, progressive web apps were still in the conceptual phase, and there were not a lot of examples to work from. So our first app was developed as two native apps, one for Apple and one for Android. After some initial testing, we began marketing the app at the end of 2016.
For a while, it was great. But as smartphone software was updated, we ran into issues. We had our first major bug midway through 2017 when iOS users were not able to log in to their account. After resolving this issue, we had another issue in the beginning of 2018 when neither Android nor iOS users could access their accounts. We were starting to see how the fast development pace and wide range of smartphone OSs were difficult to keep up with.
Another challenge we found was keeping up with legacy APIs used by the app. As we began redesigning our web presence, the APIs for our blog and calendars changed. With the amount of work involved in updating the two apps, getting those changes approved by the app stores and knowing that not everyone updates their apps promptly, we realized we were still going to have to support the legacy APIs for a while. So, we decided it would be simpler to forgo updating the apps and continue supporting the legacy APIs, since it was more in our control to manipulate the APIs than it was to update the apps and hope our users change to the newest version.
Then we reached 2020, when we started getting more and more reports that the app had stopped working altogether for those with newer phones. It was no longer compatible with the newest OS upgrades, and it was going to take a large amount of work to get the app functioning again for this growing group of people with the latest phone models.
A New Approach
As we debated our options, we realized we were not happy with the way the development cycle had been going. It was a lot of work that was left up to Todd to maintain. We knew we wanted to spread out the work among our three developers and wondered about how best to do that. This is when we came back to the idea of a progressive web app, a technology that had become more established. More and more companies were starting to develop their own progressive web apps. Twitter was one of the biggest companies to do so, and it was working well.
A progressive web app looked promising and could potentially solve some of the key issues that we’d been having over the years with our native app. With a progressive web app, we’d only have one codebase to update and wouldn’t have to develop separate codebases for different OSs. It would allow us to bypass the app stores, which were often a barrier for us to quickly push updates, either for bug fixes or new features. We’d also be able to more easily split up the work, since progressive web apps are browser-based, have a more familiar syntax, and don’t require special software to run or test them.
Since we had many people who were not able to access the old app at all, our plan was to get a working version as quickly as possible, preparing to cut nonessential features in order to move fast. We decided to divide the work among the three of us on our development team. While we all worked on features, our main roles were divvied up among Todd, as the project lead; Brent for the app’s hosting setup; and me for design and usability.
We started with the Create React App framework originally developed by Facebook. It was built with the Java-Script React library, which none of us had worked with before. We found online tutorials that could help us learn. As it was similar to other web development work we’d done, we were able to use our existing skills and put together a working version within a few months. During this process, we evaluated the features of our old app and prioritized the essential features to port over in this first version of our progressive web app. We wanted to see if this would be a viable option before spending too much time redeveloping the app.
The main reason for having an app was so that people could manage their library account. We knew that the current functions of showing the barcode, renewing items, suspending holds, and canceling holds were important to include.
After we got the essentials running, some of the secondary functions we included were our hours and contact information, a search box that would direct users to search our catalog, and the ability to pull in events and blog posts, the latter of which could finally use the new APIs.
There were some features that, at the time, were difficult to add and got put on hold. They required access to tools that browsers historically have not had easy access to, such as the camera for scanning and searching barcodes—a function our old app could do—or for pushing notifications.
Testing the App
During our development process, we each had our own local versions of the app that we were able to run locally in our browser to test. We also set up individual instances on Microsoft Azure (our hosting service) for each of us to push our work in progress so we could test how it behaved on the server.
Once we had a solid working version, we started having others test it. As more people contacted us about their app not working, we had begun collecting contact information for those interested in being the first to know when we had a new app available, and they joined staff as our early testers.
As we were testing the app, we found there were features we needed in order to troubleshoot better when certain functions weren’t behaving the way we expected. For instance, we learned it wasn’t always easy to tell if the app was using the current code build. To solve this problem, we implemented a versioning system in which each new build would have an incremented build number, which we could compare to the device having issues to see if it had updated.
This was useful because, in theory, pushing updates meant everyone would receive those updates right away; in practice, they often weren’t pulled in until after the app was closed and reopened. It was still usually a smaller amount of time than with native apps, which may go months or more without an update.
Another issue we encountered was that the account information wouldn’t always update when you’d pull down to refresh the page. Because progressive web apps are meant to run on cached data, we needed to specifically build in a refresh script to update someone’s account information as well as the other data in the app. For other general issues in which something may have gone wrong with the cached data, we implemented a Delete All data button that would clear everything and start the app fresh.
During our testing phase, we received mostly positive reviews, with just a few bugs to work out. The people testing it were mostly just thankful that they had a working app again. So, after revamping our how-to information, we released the new MyICPL app to the rest of our community.
Helping Users Get Set Up
In our how-to information, we made sure to emphasize that the new app isn’t found in an app store, but is instead installed by visiting its web address. One of the biggest lessons we learned was that we needed to alter how we spoke about it to help make the connection that it was a different kind of app. Instead of saying, “Have you downloaded/installed our app?” we switched to, “Have you bookmarked our app?” to better match the process.
Along with written instructions, we also made videos to walk people through the process. While the development work was able to be simplified into one app, we needed an Apple and Android version of the installation video since the process looks slightly different for each. For Apple users, progressive web apps are officially only available to be bookmarked in Safari, although there is a workaround to use Chrome for those who don’t mind a more complicated setup process. For users of Android and other similar OSs, they can be bookmarked with almost any browser, although Chrome makes it the most obvious.
To aid people with the bookmarking process, everyone on our help desk has been trained in how to bookmark the app on both Apple and Android devices. That way, they can walk through it with people who come to the desk, either when they sign up for a library card or during other interactions.
Later Stages
After the release of our progressive web app, we were soon able to turn back to other projects. As opposed to smartphone OSs—which often undergo large changes in short periods of time and might require reworking the app’s code—our progressive browser-based app has required fewer browser changes that might have broken the app’s functionality. This has given us the confidence that we made the right decision in switching to a progressive web app.
At this point, the only thing left to do with the old app was to retire it. As we neared retiring our old catalog, we decided to pair the retirements, since the scripts feeding the old app were connected to the old catalog, and we didn’t want to confuse people by having to communicate two different end dates. While we had added an alert in the old app inviting users to make the switch to our new app, we revised the alert to instead warn of the old app’s upcoming end of life.
Even though it had been almost 8 months since we had alerted users of the new app—2 months warning of its retirement—we still had a few people who contacted us about the app going dark after we removed it from the app stores. Luckily, we could easily set them up with the new app, and they were able to continue without noticing much difference.
While the bug fixes have been minor, we have many ideas for continuing to develop other features for the app. One feature we have been eager to implement is notifications. We would also like to make some usability improvements such as making the barcode—one of the most popular uses of the app—easier to access. In addition, we’d like to take advantage of our newer APIs to integrate the promotion of new materials and other collections.
With only one codebase to update, we can spend our extra time on new features or other projects instead of duplicating work in another
codebase. It also allows us to divide the work and use our existing skills to contribute to its development. It has been a much smoother development process than with our old native app. And overall, we are very happy with our switch to a progressive web app.
|
Alyssa Hanson (