Wounded Warrior Support Network is a website I have worked on since its inception.
WWSN is a non profit organization that supports wounded and in transition veterans and their families reacclimatize to civilian life.
Originally the website was made in Adobe's Muse. This was as a result of my own lack of time and web development knowledge, but had a number of perks.
For one, the site was created quickly, within about a week of on and off development, focusing almost entirely on the design. Was the design great? No. By modern standard the website was navigable, was readable and legible, accomplished many goals of the organization, was better than most websites available at the time, but still not great to look at. In addition, WWSN as an organization was moving quickly, and needed to be able to update the website in almost real time. Muse required a full reupload of the site at every update, an untenable solution. In addition the website was not responsive, an issue not as important in 2010, but very important today.
So the problems that needed solving were straight forward, a non profit website that was focused on updates and a lot of static content, with a reliable backend infrastructure that allows for infrequent, but high priority updates anywhere.
In 2014 I attended Google's I/O developer conference. The draw for me was the web development tools, specifically, Polymer. Polymer allowed for easy implementation of the new Material Design spec, with added access to much easier implementations of ajax requests that are cross platform and light on code. Perfect for resolving many issues I was running into.
Polymer has changed my life.
It makes so many web development issues much easier, and I can lean and learn from the massive community of web developers the world over and allows me to focus on the goals of the project. So for a year I spent my days writing and rewriting WWSN's website using Polymer as its underlying structure. Each rewrite offered better and better handles on the code, HTML, and CSS. Then, Polymer reached its milestone precisely one year later, Polymer 1.0, production ready. Then I got to work.
From that came this.
This site is a lot of great things.
It was pretty fast. It is a full scale single page application. Essentially, this means the web page is fully loaded at the very first load, and page changes occur at the client level. This means there is a perception of nearly no load time in between page switches, and reduces people deciding to leave due to page load from the front page to the donation page. This site can be changed on the fly. A backend service handles nearly all of the content and minute changes can be made from anywhere on earth with any device, and instantly.
It was responsive.
It has breakpoints based on the Material Design Spec, and adapts to those scenerios properly. The site is capable of being viewed comfortably on any web enabled device down to an iPhone 4 without missing any content.
It was filled with nice Material Design flair. Paper buttons and ripples whenever something important was selected.
But it wasn't good enough.
Modern hardware with a 10x processor throttle.
Now, it was fast on modern hardware. A 6 second page load is decent, but that was on a modern piece of hardware, something like an iPhone 6 or a MacBook Air with a 1 to 2 Ghz processor. But on an iPad Mini, the page would load in 12-15 seconds on a good network.
The problem was a few things. Remember that backend I was talking about? Well, it was a Google Sheet. I know what you're thinking, "What in the world are you thinking?" but there are some advantages in terms of security and reliability, and the fact that it has companion apps meant there was a great backend with adaptability to variables, etc. etc.
But the drawback was a guaranteed 1 second add to load time. After that load, all of the json was filtered, sometimes twice, to allow for pages to get and show data, then, and only then, was a page actually loaded. This is fine for a beefy computer, but for an iPad 2 or a lower end iPhone, that was not acceptable.
This was something that I was OK with, since I didn't really have the knowledge set to improve this. I compressed and resized images.. 1 sec off. compressed the JS, the HTML, another half second.. used a gulp toolchain to automate the process, another second... Loaded the pages lazily, meaning the Single Page architecture mentioned before was made more lenient, another couple of seconds off..
Despite these improvements, the issue was the underlying structure. Google Sheets mixed with repetitive json parsing = poor CPU performance.
Also, the perception vs actual performance was also an issue. On an iPad Mini, Not only were there issues with load time, but also the scroll performance and page bumping as a result of components loading. Overall, the experience was.. decent, but not great..
Then Polymer 2.0 landed.
Web Components (WCs) is the underlying structure of the modern WWSN website. For the first year of using WCs the only browser with native support was Chrome. >80% of the sites population is fine, Safari and others simply needed to load a polyfill and no problems were had. I also used Service Workers and some fancy CSS effects, Chrome and Chrome. It meant I left out IE, but I simply renavigated them to the legacy site and that was that.
Now those options are available in all modern browsers, even Safari. This means the door was open for some amazing things.
In comes WWSN-New.
This site has a lot of great things going for it. I changed hosting to Firebase, meaning between Cloudflare and Google's CDN, I have a performative, adaptive website with SSL, high uptime, and other neat things like HTTP2 push, and Service Workers allowing the site to mostly work even with no or poor connection.
The site loads lazily. Especially pictures and other heavy content, it loads the basics, like the framework and basic structure, and then loads the content like txt and images after. I have tried my best to emulate the PRPL pattern. A method of loading websites with as little as possible that lowers perceived wait as much as possible.
And, it uses the new Polymer 2.0, which is as closely linked to the basic platform as possible. Basically, if I am using the low level operations of the browser as much as possible, I have a site that is fast and scalable. I polyfill when necessary, and I simply don't use features not available on most every browser.
There are some browser specific features I really like, like Safari's backdrop-filter: blur..
But I also planned for the lack of support on other browsers and it looks fine.
Responsiveness? Better than ever.
The site is based on a flexbox grid and only a single responsive breakpoint.
Wait what? Only 1?!?
That's right. I only added a mobile breakpoint since I used rem and percentages to handle effectively every usable size on the web. The previous site was good at handling most of the web, but large screens were its achilles heel, things just didn’t look right. Now, from a 5k iMac, to an iPhone 4, the site looks great.
And most of all the site is fast.
Even on my iPad Mini.
Notice the animation at the start. That is just an SVG on a looping animation that keeps the user from perceiving the site isn't functioning, and, it only adds maybe 7kb..
And check out this sweet animation
And finally, the site uses Firebase for its backend. Firebase is designed for realtime updates, far exceeding the needs of an essentially static website, but allows for far improved speeds. I had to handcode an administration site, but that's not so bad, and Polymer makes it pretty easy. It's not pretty, but it works, and I can improve it over time.
The site is not perfect and it is not done, but the foundations are there. The site has a 98 Performance score on Lighthouse, and the user experience is light years ahead of anything I have experienced throughout the web, let alone on a NPO website.
At the end of the day this project is a story of my own learning. The process by which I have learned more and more through building, iterating, tearing it down and starting again. The pictures and thoughts you see here are finalized conclusions of long nights staring at a computer screen sometimes cursing ever starting the project.
In the end, I am a better developer, designer, and collaborator as a result, and for that Wounded Warrior Support Network will forever hold a precious place in my thoughts.