13 Jan

Full Mobile Throttle

tl;dr: Being put on “lowered priority to access your network” aka throttling makes for a pretty sad experience of browsing and using the web. Unless there aren’t any images involved, which hardly is the case. And it’s everybody’s job to try to make this better.

During December a WebRTC video chat sucked up the my remaining 7Gb of my data plan and reached the ‘fair usage data threshold’ and thus the provider ‘lowered my priority to access the network’. I’m not quite sure why they name it like this, but since pictures speak a thousand words, here’s a screenshot of what the mystic term ‘lowered priority to access the network’ actually means:

Speedtest Screenshot

To translate the above download speeds to some reference points:

0.02 mbps = 20 kbps
0.15 mbps = 150 kbps

GPRS: 60 kbps
Edge, good connectivity: 250 kbps
3G, good connectivity: 850 kbps
DSL: 2 mbps
Cable Modem: 6 mbps

From the above screenshot we can see: Download speed is very slow, somewhere in between GPRS and EDGE for most of the time. December 16th was the day I got throttled, the readings above show the connection speeds I usually get to enjoy.

So out of curiosity about how this actually affects real-life usage and browsing experience, I ran some tests on a few sites, since as you probably can imagine, took quite some time to load.

This shall not be a comparison between sites saying one is better than another, they all have different requirements, serve different content and so on. It’s more to be seen as a showcase about what happens to your browsing when you’re throttled like this.

I picked sites that have somewhat a reputation for caring about performance, might be part of your daily use just by random choice.

These sites have all been tested with their ‘desktop’ versions with a MacBook Air late 2011 tethered to my throttled phone data connection. I wanted to actually try it from the mobile, but couldn’t get the iOS Remote Proxy to work properly. In this case, load times have been calculated from window.chrome.loadTimes() in Chrome. Furthermore, all sites have been tested from Hong Kong, which might slightly slow things down, since I believe sites to be faster from Europe or even within the US, because I can see a difference quite frequently.

I was mainly interested in how long it takes until you get to actually see something on screen and can start reading, rather than the full load times. Unfortunately for some of the tests firstPaintTime and/or finishLoadTime wasn’t recorded correctly which I didn’t notice at that time and thus aren’t available. I wanted to recreate the conditions by throttling the connection with Network Link Conditioner, but I somehow feel it doesn’t create the exact same conditions.

Here are the results from the sites I have correct data from. Unfortunately it’s also only one recorded result each, but I’m intrigued to go into throttle mode once again to make these tests more extensive. As I said before, these values should rather be seen as approximate, since depending on the throttled network, results might vary over the course of a day.

time to first paint: 1.09s
total load time: n/a
time to first paint: 6.74s
total load time: n/a
time to first paint: n/a
total load time: 49.08
time to first paint: 12.30s
time to first paint: 4.91s
total load time: 4.91s
time to first paint: 24.76s
total load time: 146.21
time to first paint: n/a
total load time: 124.91
time to first paint: 14.44s
total load time: 70.72
time to first paint: 29.35s
total load time: 332.75
time to first paint: 30.36s
total load time: 146.52s

The one thing I noticed was that smashingmagazine.com was blazingly fast for every time I loaded it and that was so much faster than any other site. Remarkable job and well done :) For all others, and there have been some sites I just tried or even while surfing around while throttled, the web can turn into quite a painful thing unless there are no images involved; which is quite a rare case.

The throttling might be just an edge case, but it’s great to see if things work ok-ish under these conditions, because then it’s probably a great (or rather fast) experience when you’re on a fast connection. I’m glad to see so many people out there working hard on improving site performances and developing better performance tooling. But in the end it’s all of us who have to make a lot of smart and educated decisions about when to load what and how much of it, so we can improve not only our, but every user’s life. Because not everyone has the privilege of being on a broadband connection every single day. Yet.

03 Jan

To A Happy & More Secure 2015!

A happy, healthy and also more secure year to you, dear reader!
I generally don’t do any new years resolutions, but of course there are things that need to get done at some point. I’ve been planning to update this site for quite some time, so the quiet start of the year is a good time to do that. Or at least starting somewhere, since this will probably be more of a step by step process over some time.

