Dion Almaer

Software, Development, Products

Archives for May 2016

Stop painting and have a Meaningful Interaction with me!

Leave a Comment


When it comes to performance, what do we measure? Our focus has changed over time as we get more of an understanding on the importance of perceived performance vs. some absolute “the bytes came down in X seconds and the view rendered in Y”.

We had a lot of performance related talks at Google I/O, and it was fun to see some of this evolution. There are a series of tricks at play, where you keep the user engaged by showing them progress versus a binary blank view becoming fully available and interactive:

  • As developers we know that loading indicators are lies, but some of our users still buy them
  • We can get something painted ASAP (e.g. a shell) and then spinner until other content shows up
  • We can show fake UI component holders that are then filled in later
  • We can show snapshots of past content (sometimes literally a prior screenshot) and replace when new data comes in
  • We can show the visible content in the viewport and lazily load below the fold (AMP does this and much much more… learn what they do here and how they prerender)
  • We can load tiny images scaled up, and then replace the full images when downloaded (e.g. what Medium does with its images).

There are a lot of tools such as these to give us some slight of hand, and they work especially well when we can progress through the stages. I find that they tend to break down the most when there is a huge delay in one step: e.g. the shell loaded pretty quickly but most of the page is a huge spinner going on and on and you can’t trust if anything is happening.

Recently, we spent a lot of time measuring the time to first paint, which is often great, but it can cause you to trick yourself into thinking you have done a great job when all you have done is sped up one step, and you could have actually slowed the illusion and done harm.

Paul Lewis shared a visualization of how various approaches can differ here:

This brings us to the new topic of the day: Time to First Meaningful Interaction.

Alex talks about the “time to interactive” measure at length in a fantastic talk, and it is a key subset.

Search for meaningful interaction, and you will see links to a lot of therapy and tips for how to communicate with others. Compared to first paint it is much vaguer and requires you to think through the details of each view and what interactions are meaningful. They may differ based on the type of user, or where they are coming from in a flow, or the time of year. This is the type of thinking that you go through when you are building your UX, not just your performance. It is strategic as well as tactical.

The answers to these questions may change your approach to how you deliver a given view or application.

For example, in a transactional system that doesn’t have a lot of content to consume, you will very much want to wire up application so the user can click that button asap, and you will wait to minimize the time between “I see the button that I need to click on!” and “Why doesn’t it do anything when I tap on it?”

On the other hand, if you have a content heavy site where a user will want to spend some time taking everything in before their next interaction with the application itself, then you will be rushing to paint valuable content and allow them to scroll around to read that content. The actions and other items can lazily load much later.

Often there will be a mix and match. When you get to a product page on an e-commerce application you can quickly load information such as description and price, and load other info later such as reviews and secondary details (dimensions etc).

The right choice here will be the difference between frustration and showing the right level of progress so the user can keep in some sort of flow in your experience.

This is why I am excited for us to search for meaning, rather than blindly rush to paint, and how the Web now has the capabilities to deliver reliable resilient performance.

Ruby isn’t the only gem

Leave a Comment

… and that’s OK.

I overheard someone talking about how Ruby has “failed to have the impact that it could have had”. I leaned in further when I heard that, and he continued to talk about how Ruby was set to jump and and be The Next Java, mainly thanks to Rails.

I think that Ruby and Rails have had a massive impact if you widen the lens of what “impact” means. If you look at its impact by connecting it to the number of lines of code of ruby out there (which would be ironic in the case of ruby), or the number of developers using it, then I can see how you come to the wrong conclusion.

I prefer to look at the impact across the computing landscape.

My brain has always connected to Ruby in a way that it never did with Java. It feels right-er to me, and I enjoy programming with it so much more. Rails came along and filled a need to develop CRUD based web apps in an opinionated way that was a breath of fresh air to many PHPers and Java practitioners alike. It did that thing well.

