Don’t Use My Grid System (or any others)

This presentation by Miriam at DjangoCon US last summer is not only well done, but an insightful look at the current and future direction of CSS layout tools.

Many of us are familiar with Susy, the roll-your-own Grid system Miriam developed. We published a deep-dive on Susy a few years back to illustrate how easy it makes defining custom grid lines without the same pre-defined measures included in other CSS frameworks, like Foundation or Bootstrap. It really was (and is) a nice tool.

To watch Miriam give a talk that discourages using frameworks—even her very own—is a massive endorsement of more recent CSS developments, like Flexbox and Grid. Her talk feels even more relevant today than it was a few months ago in light of Eric Meyer’s recent post on the declining complexity of CSS.

Yes, today’s CSS toolkit feels more robust and the pace of development seems to have increased in recent years. But with it come new standards that replace the hacks we’ve grown accustomed to and, as a result, our beloved language becomes less complicated and less reliant on dependencies to make it do what we want.

Direct Link to Article — Permalink


Don’t Use My Grid System (or any others) is a post from CSS-Tricks

Comparing Novel vs. Tried and True Image Formats

Popular image file formats such as JPG, PNG, and GIF have been around for a long time. They are relatively efficient and web developers have introduced many optimization solutions to further compress their size. However, the era of JPGs, PNGs, and GIFs may be coming to an end as newer, more efficient image file formats aim to take their place.

We’re going to explore these newer file formats in this post along with an analysis of how they stack up against one another and the previous formats. We will also cover optimization techniques to improve the delivery of your images.

Why do we need new image formats at all?

Aside from image quality, the most noticeable difference between older and newer image formats is file size. New formats use algorithms that are more efficient at compressing data, so the file sizes can be much smaller. In the context of web development, smaller files mean faster load times, which translates into lower bounce rates, more traffic, and more conversions. All good things that we often preach.

As with most technological innovations, the rollout of new image formats will be gradual as browsers consider and adopt their standards. In the meantime, we as web developers will have to accommodate users with varying levels of support. Thankfully, Can I Use is already on top of that and reporting on browser support for specific image formats.

The New Stuff

As we wander into a new frontier of image file formats, we’ll have lots of format choices. Here are a few candidates that are already popping up and making cases to replace the existing standard bearers.

WebP

WebP was developed by Google as an alternative to JPG and can be up to 80 percent smaller than JPEGs containing the same image.

WebP browser support is improving all the time. Opera and Chrome currently support it. Firefox announced plans to implement it. For now, Internet Explorer and Safari are the holdouts. Large companies with tons of influence like Google and Facebook are currently experimenting with the format and it already makes up about 95 percent of the images on eBay’s homepage. YouTube also uses WebP for large thumbnails.

If you’re using a CMS like WordPress or Joomla, there are extensions to help you easily implement support for WebP, such as Optimus and Cache Enabler for WordPress and Joomla’s own supported extension. These will not break your website for browsers that don’t support the format so long as you provide PNG or JPG fallbacks. As a result, browsers that support the newer formats will see a performance boost while others get the standard experience. Considering that browser support for WebP is growing, it’s a great opportunity to save on latency.

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome Opera Firefox IE Edge Safari
23 12 No No No No

Mobile / Tablet

iOS Safari Opera Mobile Opera Mini Android Android Chrome Android Firefox
No 11.1 all 4.2-4.3 62 No

HEIF

High efficiency image files (or HEIF) actually bear the extension HEIC (.heic), which stands for high efficiency image container, but the two acronyms are being used interchangeably. Earlier this year, Apple announced that its newest line of products will support HEIF format by default.

On top of smaller file sizes, HEIF offers more versatility than other formats since it can support both still images and image sequences. Therefore, it’s possible to store burst photos, focal stacks, exposure stacks, images captured from video and other image collections in a single file. HEIF also supports transparency, 3D, and 4K.

In addition to images, HEIF files can hold image properties, thumbnails, metadata and auxiliary data such as depth maps and audio. Image derivations can be stored as well thanks to non-destructive editing operations. That means cropping, rotations, and other alterations can be undone at any time. Imagine all of your image variations contained in a single file!

Apple is doing everything it can to make the transition as seamless as possible. For example, when users share HEIF files with apps that do not support the format, Apple will automatically convert the image to a more compatible format such as JPG.

