Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers.

The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, in case you missed some here’s a quick and useful compilation of the most popular designer news that we curated from the past week.

The Best Design Tool of 2020 is not What You Expect

14 Top Design Trends to Watch Out for in 2021

UI Trends for 2077

Firefox was Always Enough

Wavelry – Create & Customise Wavey Svg and Png Backgrounds

Design Documentation

The Best 25 Black and White Web Design Inspiration

2020 Design Tools Survey

Web Design in 2021 – What to Expect

How to Accelerate your Online Presence Using SEO

Email Signature Design Guide, Best Practices, and Examples

Lavender – Write More Confident, Effective, and Thoughtful Emails

Buy Don’t Build

Glorify 2.0: Create High-Quality Product Images at Low Cost

5 WooCommerce Design Mistakes to Avoid

15 Best Free Christmas Fonts to Design Gift Cards

How to Create a Full Width Page in WordPress (Beginner’s Guide)

For the Fans: How to Make and Sell your own Merch

How to Build a Strong Design Team Structure

A Designer’s Guide to Receiving Criticism and Managing Feedback

It’s Always Year Zero

How to Design Better Pinterest Graphics and Attract Clicks

Dropover – Easier Drag & Drop on your Mac

7 Fantastic Youtube Videos on Web Typography

Colour Contrast Checker – Check the Contrast Between Different Colour Against WCAG

Want more? No problem! Keep track of top design news from around the web with Webdesigner News.

Source

Recently, I’ve become more deeply aware of the inherent tension between change and inertia, as it applies to the evolution and use of web technologies. These forces have always been present and opposed to each other, but it seems to me that the side effects of these collisions are impacting web development more noticeably.

On one hand, we’ve never seen more progress in the expansion of the array of web platform capabilities; the web is powerful and mature in ways that our 10-year younger selves would be seriously envious of. But on the other hand, like the crisp fall winds signal a seasonal shift, there’s a chill in the air settling down the once feverish pace of new JavaScript features—hello, JavaScript fatigue!—and new JavaScript frameworks seemingly launching weekly.

Technology is a word that describes something that doesn’t work yet.

Douglas Adams

As Adams’s humorous quip might imply, the software (technology) we work on doesn’t work yet, because it (and everything around it!) is always changing and evolving to something better.

Or… so it has seemed for a long time. But from where I peek out at web community trends, I think our community is shifting from the rapid expansion of the past few years to a season of consolidation and establishment.

There seems to be an expected assumption that any web team or project must stack itself on top of Babel, Webpack, TypeScript, JSX for the markup, styled-components (or CSS-in-JS of some sort), and one of just a handful of JavaScript frameworks (like React, Vue, or Angular).

That’s not to say these are the only options. I know there’s the Jamstack crowd who’s increasingly embracing static-site generation, and I know there’s the upstart Svelte crowd who wants to compile away all that front-end framework complexity (or so they claim).

But let’s be honest: the “diversity” we see in front-end framework tech now is more surface than substance. They all use some flavor of component-oriented mechanics (based on some kind of virtualized DOM), and with each new release of each framework, the parity between them is only increasing. We’ll see this space continue its contraction over the next few years, I think, to where the best parts of Svelte are built into React, and vice versa.

What will all this consolidation mean for the pace of change of JavaScript, or CSS, or even HTML itself? Will the core web platform technologies keep growing as they have, or will the demand for these changes subdue as developers stop asking for more and focus instead on doing more with what they’ve already got.

Is front-end tech almost solved? For my whole career, we’ve been assuming that every few years we’ll see a wholesale reinvention of the front end, on that ever-constant search for the perfect framework that rules them all. Are we nearing that point?

What’s clear to me is that the community is favoring inertia over change right now. What does work works so well—why should we rock the ship and try to disrupt and re-invent? The sheer brilliance (paired with countless human decades of blood sweat and tears) that has created the amazing front-end tools and frameworks might have finally done a good enough job that we don’t collectively care to keep asking it to do more.

