Tags: ning

383

sparkline

Monday, May 4th, 2020

CSS Tips for New Devs | Amber’s Website

Never mind Kevin Kelly’s 68 bits of advice, here’s Amber’s 24 nuggets of CSS lessons for people new to web development.

Thursday, April 30th, 2020

User agents

I was on the podcast A Question Of Code recently. It was fun! The podcast is aimed at people who are making a career change into web development, so it’s right up my alley.

I sometimes get asked about what a new starter should learn. On the podcast, I mentioned a post I wrote a while back with links to some great resources and tutorials. As I said then:

For web development, start with HTML, then CSS, then JavaScript (and don’t move on to JavaScript too quickly—really get to grips with HTML and CSS first).

That’s assuming you want to be a good well-rounded web developer. But it might be that you need to get a job as quickly as possible. In that case, my advice would be very different. I would advise you to learn React.

Believe me, I take no pleasure in giving that advice. But given the reality of what recruiters are looking for, knowing React is going to increase your chances of getting a job (something that’s reflected in the curricula of coding schools). And it’s always possible to work backwards from React to the more fundamental web technologies of HTML, CSS, and JavaScript. I hope.

Regardless of your initial route, what’s the next step? How do you go from starting out in web development to being a top-notch web developer?

I don’t consider myself to be a top-notch web developer (far from it), but I am very fortunate in that I’ve had the opportunity to work alongside some tippety-top-notch developers at ClearleftTrys, Cassie, Danielle, Mark, Graham, Charlotte, Andy, and Natalie.

They—and other top-notch developers I’m fortunate to know—have something in common. They prioritise users. Sure, they’ll all have their favourite technologies and specialised areas, but they don’t lose sight of who they’re building for.

When you think about it, there’s quite a power imbalance between users and developers on the web. Users can—ideally—choose which web browser to use, and maybe make some preference changes if they know where to look, but that’s about it. Developers dictate everything else—the technology that a website will use, the sheer amount of code shipped over the network to the user, whether the site will be built in a fragile or a resilient way. Users are dependent on developers, but developers don’t always act in the best interests of users. It’s a classic example of the principal-agent problem:

The principal–agent problem, in political science and economics (also known as agency dilemma or the agency problem) occurs when one person or entity (the “agent”), is able to make decisions and/or take actions on behalf of, or that impact, another person or entity: the “principal”. This dilemma exists in circumstances where agents are motivated to act in their own best interests, which are contrary to those of their principals, and is an example of moral hazard.

A top-notch developer never forgets that they are an agent, and that the user is the principal.

But is it realistic to expect web developers to be so focused on user needs? After all, there’s a whole separate field of user experience design that specialises in this focus. It hardly seems practical to suggest that a top-notch developer needs to first become a good UX designer. There’s already plenty to focus on when it comes to just the technology side of front-end development.

So maybe this is too simplistic a way of defining the principle-agent relationship between users and developers:

user :: developer

There’s something that sits in between, mediating that relationship. It’s a piece of software that in the world of web standards is even referred to as a “user agent”: the web browser.

user :: web browser :: developer

So if making the leap to understanding users seems too much of a stretch, there’s an intermediate step. Get to know how web browsers work. As a web developer, if you know what web browsers “like” and “dislike”, you’re well on the way to making great user experiences. If you understand the pain points for browser when they’re parsing and rendering your code, you’ve got a pretty good proxy for understanding the pain points that your users are experiencing.

Tuesday, April 28th, 2020

What is a resilient website? (with Jeremy Keith) | A Question of Code

I really enjoyed having a chat with Ed and Tom on their podcast. It’s aimed at people making a career shift into web development, but that didn’t stop me banging on about my usual hobby horses: progressive enhancement, resilient web design, and all that jazz.

Available for your huffduffing pleasure.

Design Can Change the World - But It’s Up to Us to Make it So by Daniel Burka

There is a huge world out there where design isn’t embraced, where designers are clawing for resources, and where design isn’t prioritized. Most of the organizations that are changing your world don’t know much about design, aren’t looking for designers, and won’t even understand what designers are talking about when they show up at the front door.

Monday, April 20th, 2020

How I’m teaching the kids coding for the web

I love how Remy explains front-end development to his kids:

The bones are the HTML. Each bone has a name, we call them tags (or elements).

…the skin and the paint on the skin, this is CSS.

Finally, the brain and behaviour, the way the website can be interacted with is using the third layer: JavaScript.

Monday, March 30th, 2020

Prioritising Requirements | Trys Mudford

Over the past few years, I’ve given quite a few workshops and talks on evaluating technology. This methodical approach to evaluation and prioritisation from Trys is right up my alley!

In any development project, there is a point at which one must decide on the tech stack. For some, that may feel like a foregone conclusion, dictated by team appetite and experience.