There is no browser support for HEIF at the time of this writing.

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome Opera Firefox IE Edge Safari
No No No No No No

Mobile / Tablet

iOS Safari Opera Mobile Opera Mini Android Android Chrome Android Firefox
No No No No No No

That being said, the file format offers impressive file savings for both video and images. This is becoming increasingly important as our devices become stronger and are able to take higher quality images and videos, thus resulting in a greater need for efficient media files.

FLIF

Free Lossless Image Format (or FLIF) uses a compression algorithm that results in files that are 14-74 percent smaller than older formats without sacrificing quality (i.e. lossless). Therefore, FLIF is a great fit for any type image or animation.

The FLIF homepage claims that FLIF files are 43% percent smaller on average than typical PNG files. The graph below illustrates how FILF compares to other formats in this regard.

FLIF often winds up being the most efficient format in tests.

FLIF takes advantage of something called meta-adaptive near-zero integer arithmetic coding, or (appropriately) MANIAC. FLIF also supports progressive interlacing so that images appear whole as soon as they begin downloading, which is another feature that has shown to reduce web page bounce rates.

The potential of FLIF is very exciting, but there is no browser support at the moment nor does it look like any browsers are currently considering adding it. While creators of the format are working hard on achieving native support for popular web browsers and image editing tools, developers can access the FLIF source code and snag a polyfill solution to test it out.

The Existing Stuff

As mentioned earlier, we’re likely still years away from the new formats completely taking over. In some cases, it might be better to stick with the tried and true. Let’s review what formats we’re talking about and discuss how they’ve stuck around for so long.

JPG

As the ruling standard for most digital cameras and photo sharing devices, JPG is the most frequently used image format on the internet. W3Techs reports that nearly three-quarters of all websites use JPG files. Similarly, most popular photo editing software save images as JPG files by default.

JPG is named after Joint Photographic Experts Group, the organization that developed the technology; hence why JPG is alternatively called JPEG. You may see these acronyms used interchangeably.

The format dates all the way back to 1992, and was created to facilitate lossy compression of bitmap images. Lossy compression is an irreversible process that relies on inexact approximations. The idea was to allow developers to adjust compression ratios to achieve their desired balance between file size and image quality.

The JPG format is terrific for captured photos; however, as the name implies, lossy compression comes with a reduction in image quality. Quality degrades further each time an image is edited and re-saved, which is why developers are taught to refrain from resizing images multiple times.

GIF

GIF is short for graphics interchange format. It depends on a compression algorithm called LZW, which doesn’t degrade image quality. The GIF format lacks the color support of JPG and PNG, but it has stuck around nonetheless thanks to its ability to render animations by bundling multiple images into a single file. Images stored inside a GIF file can render in succession to create a short movie-like effect. GIFs can be configured to display image sequences a set number of times or loop infinitely.

Image courtesy of Giphy.com

PNG

The good old portable network graphic (PNG) was originally conceptualized as the successor to the GIF format and debuted in 1996. It was designed specifically for representing images on the web. In terms of popularity, PNG is a close runner-up to JPG. W3Techs claims that 72 percent of websites use this format. Unlike JPG, PNG images are capable of lossless compression (meaning no image quality is lost).

Another advantage over JPG is that PNG supports transparency and opacity. Since large photos tend to look superior in the JPG format, the PNG format is typically used for non-complex graphics and illustrations.

Comparing the transparency support of JPG (left) and PNG (right).

Ways to Improve Image Optimization and Delivery

There are a few vital things to consider when optimizing images for the web because any file format—including the new ones—can end up adding yet another layer of complexity. Images typically account for the bulk of the bytes on a web page, so image optimization is considered low-hanging fruit for improving a website’s performance. The Google Dev Guide has a comprehensive article on the topic, but here is a condensed list of tips for speeding up your image delivery.

Implement Support for New Image Formats

Since newer formats like WebP aren’t yet universally supported, you must configure your applications so that they serve up the appropriate resources to your users.

You must be able to detect which formats the client supports and deliver the best option. In the case of WebP, there are a few ways to do this.

Invest in a CDN

