Categories
business Career CSS Design Education maturity

You got this.

I’M LEARNING new tech and it’s hard. Maybe you’re in the same boat.

Through the rosy lens of memory, learning HTML and Photoshop back in the day was a breeze.

It wasn’t, really. And CSS, when it came along in 1996, was even tougher to grasp—in part because it was mostly theoretical, due to poor support in some browsers and no support at all in others; in part because the design model in early CSS wasn’t conceived by designers.

But my memory of learning these tools in 1995 and 1996 is pain-free because it’s an old pain, forgotten because of time passing and even more because the pleasure of achievements gained by acquired knowledge masks the pain of acquisition. (See also: learning to read, learning to ride a bicycle.)

Beyond all that, my old learning’s pain-free in hindsight because I view it through the filter of nostalgia for a younger, simpler me in a simpler time. I was faster, sexier, ached less. Maybe you feel that way sometimes.

Most of all, I falsely remember it being easy to learn HTML, CSS, and Photoshop because I wanted to learn those things. I was doing it for me, not for a job, and certainly not to keep up.

I was a pioneer—we all were, back then. I was passionate about the possibilities of the web and eager to contribute.

Do you dream in color?

That first year of learning web design, I often, quite literally, dreamed in four-color GIFs. I got near-physical pleasure from reducing file sizes. I subscribed to every web design mailing list out there, and even started one of my own.

Remember mailing lists? I don’t mean sponsored, monetized newsletters with images and tortuous HTML. I mean stuff you read in Lynx.

When I shared what I was learning, by writing about it—when I learned what I was learning by teaching it—I felt euphoric. We were at the dawn of a new kind of information age: one that came from the people, and to which anyone could contribute merely by learning a few simple HTML elements. It was going to be great. And democratic. And empowering. Our tech would uplift the whole suffering world.

With every new discovery I made and shared, I felt a sense of mastery and control, and a tingling certainty that I was physically contributing to a better world of the near-future. A world forged in the best tech ever: simple, human-readable HTML.

And then the future happened.

Cut to 25 years later. Web design has become overly and often needlessly complex, and social media’s having a profoundly antisocial affect that designers with good intentions seem powerless to change.

Design is supposed to fix the world, not break it. Yet some of us, possibly even most of us, work on products and at companies we feel conflicted about.

Design is supposed to value simplicity. And yet here many of us are, struggling to learn new tech, and not feeling it.

But enough about the universe; let’s talk about me.

I’m learning new tech and it’s hard.

I work at a company that makes it easy to use a popular open-source publishing platform. Making things easy for customers is what design’s about. It’s also, always, hard work. And it’s supposed to be. The harder designers work behind the scenes, the easier the experience is supposed to get for the customer.

I have a confession to make: I love hard, mental, strategic design work. I love going cross-eyed envisioning customer journey options small and large. I love it like I love good typography and icons and layout, and I’m way better at it than I ever was at those things. I love it like I love color schemes, and, again—I’m better at it than I was at those.

And, stop me if you’ve heard this one, the more strategic I gets, the further from the code I feels.

Learning new code and tools

I’m not on a product team—I do client-facing design on a special projects team inside our product company—but every designer at the company should understand our products on a deep level, and every designer at the company, whether officially working on product or not, should be able to help make the products better for the customer.

For team-building and other reasons, every designer at our company who can do so is flying to a desert resort next month for a meet-up. And at that meet-up, each of us will fix at least one thing that’s wrong with one of our products. And when I say fix it, I don’t mean file a bug report as a GitHub issue. I mean fix it.

To be ready for that, I’m learning code and tools I probably should have learned a few years ago, but, as a rich man says of his servants, I always had people for that.

New to my work day, before and after internal and client meetings, I slog away trying to master command line interfaces, GitHub workflow, WordPress Calypso, Gutenberg, and React. I’ll need facility in these areas to do a live product fix at next month’s meetup.