Ruby was particularly well suited to this opinionated approach, but the concepts behind Rails were adaptable to many other systems and programming languages, and we saw that. PHP developers looked to take some of the ideas via frameworks such as Symfony and Zend Framework. The same could be said for many other languages that people were using for the Web. Rails, and Ruby, has helped the evolution of all web frameworks from there…. even if they made very different choices, they thought about those choices differently due to Rails.

Ecosystems, not Languages

Right as Rails was getting bigger there was a shift in the force with mobile, and it turns out that ecosystems have a huge say in which languages are used.

JavaScript is as large of a player as it is due to the browser, and the fact that JavaScript is the only *first class* programming language allowed, and the Web platform APIs are designed with that in mind.

Objective-C developers had the shock of their lives when they went from “crap how do we make money?” to the clouds raining it down thanks to iOS. The language that Android was optimized for kept that world strong, working with Java on the backend.

Our backend needs also changed a lot again. We weren’t mainly interested in shooting out HTML, but instead we were focused on APIs and the push to microservices and network servers enabled much more freedom to choose solutions such as go and node.

Ruby didn’t come along and own the market. The VC’s that wanted to find Ruby or Rails Inc didn’t get exactly what they wanted, but please don’t underestimate the role that Ruby and Rails have, and will continue to play.

It may not be the only gem on the planet, but I like diversity and it would be a sad state of affairs if it was.

The Ideal Web Experience

Leave a Comment

When you name something you need to define it. Once you do that it is natural to have the definition poked at, and you run examples through those definitions. “What is different between a cat and a dog?”.

I am seeing some robust discussions about progressive web apps. What makes foo.com a progressive web app? What if it didn’t have this feature or that feature?

You tend to start with the definition, which leads you to Alex Russell’s original post and look through the attributes of a progressive web app:

  • Responsive: to fit any form factor
  • Connectivity independent: Progressively-enhanced with Service Workers to let them work offline
  • App-like-interactions: Adopt a Shell + Content application model to create appy navigations & interactions
  • Fresh: Transparently always up-to-date thanks to the Service Worker update process
  • Safe: Served via TLS (a Service Worker requirement) to prevent snooping
  • Discoverable: Are identifiable as “applications” thanks to W3C Manifests and Service Worker registration scope allowing search engines to find them
  • Re-engageable: Can access the re-engagement UIs of the OS; e.g. Push Notifications
  • Installable: to the home screen through browser-provided prompts, allowing users to “keep” apps they find most useful without the hassle of an app store
  • Linkable: meaning they’re zero-friction, zero-install, and easy to share. The social power of URLs matters.

It is more important to look at the motivation and the outcomes that you are really looking for though.

I will talk a lil about the past, and then talk about the journey from about:blank to what I think would be the Ideal Web Experience.

AJAX to Ajax

When Ajax first came along it was talked about as an acronym, but we quickly saw that this wasn’t what we actually meant:

  • If you used JSON instead of XML do I have an Ajax app?
  • The killer feature of Google Maps was the panning and loading of tiles, which wasn’t about Ajax

What mattered was that we had enough tools to deliver a great desktop web experience, and that people were on the journey to build these. And, it was a journey. People talked about the various states of ajax adoption, and often the path was ugly.

We had to deal with legacy systems and you would often see a app.foo.com approach until that experience could eat http://www.foo.com. We also see the regression of behavior, when people would focus on the new shiny and leave behind some of the great features of the web (accessibility, progressive enhancement, etc). Evolution is messy, but many got through to the other side.

We are starting the same journey again. This time around we are dealing with constrained mobile devices and networks, and new great capabilities due to sensors and context. The browsers had to quickly optimize themselves for this new world. We are seeing some early success stories where we finally see proof that this is worthwhile, for users and businesses.

The Journey

It has helped me to think about the Web experiences that I look forward too. Those that reach the ideal. What do they look like?

  • They are predictably fast (all across RAIL, all the time, all devices, via any deep link entry point)
  • They are secure (https all the things, CORS, CSP)
  • They are accessible (everyone in the world can experience them)
  • They have low friction (if I want to get to one from my home screen I can. If I want to easily pay without filling out forms AGAIN I can. If I want to be notified to re-engage, I can, …. etc etc)
  • They are resilient (shit happens, they deal with it)
  • They are adaptable (responsive across the board, from screens to inputs to context)
  • They are progressive (they are always the best they can be given the constraints of their environment. no lowest common denominator, they keep getting better and better and they use ever capabilities that makes sense)