A content delivery network (CDN) accelerates the delivery of images by caching them on their network of edge servers. Therefore, when visitors come to your website, they get routed to the nearest edge server instead of the origin server. This can produce massive time savings especially if your users are far from your origin server.

We have a whole post on the topic to help understand how CDNs work and how to leverage them for your projects.

Use CSS Instead of Images

Because older browsers didn’t support image shadows and rounded corners, veteran web developers are used to displaying certain elements like buttons as images. Remember the days when displaying a custom font required making images for headlines? These practices are still out in the wild, but are terribly inefficient approaches. Instead, use CSS whenever you can.

Check Your Image Cache Settings

For image files that don’t change very often, you can utilize HTTP caching directives to improve load times for your regular visitors. That way, when someone visits your website for the first time, their browser will cache the image so that it doesn’t have to be downloaded again on subsequent visits. This practice can also save you money by reducing bandwidth costs.

Of course, improper caching can cause problems. Adding a fingerprint, such as a timestamp, to your images can help prevent caching conflicts. Fortunately, most web development platforms do this automatically.

Resize Images for Different Devices

Figuring out how to best accommodate mobile devices with inferior screen resolutions is an ongoing process. Some developers don’t even bother and simply offer the same image files for all users, but this approach wastes your bandwidth and your mobile visitors’ time. Consider using srcset so that the browser determines which image size it should deliver based on the client’s size dimensions.

Image Compression Tests

It’s always interesting to see the size differences each image format provides. In the case of this article, we’re comparing lossless and lossy image formats together. Of course, that’s not common practice as many times lossy will be smaller in size than lossless as the quality of the image suffers in order to produce a smaller image size.

In any case, choosing between lossless and lossy image formats should be based on how image intensive your site is and how fast it already runs. For example, an e-commerce shop may be comfortable with a slightly degraded image in exchange for faster load times while a photographer website is likely the opposite in order to showcase talent.

To compare the sizes of each of the six image formats mentioned in this article, we began with three JPG images and converted them into each of the other formats. Here are the performance results.

  • Image 1
  • Image 2
  • Image 3

As previously mentioned, the results below vary significantly due to lossless/lossy image formats. For instance, PNG and FLIF images are both lossless, therefore resulting in larger image files.

Image 1 Size Image 2 Size Image 3 Size
WebP 1.8 MB 293 KB 1.6 MB
HEIF 1.2 MB 342 KB 1.1 MB
FLIF 7.4 MB 2.5 MB 6.6 MB
JPG 3.9 MB 1.3 MB 3.5 MB
GIF 6.3 MB 3.9 MB 6.7 MB
PNG 13.2 MB 5 MB 12.5 MB

According to the results above, HEIF images were smaller overall than any other format. However, due to their lack of support, it currently isn’t possible to integrate the HEIF format into web applications. WebP came in at a fairly close second and does offer ways to work around the less-than-ideal amount of browser support. For users who are using Chrome or Opera, WebP images will certainly help accelerate delivery.

As for the lossless image formats, PNG is significantly larger than it’s lossy JPG counterpart. However, when optimized with FLIF, savings of about 50 percent were realized. This makes FLIF a great alternative for those who require high-quality images at a smaller file size. That said FLIF currently isn’t supported by another web browsers yet, similar to HEIF.


Conclusion

The old image formats will likely still be around for many years to come, but more developers will embrace the newer formats once they realize the size-saving benefits.

Cameras, mobile devices and many gadgets, in general, are becoming more and more sophisticated meaning that the images and videos taken are of higher quality and taking up more space. New formats must be adopted to mitigate this and it looks like we have some extremely promising options to look forward to, even if it will take some time to see them officially adopted.


Comparing Novel vs. Tried and True Image Formats is a post from CSS-Tricks

The youth these days couldn’t possibly understand the abstraction of a floppy disk for a save icon.

People have been kicking that ol’ chestnut around for years.

Do the youngsters have no idea what it is?, we ask. What happens when all the things we based our icons on don’t exist anymore?, we wonder. Do we need a new one?, and we experiment.

Olivia Walch’s skewering is hilarious:

Baby bear: Make a button and put the word save in it.


The youth these days couldn’t possibly understand the abstraction of a floppy disk for a save icon. is a post from CSS-Tricks

Is jQuery still relevant?