Getting the hang of this tech will empower me to fix broken designs and create good ones. That excites me. But learning new things is hard—and GitHub, Terminal, Calypso, Gutenberg and React do not come nearly as naturally to me as HTML, CSS, and Photoshop did 25 years ago (or so I remember).

Age. It’s not just a number.

We’ve all heard that the body replaces itself every seven years. Which means I’m not just a different person mentally, emotionally, and spiritually since I first learned web design 25 years ago; I’m also physically an entirely different person, inhabiting a body that’s been rebuilt, cell by cell, more than three times. (The actual science is more granular than the seven-year meme, but go with me, here.)

At my age, change comes harder than it used to. Guess what? That means I need to change, not just to do my job; I need to change to stay young. (No, that’s not science, but yes, it works.) When it’s hard to move, you need to start exercising, even if starting is hard. When you’re trapped in a dead-end relationship, it’s time to say goodbye, even though breaking up is sad and scary and hard as hell. And if you work in tech and find yourself thinking your past learning gets you off the hook from having to learn new things, you need to think again.

Change. Try it, you’ll like it.

I’m lucky. I work in a supportive place. When I get stuck, a dozen people offer to help. (If where you work isn’t like this, consider working with us.)

Learning new things is hard, and it gets harder if you’re rusty at it, but it gets easier if you keep at it. Or so I tell myself, and my friends tell me.

Maybe you’re in the same position. Maybe you’ve even wasted time and energy on mental ju-jitsu like this: “I believe in semantic, accessible HTML. Therefore I don’t need to learn React.” If that’s you, and it was me, review your thinking. There is no therefore. You can have both things.

You can do this, because I can, and I’m more stubborn and more full of myself than you ever were.

So to my old-school sisters and brothers in HTML. If you’re struggling to learn new things today so you can do your job better tomorrow, I’m going to tell you what a friend told me this morning:

“You got this.”

__

 

Photo by Tim Gouw on Unsplash

Categories
A List Apart Best practices Code CSS CSS Grid Layout Design development

The Cult of the Complex

Illustration by Kevin Cornell.
“IN AN INDUSTRY that extols innovation over customer satisfaction, and prefers algorithm to human judgement (forgetting that every algorithm has human bias in its DNA), perhaps it should not surprise us that toolchains have replaced know-how.”

Our addiction to complicated toolchains and overbuilt frameworks is out of control. Web-making has lately become something of a dick-measuring competition. It needn’t stay that way.

If we wish to get back to the business of quietly improving people’s lives one thoughtful interaction at a time, we must rid ourselves of the cult of the complex. For more about why and how, see my new article, “The Cult of the Complex,” in A List Apart, for people who make websites.

 

 

 

Illustration by Kevin Cornell

Categories
Best practices CSS HTML industry Markup Off My Lawn! Responsibility Standards State of the Web The Essentials The Profession

Kiss My Classname

SORRY. I disagree. Nonsemantic classnames that refer to visual styles will always be a bad idea.

I’m sure you’re a good coder. Probably much better than I am these days. I know most of you weren’t around for the standards wars and don’t know how much damage non-semantic HTML and CSS did to the web.

I’ve worked on big sites and I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.

Slapping a visually named class on every item in your markup may indeed make your HTML easier to understand for a future developer who takes over without talking to you, especially if you don’t document your work and create a style guide. But making things easier for yourself and other developers is not your job. And if you want to make things easier for yourself and other developers, talk to them, and create a style guide or pattern library.

The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries. And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top.

Employers who value quality in CSS and markup will insist that their employees communicate, think through long-term implications, and document their work. Employers who see developers and designers as interchangable commodities will hurry their workers along, resulting in bloated codebases that lead intelligent people to blame best practices instead of work processes.

