Posts tagged “code”, page 4

Cole Henley makes some very astute observations on the value and purpose of web development tools:

At the risk of sounding like a Luddite, I do worry that the adoption of tools for producing websites often lacks focus and a clear reason for “why.” As a largely self-taught profession, we have often lent on our peers for guidance and direction. But how often is the context of this guidance comparable to our own? As I said earlier, can the efforts to produce code for enterprise website applications across large, distributed teams share some equivalence with the work many of us produce in creating small, brochure sites for small to medium-sized businesses and not-for-profits? Does one shoe fit all? And are we in danger of focusing too much on the “Pencils rather than the drawing”? The Process over the Product?

I found this question particularly hard to grapple with:

But one of the ways CSS Zen Garden was used to persuade people about the merits of a web standards approach was to suggest that we can retain the markup and replace the CSS. However in reality how many projects has this ever happened on? What is the realistic lifespan of a thing we produce? And do we tend to underestimate how disposable our code truly is?

Sara Soueidan:

Using the color wheel to pick colors has many benefits. One of the main advantages of HSL is that creating color harmonies becomes a piece of cake.

Jeremy Keith:

Frankly, the whole point of prefixed CSS is that is not used after a reasonable amount of time (originally, the idea was that it would not be used in production, but that didn’t last long). As we’ve moved away from prefixes to flags in browsers, I’m seeing the amount of prefixed properties dropping, and that’s very, very good. I’ve stopped using autoprefixer on new projects, and I’ve been able to remove it from some existing ones—please consider doing the same.

Browser prefixes seem to be slowly going away. I stopped using Autoprefixer last year and haven’t missed it.

David Bryant Copeland writes a manifesto:

Brutalist Web Design is honest about what a website is and what it isn’t. A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.

A website is about giving visitors content to enjoy and ways to interact with you.

Jeffrey Zeldman:

Good communication strives for clarity. Design is its most brilliant when it appears most obvious—most simple. The question for web designers should never be how complex can we make it. But that’s what it has become. Just as, in pursuit of “delight,” we forget the true joy reliable, invisible interfaces can bring, so too, in chasing job security, do we pile on the platform requirements, forgetting that design is about solving business and customer problems … and that baseline skills never go out of fashion.

Adam Silver:

The best way to make pages fast, is to have less stuff in them. You’d be forgiven for wanting to punch me in the face as this is obvious. And yet web pages keep getting fatter and fatter.

Oliver Williams thinks we should update the “mustard cut” technique to truly deprecate Internet Explorer, and I love the idea.

Users have more browsers than ever to choose from, yet IE manages to single-handedly tie us to the pre-evergreen past of the web. If developing Chrome-only websites represents one extreme of bad development practice, shackling yourself to a vestigial, obsolete, zombie browser surely represents the other.

He makes a crucial point — IE users might actually be better off with a pared-down experience:

By making a clean break with the past, we can focus our energies on building modern sites using modern standards without leaving users stuck on antiquated browsers with an untested and possibly broken site. We save a huge amount of mental overhead. If your content has real value, it can survive without flashy embellishments.

Aaron Gustafson:

Last week, two events reminded us, yet again, of how right Douglas Crockford was when he declared the web “the most hostile software engineering environment imaginable.” Both were serious enough to take down an entire site—actually hundreds of entire sites, as it turned out. And both were avoidable.

Start simply. Code defensively. User-test the heck out of it. Recognize the chaos. Embrace it. And build resilient web experiences that will work no matter what the internet throws at them.

Jen Simmons introduces the concept of Intrinsic Web Design. It’s a bold idea that brings together all recent advances in CSS layout. It really feels like a paradigm shift — I love it.

Jeremy Keith’s notes are a good companion to the slides, and code examples can be found in Jen’s CodePen.

Update: a video of the talk is now available.

Frank Chimero:

At first I was bummed about my studio’s lack of visible progress, but then it hit me: what if I nailed it? Why change if it’s working? I’ve been able to approach a lot of different projects from many different angles, and I’m happy to report that I’ve gotten pretty good at a lot of it! Time and practice really do help.

Except with the websites. They separate themselves from the others, because I don’t feel much better at making them after 20 years. My knowledge and skills develop a bit, then things change, and half of what I know becomes dead weight. This hardly happens with any of the other work I do.

I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times. If you’ve been working in the technology industry a while, please tell me this sounds familiar to you.