Can you imagine trying to launch a competitor to React or Vue right now? Can you imagine trying to build a different tool to unseat TypeScript¹? It sure seems like a daunting enough hill that’s probably not worth trying to climb.

The big players have drawn in all the attention of millions of web developers worldwide, and they survived the heated change-fest over the last five years. We’re now settling on those few options that are left, as plenty powerful enough to build what we want. These solutions may not be idealist absolute maximums, but they’re undoubtedly approaching (at least) local maximums.

With the craziness we’ve all faced down in this weird year of 2020, maybe deep down in our guts, we’re all just yearning for some boring, stable, predictable comfort. Maybe that’s at least in part reflecting in our technology choices!?

I’ve been betting on change for, quite frankly, nearly two decades of my career in web technology. But I think my bet might be shifting to the predictability of inertia. We should assume that the default will be to stick to what you know already works rather than constantly looking for what might be emerging next.

Where’s your bet?

---

The post Change vs. Inertia appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Something I learned (or, I guess, re-learned) this year is how important it is to pay close attention to the bit depth of images. Way back in the day, we used to obsessively choose between 2-, 4-, or 8-bit color depth on our GIFs, because when lots of users were using dialup modems to surf the web, every kilobyte counted.

Now that a huge number of us access the web via broadband, guess what? Every kilobyte still counts. Because not everyone has access to broadband, particularly in the mobile space; and also, any time we can shave off page rendering is worth pursuing. I’d assumed that optimization tools handled things as trivial as color depth optimization that for us, but discovered I was wrong there.

This is particularly true for PNGs. By default, lots of image editing tools save PNGs with 2^24 color depth, just in case.

For a photograph, that makes some sense (though if it’s a photograph, you should probably save it as JPG or WebP) but for things like logos and icons, that’s approximately 2^24 more colors than you’re going to be using.

So in Acorn, my image editor of choice, I’ve been taking special care to crank down the bit depth on PNGs in the export dialog. In many cases, I’ve cut image weight 80% or more by indexing colors to a palette of 256 or fewer values, with no loss of visual fidelity. (Again, these aren’t photographs I’m talking about.)

Here’s an example:

That PNG at full-color depth is about 379KB. Restricted to a palette of 32 colors, it’s 61KB. And that’s just at the export time: once I run them through ImageOptim, the optimized sizes are 359KB and 48KB. That’s a weight savings of about 85%, just by lowering the color depth. And if I deployed the image and discovered it needs a few more colors, I could re-run the process to use 64 colors: the final size, in that case, is 73KB, still enormous savings.

Reducing color depth by eye is clearly more onerous than throwing an optimization script at a directory of images, but in my experience, the results are much more efficient in terms of image weight and therefore user experience. And that’s really what all this is about, isn’t it?

---

The post Optimizing Image Depth appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Tim Severien:

I feel we, the community, have to acknowledge that CSS is easy to get started with and hard to master. Let’s reflect on the language and find out what makes it hard.

Tim’s reasons CSS is hard (in my own words):

• You can look at a matching Ruleset, and still not have the whole styling story. There might be multiple matching rulesets in disparate places, including in places that only apply conditionally, like within @media queries.
• Even if you think you’ve got a complete handle on the styling information in the CSS, you still may not, because styling is DOM-dependent. You need information from both places to know how something will be styled.
• You have no control over the device, browser, version, resolution, input mode, etc., all of which can be CSS concerns.
• Making changes to CSS can be scary because it’s hard to understand everywhere it applies.

I’m not sure people making sweeping generalizations about CSS either being too hard or too easy is helpful for anyone. It’s much more interesting to look at what can be straightforward about CSS and what can be tricky, like Tim has done here.

Direct Link to Article — Permalink

---

The post What Makes CSS Hard To Master appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Animation is a fun and interesting way to bring life to a website. Used correctly, it can capture audience attention, make your website more engaging, and even improve your chances of delivering conversions for your clients.

Unfortunately, like many things in the web design world, it’s also easy to get too carried away with animation. As professional designers and developers, it’s up to us to find the line between making the most of animation on our website projects and creating a site that’s overwhelmed with too much activity.