The present is always compromised, always rushed. We muddle through with half the information we need, praised for our speed and faulted when we stop to contemplate or even breathe. Frameworks built on newish worst practices seem like the way out, but they end up teaching and permanently ingraining bad habits in a generation of web makers. Semantics, accessibility, and clarity matter. Reusability is not out of reach. All it takes is clarity and communication.

Categories
A Book Apart A List Apart Advertising Advocacy An Event Apart architecture automattic Blogs and Blogging business Career client services clients climate change Code Community conferences content Coudal Partners creativity CSS Design Designers development DWWS engagement eric meyer Future-Friendly glamorous HTML Ideas industry Jason Santa Maria launches Ma.gnolia My Back Pages Off My Lawn! parenting peachpit Publications Publisher's Note Publishing Redesigns Self-Employment software Standards Startups State of the Web Stories studio.zeldman The Essentials The Profession Usability User Experience UX Web Design Web Design History Web Standards Websites wordpress Working writing Zeldman zeldman.com

Ten Years Ago on the Web

2006 DOESN’T seem forever ago until I remember that we were tracking IE7 bugsworrying about the RSS feed validator, and viewing Drupal as an accessibility-and-web-standards-positive platform, at the time. Pundits were claiming bad design was good for the web (just as some still do). Joe Clark was critiquing WCAG 2. “An Inconvenient Truth” was playing in theaters, and many folks were surprised to learn that climate change was a thing.

I was writing the second edition of Designing With Web Standards. My daughter, who is about to turn twelve, was about to turn two. My dad suffered a heart attack. (Relax! Ten years later, he is still around and healthy.) A List Apart had just added a job board. “The revolution will be salaried,” we trumpeted.

Preparing for An Event Apart Atlanta, An Event Apart NYC, and An Event Apart Chicago (sponsored by Jewelboxing! RIP) consumed much of my time and energy. Attendees told us these were good shows, and they were, but you would not recognize them as AEA events today—they were much more homespun. “Hey, kids, let’s put on a show!” we used to joke. “My mom will sew the costumes and my dad will build the sets.” (It’s a quotation from a 1940s Andy Hardy movie, not a reflection of our personal views about gender roles.)

Jim Coudal, Jason Fried and I had just launched The Deck, an experiment in unobtrusive, discreet web advertising. Over the next ten years, the ad industry pointedly ignored our experiment, in favor of user tracking, popups, and other anti-patterns. Not entirely coincidentally, my studio had just redesigned the website of Advertising Age, the leading journal of the advertising profession.

Other sites we designed that year included Dictionary.com and Gnu Foods. We also worked on Ma.gnolia, a social bookmarking tool with well-thought-out features like Saved Copies (so you never lost a web page, even if it moved or went offline), Bookmark Ratings, Bookmark Privacy, and Groups. We designed the product for our client and developed many of its features. Rest in peace.

I was reading Adam Greenfield’s Everyware: The Dawning Age of Ubiquitous Computing, a delightfully written text that anticipated and suggested design rules and thinking for our present Internet of Things. It’s a fine book, and one I helped Adam bring to a good publisher. (Clearly, I was itching to break into publishing myself, which I would do with two partners a year or two afterwards.)

In short, it was a year like any other on this wonderful web of ours—full of sound and fury, true, but also rife with innovation and delight.


As part of An Event Apart’s A Decade Apart celebration—commemorating our first ten years as a design and development conference—we asked people we know and love what they were doing professionally ten years ago, in 2006. If you missed parts onetwothree, or four, have a look back.

 

 

Categories
Code CSS Design Free Advice

Position Wanted: Front-End Director

WE have creative directors and design directors, but we don’t seem to have any front-end directors. And maybe we should.

For years at big companies, people in different silos have written CSS with no information or understanding about each other’s work. This results in huge, sloppy files that have a negative impact on site performance, as folks write more and more complex rules trying to override pre-existing ones … or “solve” the problem by adding dozens or even hundreds of classes to their CSS and markup.