One thing I’ve been planning was to get a SSL certificate to serve the pages via a secure connection. There’s been a few articles on that in the recent time and I also wanted to find out how much of an impact on performance it had. If you’re interested to find out more about the why and how of serving pages via SSL, have a look at this question on Quora and this document from Google.

I started off with a SSL certificate from my hosting provider, but after setting it up and testing it only achieved an overall rating of B with issues that could only be resolved on the server, which in this case isn’t possible for me to do. Since I was looking into setting up a CDN as well, I now went with Cloudflare as the CDN and also use their SSL certificate, which in the end was much easier to install and rates with an overall A.

So far everything seems to work very well and I can’t notice any big difference in performance. SSL negotiation seems to slightly increase the wait for a first response, but overall it doesn’t affect the load times much. So far I can’t really say if the use of a CDN makes asset loading faster in turn, but this will show over time I suppose.
Have a good start into the new year and happy secure browsing!

31 Dec

Missed in HKG

A while ago I started working on a new side project called “Missed in HKG” with the main purpose to polish up my rusty JavaScript skills.

Here goes the back story: Many years ago I used to live in San Francisco and by that time, was a frequent reader of the two city magazines, the San Francisco Bay Guardian and SF Weekly. I can’t remember which one or if both, but there was a popular section called “Missed Connections”, which always was a fun read.

Earlier this year I came across an article on Medium called “Missed Connections – Why I read the classifieds (and why you should too).”. I read it and it reminded me very much about my time in the US and how I frequently scanned these classifieds in various coffeeshops.

It also reminded me that I was looking for a good idea to build a side project around, a project with a purpose and an oversee able scope so it wouldn’t be too much work, because these things might never get finished in the end. It required to have all the functionality that I was interested in trying out and was basic enough to not eat up too much time. Building a ‘missed connections’ site seemed like the perfect scope and a fun idea.

I started to look for what else was out there and besides probably the most well known missed connections on Craigslist I didn’t find much else and have to say, not one of the sites I found seemed any good. Design-wise it almost felt like a little time travel back to the early 2000’s and back then and for obvious reasons none of them would display nicely on mobile. To me displaying ‘ok’ and thus being usable on a mobile phone is the minimum requirement for such an app. To fill that gap and to provide a prettier, better and faster mobile alternative was kind of a no-brainer and my new side project was born.

I talked to a friend of mine about what I wanted to do and he agreed it was a fun little project to work on and offered his help to build a proper backend and API for it. This was a huge improvement to the whole project and we started working on it.

To make a long story short, the site was built and has been finished for some time now, only getting some minor tweaks and improvements here and there.

So far we never officially announced it, since there was always something more important to do. To not carry one more to-do over into 2015, consider this the launch announcement for “Missed in HKG”, our own version of Missed Connections for Hong Kong.

Give it a go at missedin-hkg.com and spread the word ;)

03 Dec

Harbour Front Monthly #4

Time flies and it’s almost the end of the year… Still we have planned the 4th edition of Harbour Front Monthly to send you off into the new year with some more practical take aways. This time our speaker Kristin Low will focus on learning UX by doing UX.

How do you learn UX? As a teacher of UX, I’m often tasked with helping to impart a designer-ly view of the world into the mind of students. Although each student learns differently, one common factor applies to all students: learning by applying.

The event will take place on Wednesday, December 17th in our usual location at the Hive in Wan Chai. You can register here and we’d love to see you there.

18 Nov

The Difficult Has Become Too Easy

I just read this post by Jonathan Stark called ‘Mobile Last?’ about his experience at the Rails Rumble hackathon and having come across the same assumptions from various people on a frequent basis, I wanted to write down a few thoughts on it.

In case you haven’t read the article yet, you should really do so, but here’s the quick gist:

The Rails Rumble is a distributed programming competition where hundreds of teams from all over the world have 48 hours to build an innovative web application.
However, there’s one thing that really sticks in my craw: only one of the top ten winning entries was even a little bit mobile friendly. That’s right… 90% of the entries were virtually unusable on even the most modern smartphone. My reaction to this ranged from shock to frustration to sadness.