Fortunately, by the time you’ve finished reading this article, you’ll have a deeper insight into how you can use animation in web design, without going too over the top.

Introducing Animation in Web Design

Animations are virtually everywhere on the web today.

In the past, when designers first discovered that they could embed movement into their websites, the amount of animation we saw was often higher than it needed to be. It wasn’t uncommon to find some websites running entirely on Flash, where every element could be animated.

Fortunately, the trends of modern web design have left those practices behind. These days, it’s a lot more common to make animation a part of the overall user experience, rather than focusing on them as a centerpiece attraction. For instance, you’ve probably noticed plenty of animated sliders showing off pictures in a gallery, or transition animations when people hover over a button.

Since it’s entirely possible to construct an entire website with no animations at all, the key to creating an engaging website today is making sure that every animation you use serves a specific purpose. Your animations should make a website more attractive, easier to use, and better for navigation. Add too many, and you could even risk slowing down a site.

So, where does it make sense to use animation for web design?

1. Loading Animations

One of the best ways to use animations in a website is to distract and delight users as a page loads. You can use the animation to deliver a unique experience, or even just highlight the playful nature of your brand. For instance, just check out this classic load animation called “Tightrope.”

You can also use things like particle animations to capture a customer’s attention and help your visitors relax when they visit a website. Particle animations can be interactive or non-interactive, and they’re a great way to stop visitors from feeling frustrated when a page takes too long to load.

A website by Edan Kwan called “Particle Love” shows you exactly what kind of experience you can create with real-time animations.

The more you can delight visitors with experiences that keep them engaged while the information they need is loading, the less likely people will be to hit the “back” button.

2. Microinteraction Animations

Microinteractions are quick and simple animations that come with specific use cases. Usually, this animation works to provide visual feedback and information when you interact with a specific element.

For instance, this microinteraction design from Colin Garven encourages users to enter their email address and password into a login field:

Ideally, the best way to use microinteractions is to make them as subtle as possible. These tools aren’t here to steal the spotlight from other information on the page. However, they can sometimes encourage your viewers to take the next stage in their conversion journey.

Animated microinteractions can be as complex or as basic as you choose. For instance, you could use them when:

• Highlighting if a feature is switched on or off;
• Letting users know when actions were successful (like sending a message in a contact form);
• Showcasing important information, like prices on a table;
• Animating icons on your site to encourage action;
• Depending on your experience with animations, you can even find themes and plugins that come with options already built-in.

3. Dynamic Backgrounds

An animated background can be an excellent way to make your website stand out from the crowd. However, it’s important to remember that excessive animation has a habit of making your site slower and more clunky than it needs to be.

The animated background on the mystaticself.com website is fantastic for introducing customers to new information with a handy dynamic menu.

Often, the only reason that you should create your own dynamic background for a website, is if it’s going to improve your customer’s experience in some way.

Remember, ensure that the animations that you’re using on your website aren’t going to make any aspect of your site more difficult to use. Animated backgrounds need to offer a compliment to your existing website, rather than distracting customers from what they want to do.

Before you go all-in with your background animations, focus on animating small sections of an image, one piece at a time. You can also animate components with very small motions too.

4. Reveal Hidden Messages

Another excellent way to use animation in web design is to harness it for showcasing important information. For instance, a navigation menu is an important component in your website design, but it can also take up a lot of valuable space.

In some cases, a hidden menu that appears when a customer scrolls over a small box or icon could make a lot of sense. You can also think about animated drop-down menus if you’re working with a website that has a large number of pages.

Check out this fun example of an animated CSS3 menu:

The sections change color and move as you hover over them, making it easier to see exactly where you’re clicking.

It’s up to you exactly how creative you want to be when you’re playing with animated menus. The easiest option is often just to have a component that changes color or shape with a hover effect. However, you can also expose hidden menus and extra information too.

For instance, with some websites, you can create pictures that turn over to show information on the other side. That means that you could create an about page with pictures of team members, which flip to show biography information.

Just make sure that everything works smoothly, both on desktop and mobile.

5. Try Carousels

