500 Albums

13 December 2018

500 Albums

Building a Progressive Web Application

500 Albums is a simple mobile web app that I designed and built to practice design and development. The app helps me find good albums when I am at the record store. If you visit the link above on Android, you will see a banner with an “Add to Home Screen” button. On iOS, you can tap the export icon and swipe the bottom section to the left and tap the “Add to Home Screen” button to add the app to your phone’s home screen like a native app.

Apple pioneered web apps in 2009 by adding support in Safari for special meta tags and a cache.manifest file to control what data was cached as part of the web app, Google has recently released tools including Workbox that makes creating web apps using service workers easier and Lighthouse that rates how closely a progressive web app meets Googles’s new standards. Progressive web application an important part of last year’s I/o conference.

Web apps are interesting to me because they are built with HTML, CSS, and JavaScript which means that I can design and develop the app myself. I wanted a project that would need only one screen so it wouldn’t require designing or coding menus or managing routing. The finished product above is the result of a lot of designing and tinkering.

The project was also a chance to design an app icon and I created a variety of different versions before I landed on the one above. I added the icon to the iOS splash screens.

My initial idea was to design and build the simplest functional web app possible using HTML and CSS from another project. By using a fixed width for the list box I avoided designing breakpoints. I designed and coded a responsive version but ultimately decided against moving forward with it because the larger images hurt load times on mobile. I tried out a responsive version with filter buttons but decided against moving forward with that version because it would have required adding a lot more data to my data model (a single JSON file) or even adding a back-end so that there would be attributes to filter.

I started with an older Angular JS address book project. Then I refactored it into JSX and React to get more familiar with React. Then I refactored it into ES6/Babel to learn a little of the newer syntax.

Chuck McQuilkin

Portfolio Blog About

Code 500 Albums Progressive Web Application Posted by admin on Dec 13, 2018 in Code, UX, Web Design | No Comments 500Albums

500 Albums is a simple mobile web app that I designed and built to practice design and development. The app helps me find good albums when I am at the record store. If you visit the link above on Android, you will see a banner with an “Add to Home Screen” button. On iOS, you can tap the export icon and swipe the bottom section to the left and tap the “Add to Home Screen” button to add the app to your phone’s home screen like a native app. 


Apple pioneered web apps in 2009 by adding support in Safari for special meta tags and a cache.manifest file to control what data was cached as part of the web app, Google has recently released tools including Workbox that makes creating web apps using service workers easier and Lighthouse that rates how closely a progressive web app meets Googles’s new standards. Progressive web application an important part of last year’s I/o conference. 


Web apps are interesting to me because they are built with HTML, CSS, and JavaScript which means that I can design and develop the app myself. I wanted a project that would need only one screen so it wouldn’t require designing or coding menus or managing routing. The finished product above is the result of a lot of designing and tinkering. 


The project was also a chance to design an app icon and I created a variety of different versions before I landed on the one above. I added the icon to the iOS splash screens. 


My initial idea was to design and build the simplest functional web app possible using HTML and CSS from another project. By using a fixed width for the list box I avoided designing breakpoints. I designed and coded a responsive version but ultimately decided against moving forward with it because the larger images hurt load times on mobile. I tried out a responsive version with filter buttons but decided against moving forward with that version because it would have required adding a lot more data to my data model (a single JSON file) or even adding a back-end so that there would be attributes to filter.

I started with an older Angular JS address book project. Then I refactored it into JSX and React to get more familiar with React. Then I refactored it into ES6/Babel to learn a little of the newer syntaxes.

I also adapted the design several times. I tried out more of a brutalist look and feel with a white background and black text. I also tried out two versions with larger album images, but I found that the designs with larger images performed poorly according to Lighthouse. A version with that used static HTML (No AJAX) and lazy-loaded the images with Javascript didn’t improve performance much.

Designing a simple web app got complicated. Now I know why the original 500 album list was paginated. Loading a few 20k images isn’t a big deal, loading 500 20k images is slow. I didn’t want to add pagination, so that meant that the images had to be small and optimized.

I found with Lighthouse that the React framework was one of the things that were slowing my little app down. I didn’t really need to use React in this project because all I was doing was fetching the list JSON, rendering the list HTML and filtering the list, all things that could be done with vanilla JavaScript. Then I discovered Preact which is a scaled down version of React created specifically for web applications. I also ran across an article that described measuring the baseline costs of javascript frameworks.

Performance and simplicity were the main reasons why I settled on a vanilla Javascript progressive web application for the final version.

Developing the idea for the project was almost as difficult as refactoring the code because I wanted to build something useful but avoid the temptation to add a new feature. I own a copy of Rolling Stone’s 500 Greatest Albums of all time, but when I am at the record store (we still have those in Austin ❤ Waterloo Records), chances are I didn’t bring the book with me. This filterable list could be reused with different kinds of lists such as top 500 beers, top 100 TV shows or top 100 movies, top 500 podcasts, 500 easy to prepare recipes, etc.

The code for the final version is on Github, the other versions are on Codepen.