Archive: October, 2018

41

sparkline
                    5th                     10th                     15th                     20th                     25th                     30th     
12am
4am  
8am            
12pm          
4pm          
8pm          

Tuesday, October 30th, 2018

Monday, October 29th, 2018

Programming Sucks

There’s a theory that you can cure this by following standards, except there are more “standards” than there are things computers can actually do, and these standards are all variously improved and maligned by the personal preferences of the people coding them, so no collection of code has ever made it into the real world without doing a few dozen identical things a few dozen not even remotely similar ways. The first few weeks of any job are just figuring out how a program works even if you’re familiar with every single language, framework, and standard that’s involved, because standards are unicorns.

Sunday, October 28th, 2018

The Three Types of Performance Testing – CSS Wizardry

Harry divides his web performance work into three categories:

  1. Proactive
  2. Reactive
  3. Passive

I feel like a lot of businesses are still unsure where to even start when it comes to performance monitoring, and as such, they never do. By demystifying it and breaking it down into three clear categories, each with their own distinct time, place, and purpose, it immediately takes a lot of the effort away from them: rather than worrying what their strategy should be, they now simply need to ask ‘Do we have one?’

Friday, October 26th, 2018

Thursday, October 25th, 2018

Tuesday, October 23rd, 2018

Monday, October 22nd, 2018

Monday, October 15th, 2018

Thursday, October 11th, 2018

Tuesday, October 9th, 2018

Monday, October 8th, 2018

Workplace topology | Clearleft

The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.

This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:

Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.

Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.

That last part dovetails nicely with Jerlyn’s equally great piece.

Notes on prototyping – Ben Frain

Good tips on prototyping using the very materials that the final product will be built in—HTML, CSS, and JavaScript.

The only thing I would add is that, 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.

The Hurricane Web | Max Böck - Frontend Web Developer

When a storm comes, some of the big news sites like CNN and NPR strip down to a zippy performant text-only version that delivers the content without the bells and whistles.

I’d argue though that in some aspects, they are actually better than the original.

The numbers:

The “full” NPR site in comparison takes ~114 requests and weighs close to 3MB on average. Time to first paint is around 20 seconds on slow connections. It includes ads, analytics, tracking scripts and social media widgets.

Meanwhile, the actual news content is roughly the same.

I quite like the idea of storm-driven development.

…websites built for a storm do not rely on Javascript. The benefit simply does not outweigh the cost. They rely on resilient HTML, because that’s all that is really necessary here.

I, Maintainer

Maintaining an open source project is a rollercoaster ride with high peaks and very low troughs.

Release frequency is down. Questions increasingly go unanswered. Issues remain in a triage, unresolved state. Uncertainty and frustration brew within the community room.

Brian’s experience with Pattern Lab very much mirrors Mark’s experience with Fractal. The pressure. The stress. But there’s also the community.

A maintainer must keep the needs of their project, their community, and their own needs in constant harmony.

This is hard!

Friday, October 5th, 2018

Designing design systems | Clearleft

I know I’m biased because I work with Jerlyn, but I think this in-depth piece by her is really something! She suveys the design system landscape and proposes some lo-fi governance ideas based around good old-fashioned dialogue.

Developing a design system takes collaboration between the makers of the design systems and the different users of the system. It’s a continual process that doesn’t have to require a huge investment in new departments or massive restructuring.

It can start small.

Thursday, October 4th, 2018

Infovore » Pouring one out for the Boxmakers

This is a rather beautiful piece of writing by Tom (especially the William Gibson bit at the end). This got me right in the feels:

Web 2.0 really, truly, is over. The public APIs, feeds to be consumed in a platform of your choice, services that had value beyond their own walls, mashups that merged content and services into new things… have all been replaced with heavyweight websites to ensure a consistent, single experience, no out-of-context content, and maximising the views of advertising. That’s it: back to single-serving websites for single-serving use cases.

A shame. A thing I had always loved about the internet was its juxtapositions, the way it supported so many use-cases all at once. At its heart, a fundamental one: it was a medium which you could both read and write to. From that flow others: it’s not only work and play that coexisted on it, but the real and the fictional; the useful and the useless; the human and the machine.

The Way We Talk About CSS

A very thoughtful post by Rachel…

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.

Tuesday, October 2nd, 2018

Designing With Code

How mucking about in HTML and CSS can lead to some happy accidents.

‘Sfunny, people often mention the constraints and limitations of “designing in the browser”, but don’t recognise that every tool—including Sketch and Photoshop—comes with constraints and limitations. It’s just that those are constraints and limitations that we’ve internalised; we no longer even realise they’re there.

Form Design Patterns Book by Adam Silver

Oh, this will be good! Adam has been working on, thinking and writing about forms for quite a while and he has distilled that down into ten patterns. You just know that progressive enhancement will be at the heart of this book.

By the end of the book, you’ll have a close-to exhaustive list of ready-to-go components, delivered as a design system that you can fork, contribute to and use immediately on your projects. But more than that, you’ll have the mindset and rationale behind when or when not to use each solution, which is just as important as the solution itself.

Monday, October 1st, 2018