Finally, we come to perhaps the simplest and most popular way of using animation in web design. Carousels are a common component of almost every theme on the web today. They’re great for showing off useful information, such as what a website has to offer, or which deals are available.

When creating a carousel, you can either give your users control over how quickly an image transitions, or you can implement automatic movement. On the heathfield.co.uk website, the designer has added buttons to let you flip backwards and forwards between photos, while also ensuring that the animation is automatic.

Without the animation to show you the pictures sliding into space, the transitions between each picture would be instant – which is a little more jarring for viewers.

Sliders are such a common component of web design today that customers almost expect to see them on many websites. That means that you can enjoy a very effective experience if you want to avoid doing anything too dramatic with your websites.

You can use sliders for everything from showing off products, to displaying testimonials from customers and more. It’s a great way to compress a lot of useful information into one small space on a site.

Use Website Animation Carefully

The most important thing for most designers to remember with animation and web design is that it’s entirely possible to have too much of a good thing. When it comes to creating amazing designs for your clients, you can take advantage of animation to encourage more engagement and a unique experience. However, you shouldn’t allow yourself to go too over the top.

Rather than animating every aspect of a page to constantly grab visitor attention, think about how you can make the visitor experience more compelling with the right animation choices. If an entire page of animation on the background isn’t right for your target audience, perhaps custom animations on a navigation bar or a slider would be a good option instead.

At the same time, remember to make the most of the latest technologies on the market for adding animation to web design. A good combination of CSS3, JavaScript, and HTML5 often makes it easier to create more immersive, high-quality animations that users can interact with on desktop and mobile alike.

Source

This year, I learned a lot about how “old” tricks can solve a lot of modern problems if you use the right tools. Following the growth of Jamstack-style development has been both a learning experience, while also a nostalgic one. It’s been amazing to see how you can power plain ol’ HTML, CSS, and JavaScript with the rise of headless CMSes, API-driven databases, e-commerce services, and modern frameworks.

I feel like the biggest hurdle that all of the different framework developers and hosting providers are trying to overcome is the fine art of caching. There are so many different approaches to how to serve the most performant, accessible, user-friendly, fast websites.

I love seeing the “hot takes” on this because some of them are old, some are new, and some are combining the old and the new into really interesting ideas.

Conversations around “stale-while-revalidate” and incremental static regeneration and hybrid applications are fascinating to me, and they’re all the right answer and the wrong answer depending on the project.

I’m very optimistic about the future of web development right now. There are a lot of smart brains experimenting with these technologies, and there’s a lot of education happening in the space right now. It reminds me of the phrase, “a rising tide lifts all boats.” We’re all trying to build the best websites we can right now, and though it might seem like it’s competitive, I’m very hopeful about how much we can be “lifted” together by collective learning.

---

The post What’s Old is New appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

I spent a good chunk of my work life this year trying (in collaboration with the amazing Noam Rosenthal) to standardize a new web platform feature: a way to modify the intrinsic size and resolution of images. And hey! We did it! But boy, was it ever a learning experience.

This wasn’t my first standardization rodeo, so many of the issues we ran into, I more-or-less anticipated. Strong negative feedback from browsers. Weird, unforeseen gotchas with the underlying primitives. A complete re-think or two. What I didn’t anticipate though, was that our proposal — which, again, was “only” about modifying the default display size of images — would run afoul of the fundamental privacy and security principles of the web. Because before this year, I didn’t really understand those principles.

Let me set the table a bit. What were we trying to do?

By default, images on the web show up exactly as big as they are. Embedding an 800×600 image? Unless you stretch or shrink that image with CSS or markup, that’s exactly how large it’s going to be: 800 CSS pixels across, and 600 CSS pixels tall. That’s the image’s intrinsic (aka “natural”) size. Another way to put this is that, by default, all images on the web have an intrinsic density of 1×.

That’s all well and good, until you’re trying to serve up high-, low-, or ?variable?-density images, without access to CSS or HTML. This is a situation that image hosts like my employer, Cloudinary, find themselves in quite often.

So, we set out to give ourselves and the rest of the web a tool to modify the intrinsic size and resolution of images. After a couple of re-thinks, the solution that we landed on was this:

1. Browsers should read and apply metadata contained within image resources themselves, allowing them to declare their own intended display size and resolution.
2. Following in the recent footsteps of image-orientation — by default, browsers would respect and apply this metadata. But you could override it or turn it off with a little CSS (image-resolution), or markup (srcset‘s x descriptors).

We felt pretty good about this. It was flexible, it built on an existing pattern, and it seemed to address all of the issues that had been raised against our previous proposals. Alas, one of the editors of the HTML spec, Anne van Kesteren, said: no. This wasn’t going to work. And image-orientation needed an urgent re-think, too. Because this pattern, where you can turn the effects of EXIF metadata on and off with CSS and HTML, would violate the “Same-Origin Policy.”

Uh… what?

Aren’t we just scaling and rotating images??

Confession time! Before all of this, I’d more or less equated the Same-Origin Policy with CORS errors, and all of the frustration that they’ve caused me over the years. Now, though, the Same-Origin Policy wasn’t just standing between me and handling a fetch, it was holding up a major work initiative. And I had to explain the situation to bosses who knew even less about security and privacy on the web than I did. Time to learn!

Here’s what I learned:

• The Same-Origin Policy isn’t a single, simple, rule. And it certainly isn’t == CORS errors.
• What it is, is a philosophy which has evolved over time, and has been inconsistently implemented across the web platform.
• In general, what it says is: the fundamental security and privacy boundary of the web is origins. Do you share an origin with something else on the web? You can interact with it however you like. If not, though, you might have to jump through some hoops.
• Why “might?” Well, a lot of cross-origin interactions are allowed, by default! Generally, when you’re making a website, you can write across origins (by sending POST requests off to whoever you please, via forms). And you can even embed cross-origin resources (iframes, images, fonts, etc) that your site’s visitors will see, right there on your website. But what you can’t do, is look at those cross-origin resources, yourself. You shouldn’t be able to read anything about a cross-origin resource, in your JavaScript, without specially-granted permission (via our old friend, CORS).
• Here’s the thing that blew my mind the most, once I finally understood it: cross-origin reads are forbidden by default because, as end-users, we all see different world-wide webs, and a website shouldn’t be able to see the rest of the web through its visitors’ eyes. Individuals’ varied local browsing contexts – including, but not limited to, cookies — mean that when I go to, say, gmail.com, I’m going to see something different than you, when you enter that same URL into your address bar and hit “return.” If other websites could fire off requests to Gmail from my browser, with my cookies, and read the results, well – that would be very, very bad!

So by default: you can do lots of things with cross-origin resources. But preventing cross-origin reads is kind of the whole ballgame. Those defaults are more-or-less what people are talking about when they talk about the “Same-Origin Policy.”

How does this all relate to the intrinsic size and resolution of images?

Let’s say there’s an image URL – https://coolbank.com/hero.jpg, that happens to return a different resource depending on whether or not a user is currently logged in at coolbank.com. And let’s say that the version that shows up when you’re logged in, has some EXIF resolution info, but the version that shows up when you’re not, doesn’t. Lastly, let’s pretend that I’m an evil phisher-man, trying to figure out which bank you belong to, so I can spoof its homepage and trick you into typing your bank login info into my evil form.

So! I embed https://coolbank.com/hero.jpg on an evil page. I check its intrinsic size. I turn EXIF-sizing off, with image-resolution: none, and then check its size again. Now, even though CORS restrictions are preventing me from looking at any of the image’s pixel data, I know whether or not it contains any EXIF resolution information — I’ve been able to read a little tiny piece of that image, across origins. And now, I know whether or not you’re logged into, and have an account at, coolbank.com.

Far-fetched? Perhaps! But the web is an unimaginably large place. And, as Jen Simmons once put it,

This one of the best & most important things about THE WEB. Go to a website, it’s safe from malware. Download an app, you are at risk. You can’t download random apps from random places. You can go to random websites, and expect to be safe. We must fight to keep the web like this. https://t.co/xKQ5vVNCaU

