Tag: tools

Make Your Own Tools

Spencer Miskoviak on the Wealthfront blog:

By creating custom DevTools specific to an app, they can operate at an even higher abstraction to handle things like user interactions, or debugging tracking events. While this requires building and maintaining the custom DevTools, it also means it can be tailored to the needs of the app and engineers to streamline development.

I think it’s super cool and smart to build custom tools for your team of developers. Even if custom tools are just for yourself they can be a productivity boon. But by building custom tools for your whole team, and opening the door to their ideas, that’s extra smart and compounds the value.

Spender showcased a variety of different tools they have, all under the umbrellas of a UI popup widget thingy:

  • Shows current branch and CI status
  • Fills out forms, performs user actions, switches between users
  • Highlights components

Clever stuff.

We don’t have a fancy UI widget like that at CodePen, but do have some productivity-helping fuctionality sprinkled into the app. For example, many forms have a prefill button that only shows up for devs:

And we have a custom tool for our support inbox that gives context to the users and content that the support ticket references:

Not to mention a whole protected admin area on the site itself to perform a whole slew of admin and developer focused tasks:

I think the “component highlighter” that Spencer talked about is particularly neat:

React DevTools can be helpful in seeing what parts of the current page are which components, but that’s not on-page like this. I think it would be rad to have a little 🔗 next to each title that would open that file in VS Code.

Speaking of building your own tools, Shawn Wang wrote “You’re Allowed To Make Your Own Tools” recently:

Even the greatest software has parts that aren’t so great for you. But the difference between you and everyone else is that you can code.

Shawn talks about things like…

  • Building your own custom stylesheets
  • Building a UI query generator
  • Building your own CLIs (I’m reminded of Mina Markham’s dotfiles)
  • Building your own proxies

Shawn wrote his own dang proxy for Google Search Results to optimize them and present them how he likes:

Once in a while, I’m in the mood to focus on tooling, which leads me to do stuff like when I decided to “Run Gulp as You Open a VS Code Project using VS Code Tasks” which I had to learn all about and struggle through weird problems. I’d think a great DevOps person at a company would be all over stuff like this—constantly thinking of developer experience for their own people.

I even scripted the opening of a text-based multi-player video game I play not long ago to save myself some time.

And speaking of building your own tools generally, I think of Dick Proenneke’s in Alone in the Wilderness documentary. In this intro clip, you can hear Dick talk about quite literally building tools, which was useful for him as he didn’t back to hand-carry them deep into the Alaskan wilderness.


The post Make Your Own Tools appeared first on CSS-Tricks.

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


Tools for Optimizing SVG

Command Line Tools

The biggest (and maybe only?) player in this space: SVGO. It’s even used under the hood of other tools.

Using with a Task Runner

Desktop Apps

There are generic app for optimizing images on Windows and Linux, but I haven’t yet confirmed any of them do SVG.

Web Apps

The idea with these tools is that you have an SVG on your machine and you upload it to this web app to optimize this one SVG.


Optimizing Directly Out of Design Tools

Typically, when you export SVG out of a design tool it is in dire need of optimization. Hence, all the tools in this article. The design tool itself can help though, at least somewhat.

The post Tools for Optimizing SVG appeared first on CSS-Tricks.



Smarter Design Systems Tools

What has me really excited about building websites is largely around design systems and the design tools we use to build them. Though, design systems are certainly not limited to websites.

Closing the Gap

In the ever-so-hot-right-now world of design systems, one of the most common phrases people use is “bridging the gap” (between designers and engineers). This was on several résumés I reviewed during my time at Salesforce when we were hiring for the Lightning Design System team. It’s a fair endeavor to strive for, as we want to bring alignment, coherence, and unity to our product design and engineering — all with the goal of having a quality-consistent experience for the people using our products and services.

However, “bridging the gap” still implies there is a gap. Why is that gap there in the first place? Is it due to many years of legacy process and workflows that still seep into our day to day work? I could see legacy being a real-world scenario need to work through. But what about newer, smaller startups? Why do many of them have a gap, too?

As a design systems practitioner, advocate, and enthusiast, I am always seeking ways to improve the people side of our work: how we meet and communicate, how we prioritize our roadmap, and how we can iterate on our process and way of working. However, another piece of this are the tools we use.