As I have mentioned, I hear the point of building mobile-first (or even) responsive in general being more work quite often. I find this being the same sort of myth as saying that responsive sites can’t be fast (they can!). It always depends on how you do it and what you’re after. There’s no question that responsive websites can be a lot of work, depending on the level of detail you want to put into it. But for now that’s not the point.

What I have noticed over the last years, is that web design in general has become a lot harder and as we know, especially building responsive sites can be a very daunting task. At the same time, building websites has nowadays become very easy. Maybe too easy.
Today, we have a lot of tools on hand, that make building websites easier. Frameworks and plugins make building websites so easy, people have to think less about what they are doing. The web has become a plug-and-play playground. Are we losing our craft to build for the web?

By doing it this way, understanding underlying paradigms, languages and technologies isn’t mandatory anymore and I believe that this might be part of the problem. Don’t get me wrong, I believe that it’s great that everyone can create for the web. But as developers, we should know our tools, as much inside out as possible. Many people advertise their sites as being responsive; in reality they are just plugged together by using different frameworks which are spitting out 3 different fixed-width screen size layouts that adapt for the assumed ‘most common’ screen sizes. I’m not arguing that adaptive design is wrong, but you need to first know the rules before you can break them – meaning to understand what’s right for you.

To get back on the topic of building mobile-first and why it is considered so much more work: only practice makes ‘perfect’.
The more you do it, the better you get at it. The more you get used to the underlying thinking, understanding and applying the processes involved in doing things mobile-first over and over, you will gain experience and at some point it will all feel normal to you. And this is when you’ll start to agree that building mobile-first isn’t that much harder than you might initially have thought.

No single framework can teach you how to build great sites, you only learn and become better by understanding the basic skills and concepts first, there’s no fast-forward. When you have this down, you can control the tools and not let the tools control you. Once you’re in control, you’ll be faster to apply and work with these techniques & tools and will find building mobile-first responsive sites just comes natural to you.

03 Nov

Harbour Front HK Monthly #3 (and #3.5)

The next Harbour Front Monthly event is coming up and because it’s during StartmeupweekHK we’re running two events in a row this time.

The first event will take place on Tuesday, November 11, 2014 from 7:00pm to 9:00pm at the Hive in Wan Chai. We will feature 2 speakers with a ~30 minute talk each, covering web design topics in a practical approach for greatest take-aways.

Our second event will be held on Thursday, November 13, 2014 from 7:00pm to 9:00pm and is also hosted at the Hive in Wan Chai. What’s on? A workshop, the ‘Big Front End Quiz’ or something else, we won’t tell, yet.

Come and join us for two fun evenings with drinks and a little banter afterwards, all for free. You can register via Eventbrite here.

02 Nov

Escaping an Issue with Grunt ‘string-replace’

Since I started using Grunt, I have found more and more cases where Grunt tasks turn out to be very useful and a huge timesaver. That is, timesaver once you got whatever you’re trying to do up and running. In the most recent case, I ran into an issue with using Grunt string-replace to replace background-image URLs in my CSS file with a different path to prepare them for use with Rails’ asset pipeline.

I needed to search for : url(img/imagename) to then be replaced with : url(<%= asset_path 'img/imagename' %>).

As the first replacement pattern I used ':$1url(<%= asset_path \'$2$3\' %>)’. This failed with an error message. Since I was using the < & > characters in the pattern, I figured these characters might need to be escaped.

I tried ':$1url(\<%= asset_path \'$2$3\' %\>)’ and various variations, all without any luck. Eventually I found a hint on Stack Overflow, that this might not work this way at all and needs to be processed with two passes.

After checking back with the author of string-replace, this problem seems to be related to Lo-Dash‘s template security.

The final working code looks like this now and works pretty much as well as it would with running it in one pass, I believe.

'string-replace': {
  inline: {
    files: {
      'dist/css/app.css.erb': ['css/app.css'],
    options: {
      replacements: [{
        pattern: /:(\s*)url\((img)(.+?)\)/ig,
        replacement: ':$1url(\<%= asset_path \'$2$3\' CLOSETAG)'
        pattern: /CLOSETAG/g,
        replacement: '%>'