Responsive Design (again)
This may seem a bit “last year”, but the challenges we face with responsive design have not gotten any easier. Not only do we have to deal with desktops, laptops and tablets and screen readers, but the growth of mobile and wearable technology means that more and more we need to be aware of just how our users will engage with our products.
This is complex enough when you’re just building a website, but it becomes significantly more challenging when you’re developing applications. Smaller screens mean showing differing amounts of information, or perhaps in a different way. This is nothing new of course, but when many websites actually see more traffic from mobiles than desktops, the priority on these designs is starting to be flipped on its head.
But of course, more form factors doesn’t just mean smaller interfaces, it means different ways to interact with an application. Keyboard and mouse may still be king, but when your application could be also be used with a single finger on a 4″ screen, multiple fingers on a tablet, or even a controller on a game console, there’s a lot more to consider. When you add in the plethora of smart watches with digital “crowns”, tablets with Pens and even voice or “gesture” control, there are ever more different ways to interact with an application. What works for one, probably doesn’t work for the others.
The Componentization of the Web
Material design is one such tool that many developers and designers are choosing to help make a consistent experience across devices. Material design is a set of design principles for components that provide a “unified experience across platforms and device sizes”. Put simply, whether you’re using a mouse on a desktop, or your finger on a phone, the experience should be obvious and consistent.
Material design implementations such as Polymer and frameworks like Foundation and Bootstrap now go a step further than the responsive design tools or UI frameworks of recent years. The objective now is not just to help you create a nice layout that looks good on mobile, but to ensure that the entire application experience is consistent across various types of interfaces. It’s also done in a way which allows the developer to lean on a set of rules and implementations and focus on the logic behind their interface.
The great thing about this componentization, is that common design patterns are starting to emerge which make all applications, regardless of framework or device, operate in a similar way. It means that every application doesn’t have its own special kind of menu, or its own special toggle button. Most importantly, however, it allows developers to ensure their own applications are consistent… which in the past was a bigger challenge than it sounds.
React JS
Facebook’s React library builds on the componentization concept and takes it a whole step further. React endeavours to abstract a lot of complex browser behaviour and data handling, and allows the developer to focus on interaction. By creating components which defer rendering to React’s virtual DOM, and promoting patterns like stateless components and one-way data flow, React gives developers the ability to create applications in a way which reduces complexity and increases performance (two things which are often competing objectives).
If you’ve used libraries like JQuery, Ember or Angular, React can be a bit of tough nut to crack. When you’re used to being able to just manipulate HTML any way you please, it can be a frustrating transition learning to give that up. React requires you to simply manage the state of your application, and how components should react to that state. It takes care of the rest for you, and that can be a little frightening.
React itself is only one part of a huge set of tools created by the Facebook team. There’s also React Native, Relay, Flow, GraphQL and Flux… the list goes on. When you look at the broader community, and the amazing frameworks, tools and libraries popping up every day, it’s pretty amazing. Of course, many developers will dismiss React as “flavour of the month”, and that’s a fair criticism. It’s not right for everybody, and not right for every application, but it’s well worth taking a half day to understand the benefits.
Modern CSS
Plenty of smarter people than I have written about this, and I encourage you to go and read every one of their posts (many of which are from our home here in Melbourne). The world of CSS is going through something of an upheaval at the moment, and there are many wide and varied opinions flying left and right about where we’re headed and whether it’s good, bad or ugly. The exciting thing for me, is that anything is happening at all. As a developer having built my first website in 1995, CSS has always been the bane of my existence.
At the root of the movement is that CSS was a programming language (yes, it is) developed to style documents on the world wide web. It was designed to specify a style for a page and, where needed, allow a developer to override certain styles in exceptional cases. In an ideal world, every page on your site would use a handful of styles, and that would be that.
Once we started using HTML to build apps instead of just documents, things started going a little pear-shaped. Where once you wanted to be able to dictate a style globally, we now want to be able to consider components self contained pieces of logic. The rules of encapsulation dictate that we can ask a component do something for us, but we can’t force it to. Traditional CSS doesn’t care for encapsulation, it’s all global variables fighting over degrees of specificity to determine what you get out the other end.
Efforts now abound to create new ways of treating CSS within applications, and while the debate still rages, a great degree of progress is being made improving how we work with styles in our applications.
Containers
Deploying web apps has always been a bit of a mixed bag of technologies. It used to be that you’d literally just FTP up some HTML to a *nix box and your job was done. But with the prevalence of third party libraries (like React, Bootstrap, Ember, Angular etc) plus the dozens of packages that your app may rely on (whether included via npm or webpack or whatever) combined with compiled CSS (sass, less, css modules), deploying a web app is no longer simply a matter of pushing “upload” on a few files. All of these things need to be compiled, minimized and mashed together as efficiently as possible. But that’s not only the case for shipping to production, you have to jump through the same hurdles any time you have a new developer joins the team, or if someone gets a new machine, or even if you just want to set up a test environment.
That’s where containers come in. Solutions like Docker simplify the deployment process by packaging up your binaries, assets and dependencies and installing them in an isolated host process on top of the Docker engine. Unlike with a VM, this container can be deployed anywhere on any operating system and will always work exactly the same way. Everything the app needs is packaged together and that means it will always be consistent whether it be in development, testing, staging or production.
So that’s our five. How did we do? Is there anything you think we’ve missed, or things here you disagree/agree with us with? Make your voice heard by hitting us up on the comment section below!
