Feeling Like An Unwelcome Guest on medium.com

I have a shortcut to medium.com on the home screen of my Android phone. It’s there because I browsed the site a couple of times and Chrome’s app install banners prompted me to add it to my home screen, so I did. Some time later I launched the site from the shortcut icon and it opened and loaded so quickly that I actually thought it had retrieved a copy from an offline cache. But it hadn’t, it was just very well optimised. So ten points to the Medium team for that.

Today I launched the site from the shortcut again – but this time the experience was somewhat different. So different that I have to take away all the points I previously awarded to the team. The problem is that when I launched the site today, I had the door emphatically slammed in my face.

Read the full article


Mobile Browsing Around The World

I find it fascinating to see the variance in browser use in the diverse regions of the world, and nowhere is that variance more apparent than in mobile web browsers. While in the West we may be used to Chrome and Safari being more or less the only game in town, elsewhere in the world the story is quite different. In this article I’m going to take a look at a few charts which illustrate that difference.

The stats used here are collected from the 30 days prior to 25th August, taken from StatCounter.com. They come with the usual disclaimer about the impossibility of getting completely accurate data, and don’t always include feature phone browsers, so should therefore be treated as indicative rather than conclusive. With the caveats out of the way, let’s begin.

Read the full article


Exploring URL discovery with the Physical Web

One of the emerging concepts that I’m fascinated and excited by is the Physical Web. If you haven’t heard of this, a brief and very coarse summary is that it’s the idea of transmitting URLs from beacon devices, commonly using low-energy Bluetooth (BLE). Current beacon schemes are largely based on Apple’s iBeacon protocol, which transmits a unique ID that requires an app receiver to decode and turn into an action. The Physical Web’s difference is that URL transmission requires no app, decentralising the process.

Making any device able to transmit a URL is rich with possibilities: from super low-friction discoverability of information about nearby places (imagine a page of search results showing only the things immediately around you), to immediate interaction with nearby physical objects. While I’ve still yet to actually build anything using the Physical Web idea, I’ve started to explore what I think it can be useful for.

Read the full article


Hardware APIs coming to browsers

There are many future web stack features that I see as being vitally important to the long-term health of the web. These include extensible web projects such as web components and CSS Houdini, as well as the scripting capabilities in ES7 and beyond. These features give developers better tools, and more fine control and power.

But I feel that what’s more important to the immediate success of the web are features that provide parity with native mobile apps. I’ve written previously about the importance of service workers in providing this parity, but there are also a few new features breaking through that I’m equally excited about, as they provide access to previously unavailable hardware.

Read the full article


Eddystone — A Briefing Note on Google’s New Beacon Format

Yesterday Google announced ‘Eddystone’, a new open Bluetooth beacon format which works on Android and iOS. I’ve been doing a bit of reading about it to understand the technology and its potential, and I put together a briefing note about it for my colleagues. I’m a believer in maximising returns on my content, so it seems like a good opportunity to republish that briefing note here.

This is a very rapid and shallow look into beacons, and I’ve no doubt made some omissions or inaccuracies, so apologies in advance for that. If you think I’ve made any huge oversights or errors, please feel free to let me know in the comments.

Read the full article


The drawbacks of post-processing

In the last few days I’ve been investigating CSS post-processing, the idea behind which – writing stylesheets using partially implemented or emerging standards, which are then transpiled to make files which work in current browsers — is more pleasing to me than the abstractions of pre-processors like Sass. I’ve been experimenting with PostCSS (or rather, cssnext, which is to PostCSS as (broadly) Bourbon is to Sass); however, there are a couple of problems with post-processing, at least in the way that PostCSS approaches it, which makes me question its utitility.

NB I must state clearly that these observations are based on a very shallow understanding from my initial investigations of how PostCSS works, and perhaps they would be clarified and resolved if I tried to use it on a full project. Update: See also the comments below this article, which clear up some of my misconceptions.

The first is that post-processing uses syntax from proposed standards which have yet to be ratified. For example, the variables syntax is based on Custom Properties which, athough implemented in Firefox, are yet to have any firm commitment from other browser vendors; the syntax could still be changed, or indeed dropped entirely. That would mean PostCSS would have to either retain an outdated syntax for backwards compatibility, or change it completely to match future decisions, making maintainability of old projects harder for developers.

The second problem is that the features of Sass which are most useful (and widely used) are those which greatly extend the core CSS syntax – notably, nesting and mixins. While there are PostCSS plugins that add extensions to match pre-processing features, using them means that your source stylesheet is no longer ‘proper’ CSS — which is the main attraction of a post-processor to me. If your source stylesheet is largely invalid, you might as well use a pre-processor.

Perhaps, as Lyza Danger Gardner concluded, using post-processors means giving up certain features:

Taking a path paved with lean, modular post-processing plugins involves sacrifices. No more nesting. Instead of an endless horizon of mixin possibilities, you may be bound to CSS spec realities, like calc or CSS variables.

I still like the idea of post-processing, but perhaps I need a longer period of acclimatisation before it fully makes sense to me.

 


Archive by category and date