Even if the decision seems obvious, it’s always worth sense-checking your thought process. Along with experience and gut-feelings, we also have blind-spots and biases.

I feel like there’s a connection here to having good design principles—the kind that explicitly value one facet over another.

Sunday, March 15th, 2020

Twitter thread as blog post: Thoughts on how we write CSS | Lara Schenck

CSS only truly exists in a browser. As soon as we start writing CSS outside of the browser, we rely on guesses and memorization and an intimate understanding of the rules. A text editor will never be able to provide as much information as a browser can.

Thursday, March 12th, 2020

Pure CSS Landscape - An Evening in Southwold

This is not an image format. This is made of empty elements styled with CSS. (See for yourself by changing the colour value of the sun.)

Wednesday, March 11th, 2020

Why is CSS frustrating? ・ Robin Rendle

CSS is frustrating because you have to actually think of a website like a website and not an app. That mental model is what everyone finds so viscerally upsetting. And so engineers do what feels best to them; they try to make websites work like apps, like desktop software designed in the early naughts. Something that can be controlled.

Tuesday, March 3rd, 2020

Getting your priorities right | Clearleft

A ludicrously useful grab-bag of prioritisation techniques from Chris—so, so handy for workshops and sprint planning.

Selectors Explained

I can see this coming in very handy at Codebar—pop any CSS selector in here and get a plain English explanation of what it’s doing.

Friday, February 28th, 2020

Why is CSS Frustrating? | CSS-Tricks

Why do people respect JavaScript or other languages enough to learn them inside-out, and yet constantly dunk on CSS?

The headline begs the question, but Robin makes this very insightful observation in the article itself:

I reckon the biggest issue that engineers face — and the reason why they find it all so dang frustrating — is that CSS forces you to face the webishness of the web. Things require fallbacks. You need to take different devices into consideration, and all the different ways of seeing a website: mobile, desktop, no mouse, no keyboard, etc. Sure, you have to deal with that when writing JavaScript, too, but it’s easier to ignore. You can’t ignore your the layout of your site being completely broken on a phone.

Tuesday, February 25th, 2020

Inspiring high school students with HTML and CSS - Stephanie Stimac’s Blog

I love, love, love this encounter that Stephanie had with high school students when she showed them her own website (“Your website? You have a website?”).

I opened the DevTools on my site and there was an audible gasp from the class and excited murmuring.

“That’s your code?” A student asked. “Yes, that’s all my code!” “You wrote all of that?!” “Yes, it’s my website.”

And the class kind of exploded and starting talking amongst themselves. I was floored and my perspective readjusted.

When I code, it’s usually in HTML and CSS, and I suppose there’s a part of me that feels like that isn’t special because some tech bros decide to be vocal and loud about HTML and CSS not being special nearly everyday (it is special and tech bros can shut up.)

And the response from that class of high school students delighted me and grounded me in a way I haven’t experienced before. What I view as a simple code was absolute magic to them. And for all of us who code, I think we forget it is magic. Computational magic but still magic. HTML and CSS are magic.

Yes! Yes! Yes!

Monday, February 24th, 2020

Let’s Define CSS 4 · Issue #4770 · w3c/csswg-drafts

Jen kicked off a fascinating thread here:

It’s come up quite a few times recently that the world of people who make websites would greatly benefit from the CSS Working Group officially defining ”CSS 4”, and later “CSS 5“, etc.

The level is discourse is impressively smart and civil.

Personally, I don’t (yet) have an opinion on this either way, but I’ll be watching it unfold with keen interest.

Le Corbusier: How A Utopic Vision Became Pathological In Practice | Orange Ticker

Through planning and architectural design, Le Corbusier hoped to create a scientifically rational and comprehensive solution to urban problems in a way that would both promote democracy and quality of life. For him, the factory production process applied to high-rise buildings with prefabricated and standardized components is the most modern and egalitarian of urban forms.

Something something top-down design systems.

Tuesday, February 18th, 2020

An app can be a home-cooked meal

I am the programming equivalent of a home cook.

The exhortation “learn to code!” has its foundations in market value. “Learn to code” is suggested as a way up, a way out. “Learn to code” offers economic leverage, a squirt of power. “Learn to code” goes on your resume.

But let’s substitute a different phrase: “learn to cook.” People don’t only learn to cook so they can become chefs. Some do! But far more people learn to cook so they can eat better, or more affordably, or in a specific way.

Friday, February 14th, 2020

Variable fonts’ past, present and future, according to Dalton Maag

In this interview, Biance Berning says:

Cassie Evans from Clearleft is an interesting person to follow as she combines web animation with variable font technology, essentially exploring the technology’s practicality and expression.

Hells yeah!

We’re only just scratching the surface of what variable fonts can do within more interactive and immersive spaces. I think we’ll see a lot more progress and experimentation with that as time goes on.

Monday, February 10th, 2020

Open source beyond the market - Signal v. Noise

