Forem: Paweł Ludwiczak

No way!

Paweł Ludwiczak — Wed, 13 Nov 2024 15:52:53 +0000

Accessible Toggle

Paweł Ludwiczak — Fri, 08 Apr 2022 15:25:41 +0000

Intro

Toggle is a TRUE/FALSE switch that looks like a... switch... Similar control you can find in your smartphone settings probably.

Under the hood, since it's a TRUE/FALSE type of a control, it's basically just a more fancy styled input[type="checkbox"].

And here's why it's tricky to make it accessible.

Usual way

Usually, to build such a toggle with HTML & CSS you need a visually hidden checkbox within a fancy styled label element. And that's what most of the tutorials will tell you.

label element makes sure that the entire toggle is "interactive" (i.e. clickable).

You can't just hide the checkbox with display: none because it would make it invisible to assistive technologies. So here's the trick to make it invisible to screens yet accessible:

label.toggle {
    position: relative;
    ...

    [type="checkbox"] {
        position: absolute;
        left: -10000px;
        top: auto;
        width: 1px;
        height: 1px;
        overflow: hidden;
    }

    ...
}

The Problem and The Solution

And here's a caveat: our toggle (which is a checkbox) is wrapped with label therefore it's required (by the a11y police 👮) to provide an actual text description. But we don't want our component to dictate how that text description should look like... Because it might be used in several different ways:

sometimes text might be in front of a toggle, sometimes after it, and sometimes above it,
sometimes text might be longer and styled and sometimes not.

Hence we can't use label 🤷‍♂️. But if we use regular div or span instead, then we lose the "clickability" of our toggle.

So the actual trick is to enlarge the checkbox to be as big as the toggle wrapper (that div or span) and hide it differently:

div.toggle {
    position: relative;
    ...

    [type="checkbox"] {
        width: 100%;
        height: 100%;
        opacity: 0.00001;
        ...
    }

    ...
}

First we make sure checkbox takes full width and height. Then we almost hide the checkbox with opacity: 0.00001;.

Opacity can take values between 0 (fully invisible) and 1 (fully visible). We use value very close to 0 so it's basically invisible on the screen but visible to assistive technologies.

That's it folks. Below is a full demo :)

^ try to remove that opacity property to see the actual checkbox placement.

Couple notes:

You could practically use any element to create toggle if you also sprinkle it with JS. But I wanted to avoid it.
Keep in mind, all form elements should be placed inside label, but in the World of Components, we don't really want such a low-level component to dictate how everything around it should look like. Components should be self-contained and not affect its surroundings (at least that's my philosophy).

TailwindCSS @apply - the right approach?

Paweł Ludwiczak — Wed, 10 Mar 2021 16:35:33 +0000

I've been experimenting with Tailwind quite a lot recently and there's one thing that I can't figure out... Which of these is better:

.element {
  @apply bg-red ... hover:bg-green ... focus:bg-yellow ...;
}

or...

.element {
  @apply bg-red ...;

  &:hover {
     @apply bg-green ...;
  }

  &:focus {
    @apply bg-yellow ...;
  }
}

The latter example is probably more readable but on the other hand it doesn't utilize Tailwind's variants. So I'm wondering if there's any difference between one and the other? Maybe performance?

Here's my website setup...

Paweł Ludwiczak — Tue, 02 Mar 2021 11:00:18 +0000

My wife came up with a business idea and she needed a simple website. So I decided to build one. And this post is basically me documenting some of the tools I've used.

Context

It's a simple page with one short form to gather emails and some extra data. It's likely going to have two more subpages, including one with extra form. Mostly static content. Easy-peasy.

I'm fully aware this may not work for everyone and this may not be enough (or too much!) for other scenarios. But this was my playground and my toys and I just wanted to share with you all my experience and rationale behind my choices.

Tools

I could build everything with pure HTML and CSS and then upload it through FTP on my own server. But I thought it's gonna be fun taking alternative path.

Frontend

Instead of creating one index.html file in Notepad.exe I decided to go with Gatsby - which is basically a framework for creating websites 🤷‍♂️.

It's based on React and its API/documentation seems pretty straightforward and understandable. Plus I wanted to play with React a bit more.

CSS

I used to use Sass or Less in my previous projects but this time I wanted to try something new so I went with PostCSS which basically adds a bit of magic to normal CSS.

Plugins I've added on top of PostCSS:

Autoprefixer - so I don't have to add -moz or -webkit vendor prefixes to some CSS properties.
PostCSS Nested - so I can use Sass-like nesting.
postcss-preset-env - it lets you use some cutting-edge CSS but understandable by modern browsers.

CSS Modules

Since my project is based on Gatsby and React, I basically created components for everything: header, footer, forms, buttons and specific content sections. And because of componentized nature of my codebase, I decided to utilize CSS Modules concept so I don't have to be worried about using too generic names for my CSS selectors and everything can be scoped locally.

"Server"

GitHub

I store everything as a GitHub repo. You may wonder if it makes any sense to do so if it's a tiny project that I don't collaborate on with anyone else... And my answer is: YES! I make small commits and this alone saved my butt once or twice already - for example when I had to restore some previous version of a component. And you're right - I don't utilize 95% of what GitHub (or Git alone) provides, but the rest 5% is still worth it.

Netlify

And everything is online thanks to Netlify! I love how smooth this whole process is:

Make a change.
Commit and git push to my repo.
Boom, after a minute or two it's online.

^ My Netlify account is connected with my GitHub repo so it all happens automatically.

Forms!

But there's more! As I mentioned earlier - that landing page has one "interactive" element - a form to collect emails and some additional data. Apparently Netlify can handle form submissions and store all the collected data for you. The best part: all you have to do is basically add netlify attribute to the form and it will do all the hard work for you... 🤯

I could have done some things differently but I wanted to play with these particular tools as I personally consider them being the future of "simple" site building.

Any reason for not using loading="lazy" attribute?

Paweł Ludwiczak — Mon, 26 Oct 2020 14:08:28 +0000

One of our community members suggested using loading="lazy" for all images on DEV. Pros are pretty clear to me. But are there any cons of this? Any kind of gotchas or edge cases we should watch out for?

If not, why isn't that the default for loading images in browser?

10x CSS

Paweł Ludwiczak — Mon, 03 Aug 2020 19:41:55 +0000

This post is just a collection of some CSS tricks and magic I've learned about over the last couple months.

`background-repeat: space|round`

When you have tiles-type background and you don't a tile to be cut-off.

Source: CSS-Tricks.

`scroll-margin-top`

Having sticky header (or nav) is pretty common UI pattern. But it's a bit tricky when your app also has anchor links (https://....#section) that users use to navigate between page sections. Header will likely overlay part of the section that user navigated to. scroll-margin-top will help with this.

Source: Bram.us

`resize: both`

It's not really surprising you can use resize: ... to define how users can resize the textarea (it's the little handle in the bottom right corner). But what I think is pretty cool about it is you can use it elsewhere - for example on iframe - which I personally found very useful when testing responsiveness on certain elements.

Source: Bram.us

`place-items`

Nifty shorthand for two properties.

place-items: center;
/* ...instead of: */
align-items: center;
justify-items: center;

Source: MDN

`inset`

Another shorthand:

inset: 10px 20px 30px 40px;
/* ...instead of: */
top: 10px;
right: 20px;
bottom: 30px;
left: 40px;

It has similar syntax to margin or padding, so you can also use it like this:

inset: 10px 20px;
/* ...instead of: */
top: 10px;
right: 20px;
bottom: 10px;
left: 20px;

Source: MDN

`user-select: all`

Not crazy useful but it's a nice proof of concept. You can use a user-select: all trick to select, for example, a code snippet on click.

Source: Coder's Block (there's actually much more info about this property in general)

`-webkit-fill-available`

If you have ever tried to use vh units you probably know how "tricky" things get on mobile, especially webkit-based browsers. Below is a really nice trick to make things more predictable.

// Detect dark theme var iframe = document.getElementById('tweet-1254151507412496384-260'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1254151507412496384&theme=dark" }

`counter-*`

I have no idea if this could be any useful but I thought it's interesting 😂.

// Detect dark theme var iframe = document.getElementById('tweet-1258283004465680384-134'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1258283004465680384&theme=dark" }

`gap`

One of the best things about CSS grid is grid-gap. It's something I've been missing on flexbox but looks like it's coming: gap will be universal property that can work on both - grid AND flexbox. Browser support is pretty poor as of today but... Hey! It's coming!

Source: MDN
Browser support: Can I use...

new header, who dis

Paweł Ludwiczak — Thu, 26 Mar 2020 16:55:28 +0000