Some of our tools have come quite a long way, and it certainly seems that a new one is announced pretty frequently these days. But the ones that really get me excited are where I see them do more than “bridge the gap”.

A while back, when Modulz arrived at the scene, I noticed they used the hashtag, #closethegap. I couldn’t help but love that.

I’m very keen to see our design tools move away from simply bridging gaps and more toward closing them. For example, a feature I see as only bridging the gap is a “developer handoff” (which tends to rely on pixel dimensions and hex codes delivered as a spec). In my experience, delivering specs like this can promote duplication in code, inconsistencies, and are prone to errors. An example of closing the gap, however, are tools that work with actual, real, quality code instead of vector boxes.

Some tools achieve this by exposing design tokens — you can see that in InVision DSM which has tokens built-in as a feature. Another tool, Diez, is an open-source developer toolkit using tokens to turn your design language into scalable code. There are other tools like the previously mentioned Modulz, along with Interplay, that work with coded components but in a visual way. This is much better than the earlier WYSIWYG editors of the past because their generated code can be accessible and production-quality. And that’s not to leave out the other players in this space like Adobe, Figma, Framer, Sketch, UXPin, and many, many more that are also doing a lot to move this forward.

The Invisible Design System

Something I’ve been thinking a lot about is how much time we spend on making beautiful design system websites. I love looking at them. They’re great. But as our design and engineering tools get closer and closer together, will we come to a point where we don’t need the website? Can our tools surface suggestions for better accessibility, localization, performance, and usability, because our design system is baked into the tools? Just a thought.

The No-Code Movement

Webflow, which empowers people to build websites (complete with business and e-commerce features) without writing code, recently had a conference called No Code Conf. According to their website, the conference celebrates the future of visual development.

This is a movement that, while not new, is growing rapidly. In addition to building a full-featured website using Webflow, visual, declarative app-building has been explored for years at larger tech giants like Salesforce (with their Lightning App Builder) to smaller companies like Glide which let you generate an entire app from a spreadsheet. And with all of the task-based automation services such as Zapier and IFTTT, there is much you can do without writing code at all.

Now don’t get me wrong. I still love writing code, and I love seeing other designers code. I enjoy working closely with engineers as well. I’m not saying we shouldn’t code at all. But I’m excited to see us move away from a slower “throw designs over a wall” process. I want to see people able to make things without the requirement to write code. It will also be nice to move away from the tired argument on whether designers should code — and we all move toward what can we make together?

And if we can get to a point where we don’t need to bridge or close any gaps because the gap never existed at all — well that’s a pretty exciting world I want to be in.

The post Smarter Design Systems Tools appeared first on CSS-Tricks.


, , ,

The Tools are Here

Heading into 2020, it occurs to me that I’ve now been making websites for 20 years. Looking back on that time, it seems as though our practices have been in near-constant churn, and that our progress did not always seem linear. But ultimately, even the missteps and tangents along the way have contributed to a pattern of refinement, and now for the first time, it feels like we’ll have a standard pattern for most of the technical challenges we face. I think 2020 looks to be a stabilizing moment for web standards.

Given that delivery is inherent to our medium, many of our challenges have come from network constraints. Early on, networks offered limited bandwidth, so we developed tools and practices to reduce the physical size of our files. Soon enough, bandwidth er… widened, and latency–the time spent making trips between servers and devices–became our next bottleneck. To mitigate latency, we developed techniques to deliver more code in fewer trips, like combining like-files, splitting our resources across many domains to allow more downloads at a given time, and inlining unlike-files into our HTML to avoid waiting for additional requests. We also learned to distribute our code around the world on CDNs, as physical proximity always helps. But latency itself is improving now, especially with the arrival of 5G, and advancements in how browsers communicate with servers now allow us to request any number of files at a time, or even push files to the browser before it asks for them. All of this has simplified our ability to deliver quickly and reliably, and it’s only just recently become available without complicated workarounds.

