Curt Long | Curt D. Long

Web Development Reading List #150: Less Code, GitHub’s Security, And The Morals Of Science

August 18, 2016 by Curt Long

Web Development Reading List #150: Less Code, GitHub’s Security, And The Morals Of Science

There is a lot to learn this week. It starts with non-technical things like going for a walk to refresh your mind and finishes with how to prevent reverse XSS attacks in forms. But it doesn’t matter whether you learn how to build self-contained web components using the new specification or to maximize the efficiency of your Angular 2 app or just how you can write less code. What matters is that you keep asking questions and that you try to get better and smarter at your craft.

General Link

Heydon Pickering shares tips on writing less code¹ to make your developer life easier. Something we all should remember.

Tools & Workflows Link

Nucleus⁵² is certainly not the first living style guide generator but it’s still worth sharing. The Node.js module fits into existing projects, follows the Patternlab splitting by default, and has a nice layout where you easily find the things you’re looking for.
If you ever lost a stash in git, here are a few tips on how to recover dropped stashes³.

⁴

Nucleus⁵² is a living style guide generator that fits in well in both new and existing projects.

Security Link

Matthew Green asks himself if Apple’s cloud key vault is a crypt backdoor⁶. In his explanatory answer, he shares why Apple’s method of using Hardware Security Modules is pretty clever and maybe worth learning more about if you’re interested in storing sensitive user data behind weak user-set passwords.
Using social engineering by pretending to be a valid website in the URL bar is easy with the RTL feature of Chrome and Firefox and this little trick⁷. I’m sure this type of attack is successful since most normal users do check if a URL is correct but they can’t see anything bad in it. A good reminder that we need to find better ways to let users know that the URL they visit is safe.
When we look into the source code of forms at github.com, we’ll find some interesting markup in there⁸. Its purpose: preventing XSS attacks. In this blog post we can learn about the tricks that GitHub uses⁹ to maximize the security of their web application.
Troy Hunt wraps up how our personal data is usually leaked¹⁰ and why security is a design process, not only an implementation process. Also a good primer on how to design a password recovery feature.

Address bar spoofing — Who’s really behind the URL? Ray Baloch uncovers an address bar spoofing vulnerability¹² in Chrome and Firefox. (Image credit: Rafay Baloch¹³)

Web Performance Link

Nolan Lawson wrote about the cost of small modules¹⁴, analyzing how much code is used when you build your codebase with a lot of small modules. The article reveals interesting stats and compares modern minifiers and JavaScript bundlers, as well as execution times of such bundles in various browsers.

JavaScript Link

Minko Gechev shares how you can do Ahead-of-time compilation in Angular 2¹⁵ to improve performance and reduce energy and bandwidth consumption to make your application more efficient.
Addy Osmani shares best practices on how to use offline storage for your web application¹⁶ to ensure the app stays usable when the network connection is flakey.
Eric Bidelman explains the new Shadow DOM v1 standard¹⁷, the now de-facto standard for building self-contained web components.

Work & Life Link

Margaret Gould Stewart talks about how she learned that making mistakes is crucial for a team’s morale¹⁸ and why this prevents people from becoming bored, burning out, and from feeling annoyed about their manager.
Sometimes, a long walk outside can refresh your mind¹⁹. It can give you new inspiration and help you calm down if you’re feeling upset.

Going Beyond… Link

Bill Gates shares what he learned from his school teacher²⁰ and how only later he realized that students should ask teachers more questions. If we ask more, we will learn from others. It’s always harder to proactively communicate knowledge to other people than being asked for it.
Phillip Rogaway shares a paper on “The Moral Character of Cryptographic Work²¹” (PDF). An interesting read on the shift of power and why cryptography is often a political tool that demands high morals and ethical fundamentals of those who build it. Anyone who ever discussed the topic of morals and ethics in science should read this.

And with that, I’ll close for this week. If you like what I write each week, please support me with a donation²² or share this resource with other people. You can learn more about the costs of the project here²³. It’s available via email, RSS and online.

— Anselm

Footnotes Link

1 http://www.heydonworks.com/article/on-writing-less-damn-code
2 https://holidaypirates.github.io/nucleus/
3 https://stackoverflow.com/questions/89332/how-to-recover-a-dropped-stash-in-git/7844566
4 https://holidaypirates.github.io/nucleus/
5 https://holidaypirates.github.io/nucleus/
6 http://blog.cryptographyengineering.com/2016/08/is-apples-cloud-key-vault-crypto.html?m=1
7 http://www.rafayhackingarticles.net/2016/08/google-chrome-firefox-address-bar.html
8 https://chloe.re/2016/07/19/protect-against-html-extraction/
9 https://chloe.re/2016/08/15/lets-look-at-some-of-the-security-at-github/
10 https://www.troyhunt.com/website-enumeration-insanity-how-our-personal-data-is-leaked/
11 http://www.rafayhackingarticles.net/2016/08/google-chrome-firefox-address-bar.html
12 http://www.rafayhackingarticles.net/2016/08/google-chrome-firefox-address-bar.html
13 http://www.rafayhackingarticles.net/2016/08/google-chrome-firefox-address-bar.html
14 https://nolanlawson.com/2016/08/15/the-cost-of-small-modules/
15 http://blog.mgechev.com/2016/08/14/ahead-of-time-compilation-angular-offline-precompilation/
16 https://medium.com/@addyosmani/offline-storage-for-progressive-web-apps-70d52695513c
17 https://developers.google.com/web/fundamentals/primers/shadowdom/
18 https://shift.newco.co/how-a-single-conversation-with-my-boss-changed-my-view-on-delegation-and-failure-ae5376451c8d
19 http://zenhabits.net/walk/
20 https://www.gatesnotes.com/Education/A-Teacher-Who-Changed-My-Life
21 http://web.cs.ucdavis.edu/~rogaway/papers/moral-fn.pdf
22 https://wdrl.info/donate
23 https://wdrl.info/costs/

API Frameworks JavaScript

Building A Server-Side Application With Async Functions and Koa 2

August 17, 2016 by Curt Long

Building A Server-Side Application With Async Functions and Koa 2

One of the upcoming features of JavaScript that I especially like is the support for asynchronous functions¹. In this article, I would like to show you a very practical example of building a server-side application using Koa 2, a new version of the web framework, which relies heavily on this feature.

First, I’ll recap what async functions are and how they work. Then, I’ll highlight the differences between Koa 1 and Koa 2. After that, I will describe my demo app for Koa 2, covering all aspects of development, including testing (using Mocha, Chai and Supertest) and deployment (using PM2).

Async Functions Link

The old problem of complex JavaScript applications is how to deal with callbacks and how to structure the code to avoid so-called “callback hell.” Several solutions have been developed over time, some of which are still based on callbacks and others that rely on more recent features of JavaScript — promises and generators. Let’s compare callbacks, promises and generators using the example of a function that fetches two JSON files in sequence.

// Fetch two files with callbacks function doWork(cb) { fetch('data1.json', (err1, result1) => { if (err1) { return cb(err1); } fetch('data2.json', (err2, result2) => { if (err2) { return cb(err2); } cb(null, { result1, result2, }); }) }); }

Nested anonymous inline callback functions are the primary indicator of callback hell. You could restructure the code and split the functions into modules, but you would have to rely on callbacks anyway.

// Fetch two files with promises function doWork(cb) { fetch('data1.json') .then(result1 => fetch('data2.json') .then(result2 => cb(null, { result1, result2, }))) .catch(cb); }

The promise-based version looks a bit better, but the calls are still nested and we need to reorganize the code to appear sequential.

// Fetch two files with generators function* doWork() { var result1 = yield fetch('data1.json'); var result2 = yield fetch('data2.json'); return { result1, result2 }; }

Generators allow for the shortest solution, and this looks like normal synchronous code, whereas the callback and promise snippets are clearly asynchronous and highly nested. Nevertheless, the generator solution requires that we change the function type to the generator function by adding * after the function keyword, and it requires the special way to invoke doWork. This looks somewhat unintuitive, and the async/await syntax addresses this drawback by providing better abstraction. Look at the same example using async functions:

async function doWork() { // Fetch two files with async/await var result1 = await fetch('data1.json'); var result2 = await fetch('data2.json'); return { result1, result2 }; }

This syntax can be interpreted as follows: Functions marked with the async keyword allow us to use the await keyword in them, which pauses the execution of the function to wait for the asynchronous operations to finish. The asynchronous operation can be represented by a generator, a promise or another async function. Also, you can use try/catch to handle any errors or rejections that occur during the async operations that you await. The same error-handling mechanism is possible with the generator-based control flow.

What is Koa? Link

Koa is positioned as a next generation web framework and it was designed by the people who created Express (and in particular, by TJ²). Koa is very lightweight and modular and allows writing code without using callbacks. Koa application is an array of middleware functions that run in sequence processing incoming requests and providing a response. Every middleware function has the access to the context object that wraps native node request and response objects and provides an improved API to work with them. Basic Koa application looks like this:

// This is Koa 1 var koa = require('koa'); var app = koa(); app.use(function *(){ this.body = 'Hello World'; }); app.listen(3000);

This is not much except for this in the Koa core. Advanced functionality is provided by 3rd-party modules.

Koa 2 Versus Koa 1 Link

Koa 1 is famous for its early adoption of generators and for supporting generator-based control out of the box. This is what a typical piece of code for Koa 1 that uses the middleware cascading and improved error handling looks like:

// Adapted from https://github.com/koajs/koa // In Koa 1.0, middleware is a generator function. app.use(function *(next) { try { yield next; } catch (err) { // the request context is <code>this</code> this.body = { message: err.message } this.status = err.status || 500 } }) app.use(function *(next) { const user = yield User.getById(this.session.id); this.body = user; })

Koa 2 removes built-in support for generators and uses async functions instead. The signature of middleware functions will change to support async arrow functions. Here is what the same code looks like written for Koa 2:

// Taken from https://github.com/koajs/koa // Uses async arrow functions app.use(async (ctx, next) = > { try { await next(); // next is now a function, await instead of yield } catch (err) { ctx.body = { message: err.message }; ctx.status = err.status || 500; } }); app.use(async ctx => { // await instead of yield const user = await User.getById(ctx.session.id); // ctx instead of this ctx.body = user; });

Using normal functions, promises and generator functions is still possible, as described in the documentation for Koa 2³.

Koa Versus Express Link

Koa is a simpler and leaner framework than Express, built on top of the Node.js’ HTTP module. Express provides built-in features for routing, templating and sending files and other features, whereas Koa provides the very minimum, as well as a generator-based (Koa 1) or async/await-based (Koa 2) control flow. Routing, templating and other features are provided as separate modules by the community, and normally there are several alternatives to choose from. The Koa section of GitHub has a document with additional insight⁴ on the differences between Koa and Express.

Status of Koa 2 Link

Koa 2 will be released once the async/await feature is available in Node.js natively. Fortunately, async/await and Koa 2.0 can be tested right now using Babel. We will get to this soon. First, let’s go over the scope of the app that I built to demonstrate Koa 2 and async functions.

Demo App Link

The goal here is to build a simple app that tracks page views for a static website — something like Google Analytics but much simpler. The app will have two endpoints:

one to store the information about an event (for example, a page view);
and one to get the total number of events;
additionally, the endpoints have to be secured with an API key.

Redis will be used to store the events data. The functionality will be tested by unit and API tests. The full source code of the app is available on Github⁵.

App Dependencies Link

Let’s start with the list of modules needed for the app, along with explanations for why they are needed. First, here are the dependencies needed at runtime:

npm install --save  # babel-polyfill provides the runtime that async functions need babel-polyfill  # The Koa framework itself koa@next  # Because Koa is minimalist, we need a parser # to parse JSON in the body of requests koa-bodyparser@next  # and the router koa-router@next  # The redis module to store the app's data redis # The Koa cors module to allow cross-origin requests kcors@next

Note that the version for Koa modules we are using is next. This means that this version will be compatible with Koa 2, and many modules already provide it. Here are the modules needed for development and testing:

npm install --save-dev  # To write assertions in our tests chai  # A popular testing framework mocha  # API-level tests supertest  # Babel CLI to build our app babel-cli  # A set of Babel plugins to support ES6 features babel-preset-es2015  # and to support stage-3 features babel-preset-stage-3  # Overrides Node.js's require and compiles modules at runtime babel-register  # To watch JavaScript files in development and restart the server # if there are changes in the files nodemon

How to Organize the Application? Link

After trying out several ways to organize the application’s files, I came up with the following simple structure that is suitable for small apps and small teams:

index.js

The main entry point of the app
ecosystem.json

The PM2 ecosystem, which describes how to start the app
src

The source of the app, containing JavaScript files to be compiled by Babel
config

The app’s configuration files
build

The build of the app, containing the compiled code from src

The src directory contains the following:

api.js

The module that defines the app’s API
app.js

The module that instantiates and configures the Koa app’s instance
config.js

The module that provides the configuration of the app to other modules

If additional files or modules are needed as the app grows, we would put them in a subfolder of the src folder — for example, src/models for application models, src/routes for more modular API definitions, src/gateways for modules that interact with external services, and so on.

NPM Scripts As A Task Runner Link

After using Gulp and Grunt as task runners, I came to the conclusion that npm scripts are better than separate tools when working on server-side projects. One of the advantages of npm scripts is that they allow you to invoke locally installed modules as if there were globally installed. I use the following scripts, which need to be defined in package.json:

"scripts": { "start": "node index.js", "watch": "nodemon --exec npm run start", "build": "babel src -d build", "test": "npm run build; mocha --require 'babel-polyfill' --compilers js:babel-register" }

The start script simply runs index.js. The watch script runs the start script using the nodemon tool, which automatically restarts the server whenever you change something in the app. Note that nodemon is installed as a local development dependency and does not have to be installed globally.

The build script compiles the files in the src folder using Babel and outputs the results to the build folder. The test script runs the build script first and then runs tests using mocha. Mocha requires two modules: babel-polyfill, to provide runtime dependencies of the compiled code, and babel-register, to compile the test files before executing them.

Additionally, presets for Babel have to be added to package.json, so that you don’t have to provide them in the command line:

{ "babel": { "presets": [ "es2015", "stage-3" ] } }

This preset enable all ECMAScript 2015 features, as well as features that are currently in stage 3⁶. With this installed and configured, we can start developing the app.

The Application’s Code Link

First, let’s look at index.js:

const port = process.env.PORT || 4000; const env = process.env.NODE_ENV || 'development'; const src = env === 'production' ? './build/app' : './src/app'; require('babel-polyfill'); if (env === 'development') { // for development use babel/register for faster runtime compilation require('babel-register'); } const app = require(src).default; app.listen(port);

The module reads two environmental variables: PORT and NODE_ENV. NODE_ENV should be either development or production. In development mode, babel-register will be used to compile modules at runtime. babel-register caches the results of the compilation and, thus, reduces the server start time, so that you can iterate faster during development. Because this module is not recommended for production use, the precompiled version from the build directory will be used in production mode.

index.js is the only file of the project that will not be compiled by Babel and that must use native module syntax (i.e. CommonJS). Therefore, the app’s instance is located in the default property of the imported app module, which is an ECMAScript 6 module that exports the app’s instance as a default export:

export default app;

This is important to keep in mind if you mix ECMAScript 6 and CommonJS modules.

Now to the app.js file itself. This and the other files discussed below are always compiled by Babel in both development and production environments, and the new syntax (including async functions) may be used freely in them:

import Koa from 'koa'; import api from './api'; import config from './config'; import bodyParser from 'koa-bodyparser'; import cors from 'kcors'; const app = new Koa() .use(cors()) .use(async (ctx, next) => { ctx.state.collections = config.collections; ctx.state.authorizationHeader = `Key ${config.key}`; await next(); }) .use(bodyParser()) .use(api.routes()) .use(api.allowedMethods()); export default app;

Here, we are using ECMAScript 2015’s import syntax to import the required modules. Then, we create a new instance of the Koa application and attach several middleware functions to it using the use method. The last thing we do is export the app so that it can be used by index.js.

The second middleware function in the chain is an async function and an arrow function at the same time:

app.use(async (ctx, next) => { // Set up the request context ctx..state.collections = config.collections; ctx..state.authorizationHeader = `Key ${config.key}`; await next(); // The execution will reach here only when // the next function returns and finishes all async tasks // console.log('Request is done'); })

In Koa 2, the next parameter is an async function that triggers the next middleware function in the list. Just like in Koa 1, you can control whether the current middleware function should do its job before or after the others by putting the call to next either at the beginning of the current function or at the end. Also, you can catch all errors in the downstream middleware functions by wrapping the await next(); statement in a try/catch statement wherever doing so makes sense.

Defining the API Link

The api.js file is where the core logic of our app resides. Because Koa does not provide routing out of the box, the app has to use the koa-router module:

import KoaRouter from 'koa-router'; const api = KoaRouter();

Here, koa-router provides functions to define middleware functions for specific HTTP methods and paths — for example, the route that stores events in the database:

// Declare a post method and what it does // :collection is a parameter api.post('/:collection', // First, validate auth key validateKey, // Then, validate that the provided collection exists validateCollection, // Handle adding the new item to the collection async (ctx, next) => { // Use ES6 destructuring to extract the collection param const { collection } = ctx.params; // Wait until the persistence layer saves the item const count = await ctx .state .collections[collection] .add(ctx.request.body); // Reply with 201 Created when the item is saved ctx.status = 201; });

Each method can have several handlers, which run sequentially and have exactly the same signature as the middleware functions defined in the top level of app.js. For example, validateKey and validateCollection are simply async functions that validate the incoming request and return 404 or 401 if the provided event collection does not exist or if the API key is not valid:

const validateCollection = async (ctx, next) => { const { collection } = ctx.params; if (!(collection in ctx.state.collections)) { return ctx.throw(404); } await next(); } const validateKey = async (ctx, next) => { const { authorization } = ctx.request.headers; if (authorization !== ctx.state.authorizationHeader) { return ctx.throw(401); } await next(); }

Note that arrow middleware functions cannot refer to the context of the current request using this (i.e. this is always undefined in the examples thus far). Therefore, request and response objects as well as Koa helpers are available in the context object (ctx). Koa 1 had no separate context object, and this referred to the current request context.

After defining other API methods⁷, we finally export the API to be connected to the Koa application in app.js:

export default api;

Persistence Layer Link

In api.js, we accessed the collections array in the context ctx, which we initialized in app.js. These collection objects are responsible for storing and retrieving data stored in Redis. The Collection class is as follows:

// Use promise-based Redis client const redis = require('promise-redis')(); const db = redis.createClient(); class Collection { // Full source: // https://github.com/OrKoN/koa2-example-app/blob/master/src/collection.js async count() { // We can `await` for promises // The await syntax allows us to work with // async calls as if they were synchronous var count = await db .zcount(this.name, '-inf', '+inf'); return Number(count); } async add(event) { await db .zadd(this.name, 1, JSON.stringify(event)); await this._incrGroups(event); } async _incrGroups(event) { // ES6 for:of syntax allows for easier iteration // groupBy is an array that holds possible attributes of the event for (let attr of this.groupBy) { // We can use await inside loops, // thus calling async operations sequentially in the loop await db.hincrby(`${this.name}_by_${attr}`, event[attr], 1); } } } export default Collection;

The async/await syntax is really helpful here because it allows us to coordinate several async operations easily — for example, in a loop. But there is one important thing to keep in mind. Let’s look at the _incrGroups method:

async _incrGroups(event) { // ES6 for:of syntax allows iterating easier for (let attr of this.groupBy) { // We can use await inside loops, // thus calling async operations sequentially in the loop await db.hincrby(`${this.name}_by_${attr}`, event[attr], 1); } }

Here, the keys are incremented sequentially, meaning that the next key will be incremented once the previous incrementation has succeeded. But this kind of job can be done in parallel! With async/await, the task might not be easy to accomplish, but promises can help:

// Start all increments in parallel // because there is no await inside the map callback here const promises = this.groupBy.map(attr => db.hincrby(`${this.name}_by_${attr}`, event[attr], 1)); // Wait for all of them to finish await Promise.all(promises);

The interchangeability of promises and async functions is very helpful.

Testing Link

The app’s tests are located in the test folder⁸. Let’s look at apiSpec.js, which represents the test specification for the app’s API:

import { expect } from 'chai'; import request from 'supertest'; import app from '../build/app'; import config from '../build/config';

We import expect from chai and supertest. We use the precompiled version of the app and the config to make sure that we are testing exactly the same code that will be running in production. Next, we write the tests for the API, leveraging the async/await syntax to achieve sequential execution of the test steps:

describe('API', () => { const inst = app.listen(4000); describe('POST /:collection', () => { it('should add an event', async () => { const page = 'http://google.com'; const encoded = encodeURIComponent(page); const res = await request(inst) .post(<code>/pageviews</code>) .set({ Authorization: 'Key ' + config.key }) .send({ time: 'now', referrer: 'a', agent: 'b', source: 'c', medium: 'd', campaign: 'e', page: page }) .expect(201); // here res is available // you can use res.headers, res.body etc // no callback for <code>expect</code> or <code>end</code> functions is required. expect(res.body).to.be.empty; }); }); });

Note that functions passed to it functions are marked with async. This means that await can be used to run asynchronous tasks, including the supertest requests, which return then-able objects and which, therefore, are compatible with what await expects.

Deployment With PM2 Link

Once the app is ready and tests have passed, let’s prepare everything to run the app in production. For this, let’s declare ecosystem.json, which will hold the production configuration of the app:

{ "apps" : [ { "name" : "koa2-example-app", // The entry point to the compiled version of the app "script" : "index.js", // In production, we don't want to watch for changes in files "watch" : false, // And we want to merge logs from all instances "merge_logs" : true, // We want to timestamp log messages "log_date_format": "YYYY-MM-DD HH:mm Z", "env": { // And include environment variables for the app "NODE_ENV": "production", "PORT": 4000 }, // Start two processes of the app, and balance the load between them "instances": 2, // Start app as a cluster "exec_mode" : "cluster_mode", // Watch failures and auto-restart processes "autorestart": true } ] }

If your app requires additional servers (for example, a cron job), you can add them to ecosystem.json, and they will be started together with the main server. To start the app on the production server, you can run this:

pm2 start ecosystem.json

And to persist the configuration, you would run this:

pm2 save

PM2 provides some monitoring features (try pm2 list, pm2 info, pm2 monit). For example, PM2 shows how much memory your application is using. This basic Koa application consumes 44 MB per Node.js process.

Conclusion Link

Babel allows us to build apps using ECMAScript syntax that is not natively available but that includes async/await, which makes writing asynchronous code more enjoyable. The code that uses the async/await syntax is easier to read and maintain. Koa 2 and Babel allow you to start using async functions right now.

Nevertheless, Babel brings additional overhead and requires additional configuration and an extra build step. Therefore, waiting until async/await is natively available in Node.js is recommended. Koa 2 should be officially released once this happens. Then, Koa 2 will be a good alternative to Express because it is more modular and simpler and allows for configuration the way you want it.

The deployment section of this tutorial might be too simple and unscalable. It leaves open the question of how and when to build and actually deploy the code — you can do this manually (rsync, scp) or set up a continuous integration server for this. Also, the inner architecture of the app is too simple yet is suitable for a demo. Larger and more ambitious apps might require other entities, such as gateways, mappers, repositories and so on, but all of them can leverage async functions.

I hope you’ve enjoyed this tutorial. Thanks for reading!

Links Link

Koa⁹, GitHub

A list of Koa modules
“Async Functions, Stage 3 Draft¹⁰,” Ecma International Technical Committee 39, GitHub

The async specification
koa2-example-app¹¹
The full source code of our demo app
“Middleware¹²,” Koa, GitHub

Middleware support for Koa 2
“Koa 2.0.0¹³,” GitHub

The GitHub issue to track the progress of Koa 2
“Async/Await implementation in V8¹⁴,” GitHub

The GitHub issue to track the progress of Async/Await implementation in Node

(al)

Footnotes Link

1 https://tc39.github.io/ecmascript-asyncawait/
2 https://github.com/tj
3 https://github.com/koajs/koa/tree/v2.x#common-function
4 https://github.com/koajs/koa/blob/master/docs/koa-vs-express.md
5 https://github.com/OrKoN/koa2-example-app
6 https://github.com/tc39/ecma262#current-proposals
7 https://github.com/OrKoN/koa2-example-app/blob/master/src/api.js
8 https://github.com/OrKoN/koa2-example-app/tree/master/test
9 https://github.com/koajs/koa/wiki
10 https://tc39.github.io/ecmascript-asyncawait/
11 https://github.com/OrKoN/koa2-example-app
12 https://github.com/koajs/koa/wiki#middleware
13 https://github.com/koajs/koa/issues/533
14 https://github.com/nodejs/promises/issues/4

Photoshop Responsive Web Design Workflow

Photoshop Etiquette For Responsive Web Design

August 16, 2016 by Curt Long

Photoshop Etiquette For Responsive Web Design

By Dan Rose
August 17th, 2016
Photoshop Responsive Web Design Workflow
19 Comments

It’s been almost five years since Photoshop Etiquette¹⁵¹ launched, which officially makes it a relic on the web. A lot can happen on the web in a few years, and these past five have illustrated that better than most.

In 2011, everyone was just getting their feet wet with responsive web design. The traditional comp-to-HTML workflow was only beginning to be critiqued, and since then, we’ve seen a myriad of alternatives. Style Tiles², Style Prototypes³, Visual Inventories⁴, Element Collages⁵, style guides⁶, and even designing in the browser have all been suitable approaches to multi-device design. With a shift from page-based design to building a design system, it’s truly an exciting time.

Is ‘Etiquette’ Still Relevant? Link

With alternatives to the heavy Photoshopping we may be familiar with, it’s fair to question if we still need etiquette. For the sake of this article, we’ll define etiquette as transferring files in an organized, clear, and discernible way. Responsive design typically comes with a lot of moving pieces, from @2x images, concatenated CSS files, and more. With seemingly more to do in order to publish a website, being efficient is unquestionably high priority, if we want to be profitable.

Often masked as efficiency, poor organization and communication are products of rushing to ship a project. With Photoshop taking on different roles in our workflows, layers and exported files are easy targets for cutting corners. The fact remains: anything worth doing is worth doing well.

If we want to save time, we need to invest a bit upfront in staying organized and clear. Inefficiency is inheriting a file from a coworker and spending valuable time attempting to figure out where to start because it’s not clearly labeled. It’s having to fix images that have already been exported. At worst, it’s not being able to find the file you need in the first place.

What’s New In Photoshop Etiquette? Link

Photoshop Etiquette was given a fresh coat of paint by Adjacent¹², a design studio in Syracuse, NY. For those new to the concept, Photoshop Etiquette is a best practices guide that promotes efficiency through clarity in web design. Though engineered for Photoshop, many of these principles apply to Sketch and similar, layer-based design tools.

The guide is broken down into the following sections:

File organization
Layer structure
Asset exporting
Type execution
Effect application
Quality check

Those familiar with the site will see a lot of familiar guidelines, such as quintessential tips like ‘Name Your Layers’ and ‘Name Files Accurately’, each an attempt at ridding the earth of practices like ‘Layer copy copy 5’ and ‘client-final-v3.psd’, respectively. If you dig a little deeper, you’ll find a glut of responsive resources attached to various guidelines, and a few tips for designing for multiple devices.

1. Consolidate Your PSDs Link

If you’re making multiple comps for multiple pages, Photoshop now has artboards that can help you stick to a single document. This helps eliminate confusion about which PSD is the right PSD.

If you can swing it, try using artboards, layer comps, or smart objects instead of managing tons of PSDs.

2. Work Collaboratively Link

With the addition of Creative Cloud Libraries and Linked Smart Objects, designers can share assets quite easily. For example, if you’re creating a pattern or component guide in Photoshop, one designer can be working on a component while another designer simultaneously works on a different one. These components can be shared within a Library, or as Linked Smart Objects that are pulled into a master PSD.

Between Linked Smart Objects and CC Libraries, there’s plenty of options for being collaborative.

3. Don’t Design To The Device Link

This can be argued, but if responsive design is about embracing all devices, perhaps we shouldn’t use popular Apple device presets as document sizes in Photoshop. Instead, allow your design to dictate breakpoints because of layout stress, wherever it falls. The exception is if you’re designing a device or platform-specific app, where targeting such presets is helpful.

Allow your design to dictate breakpoints, not popular-for-the-moment device widths.

4. Be Non-Destructive Link

With the rising implementation and support for SVG, it’s important for designers to sustain vector assets in Photoshop and not flatten them. Photoshop now allows you to save out SVGs, giving us one more reason to be nondestructive with our pixels.

5. Be Aware Of Screen Resolution Link

Speaking of SVG, it has really become a great approach to serving one asset that can adapt to any size and not lose fidelity. Having a Retina asset workflow¹³, whether SVG or @2x/@3x images, has become part of a responsive practitioner’s workflow.

6. Compress Link

Performance is a worthy cause, not only for a developer but for a designer. I’ve often rationalized that if I want to include heavy web fonts and their Open Type features in my projects, I’ll need to make up the difference by aggressively compressing my images to stay within a performance budget. Third party tools like TinyPNG¹⁴ have made image compression a breeze.

Performance is a designer’s task. Make sure you’re squeezing any extra file size out of your images.

As our web design workflows and use of Photoshop continues to change, so will the site. While it encompasses a Photoshop-centric workflow, there’s a few tips for ones where Photoshop is used sparingly, as well. The guide only advocates that if, and when, you use Photoshop, communicate your intent as clearly as possible.

Fueled By Community Link

One of the primary focuses for Photoshop Etiquette¹⁵¹ is growth, manifested in more guidelines, more resources, and more perspectives. A feature has been added to the site providing easier access to submit a new guideline for review, something hundreds of designers and developers did over the years by tracking me down on Twitter or hunting down an email address.

In the wake of Google Translate’s inaccuracies, there’s also an open call for translations by community volunteers.

It’s exciting to see how Photoshop Etiquette has resonated with so many organizations and individuals. How can it help you and your team?

(vf, il)

Footnotes Link

1 http://photoshopetiquette.com/
2 http://styletil.es/
3 http://seesparkbox.com/foundry/our_new_responsive_design_deliverable_the_style_prototype
4 http://danielmall.com/articles/visual-inventory/
5 http://danielmall.com/articles/rif-element-collages/
6 http://styleguides.io/
7 https://www.smashingmagazine.com/2015/05/retina-design-in-photoshop/
8 https://www.smashingmagazine.com/2015/06/creating-advanced-animations-in-photoshop/
9 https://www.smashingmagazine.com/2016/03/the-retina-asset-workflow-youve-always-wanted-for-photoshop/
10 https://www.smashingmagazine.com/2016/01/responsive-image-breakpoints-generation/
11 http://photoshopetiquette.com/
12 http://weareadjacent.com
13 https://www.smashingmagazine.com/2015/05/retina-design-in-photoshop/
14 http://tinypng.com
15 http://photoshopetiquette.com/

Communication User Interaction

S(GH)PA: The Single-Page App Hack For GitHub Pages

August 15, 2016 by Curt Long

Creativity Under The Microscope: Running A UI Design Critique

August 14, 2016 by Curt Long

Creativity Under The Microscope: Running A UI Design Critique

Criticism is easy. It seems like everybody has an opinion, but, as the author Harlan Ellison points out, “You are not entitled to your opinion. You are entitled to your informed opinion.” To become informed, though, requires exploration. Design critiques are an important part of any product exploration.

A design critique — where the creator discusses and explains the creation with the rest of the team and/or client — is not about badgering the designer or pushing them to justify every decision they made. That’s just criticism. A good design critique is meant to explore the design, find where it is working and where it could be improved. If done well, design critiques allow everyone on the team to feel as if they have been heard and allow clients to give valuable feedback.

If you are the person running the critique, getting to constructive criticism is often a challenge, especially with groups that do not have experience with the design critique format. In an agile environment, you will often have coders, project managers, product managers and people from other disciplines sitting in to give feedback, and you need to know how to quickly get them up to speed on the expectations if you want to get anywhere fast.

Principles For Running A Great UI Critique Link

From my own experience, I’ve found that design critiques for user interfaces (UIs) need to be performed throughout the entire product design and development process, at least weekly, and possibly even daily at certain times. They keep the product design on track, and they become even more critical in an interactive agile or lean UX product environment, where designs go through multiple iterations before deployment. Running a UI design critique is a challenge, requiring you not only to explain decisions, but also to listen carefully to other ideas.

The critique allows your team to create together. (Image: Jamie Cummings²) (View large version³)

Establishing clear principles — not “rules” — at the beginning of every critique is imperative. Unlike rules, which are dogmatic and feel restrictive, principles help everyone understand the expectations but still allow for the freeform discussion that is needed.

Chief among these expectations is for everybody to agree on why you are actually critiquing what you are looking at. Jason Ulaszek recommends:

Start by asking about the purpose or intention behind the design you’re critiquing. Why are we asking for this piece of information? What expectations have been set that allow us to ask for it? What will we do with it? If we can answer those questions, then we move on to discussing various options of interpreting the need for the element and respective advantages and disadvantages with each option.

To help you keep to this guideline, I recommend following the standard principles you might apply to any design critique, whether it involves UI design or not:

Show respect.

It might sound cliched, but if everyone in the critique is not respectful of the opinions and skills of the others at the table, then the critique will quickly degrade into hostility.
Designate roles.

Before starting, clarify who will be taking on which role(s) during the critique. It’s best to mix these up from critique to critique so that no one feels left out, and it’s optimal if the three lead roles are different people (but that is not always practical).
- Presenter
  
  This is the person responsible for presenting the design and the thinking behind it. This person answers all questions or directs them to other people in the critique who can answer them.
- Moderator
  
  If possible, it is best if this role is performed by someone not directly responsible for the design, often the project or product manager. The moderator ensures that everyone stays on topic and that everyone is heard.
- Note-taker
  
  This person focuses on recording what is discussed and is especially vital for making sure that the takeaways (another principle, listed below) are clearly defined at the end of the critique. The note-taker should not be left out of the discussion, although their role might lean towards getting other members of the team to clarify what they have said.
State the goals for the project and for the critique up front.

Quickly remind everyone of the goals of the project and what this specific critique will cover. Keep the critique focused on the task at hand, rather than allowing the scope to creep to other considerations that would derail the primary purpose of the discussion.
Review the audience(s).

To reinforce that the people in the critique are not the target audience for the product, remind everyone about who is.
Avoid coming up with “the answers.”

Participants will feel a strong desire to solve problems and come up with the “answer” in a critique. However, the best solutions rarely arise in the actual meeting. The point of a critique is to probe for issues and discuss multiple potential solutions for the designer to take away and consider.
Agree on takeaways.

After everything has been said in the critique, the note-taker needs to review the takeaway tasks for everyone who participated to ensure that everyone is on the same page for the next critique.

Unfortunately, all too often, UI design critiques focus heavily on the visual and not enough on the interactive, much less temporal, nature of the design. For a UI design critique, add the following elements:

Identify the presentation media.

Along with identifying the audience, review the platform and technologies being used to create the product. Is this an iPhone app? A website? Are you using AngularJS? C#? Make sure these are all considered so that you avoid proposing solutions that wouldn’t work.
Outline the process flow.

You need to know the road map. For UI design, that would be the process flow for the user’s experience. This might come in the form of storyboards, journey maps or other ways of describing the process, but everyone should be familiar with it before considering the UI.
Demo the product, but show more than tell.

I cannot stress this one enough: A great user experience has a lot more showing than telling. The end user will need to know exactly how the product works with minimal explanation. Your demo should also require as little explanation as possible. As the saying goes, a good UI is like a joke: If you have to explain it, it’s not very good.

Asking The Right Questions Link

Plenty of questions⁷ and statements⁸ work against strong cooperation in a design critique. Here are a few questions that I have found open dialogue for exploring designs in a collaborative, rather than combative, way, which you can suggest to your team.

Ask More Questions. — The key is to ask the right questions. (Image: Jonathan Simcoe¹⁰) (View large version¹¹)

“How Did You Come Up With That Solution?” Link

A great place to start any critique or conversation is to ask the designer how — not why — they did something. Asking why immediately puts them on the defensive, while asking how invites exploration of the concept’s origin without the need for justification.

Description of the image. — Finding answers is easy. Asking the right questions is hard. (Image: Jason CranfordTeague¹³) (View large version¹⁴)

“Why” questions push us towards trying to prove something is “true,” rather than explaining it as one possibility. According to Aaron Morton¹⁵:

“Why” elicits a story, explanations of why something is true. If you ask why nothing is working out the way you want it to, you are likely to create a story, which may or may not be true. This is dangerous territory in making you feel bad.

Instead of asking “why,” consider asking “how” questions to elicit a story about the process of creation, rather than a defence of its existence. From there, you can then ask what possibilities the designer considered before, and only then explore alternatives they may not have considered. But listen carefully to what the designer has already tried before offering suggestions. They may have overlooked something, but don’t go into the conversation assuming so.

“Where Did You Get the Idea To Do It That Way?” Link

Thomas Edison famously said, “Genius is one percent inspiration and ninety-nine percent perspiration.” But he largely stole his one percent from Nikola Tesla. Then again, Picasso said, “Good artists borrow, great artists steal” (but he probably stole that line).

A central idea of Pixar Animation president Ed Catmull¹⁶’s book Creativity, Inc is that having a great team is more important than having a great idea:

Getting the right people and the right chemistry is more important than getting the right idea.

We rarely conceive ideas in a vacuum, and thinking about where we got our inspiration from can push our own innovation. Even better, bringing our inspirations together in a team setting can spawn new ideas.

A word of caution: Be careful not to sound accusatory or condescending — i.e. implying they stole the idea. Though, you do want the designer to push their own understanding of the motivations for their ideas and where they came from, without squishing the innovation.

“When Does That Need to Happen?” Link

Just like in comedy, timing is everything in temporal design¹⁷, and events need to happen at the right time and in the right order. When we are designing, though, that order is not always obvious until we have to sit down and explain it.

A great UI is like a great story, and that means you have to carefully pace it. How much information is just enough to get started with a form? Are you displaying data in the right context for the user to understand? Is this the right moment to reveal the conclusion?

Jason Kunesh, CEO of Public Good¹⁸, a startup that helps nonprofits connect with people through the news, tells me:

For our customers, a great interaction at the right moment is the difference between a happy fan of the product or service and a lost opportunity to connect. Turning a casual interaction into a lasting relationship depends on a series of tiny, positive interactions and messages arriving when people are ready for them.

Part of the critique process should be to iron out the wrinkles in the timing of the interface by asking at every opportunity whether this is the right moment to perform an action, ask a question or present data.

“Can We Use Motion to Add Visual Cues?” Link

This question will surprise a lot of designers who are used to the static nature that has dominated UI design for years. However, movement, animation and transitions are becoming the norm in experience design. Motion will soon be as important to consider in a design as color.

Animated UI. — Motion is as important as color in modern UI design. (Image: Jakub Antalík²⁰) (View large version²¹)

According to UI animation expert Rachel Neighbors²²:

With the rise of flat design and the UX stumbles that have come with it, we’ve seen just how dangerous it can be to strip visual cues from a site’s components. Animation can be used to the opposite effect.

Movement or change could be as simple as a change in opacity or color, or a monkey’s arm stretching across the page, or a sun rising as the user completes a task. Asking about adding moment-to-moment movement in a UI design will often push the designer to change their perspective in good ways. Push the designer to think beyond the discrete moment and to discuss the design in time, not just in space.

“How Could We Make It Simpler?” Link

Simplicity is hard. It seems like adding is always easier than taking away, and many UIs suffer from what I like to call the “snowflake in a blizzard” syndrome: Sure, every snowflake is unique, but you’ll never notice that in a blizzard. In UI design, we all too often see interfaces chockablock full of links, buttons, controls and images. Clients will often think they need to include everything the audience might ever need, to the point that you can’t find anything you actually need.

I put the simplicity question to Steve Krug, author of Don’t Make Me Think²⁶:

I think it’s a very useful question. I would have thought it’s a lesson everyone’s absorbed by now, but I know they haven’t. I always like to say that anything on the page or screen that’s not part of the solution — for the user’s real goals — is noise and a candidate for being thrown overboard.

At every step in a design, we need to ask ourselves, How can we create something that requires less thought yet keeps the same power? In a critique, this is best expressed by asking how to make something simpler. It’s important to maintain clarity in the design, but to do so with fewer clicks, less text and not as many form fields. Get down to the bare minimum needed to get the job done, and your users will thank you.

“What Happens Next?” Link

A great design critique shares a lot in common with a great interview: They are both about exploration. One of the greatest interviewers, Studs Terkel, said²⁷:

[Interviewing] isn’t an inquisition; it’s an exploration, usually an exploration into the past. So I think the gentlest question is the best one, and the gentlest is, “And what happened then?”

Applying this to a UI design, we always need to ask the designer to think about what happens next. This question invites them to think beyond what they considered to be the end. Users must always have somewhere to go next.

One of the greatest challenges to envisioning any UI is to consider all of the possible paths, not just the “happy path” we want the user to take. What happens after they click a button? What happens if there is an error? What happens after they submit a form? Ask what happens next until you’ve considered every possible scenario, otherwise you run the risk of leaving the user hanging, which is always a bad experience.

Don’t Just Ask Questions to Answer Them Link

When asking these questions — or any others for that matter — don’t ask simply so that you can answer yourself. It is annoying when someone asks you a question not to hear your answer or to understand your thinking but simply to hear their own voice.

Blank Notebook. — Be ready to take notes and listen. (Image: Luis Llerena²⁹) (View large version³⁰)

If you are one of those people, cut it out immediately. Ask all of your questions with your mind wide open to the answers given. Then, craft your responses based on those answers, not the answers you wanted to hear.

What A Good UI Critique Looks Like Link

Critiques will vary greatly depending on the skills, goals and responsibilities of the participants. However, a good critique always focuses on specific aspects of the product and thoroughly explores the presented solution.

A UI critique focuses not just on what the product looks like at the moment, but on how it works over time and whether this best suits the user’s needs. Rather than considering the user’s needs, participants will often wonder why something wasn’t done the way they expected. Jason Ulaszek of UX for Good³¹ agrees, telling me about his own critiques:

Staying objective in our discussion and considering the mental model of the individual tasked with using the design [i.e. the user] is critical in how we discuss the solution.

Always keep in mind that — like cell-based animation, where a second’s worth of the final film could take weeks or months to produce — while we might spend hours agonizing over a minute detail in the interface, it will probably be just a blip on the user’s radar.

CCTV Cams. — The whole team needs to be looking in the same direction. (Image: Matthew Wiebe³³) (View large version³⁴)

Steve Krug had this to say when I asked him about this:

We’re thinking, “great literature” (or at least “product brochure”), while the user’s reality is much closer to “billboard going by at 60 miles an hour.” It’s incredibly hard for UI designers to realize just how quickly people are zooming through — or past — the interface they’ve worked so hard to develop, and how little of it they actually take in.

A good UI critique slows down to consider every element, but recognizes that this is not how the user will be seeing the design. If the participants in your critique do not have formal training to speak directly to color, typography or experience design, they can still consider these important factors in all UI designs:

Consistency

Are the design and its implementation consistent throughout the product? This includes color, typography, controls, imagery and any design element (static or interactive) that is used more than once in the interface.
Context

Have you consistently respected the context of the user as they are using the product? Constantly asking this question is key because you are likely not in that context, but merely simulating it, while designing or testing.
Voice

Do the brand and design have a clear, consistent and recognizable voice?
Transitions

Are you using transitions from state to state for any significant changes in the UI? Modern designs are about far more than the visual. Consider how all interface elements move and change during the user’s interaction.
Simplicity

Is the design as simple as it can be to get the job done?

Avoiding Hostile Critiques Link

Critiques can be — and often are — done in a pugnacious way, where members of the team, for whatever reason, are inclined to criticize the work without listening to the thought process that went into its creation. They bring their own biases to the design, rather than consider the user, and they often just try to show how clever they are.

You can always tell when a critique becomes overly aggressive: The designer tends to become prickly about their decisions, rather than explain how they arrived at them and discuss alternatives. The key to avoiding aggressive critiques is to set out clear principles and ask open-ended, constructive questions. Remember that the idea is to strengthen the design collaboratively, not to win a design battle.

I find aggressive critiques to be unhelpful and usually harmful. Antagonistic critiques force the designer into a defensive posture, entrenching them in what they have done, rather than empowering them to expand it. Design is — to a very large extent — intuitive and not always easily qualifiable, much less quantifiable.

However, that does not mean the critique is purely about the designer’s opinion; it is about the designer’s well-informed opinion gained through years of study. Web producer Phillip Djwa³⁵ of Agentic feels that the key is to…

… speak from my experience, and not try to generalize. For example, I would ask, “I wonder whether the opening banner is communicating enough of the brand?” instead of, “Wow, people will never understand what brand value we have.”

Final Word: A Critique Is Not Usability Testing Link

It’s easy to trick yourself into thinking that you speak for the audience, either through the use of personas or your own biases. No matter how many personas you create or critiques you run through, you are not your audience. Steve Krug tells me:

This is one reason why I think every designer should spend time watching people try to use what they’ve built (aka usability tests).

Toolchest. — A design critique is just one tool in your UX toolchest. (Image: Todd Quackenbush³⁷) (View large version³⁸)

Just like a laser level³⁹ versus a bubble level, usability testing is more precise and accurate than internal critiques, but also generally more time-consuming and expensive. Regular design critiques are invaluable for keeping a project on target but can never replace getting out in the field and testing with real-life users. Otherwise, all you are doing is talking to yourself.

(ah, al, il)

Footnotes Link

1 https://www.smashingmagazine.com/wp-content//uploads/2016/08/create-opt.jpeg
2 https://unsplash.com/@bamagal
3 https://www.smashingmagazine.com/wp-content//uploads/2016/08/create-opt.jpeg
4 https://www.smashingmagazine.com/wp-content//uploads/2016/08/critique-opt.jpg
5 http://cranfordTeague.com/
6 https://www.smashingmagazine.com/wp-content//uploads/2016/08/critique-opt.jpg
7 https://medium.com/jasonspeaking-report/6-seemingly-innocent-questions-guaranteed-to-kill-creativity-c4d35aa8f2cd#.kbk4wne2l
8 https://medium.com/jasonspeaking-report/6-statements-that-kill-ui-creativity-f0a8384a63aa#.ahc7de9j9
9 https://www.smashingmagazine.com/wp-content//uploads/2016/08/questions-opt.jpeg
10 https://unsplash.com/@jdsimcoe
11 https://www.smashingmagazine.com/wp-content//uploads/2016/08/questions-opt.jpeg
12 https://www.smashingmagazine.com/wp-content//uploads/2016/08/solution-opt.jpg
13 http://cranfordteague.com/
14 https://www.smashingmagazine.com/wp-content//uploads/2016/08/solution-opt.jpg
15 http://lateralaction.com/articles/creative-questions
16 http://waltdisneystudios.com/corp/unit/6/bio/53
17 https://medium.com/jasonspeaking-report/temporal-design-thinking-8b37e2879d08#.u8qxa5do8
18 https://publicgood.com/
19 https://www.smashingmagazine.com/wp-content//uploads/2016/08/goals-animation.gif
20 https://dribbble.com/antalik
21 https://www.smashingmagazine.com/wp-content//uploads/2016/08/goals-animation.gif
22 http://rachelnabors.com/
23 https://www.smashingmagazine.com/wp-content//uploads/2016/08/simple-opt.jpg
24 https://unsplash.com/@benchaccounting
25 https://www.smashingmagazine.com/wp-content//uploads/2016/08/simple-opt.jpg
26 https://www.sensible.com/
27 http://www.nytimes.com/2008/11/01/books/01terkel.html
28 https://www.smashingmagazine.com/wp-content//uploads/2016/08/notes-opt.jpeg
29 https://unsplash.com/@albertosaure
30 https://www.smashingmagazine.com/wp-content//uploads/2016/08/notes-opt.jpeg
31 http://www.uxforgood.com
32 https://www.smashingmagazine.com/wp-content//uploads/2016/08/looks-opt.jpeg
33 https://unsplash.com/@matthewwiebe/
34 https://www.smashingmagazine.com/wp-content//uploads/2016/08/looks-opt.jpeg
35 http://www.agentic.ca/studio/phillip-djwa
36 https://www.smashingmagazine.com/wp-content//uploads/2016/08/tools-opt.jpg
37 https://unsplash.com/@toddquackenbush
38 https://www.smashingmagazine.com/wp-content//uploads/2016/08/tools-opt.jpg
39 http://www.dewalt.com/en-us/products/hand-tools/measuring-and-layout-tools/self-leveling-line-lasers/12v-max-compatible-red-cross-line-laser/dw088lr

Web Development Reading List #149: CSS Dynamic Colors, Refactoring CSS, And CSP Hashing

August 11, 2016 by Curt Long

Web Development Reading List #149: CSS Dynamic Colors, Refactoring CSS, And CSP Hashing

Even though we think everything happens in real-time nowadays, we need patience. While technology has been capable of real-time for long now, the “bottleneck” are human beings. Whether it’s a pull request that’s waiting for review since days or weeks or an email response, we need to keep in mind that delays might happen for a good reason.

Different people have different priorities, they might be focusing on something else at the moment, or they just take a break. Training patience is an important aspect of mental health, and, in the end, a well-thought-out, not instantly written feedback is better, too. Take your time and let others do the same.

To my readers in or near Germany: Some of you might be aware that I organize a small event, and this week I have one ticket to give away for the NightlyBuild conference 2016¹ in Cologne, Germany on September, 2nd. If you want to attend, just send me an email², and I’ll raffle the ticket on Tuesday.

News Link

WebKit now supports <script> and <style> hashes³ so you don’t need to set your Content Security Policy to allow 'unsafe-inline'.

Privacy Link

While researching a bit on user tracking, I found out about header enrichment, a technique used by mobile network providers to set unique identifiers. But more interestingly, while it’s advised by the IETF to not expose any of these headers to public servers, many ISPs do it anyway and leak the private IP addresses of devices, the IMEI/IMSI or even the phone number, to any server. This research paper⁴ by the ICSI analyzed the worldwide spread and impact on users’ privacy.
Many of you might be aware that we can’t style :visited states and similar browser-history-based features in CSS very well. With CSS’ new mix-blend-mode-feature there seems to be a leak again that lets rogue sites inspect your browsing history. Michał Zalweski explains how it works⁵.
Netflix engineers now share insights into how they protect the viewing privacy⁶ of their users by adding TLS to their video streams, which at that scale is a pretty challenging and interesting problem.

JavaScript Link

Damon Bauer shares how you can build an image uploader in React.js⁷ and use it to manipulate the image for later usage.
Peter van der Zee outlines how to reduce complexity in your code by thinking outside the box⁸. In another article worth reading, he also reflects on the question if we need JavaScript for everything⁹. The outcome of this little anecdote is nothing ground-breaking, but something we all should remind ourselves of from time to time.

CSS/Sass Link

Erik Jung explores new ways to add dynamic themes in CSS with CSS variables and CSS Colors Level 4¹⁰ features like the new color() function.
Meanwhile, Abbey Fitzgerald wrote a great tutorial on how to use CSS and SVG clipping and masking techniques¹¹ to create new types of layouts on websites.
Harry Roberts now shares the slides to his talk “Refactoring CSS Without Losing Your Mind¹²”. Having experienced many of the mentioned problems already in the past, I think there are a lot of great tricks in there that can be really helpful.

¹³

Clipping and masking allows for interesting ways to show or hide pieces of your graphics. Abbey Fitzgerald explains how to do it with CSS and SVG¹⁴.

Work & Life Link

Today I read an interesting statement about constant learning¹⁵ (see the blockquote below) with which I fundamentally disagree. So instead of following this advice, I want to encourage you to take a break from constant learning every few days. There are reasons why you should rest on a weekend and recover from learning new things during the week: By taking a break, you’ll eagerly await learning something new afterwards.

“In today’s highly competitive business environment, we all need to be in constant learning mode. No one can afford to take a vacation from developing new skills, especially as economic and political uncertainty threaten businesses and job stability and make future career prospects unclear.”

Rose Marcario, CEO of Patagonia, has published an essay on why it’s important that employers support families¹⁶. It’s not just about saying this but about taking meaningful, real action to make employees feel comfortable, have a good life, and enjoy working for their employer.

Going Beyond… Link

The NASA started a new blog called “Science WOW!¹⁷” which shares educational articles on science each week. If you’re interested in learning how hurricanes form or about space exploration stuff, this might be for you.

And with that, I’ll close for this week. If you like what I write each week, please support me with a donation¹⁸ or share this resource with other people. You can learn more about the costs of the project here¹⁹. It’s available via email, RSS and online.

— Anselm

Footnotes Link

1 https://nightlybuild.io/
2 mailto:mail@wdrl.info
3 https://webkit.org/blog/6830/a-refined-content-security-policy/
4 https://www.icsi.berkeley.edu/pubs/networking/headerenrichment15.pdf
5 https://lcamtuf.blogspot.de/2016/08/css-mix-blend-mode-is-bad-for-keeping.html
6 http://techblog.netflix.com/2016/08/protecting-netflix-viewing-privacy-at.html
7 https://css-tricks.com/image-upload-manipulation-react/
8 http://qfox.nl/weblog/371
9 http://qfox.nl/weblog/361
10 https://cloudfour.com/thinks/building-themes-with-css4-color-features/
11 https://getflywheel.com/layout/css-svg-clipping-and-masking-techniques/
12 https://speakerdeck.com/csswizardry/refactoring-css-without-losing-your-mind
13 https://getflywheel.com/layout/css-svg-clipping-and-masking-techniques/
14 https://getflywheel.com/layout/css-svg-clipping-and-masking-techniques/
15 http://further.net/tricky-goals/
16 https://www.linkedin.com/pulse/why-should-employers-care-families-rose-marcario
17 https://blogs.nasa.gov/educationsciencewow/
18 https://wdrl.info/donate
19 https://wdrl.info/costs/

A Beginner’s Guide To Progressive Web Apps

August 10, 2016 by Curt Long

A Beginner’s Guide To Progressive Web Apps

Progressive web apps could be the next big thing for the mobile web. Originally proposed by Google in 2015, they have already attracted a lot of attention because of the relative ease of development and the almost instant wins for the application’s user experience.

A progressive web application takes advantage of the latest technologies to combine the best of web and mobile apps. Think of it as a website built using web technologies but that acts and feels like an app. Recent advancements in the browser and in the availability of service workers and in the Cache and Push APIs have enabled web developers to allow users to install web apps to their home screen, receive push notifications and even work offline.

Progressive web apps take advantage of the much larger web ecosystem, plugins and community and the relative ease of deploying and maintaining a website when compared to a native application in the respective app stores. For those of you who develop on both mobile and web, you’ll appreciate that a website can be built in less time, that an API does not need to be maintained with backwards-compatibility (all users will run the same version of your website’s code, unlike the version fragmentation of native apps) and that the app will generally be easier to deploy and maintain.

Why Progressive Web Apps? Link

A study has shown that, on average, an app loses 20%¹ of its users for every step between the user’s first contact with the app and the user starting to use the app. A user must first find the app in an app store, download it, install it and then, finally, open it. When a user finds your progressive web app, they will be able to immediately start using it, eliminating the unnecessary downloading and installation stages. And when the user returns to the app, they will be prompted to install the app and upgrade to a full-screen experience.

However, a native app is definitely not all bad. Mobile applications with push notifications achieve up to three times more retention² than their counterparts without push, and a user is three times more likely to reopen a mobile application than a website. In addition, a well-designed mobile application consumes less data and is much faster because some resources reside on the device.

A progressive web application takes advantage of a mobile app’s characteristics, resulting in improved user retention and performance, without the complications involved in maintaining a mobile application.

Use Cases Link

When should you build a progressive web app? Native is usually recommended for applications that you expect users to return to frequently, and a progressive web app is not any different. Flipkart³ uses a progressive web app for its popular e-commerce platform, Flipkart Lite, and Air Berlin⁴ uses a progressive web app for its online check-in process, allowing users to access their tickets without an Internet connection.

When assessing whether your next application should be a progressive web app, a website or a native mobile application, first identify your users and the most important user actions. Being “progressive,” a progressive web app works in all browsers, and the experience is enhanced whenever the user’s browser is updated with new and improved features and APIs.

Thus, there is no compromise in the user experience with a progressive web app compared to a traditional website; however, you may have to decide what functionality to support offline, and you will have to facilitate navigation (remember that in standalone mode, the user does not have access to the back button). If your website already has an application-like interface, applying the concepts of progressive web apps will only make it better.

If certain features are required for critical user actions but are not yet available due to a lack of cross-browser support⁵, then a native mobile application might be the better option, guaranteeing the same experience for all users.

Characteristics Of A Progressive Web App Link

Before we jump into the code, it is important to understand that progressive web apps have the following characteristics⁶:

Progressive

By definition, a progressive web app must work on any device and enhance progressively, taking advantage of any features available on the user’s device and browser.
Discoverable

Because a progressive web app is a website, it should be discoverable in search engines. This is a major advantage over native applications, which still lag behind websites in searchability.
Linkable

As another characteristic inherited from websites, a well-designed website should use the URI to indicate the current state of the application. This will enable the web app to retain or reload its state when the user bookmarks or shares the app’s URL.
Responsive

A progressive web app’s UI must fit the device’s form factor and screen size.
App-like

A progressive web app should look like a native app and be built on the application shell model, with minimal page refreshes.
Connectivity-independent

It should work in areas of low connectivity or offline (our favorite characteristic).
Re-engageable

Mobile app users are more likely to reuse their apps, and progressive web apps are intended to achieve the same goals through features such as push notifications.
Installable

A progressive web app can be installed on the device’s home screen, making it readily available.
Fresh

When new content is published and the user is connected to the Internet, that content should be made available in the app.
Safe

Because a progressive web app has a more intimate user experience and because all network requests can be intercepted through service workers, it is imperative that the app be hosted over HTTPS to prevent man-in-the-middle attacks.

Let’s Code! Link

Our first progressive web app, Sky High, will simulate an airport’s arrivals schedule. The first time the user accesses our web app, we want to show them a list of upcoming flights, retrieved from an API. If the user does not have an Internet connection and they reload the web app, we want to show them the flight schedule as it was when they last downloaded it with a connection.

⁷

Sky High, our fictitious progressive web app (Large preview⁸)

The Basics Link

The first characteristic of a progressive web app is that it must work on all devices and must enhance on devices and browsers that allow it. Therefore, we’ve built our website using traditional HTML5 and with JavaScript that simulates the retrieval of data from a mock API. Throughout the application, we are using small bits of Knockout⁹ to handle our Model-View-ViewModel (MVVM) bindings — a lightweight JavaScript framework that allows us to bind our JavaScript models to our HTML views. We chose to use Knockout because it is relatively simple to understand and does not clutter the code; however you may replace this with any other framework, such as React or AngularJS.

Our website follows Google’s material design¹⁰ guidelines, a set of principles that guide design and interaction. Material design not only serves as a unified standard across applications and devices, but also gives design meaning. We’ve used material design for Sky High’s arrivals view to give our progressive web app that native-app look and feel.

Finally, we tested our app to make sure it is jank-free¹¹ and that scrolling is silky-smooth. Jank-free rendering has been shown to improve user engagement. Aim for a rendering of 60 frames per second.

For this demo, we will retrieve a static JSON file, instead of a real API. This is merely to keep things simple. In the real world, you would query an API or use WebSockets.

index.html Link

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Sky-High Airport Arrivals</title> <link async rel="stylesheet" href="./css/style.css"> <link href="https://fonts.googleapis.com/css?family=Roboto:300,600,300italic,600italic" rel="stylesheet" type="text/css"> </head> <body> <header> <div> <h3>Arrivals</h3> </div> </header> <div> <div> <ul data-bind="foreach: arrivals"> <li> <span data-bind="html: title"></span> <span data-bind="html: status"></span> <span data-bind="html: time"></span> </li> </ul> </div> </div> <script src="./js/build/vendor.min.js"></script> <script src="./js/build/script.min.js"></script> </body> </html>

The index.html file is relatively standard. We’ve created an HTML list and bound our View Model property arrivals to it using Knockout¹², through the attribute data-bind="foreach: arrivals". The View Model arrivals is declared in the page.js file below and exposed in the Page module. On our HTML page, for each item in the arrivals array, we’ve bound the title, status and time properties to the HTML view.

page.js Link

(var Page = (function() { // declare the view model used within the page function ViewModel() { var self = this; self.arrivals = ko.observableArray([]); } // expose the view model through the Page module return { vm: new ViewModel(), hideOfflineWarning: function() { // enable the live data document.querySelector(".arrivals-list").classList.remove('loading') // remove the offline message document.getElementById("offline").remove(); // load the live data }, showOfflineWarning: function() { // disable the live data document.querySelector(".arrivals-list").classList.add('loading') // load html template informing the user they are offline var request = new XMLHttpRequest(); request.open('GET', './offline.html', true); request.onload = function() { if (request.status === 200) { // success // create offline element with HTML loaded from offline.html template var offlineMessageElement = document.createElement("div"); offlineMessageElement.setAttribute("id", "offline"); offlineMessageElement.innerHTML = request.responseText; document.getElementById("main").appendChild(offlineMessageElement); } else { // error retrieving file console.warn('Error retrieving offline.html'); } }; request.onerror = function() { // network errors console.error('Connection error'); }; request.send(); } } })();

This page.js file exposes the Page module, which contains our ViewModel vm and two functions, hideOfflineWarning and showOfflineWarning. The View Model ViewModel is a simple JavaScript literal that will be used throughout the application. The property arrivals on the ViewModel is Knockout’s observableArray, which automatically binds our HTML to a JavaScript array, allowing us to push and pop items onto our array in JavaScript and automatically update the page’s HTML.

The functions hideOfflineWarning and showOfflineWarning enable the rest of our application to call these functions to update the page’s UI that displays whether we are connected online. The showOfflineWarning adds a class of loading to our arrivals-list HTML element to fade the list, and then it retrieves the HTML file offline.html through XHR. Assuming that the file has been retrieved successfully (response.status === 200), we append this to our HTML. Of course, if we aren’t using service workers¹³ and the user is not connected to the Internet, then it would not be possible to retrieve offline.html, and so the user would see the browser’s offline page.

The business logic from where we retrieve the data from our API and bind it to our View Models and Views is found in arrivals.js¹⁴ and is standard MVVM functionality using Knockout. In the arrivals.js file, we simply initialize the services and View Models that we will be using throughout the application, and we expose a function — Arrivals.loadData() — that retrieves the data and binds it to the view model.

Web App Manifest Link

Let’s make our web app more app-like. A web app manifest file is a simple JSON file that follows the W3C’s specification¹⁵. With it, it is possible to run the web app in full-screen mode as a standalone application, to assign an icon that will get displayed when the application is installed on the device, and to assign a theme and background color to the app. In addition, Chrome on Android will proactively suggest that the user install the web app, via a web app install banner¹⁶. To display the installation prompt, your web app needs to:

have a valid web app manifest file,
be served over HTTPS,
have a valid service worker registered,
have been visited twice, with at least five minutes between each visit.

Web app install banner (View large version¹⁸)

manifest.json Link

{ "short_name": "Arrivals", "name": "Arrivals at Sky High", "description": "Progressive web application demonstration", "icons": [ { "src": "launcher-icon.png", "sizes": "48x48", "type": "image/png" }, { "src": "launcher-icon-96.png", "sizes": "96x96", "type": "image/png" }, { "src": "launcher-icon-144.png", "sizes": "144x144", "type": "image/png" }, { "src": "launcher-icon-192.png", "sizes": "192x192", "type": "image/png" }, { "src": "launcher-icon-256.png", "sizes": "256x256", "type": "image/png" } ], "start_url": "./?utm_source=web_app_manifest", "display": "standalone", "orientation": "portrait", "theme_color": "#29BDBB", "background_color": "#29BDBB" }

Let’s break down this manifest file:

short_name is a human-readable name for the application. In Chrome for Android, this is also the name accompanying the icon on the home screen.
name is also a human-readable name for the application and defines how the application will be listed.
description provides a general description of the web application.
icons defines an array of images of varying sizes that will serve as the application’s icon set. In Chrome for Android, the icon will be used on the splash screen, on the home screen and in the task switcher.
start_url is the starting URL of the application.
display defines the default display mode for the web application: fullscreen, standalone, minimal-ui or browser.
orientation defines the default orientation for the web application: portrait or landscape.
theme_color is the default theme color for the application. On Android, this is also used to color the status bar.
background_color defines the background color of the web application. In Chrome, it also defines the background color of the splash screen.
related_applications is not implemented in our example but is used to specify native application alternatives in the various app stores.

Add the manifest.json reference to the index.html file’s head tag:

<link rel="manifest" href="./manifest.json">

Once a user has added the web app to their home screen, they will be able to re-engage with your application immediately from their device, without having to directly open the browser. You can see how this is much more than a web bookmark.

Add to home screen in Chrome for Android

Service Workers

One of the more exciting aspects of progressive web apps is that they can work offline. Using service workers, it is possible to show data that was retrieved in previous sessions of the app (using IndexedDB¹⁹) or, alternatively, to show the application shell and inform the user that they are not connected to the Internet (the approach we’ve taken in this demo). Once the user reconnects, we can then retrieve the latest data from the server.

All of this is possible through service workers, which are event-driven scripts (written in JavaScript) that have access to domain-wide events, including network fetches. With them, we can cache all static resources, which could drastically reduce network requests and improve performance considerably, too.

Application Shell Link

The application shell is the minimum HTML, CSS and JavaScript required to power a user interface. A native mobile application includes the application shell as part of its distributable, whereas websites ordinarily request this over the network. Progressive web applications bridge this gap by placing the application shell’s resources and assets in the browser’s cache. In our Sky High application, we can see that our application shell consists of the top header bar, the fonts and any CSS required to render these elegantly.

To get started with service workers, we first need to create our service worker’s JavaScript file, sw.js, placed in the root directory.

sw.js Link

// Use a cacheName for cache versioning var cacheName = 'v1:static'; // During the installation phase, you'll usually want to cache static assets. self.addEventListener('install', function(e) { // Once the service worker is installed, go ahead and fetch the resources to make this work offline. e.waitUntil( caches.open(cacheName).then(function(cache) { return cache.addAll([ './', './css/style.css', './js/build/script.min.js', './js/build/vendor.min.js', './css/fonts/roboto.woff', './offline.html' ]).then(function() { self.skipWaiting(); }); }) ); }); // when the browser fetches a URL… self.addEventListener('fetch', function(event) { // … either respond with the cached object or go ahead and fetch the actual URL event.respondWith( caches.match(event.request).then(function(response) { if (response) { // retrieve from cache return response; } // fetch as normal return fetch(event.request); }) ); });

Let’s look more closely at our service worker. First, we are setting a cacheName variable. This is used to determine whether any changes have been made to our cached assets. For this example, we will be using a static name, meaning that our assets will not change or require updating.

self.addEventListener('install', function(e) { // declare which assets to cache }

The install event fires during the installation phase of the service worker and will fire only once if the service worker is already installed. Therefore, refreshing the page will not trigger the installation phase again. During the installation phase, we are able to declare which assets will be cached. In our example above, we are caching one CSS file, two JavaScript files, our fonts file, our offline HTML template and, of course, the application root. self.skipWaiting() forces the waiting service worker to become active.

So far, we have declared our service worker, but before we see it kick into effect, we need to reference it in our JavaScript. In our application, we register it in main.js

// Register the service worker if available. if ('serviceWorker' in navigator) { navigator.serviceWorker.register('./sw.js').then(function(reg) { console.log('Successfully registered service worker', reg); }).catch(function(err) { console.warn('Error whilst registering service worker', err); }); } window.addEventListener('online', function(e) { // Resync data with server. console.log("You are online"); Page.hideOfflineWarning(); Arrivals.loadData(); }, false); window.addEventListener('offline', function(e) { // Queue up events for server. console.log("You are offline"); Page.showOfflineWarning(); }, false); // Check if the user is connected. if (navigator.onLine) { Arrivals.loadData(); } else { // Show offline message Page.showOfflineWarning(); } // Set Knockout view model bindings. ko.applyBindings(Page.vm);

We’ve also included two event listeners to check whether the session’s state has changed from online to offline or vice versa. The event handlers then call the different functions to retrieve the data through Arrivals.loadData() and to enable or disable the offline message through Page.showOfflineWarning and Page.hideOfflineWarning, respectively. Our application also checks whether the user is currently online, using navigator.onLine²⁰, and either retrieves the data or shows the offline warning accordingly. And in the last line of main.js, we apply the Knockout bindings to our View Model Page.vm.

If we load our application for the first time (with Chrome Developer Tools), we will see nothing new. However, upon reloading, we will see that a number of network resource have been retrieved from the service worker. This is our application shell.

Application shell network resources, in Chrome Developer Tools (View large version²²)

Offline Test Link

A user running the application without an Internet connection (assuming that they have already been on the page) will simply result in the application shell and the offline warning being displayed — an improvement over Chrome’s prowling t-rex. Once the user has established a network connection, we disable the warning and retrieve the latest data.

Failing gracefully — Render a custom HTML page instead of Chrome’s default page (View large version²⁴)

The Guardian takes a particularly interesting approach when offline users access its website, providing a crossword puzzle:

The Guardian's offline crossword puzzle — The Guardian’s offline crossword puzzle (View large version²⁶)

Push Notifications Link

Push notifications allow users to opt in to timely updates from applications they trust, helping them to re-engage with the apps. Push notifications on the web²⁷ allow you to engage with your audience even when the browser is closed.

The Push API is supported in Chrome, Opera and Samsung’s browser and is under development in Firefox and Microsoft Edge. Unfortunately, there is no indication that the feature will be implemented in Safari.

Performance Link

One of the easiest wins with service workers is that we can improve performance with little to no effort. Comparing our website to itself before service workers were implemented, before we were retrieving over 200 KB upon page load; that is now reduced to 13 KB. On a regular 3G network, the page would have taken 3.5 seconds to load; now it takes 500 milliseconds.

These performance improvements are drastic because the application itself is very small and has limited functionality. Nevertheless, through the correct use of caching, it is possible to significantly improve performance and perceived performance, especially for users in places with low-connectivity.

Lighthouse Link

Google’s Chrome team has put together a tool for testing progressive web apps. Lighthouse³¹ runs in Node.js or as a Chrome plugin³² and can be found on GitHub, too.

To run a Lighthouse test, your website needs to be available online, meaning that you cannot test on localhost.

To start, download the npm package:

npm install -g GoogleChrome/lighthouse

Once that’s installed, run Chrome (version 52 onwards):

npm explore -g lighthouse -- npm run chrome lighthouse https://incredibleweb.github.io/pwa-tutorial/

The output of the Lighthouse run will be visible in the command line and will grade your website according to the progressive web app features and properties you have implemented — for example, whether you are using a manifest.json file or whether your page is available offline.

Conclusion Link

This article is merely an appetizer for progressive web apps. We could do a lot more to create that app-like experience users are looking for, whether by supporting push notifications with the Push API³³, making the app re-engageable, or using IndexedDB and background syncing³⁴ to improve the offline experience.

Cross-Browser Support

These are still early days for progressive web apps, and cross-browser support is still limited, especially in Safari and Edge. However, Microsoft openly supports progressive web apps and should be implementing more features by the end of the year.

Service workers and Cache API

Supported in Chrome, Firefox, Opera and Samsung’s browser. In development in Microsoft Edge, expected to be available by the end of 2016. Under consideration for Safari.
Add to home screen

Supported in Chrome, Firefox, Opera, Android Browser and Samsung’s browser. Microsoft seems to indicate that progressive web apps will be available as store listings. No plans for Safari as of yet.
Push API

Mostly supported in Chrome, Firefox, Opera and Samsung’s browser. In development in Microsoft Edge. No plans for Safari as of yet.

If more developers take advantage of the features offered by progressive web apps — which are relatively easy to implement and provide immediate rewards — then users will prefer consuming these web apps in supported browsers, hopefully convincing the other browser vendors to adapt.

Source Code Link

The entire source code for this tutorial is available in a Github repository³⁵, and the demo is available on GitHub Pages³⁶.

(da, al, il)

Footnotes Link

1 http://blog.gaborcselle.com/2012/10/every-step-costs-you-20-of-users.html
2 http://info.localytics.com/blog/push-messaging-drives-88-more-app-launches-for-users-who-opt-in
3 http://www.flipkart.com/
4 https://flights.airberlin.com/en-DE/progressive-web-app
5 #crossBrowser
6 https://developers.google.com/web/fundamentals/getting-started/your-first-progressive-web-app/
7 https://www.smashingmagazine.com/wp-content//uploads/2016/08/sky-high-screenshot-opt.png
8 https://www.smashingmagazine.com/wp-content//uploads/2016/08/sky-high-screenshot-opt.png
9 http://knockoutjs.com/
10 https://material.google.com/
11 https://addyosmani.com/blog/making-a-site-jank-free/
12 http://knockoutjs.com/documentation/introduction.html
13 #serviceWorker
14 https://github.com/IncredibleWeb/pwa-tutorial/blob/master/demo/js/arrivals.js
15 https://w3c.github.io/manifest/
16 https://developers.google.com/web/updates/2015/03/increasing-engagement-with-app-install-banners-in-chrome-for-android
17 https://www.smashingmagazine.com/wp-content//uploads/2016/08/web-app-install-banner-opt.png
18 https://www.smashingmagazine.com/wp-content//uploads/2016/08/web-app-install-banner-opt.png
19 https://developer.mozilla.org/en/docs/Web/API/IndexedDB_API
20 https://developer.mozilla.org/en-US/docs/Web/API/NavigatorOnLine/onLine
21 https://www.smashingmagazine.com/wp-content//uploads/2016/08/app-shell-opt.png
22 https://www.smashingmagazine.com/wp-content//uploads/2016/08/app-shell-opt.png
23 https://www.smashingmagazine.com/wp-content//uploads/2016/08/sky-high-offline-opt.png
24 https://www.smashingmagazine.com/wp-content//uploads/2016/08/sky-high-offline-opt.png
25 https://www.smashingmagazine.com/wp-content//uploads/2016/08/the-guardian-opt.jpg
26 https://www.smashingmagazine.com/wp-content//uploads/2016/08/the-guardian-opt.jpg
27 https://developers.google.com/web/updates/2015/03/push-notifications-on-the-open-web
28 https://www.smashingmagazine.com/wp-content//uploads/2016/08/pwa-push-opt.png
29 https://jakearchibald-gcm.appspot.com/
30 https://www.smashingmagazine.com/wp-content//uploads/2016/08/pwa-push-opt.png
31 https://github.com/GoogleChrome/lighthouse
32 https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk
33 https://developer.mozilla.org/en/docs/Web/API/Push_API
34 https://developers.google.com/web/updates/2015/12/background-sync
35 https://github.com/IncredibleWeb/pwa-tutorial
36 https://incredibleweb.github.io/pwa-tutorial/

Apps Techniques Tools

Experience Design Essentials: Animated Microinteractions In Mobile Apps

August 9, 2016 by Curt Long

Developers “Own” The Code, So Shouldn’t Designers “Own” The Experience?

August 8, 2016 by Curt Long

Opinion ColumnDevelopers “Own” The Code, So Shouldn’t Designers “Own” The Experience?

We’ve all been there. You spent months gathering business requirements, working out complex user journeys, crafting precision interface elements and testing them on a representative sample of users, only to see a final product that bears little resemblance to the desired experience.

Maybe you should have been more forceful and insisted on an agile approach, despite your belief that the organization wasn’t ready? Perhaps you should have done a better job with your pattern portfolios, ensuring that the developers used your modular code library rather than creating five different variations of a carousel. Or, maybe you even should’ve sat next to the development team every day, making sure what you designed actually came to pass.

Instead you’re left with a jumble of UI elements, with all the subtlety stripped out. Couldn’t they see that you worked for days getting the transitions just right, only for them to drop in a default animation library? And where on earth did that extra check-out step come from. I bet marketing threw that in at the last minute. You knew integration was going to be hard and compromises would need to be made, but we’re supposed to be making the users lives easier here, not the tech team.

When many people are involved in a project, it is very important to make sure that they have a common understanding of the problem and its solution. (Image credit: The Next Web²)

Of course, there are loads of good reasons why the site is this way. Different teams with varying levels of skill working on different parts of the project, a bunch of last-minute changes shortening the development cycle, and a whole host of technical challenges. Still, why couldn’t the development team come and ask for your advice on their UI changes? You don’t mess with their code, so why do they have to change your designs around? Especially when the business impact could be huge! You’re only round the corner and would have been happy to help if they had just asked.

While the above story may be fictional, it’s a sentiment I hear from all corners of the design world, whether in-house or agency side. A carefully crafted experienced ruined by a heavy-handed development team.

This experience reminds me of a news story I saw on a US local news channel several years ago. A county fair was running an endurance competition where the last person remaining with their hand on a pickup truck won the prize. I often think that design is like a massive game of “touch the truck”, with the development team always walking away with the keys at the end of the contest. Like the last word in an argument, the final person to come in contact with the site holds all the power and can dictate how it works or what it looks like. Especially if they claim that the particular target experience isn’t “technically possible”, which is often shorthand for “really difficult”, “I can’t be bothered doing it that way” or “I think there’s a better way of doing it so am going to pull the dev card”.

Now I know I’m being unfairly harsh about developers here and I don’t mean to be. There are some amazingly talented technologists out there who really care about usability and want to do the best for the user. However, it often feels as though there’s an asymmetric level of respect between disciplines due to a belief that design is easy and therefore something everybody can have an opinion on, while development is hard and only for the specially initiated. So while designers are encouraged (sometimes expected) to involve everybody in the design process, they often aren’t afforded the same luxury.

To be honest, I don’t blame them. After all, I know just enough development to be dangerous, so you’d be an idiot if you wanted my opinion on database structure and code performance (other than I largely think performance is a good thing). Then again I do know enough to tell when the developers are fudging things and it’s always fun to come back to them with a working prototype of something they said was impossible or take months to implement — but I digress.

The problem is, I think a lot of developers are in the same position about design — they just don’t realize it. So when they make a change to an interface element based on something they had heard at a conference a few years back, they may be lacking important context. Maybe this was something you’ve already tested and discounted because it performed poorly. Perhaps you chose this element over another for a specific reason, like accessibility? Or perhaps the developers opinions were just wrong, based on how they experience the web as superusers rather than an average Jo.

Now let’s get something straight here. I’m not saying that developers shouldn’t show an interest in design or input into the design process. I’m a firm believer in cross-functional pairing and think that some of the best usability solutions emanate from the tech team. There are also a lot of talented people out there who span a multitude of disciplines. However, at some point the experience needs to be owned, and I don’t think it should be owned by the last person to open the HTML file and “touch the truck”.

So, if good designers respect the skill and experience great developers bring to the table, how about a little parity? If designers are happy for developers to “own the code”, why not show a similar amount of respect and let designers “own the experience”?

Communication is key, so be available. — Everybody has an opinion. However, it’s not a good enough reason to just dive in and start making changes. Image credit: Open Source Way⁴

Doing this is fairly simple. If you ever find yourself in a situation where you’re not sure why something was designed in a particular way, and think it could be done better, don’t just dive in and start making changes. Similarly, if you hit a technical roadblock and think it would make your lives easier to design something a different way, go talk to your designer. They may be absolutely fine with your suggested changes, or they may want to go away and think about some other ways of solving the same problem.

After all, collaboration goes both ways. So if you don’t want designers to start “optimizing” your code on the live server, outside your version control processes, please stop doing the same to their design.

(vf, il)

Footnotes Link

1 https://www.flickr.com/photos/thenextweb/5664545340/
2 https://www.flickr.com/photos/thenextweb/5664545340/
3 https://www.flickr.com/photos/opensourceway/4371000846
4 https://www.flickr.com/photos/opensourceway/4371000846

Communication Workflow

Apps JavaScript Performance

A Glimpse Into The Future With React Native For Web

August 24, 2016August 7, 2016 by Curt Long

A Glimpse Into The Future With React Native For Web

One of the hardest decisions to make when starting a new app is which platforms to target. A mobile app gives you more control and better performance but isn’t as universal as the web. If you’re making a mobile app, can you afford to support both iOS and Android? What about trying to build a mobile app and a responsive web app? Ultimately, the best experience for your customers is for your app to work everywhere, but the development and maintenance costs of that can be prohibitive.

We have already seen how¹ React Native can help you make iOS and Android apps with a shared code base, without sacrifices in quality. But what about the web? This is exactly the problem the React Native for Web³¹² project is trying to solve. Instead of forcing you to maintain two separate code bases for your mobile and web apps, or making a hybrid app, with all its compromises³, React Native for Web is intended to let you write a single app that runs in a browser using standard web technologies, or on iOS and Android as a real native mobile app. While I don’t think the project is ready for production use yet, its potential success could mark a massive change in how large multi-platform applications are built. Let’s jump in!

How It Works Link

You might be thinking, “Wait! doesn’t React already work on the web?” You wouldn’t be wrong. Unfortunately, traditional React and React Native build on a different set of primitives. React uses <div>, <p> and <input>, whereas React Native uses <View>, <Text> and <TextInput>. There are good historical reasons for this, since the building blocks of a web page and of a mobile app are quite different. Nonetheless, it would be great if we could use a single set of shared components.

React Native for Web’s solution is to provide browser-compatible implementations of React Native’s components — meaning, for example, that the <View> of React Native has a DOM-based version that knows how to render to a <div>. While not every React Native component is supported, enough of them are that you could (hopefully) share the majority of your code base.

In addition to the components themselves, styles for React and React Native are written differently. With React, most people use plain CSS or a preprocessor such as Sass⁴. But in React Native, all styles are written in JavaScript, because there is no DOM and no selectors. With React Native for Web, styles are written just like they would be for React Native, rather than with CSS. This has the benefit of allowing you to write a single set of styles, which will work on both native mobile and the web.

We’ll take a deeper look later at how these ideas work in practice and at how much code is actually reusable. First, let’s get a sample app going.

Starting A New React Native Project Link

To get started, we will need to set up our project. At first, this will just be a regular React Native app, and then we’ll add React Native for Web. If you are following along, you’ll need to complete React Native’s “Getting Started³²⁵” guide before heading into the next section.

Once you’ve got React Native installed, you can run the following command from your terminal:

react-native init ReactNativeWeb

This will make a new React Native project named ReactNativeWeb. After it has finished installing, you can cd ReactNativeWeb, and then react-native run-ios or react-native run-android. If everything has gone correctly, you should see a friendly welcome message on your iOS or Android simulator or device.

⁶

React Native iOS welcome screen (View large version⁷)

React Native Android welcome screen (View large version⁹)

Notice that React Native has created two JavaScript files in our project’s directory: index.android.js and index.ios.js. You can edit any of the styles or logic in these files and see those changes update in the running app. As you can probably guess, the .android.js file is for Android, and the .ios.js file is for iOS. Fortunately, separate files are only needed when you want multiple versions of a given file per platform. Most of the time, you’ll have a single file per component.

Managing Dependencies Link

Before we can get our app running in a web browser, we’ll need to get a bit of package installation out of the way. First, run the following to install both the react-native-web package and the official React web packages.

npm i react react-dom react-native-web --save

(You might see some errors about peer dependencies from this command. You should be safe to ignore them, because they didn’t cause me any problems. If newer versions of any of these packages are out when you run the commands, though, you might need to adjust the installed versions.)

At this point, your package.json file should look something like this:

{ "name": "ReactNativeWeb", "version": "0.0.1", "private": true, "scripts": { "start": "node node_modules/react-native/local-cli/cli.js start" }, "dependencies": { "react": "15.1.0", "react-dom": "15.1.0", "react-native": "0.28.0", "react-native-web": "0.0.25" } }

While we have what seems to be everything required for our React Native app to run in a web browser, we must take a brief detour to consider the realities of web development. React Native’s packager compiles your ECMAScript 6 code to something that a phone’s JavaScript engine can understand, but it won’t help us in the browser. If we tried to run our app in a web browser right now, it would quickly fail due to syntax errors.

To solve this problem, we will use Babel¹⁰ and webpack¹¹. Babel will compile our ECMAScript 6 code into browser-compatible ECMAScript 5, and webpack will bundle the compiled JavaScript, as well as just generally make development faster. (There are other options for this. If you prefer another compiler or bundler, feel free to use it instead.)

Here are the installation commands to run:

npm i webpack babel-loader babel-preset-react babel-preset-es2015 --save

npm i webpack-dev-server --save-dev

Here, babel-loader and webpack-dev-server will be used to bundle and serve our JavaScript, while babel-preset-react and babel-preset-es2015 tell Babel which plugins we need to compile our code.

Here is what your package.json file should look like now:

{ "name": "ReactNativeWeb", "version": "0.0.1", "private": true, "scripts": { "start": "node node_modules/react-native/local-cli/cli.js start" }, "dependencies": { "babel-loader": "6.2.4", "babel-preset-es2015": "6.9.0", "babel-preset-react": "6.5.0", "react": "15.1.0", "react-dom": "15.1.0", "react-native": "0.28.0", "react-native-web": "0.0.25", "webpack": "1.13.1" }, "devDependencies": { "webpack-dev-server": "1.14.1" } }

Configuring Link

Those are all of the packages we will need. But more setup is required before our app will work in a browser.

webpack.config.js Link

First, we’ll make a webpack config file. This file tells webpack how to build, bundle and serve our compiled code. In addition, we are going to use the alias property to automatically replace imports on react-native with react-native-web. This file should be placed in your project’s root.

const webpack = require('webpack'); module.exports = { entry: { main: './index.web.js', }, module: { loaders: [ { test: /.js?$/, exclude: /node_modules/, loader: 'babel', query: { presets: ['es2015', 'react'], }, }, ], }, resolve: { alias: { 'react-native': 'react-native-web', }, }, };

index.html Link

Now, we need to create an HTML file for our app to run in. This will be pretty simple because it will just be a skeleton to attach our React app to.

<!DOCTYPE html> <html> <head> <title>React Native Web</title> <meta charSet="utf-8" /> <meta content="initial-scale=1,width=device-width" name="viewport" /> </head> <body> <div></div> <script type="text/javascript" src="/bundle.js"></script> </body> </html>

index.web.js Link

Finally, we must make an index JavaScript file for the web. The contents of this file can be the same as index.ios.js or index.android.js, but with one additional line to attach to the DOM. The div with the ID react-app from our HTML file must be selected and then used in the call to AppRegister.runApplication.

import React, { Component } from 'react'; import { AppRegistry, StyleSheet, Text, View } from 'react-native'; class ReactNativeWeb extends Component { render() { return ( <View style={styles.container}> <Text style={styles.welcome}> Welcome to React Native! </Text> <Text style={styles.instructions}> To get started, edit index.web.js </Text> <Text style={styles.instructions}> Press Cmd+R to reload </Text> </View> ); } } const styles = StyleSheet.create({ container: { flex: 1, justifyContent: 'center', alignItems: 'center', backgroundColor: '#F5FCFF', }, welcome: { fontSize: 20, textAlign: 'center', margin: 10, }, instructions: { textAlign: 'center', color: '#333333', marginBottom: 5, }, }); AppRegistry.registerComponent('ReactNativeWeb', () => ReactNativeWeb); AppRegistry.runApplication('ReactNativeWeb', { rootTag: document.getElementById('react-app') });

Now, just run ./node_modules/.bin/webpack-dev-server --inline to start webpack, and open your browser to http://localhost:8080/¹². Fingers crossed, you will see a familiar welcome message but in the browser!

React Native web welcome screen (View large version¹⁴)

With all of that setup complete, we are ready to start tinkering!

Experimenting With The Code Link

Create a FriendsList.js Component Link

Let’s start by making a friends list. This will be a good simple stress test of React Native for Web, because we need to use a few different components for it: <Image>, <Text>, <View> and <ListView>.

import React, { Component } from 'react'; import { Image, ListView, StyleSheet, Text, View, } from 'react-native'; const styles = StyleSheet.create({ list: { marginTop: 20, }, friend: { flexDirection: 'row', alignItems: 'center', justifyContent: 'flex-start', }, avatar: { margin: 10, width: 50, height: 50, borderRadius: 25, }, name: { fontSize: 18, color: '#000', } }); export default class FriendsList extends Component { constructor(props) { super(props); const ds = new ListView.DataSource({ rowHasChanged: (r1, r2) => r1 !== r2 }); this.state = { ds: ds.cloneWithRows(props.friends), }; } render() { return ( <ListView dataSource={this.state.ds} style={styles.list} renderRow={(friend) => <View style={styles.friend}> <Image style={styles.avatar} source={{ uri: friend.avatarUrl }} /> <Text style={styles.name}>{friend.firstName} {friend.lastName}</Text> </View> } /> ); } }

We’ll need to edit our index files, too, so that a friends array gets passed in as a prop.

import FriendsList from './FriendsList'; import React, { Component } from 'react'; import { AppRegistry, Text, View } from 'react-native'; const friends = [ { id: 1, firstName: 'Jane', lastName: 'Miller', avatarUrl: 'https://placehold.it/100x100', }, { id: 2, firstName: 'Kate', lastName: 'Smith', avatarUrl: 'https://placehold.it/100x100', }, { id: 3, firstName: 'Kevin', lastName: 'Yang', avatarUrl: 'https://placehold.it/100x100', }, ]; class ReactNativeWeb extends Component { render() { return <FriendsList friends={friends} />; } } AppRegistry.registerComponent('ReactNativeWeb', () => ReactNativeWeb);

Upon running it in iOS or Android, you should see something like this:

React Native iOS friends list (View large version¹⁶)

Looks good so far. Let’s see the web version:

¹⁷

React Native web friends list. (View large version¹⁸)

Uh oh! Turns out there isn’t any web support yet for ListView’s DataSource, effectively making ListView completely unusable.

Friend.js Link

We can work around this lack of support for now. Let’s make a Friend component for the individual rows, but have a FriendsList component per platform. This will separate out the shared code that works everywhere but allow us to customize each platform where we need to.

import React, { Component } from 'react'; import { Image, StyleSheet, Text, View, } from 'react-native'; const styles = StyleSheet.create({ friend: { flexDirection: 'row', alignItems: 'center', justifyContent: 'flex-start', }, avatar: { margin: 10, width: 50, height: 50, borderRadius: 25, }, name: { fontSize: 18, color: '#000', } }); export default class Friend extends Component { render() { return ( <View style={styles.friend}> <Image style={styles.avatar} source={{ uri: this.props.avatarUrl }} /> <Text style={styles.name}>{this.props.firstName} {this.props.lastName}</Text> </View> ); } }

FriendsList.ios.js Link

import Friend from './Friend'; import React, { Component } from 'react'; import { Image, ListView, StyleSheet, Text, View, } from 'react-native'; const styles = StyleSheet.create({ list: { marginTop: 20, }, }); export default class FriendsList extends Component { constructor(props) { super(props); const ds = new ListView.DataSource({ rowHasChanged: (r1, r2) => r1 !== r2 }); this.state = { ds: ds.cloneWithRows(props.friends), }; } render() { return ( <ListView dataSource={this.state.ds} style={styles.list} renderRow={(friend) => <Friend key={friend.id} avatarUrl={friend.avatarUrl} firstName={friend.firstName} lastName={friend.lastName} /> } /> ); } }

On iOS, our ListView usage code is unchanged. (I’m leaving out the Android code example here and for the rest of the article, for brevity. The Android and iOS code can be the same for the rest of the code samples.)

FriendsList.web.js Link

import Friend from './Friend'; import React, { Component } from 'react'; import { Image, Text, View, } from 'react-native'; export default class FriendsList extends Component { render() { return ( <View> {this.props.friends.map(friend => <Friend key={friend.id} avatarUrl={friend.avatarUrl} firstName={friend.firstName} lastName={friend.lastName} /> )} </View> ); } }

Now, for the web, we use the map function to render each Friend, similar to traditional React.

React Native friends list on the web, now working (View large version²⁰)

Much better. At this point, hearing that ListView requires workarounds might be enough to make you think that React Native for Web isn’t ready for production use. I am inclined to agree, particularly since lists constitute a large percentage of many applications. How much it matters will vary depending on the project, though. On the bright side, all of our other React Native code so far has been completely reusable. In any case, I am still interested in exploring it further, because there is still much potential in the ideas on display here. Let’s continue with our sample app.

Instead of hardcoding a handful of list items, we can use JSON Generator²¹ to create a long list for us to work with. If you haven’t used it before, JSON Generator is a great tool for creating dummy and development data. Here is the structure I have defined, which adds a few fields on top of what we already have.

[ '{{repeat(200)}}', { id: '{{guid()}}', firstName: '{{firstName()}}', lastName: '{{surname()}}', avatarUrl: 'https://placehold.it/100x100', isOnline: '{{bool()}}', company: '{{company()}}', email: '{{email()}}' } ]

And here is a snippet of some of the generated data:

[ { "id": "c5368bbe-adfb-424f-ade3-9d783befa2b6", "firstName": "Hahn", "lastName": "Rojas", "avatarUrl": "https://placehold.it/100x100", "isOnline": true, "company": "Orbixtar", "email": "hahnrojas@orbixtar.com" }, { "id": "15ef2834-3ba5-4621-abf1-d771d39c2dd6", "firstName": "Helen", "lastName": "Stout", "avatarUrl": "https://placehold.it/100x100", "isOnline": true, "company": "Ebidco", "email": "helenstout@ebidco.com" }, { "id": "1ef05de1-fd8e-41ae-85ac-620b6d716b62", "firstName": "Floyd", "lastName": "Mcpherson", "avatarUrl": "https://placehold.it/100x100", "isOnline": false, "company": "Ecraze", "email": "floydmcpherson@ecraze.com" }, … ]

To use it, just take your generated JSON and replace our friends array declaration from before. Of course, you can move that data into its own file if you’d like, so that your code files aren’t cluttered with data. In a real application, we would get that data from an API server.

Friend.js Link

Next, we can add these new fields to the Friend component.

… render() { return ( <View style={styles.friend}> <Image style={[styles.avatar, { borderColor: this.props.isOnline ? '#9d9' : '#d99' }]} source={{ uri: this.props.avatarUrl }} /> <View> <Text style={styles.name}>{this.props.firstName} {this.props.lastName}</Text> <Text style={styles.company}>{this.props.company}</Text> <Text style={styles.email}>{this.props.email}</Text> </View> </View> ); } …

FriendsList.js Link

Next, add them as props in each platform’s FriendsList.

… <Friend key={friend.id} avatarUrl={friend.avatarUrl} firstName={friend.firstName} lastName={friend.lastName} isOnline={friend.isOnline} company={friend.company} email={friend.email} /> …

React Native long friends list for iOS — React Native’s long friends list for iOS (View large version²³)

React Native long friend list web — React Native’s long friends list for the web (View large version²⁵)

So far so good. It is encouraging to see that the core components seem to work well.

Friend.js Link

Next, we can add an animation with a transformation to see how well those work. Let’s make it so that when you tap a row, it animates left and right before returning to its initial position. We will need to add imports for Animated and TouchableOpacity, and wire up the animation and press handler.

import { Animated, TouchableOpacity, … } from 'react-native'; … export default class Friend extends Component { constructor(props) { super(props); this.state = { translateValue: new Animated.Value(0), }; } animate() { Animated.sequence([ Animated.timing(this.state.translateValue, { toValue: 50, duration: 200, }), Animated.timing(this.state.translateValue, { toValue: -50, duration: 200, }), Animated.timing(this.state.translateValue, { toValue: 0, duration: 200, }) ]).start(); } render() { return ( <TouchableOpacity onPress={() => this.animate()} style={[styles.friend, { transform: [{ translateX: this.state.translateValue }]}]}> <Image style={[styles.avatar, { borderColor: this.props.isOnline ? '#9d9' : '#d99' }]} source={{ uri: this.props.avatarUrl }} /> <View> <Text style={styles.name}>{this.props.firstName} {this.props.lastName}</Text> <Text style={styles.company}>{this.props.company}</Text> <Text style={styles.email}>{this.props.email}</Text> </View> </TouchableOpacity> ); } }

Looks good on mobile.

React Native iOS animation (View large version²⁷)

What about the web?

²⁸

React Native web animation (View large version²⁹)

No luck. Our TouchableOpacity throws an error when pressed. Apparently, this will be fixed³⁰ in the next release and is only present for our particular combination of versions. Attempting to run the animation without using TouchableOpacity causes the same error, too.

I am going to stop here, but if you want to continue on your own, here is a list of topics you could research next:

How well do the remaining React Native components and APIs work? We’ve seen that some definitely don’t work, but we don’t yet have a comprehensive list of support.
You could explore more extensive styling work, including media queries.
React Native for Web supports server rendering. This could be particularly cool because, if it works, it would mean that you could have a single code base driving native mobile applications and a responsive web app that is SEO-optimized.

Conclusion Link

As you can tell, React Native for Web is definitely not ready for production. There are too many unsupported components, even in our small demo app, for me to feel confident about using it in a real project. The most encouraging thing to me, though, is that the pieces that do work seem to completely work, and the parts that don’t, fail entirely. I find that much preferable to the entire thing just kind of working. At the moment, it seems like the project just needs more time to build support. If everything was only 50% functional, I would view that as a sign that the approach is fundamentally broken.

Despite the problems, I still think this is a very exciting project and worth keeping an eye on.

Resources Link

React Native for Web³¹², GitHub
“Getting Started³²⁵,” React Native

(da, ml, al)

Footnotes Link

1 https://www.smashingmagazine.com/2016/04/consider-react-native-mobile-app/
2 https://github.com/necolas/react-native-web
3 http://www.apptentive.com/blog/5-points-to-consider-before-making-a-hybrid-mobile-app/
4 http://sass-lang.com/
5 https://facebook.github.io/react-native/docs/getting-started.html
6 https://www.smashingmagazine.com/wp-content/uploads/2016/07/01-react-native-welcome-ios-opt.png
7 https://www.smashingmagazine.com/wp-content/uploads/2016/07/01-react-native-welcome-ios-opt.png
8 https://www.smashingmagazine.com/wp-content/uploads/2016/07/02-react-native-welcome-android-opt.png
9 https://www.smashingmagazine.com/wp-content/uploads/2016/07/02-react-native-welcome-android-opt.png
10 https://babeljs.io/
11 https://webpack.github.io/
12 http://localhost:8080/
13 https://www.smashingmagazine.com/wp-content/uploads/2016/07/03-react-native-welcome-web-opt.png
14 https://www.smashingmagazine.com/wp-content/uploads/2016/07/03-react-native-welcome-web-opt.png
15 https://www.smashingmagazine.com/wp-content/uploads/2016/07/04-react-native-friends-ios-opt.png
16 https://www.smashingmagazine.com/wp-content/uploads/2016/07/04-react-native-friends-ios-opt.png
17 https://www.smashingmagazine.com/wp-content/uploads/2016/07/05-react-native-friends-web-opt.png
18 https://www.smashingmagazine.com/wp-content/uploads/2016/07/05-react-native-friends-web-opt.png
19 https://www.smashingmagazine.com/wp-content/uploads/2016/07/06-react-native-friends-web-2-opt.png
20 https://www.smashingmagazine.com/wp-content/uploads/2016/07/06-react-native-friends-web-2-opt.png
21 http://www.json-generator.com/
22 https://www.smashingmagazine.com/wp-content/uploads/2016/07/07-react-native-friends-2-ios-opt.png
23 https://www.smashingmagazine.com/wp-content/uploads/2016/07/07-react-native-friends-2-ios-opt.png
24 https://www.smashingmagazine.com/wp-content/uploads/2016/07/08-react-native-friends-2-web-opt.png
25 https://www.smashingmagazine.com/wp-content/uploads/2016/07/08-react-native-friends-2-web-opt.png
26 https://www.smashingmagazine.com/wp-content/uploads/2016/07/09-react-native-ios-animation-opt.gif
27 https://www.smashingmagazine.com/wp-content/uploads/2016/07/09-react-native-ios-animation-opt.gif
28 https://www.smashingmagazine.com/wp-content/uploads/2016/07/10-react-native-web-animation-opt.png
29 https://www.smashingmagazine.com/wp-content/uploads/2016/07/10-react-native-web-animation-opt.png
30 https://github.com/necolas/react-native-web/issues/150
31 https://github.com/necolas/react-native-web
32 https://facebook.github.io/react-native/docs/getting-started.html

Web Development Reading List #148: CSS Color Syntax Change, Browser News, And Hidden Expectations

August 24, 2016August 4, 2016 by Curt Long

Web Development Reading List #148: CSS Color Syntax Change, Browser News, And Hidden Expectations

I shut down my browser on Wednesday, accidentally having a setting switched on that clears history and all sessions. First, I was sad to have lost many tabs with articles I stored “for later”. At the same time, it felt refreshing, liberating to have a clean browser window with zero tabs open. So my new goal is to start work in the morning with a completely clean browser window at least once a week.

In other news: I spent several hours fixing broken links this week, and as a result I can’t say how happy I am that archive.is¹ and archive.org² exist to prevent content from disappearing forever. Still, some of the resources I found broken have left forever. So remind yourself about redirecting content.

News Link

There’s a big change coming up for how we write colors in CSS. Tab Atkins recently changed the color functions syntax³ in the CSS specification. So in future, we will write rgb(0 255 0 / 50%) instead of rgba(0, 255, 0, 50%). This might sound awkward after years of doing it differently, but the reason for it are the new color functions available in CSS Colors Level 4, including color(). You can read more about this in Tab’s blog post, but for now be assured that the old syntax is likely to be supported forever in our browsers thanks to legacy support.
Opera 39 and Chromium 52 hit the streets this week and with them a couple of new features⁴: The Fetch API now supports a custom referrer policy, Performance Observer⁵ is supported, just like alpha channel for RGB colors in hex notation (#ffffff50), and CSP 3’s strict-dynamic directive is now available as well.
The new Docker for Mac and Windows is finally production-ready⁶ after several months in beta. Great news for all users who eagerly awaited it but always had issues with the previous version (i.e. disk and permission management problems).
Big news from Mozilla this week: With Firefox 48⁷, the multi-process engine e10s is now enabled for many users, making Firefox much more robust, faster and more reliable. Also, protection against harmful downloads has been improved⁸ and unsigned/unverified add-ons won’t load anymore. Web Extensions support⁹ including CSP enforcements for web extensions is also new, just like the about:debugging developer page. For developers, the DevTools come with an improved font inspector, calc() is now supported for line-height and can be nested, and, last but not least, support for the CSP directive upgrade-insecure-requests has been added, too.
Microsoft pushed Edge 14 this week¹⁰ and with it a lot of great new things¹¹. Notably, the new version got a lot of accessibility improvements and now competes as one of the best browsers in the HTML5 Accessibility test¹⁴¹². New features also include extensions and pinned tabs and performance got better to improve battery life, too. Fellow developers will be happy to hear about web notifications, the Fetch API, Beacon Interface, JavaScript’s asyncawait, and support for <time> and WOFF2.

¹³

The new version of Edge, Edge 14, got a lot of improvements and now scores 100% in the HTML5 Accessibility test¹⁴¹².

General Link

Dave Rupert reflected on hidden expectations¹⁵ and why the hardest parts of the web are the ones the client doesn’t see. Accessibility, security, and performance serve very well as main examples for such hidden expectations.

Concept & Design Link

In our industry, it’s important to have a connected workflow between design and development¹⁶ to make sure we’re aligned and to make real collaboration possible. Subjects like “avoiding assumptions, team up with our peers or sharing knowledge” will help us work together in a better way, says Simon Colijn.

Tools & Workflows Link

Users don’t care what tools we use; they care when we ship something useful. A great presentation by Liz Abinante on the simplicity of tooling¹⁷ and reasonable choices¹⁸.
We take GitHub for granted. We pay for it and we use it as the primary end point for our git-repositories. Now Fabio Akita shares why it’s the more expensive option and how you can use the open-source alternative gitlab¹⁹ on a pre-configured VPS that is cheaper and more flexible. At least worth reading.

Security Link

Proofpoint published a very interesting in-depth analysis of a big malvertising network²⁰ that they found in the wild and that hid itself from plain sight by using steganography and file whitelisting. There’s evidence that they targeted a daily traffic of 1-5 million high-quality client hits.
Mathy Vanhoef and Tom Van Goethem presented a new HEIST-attack on HTTPS pages to steal SSNs, email addresses, and more. You can view the slides²¹ (PDF) or read the write-up²² (PDF) to understand the attack and what you can do to prevent it.
Mike West, one of the main persons pushing security web standards at the moment, proposes to introduce an origin-wide policy manifest²³ to reduce the risk that security policies aren’t applied to specific resources. The proposal suggests to use a file in the /.well-known/origin-policy/[name-goes-here] directory on the origin server, adapting an already used folder name and path.
The well-known security researcher Jonathan Zdziarski found an issue in Whatsapp’s iOS app that seems wide-spread in iOS apps in general: Deleted chats aren’t deleted²⁴, which means that forensic experts could reconstruct them. Any app that uses SQLite on iOS has the same issue since deleted entries are only set “free” to be overwritten instead of actually deleted. In fact, Apple’s Messages app faces the same issues, and cloud sync makes this even worse as it spreads the deleted information to other devices. Jonathan finally shows how to implement an SQLite database in an iOS app to prevent this issue.

A wide-spread issue in iOS apps that use SQLite: Deleted entries aren’t deleted²⁶ but only set free to be overwritten. (Image credit: Jonathan Zdziarski²⁷)

Privacy Link

The Battery Status API in general sounds like a great addition to our web platform. Initially built by Mozilla to complete the API-set on the web, we can use it on websites to reduce the amount of interactivity and animation or serve videos in low resolutions when the battery is nearly empty, for example. Lukasz Olejnik, however, found out that this API is actually already used²⁸ as a user tracking identifier by ad networks and others. And last but not least, it can also be used to charge more for a service when a user’s battery is low — as reportedly done by Uber²⁹.

Web Performance Link

Mattias Geniar had a look at Google’s new QUIC protocol³⁰ that uses UDP instead of TCP and manages to be more reliable and faster — an ideal candidate as a successor to the TCP protocol. While it’s still at an early stage, the IETF is considering to make it a standard, Google uses it for some of their services already, and several server and browser vendors have plans to implement it, too.
For very big websites, we often tend to use a CMS, as this seems to be the best option at first glance. But what about choosing a static site generator for better performance and less security risks? Stefan Baumgartner shares his experience with using static site generators at scale³¹ and how they even built something like a content management system around it.

JavaScript Link

React is a bit different when it comes to technical design decisions. Chris James Hycner looks into SVG icon systems for React.js³² and how to build a well-working module for it.
“Add this JS-snippet to the project.” — a request that developers hear quite often. Kevin J. Dolan shares his eye-opening experience with a QA-person on why it’s a very, very bad idea to follow such requests blindly and why you shouldn’t include external third-party JavaScript references without extensive reviews³³.
Ben Frain explains the native JavaScript array methods³⁴ and how they differ from each other. A great introduction (or reminder) of what we can use today to get data out of arrays.

CSS/Sass Link

For long articles, a scroll indicator can be very useful to indicate the reading progress. Most people use some sort of JavaScript code to do this (which is calculation-expensive); some people, however, find clever tricks to do it with CSS. The CSS-only scroll indicator³⁵ by Mike Riethmuller is an awesome show-off of using gradients, viewport units and a pseudo-element.

CSS only scroll indicator³⁶ by Mike Riethmuller (MadeByMike³⁷) on CodePen³⁸.

CSS-only scroll indicator by Mike Riethmuller.

Work & Life Link

Hannah Rosefield puts exhaustion, the ‘status symbol’ of today, into perspective³⁹.
Tom Bartel shares some great thoughts on recalibrating your productivity sensors as a developer⁴⁰. Reframe your work, whether it’s managing people, talking to others, or actual coding work whenever you think you’re not productive. Most of the time it’s simply untrue.

Going Beyond… Link

Simon St. Laurent on decentralizing the web⁴¹. Some useful thoughts about our current lock-in on technology, service providers, and centralized solutions, and how we might be able to break that up again to unlock the real power of the web.
Katharine Viner writes about how social media swallowed the news⁴² and how the consequences of this go far beyond journalism. Does the truth even matter any more? An interesting essay on how well-done social marketing has an enormous influence on the decisions people make — no matter if it’s about buying a product or making a political decision.
Since the financial crisis, the private equity industry has become hugely influential. The New York Times curated a lovely, interactive story about how private equity plays out in your daily life⁴³.

And with that, I’ll close for this week. If you like what I write each week, please support me with a donation⁴⁴ or share this resource with other people. You can learn more about the costs of the project here⁴⁵. It’s available via email, RSS and online.

— Anselm

Footnotes Link

1 https://archive.is/
2 https://archive.org/
3 http://www.xanthir.com/b4iW0
4 https://dev.opera.com/blog/opera-39/
5 https://developers.google.com/web/updates/2016/06/performance-observer
6 https://blog.docker.com/2016/07/docker-for-mac-and-windows-production-ready/
7 https://blog.mozilla.org/blog/2016/08/02/exciting-improvements-in-firefox-for-desktop-and-android/
8 https://blog.mozilla.org/security/2016/08/01/enhancing-download-protection-in-firefox/
9 https://blog.mozilla.org/addons/2016/04/29/webextensions-in-firefox-48/
10 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/14393/?compareWith=10586
11 https://blogs.windows.com/msedgedev/2016/08/04/introducing-edgehtml-14/
12 http://www.html5accessibility.com/
13 http://www.html5accessibility.com/
14 http://www.html5accessibility.com/
15 http://daverupert.com/2016/08/hidden-expectations/
16 http://simon.fyi/articles/aligning-design-and-development
17 https://twitter.com/AndyHieb/status/761272450554269696
18 https://speakerdeck.com/feministy/in-defense-of-static-sites
19 http://www.akitaonrails.com/2016/08/03/moving-to-gitlab-yes-it-s-worth-it
20 https://www.proofpoint.com/us/threat-insight/post/massive-adgholas-malvertising-campaigns-use-steganography-and-file-whitelisting-to-hide-in-plain-sight
21 https://tom.vg/talks/BlackHatUSA2016_HEIST-presentation.pdf
22 https://tom.vg/papers/heist_blackhat2016.pdf
23 https://discourse.wicg.io/t/proposal-set-origin-wide-policies-via-a-manifest/1617/4
24 http://www.zdziarski.com/blog/?p=6143
25 http://www.zdziarski.com/blog/?p=6143
26 http://www.zdziarski.com/blog/?p=6143
27 http://www.zdziarski.com/blog/?p=6143
28 https://go.lynxbroker.de/eat_heartbeat.js
29 http://www.telegraph.co.uk/business/2016/05/22/uber-app-can-detect-when-a-users-phone-is-about-to-die/
30 https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/
31 https://www.smashingmagazine.com/2016/08/using-a-static-site-generator-at-scale-lessons-learned/
32 http://blog.goguardian.com/nerds/an-odyssey-to-find-a-sustainable-icon-system-with-svgs-in-react
33 https://tech.metriccollective.com/of-course-ill-let-you-execute-arbitrary-javascript-code-in-my-users-browsers-3032eca3480e
34 https://benfrain.com/understanding-native-javascript-array-methods/
35 https://codepen.io/MadeByMike/pen/ZOrEmr?editors=0100
36 ‘https://codepen.io/MadeByMike/pen/ZOrEmr/’
37 ‘http://codepen.io/MadeByMike’
38 ‘http://codepen.io’
39 https://newrepublic.com/article/135468/exhaustion-became-status-symbol
40 http://www.tombartel.de//2016/07/05/recalibrate-your-productivity-sensors/
41 https://www.oreilly.com/ideas/decentralize-now
42 https://www.theguardian.com/media/2016/jul/12/how-technology-disrupted-the-truth
43 http://www.nytimes.com/interactive/2016/08/02/business/dealbook/this-is-your-life-private-equity.html?_r=0
44 https://wdrl.info/donate
45 https://wdrl.info/costs/

https://www.meteor.com/install
https://docs.meteor.com

7 Reasons to Develop Your Next Web App with Meteor

August 3, 2016 by Curt Long

When I first learned about the Meteor JavaScript framework, I saw someone write, “Meteor is to Node.js as Rails is to Ruby,” and I think that’s a good comparison. A few years ago, Rails was the hot new thingon the web, sprinkling some useful “magic” through the development process to make programming on the web more approachable and pleasant. Out of the countless new frameworks that have spawned as of late though, none have made me feel the way Rails did as much as Meteor — a framework that you should seriously consider using for your coming projects. Here’s a few reasons why.

1. Your applications are real-time by default.

Lately, companies like Twitter and Facebook have been moving toward a real-time web. It’s inevitable that, sooner than you probably expect, users will expect web applications to work near-instantaneously. I imagine there’s already users who wince whenever a separate page load is required for simple tasks like changing settings and logging out.

The problem is, creating real-time web applications is tricky. Or at least, it was. Meteor has real-time built into its core though. When the database is updated, the data in your templates is updated. When a user clicks a button or submits a form, the action occurs immediately. In the vast majority of cases, this doesn’t even require any extra effort. You build a web application as you normally would and, out of the box, it just happens to be real-time.

A while back, the folks at Meteor released a screencast to demonstrate these real-time features, and it’s very much worth a watch, but there’s a range of production applications that do an even better job of showing off the Meteor difference:

These are just a small sample, too.

2. You can develop with just one language.

One of the frustrating parts of being a web developer is the need to wear a variety of hats. You need to think about the front-end, the back-end, and the database, and then there’s another million details that squeeze out the last inch of your mental capacity. Meteor simplifies this process by shrinking the scope of what you need to consider, allowing you to build and manage the front-end, the back-end, and the database with nothing but JavaScript.

This, for instance, is how we create a “collection” — the equivalent of an SQL table – in Meteor:

BlogPosts = new Meteor.collection('posts');

So, we can create a collection with a familiar syntax, but also manipulate a collection with a familiar syntax. Here’s how we insert data:

BlogPosts.insert({
  title: 'Hello World',
  content: 'This is the content.',
  published: true
});

There’s another benefit to writing an entire application with one language. One line of code can run on both the client and the sever and do different things in either environment. Here’s why this matters:

When the statement to create a collection runs on the server it, predictably enough, creates a collection. But when that same statement runs on the client (which it will do by default), it creates a purely local collection within the user’s browser. The user then interfacts with the local collection directly, which is why the data on their screen can change instantaneously, while the local and server-side collections are seamlessly synced in the background.

This doesn’t require any special treatment. You write one line of code and are provided with a boat-load of functionality in addition to being able to use a familiar syntax throughout the development cycle.

3. You can save a lot of time with smart packages.

Let’s say you want to create a user accounts system within a Meteor project. How might you approach it? If your first thought was, “Well, I’d create a collection for the user’s data,” then you’re already thinking too hard.

In Meteor, this is how we create an accounts system:

meteor add accounts-password

We run this command in a terminal, and Meteor adds one of its built-in “smart packages” to the project. This particular package creates an accounts system that expects an email (or username) and password. But what if we wanted to let users sign up with their Twitter account? Then we could write:

meteor add accounts-twitter

Or, with their Google account:

meteor add accounts-google

Or, Facebook:

meteor add accounts-facebook

We could even run all of these commands so our users could choose how they want to sign up.

Meteor also provides an accounts-ui package that creates the front-end of this accounts system, and that only requires one other command:

meteor add accounts-ui

With our account system in place, we can do everything we would reasonably need to do when working on a web application, like checking if the current user is logged in via one of our templates:

{{#if currentUser}}
  <p>You're logged in.</p>
{{else}}
  <p>You're not logged in.</p>
{{/if}}

Or navigating through and manipulating the Meteor.users collection, which is the collection that Meteor creates to store the data of our users.

Smart packages are not just for accounts though. There’s a range of them already available, with more presumably on the way, and they all allow you to do something cool, including:

Writing your applications in CoffeeScript.
Automatically compiling LESS files into CSS.
Integrating extras like D3.js and Bootstrap.

But if smart packages don’t have what you need, then the increasingly large library of third-party packages will probably have you covered.

4. The community is extremely supportive.

Nothing attracts me more to a new framework or technology than an active and vibrant community. I figure that, if the community’s active, then:

There’ll be a lot of detailed documentation.
I’ll waste less time getting up to speed with the basics.
The technology won’t hit the deadpool in the near future.

Luckily, Meteor’s community is already one of its greatest assets. There’s a ton of helpful resources that have spawned from people’s love of the framework, including:

Crater, a Reddit-like site for keeping track of what’s happening in the world of Meteor.
Evented Mind, a video training site for intermediate developers wanting deeper insight into how Meteor works.
Kadira, a performance tracking application that is both easy to use and has a reasonable free plan for getting started.

The official YouTube channel for Meteor has a range of talks from Meteor meetups and there’s plenty of blogs to follow for tips and tutorials:

But if you’re still not satisfied with what’s available, Stephan Hochhaus maintains a huge list of Meteor resources that has a little something for everyone.

5. It’s optimized for developer happiness.

Just about every framework markets itself as a better and more enjoyable way to work. What I appreciate though is Meteor’s attention to detail in holding true to its promise of optimizing for developer happiness.

Take this code, for instance:

<head>
  <title>Your Cool Meteor App</title>
</head>
<body>
  {{> myCoolTemplate}}
</body>

<template name="myCoolTemplate">
  <p>Hello world.</p>
</template>

This is a basic interface for a Meteor application with a template included between the body tags. (For templating, Meteor uses Spacebars — a Handlebars-inspired syntax.)

But notice that:

We haven’t included the html tags.
We haven’t included any CSS files.
We haven’t included any JavaScript files.

…and that’s because we don’t need to do these things since Meteor takes care of them for us. Is this the most significant feature in the world? Nope. But it’s indicative of Meteor’s interest in making every developer’s life that little bit easier at every turn.

Other pleasant details include:

A built-in LiveReload feature so you won’t have to manually refresh your browser.
The freedom to structure your projects however you want. There are standards you can follow but no strict rules or conventions.
The sheer modularity of Meteor that allows you to mix-and-match different components in case one part of Meteor isn’t to your liking.

So while Meteor has its fair share of “magic” and conventions designed to make your life easier, you can still make choices based on your personal preferences. It’s the best of both worlds.

6. It’s friendly to beginner developers.

What surprised me about Meteor was how quickly I was able to start building things that were actually kind of cool. I’d heard people refer to the framework as “easy” but, usually, other people’s definition of that word differs from my own. In this case though, they were right:

Meteor is one of the easiest frameworks for beginners to learn.

It’s still programming, and you’ll want to be familiar with the syntax of JavaScript — variables, loops, conditionals, JSON, etc. — but you don’t need to be a JavaScript ninja to make a start. You don’t even need prior experience with making web applications (it’s a great choice for front-end developers looking to bolster their skillset). You might not grasp all of the concepts right away but that won’t stop you from enjoying the practical side of things.

As for why Meteor is such a great fit for beginning developers, it’s mostly for the same reasons that I recommend Meteor in general:

You only need to know a single language.
There’s a ton of community-made resources.
It’s optimised for developer happiness.

So even if you stumble across a slight hump when learning Meteor, just push a little further and I think you’ll find that those humps are few and far between.

7. It’s ahead of the tech curve.

Like I said earlier, the web is becoming a real-time environment, but the shift won’t happen purely based on the actions of the big companies with the big budgets. The shift will happen as tools become available that allow small teams and individual developers to make real-time applications quickly and easily. Meteor is amongst the first wave of this tools and its “all in one” approach is surely going to make it a big player in the coming years.

The folks at Meteor have stated their long-term mission, and to put it plainly, their mission is huge:

…to build a new platform for cloud applications that will become as ubiquitous as previous platforms such as Unix, HTTP, and the relational database.

Can they pull this off? No one can say with absolute certainty, of course, but they have the funding, the community, and the ever-important balance of being great for developers and great for end-users. So at the very least, they’re on the right track (and it’s a track where I’m glad to be tagging along for the ride).

Conclusion

As of writing these words, Meteor is still young at version 0.8.2, but the releases are coming big and quick, and a range of impressive Meteor-built apps are live and being used on the web. Your particular situation will determine whether or not a particular framework is the right fit for you and your creations, but every developer owes it to themselves to at least play with Meteor for a day or two. I haven’t had this much fun with programming on the web in a long while and there’s a good chance you’ll feel the same way.

Was this helpful? –

Meet the author

David Turnbull

David Turnbull is the author of the Meteor Tips blog, a regular source of tips, tricks, and tutorials for the Meteor JavaScript framework. He’s currently hard at work on a screencast series for beginning developers to get started with Meteor.

Web Development Reading List #147: Security Guidelines, Accessible UI Components, And Content-First Design

August 8, 2016July 28, 2016 by Curt Long

Web Development Reading List #147: Security Guidelines, Accessible UI Components, And Content-First Design

When working in a team, it’s important to stick to rules. A common challenge is to build all your projects with a similar or the same toolset and coding guidelines. Only yesterday I discussed how we could port over a project that outgrew its initial codebase over the years to a fresh, React.js-based source code.

The decision for this wasn’t easy, since we had invested quite a lot of work and money into this project already, and a move to React would require quite some time, too. But since the switch makes sense from a technical perspective and the team is already using React for three other projects, we concluded that this would be a good step to do. It will enable more developers of the team to contribute to the project, to review code and to reduce the shift of technologies in the company. Occasionally, it’s time to re-evaluate your projects and move on.

News Link

Bootstrap 4 Alpha 3¹ has been released this week. It comes with an overhauled grid, updated form controls, a system font stack, and more.
Microsoft announced that their JavaScript engine ChakraCore² now supports Mac OS and Linux. This means, you can now test and run your Node.js applications not only in Google’s V8 engine. Christian Heilmann wrote up why this is an important step³.

⁴

Good news for Mac and Linux users: ChakraCore is finally supported⁵. (Image credit: Christian Heilmann⁶)

Concept & Design Link

“Web Design in 4 minutes⁷” is a very concise article on why content-first matters.

Tools & Workflows Link

If you work on small projects, an (S)FTP-client can still be very useful. But on the other hand, it means you need to manually copy files from your git workflow to the server. To solve this issue, the indie developer Jan Östlund built GitFTP-Deploy⁸, a handy (S)FTP tool for a small fee that does automatic deployments based on your git workflow.
The privacy/tracking issue is bigger than we think. Have you ever monitored which apps connect to which service? You suddenly realize that an ad blocker/privacy add-on in your browser is only a drop in the bucket. Apps often connect to Google services, Google Analytics, sometimes to various ad networks, and very often to New Relic’s user tracking service. Fortunately, there’s a solution to nearly every problem: Add tracker hostnames to your /etc/hosts file. There’s even a public sample hosts file that you can use⁹ that includes most ad networks and trackers. Use it at your own risk though and be aware that some apps might not work anymore. But maybe your privacy is worth it?

Security Link

FallibleInc’s “A practical security guide for web developers¹⁰” tries to help developers build more secure, less vulnerable solutions. While they claim that it’s by no means a comprehensive guide, it covers stuff based on the most common issues they’ve discovered in the past.
We know that HTTPS is not super-secure. That’s why lately a lot of bugs were fixed in the software implementations and a lot of techniques like HSTS and HPKP were added. But sometimes all of this won’t help. Recently, an attack was discovered that can be carried out by operators¹¹ of just about any type of network, including public Wi-Fi networks, which arguably are the places where people need HTTPS the most. There are also hints that this type of attack is already in use by at least the NSA and therefore likely by a lot of other people, too. Please never trust TLS only for your own security but use a VPN for public networks.

HTTPS protection — Even when the Wi-Fi can’t be trusted, people rely on HTTPS to secure their connection. A fallacy, as a recently-discovered attack¹³ shows. (Image credit: Ars Technica¹⁴)

Privacy Link

I don’t want to be the scapegoat here, but Pokémon Go is very popular, and I read some interesting things about the privacy of the game. For example, not only Alphabet (aka Google) is one of the main investors, but there’s also a financial relationship between the game-maker Niantic and the CIA angel investment company In-Q-Tel¹⁵. While there’s no evidence on what this could mean for the privacy of users, it definitely means that those companies are highly interested in the data that is provided by the gamers — understandable, as it’d be very hard to get geo information and pictures of private ground in a normal way. I’ve heard that several companies such as BMW already advised their employees that it’s forbidden to play the game at their factory sites and the German army published a similar order to their soldiers. ExpressVPN also published a short summary list with nine privacy issues to consider when playing Pokémon Go¹⁶.

Web Performance Link

Erik Duindam writes about how a good architecture can save you a lot of money when building a product. He shares how he built a Pokémon Go app with 500k users in just five days¹⁷ and reduced the costs of it to a $100/month server infrastructure, compared to many MVP products that burn money by choosing bad technical designs.
Jake Archibald shares an interesting little fact about the benefits of using rel=noopener: it’s faster¹⁸.

Accessibility Link

Addy Osmani explains how to build accessible UI components for the web¹⁹, taking into consideration visual, hearing, mobility and cognition as accessibility factors. A pretty great entry-level guide to better, accessible products.
Having a guideline for accessibility that developers can refer to makes sense for every project. Inspiration to create one comes from Vox who published their accessibility guidelines publicly.²⁰

JavaScript Link

Pascal Precht shares how to create custom form controls in Angular 2²¹ in his usual easy-to-understand, high-quality style.
Krasimir Tsonev wrote an article about React.js in design patterns²² with some common code snippets that will come in handy in most React.js projects.

CSS/Sass Link

Chris Coyier wrote up solutions to create full-width child containers²³ of a limited-width parent, including Sven Wolfermann’s simple and clever approach²⁴.

Work & Life Link

“Always improve, never stop, never pause, never appreciate” is something that developers, company leaders, and managers can easily apply to their work. Mathias Meyer points out the importance of properly appreciating work that has been done²⁵.
We have some evidence already that multitasking isn’t beneficial for productivity. Lydia Dishman now wrote up what changed when she moved to monotasking for a week. The reason why I found this article particularly interesting, is realizing how much multitasking we do during a normal day without taking note of it²⁶.

Multitasking — What happens when you give up multitasking for a week? Lydia Dishman found out²⁸.

Going Beyond… Link

We still might not know if it’s our fault that the climate is changing²⁹. But what we now know is that Greenland’s ice-shield lost twice as much ice in the past four years³⁰ as in the 20 years before that. And this means much faster-rising sea levels, the loss of drinking water, and the loss of an important weather control on Earth (the Arctic has much influence on how storms and weather develop). In the end, it’s us who suffer from it, so we need to act and do our best to stop this trend.
Zack Bloom shares what the alternative suggestions of languages were back when CSS was invented³¹ and why CSS succeeded.

And with that, I’ll close for this week. If you like what I write each week, please support me with a donation³² or share this resource with other people. You can learn more about the costs of the project here³³. It’s available via email, RSS and online.

— Anselm

Footnotes Link

1 https://blog.getbootstrap.com/2016/07/27/bootstrap-4-alpha-3/
2 https://github.com/Microsoft/ChakraCore
3 https://www.christianheilmann.com/2016/07/27/why-chakracore-matters/
4 https://github.com/Microsoft/ChakraCore
5 https://github.com/Microsoft/ChakraCore
6 https://www.christianheilmann.com/2016/07/27/why-chakracore-matters/
7 http://jgthms.com/web-design-in-4-minutes/
8 https://eastwest.se/apps/gitftpdeploy
9 http://winhelp2002.mvps.org/hosts.txt
10 https://github.com/FallibleInc/security-guide-for-developers
11 http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/
12 http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/
13 http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/
14 http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/
15 https://medium.com/friction-burns/pokémon-spy-17087ae3653d
16 https://www.expressvpn.com/blog/pokemon-go-privacy-concerns/
17 https://medium.com/unboxd/how-i-built-an-app-with-500-000-users-in-5-days-on-a-100-server-77deeb238e83#.91iwcl397
18 https://jakearchibald.com/2016/performance-benefits-of-rel-noopener/
19 https://medium.com/@addyosmani/accessible-ui-components-for-the-web-39e727101a67
20 http://accessibility.voxmedia.com/
21 http://blog.thoughtram.io/angular/2016/07/27/custom-form-controls-in-angular-2.html
22 http://krasimirtsonev.com/blog/article/react-js-in-design-patterns
23 https://css-tricks.com/full-width-containers-limited-width-parents
24 https://css-tricks.com/full-width-containers-limited-width-parents/#article-header-id-6
25 http://www.paperplanes.de/2015/9/28/always-improve-never-appreciate.html
26 https://www.fastcompany.com/3062183/your-most-productive-self/what-happened-when-i-gave-up-multitasking-for-a-week
27 https://www.fastcompany.com/3062183/your-most-productive-self/what-happened-when-i-gave-up-multitasking-for-a-week
28 https://www.fastcompany.com/3062183/your-most-productive-self/what-happened-when-i-gave-up-multitasking-for-a-week
29 http://www.flassbeck-economics.com/how-climate-change-is-rapidly-taking-the-planet-apart/
30 https://www.washingtonpost.com/news/energy-environment/wp/2016/07/19/greenland-lost-a-trillion-tons-of-ice-in-just-four-years/
31 https://eager.io/blog/the-languages-which-almost-were-css/
32 https://wdrl.info/donate
33 https://wdrl.info/costs/

6 key tips to taking your business global

July 25, 2016July 21, 2016 by Curt Long

If your business has seen successful growth in the US, it most likely will see success in other countries as well. And, you may want to lock up those markets, before some other company does.

I recently met a startup that had successfully tripled its revenues – largely from the results of a successful international expansion effort and wanted to share those learnings with all of you.

Pick your markets

All Killer, No Filler

We’re bringing Momentum to New York: our newest event, showcasing only the best speakers and startups.

This post originally appeared on Red Rocket.

There are 195 countries in the world. How do you even know where to start?

Many US companies go after the path of least resistance: In other English speaking countries, like Canada, the United Kingdom, Australia and New Zealand, typically in that order of closest to home.

While that is certainly a good strategy, a better strategy is figuring out which countries have the highest demand for your products. For example, if you’re selling into the auto industry, perhaps big auto markets like Japan and Germany may be the best place to start.

Like anything, there will be an 80/20 logic here, where 80 percent of your international sales will come from 20 percent of your international markets. So, carefully prioritize your efforts.

Pick your structure

There are many ways to take your business global, with various levels of complexity and investment. You’re going to need to decide between opening our own office overseas, leveraging key in-country distributors or striking channel partnerships with key companies that have access to your target customers, based on your goals and budgets.

And, the solutions you use in one country, may not be the same solution you use in others, depending on the challenge in those markets. For example, in China, you’ll need a local company to partner with, to help you navigate the local market.

Where you can, setting up your own efforts, either as a startup or via an acquisition of a local player, will typically exceed the results of piggy backing on the efforts of others.

Learn the local rules

Every country has different “rules of engagement”. And, when you’re getting started, it’s often helpful to engage an international expansion consulting firm, that can help you quickly learn all the local laws, regulations, accounting rules, business taxes, government taxes, employment vs contractor rules, compensation rules, privacy rules, etc.

And, don’t underestimate the downside risks from things like bribery payments, organized crime and other corruption in various countries, which you never want to partake in, or risk going to jail.

These varying rules can make the difference in deciding whether or not those markets make sense for you.

Localize your fulfillment

Make sure you have a plan for communicating in foreign markets.

You’ll have to think through all the back office tasks for your business and how it will be different overseas.

Who will be answering the phones (in the local language and during local business hours), how will products be warehoused and shipped, how will you collect payments from customers, how will you process payroll payments, into which bank accounts, who is going to train your local customers, who is going to service local customers post sale, etc.

Often times, it’s like building a whole new fulfillment process from scratch.

Localize your marketing efforts

Every country has a unique culture of its own. And, you need to tailor your marketing creatives into the messaging that will most resonate with the local market and stand out against local competitors (who are most likely different companies than the ones you’re competing with in the US).

If you’re already successfully selling into global companies today, be sure to ask your US contacts at those companies for introductions to their counterparts in the countries you desire to enter.

Anyway, hope you found this high level introduction to the topic helpful. Global expansion is a really tricky topic to cover is a short post, given all its complexities by country, so be sure to surround yourself with expert consultants, lawyers and other global entrepreneurs that can help you here.

3D printers could replicate your fingerprints to help unlock phones – even after you’re dead

July 21, 2016 by Curt Long

Fusion reports that police officers contacted Michigan State University professor Anil Jain recently to recreate a dead man’s fingers using a 3D printer, so they could unlock his phone and sift through its content for clues.

Details are scare because the investigation is still underway. But Jain said that the deceased person in question was the victim in a murder case, not the attacker. Law enforcement officials had his fingerprints on file as he was arrested in a previous incident, and handed those over to Jain for replication.

All Killer, No Filler

We’re bringing Momentum to New York: our newest event, showcasing only the best speakers and startups.

Police asked this 3D printing lab to recreate a dead man’s fingers to unlock his phoneon Fusion

The victim’s phone hasn’t yet been unlocked – Jain has created replicas of all ten digits, but is still working to refine them so the plastic fingers coated with metallic particles can be read by a fingerprint scanner as easily as human fingers, which are more conductive.

If this method works, it’ll prove once again that fingerprints aren’t as secure as we’d like to believe when it comes to locking our digital devices.

In October 2014, a Virginia court ruled that suspects can be asked to unlock their phones using their fingerprints. In contrast, PINs are more secure because the Fifth Amendment prevents government agencies from compelling people to turn over things in their minds, like memorized passcodes.

It’s also worth keeping in mind that phones locked with a fingerprint usually require a PIN to be entered if it hasn’t been used in 48 hours, or if it’s been powered off and back on again. In both instances, fingerprints are of no help, regardless of how they’re obtained.

This case could also set a precedent for law enforcement gaining access to people’s phones more easily. If a person has been arrested and their mobile device has been confiscated, they could be asked to merely submit to a fingerprint scan that would give police everything they need to create replicas for unlocking a phone.

The extent to which fingerprints and PINs can help protect our privacy seems to be rather limited; ultimately, what we really need is transparency and oversight when it comes to how our digital data is handled by law enforcement and government agencies.

Hackers can steal your iOS and Mac passwords with a single image file

July 20, 2016 by Curt Long

A new vulnerability discovered by a Cisco researcher could allow hackers to gain access to the internal storage and stored passwords on your iOS or Mac device – and all they’d have to do is send you a malicious image file.

Tyler Bohan of Cisco Talos found that a TIFF format file – sent via MMS, email or placed on a webpage that a victim is guided to visit – can hide malware which can run automatically, without being detected.

All Killer, No Filler

We’re bringing Momentum to New York: our newest event, showcasing only the best speakers and startups.

Vulnerability Spotlight: Apple Remote Code Execution With Image Fileson Talos Blog

In addition to beaming across your authentication credentials on iOS, Mac OS X, tvOS and watchOS, the vulnerability can also allow attackers to remotely control Macs which don’t support sandboxing.

Thankfully, these issues have been patched by Apple; you’ll need to update to the latest versions of their operating systems – iOS 9.3.3, El Capitan 10.11.6, tvOS 9.2.2 and watchOS 2.2.2 – to stay safe.

If this sounds familiar, it’s because the security flaw is eerily similar to the Stagefright vulnerability discovered in Android devices last year. After it was spotted last August, a second version was uncovered in which hardware could be compromised by sending across an audio file.

Snowden is designing a tin foil hat for your iPhone

July 20, 2016 by Curt Long

Not-so-fun fact: your smartphone can be tricked into transmitting signals even when it’s turned off. That means it can be used to track your location without your knowledge. And NSA whistleblower Edward Snowden is having none of it.

That’s why he’s collaborating with famed hardware hacker Andrew “Bunnie” Huang to create an iPhone 6 case that can detect whether your phone is transmitting data when it’s not supposed to. The idea is to protect journalists, rights workers and the like from being tracked by governments and to expose their agencies’ efforts to spy on such people.

All Killer, No Filler

We’re bringing Momentum to New York: our newest event, showcasing only the best speakers and startups.