Travel to Live Blog

Stories of our adventures and updates about the site.

Category: Web Development

Progressive Web App Checklist

We’re constantly working to improve Travel to Live and following Google’s Progressive Web App Checklist is a pretty good way to do that. But when I wanted to transfer this list into our project management tool (we use Taiga), I had to do some annoying copying and pasting. Below you’ll find the list, in an easily copy-able form, as of February 9th, 2017. For reference, here is the full list.

  • Site is served over HTTPS
  • Pages are responsive on tablets & mobile devices
  • The start URL (at least) loads while offline
  • Metadata provided for Add to Home screen
  • First load fast even on 3G
  • Site works cross-browser
  • Page transitions don’t feel like they block on the network
  • Each page has a URL
  • Site’s content is indexed by Google
  • Schema.org metadata is provided where appropriate
  • Social metadata is provided where appropriate
  • Canonical URLs are provided when necessary
  • Pages use the History API
  • Content doesn’t jump as the page loads
  • Pressing back from a detail page retains scroll position on the previous list page
  • When tapped, inputs aren’t obscured by the on screen keyboard
  • Content is easily sharable from standalone or full screen mode
  • Site is responsive across phone, tablet and desktop screen sizes
  • Any app install prompts are not used excessively
  • The Add to Home Screen prompt is intercepted
  • First load very fast even on 3G
  • Site uses cache-first networking
  • Site appropriately informs the user when they’re offline
  • Provide context to the user about how notifications will be used
  • UI encouraging users to turn on Push Notifications must not be overly aggressive.
  • Site dims the screen when permission request is showing
  • Push notifications must be timely, precise and relevant
  • Provides controls to enable and disable notifications
  • User is logged in across devices via Credential Management API
  • User can pay easily via native UI from Payment Request API.

This is only a summary of Google’s checklist, which you’re going to need to understand what anything on this list means. Read it and then come back and copy/paste this list, so you can actually use it as a “Progressive Web App Checklist“. 🙂 And don’t forget to check out Lighthouse to automatically test for many of the items on this list!

Eating your own dog food

No, this post isn’t about man’s best friend or his favourite dishes. Eating your own dog food refers to a company using its own products. Believed to have originated at Microsoft in the 1980s, it’s a colloquialism I’ve always believed in at every place I’ve worked for. It’s not always easily achievable but you need to find a way to use your own product, if you truly want to understand it as consumers do.

It’s easy to get into a bubble and focus only on what you think your product is or what you hope your product will do. Sometimes programmers are assigned a task and they view it purely as a task to be accomplished. I worked at a company previously who was making a Facebook version of their popular web game. Some fellow coders told me how they had never tried the game yet because they didn’t use Facebook. That’s great but we’re making a Facebook game, so you better start using Facebook now. Often I hear arguments about how a feature ought to work, from people who have never themselves used the product and don’t realize that it doesn’t work as they planned it to. That’s why you’ve got to use your own product; you’ve got to be eating your own dog food.

Thus, I came to the conclusion that the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual. The separation of any of these four components would have hurt TeX significantly. If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important. – Donald E. Knuth, The Errors Of TeX”

Making a product you believe in

Perhaps we’re very fortunate at Travel to Live because we’re making a product we really believe in. We hatched the whole idea when we were flying back from one of our many travels. This is a product that, by definition, is one we want to and do use. That’s why when I started planning my Vienna trip, I started planning it on Travel to Live.

You can gain a lot of insight by eating your own dog food. Regular bug testing won’t catch everything because you won’t think of every use case. By using the product naturally, you find those corner cases or you find the places your app breaks down and stops being fun. You think of new ideas for the future. Soon, your bug list has exploded, your wish list has created work for the next ten years, and your understanding of the product has deepened immensely.

Staying focused

It sounds like all upsides but it isn’t. It’s easy to become distracted or to lose focus. Every software developer knows that you can’t implement every dream feature or fix every bug. The first thing I learned when I started working at Electronic Arts is that the typical game ships with hundreds or thousands of bugs. Most of these errors are simple: the user will never see them. But it’s a reality every project manager needs to consider when prioritizing tasks and assigning work.

I’m on day 4 of my trip and I’ve already thought of months worth of work, all of which would derail us from our current plans. Right now, we want to focus on user acquisition and the early experience. As a power user of this site, the things that matter to me aren’t the things that matter to our target users. You can’t lose sight of that. You can’t allow bias to cloud your judgement and change your plans. I would absolutely love to implement a tagging feature right now, to make sorting my Ideas much easier, but it’s not a top priority. It’s going to have to wait a little longer.