The transcript of David Heinemeier Hansson keynote from last year’s RailsConf is well worth reading. It’s ostensibily about open source software but it delves into much larger questions.

Monday, February 3rd, 2020

The Web is Industrialized and I helped industrialize it - daverupert.com

We’ve industrialized design and are relegated to squeezing efficiencies out of it through our design systems. All CSS changes must now have a business value and user story ticket attached to it.

Dave follows on from my post about design systems and automation.

At the same time, I have seen first hand how design systems can yield improvements in accessibility, performance, and shared knowledge across a willing team. I’ve seen them illuminate problems in design and code. I’ve seen them speed up design and development allowing teams to build, share, and validate prototypes or A/B tests before undergoing costly guesswork in production. There’s value in these tools, these processes.

Wednesday, January 29th, 2020

Architects, gardeners, and design systems

I compared design systems to dictionaries. My point was that design systems—like language—can be approached in a prescriptivist or descriptivist manner. And I favour descriptivism.

A prescriptive approach might give you a beautiful design system, but if it doesn’t reflect the actual product, it’s fiction. A descriptive approach might give a design system with imperfections and annoying flaws, but at least it will be accurate.

I think it’s more important for a design system to be accurate than beautiful.

Meanwhile, over on Frank’s website, he’s been documenting the process of its (re)design. He made an interesting comparison in his post Redesign: Gardening vs. Architecture. He talks about two styles of writing:

In interviews, Martin has compared himself to a gardener—forgoing detailed outlines and overly planned plot points to favor ideas and opportunities that spring up in the writing process. You see what grows as you write, then tend to it, nurture it. Each tendrilly digression may turn into the next big branch of your story. This feels right: good things grow, and an important quality of growth is that the significant moments are often unanticipated.

On the other side of writing is who I’ll call “the architect”—one who writes detailed outlines for plots and believes in the necessity of overt structure. It puts stock in planning and foresight. Architectural writing favors divisions and subdivisions, then subdivisions of the subdivisions. It depends on people’s ability to move forward by breaking big things down into smaller things with increasing detail.

It’s not just me, right? It all sounds very design systemsy, doesn’t it?

This is a false dichotomy, of course, but everyone favors one mode of working over the other. It’s a matter of personality, from what I can tell.

Replace “personality” with “company culture” and I think you’ve got an interesting analysis of the two different approaches to design systems. Descriptivist gardening and prescriptivist architecture.

Frank also says something that I think resonates with the evergreen debate about whether design systems stifle creativity:

It can be hard to stay interested if it feels like you’re painting by numbers, even if they are your own numbers.

I think Frank’s comparison—gardeners and architects—also speaks to something bigger than design systems…

I gave a talk last year called Building. You can watch it, listen to it, or read the transcript if you like. The talk is about language (sort of). There’s nothing about prescriptivism or descriptivism in there, but there’s lots about metaphors. I dive into the metaphors we use to describe our work and ourselves: builders, engineers, and architects.

It’s rare to find job titles like software gardener, or information librarian (even though they would be just as valid as other terms we’ve made up like software engineer or information architect). Outside of the context of open source projects, we don’t talk much about maintenance. We’re much more likely to talk about making.

Back in 2015, Debbie Chachra wrote a piece in the Atlantic Monthly called Why I Am Not a Maker:

When tech culture only celebrates creation, it risks ignoring those who teach, criticize, and take care of others.

Anyone who’s spent any time working on design systems can tell you there’s no shortage of enthusiasm for architecture and making—“let’s build a library of components!”

There’s less enthusiasm for gardening, care, communication and maintenance. But that’s where the really important work happens.

In her article, Debbie cites Ethan’s touchstone:

In her book The Real World of Technology, the metallurgist Ursula Franklin contrasts prescriptive technologies, where many individuals produce components of the whole (think about Adam Smith’s pin factory), with holistic technologies, where the creator controls and understands the process from start to finish.

(Emphasis mine.)

In that light, design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.

Humans aren’t always great at efficiency and consistency, but machines are. Automation increases efficiency and consistency, sacrificing messy humanity along the way:

Machine with the strength of a hundred men
Can’t feed and clothe my children.

Historically, we’ve seen automation in terms of physical labour—dock workers, factory workers, truck drivers. As far as I know, none of those workers participated in the creation of their mechanical successors. But when it comes to our work on the web, we’re positively eager to create the systems to make us redundant.

The usual response to this is the one given to other examples of automation: you’ll be free to spend your time in a more meaningful way. With a design system in place, you’ll be freed from the drudgery of manual labour. Instead, you can spend your time doing more important work …like maintaining the design system.

You’ve heard the joke about the factory of the future, right? The factory of the future will have just two living things in it: one worker and one dog. The worker is there to feed the dog. The dog is there to bite the worker if he touches anything.

Good joke.

Everybody laugh.

Roll on snare drum.

Curtains.