— Jen Simmons (@jensimmons) March 11, 2020

Browsing the web is basically going around running other people’s untrusted and potentially malicious code, willy-nilly, all day long. The principles that underly web security and privacy — including the Same-Origin Policy — enable this safety, and must be defended absolutely. The hole we were unintentionally trying to open in the Same-Origin Policy seemed so small, at first. A few literal bits of seemingly-harmless information. But a cross-origin read, however small, is a cross-origin read, and cross-origin reads are not allowed.

How did we fix our spec? We made EXIF resolution and orientation information un-readable across origins by making it un-turn-off-able: in cross-origin contexts, EXIF modifications are always applied. An 800×600 image whose EXIF says it should be treated as 400×300 will behave exactly like a 400×300 image, would, no matter what. A simple-enough solution — once we understood the problem.

As a bonus, once I really understood the Same-Origin Policy and the whys behind the web’s default security policies, a bunch of other web security pieces started to fall into place for me.

Cross-site request forgery attacks take advantage of the fact that cross-origin writes are allowed, by default. If an API endpoint isn’t careful about how it responds to POST requests, bad things can happen. Likewise, Content Security Policy allows granular control over what sorts of embeds are allowed, because again, by default, they all are, and it turns out, that opens the door to cross-site scripting attacks. And the new alphabet soup of web security features — COOP, COEP, CORP, and CORB — are all about shutting down cross-origin interactions completely, fixing some of the inconsistent ways that the Same-Origin Policy has been implemented over the years and closing down any/all possible cross-origin interaction, to achieve a rarefied state known as “cross-origin isolation”. In a world where Spectre and friends mean that cross-origin loading can be exploited to perform cross-origin reading, full cross-origin isolation is needed to guarantee saftey when doing various, new, powerful things.

In short:

• Security and privacy on the web are actually pretty amazing, when you think about it.
• They’re a product of the platform’s default policies, which are all about restricting interactions across origins.
• By default, the one thing no one should ever be able to do is read data across origins (without special permission).
• The reason reads are forbidden is that we all see different webs, and attackers shouldn’t be able to see the web through potential victims’ eyes.
• No ifs, ands, or buts! Any hole in the Same-Origin Policy, however small, is surface area for abuse.
• In 2020, I tried to open a tiny hole in the Same-Origin Policy (oops), and then got to learn all of the above.

Here’s to a safer and more secure 2021, in every possible sense.

---

The post I learned to love the Same-Origin Policy appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

(This is a sponsored post.)

Pluralsight is giving away 25 courses on JavaScript for free to celebrate JavaScript’s 25^th birthday. It’s no cheapie, either. The courses range from getting your hands dirty with JavaScript for the first time, to full-on reactive development. Pluralsight’s been around a long time and they know how to design a great course.

Five free courses are being released each week throughout this month, December. The $0 price tag is probably enough of an incentive to check things out. But in a year that’s made learning tough for lots of reasons, this might just be the sort of thing that gets you back on track, helps you level up, or even allows you to revisit things you’ve learned before.

Like, for me personally, I’m planning to brush up on objects, prototypes, and classes. Zell Liew wrote up a thorough article walking through them a little while back, and it reminded me just how rusty I am. And guess what? That’s one of the free courses. Score.

You can see the full course schedule to see everything that’s included. You do need to sign up, but it’s not like you enter a credit card or anything. You get a temporary user name, create a password, then start learning!

Direct Link to Article — Permalink

---

The post 25 Years of JavaScript & 25 Free Courses appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

In an age where so much web design is already neat, clean, and simple, I can think of three ways to distinguish your site from the norm:

1. Stunning visuals that cannot be created in UI vector editors, like Figma and Sketch
2. Beautifully-animated interactions that cannot be dreamt in the language of Stacks of Rectangles
3. Typography

The third is the most accessible, and an awesome place to differentiate your brand. Accordingly, look for a renaissance of type — a flourishing of serifs, throwbacks, quirky fonts, and genre-bending typefaces. Expect that font pairing will become an even more important skill, and picking great fonts for your brand will carry even more weight in the near future.