Part of Remy Sharp’s argument that jQuery is still relevant is this incredible usage data:

I’ve been playing with BigQuery and querying HTTP Archive’s dataset … I’ve queried the HTTP Archive and included the top 20 [JavaScript libraries] … jQuery accounts for a massive 83% of libraries found on the web sites.

This corroborates other research, like W3Techs:

jQuery is used by 96.2% of all the websites whose JavaScript library we know. This is 73.1% of all websites.

And BuiltWith that shows it at 88.5% of the top 1,000,000 sites they look at.

Even without considering what jQuery does, the amount of people that already know it, and the heaps of resources out there around it, yes, jQuery is still relevant. People haven’t stopped teaching it either. Literally in schools, but also courses like David DeSandro’s Fizzy School. Not to mention we have our own.

While the casual naysayers and average JavaScript trolls are obnoxious for dismissing it out of hand, I can see things from that perspective too. Would I start a greenfield large project with jQuery? No. Is it easy to get into trouble staying with jQuery on a large project too long? Yes. Do I secretly still feel most comfortable knocking out quick code in jQuery? Yes.

Direct Link to Article — Permalink


Is jQuery still relevant? is a post from CSS-Tricks

When You Just Don’t Trust a Tab

Do we need a word for when a browser tab has sat too long and you just don’t trust thing are going to work as you expect them do when you come back?
I tweeted that the other day and apparently other people had them feels.

It’s that feeling where you just know your session isn’t valid anymore and if you actually try to do anything that requires you to be logged in, it ain’t gonna work. It’s particularly uncomfortable if you were actually trying to do something and now you’re unsure if it’s done or saved.

As for that name… here’s some good ones from the thread:

  • Schrödinger’s tab
  • Crusty tab
  • Tab smell
  • Stale tab
  • Fossilized tab
  • Tab napping
  • Dead tab
  • Orphaned tab
  • Tab rot

So how do you fix it?

It’s a UX issue, really. Depends on the situation. Here’s some options.

Shut it all down.

Banks do this a lot. When your session expires, which they time-limit pretty aggressively, you don’t just sit on the page, they log you out and send you back to a log in screen with a message.

They might warn you:

Then you’re gone:

That might seem a bit much for a site with less sensitive security. But it does quite nicely solve the (let’s pick one) “Dead Tab” issue. You aren’t left wondering anything. It took action, logged you out, and dropped you on a page where there isn’t any half-baked state.

Stay where you are, but warn about actions.

Many sites want to keep you logged in. Ideally, as long as it’s secure, you’d be logged in forever until you explicitly log out. Logging in is an awkward dance that nobody particularly enjoys and keeps you away from doing what you want to do.

CodePen is in this category, I’d say. We’d rather not log you out agressively, but certainly you can get logged out either with long periods of inactivity, or you can log yourself out. Say you logged out on a different tab… that’ll log you out everywhere, but at the moment we don’t anything for those other tabs left often that look like you are logged in.

That’s the “dead tab” issue. But we do warn you if an action happens that you can’t actually do.

WordPress has a kind of awkward flow related to this. Tabs can easily become dead, and if they do, you get no warning at all. When you perform an action that you can’t do, you’ll get this:

That’s a kind of middleman page that actually does refresh you session, so if you do “try again”, it usually works. It’s scary every time though. Even if it doesn’t work, the biggest risk in WordPress is losing writing, but even then, autosave usually saves the day.

Here’s an example on CodePen where I created a Pen when I was logged in, but logged out elsewhere, then tried to save.

I’d give us a C- here. At least you know what’s going on and you don’t lose any work, but, from here on out it’s awkward. You’ll have to log in on another tab, and probably copy and paste code elsewhere to save it, as the “dead tab” can’t get un-dead unless you refresh it.

If we were gunning for an A, we’d allow you to log in on that page without refreshing somehow, and make sure any unsaved changed get saved after the successful login. And with an unsuccessful login, still make sure you get a copy of unsaved work somehow. We might call that…

Stay where you are, warn proactively.

Perhaps messaging like: “You’ve been logged out. You can log back in here.”

To know this, the front end of your site needs to know about the log in status either periodically or in real time. For example, a server-ping every X seconds to check that status and if you’ve become logged out, show the message (without requiring any other action). Or perhaps a more modern websocket connection that could push the logging out messaging as it happens.

