Why it’s hard to read the time on Infograph
marco.org
Marco Arment:
Even with almost no complications, the basic essence of the Infograph dial has poor time legibility.
Marco Arment:
Even with almost no complications, the basic essence of the Infograph dial has poor time legibility.
Miles Klee, for MEL Magazine:
“Every homeless person has like three scooters now,” Michael Ghadieh, owner of an electric bike store in San Francisco, told CNET. “They take the brains out, the logos off and they literally hotwire it.”
Ben Frain gives some very useful and pragmatic advice on how to build web front-end prototypes.
Producing something of high fidelity, perfectly matching any flat designs, runs counter to the notion of creating something quickly. The challenge for the prototyper is therefore how to cut corners that don’t impact the fidelity of the prototype.
In my experience, it’s vital that the prototype does not morph into the final product …no matter how tempting it sometimes seems.
Prototypes are made to be discarded (having validated or invalidated an idea). Making a prototype and making something for production require very different mindsets: with prototyping it’s all about speed of creation; with production work, it’s all about quality of execution.
Max Böck:
Text-only sites like these are usually treated as a MVP of sorts. A slimmed-down version of the real site, specifically for emergencies.
I’d argue though that in some aspects, they are actually better than the original.
This is the web as it was originally designed. Pure information, with zero overhead. Beautiful in a way.
Jeremy Keith:
I really like this design pattern. Cover 80% of the use cases with a declarative solution in HTML, but also provide an imperative alternative in JavaScript that gives more power. HTML5 has plenty of examples of this pattern. But I feel like the history of web standards has a few missed opportunities too.
In recent years there’s been a push to expose low-level browser features to developers. They’re inevitably exposed as JavaScript APIs. In most cases, that makes total sense. I can’t really imagine a declarative way of accessing the
fetchorcacheAPIs, for example. But I think we should be careful that it doesn’t become the only way of exposing new browser features. I think that, wherever possible, the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for the simple use cases, and power for the more complex use cases.
Rachel Andrew:
There is frequently talk about how developers whose main area of expertise is CSS feel that their skills are underrated. I do not think we help our cause by talking about CSS as this whacky, quirky language. CSS is unlike anything else, because it exists to serve an environment that is unlike anything else. However we can start to understand it as a designed language, with much consistency. It has codified rules and we can develop ways to explain and teach it, just as we can teach our teams to use Bootstrap, or the latest JavaScript framework.
A look at the 12 principles of animation developed by Disney to give life to an image.
Explainers about Disney’s animation techniques have been done to death, but Kristian’s stellar editing and compositing make this one worth watching. He uses some great examples that I hadn’t seen before.
Played 30 September 2018 on Mac
Brilliant in mechanics and narrative. Absolutely fantastic soundtrack. Got a bit too high on its own supply at the end there, which left me somewhat emotionally detached. That disconnect might just have been due to expectations, though: I was anticipating a more adult-ish, less “anime” overarching feeling. But I guess anime is real.
Eye-opening and surprisingly poignant.
Heydon Pickering:
Most of you will be familiar with JavaScript’s fat arrow functions, also known as “chonky darts”.
In ES2019, fat arrow functions are not the only kinds of arrow functions available to you. Let’s take a look at some of the others and what they have to offer.
Brad Frost:
JavaScript is eating the world and the rest of the frontend stack with it. Those server-side languages people used to write in? Node. HTML? JSX. Styling? We do that in JS now too. HTML, CSS, and JavaScript are three sturdy, capable languages that each have their own histories, nuances, and best practices. I do worry that as we author more and more in JS we risk losing those hard-won HTML/CSS best practices. Of course, it’s totally possible to preserve those HTML/CSS best practices even as we write everything in JS, which is why I want to make sure libraries like React are accessible to frontend people like me who don’t come from a JavaScript/programming background.
Kevin Ball:
“Real programmers” were antisocial, geeky, and only cared about computing. If you didn’t fit the profile you didn’t belong.
With the growth of the importance of front-end development, we’re seeing the story play out again.
The systematic devaluation of CSS, and more, the people who use CSS.
Watched 13 September 2018
Cool and exciting, but the low budget/high ambition combo leaves it stuck in a sort of uncanny valley — the kind of sci-fi that never quite manages to hide its seams. Still, very enjoyable and made me wish for more cyberpunk movies. I’ll probably go watch Ghost in the Shell for the fiftieth time now.
At the top of Jeremy’s list, other people’s Javascript:
At number one with a bullet, it’s all the crap that someone else tells us to put on our websites. Analytics. Ads. Trackers. Beacons. “It’s just one little script”, they say. And then that one little script calls in another, and another, and another.
It’s so disheartening when you’ve devoted your time and energy into your web font loading strategy, and optimising your images, and unbundling your JavaScript …only to have someone else’s JavaScript just shit all over your nice performance budget.
Watched 10 September 2018
Dinosaurs are cool