Professionals with serious front-end chops have tried to solve the problem by coming up with complex rules and systems which, by the time they filter their way down to less experienced developers, get turned into dogma. Every time I see a front-end article’s comments section rapidly fill with absolute statements about whether it’s okay or not to use id, I recognize that someone’s good idea has turned into somebody else’s religion.

And while I commend my colleagues who craft approaches to CSS that help avoid the inevitable problems large-scale enterprises encounter when many coders in many silos work on many components without talking to each other, I think there may be another way to look at the problem.

We all know having many people in many silos write CSS any old way doesn’t work, unless you consider bloat and poor performance working.

And while restricting how you allow people to write code solves some of these problems, it introduces others: too many class names is just another word for bloat.

So how about following the example of other creative endeavors, and putting a single mind in charge? After all, no matter how many disparate photographers, teamed with how many art directors, work on a given issue of a periodical, there’s always a lead art director who advises, helps plan shoots, and ultimately approves the work. Every orchestra requires a conductor. And no matter how many animators work on a film, there’s always a director. There’s a reason for that.

Imagine shooting a film with no director and no storyboards, in which each scene was written by a different screenwriter, and nobody knew the shape of the overall story. It wouldn’t make a coherent movie, much less a good one. Yet that’s how too many big organizations still approach front-end design and development.

So here’s a thought, big orgs. Instead of throwing a thousand front-end developers at your problem and seeing what sticks, consider creating a front-end director position as empowered as any other director at your organization.

Categories
Code CSS CSS3 Design Layout

Grid Layout & Flexbox City

CSS GRID LAYOUT is nearly finalized. Which means it’s time for designers and front-end developers to set the flags enabling their browsers to support the new specification, put CSS Flexbox through its paces by using it to create layouts, and see if anything breaks. This way, if anything does break, we’ll have time to tell the framers of CSS Grid Layout what happened, and get the spec (and browser support) fixed before it is released. Once Grid is finalized, it will be too late to fix oversights.

The links below can help you (and me) get up to speed with the new tech:

CSS Grid Layout and CSS Flexbox Links

Thank You

Additional link curation by Rachel Andrew, author of Get Ready for CSS Grid Layout from A Book Apart, and speaker extraordinaire at An Event Apart Nashville, a three-day conference that wrapped yesterday. For a ton of great web resources, see AEA Resources: Articles, Links, and Tools From An Event Apart Nashville 2016.

Categories
A Book Apart A List Apart Advocacy An Event Apart Best practices Big Web Show Browsers chrome Code CSS CSS Grid Layout CSS3 Design HTML Layout Standards State of the Web The Big Web Show Web Design Web Design History Web Standards

CSS Grid Layout with Rachel Andrew: Big Web Show

Rachel Andrew

RACHEL ANDREW—longtime web developer and web standards champion, co-founder of the Perch CMS, and author of Get Ready For CSS Grid Layout—is my guest on today’s Big Web Show. We discuss working with CSS Grid Layout, how Grid enables designers to “do something different” with web layout, why designers need to start experimenting with Grid Layout now, how front-end design has morphed into an engineering discipline, learning HTML and CSS versus learning frameworks, and the magic of David Bowie, RIP.

Enjoy Episode ? 141 of The Big Web Show.

Sponsored by A List Apart and An Event Apart.

URLs

rachelandrew.co.uk
Get Ready for CSS Grid Layout
Perch CMS
Writing by Rachel Andrew
Books by Rachel Andrew
@rachelandrew

Categories
A Book Apart Announcements business CSS CSS3 Design Designers

A Book Apart Briefs!

Introducing A Book Apart Briefs–even briefer books for people who make websites.

FROM THOSE WONDERFUL people who brought you Responsive Web Design, Design Is A Job, Mobile First, plus thirteen additional instant classics of web design and development, here come A Book Apart Briefs: even briefer books for people who make websites. Starting with the immediately useful and illuminating Get Ready For CSS Grid Layout by Rachel Andrew (foreword by Eric Meyer), and Pricing Design by Dan Mall (foreword by Mike Monteiro).