If you can wire that up to all happen on any page of the site, not require changing pages to fix it, and never lose any unsaved work, that’s pretty ideal.

The truly dead tab

The worst case scenario is when the tab has died, and there is no path to recovery. It doesn’t tell you it’s dead, leaving the page could result in unsaved work or actions, and there is no warning or recovery steps.

Have you seen great UX for this?

This is a major issue in that it affects every single site you can log into. It’s both suprising that there isn’t more talk and best practices surrounding this, and that there aren’t some stand-out sites that handle this particularly awesome to shout out.

Do you know of some particularly good (or bad) examples?


When You Just Don’t Trust a Tab is a post from CSS-Tricks

Creating Cue Files from Markdown

Pretty specific, huh? While we’re going to do exactly what the title says, this post is more about a learning exercise and an example of getting help on the internet.

My podcast editor, Chris Enns, is always looking for ways to improve his work and make podcasting better. One kinda cool way to do that is to offer “chapters” so that people can jump around in a podcast to specific points.

Through TimeJump, we already offer that on the website itself. Those happen in the format of hash links like this: #t=12:18. Believe it or not, relative links like that, in the show notes, actually work in some podcatchers (podcast listening apps).

Jumping around an audio element with the TimeJump JavaScript library.

But using “chapters” is, I suppose, the more correct way of handling this. With chapters, a podcatcher can offer its own native UI for displaying and allowing the user to jump between chapters.

Even iOS 11 is now supporting them in the podcast app:

This is the Podcast app built into iOS, but all sorts of different podcatchers display chapters in their own way.

How do you add them to a podcast? I’m no expert here, but there is an native Mac app called Podcast Chapters that does this:

This is exactly what Chris Enns uses to add the chapters, which leads us to Chris’ workflow. Chris writes show notes for podcasts, and does that in Markdown format. The shows he edits for (at least some of them) post the show notes on the web and the CMS’s that power that use Markdown.

He’ll create a Markdown list (TimeJump compatible) of what is happening in the podcast, like this:

* **[1:49](#t=1:49)** Toys from the future.
* **[8:40](#t=8:40)** Talking about flip.

Another piece of the puzzle here is that the Podcast Chapters app does its thing by giving it a `.cue` file. Cue files look like this:

PERFORMER "ShopTalk Show" TITLE "Episode 273" FILE "shoptalk-273.mp3" MP3 TRACK 01 AUDIO PERFORMER "" TITLE "Toys from the future." INDEX 01 01:49:00 TRACK 02 AUDIO PERFORMER "" TITLE "Talking about flip." INDEX 01 08:40:00

That’s a very specific format. It’s hand-writable, sure, but it essentially has all the same data as that Markdown list, just in a different format.

There is even an online generator to help make them:


All that stuff I just explained I only understand because Chris himself explained it. This is my favorite part. He explained it by asking for help through a YouTube video that make the problem clear as day.

Chris knew exactly what he needed to make this workflow work, he just couldn’t figure out one little part of it, so he asked.

To be honest, I didn’t really know how to solve it either. But, maybe just maybe, I knew just a little bit more, enough to get the process started.

  1. I know how to make an interface that would do the job here: side-by-side <textarea>s for easy copy and pasting.
  2. I know JavaScript can get this done, because it can grab string values out of textareas and has plenty of string processing methods.
  3. I know it’s likely to be RegEx territory.

I also know this is programming stuff at the edge of my abilities. I bet I could do it, but it might take me all day and really challenge me.

So instead, I again set the problem up for someone else to jump in and help.

I wrote a script (“a script in the screenwriting or theatre sense”) to explain what I thought needed to happen. I made a Pen, and in the JavaScript area, wrote out…

/* Step 1 Break markdown in first textarea into array of lines Loop over each line Step 2 Extract value "1:49" from line Step 3 Convert value to "01:49:00" Step 4 Extract value "Toys from the future." from line Step 5 Place these two values into a template you can see in the second textarea */

Then James Padolsey jumped in an helped with the final solution:

See the Pen WIP: Creating Cuefile from Markdown by James Padolsey (@padolsey) on CodePen.

It does exactly what everyone was hoping it would do! Thanks James!

It does essentially what I laid out in my little script.

Splits on new lines and loops over the array:

markdown.split('\n').map((line, i) => {

Extract parts of the string that are best to work with:

const title = line.split('** ')[1];
const time = line.match(/\d+:\d+/)[0];

Then manipulates those bits into shape and ultimately uses template literals to craft a new string to plop back into the textarea.

I’m sure this isn’t the only way, and you might balk at the fragility and perhaps awkward nature of this type of parsing. But it also solves a very real and immediate workflow issue.


Creating Cue Files from Markdown is a post from CSS-Tricks

Evolution of img: Gif without the GIF

Colin Bendell writes about a new and particularly weird addition to Safari Technology Preview in this excellent post about the evolution of animated images on the web. He explains how we can now add an MP4 file directly to the source of an img tag. That would look something like this:

<img src="video.mp4"/>

The idea is that that code would render an image with a looping video inside. As Colin describes, this provides a host of performance benefits:

Animated GIFs are a hack. […] But they have become an awesome tool for cinemagraphs, memes, and creative expression. All of this awesomeness, however, comes at a cost. Animated GIFs are terrible for web performance. They are HUGE in size, impact cellular data bills, require more CPU and memory, cause repaints, and are battery killers. Typically GIFs are 12x larger files than H.264 videos, and take 2x the energy to load and display in a browser. And we’re spending all of those resources on something that doesn’t even look very good – the GIF 256 color limitation often makes GIF files look terrible…

By enabling video content in img tags, Safari Technology Preview is paving the way for awesome Gif-like experiences, without the terrible performance and quality costs associated with GIF files. This functionality will be fantastic for users, developers, designers, and the web. Besides the enormous performance wins that this change enables, it opens up many new use cases that media and ecommerce businesses have been yearning to implement for years. Here’s hoping the other browsers will soon follow.

This seems like a weird hack but, after mulling it over for a second, I get how simple and elegant a solution this is. It also sort of means that other browsers won’t have to support WebP in the future, too.

Direct Link to Article — Permalink


Evolution of img: Gif without the GIF is a post from CSS-Tricks

Calendar with CSS Grid

Here’s a nifty post by Jonathan Snook where he walks us through how to make a calendar interface with CSS Grid and there’s a lot of tricks in here that are worth digging into a little bit more, particularly where Jonathan uses grid-auto-flow: dense which will let Grid take the wheels of a design and try to fill up as much of the allotted space as possible.

As I was digging around, I found a post on Grid’s auto-placement algorithm by Ian Yates which kinda fleshes things out more succinctly. Might come in handy.

Oh, and we have an example of a Grid-based calendar in our ongoing collection of CSS Grid starter templates.

Direct Link to Article — Permalink


Calendar with CSS Grid is a post from CSS-Tricks

An Open Source Etiquette Guidebook

Open source software is thriving. Large corporations are building on software that rests on open collaboration, enjoying the many benefits of significant community adoption. Free and open source software is amazing for its ability to bring together many people from all over the world, and join their efforts and skills by their interests.

That said, and because we come from so many different backgrounds, it’s worth taking a moment to reflect on how we work together. The manner in which you conduct yourself while working with others can sometimes impact whether your work is merged, whether someone works on your issue, or in some cases, why you might be blocked from participating in the repository in the future. This post was written to guide people as best as possible on how to keep these communications running smoothly. Here’s a bullet point list of etiquette in open source to help you have a more enjoyable time in the community and contribute to making it a better place.

For the Maintainer

  • Use labels like “help wanted” or “beginner friendly” to guide people to issues they can work on if they are new to the project.
  • When running benchmarks, show the authors of the framework/library/etc the code you’re going to run to benchmark on before running it. Allow them to PR (it’s ok to give a deadline). That way when your benchmark is run you know they have your approval and it’s as fair as possible. This also fixes issues like benchmarking dev instead of prod or some user errors.
  • When you ask someone for help or label an issue help wanted and someone PRs, please write a comment explaining why you are closing it if you decide not to merge. It’s disrespectful of their time otherwise, as they were following your call to action. I would even go so far as to say it would be nice to comment on any PR that you close OR merge, to explain why or say thank you, respectively.
  • Don’t close a PR from an active contributor and reimplement the same thing yourself. Just… don’t do this.
  • If a fight breaks out on an issue that gets personal, shut it down to core maintainers as soon as possible. Lock the issue and ensure to enforce the code of conduct if necessary.
  • Have a code of conduct and make its presence clear. You might consider the contributor covenant code of conduct. GitHub also now offers easy code of conduct integration with some base templates.

For the User

  • Saying thank you for the project before making an inquiry about a new feature or filing a bug is usually appreciated.
  • When opening an issue, create a small, isolated, simple, reproduction of the issue using an online code editor (like codepen or codesandbox) if possible and a GitHub repository if not. The process may help you discover the underlying issue (or realize that it’s not an issue with the project). It will also make it easier for maintainers to help you resolve the problem.
  • When opening an issue, please suggest a solution to the problem. Take a few minutes to do a little digging. This blog post has a few suggestions for how to dive into the source code a little. If you’re not sure, explain you’re unsure what to do.
  • When opening an issue, if you’re unable to resolve it yourself, please explain that. The expectation is that you resolve the issues you bring up. If someone else does it, that’s a gift they’re giving to you (so you should express the appropriate gratitude in that case).
  • Don’t file issues that say things like “is this even maintained anymore?” A comment like this is insulting to the time they have put in, it reads as though the project is not valid anymore just because they needed a break, or were working on something else, or their dad died or they had a kid or any other myriad human reasons for not being at the beck and call of code. It’s totally ok to ask if there’s a roadmap for the future, or to decide based on past commits that it’s not maintained enough for your liking. It’s not ok to be passive aggressive to someone who created something for you for free.
  • If someone respectfully declines a PR because, though valid code, it’s not the direction they’d like to take the project, don’t keep commenting on the pull request. At that point, it might be a better idea to fork the project if you feel strongly the need for a feature.
  • When you want to submit a really large pull request to a project you’re not a core contributor on, it’s a good idea to ask via an issue if the direction you’d like to go makes sense. This also means you’re more likely to get the pull request merged because you have given them a heads up and communicated the plan. Better yet, break it into smaller pull requests so that it’s not too much to grok at one time.
  • Avoid entitlement. The maintainers of the project don’t owe you anything. When you start using the project, it becomes your responsibility to help maintain it. If you don’t like the way the project is being maintained, be respectful when you provide suggestions and offer help to improve the situation. You can always fork the project to work on on your own if you feel very strongly it’s not the direction you would personally take it.
  • Before doing anything on a project, familiarize yourself with the contributor guidelines often found in a CONTRIBUTING.md file at the root of the repository. If one does not exist, file an issue to ask if you could help create one.

Final Thoughts

The overriding theme of these tips is to be polite, respectful, and kind. The value of open source to our industry is immeasurable. We can make it a better place for everyone by following some simple rules of etiquette. Remember that often maintainers of projects are working on it in their spare time. Also don’t forget that users of projects are sometimes new to the ever-growing software world. We should keep this in mind when communicating and working together. By so doing, we can make the open source community a better place.


An Open Source Etiquette Guidebook is a post from CSS-Tricks

The User Experience of Design Systems

Rune Madsen jotted down his notes from a talk he gave at UX Camp Copenhagen back in May all about design systems and also, well, the potential problems that can arise when building a single unifying system:

When you start a redesign process for a company, it’s very easy to briefly look at all their products (apps, websites, newsletters, etc) and first of all make fun of how bad it all looks, and then design this one single design system for everything. However, once you start diving into why those decisions were made, they often reveal local knowledge that your design system doesn’t solve. I see this so often where a new design system completely ignores for example the difference between platforms because they standardized their components to make mobile and web look the same. Mobile design is just a different thing: Buttons need to be larger, elements should float to the bottom of the screen so they are easier to reach, etc.

This is born from one of Rune’s primary critiques on design systems: that they often benefit the designer over the user. Even if a company’s products aren’t the prettiest of all things, they were created in a way that solved for a need at the time and perhaps we can learn from that rather than assume that standardization is the only way to solve user needs. There’s a difference between standardization and consistency and erring too heavily on the side of standards could have a water-down effect on UX that tosses the baby out with the bath water.

A very good read (and presentation) indeed!

Direct Link to Article — Permalink


The User Experience of Design Systems is a post from CSS-Tricks