Device differences used to confound us as well. In the early years of the mobile web, we had to find creative and often clumsy workarounds to deliver contextually appropriate features and assets, but nowadays we have fantastic tools to deliver device-appropriate experiences. We can use media queries to fluidly adapt our visual layouts across screen sizes, and we can build those layouts using proper design tools like grid and flexbox. We can use standard feature queries to test if we can rely on a particular tool before using it, or even to decide whether to load costly files in the first place. For media delivery, we now have powerful options for delivering appropriately sized images and videos to any device. All of this required less-ideal or non-standard practices only a few years ago, but things have changed for the better.

Accessibility has become simpler to achieve too, which is timely since awareness of its importance has likely never been greater. Standards have given us tools to better communicate the meaning and state of our components to assistive technology, and browsers and OSs have dramatically improved their interaction with those standards.

I don’t mean to suggest that we don’t still face hard technical problems, but I think it is increasingly our own practices and assumptions that create those problems, rather than any forces beyond our control. For example, we still see a few sites that smoothly reconcile fast delivery with smooth responsiveness during runtime, particularly in the average devices that people are using worldwide. But problems like that aren’t absolute–they’re caused by faults in our own priorities, or in over-relying on patterns we already know to be costly.

In short, the tools we need to do our jobs well are here. Except for container queries. We still really need container queries to do our jobs well, and it’s frankly ridiculous that in 2020 we—ahem. Where was I? Oh, right.

So heading into 2020, it feels like we finally have a well-rounded standard toolset for building and analyzing our sites. Nowadays, if a site is slow or expensive to deliver, or slow to respond to user interaction, or inaccessible to assistive technology, or poorly designed on a particular screen, we can take comfort in knowing that it’s probably our own fault and that we can fix it. And that’s great because the web has much bigger, more pressing, non-technical problems that need our attention much more.

The post The Tools are Here appeared first on CSS-Tricks.



The Amazingly Useful Tools from Yoksel

I find myself web searching for some tool by Yoksel at least every month. I figured I’d list out some of my favorites here in case you aren’t aware of them.

The post The Amazingly Useful Tools from Yoksel appeared first on CSS-Tricks.


, , , ,

JAMstack Tools and The Spectrum of Classification

With the wonderful world of JAMstack getting big, all the categories of services and tools that help it along are as important as ever. There are static site generators, headless CMSs, and static file hosts.

I think those classifications are handy, and help conversations along. But there is a point where nuance is necessary and these classification buckets get a little leaky.

Note, these charts are just intended to paint a spectrum, not to be a comprehensive list of services.

Headless CMSs

A Headless CMS is a CMS that provides an admin area for creating and editing content, but offers no front-end to build the website from. All the content is accessed via APIs.

Imagine WordPress, which has an admin area, but it also has themes from which you build the website from on the server-side, with all kinds of PHP functions for you to use the content data. All that theming stuff is the “head”. So a headless CMS would be like WordPress with just the admin area. And indeed you can use it that way, as it offers APIs.

There is even more nuance here, as there are services that offer an admin area, but don’t actually store the data for you. Plus there is CMSs that are hosted for you, and CMSs where you have to bring your own hosting. Let’s have a peak.

Service Headless? Hosting Notes
Contentful Yes Cloud A classic headless CMS
Sanity JSON data structure, accessed via APIs, custom admin area is self-hosted
Cockpit Self Comes with admin UI
KeystoneJS All code, not even an admin UI
WordPress Sorta – Usually used with head Self or Cloud Has a head, but you don’t have to use it, you choose to only use APIs to access content if you wish.
Drupal Self
CraftCMS Self Specifically has a headless mode and GraphQL API. Craft Cloud will bring a cloud-hosted headless varient
NetlifyCMS Sorta – Doesn’t actually store content, just helps edit it. GUI for Git-hosted Markdown
Forestry Cloud
Joomla No Self A classic headed CMS
Squarespace Cloud Site builder, meant to build hosted/headed sites

Static Site Hosts

This is tricky to talk about because literally, any web host will host static files, and probably do an OK job of it. I think it’s most useful to consider hosts that only do static hosting on purpose because it means they can optimize for that situation do other useful things.