The most important thing to do is fill out the bug reports and write down the new user stories. Don’t lose all this valuable data. Issues can be closed and rejected or simply scheduled for the future. You lose nothing by recording these valuable insights.

Eating your own dog food is important at all levels of the company

The most difficult thing is keeping all employees engaged. In a small startup, it’s not so difficult, because the company is made up of a tight group of passionate people. They wouldn’t be working on the project if they weren’t interested. It’s a different story in a larger company, meaning startups need to keep their culture as they grow. As companies grow, they hire people to do a task, not always because they are passionate about the product. It’s important to keep a culture of eating your own dog food in the company because employees may not do it without prompting.

Like many millennials, I believe everybody has something to contribute, at all levels. I believe everybody should feel included. You want the people at the lowest level of the company to be able to raise issues that might be important, issues which the highest levels might find important. If everybody is using the product, you maximize the number of different internal viewpoints on the product, which can only be a good thing. You don’t need to implement everything Joe in QA wants; however, he just might be using the product in a way you never imagined.

Time to eat more

I’ve been writing this article from Cafe Tirolerhof in Vienna, Austria. I’m on vacation but an entrepreneur is never truly on vacation. After all, I’m eating my own dog food every day I’m here. Follow my adventures on my personal blog or view my Vienna trip on Travel to Live! Coming soon: blog integration with your personal profile! Stay tuned for more details.

Google Polymer: Making the Switch

I’ll say up front that I’m a happiness is a boring stack kind of guy, so when Elon came up with the idea to switch to Google Polymer, I was apprehensive. I learned web design somewhere between the years of 1995 and 2005, a time of radical change for web design to be sure, but the ideas were quite different than the world of AngularJS, Material Design, and Web Components. Still, I agreed that we could take a look into it. Elon maintained that Polymer would solve several existing problems we had with the site.

About Google Polymer

If you haven’t heard of it, Google Polymer is an open-source JavaScript project developed by Google. It includes things like simplified creation of custom elements, two-way data binding (more on that later), computed properties, conditional and repeat templates, and gesture events. The Polymer Element Catalog is a library of already created custom elements, many of which you will absolutely be using in any project. You hopefully already know about the newer tags added in HTML5, such as <article> or <header> but with Polymer, you’ll be writing things like <my-cool-custom-input>, with all the functionality hidden away in that custom element. Nifty.

Making the Switch

Maybe you’re still considering making the switch to Polymer and don’t know where to start. With a new project, it’s a lot easier because the shift in code organization and design can be taken from the beginning. If you’re switching and you want to take full advantage of Polymer, you’re going to want to re-write all your code. Let me say that again, because it’s the terrifying truth, you’re going to want to re-write all your code. (but you don’t have to!)

It’s not that bad but in many ways it is. Polymer offers a lot of benefits and saves on a lot of coding but in order to take advantage of them and really drink the Google Polymer Kool-aid, you’re going to have to change the way you’ve been writing your website. We began by converting as little as possible, creating a single-page version of the site, using Polymer’s <app-route>, among other components. Because we wanted to majorly overhaul and redesign the itinerary, we took this as the first component to create.

Getting a basic Google Polymer project up and running was really fast. Getting it to work with our existing code produced a nightmare of Frankenstein code. Introducing any new framework is a pain but what allowed us to get going fast is that once you include the polyfill and Polymer libraries, you can pretty much dive in and get going right away. If you want to get your feet wet and create just one small component to start, you can. You don’t need to switch over to anything like TypeScript, for example.

Polymer uses two-way binding, which basically allows you to keep everything in sync between your components automatically. If the user renames an Event in one interface, it’s automatically updated in the Itinerary, without even writing a single line of code. The problem is, we already stored and updated our data in MapData.js and doing it in the Polymer way would have forced us to rewrite all code everywhere. Our solution was to create the ttl-data-bridge, which bridged our old data system with the new data system. Not very elegant, right? Yes, it was a big source of headaches, confusion, and bugs.

Google Polymer makes it easy to create custom components for your website

Every component is bound and, therefore, kept up-to-date automatically.

Finishing what we started

Eventually, we decided to take the plunge and rewrite all MapData-related code, which was the bulk of, well, everything on the site. Happily some of that rewriting was actually just deleting, as Polymer simplifies a lot of data handling and updating. You don’t need to write show and hide calls all over your code when you can write <my-component hidden$=”[[_calculatedHideMyComponent(hideOrShowProperty)]]”> instead. Where we were updating different UI elements on data change, now the components update themselves with data binding.

My suggestion would be to start much smaller and only replace smaller components. Build up to it and don’t try to bite off more than you can chew. You won’t be able to reap all the benefits of Polymer right away but if you have deadlines to meet, it’ll be your only choice.

