Review of the usability and readiness of modern web technologies

Progressive web apps, or PWAs, are web applications that provide a user experience comparable to a native mobile app using only web technologies. Historically, web apps have been unable to interface closely with hardware, such as mobile cameras and sensors, which combined with other limits associated with running in a browser greatly reduced their utility relative to a native mobile app. Over the years since the appearance of mobile apps, new web APIs have been developed to allow developers to access many of the unique features of mobile devices, such as geolocation, touchscreen inputs, motion and orientation data, and media capture, among others. Between these APIs and the PWA system, web developers can potentially avoid the complexity of developing for both Android and iOS while making only minimal compromises on their feature set and user experience, and now can even offer PWAs alongside native apps in mobile app stores1. However, support for these features varies between browsers and operating systems, and there can be substantial disparities in feature maturity. At present, this space is still evolving, and several of the features discussed in this thesis are still experimental or of limited availability. Beyond this, the complexity of implementing each feature may render their use impractical for a given project. These questions are of particular relevance in student development projects, where resources and practical experience are limited. This thesis will review a selection of web features, as well as the code necessary to set up an app as a PWA, evaluating their technical maturity and relative difficulty of implementation.

REVIEW OF THE USABILITY AND READINESS OF MODERN WEB TECHNOLOGIES by Skogen Larson A Senior Honors Thesis Submitted to the Faculty of The University of Utah In Partial Fulfillment of the Requirements for the Honors Degree in Bachelor of Science In The School of Computing Approved: _____________ David Bean, PhD Thesis Faculty Supervisor _________ Mary Hall, PhD Director, Kahlert School of Computing Thomas Henderson, PhD Departmental Honors Liaison _____________________________ Monisha Pasupathi, PhD Dean, Honors College May 2024 Copyright © 2024 All Rights Reserved ABSTRACT Progressive web apps, or PWAs, are web applications that provide a user experience comparable to a native mobile app using only web technologies. Historically, web apps have been unable to interface closely with hardware, such as mobile cameras and sensors, which combined with other limits associated with running in a browser greatly reduced their utility relative to a native mobile app. Over the years since the appearance of mobile apps, new web APIs have been developed to allow developers to access many of the unique features of mobile devices, such as geolocation, touchscreen inputs, motion and orientation data, and media capture, among others. Between these APIs and the PWA system, web developers can potentially avoid the complexity of developing for both Android and iOS while making only minimal compromises on their feature set and user experience, and now can even offer PWAs alongside native apps in mobile app stores1. However, support for these features varies between browsers and operating systems, and there can be substantial disparities in feature maturity. At present, this space is still evolving, and several of the features discussed in this thesis are still experimental or of limited availability. Beyond this, the complexity of implementing each feature may render their use impractical for a given project. These questions are of particular relevance in student development projects, where resources and practical experience are limited. This thesis will review a selection of web features, as well as the code necessary to set up an app as a PWA, evaluating their technical maturity and relative difficulty of implementation. 1 For example, Google supports PWAs in its Play store: https://chromeos.dev/en/publish/pwa-in-play. Apple’s App Store can also serve PWAs, but this process is experimental and more complicated: https://docs.pwabuilder.com/#/builder/app-store. ii TABLE OF CONTENTS ABSTRACT ii INTRODUCTION 1 METHODS 3 FEATURE DOCUMENTATION AND STATISTICS 5 TEST APP INFORMATION 6 DISCUSSION 7 CONCLUSION 16 REFERENCES 99 iii 1 INTRODUCTION Over the past two decades, the boundaries of web technology have regularly expanded with new capabilities to serve its continuously growing user base. Following the proliferation of mobile devices and their app systems, which offered unique opportunities for developers, several web APIs and technologies have been developed to take advantage of the functionality of mobile devices. Despite the historical advantages of native mobile apps, the division of the mobile market between iOS and Android makes developing one less appealing, as it is necessary to develop parallel versions of an application to reach the full set of available users, and the two platforms use different programming languages. [1, 2] As a result, the PWA has emerged to provide an option to reach a wider range of mobile users with less development overhead. Implementing a web app as a PWA allows many mobile users to directly install the app on their device, and provisions are available for offline functionality, another traditional advantage of native apps. [2] PWAs and related features allow developers to use many of the advantages associated with a native mobile app, but being web based means that in using these features they are subject to factors native apps aren’t. [2] For example, the standards and specifications for many web APIs are defined by the World Wide Web Consortium (W3C), which issues recommendations for mature features and develops draft and candidate recommendations for others still under development. However, W3C is not the sole authority on feature support, as some specifications for widely supported features are provided by organizations such as the Web Hypertext Application Technology Working Group, WHATWG. Each system of specifications for web features generally follows a similar format regardless of the 2 issuing organization. As support for a feature must be implemented by the browser for it to be of any use for web developers, this arrangement of recommendations provides a common starting point for browser developers, though some variation in how features are implemented still occur. This analysis is intended to gather and synthesize information about a selection of current technologies, providing an evaluation of their current state. The selection of features was chosen and evaluated partly because of their potential utility for my own senior capstone project, MapU, an indoor mapping and navigation web app. Several of the selected features seemed to have potential applications to the project, but ultimately they were not used. While they did offer some potentially interesting opportunities for extending the project app’s feature set, none of the selections were necessary to fulfill the app’s core functions, and didn’t prove directly applicable enough to build advanced features with. However, the information collected here may be of some use to others in a similar academic project context. 3 METHODS There are a number of relevant factors for evaluating the technical maturity of a web feature. These include browser and operating system support, the state of the feature’s specifications, and its complexity and difficulty of use in development. To address questions like extent of support, existing statistics are available. Here, an invaluable source of such data has been the site Can I Use, at https://caniuse.com/, which is a project maintaining tables of compatibility and support information for many web features. Community contributors determine whether a given browser version supports a feature, and then based on browser usage statistics the site is able to provide an estimate of how widely available it is to users. Links to documentation and examples for each feature are also often available. Specifications for each of the selected features are available from the respective organizations that maintain them: W3C, the WHATWG, and Google. Of particular note is the status of these specifications- W3C has a system with several levels. Recommendations are considered technically mature, with Proposed and Candidate recommendations being those that are working towards full Recommendation status, and Working Drafts being the earliest proposals still under review. In evaluating the difficulty of using a new web feature in development, it can be useful to try it out by implementing it in an app to develop familiarity. As such, I created a simple test app to let me try out and determine the technical maturity of each of the features. Another useful resource in finding information for this review has been the site “What PWA Can Do Today”, at https://whatpwacando.today/. This site is based on a similar 4 premise to this review’s test app, being a site which provides a collection of demos of web features, and was part of the inspiration for creating the test app used here. 5 FEATURE DOCUMENTATION & STATISTICS This table collects information about the selected features, with links to its specification, leading sources of documentation, and the link to the CanIUse statistics on support. Feature Specification Documentation Support Statistics Web App Manifest/PWA W3C Working Draft MDN Docs CanIUse Media Capture W3C Candidate Rec. MDN Docs CanIUse Geolocation W3C Rec. MDN Docs CanIUse Notifications WHATWG Standard MDN Docs CanIUse Barcodes & QR Codes W3C Draft Community Group Report MDN Docs CanIUse Touch Events W3C Rec. MDN Docs CanIUse Motion & Orientation W3C Rec. MDN Docs CanIUse View Transitions W3C Candidate Rec. MDN Docs CanIUse Wake Lock W3C Candidate Rec. Chrome for Developers CanIUse 6 TEST APP INFORMATION TEST APP: The testing app repository is available for review on GitHub: https://github.com/SkogenL/PWA_TestApp LINES OF CODE: Lines of code as an independent metric is generally not a useful measure of the difficulty of using a feature, but can help inform a wider assessment of the feature’s complexity. Line count is based on the number of lines of JavaScript in the functions supporting the feature or setup code, plus lines of HTML directly associated with the feature. Comment lines as well as HTML linked with the feature code but used for controlling page layout and styling are not included in the count. Feature Lines of Code Media Capture 2* Geolocation 29 Notifications 39 Barcodes & QR Codes 35 Touch Events 134 Motion & Orientation 38 View Transitions 17 Wake Lock 35 PWA Support 96 *Note: This count is for the simpler form of image/video capture. 7 DISCUSSION Feature PWA Support Function Allows the web app to be installed to the users device, and allows the installed app to function offline. Support Statistics Web Manifest: CanIUse - As noted, no single compatibility table for the web manifest system. Service Worker: CanIUse - 96.73% Full support, 0.63% partial support. Supported by all current browsers- the main browser which does not is Internet Explorer. Specification W3C Working Draft - Very recently updated, actively in the works but still has some distance to go until full recommendation status. Documentation As several components are required to provide installable and offline capable PWAs, relevant documentation is spread across multiple areas. Extensive background information and code examples are available. Manifests: MDN Docs Service Workers: MDN Docs PWAs Generally: MDN Docs Test App Usage On supported devices and browsers, the test app can be installed as a PWA. Typically on mobile this adds an app icon to the home screen which opens the app similarly to how it appears in a web browser. In the absence of network connectivity, the app can still be opened and used, as a service worker caches the relevant resources. Readiness High - Web manifests, allowing installation, and service workers, allowing caching for offline use, are widely supported. Specific parts of the manifests may not be available, but the minimum requirements are largely available on all browsers. Ease of Use Moderate - Basic offline functionality and installability for a simple app is straightforward, though requires some effort. In the test app, there was a bit of work required to set up the Django backend to work with the service worker system, as the scope of web pages they can work with is typically defined based on its position in the server’s file structure. 8 Feature Media Capture Function Interfaces with the device camera to capture imagery or video. Support Statistics CanIUse - 97.1% Full Availability, 0.25% Partial Availability Very widespread support. Not supported by Internet Explorer, which despite its deprecation still remains in use, and at around 0.59% represents the largest share of non-supported users. Specification W3C Candidate Rec. - Status: Candidate Recommendation Draft. This recommendation is still at the candidate level, but it is well developed and extensively implemented despite not being considered a full recommendation yet. Under the Status of This Document section, it notes that a review identified some issues that are supposed to be addressed before moving further, and there is active discussion on these on the GitHub issues page. Documentation MDN Docs - Media capture is well documented, including examples. Test App Usage As implemented in the test app this is a simple version- on iOS, for example, the HTML input element offers the option of selecting a photo from the device, or opening the camera. A more complex form is available, which works directly with the media so capture stream to provide a preview, however this system is much more complex. Given that mobile devices increasingly offer an option to open the existing camera system, which has its own preview, the use case of the more complex media capture has narrowed. Readiness High - Images can be readily obtained like this, either through the operating systems default file upload mechanism, or by using user media streams. Ease of Use High - Essentially just requiring the HTML file input set to the correct type, this is easy to use. The more complex interaction with the media stream is closer to moderate to low ease of use. 9 Feature Geolocation Function Obtains the device’s current location data from the operating system. Support Statistics CanIUse - 98.2% Full support. Very widespread support, only not available in little-used legacy browser versions. Specification W3C Rec. - As a W3C Recommendation, the specification is considered mature and suitable for widespread use. Documentation MDN Docs - Geolocation is well documented, with guides and example code available. Test App Usage Geolocation was implemented in the test app as a simple button, which when clicked displays the users latitude and longitude coordinates, with a link which opens OpenStreetMap centered on those coordinates. Typically requesting permission to access device location data is required, so if that has not already been granted, clicking the button will request permission, at which point the browser will prompt the user to grant or deny it. Readiness Full - Fully ready and mature feature, effectively fully supported. This is a long standing API, much older than many of the others reviewed here, and has had time to become fully fleshed out. Ease of Use Great - This feature wasn’t too difficult to implement, and the objects and functions provide the location data in an easy to access manner. It would be simple enough to provide the data for use in a more complex system. As with several of the other features here, it’s necessary to have a simple check to ensure it is supported before attempting to call the API, as doing so would cause an exception in a browser that doesn’t support it. This is of course a rare situation, though. 10 Feature Notifications Function Sends a notification to the user with a title, the icon of the app it was generated by, and body text to inform them of something. Support Statistics CanIUse - 77.86% Full support, 13.4% partial support, total of around 91.3%. While available to many users, several browsers do not offer support at all, and Safari on mobile, the largest share of the partial support segment, has conditions on the use of notifications that others don’t. Some measures have been taken by browser developers to prevent excessive use of this API, so these limits should be checked to avoid violating them. Specification WHATWG Standard - While differing from the W3C Recommendations of most other features here, this specification is very similar to those. Documentation MDN Docs - The notifications API is well documented, with guides and example code available. Test App Usage Notifications are implemented with a simple button that, if the API is supported, can be clicked. This produces a notification with the site icon, and some sample text. Depending on the browser and operating system, the appearance of this notification can vary somewhat- some use the OS notifications system, some have a different system. As with geolocation, permission must typically be granted by the user at least on first use. A service worker is created, which can then be used to display a notification once user permission is granted. 39 lines. Readiness High - While the standard for this API is well developed, the partial support of mobile Safari and lack of support for nearly 9% of the user space does mean that it may not be suitable for some applications. Ease of Use Good - Creating the notification is straightforward, just requiring some code to check for support, then request and receive or be denied permissions. After this, notifications can be sent regularly, though some browsers impose a minimum interval between messages. 11 Feature Barcodes & QR Codes Function Takes an input image and checks for the presence of bar codes. If any are present, the data encoded is output in an array. Support Statistics CanIUse - 46.7% Full support, 28.1% partial support, total of around 74.8%. At present, this is not available on Windows, limiting it to macOS, ChromeOS, and Android, and only certain browsers on each. Firefox and Safari do not support it at all, for example. Quite poor availability. Specification W3C Draft Community Group Report - As noted in the document, the barcodes API specification is not a W3C recommendation, and apparently isn’t even on the track to become one at this time. As such, it is still considered experimental, and likely will not progress to another stage for at least some time. Documentation MDN Docs - This API is documented somewhat, but the code examples are short and do not provide much context or supporting code, and the descriptions are not as in-depth as other features reviewed here. Test App Usage Users can upload an image through a file input, which is then displayed below alongside the information encoded in the detected QR code, typically a URL. 35 lines. Readiness Low - Not reaching Windows, Firefox, or Safari really limits this APIs reach. Developers are less likely to use it if features based on it will only be available for part of their user base. Ease of Use Moderate - Some work around file handling may be required to get the image provided and hand it off to the API and then to get any data encoded in the codes into a usable state. Error checking and handling must be provided. 12 Feature Touch Events Function Captures touch screen motions with fine detail, with continuous updates on position. Support Statistics CanIUse - 93.2% Full support, no partial support. Fairly good availability, not the highest here but achieves wide coverage. Specification W3C Rec. - As a W3C Recommendation, the specification is considered mature and suitable for widespread use. Documentation MDN Docs - Substantial documentation available, including example code that accounts for much of the complexity associated with touch events. Test App Usage Using a system similar to that in the MDN example code, a canvas allows users to draw by touching the canvas. Multiple simultaneous touches are supported. 134 lines. Readiness High - Wide coverage, and W3C Recommendation status show that this is a developed and mature API. Ease of Use Moderate - A major source of difficulty in this case is the volume of code required. Functions to handle the start and end of touches are required, for example. The code maintains a set of touch events as well, which has to be updated during start, end, and move events. 13 Feature Motion & Orientation Function Obtains device accelerometer data from the operating system, including coordinates which describe the device’s orientation and movement in all dimensions. Support Statistics CanUse - 0.04% Full support, 95.01% partial support, total of 95.05%. This requires a particular note, due to the division between partial and full support used by CanIUse in this case. As noted on that page, there is a compassneedscalibration event which is not supported by any recent browser version, but this is not strictly necessary to use motion and orientation data. Specification W3C Rec. - As a W3C Recommendation, the specification is considered mature and suitable for widespread use. Documentation MDN Docs - MDNs documentation provides details on much of the orientation API, and has a full example of using it to move a dot around in a box. Test App Usage Users can start detection of orientation data by clicking a start button, which will at that stage request permissions if necessary. Once permissions are gained, three colored bars show the three current orientation coordinate values similarly to a bar graph. 38 lines. Readiness High - Given that partial support as defined by CanIUse is based on lack of support for a function that is no longer used, it is essentially equivalent to full support. Given that this API has a W3C recommendation, it is ready for use. Ease of Use Moderate - Some extra effort is required to deal with the fact that some browsers use coordinates differently. However, once that is dealt with, data is readily accessible through the device orientation and motion events for rapid use. 14 Feature View Transitions Function Allows web page elements to be swapped out in a visually interesting way, such as fading in and out, sliding on or off the screen in any direction, and so on. Support Statistics CanIUse - 71.2% Full support, no partial. Limited availability at present, and while many browsers are working to implement this, it isn’t there yet. Notably still in the works for Safari and Firefox. Specification W3C Candidate Rec. - This specification is still on the track to approval from W3C, and is still evolving. Documentation MDN Docs - Well documented, linking to external examples and demos. Test App Usage In supported browsers, users can check a box to add view transitions when selecting a new tab on the site. Instead of the default instant swap of feature tab content, a brief transition animation will show the old tab content sliding off screen and the new content sliding into view. The transition is initiated in a function which was added between the event listener for tab selection and the original function for actually replacing tab content. 17 lines. Readiness Moderate - Though already fairly developed, the standard is still evolving and approval is pending. Support covers a decent fraction of the market, but pending Firefox and Safari support a substantial gap remains for the time being. Ease of Use High - Relatively little HTML/JS work was required, just a check to ensure transitions are supported, but many options are available for styling the transition in CSS. 15 Feature Wake Lock Function Allows the application to prevent the device from going to sleep. Support Statistics CanIUse - 89.3% Full support, no partial support. Largely supported by all current browsers, with the exception of Firefox, which only has the feature enabled in beta at present. Specification W3C Working Draft - As a draft, this specification remains in the works and isn’t immediately adjacent to full recommendation status at this time. Documentation Chrome for Developers - Google provides decent documentation and examples here. MDN Docs - Further documentation is also available from MDN. Test App Usage Users can, if supported, check and uncheck a box to activate wake locks. This should prevent their device from going to sleep after a period of inactivity as it typically would. 35 lines. Readiness High - Despite the present lack of availability on Firefox, this feature is otherwise widely available. W3C’s draft specification is well developed despite its stated classification. Ease of Use High - All that’s necessary beyond checking for support is requesting and awaiting a wake lock, and setting it up to eventually release. This is fairly simple. 16 CONCLUSION In gathering this information and developing the PWA test app, I found myself surprised by the degree to which web apps can now interface with mobile device sensors and control things like wake locks. As noted in [2], many new web technologies have focused on providing functionality to web apps previously exclusive to native mobile, although some of these features are relatively new. Some years have passed between the publication of [2] and this review, and the maturity of many of these features has advanced. However, given that several of the features evaluated here are still having their specifications developed and are still being implemented by some browsers, there’s still some distance to go to make these part of the web development baseline. When implementing apps using newer functionality, Chrome is generally a safe bet as an early adopter. Chrome, though, is not the only major browser, requiring mechanisms to handle a lack of support when other browsers are still implementing a given feature. In academic web software projects like mine, we have to consider whether APIs like those above are suitable for use in our projects, due to time and experience constraints. As these features achieve full browser support it’s likely that more of them will begin to appear in early web development education and in student projects. 17 REFERENCES [1] Biørn-Hansen, Andreas & Grønli, Tor-Morten & Ghinea, Gheorghita. (2018). A Survey and Taxonomy of Core Concepts and Research Challenges in Cross-Platform Mobile Development. ACM Computing Surveys. 51. 1-34. http://doi.org/10.1145/3241739 [2] Majchrzak, Tim A. & Biørn-Hansen, Andreas & Grønli, Tor-Morten. (2018). Progressive Web Apps: The Definite Approach to Cross-Platform Development?. Proceedings of the 51st Hawaii International Conference on System Sciences. 5735-5744. http://doi.org/10125/50607 Name of Candidate: Skogen Larson Date of Submission: May 6, 2024