Service Notes
Netlify The gold standard in static file hosts right now. Developer conviences galore.
Cloudflare Workers Sites CDN-first static file hosting alongside a cloud functions service.
Firebase Hosting Firebase is a whole suite of sub-products, but the hosting in particular is static and on a CDN.
GitHub Pages Static file host, but will also run Jekyll and other actions. Is not a CDN.
Neocities Static file host with online editor and community.
S3 Raw file storage. Can be configured to be a web host. Not a CDN unless you put CloudFront in front of it.
Bluehost Not really a static file host.

Sometimes you’ll see people trying to use stuff like Dropbox or Google Drive to do static file hosting (for a website), but I’ve found these services generally ultimately don’t like that and prevent the use for that. If it works today, fine, but I wouldn’t count on any of them long term.

Static Site Generators

You would think this category would be straightforward, without much spectrum. A static site generator takes input and makes statically generated pages that can render without, say, needing to hit a database. But even here there is a spectrum.

The language the generator is in kinda matters. It affects speed. It affects installability on different local platforms. It affects your ability to write code to extend it and hack on it.

But perhaps more importantly, not all static site generators are only static site generators. Some can be run on the server as well, weirdly enough. And there are some that kinda look like static site generators, but are more correctly classified as flat-file CMSs.

Software Lang Notes
Jekyll Ruby One of the originals in this generation of static site generator.
Hugo Go Fast and beloved.
11ty Node Processes 11 different template languages out of the box.
Gatsby React Gatsby is truly a static site generator, but generally, the sites “hydrate” into SPAs, but remains static (nothing server-rendered).
Next Next can do static site generation, but it can also run live in Node and do server-side rendering on the fly (“Isomorphic JavaScript”).
Nuxt Vue Nuxt is the spirtiual companion to Next but in Vue. It also can either be staticly generator or run isomorphicly.
Kirby PHP Kirby runs from static files (no database), but isn’t really a static site as the pages are rendered by PHP.
Statamic Statamic is similar to Kirby in that static files are used for data but the page themselves are rendered by PHP.
Perch Just an example of a CMS that keeps data in a database and isn’t trying to be a static site generator at all.

The post JAMstack Tools and The Spectrum of Classification appeared first on CSS-Tricks.


, , ,

Color contrast accessibility tools

Accessibility is all the rage these days, specifically when it comes to color contrast. I’ve stumbled upon a couple of tools this week that I think are pretty nifty for helping make sure that all of the text on our websites is legible regardless of what background color they might have.

First up is the Accessible Color Generator which happens to be a wonderful tool for picking alternative colors. Let’s say you’re working on a brand with color X. You can generate a host of other complimentary colors like this:

Next up is Contrast, a rather great MacOS app that sits in the menu bar at all times and helps identify accessible color pairings based on WCAG Guidelines. This one is particularly useful if you happen to be a designer:

This reminds me of a wonderful post about how the Lyft design team re-approached the way they use color in their app. Kevyn Arnott explains:

Color, at least on the surface, appears almost naively simple, yet as it scales across larger products it becomes unbelievably complex. You have thousands of people building products all at once, and those products are all heavily reliant on color. This puts a lot of pressure on the color system to ensure that all the products are being created consistently, but very hard to implement since it’s all too easy to apply colors on a one-off basis.

The team then went ahead and built ColorBox.io which lets you systematically build out a ton of colors for your design systems work. It’s pretty nifty!

Plus the folks over at GOV.UK made their own color accessibility tool called Contrast Checker which (as you have guessed by the name) helps check the contrast between the background of an element and the page itself:

And, of course, there’s the trusty WebAIM contrast checker, which is a go-to for many developers out there.

So far, we’ve looked at tools that check contrast. But there is a class of tooling that can automate accessible contrasts during development. Josh Bader wrote up an approach that enforces high contrast by pairing CSS custom properties with the calc() function. Facundo Corradini did something similar that switches font color based on the background color behind it.

Oh! And we may have something to look forward to with the color-adjust property. It is proposed in the CSS Color Module Level 4 specification and could give browsers more control to adjust color values that are declared in the stylesheet. It’s not really geared towards color contrast, but there’s something interesting about handing off the responsibility of rendering color values to the browser based on certain conditions.

The post Color contrast accessibility tools appeared first on CSS-Tricks.


, , ,