TL;DR You may have started noticing more updates in the UI recently. And we have just updated the header!
We've been working pretty hard on building new awesome features and improvements. Some of them are meant to be invisible yet super helpful: feed improvements or upgrading some of our infra. But we've also made some changes that affected visuals.

Frontend Codebase

Like in many projects, the front-end part of a codebase is... well... not ideal. We have tons of CSS files, lots of spaghetti code, duplicated styles, and much, much, more...

It's a classic scenario: the feature or view needs to be built. The Dev or Designer decides to write super short and simple front-end code to ship a feature fast. And 2000 lines of code later you just can't go back :)

Taking a more holistic approach is actually what we've been trying to do. We've started building our own Design System. It includes not only design guidelines, but also front-end documentation of how to use the styles and components.

Overall, this is our approach (I will write more about our Design System in the future):

We now have real components and views built in SCSS (well, just a few of them, but that's a good start!).
We also have utility-first classes (TailwindCSS - does that ring a bell?) ready to be used anywhere in the markup.
At the same time 95% of our code is legacy code, not following any rules or guidelines. We will be slowly updating that alongside releasing new style.

Which is a good segue to...

New header

One of the very first elements that we've decided to update is our header. You may notice it looks slightly different than couple days ago (if not, hit the hard refresh... If still nothing, I could have broken something and we had to roll it back :D). It's just a refresh, not complete redesign or anything. But we hope you'll like it! There's much more coming and this header update is just a teaser.

Where are we going?

Paweł Ludwiczak — Wed, 26 Feb 2020 10:20:23 +0000

For the last couple weeks we've been working pretty hard to improve the UI & UX on DEV. Our efforts so far were focused around the home page, but mostly under the hood. There's a lot of spaghetti in the frontend codebase and there were temporary solutions that were never replaced with more sustainable ones. Hence, the work that we’re doing right now is not really visible.

But some of it is.

Shipping Home Page Cleanups

Paweł Ludwiczak for The DEV Team ・ Feb 19 '20

#design #meta #ux #changelog

First of all, thank you for feedback! We really appreciate it and you helped us spot and fix many bugs. 🙌

I mentioned a couple times that what we’ve shipped so far is just a step towards something bigger. It's still far from being ideal but we’ve had to make some changes here and there to make it easier in future to implement new things. This is an ongoing process and will take time.

Today I'd love to show you a sneak peek of where we want to be in some time. Again: it's not ideal, it's not finished and it keeps evolving (like literally every day :)). But I still think it's worth sharing with a broader audience!

From yours, the community perspective, it should be more readable, easier to navigate and more fun to use. From our perspective this will be a step towards not only a more maintainable design system but also a North Star for UI improvements in other areas and views.

Shipping Home Page Cleanups

Paweł Ludwiczak — Wed, 19 Feb 2020 16:53:40 +0000

TL;DR

Today we're shipping some small UI changes for the home page. Let us know if you can spot any bugs or issues since changes might have affected other views too.

A couple weeks ago the DEV team started looking into possible improvements for the DEV home page. We asked you for feedback and opinions and OMG my product designer soul was like 🤩🤩🤩🤩🤩🤩🤩

TL;DR of what happened

We had this idea to do a home page makeover. You gave us tons of input around what we should be focused on, tons of ideas for features and improvements, and tons of great feedback. Here's a bit more detailed recap:

Follow-up: your feedback on the home page 👋🏼

Lisa Sy (she/her) for The DEV Team ・ Feb 10 '20

#design #ux #meta

For the Home Page itself, we decided to split our efforts into three separate "projects": 1) Low Hanging Fruits, 2) Feed Improvements, and 3) North Star Vision.

Shipping Low Hanging Fruit 🚢

Today we're super pumped about shipping just a tiny bit of what we have planned. We made some small UI optimizations that are mostly visible on the home page but also on other views. Some of the improvements include:

De-emphasizing sidebars – there will be fewer "boxes" in the sidebars so that you can better focus on the feed itself. It helps us build some layout hierarchy.
Spacing – it should be less random now.
Typography – font sizes, line height, and colors should also be less random :D

...I guess we could call it "DE-RANDOMIZING DESIGN". That would be a catchy title for a ~~medium~~ DEV post, huh?

It's technically not much but visually, it may feel different. Give it a couple days to get used to it. And remember it's just a first step.

