My Thoughts, Experiences, and Notes on the development of the GDG Philippines Devfest site

I was tasked to do the GDG Philippines Devfest Site for this 10th year GDG Devfest Philippines. The event will be big because this is the first time we will have multiple parallel sessions, with a lot of great speakers, with the event supported by a lot of sponsors, to be attended by a lot of people. I was tasked to develop and maintain the front-facing site that will be used by speakers, sponsors, and attendees.

When I got that task, I already know what I want to do with it.

I want to play with Polymer 2, Firebase, and service workers to make it a Progressive Web App.

Requirements

Here were the requirements I got for the site.

• View Event Schedule - Users can view the event schedule
• Event Stub Scanner - Allows sponsors to scan users IDs (which are connected eventbrite tickets).
• Codelabs - Users can play with the codelabs and get points for a prize.

Given the above parts, there are a lot more that I did based on what I think the site needs, which were:

• It needs to have a CMS - I can’t afford to re-deploy a PWA site every now and then when there’s an update in content. So I need to separate content from the shell.
• It needs to connect their Eventbrite ticket to their account - this is for the event stub scanner.

To help me, I found some really good volunteers to help me build, manage, and find bugs on the site as we are building it.

Now, the kicker: I have to develop it in a short amount of time.

So what did I do?

Landing page

I started with creating the landing page of the site. This allows people to already know that “Hey! Devfest is coming! Tickets are now available!” Good thing I have my friend Juvar Abrera who helped me with the design. So that slashes off a huge amount of time (It takes me a lot of time to plan and design sites).

Tickets

I also created a ticket page that allows them to see their perks and get their tickets from Eventbrite.

Speakers

Next part is the showcase the speakers, so I created a set of reusable components that showcase the speakers and their talks.

Schedule

Lastly, the schedule. It allows people to see the event schedule at a glance.

Updating the Content

Now, new information about the event comes almost every week. That means the site’s content should be updated when there’s new information. But I can’t re-deploy the site every week for new information, especially when I have a service worker running. I could create a content management system to allow me to update the site, but that needs me to have a whole blog system with forms and what not. Because I created the site from scratch and I don’t have a CMS module in place, I need a way to easily push updates to the site, with security features that allows only me full authority to deploy changes on content but also allow others to push their change and request those changes to be accepted and be shown on the site.

So I used Github as the repository of content, which is automatically pulled and cached by the site.

This allows me and everyone else in the team to update content without me having to re-deploy changes in the site. It also allows me to focus more on creating the more important parts of site.

Profile Page

This allows attendees to login, connect their Eventbrite ticket for the sponsor scanner later, and connect their Github repo for the codelabs. I used Firebase for this one.

Ticket Scanner

I used the mediaDevices API to allow me to access the phone’s camera and allows me to get the QR code found in the IDs (or Eventbrite tickets). Then I used a small library called qrcode-reader to process the picture on the frontend instead of sending the picture to the backend (which would be bigger and slower compared to sending string data). Then I send the data to my API to process it.

Codelabs

The most exciting part that I created was the Codelabs. Previously, the codelabs part of the Devfest have curated codelabs from the Google Developers page and has quizzes after each codelab to check if people did the codelab (or at least know how to do those parts). What they did was to linked the page to the Google Developer’s codelab page and then after doing that, a pop-up quiz will show up.

What I did is different, I remember my first attendance on GDG Devfest Philippines back in 2015 as an attendee, and I remember that after each small workshop with a codelab, we have to submit our finished Github repo to a Google Form and earn a badge or something. The attendance was small per codelab so it is easily manage-able. But now, the codelabs is open to all and I need to automate the checking process.

So instead of linking the codelabs to the Google Developers page, I asked my volunteers to create an exact replica content of curated codelabs and make it into markdown files, which I then asked to be pushed in the Github repo.

I then created reusable components to fetch those codelabs content and transform them into codelabs pages. And then I added an end page where they can submit their Github repo.

For checking, I thought of a lot of ways on checking the given Github repo link. One is having the people have an account Travis, copy a given travis.yml, which has a code to download a checker code, and then executes that checker to run the repo and checks it. Once done, it sends the score with some kind of authentication key or something to my API to get the score. At least that’s what I think it should do. But it is too complicated for me to setup and for them to set it up as well. Besides, I only know how to test website code, not Android code, so that limits the codelabs I can offer.