After all, it’s basically a design cheat code.

? There are only two “cheatcodes” in UI design. The first is: USE GOOD FONTS. Here, the popular but slightly too goofy Abril Fatface pales in comparison to stately Freight.
(10/50)

PS. More font recs here: https://t.co/zFle4by2Iq pic.twitter.com/vnpoHMq4I0

— Erik D. Kennedy (@erikdkennedy) November 27, 2020

---

The post Three Ways to Distinguish a Site From the Norm appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

When I first got this writing prompt, my mind immediately started thinking stuff like, “What tech have I learned this year?” But this post isn’t really about tech, because I think what I’ve learned the most about building websites this past year is simplification.

This year, I’ve learned that keeping it simple is almost always the best approach. Heck, I’ve been banging that drum for a while, but this year has really solidified those sort of thoughts. I’m trying to think of a single instance where a complex, technical issue has arisen this year, where the end-solution didn’t come about due to simplification, and I’m coming up blank. Sure, ideas almost always start off over-complicated, but I’m learning more and more that slowing down and refining ideas is the best approach.

Brendan Dawes created this great piece of art, and coincidentally, a copy of it sits on my wall. I think it illustrates my working process perfectly and acts as a constant reminder to refine and simplify.

I run Piccalilli and released my first course this year. I really wanted to self-publish that material, too. Sure, keeping it really simple would have me publishing the course on an existing platform, but I had some red lines. The first being that I had to own everything because if a provider or platform turned out to be ass-hats, then I’d be in a pickle.

Another red line was that my content had to be written, rather than videos, which again, makes owning my own content important, because some platforms can pull the rug from under your feet. A good example is Medium’s ever-changing content access rules and inconsistent paywall behavior.

Finally, the red line of all red lines was this: the content had to be fully accessible and easily accessed. You might be thinking they’re the same thing, but not quite: the easily accessed part means that if you buy content from me, you sure as heck will get to it with as little friction as possible.

---

This loops me nicely back to keeping things simple. To make access simple for my valued students, I needed to simplify my approach to them accessing content, while locking people out who hadn’t purchased it. My immediate thoughts — naturally — went into some complex architecture that was extremely smart™, because that’s what we do as developers, right? The difference this year versus previous years is that I forced myself to simplify and refine because I wanted to spend as little time and energy as possible writing code — especially code I know is going to haunt me in the future.

So, again, thinking about these red lines, the big caveat is that currently, my site runs off a static site generator — Eleventy, naturally — and my need for simplification along with this caveat led me to an obvious conclusion: use the platform.

In short, I used Service Workers to give people access to content. My site builds twice on Netlify. Once is what you see, over on piccalil.li. But there’s a secret site that is all exposed (it’s not really, it’s like Fort Knox) that has all the content available. When you buy a course, my little API scurries along to that site and finds all the content for it. It then pushes that down to you. Then, the platform takes over because I use the baked-in Cache and Response APIs. I create a Response for each lesson in the course, then stick it in the Cache. This means that whenever you go to a lesson, you get that version that was previously hidden from you. The added bonus to this is that the content is offline-first, too. Handy.

Sure, this solution relies on JavaScript, but heck, not much at all — especially when you compare it to even the simplest projects that produce extremely JavaScript-heavy outputs, like Gatsby et al.

Using the platform is super low maintenance because, y’know, it’s all baked into the browser, so it doesn’t keep me up at night, worrying that it’ll suddenly break if a rogue developer deletes a package. I could have also put together some galaxy brain stuff but that has a huge risk of creating technical debt and breaking at least one of my red lines: make content fully accessible and easily accessed. The platform again, wins.

If I push a big ol’ bundle of JavaScript down the pipe to a low-powered device and/or a slow connection, the chances are that content will not make it, or if it does, it will likely fail to parse. That alienates a lot of people which breaks red lines for me. Sure, building the site with this technology would keep it simple for me, as I wrote it, but utilizing the platform keeps it simple for everyone — especially me, when I need to maintain it. I’m digging that, a lot.

---

The post Learning to Simplify appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.