As I reflect on 2016, one of the highlights was working with companies who were reinvesting in the Web. I got to hear a lot of stories about their business and their technology stacks as they wrestled through how to get from here to there. It is one thing to understand that there are exciting new capabilities, but the reality is that websites are at varied stages of evolutions and there are practical constraints to work through.
You can look at this in a negative way, but you can also recognize that this is often a good problem to have. Dealing with a legacy system that runs a substantial business is a good problem indeed. It is vital to take care as you change a ship that is on an important journey, but fortunately the Web is very well suited to the job. Thanks to the loose architecture of URLs coupled with the fact that you can ship down code at will means that the logical representation of the business is very much abstracted from the physical.
Evolving your experience is similar to evolving your codebase. You make many choices that have trade offs. For example, at companies such as Google they have often taken an interesting approach of keeping One Large Codebase where everyone works as close to master as possible. What happens if you are are all evolving the same codebase together? It means that if you fix a bug in your SSL library it can be rolled out to all of your services in record time. It also means that you need to be vigilant at keeping up to date all the time, with is definitely a tax, especially if you don’t have tools to handle this.
In general it is good practice to have a strong master. I often look at the source tree and map it to a real tree. You want a strong trunk that is always growing enough to handle the branches that come off of it. You don’t want the opposite, a weak trunk with heavy branches that eventually makes the tree fall over.
How do you keep complexity down, and try to make sure that person A isn’t causing problems for person B in another part of the codebase?
One solution is small modules that can be easily composed. We see this in areas such as UNIX, node, and React. The key is the composition of the pieces, which is different to separate units that can’t be reused. Composition not solely isolation.
Native has been around long enough now that all of this has come up too. How do you handle a large codebase? What about once you have multiple apps? What do you want to share between them? There are many techniques to help here, but none are quite as flexible as the URL + Web delivery.
Speaking of which, let’s get back to evolving your Web app in 2017
After talking to many developers and companies, three patterns emerged for the journey, and I will force them into the same acronym as the latest Web revolution itself, just to be confusing:
Piece
Take one user journey, or sub-site, and make it a PWA. For example, Air Berlin did this by creating a post-purchase experience that keeps your boarding pass offline and ready for you. This then feels like a mini app, akin to early mobile apps that focus on one use case and do a good job. One of the under-explored areas of PWAs is the fact that you can mint them in any way that makes sense for your service. For example, HBO could have an overarching app for their service, but you could also choose to just have a launcher into a particular show, all in a natural way that doesn’t need multiple entries in a store if not desired.
Whole
You could take on the whole enchilada. This is ideal if you are looking to do a re-think of your experience any way. Let’s say that you haven’t done that responsive design re-do yet and have separate “mobile” and “desktop” sites? Maybe you were thinking about trying one of those shiny new frameworks that you were hearing about? Maybe your product and design team were feeling the itch anyway? Well, the water has never been warmer. If you have the buy off from the business to do this you can look at rolling out a spanking clean, offline first, super fast reliable experience that works progressively. You lucky pup!
API
Maybe there is a particular new capability that would be impactful for your business. A PM comes running in with a glint in their eye as they tell you how fantastic it would be to bump up re-engagement via push notifications. This is exactly where The Weather Channel started their journey. Once you get the infrastructure in place (e.g. make sure to get onto https) you can add a feature like push without large changes to the web app.
There are many ways to skin the cat, to start your journey to an ideal web experience, and as always, the key is to get started.
Leave a Reply