I really do want a VM to check the code but I don’t have yet the experience or cash to implement or time to research and implement, so I cheated. What I did is to have my API to check specific files and check if some of the needed parts exists to run the code. Essentially, it is not running the file but is checking it if some strings exist.

And to give incentive to those who have connected their tickets to their account, they get twice the points, which I forgot to tell… my bad :(

Note: Because by the time they have loaded the codelabs, Firebase might have also been loaded, and for easy checking, I put all codelab markdowns inside the Firebase database.

Here comes the breakage

I always tell that myself that once in production, the bugs that we were not able to see will finally come to light.

To help me see those bugs, I added Sentry to track all the bugs. What I got are many bugs, and other users who can’t use the app well… :P

iPhone users can’t use the camera

Because Safari is the new IE (I currently stand by this statement), and they did not implement mediaDevices below Safari 11…

And about 1/5 of the Devfest attendees on that day used Safari 10 below…

… means that a lot of people were not able to use the scanning page to scan and connect their tickets to their account. I did try to add a polyfill for mediaDevices but I think it didn’t work. Although I know there’s a workaround which was used by people from the first Polymer Summit where they showcased the Polymon (See around 23:05), I wasn’t able to do a workaround before the event…

So what I did is to publish a live update of the site where they can submit their ticket numbers to an input box. The good thing here (at least for this case) is that Safari hasn’t also implemented service workers…

That means my update will be experienced by Safari browsers without waiting for the new service worker to kick in.

Ticket Scanner is a bit hard to use

Because I just hacked the ticket scanner to use the mediaDevices, I forgot the UX part of it (my bad…). That means it is hard to align the phone to scan the ticket, and it doesn’t give those beeping sound, or any good scanning queue (only a red box will appear), which helps the person who scans a queue that it has already been sent to my API. The phone also has to wait for my API response before allowing the person to scan another ID. I could have used the service worker’s background sync but I haven’t got the time to study and create a module for this purpose so I wasn’t able to implement it. This means if the scanner has bad reception, it will take longer time to scan a ticket… and, unfortunately…

Internet really sucks when you’re out of range

Although we have fast Internet courtesy of Globe, We could not cover the whole event with really good Wifi, so some people can’t access the interactive parts of the site (where they need to submit to the API) on some areas of the event. Unfortunately, one of the areas is a part of the sponsor booths. Some of the sponsors weren’t able to scan attendee IDs immediately, thus long lines and not enough time to scan them all.

Why didn’t I use the Devfest Hoverboard?

Although the Devfest Hoverboard is easy to use, I wanted to have a small footprint on my app and was preparing for Polymer 3 (that was the time that the Polymer Summit happened as well when I was developing the app). I also want to use Workbox as well instead of the sw-precache, which was part of the Polymer bundle build. So I figured I use webpack for the site and create my own builder for this.

A typical Devfest Hoverboard would have half an MB (about 590KB) on first load, while the Devfest site uses about 459KB, both without the images. And just loading the site without Firebase (which is only used to authenticate the user, because all of my data is coming from Github), I am able to load the site at about 85KB, with the core shell at around 40KB and the pages at around 30KB. Because I believe that the most important thing is the page content, I also lazy-loaded the header and drawer, which amounts to 20KB and 16KB. Content data from Github streams in at about 6KB. All in all, without the Firebase lib, it can serve the page at around 128KB. Add the Firebase lib, and it will serve the core, content, header, drawer and the lib at about 254KB, just above the hoverboard-app document which is 247KB, but without content (Content streams in from Firebase with about 500+KB or about 30+ frames of 16KB each frame for a full fledged hoverboard site).

Please take note that this is not a benchmark test and this is just a crude comparison without having some rigorous testing. Also take note, hoverboard is a tried and tested template and is used by a lot of Devfests around the world. The real reason is I want to test my skills and experiment along the way that’s why I opted not to use hoverboard and create my own, given the small time I have to create it. The good thing is I am pleased with my results but not yet satisfied. The problem is that I could have made the sizes smaller, if not for using legacy Polymer lib because I need to use the paper-elements library, which uses legacy Polymer lib to support Polymer 1 users. That somehow eats up to about 10KB more on the core shell. I could also improved the loading of polyfills so I can deliver the site faster on evergreen browsers and still serve a workable site with minimum but working polyfills at around 300KB.

You can see the parts of the site here (thanks to webpack-bundle-analyzer): https://devfest.gdgph.org/_bundle-sizes.html

In Retrospect…

I’m pretty much happy with the experiment that I did. Although I did missed out on implementing some functionalities that should have been there, like personalized schedules, feedback forms per session, and claiming digital certificates (this one I need to finish after next week). I learned a lot while doing this, much of it was put into writing when I wrote going back to basics of HTML (hint: one of them is about the viewport and Safari).

I really have great support from my buddies at GDG and some Googlers who helped me along the way. They always push me to the limit. Thus, I strive to be better at this craft and always on the look out on how I can improve the site’s user experience and performance.

What’s next?

After all of this, I am distilling what I have learned from creating the Devfest site and putting it all in one webapp architecture called smallprint (it’s empty right now but working on a push next week or the week after next), which is built using Polymer 3 as an abstraction library for many boilerplate code for creating web components. I also want to experiment and fully use Redux as the core state management of the system, following what I’ve learned from managing states in Angular applications. I will still follow the PRPL pattern but making it to PRPL-50 or making it just below 50KB.

The thing is to have the app ready in at most 1.5KB and it should follow that 50KB is a good threshold to follow.

Right now, my experiments show me that I can have a core shell at 20KB with just using a modified Polymer library (that doesn’t use its templating system and dom-module lib) and lit-html.

And although lib-html is at its early stages, even using just the Polymer library (not the legacy), the core shell uses up to 25KB, which pretty much leaves me about 25KB more for content or for other things (the core already has redux inside… so… neat!).

Cool thing here is I can also lazy-load polyfills when I need them.

Because of PRPL-50, I might really have to ditch using paper-element libraries and all other libraries the Polymer team have created because they are still loading the Polymer 1 legacy bundle even in Polymer 3.

Because Bower is deprecated, I will be using npm more and smallprint will be built using webpack. I might experiment as well on targeting my builds to specific browsers, as specified here (Deploying ES2015+ Code in Production Today). This allows me to limit the polyfills needed and also might play with the browser’s new JS module importing system.

I’ll also add Workbox and the ability to allow developers to input their service worker scripts in the mix, making their service workers a bit more configurable.

I also wanted to have a modular plug-and-play style of modules and components for smallprint. So I am using configuration file to manage the other modules that will be lazy-loaded by smallprint, and also wants to have the developers have ease on transitioning their modules with components from the source folder to npm (if they want to publish it) without the need to change dependency codes in their projects.

I also added into the mix a small router that is built for smallprint called the @littleq/littleq-router (just adding a namespace called littleq). The router follows the express’ pattern of picking routes and having middlewares.

It uses the @littleq/lazy-loader to lazy load components coming from the router. But to utilize the webpack’s dynamic import mechanism, it has its own lazy-loader component.

All in all, the goal of smallprint is to have it baked into some of the best practices I encountered in my experience in developing performant sites. Having to work on a site that will follow the PRPL-50 pattern will FIRE up the app, which is having a really Fast, Integrated, Reliable and Engaging app from the get go.

The specs of the smallprint project will be fleshed out while I build it and will be used in future GDG projects and other projects that I will be having for my other volunteer groups like UXPH (User Experience Philippines), PWDO (Philippine Web Designers Organization), or ACM SIGCHI (Association of Computing Machinery Special Interest Group on Computer-Human Interaction) or for my research on PhD.

If you want to help, just give DM me on twitter or just raise an issue on the smallprint Github repo.

Appendix: Some Specs

The GDG Philippines Devfest site is built using Polymer 2. It is bundled using webpack with the help of the polymer-webpack-loader. I also used gulp to do some preliminary building of folders and to build the service worker using Workbox. I have installed Google Analytics to basically give me some feedback on users and the hardware/OS/browser they use, and Sentry to catch production bugs. I used Github as my basic CMS and Firebase Authentication and Realtime DB for storing profile and scores. I used Firebase functions as my backend API and used Firebase hosting to host the site.

You can find the repository here: https://github.com/gdgphilippines/devfest (latest is in develop branch)