Now, let’s get back to reality from my idealistic view, and put the “is it a progressive web app if….” questions to the test.

These answers are my opinionated ones:

My experience is kinda slow, but it has all of the cool new features, is that good enough?
No. Performance on mobile at the center of this. Sorry.

If you deliver an experience that focuses on mobile is that a PWA? Yes. It is far from ideal though. We cracked the progressive nut and it is a huge advantage of the Web, so please keep going on the journey! Other form factors such as desktop and tablets are still huge, and I often see some a-ha moments when talking about how you can use a feature such as push to reach your users on the desktop!

If your experience only works with service workers is it a PWA?
No. Come on, Service Workers are designed to be progressive enhancement, please don’t mess with that!

If your experience only works on Chrome is it a PWA?
No. We went through the “best viewed on X” era. It’s not good enough. I know that all of the browsers aren’t fully shipping everything yet but they are doing pretty well. Being a Web developer means that you write to the platform across implementations

If you don’t want to hide the URL bar is it not a PWA?
No. This can be a choice. The important part is that you have the possibility to go full screen / immersive.

If you don’t support $BROWSER yet is it a PWA?
Yes. Flipkart went down this path. While I would have loved for them to ship to more browsers, they decided to ship earlier and iterate and the important point is that they HAVE kept going on the journey and they now support browsers such as Safari and UC Browser

Is it OK to ship pwa.foo.com first?
It’s your choice! If that is the best way to ship and learn, go ahead. Just please keep going and reach for the ideal of One URL across desktop, mobile, etc etc.

Is it OK to ship on http?
Nope, sorry. Safety is too important. I know that it takes effort to get over to HTTPS but it has never been easier, so get on that journey

Is it OK to not be that accessible?
No. I know it takes effort here too, but it is much easier to start with accessibility in mind (and security, and performance) so try to get that habit going.

Is it OK to require JavaScript?
This is another type of “accessibility”. It’s business importance may differ depending on the demographic and what you are building, but…. remember the BILLIONS of people coming online that use browsers such as Opera Mini? This is an age old debate that will come and go, but the context is important.

What if I don’t support Add To Homescreen?
Really? Is that so much work? I get it…. this isn’t the part that MAKES it a PWA, but why not allow that option for your users?

What if I don’t use push notifications?
If there isn’t a valid use case for you or your users, then THANK YOU for not needlessly sending push messages.

What if I am building “websites” not “webapps”
All good! Just don’t ignore the capabilities that can make the website fantastic.

What if I don’t have an app shell architecture?
All good! That is just one option than people are exploring, especially for certain types of experiences.

For me when I go through this thinking, I land right where I was back in the days of Ajax. I want the browsers, frameworks, and developers to be pushing each other in the right direction, evolving so that we can deliver amazing web experiences.

We aren’t yet at the ideal web experience, but I think that we are at least poised better with the technology and thinking around progressive web apps. It is all well and good to expect every development team behind a website to be craftsmen with infinite time to build the perfect experience, but the world isn’t like that. There are a slew of problems, a ton of legacy, and piles of work to do. All we can hope for is that this work is prioritized.

The PWA term itself is also useful as it was with Ajax. It gives you something to talk about with your clients, or with your business partner.

“We really need to prioritize some of these new capabilities, have you seen the results companies are getting? And the types of experiences? There may be some tech debt to pay off as we get the foundations cleaned up, but now is the time.”

Chances are you may be a lil sick of the term already. That’s OK…. but it has its uses.

We are right in the middle of some messy evolution, but I am so excited with the direction and enjoy working with the chaotic and passionate web community to keep on trucking.

The right thing to do, is the right thing to do.