There are some real benefits

I just said there were some benefits of Google Polymer but what are they? After the horror story I just described, you might be questioning if it’s still the right way to go. I’ll leave the final decision up to you but consider the benefits.

  • Data-binding is really cool. As already mentioned, data-binding saves you a lot of work by updating your variables automatically for you without any additional code. Write <span>[[name]]</span> in one component and <input value=”{{name::change}}”> in another and you get a text that updates automatically on user input.
  • It forces you to code better. It’s easy to write spaghetti code. We’ve all done it. You want to prototype something or a deadline is fast approaching and the quickest way is just to write and write and write but not really think about the bigger picture. I’ll fix it later, except there never is a later, so you won’t. Well the whole point of Polymer’s custom elements is that these encapsulated elements work on their own or according to their explicitly stated dependencies. Technically, you aren’t forced to do anything but if you follow the design principles of Polymer, your code is going to be easier to maintain, easier to read, and easier to re-use. This is where Polymer truly shines.
  • Conditional and repeat templates are cool. Using dom-if and dom-repeat, you can output your custom elements (or anything) according to the data you provide. In just a few lines of HTML, you can automatically show all the map markers on the map, according to ever-changing data. If the user adds a new Event in the itinerary, thanks to data-binding, your Google Map component will find out about it automatically. From there, the dom-repeat iterates over that data and adds or removes markers as required. With dom-if, you can conditionally include components according to variables or computed functions you provide. Pretty slick.
Google Polymer introduces dom-repeat, making it easy to control what appears on your site

An example from our Google Maps code, showing dom-repeat

It isn’t all roses

The pitfalls of Polymer might be a show-stopper for you. In retrospect, I don’t know if I would have implemented Polymer given the effort it’s taken to convert our codebase. Now that it’s part of the project and the conversion is behind us, I’m quite pleased.

  • Lack of documentation: Polymer’s own documentation can sometimes leave you wanting but we all know the most truly important documentation resides on Stack Overflow. Well, don’t expect much here. Things are so dire that the Polymer Slack channel explicitly asks users to post their questions on Stack Overflow, so as to build up the knowledge base. It’s an unfortunate drawback of any new technology. If you’re a web developer who is used to every problem already having been solved 10 years ago on Stack Overflow, you’re in for a rough ride with Google Polymer.
  • It’s too new: I mentioned the <app-route> component earlier in the article. As of this writing, the first thing that appears on the page is app-route 0.9.3, followed by app-route is still in beta. We expect it will need some changes. We’re counting on your feedback! Wait – what?! This is Polymer 1.0, right? That’s not what I want to read on the documentation for a component that is at the foundation of my app! There’s a reason why people still  use old versions of PHP or tried and true programming languages like C++. When using Polymer, be prepared for a cutting-edge but bumpy ride.
  • Browser support: Google is promoting their version of Web Components here and not everybody is on board yet with all of it. The end result is that Polymer is slower in Firefox and performs the best in, you guessed it, Google Chrome. When 53% of mobile users abandon a slow site, this is no laughing matter. And it better be okay to abandon older browsers. Before Polymer, we sometimes tested the site in the abandoned Windows version of Safari. Now it doesn’t load at all. Cutting off support for older browsers could be a deal breaker for your business.

Polymer is a work in progress but it's come a long way

The good thing is that the Polymer community will solve all these problems problems in time. Documentation is growing, programmers are writing articles and asking questions, Polymer 2.0 is on the way, and all browser vendors have already or plan soon to implement the necessary technologies. I expect 2017 to look very different and much brighter for Google Polymer.

Lessons learned

Earlier, I praised data binding but there’s a difference between that and two-way binding. Polymer gives you the option of one-way and two-way data binding, the obvious difference being that the latter also sends changes back up the chain. We got so excited about data binding that we used it everywhere, all the time. This turned out to be a mistake, leading to unexplained or unwanted behaviour and triggering of events. Make sure to reserve any sort of data binding only for when you legitimately need it. Only use it when you have considered what the immediate communication of all data changes might do to your component.

As I said, Polymer is a big shift in thinking when it comes to the technical design of your website. There’s a learning curve and we made our share of avoidable mistakes, had we only understood a particular component’s functionality better. Don’t bite off more than you can chew at once and feel free to introduce Polymer into your project slowly. Although you will want to go full Polymerization, as we have taken to calling it, the beauty of Polymer is you can include as little as one simple custom element, if you so choose.

We hope to continue to share our experiences with Polymer with you as we continue development of Travel to Live. Ask more about our experiences in the comments below!

© 2017 Travel to Live Blog

Theme by Anders NorenUp ↑