Web design is about multi-disciplinary mastery and laser focus, so we created A Book Apart to cover the emerging and essential topics in web design and development with style, clarity, and, above all, brevity. Every title in our catalog sheds clear light on a tricky subject, and fast, so you can get back to work.

With sixteen classics under our belt, and buoyed by your support over the years, today we take that mission one step further with our new, ebook-only guides to essential fundamentals, of-the-moment techniques, and deep nerdery.

As A Book Apart co-founder and publisher, it actually thrills me to bring you the pricing guide our business has needed since forever, by Superfriends founder Dan Mall; and the easily understandable guide to the next generation of CSS layout, by the super-talented and incredibly brilliant Perch co-founder Rachel Andrew.

There are no better writer/designers to present these topics. And there are no needless words to waste your time, because these are A Book Apart Briefs: same great writing, even more brief.

Dig in!

Categories
Authoring Best practices Compatibility Content First Content-First CSS CSS3 Design Ethan Marcotte HTML HTML5 Jeremy Keith links Standards State of the Web Told you so Web Design Web Design History Web Standards

Of Patterns and Power: Web Standards Then & Now

IN “CONTENT Display Patterns” (which all front-end folk should read), Dan Mall points to a truth not unlike the one Ethan Marcotte shared last month on 24 ways. It is a truth as old as standards-based design: Construct your markup to properly support your content (not your design).

Modular/atomic design doesn’t change this truth, it just reinforces its wisdom. Flexbox and grid layout don’t change this truth, they just make it easier to do it better. HTML5 doesn’t change this truth, it just reminds us that the separation of structure from style came into existence for a reason. A reason that hasn’t changed. A reason that cannot change, because it is the core truth of the web, and is inextricably bound up with the promise of this medium.

Separating structure from style and behavior was the web standards movement’s prime revelation, and each generation of web designers discovers it anew. This separation is what makes our content as backward-compatible as it is forward-compatible (or “future-friendly,” if you prefer). It’s the key to re-use. The key to accessibility. The key to the new kinds of CMS systems we’re just beginning to dream up. It’s what makes our content as accessible to an ancient device as it will be to an unimagined future one.

Every time a leader in our field discovers, as if for the first time, the genius of this separation between style, presentation, and behavior, she is validating the brilliance of web forbears like Tim Berners-Lee, Håkon Wium Lie, and Bert Bos.

Every time a Dan or an Ethan (or a Sara or a Lea) writes a beautiful and insightful article like the two cited above, they are telling new web designers, and reminding experienced ones, that this separation of powers matters.

And they are plunging a stake into the increasingly slippery ground beneath us.

Why is it slippery? Because too many developers and designers in our amnesiac community have begun to believe and share bad ideas—ideas, like CSS isn’t needed, HTML isn’t needed, progressive enhancement is old-fashioned and unnecessary, and so on. Ideas that, if followed, will turn the web back what it was becoming in the late 1990s: a wasteland of walled gardens that said no to more people than they welcomed. Let that never be so. We have the power.

As Maimonides, were he alive today, would tell us: he who excludes a single user destroys a universe. Web standards now and forever.

Categories
A List Apart art direction Bandwidth Best practices creativity CSS CSS3 Design

CSS & Design: Blending Modes Demystified

A List Apart: Blending Modes Demystified. Illustration by Brad Colbow.

IN AN IDEAL world, we’d be able to modify a design or graphic for the web while keeping the original intact, all without opening an image editor. We’d save tons of time by not having to manually reprocess graphics whenever we changed stuff. Graphics could be neatly specified, maintained, and manipulated with just a few licks of CSS. Oh. Wait. We can do that! Justin McDowell gives us the lowdown: read Blending Modes Demystified in today’s A List Apart.


Illustration by Brad Colbow