What you may notice 👀

This update is more minimalistic, and may even look less DEV-ish. Some of you pointed out that that DEV’s eclectic, glitchy & imperfect style is 100% on-brand, so why does it look like we’re scrapping all of that? Don’t worry, we see this. Although we love this “style”, a lot of it is caused by lack of rules and guidelines especially in design. We’re cleaning it up now so that we can re-incorporate more of the DEV brand of “organized disorder” over time. Plus, this will let us build great features and improvements efficiently in the future. Trust us when we’re saying that your initial impression will just be a temporary feeling.

What's next?

Of course, we still want your feedback. If you see any issues or bugs, please let us know either here or in GitHub.

We're also looking at some metrics to see if we didn't screw up anything. If we notice that "omg signups went down by 50000%" then we do git revert or whatever you do in that case (hey, I'm not a developer!). Also, I could be fired then 🤷‍♂️.

It's not over.

This is just a very first step towards where we want to be. The whole team is working pretty hard at defining that North Star vision, not only in terms of features, but also in UI.

Cheers!

(Cover photo by JESHOOTS.COM)

Icon for bookmark, save...

Paweł Ludwiczak — Sat, 08 Feb 2020 14:20:50 +0000

Many sites have functionality for saving links or articles. You can bookmark tweets, save instagram photos, and of course save articles on DEV to read them later.

Couple days ago we've been debating internally about symbol for "SAVE" action on DEV, wondering how many people nowadays actually know what the icon above means. Do you know what it is? Is it too meta or is it actually perfectly on brand? And the most importantly: do you feel old now 👴😆?

Hello again. It's time to do some work!

Paweł Ludwiczak — Tue, 04 Feb 2020 19:53:06 +0000

tl;dr

DEV is redesigning the home page. But we need your help and feedback. Also, hi!

Hello, again.

This is Paweł, I'm a part of the Product Design team, here at DEV. Lisa and I joined DEV recently.

DEV + Product Design 👋🏼

Lisa Sy (she/her) ・ Dec 9 '19

#meta #design #ux

Hello World!

Paweł Ludwiczak ・ Jan 14 '20

#meta

So, what does the Design team at DEV actually do? Great question! To keep it short: we're trying to make DEV more usable, better-looking, and welcoming. We're also going to work on our design system — a bunch of tools and guidelines to make designing and building features much easier; it should also help us make things more consistent because… well:

The Home Page

One of our very first projects will be improving DEV's home page. There are several things we'd love to do here — some of them will be subtle changes and others more drastic and groundbreaking (ok, I'm exaggerating a bit).

Goals

We have one main problem to solve with the home page makeover: people struggle to find relevant content. They don't know where to look because the current home page is a bit overwhelming.

We need you!

Now, the most important part.

We don't want to sit in a closed room, moving pixels around and suddenly deploy changes that you may totally hate. We want to stay in touch with you through the entire process. We want to inform you of our ideas and progress. But most importantly, we want you, the DEV Community, to help us by providing feedback, words of wisdom, opinions, and your ideas... DEV is open source and we want to be as transparent as possible. That being said, can you let us know:

What are some things about the home page that you dislike the most?
What are some things about the home page that you like a lot?
What did you wish the home page did more of?

Thank you so much for your help. We’re going to take your feedback and make DEV a better place for us all! ❤️ Expect another follow-up post soon with more details about Home Page work.

What to use to measure frontend metrics?

Paweł Ludwiczak — Mon, 03 Feb 2020 10:54:49 +0000

(Photo by Mitchel Boot)

I'm curious what are your, DEV Community, choices for frontend analytics tools. And what I mean by that?

Let's say I want to check click-rate on links in DEV sidebar (left) nav to see which are used the least (so maybe we can hide some?).
Let's say I want to measure how often people click links in right sidebar widgets and break it down per each widget (listings, #help, #ama, #challenge, ...). Are some widgets used less than the others?
Let's say I want to compare if people prefer to click "Write a post" CTA in header OR the one in profile pic dropdown.
Let's say I want to compare if people prefer to go to own profile by clicking the widget in left sidebar OR the one in profile pic dropdown.
Let's say I want to see how the onboarding performs - what people click on each step, when do they drop-off, how many people skip some fields etc.

Why? Good design decisions are driven by data. Data also helps validate ideas and its success.

PS. Bonus points if it's open source :).