DEV Community: Bence Szabo

25+ short videos on creating generative art with SVG

Bence Szabo — Sun, 25 Jun 2023 10:55:52 +0000

For the past two and half years I've been creating patterns and textures on CodePen purely with SVG to explore the capabilities of SVG Filters. I've made almost a hundred of these, so I figured why not start explaining the concepts behind each of them?

Since these patterns are made with very little code (560 bytes or less), I stick to the short format in videos as well (<1 minute).

You can check them out as YouTube Shorts,

Or you can view them as TikToks if you'd like.

Here's one of the latest:

Here are all the pens if you want to check them out: PetitePatterns (Pure SVG)

Asking is thriving

Bence Szabo — Thu, 17 Dec 2020 22:33:45 +0000

[🎧 Listen to the audio version of this post on Vurbl 🎧](https://vurbl.com/listen/1URDvHMzc08/)

I started my career as a Java Software Engineer without any prior Java knowledge. I didn't study Computer Science at the university and I didn't do any software internship. All I knew was how to create static web pages with HTML and CSS.

I became the first Java Engineer in the team and my role was to take over the development of the internal tool we inherited from another team. I had to get up to speed really fast in order to survive.

The thing I couldn't get away without was asking questions. A lot. There was so much to learn about the tool, domain and Java that I never ran out of questions. I was determined, relentless, out of my comfort zone and I'm pretty sure I was annoying. In the back of my mind there was this thought that I'm asking too many times and they would start hating me, but the drive to fit in the role was stronger.

Though the members who built the tool always answered. However frequently I went they always gave me guidance. I guess I was lucky for having such helpful and resilient mentors, because there was a wide gap to bridge with me. In the end I came through and I have been in software for the last decade, probably thanks to all those questions.

Asking questions is a pretty important thing to do in software teams (most likely in any kinds of teams). So if you are ever pondering whether you should ask a question or not, rather ask away! Okay, maybe it's not always that simple because many factors come to play. But worry not, I put together a list of tips that could help you manage these factors and make you an effective asker!

Tips for asking effectively

🔍 Come prepared
⌚️ Find the right place and right time
😊 Be polite
👌 Express yourself concisely
📝 Take notes of the answer if necessary
👋 Return the favor when asked

Preparing yourself

First, try to get prepared as much as you can around the topic you are about to ask. There's a chance that you might bump into the answer. However, if you don't then you still took some time to dive deeper in the area. Presenting that you already have a level of understanding helps a lot in communication.

For example let's pretend you are given a task that revolves around hypergraphs and you know nothing about them. (Let's also pretend that most knowledge of hypergraphs has been wiped off the internet.) There's an expert in the company, but before you ask you could study around the matter. In this case the best start is to learn or revisit what graphs are. For instance understand that they are made of vertices and edges, there are undirected and directed graphs, and there are unweighted and weighted graphs.

The point is to gain a good base knowledge of the topic you are requesting some help about. This will save you and the person you are meaning to ask some time and reduce the friction of the interaction. Here's a visualization of a hypergraph if you were wondering how they look:

Time and place

A question might arise in you at any time, but you won't always say it out loud right away. We have been taught in ways when to speak up and when to stay quiet. So it's important to be aware of what situation you are in. There are several anchors to this. I'm dividing them into two groups in the following sections: the rather objective ones and the more subjective ones.

It's a good idea to gauge who might be interested in the answer for your question so you ask it in front of the right audience. If you are asking questions of taxation on a global all hands of a multinational company, you are probably wasting everyone's time who doesn't tax in your country. Similarly, think of the time presumably necessary to answer your question. Avoid asking long, open-ended questions if you are short on time, for example during a stand-up. In a fully remote setup you have much less meta information on what your coworkers are occupied with, but you can resort to checking their calendars and chat statuses. So check these before you try to engage in a discussion with someone to diminish the "Why aren't they answering?" feeling.

Some other circumstantial things need to be "felt out". Cultural backgrounds vary a lot, for example I remember the feeling of not being too encouraged to ask questions in the classroom. Why? Because if you asked something dumb or obvious you got shamed by the class or even the teacher. We might carry these ideas throughout our lives as golden truths, so it's good to keep in mind that we are not sitting in classrooms anymore. Another, maybe even greater part of this is that each country and region has their unwritten laws of how you should behave at the workplace. It's really hard to put your finger on these things, but try to be aware of these patterns as well.

Politeness

This is a no brainer, of course being polite always helps. It's good to remind ourselves to approach our colleagues respectfully. Surely people are more likely to answer a question that's asked nicely. Furthermore, keep in mind that the person might not be available to answer your question at the moment. Understand that you may need to wait for them to come back to you, or schedule a meeting in the next few days or weeks.

Communicating concisely

I already mentioned respecting other people's time earlier. Being terse is respecting the time of the person you are asking. No one wants to answer long-winded questions or verbose emails. On top of it, no one wants to pay the mental tax of figuring out the important details of a lengthy request. Phrase your questions with just the necessary information and you will save the receiver from spending a lot of mental energy.

Take a look at the following fictional email.

Hi Alice,

I'm Bob, the latest member of the Hugs Team. I'm writing you because I would like to learn about the technology you used when implemented Haha's. We are looking to integrate Hugs beside Haha's in the next quarter, so it would be really helpful if you could answered the following questions.

Hugs would be something similar like Haha's, but they would represent a different emotion. (It's still a positive one, but could be used for expressing gratitude.)

[some in-depth questions here]
[...]
[...]

Thanks in advance and looking forward for your answer!

Best Regards,
Bob Bobson
Software Engineer
Hugs Team

Have you noticed any unnecessary parts? I'm not saying the above email is wrong, but it could be optimized. It's more polite than necessary, burdens the reader with lot of extra information, and has some redundant pieces.

Now take a look at the optimized version.

Hi Alice,

We are looking to implement a feature called Hugs that's similar to Haha's in the next quarter. We would appreciate if you could answer these questions:

[some in-depth questions here]
[...]
[...]

Many Thanks,
Bob Bobson
Software Engineer
Hugs Team

We made the email shorter yet polite and still kept some crucial contextual information. Another commonly used medium is instant messaging like Slack. Whenever you are writing someone, it's better to write your request as a whole message and not line by line like you would speak in a real life dialogue.

IRL type of messaging:

Bob 9:37 AM
Hi!
Alice 9:41AM
Hello
Bob 9:42 AM
Can I ask you some questions?
Alice 9:44 AM
Sure
Bob 9:45 AM
What library did you use to implement the frontend components of Haha's?
Alice 9:49 AM
We used... [Alice proceeds to explain the answer]

Notice how 8 minutes passed from the start until Alice received the question, and 12 minutes until Bob got an answer. Instead, Bob could have opened with something like this:

Bob 9:37 AM
Hi! Could you tell what library did you use to implement the frontend components of Haha's?
Alice 9:39 AM
We used... [Alice proceeds to explain the answer]

With this type of messaging Alice received the question straight away and Bob got an answer after 2 minutes.

Notes

Sometimes you will get some long and complicated answers, and sometimes you will get some short answers but won't use them for a long time. Either way you might forget about the answer. Taking notes will help you with that. This seems unnecessary in a mailing for example, but another benefit of taking notes is that it forces you to actually interpret the answer. Interpreting immediately will push you to find potential holes in your understanding, thus driving you to ask more questions to get closer to what you need.

All in all, try to be really attentive when you are receiving an answer so you can avoid the need of repeating your questions in the future. Moreover, from the answerer's perspective it's much better to explain something to someone who is really listening. People can easily tell that, like you can tell that the dog below is paying high attention to something.

Being the one asked

You will certainly find yourself on the other side of Q&A. In that case be mindful of the tips above. Try to stay approachable so people will remember that you are someone they can ask. Set up reminders for emails you want to answer later, set up reminders even for inquiries received via Slack. It takes some effort, but people will learn that you are reliable.

Consider helping others when they ask as part of your job because the success of your company might just depend on it. Be helpful and nourish a great culture that will lead you and your peers to great wins.

When desperate be loud

This isn't a serious advice, rather a ridiculous last resort. If none of the above worked, try following some guerrilla marketing-esque tactics: State something blatantly wrong loud enough and in time someone will come and correct you anyways. Alternative explanation by David Khourshid:

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

I hope these tips gave you a confidence boost to ask more often!

Speaking in public, occasionally

Bence Szabo — Fri, 13 Nov 2020 22:04:27 +0000

Most people in the software industry rarely have to speak in front of a public audience. Let that audience be a meetup, the company you work at or your team. However, sometimes you find yourself being assigned to do a presentation. If some sort of anxiety is starting to kick in thinking about this task, read on, this is for you.

To be honest I get anxious every time I have to do a presentation. That's because I rarely have to do one. But one time I did talk at a local meetup for the first time ever and it went pretty well. I also did a talk at a company event and folks from overseas recalled it weeks later. So you don't have to be regular presenter to do a decent enough presentation, but these tips below might be just what you need.

Tips

🗣 Rehearse your presentation
🤔 Reduce the amount of uhh's, umm's, ahh's, hmmm's
🔁 Avoid repeating filler words
🎵 Find the right amount of intonation and emphasis
🏇 Speech tempo: try going for a medium pace but err on the side of going fast
🧠 Know your audience's level of understanding of the subject matter
🎓 Bring quality presentation content
🙂 Keep a positive facial expression i.e. smile

Rehearse

This is the single most important one. If you are not used to doing presentations regularly, you should probably rehearse. Think about it, most people are not good at things that they don't do regularly. You attain most masteries in your life by practicing. Great musicians play their instruments a lot, great sportspeople train a lot, great chefs cook a lot before they get good at cooking, and the list goes on. Public speaking is no different so practicing it and rehearsal should be part of it.

What I do is I actually perform the presentation out loud. Don't just rehearse in your heard, speaking it out loud makes a whole lot of difference. One of the best things you can do is to present to someone who can listen to you and provide feedback: your spouse, friend, coworker, whoever is up to that. In case no one's there you can still speak in an empty room. You could even record yourself (audio/video), but beware that presenting and analyzing the recording takes double the time or more, does not worth it in my opinion.

Speaking out loud helps you identify the "weak" parts of your presentation, and when you're alone you can stop and think about these on the spot. It's a pretty efficient way to "debug" and improve your presentation. The goal is to get to a point where you have already fixed, polished and memorized every important block.

For me rehearsing one time is usually not enough, two times might just cut it, but really three times is the charm. More than three times is overdoing, but if the stakes are high enough it can be justified. We are talking about an hour of prep work in case of a 15 minutes long presentation. I would bet that squeezing in an hour in your day for an important presentation should be possible in usual circumstances.

Ummm

Watch this video (with sound!) if the title doesn't make any sense

Get it?

Each one of us is guilty ummming every now and then. It's kind of a natural thing to do and you don't really notice it in everyday communication. It's a different thing in a presentation context though. If you haven't rehearsed enough you might be ummming when you are figuring out what to say next. That makes your presentation slow, boring, and maybe unprofessional. So when you are rehearsing try to notice when you are doing this, and think of it as a sign to what parts need improvement or some minor rehearsal in a rehearsal.

Filler Words

Slipping in filler words are a somewhat more sophisticated way of buying time. The filler word I commonly repeat is actually. What does "actually" mean? It could be used to reinforce factuality or it could be used as a way to introduce contrast. However, it rarely wears these qualities when I say it. The word is just there, adding no further meaning to my presentation. This makes your presentation longer, potentially boring your audience. Pay attention to which words you are using as a filler and try skipping them altogether.

Some common filler words to watch out for:

actually
basically
essentially
like
kind of/sort of
you know what I'm sayin'

Intonation and Emphasis

I'm not a native English speaker, I'm Hungarian and I noticed that tone has much more significance in spoken English than in my mother tongue. I mostly hear American English being spoken and it seems its "melody" carries a lot of information. As a non-native English speaker, I have to put extra care into learning which parts of words and which words to emphasize.

Accept the fact that your audience will usually only remember just a few things from your presentation. Identify the key takeaways of your talk and put most emphasis on the words/sentences that convey them. Don't fall into the trap of emphasizing too much. If everything is emphasized then nothing stands out and this is how it looks in written form:

Intonation is bringing your pitch up and down, for example you bring your pitch up at the end of a question. It's a natural way to convey your emotions. You should align your intonation with the content you are delivering. Spark interest with a question before introducing a new concept. Use falling intonation at the end of a segment to signal a short break. Most of the pitch manipulation should come naturally if you are really "living" your presentation. You will speak higher at happy parts and lower at sad parts. However, if you have ever been told that you sound flat, monotonous (like me) then focus a little more on your voice so you can improve it.

If you are not presenting in your native language then strive to bring your best pronunciation of the language you will be speaking in. In my case that's English. While native English speakers are able to understand various different accents from around the world, non-native English speakers with a different mother tongue than mine will be having the hardest time deciphering my accent.

Speech tempo

Ever watched videos on YouTube with a speed of 1.25x (even 1.5x)? We tend to consume aural (even visual?) content faster than the rate it's being produced. This tells me that most of us could speak faster than we usually do and the audience could still handle it. So if you haven't been told that you speak fast, you could probably go faster in your presentations than you would initially. But be careful, don't go as fast as Eminem!

Your pace will define the length of your talk. A shorter talk allows more time for people to ask questions bringing in more interactivity. Or more time for coffee and chit-chat with your audience. I never once heard anybody saying "I just love long presentations!". So rather focus on getting your message through than filling available time.

Know your audience

Figure out your audience's familiarity with the subject matter. The bigger the audience the harder to narrow down what they all are likely familiar with. But that's okay, the generality of your presentation should be proportional to the size of your audience.

For example don't assume that all people in your company know your team's product well. Contrarily, assume that your team knows their product well. Take some time in the beginning of your talk to even out the differences of familiarity within your audience with a preliminary section. This is where you introduce concepts that are essential to understanding your presentation.

Presentation content

Putting your presentation content on slides will give you a good baseline sectioning of your content. The sectioning outlines a steady rhythm to your flow. If you have to change the font size on a specific slide to fit the text, then it's probably a sign that the slide contains too much. Of course you can spend more time on key slides, but the general rule of thumb I always hear is aiming for 1 minute per slide.

Another easy win is staying consistent. Use the same style system within in your slides. One or two accent colors can cover most cases. No need for fancy fonts, I generally pick a sans-serif and stick with it. You can draw custom images if you are talented and efficient enough, but do consider whether it's really worth the extra effort. You can use copyright-free images from sites like Unsplash if you lack the resources to add custom images. The least you can do with stock images is to crop them to an aspect ratio that fits well within your slides.

(Lots of other things could be covered here but I focused on the - in my opinion - common low hanging fruits)

Smile

I don't think it's easy to keep smiling while giving a presentation at all. There are already so many things to pay attention to and consciously maintaining a smile adds to the cognitive load. On the other it would be foolish to deny the fact that smiling attracts people.

Luckily, there's a way to make yourself smile even if you are not in the mood. It's the basis of the "Facial feedback hypothesis" and it's pretty simple: bite on a pencil and wait. After a few moments you will be having a better mood and smiling. The video below explains it in detail, maybe it's something worth trying right before your next presentation!

Embrace the unknown

Bence Szabo — Wed, 07 Oct 2020 17:35:51 +0000

The Software Industry can be daunting: seemingly infinite amount of things to learn, hundreds and thousands of pieces of technologies, groundbreaking hardware innovations every year.

It's all normal to have doubts and uncomfortable feelings when you are starting your journey in this industry. Like learning anything in life you will feel like an outsider at first. However as soon as you overcome the hardship of beginning something new, things get a bit easier. As you spend more and more time with this "something new" you will start to feel more and more comfortable. Eventually you will arrive to a state where it would be very hard to remember what it was like before you knew this "something new".

Learning a programming language

So you decide to learn a programming language, let's name it Skillhand. You successfully create your first "Hello World!" program. Then you start writing more complex ones (FizzBuzz, TODO app, etc.), maybe you get a job and contribute small pieces to the production code. A few months pass and you don't feel so alienated by the industry anymore, it's pretty normal that you are a Software Engineer.

A few years pass and you are helping some other people in Skillhand. You know that you came a long way, and you maybe even got that mid level Software Engineer title. You thrive in writing Skillhand code, and you just love your job.

Another few years pass, and almost every other engineer comes to you for asking Skillhand questions. Your manager knows this and (s)he decides to promote you to a Senior Software Engineer.

Since you are one of the best engineers in the team now, an orphaned project is assigned to you. "Bring it" - you think, you are pretty good in Skillhand. To your surprise though the project is written in WisePalm (another fictional language).

Learning a programming language again?

Remember that daunting feeling I talked about? It was a long time ago since you experienced that, and you don't ever want to feel like a newcomer and powerless.

You could say that you don't want to work on this project, and it will be handed to another engineer. However, you decide against that and accept the project.

In the next months you start working in WisePalm. Soon you realize it lacks a lot of things you knew about Skillhand. You start to dread this new language. You would really want to work in Skillhand, but it would take a lot of effort to rewrite the project. Your productivity and enthusiasm decreases day by day.

What is happening?

Simply put, you are pushed out of your comfort zone.

How can I get back?

You can of course get back by ditching the project, but I don't think that's a wise choice. The ever-changing software industry will crush you if you don't adapt. Maybe it won't happen so quickly, it's rather a slow process which makes you miserable.

Overcoming the uncomfortable

So if nothing's left to do, why not just embrace the unknown? Take a leap of faith once again and start learning. If you did this once, why wouldn't you be able to do this the second time. It is almost a zero risk undertaking.

Accept that this new language probably exists and is used for a good reason. Be optimistic and focus on the bright sides, not on what's missing from it compared to what you are used to. Develop a Growth Mindset to get there faster.

What will also help you is thinking in concepts rather than code. Notice how most of the time the same patterns are implemented in different languages. Recognizing these patterns will help you become proficient in any new language.

Think in business, think in product, think about what actual problems you are solving with code. Your mind will open up to these things and the great picture will be much clearer. Try to describe the algorithms you implemented with natural language.

Stop entrenching yourself in the old and known, and embrace the new and unknown. I guarantee you will be happier.

This is what escaping the comfort zone can feel like

Clean Coding React - Props

Bence Szabo — Wed, 20 May 2020 20:55:22 +0000

Clean code is code that is easy to understand and easy to change.

When you are developing a React application in TypeScript, you most likely come across the problem of defining the type of the props of a component. Now this isn't something that's hard to solve, on the contrary: it can be solved in many ways! The problem comes with "many ways".

In my few months of working with React in TypeScript I came to the conclusion to use the following pattern illustrated by a made-up component:

interface Props {
  size: Size
  variant: Variant
  thirdProperty: ThirdProperty
}

const MadeUpCompo = ({ size, variant, thirdProperty }: Props) => {
  /* implementation of component */
}

Why do I use this pattern?

The declaration of the Props interface is always before the component. I find this cleaner than declaring the type of props inline which can become quite cluttered after a few properties.
I always use the name Props for the interface so I never have to think for even a second about its name. One other pattern I see would be naming it MadeUpCompoProps but that's repetitive, longer, and I don't think it enhances clarity any more.
Props are always destructured so you just use the size, variant, etc. identifiers, instead of writing something like props.size, props.variant, etc.
Props are typed, I catch errors compilation time. I avoid using any for "typing" props

One last thing I thought about is whether the Props should be an interface or type alias. At this point I don't think it matters much, but here is a well-fitting article connected to this: Type aliases vs. interfaces in TypeScript-based React apps

What do you think? Do you find this pattern useful?

Building a side project in 100 days

Bence Szabo — Sun, 01 Mar 2020 21:21:10 +0000

Side projects are a good way to enhance your programming skills and broaden your experience. You can learn a ton of things with usually no restrictions on what language, IDE, technology, etc. to use. I just launched my new side project: hypevizz.com, a data visualization blog built on Firebase, and I would like to share some pieces of it.

The idea, name & logo 💡

Some time ago I had this idea of building a service that visualizes data gathered from the music industry. However, this seemed like a massive undertaking for me so I pivoted this idea to create a non-specialized data visualization blog. This is a much more attainable goal and allows much more freedom in terms of topic.

Once I settled with the idea I had to come up with a name. When looking for a name I try to figure out one that's not already taken from the .com top-level domain. A good place to check this is the domain finder of any .com domain registrar, I used godaddy.com. Another thing I did was verifying whether the username "hypevizz" was taken on Instagram, Twitter, or Facebook (luckily it wasn't on either).

Next, I created the logo. I rarely create logos, but when I do I try to make the best of it. In my opinion a logo has to be very simple and distinguishable so I just went with a special font and the name itself (see the cover image). I skipped creating a custom graphic, icon, or symbol because I'm just not skilled enough to do so. I simply used the first letter "h" from the logo as the favicon and profile picture on social media.

The technology 🔥

Since the primary focus of this project is not earning money (yet?), I try to minimize the cost of it. Hosting a website or a web service is rarely free, or when it is free it comes with limitations. I found that the Firebase Spark Plan suits my needs: it is free with no time limitation, but with some data transfer and/or request per day or month type of limitations. When starting out a new service or blog you wouldn't expect hundreds of thousands of requests per day so it's perfect in the early phase.

Blog-like websites can be (and probably should be) very static. I decided that the posts/articles will be static HTML pages, but the home page that kind of serves as a dashboard will be a Single Page Application. I generated a React App with Create React App for the SPA part, then created some templates and npm scripts for drafting/publishing/updating posts. Firebase Hosting serves the SPA, posts, and any additional media (mostly images), and a Firestore database is the "glue" between the SPA and posts.

The npm scripts are used to render posts, update RSS/sitemap/database and deploy to hosting. They are written in TypeScript and executed by ts-node. The posts are basically pure HTML, CSS, and JS. Of course there are some common primitives like the header fragment, styling, and some utility functions. The post content resides in GitHub along with the source code.

Visualizations 📈

I built a custom "player" for the visualizations, you can see it in the first post. It's keyboard-enabled and has three buttons. The first button is a Play/Pause button (Space) that pauses the visualization. The second button (c) is used to capture and save the current frame as an image. The third button is the Full screen button (f, or double-click) which does exactly what you think it does.

To create the visualizations themselves D3.js is one of the go-to choices. I heard about D3 a lot of times throughout the last few of years, but I never really understood what it was. With this project I finally figured out what it is and how it works. Sites like d3-graph-gallery.com, bl.ocks.org, observablehq.com helped tremendously.

This is a capture of the first visualization I built with D3

Creating Content ✍️

All these pieces provide a platform on which I will try to produce content with a reasonable cadence. The good thing is I'm already full of topics to cover, the bad thing is that I don't always have the time. It took me a hundred days to get here from the first commit, I hope it won't be so long until the next post.

I've set up the hypevizz Twitter and Instagram accounts to keep contact with people. I also maintain an RSS feed for people using RSS. The Facebook account is still under the works.

I will be creating some more content on different platforms to get a better reach for the blog. Of course one of them is going to be my dev.to where I will be sharing (in a shorter form) some tips and ideas I used. My CodePen is going to be the place where I will be putting the code snippets and demos. I will be using some other ones on a more ad-hoc basis.

Final thoughts 😌

I hope to be as enthusiastic about this project as I have been in the past few months. In theory the easy part should come now, but we'll see 😄. Let us know in the comments if this writing has inspired you to create something new!

Thank you for reading this far!

Grayscale Color Palette with Equal Contrast Ratios

Bence Szabo — Thu, 23 Jan 2020 20:41:49 +0000

Ever needed a grayscale color palette for different surfaces, shadows, or states in your web app? I created a little utility to generate such palette.

tl;dr: Scroll to the end to get the list of colors

But what's the big deal?

I'm glad you asked. I could have just simply created a palette that started from black #000000, and stepped through to white #ffffff with let's say increments of #080808. So something like (remember hexadecimal):

#000000
#080808
#101010
#181818
...
#ffffff

But this feels a bit off, mostly because we humans don't perceive colors as hexadecimal representations. Qualities like hue, saturation and lightness are much better interpretations of human color perception. When you compare two different gray colors against each other they will only differ in lightness. A common method to measure difference in lightness is calculating the contrast ratio.

So how is color contrast ratio calculated?

The WCAG contrast ratio definition says:

contrast ratio
(L1 + 0.05) / (L2 + 0.05), where

L1 is the relative luminance of the lighter of the colors, and

L2 is the relative luminance of the darker of the colors.

NOTE
Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).

Actually, I already wrote an in-depth article about calculating the color contrast ratio, see below if you're interested:

Which Colors Look Good on Black and White?

Bence Szabo ・ Mar 21 '19

#a11y #css #design #productivity

All in all, the method to calculate the contrast ratio was already given.

Creating an equi-contrast color palette

My goal was to create a gray color palette on which each color against its adjacent color has the same contrast ratio. To generate such palette I only needed to step through the gray RGB space and store the colors that had enough contrast against the previous palette color. I picked the default contrast value of 1.10362 (that is roughly 1.1) so that the palette spans from #000000 to exactly #ffffff and consists of 30 individual colors. You can see the result in the embedded CodePen below, but feel free to play around by opening the Pen in Edit mode and modifying the value of CONTRAST_RATIO in the first line of JS 🙂

The UX of Shopping Clothes

Bence Szabo — Thu, 14 Nov 2019 23:00:03 +0000

I don't always shop clothes, but when I do some things just grind my gears. Based on a true story.

Arrangement

Maybe it's just me, but I usually don't get how things are arranged. Say, I want to buy some T-shirts, and maybe I'm interested in all T-shirts a shop is offering. Well good luck finding all your options in an arbitrary labyrinth of fabric. It's not like you go through some aisles and that's it, store layouts are pretty random (at least where I live). I think it would make much more sense to designate a part of a store for T-shirts, another for pants/trousers/jeans, another for underwear, and so on. Okay, they probably organize stuff by theme, but then I'd argue if it's the optimal way to go about it for most customers.

Perfectly arranged

Fit

Once you figured out which part(s) of your body to cover, you look for style and print. You look for these qualities because these are the ones you can see almost immediately. For the size and fit you have to check the tag(s). I gotta give props to stores regarding size, because the clothes are usually sorted by size. Fit is a different topic though. I know about regular, slim, skinny, long, and muscle fits. A lot of the times I see something I like and get a little excited, but then I check the tag and realize it's not the type of fit I wear. It's such a disheartening feeling that could be avoided by sorting clothes by fit as well.

This fits nicely

Fitting Room

Fitting rooms are my pet peeve. First of all there's never enough of them, you always have to wait your line to get one. Finally you get a room and the first thing you do is to mess around with those damn curtains. The worst ones are heavy, tall, and mounted on tracks that don't reach end-to-end, so you have a pretty hard time properly covering the opening of the room. The curtains should be light, just a little taller than a tall person, and mounted on longer tracks than the opening. An even better setup is when there are actual doors instead of curtains.
Inside the fitting you want to hang the clothes you will try, but the hangers sometimes look like scrap metal incapable of holding three or more items. Alternatively, you could use the seating for that, well only if it's not just some tiny circular stool. A bench-like seating is always better, allowing more space and even the opportunity to try how the clothes feel like while sitting!
Lighting is overdone. It's so much sometimes that you get to see a new face of you in the mirror. Shadows are cast by parts of your body that you don't want them to. It's just an unnatural experience and it's accompanied by the unpleasant warmth coming from the heat of the bulbs.

That's a pretty strong light

Checkout

In the end you get weary, but if you are lucky you manage to buy something you like. Congrats! Just hope it won't shrink after the first wash, because then you're back to square one. Let's call this the Circle of ~~Life~~ Shopping.

Which Colors Look Good on Black and White?

Bence Szabo — Thu, 21 Mar 2019 19:05:00 +0000

Imagine you have to find a color that looks good both on black and white. By "looking good" I mean conforming at least WCAG AA Contrast (Minimum), which is a ratio of 4.5:1.

tl;dr: Scroll to the end to get the list of colors

So how is color contrast ratio calculated?

The WCAG contrast ratio definition says:

contrast ratio
(L1 + 0.05) / (L2 + 0.05), where

L1 is the relative luminance of the lighter of the colors, and

L2 is the relative luminance of the darker of the colors.

NOTE
Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).

Simple math, right? You take two values and divide them.

But how is the relative luminance calculated??

The WCAG relative luminance definition says:

relative luminance
the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white

NOTE
For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:

if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4

if GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4

if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4

and RsRGB, GsRGB, and BsRGB are defined as:

RsRGB = R8bit/255

GsRGB = G8bit/255

BsRGB = B8bit/255

Don't get bamboozled by the equations, it's still simple math! The last three lines are just about normalizing the color channels by dividing them with 255, here are some examples:

Color	R8bit	G8bit	B8bit	RsRGB	GsRGB	BsRGB
Black	0	0	0	0	0	0
White	255	255	255	1	1	1
Red	255	0	0	1	0	0
Purple	128	0	128	0.502	0	0.502
Orange	255	165	0	1	0.647	0

Then getting the R, G, and B values is done by a simple division (divide by 12.92) if the normalized value is less than or equal to 0.03928, or applying the exponential formula above if the normalized value is greater than 0.03928. The final step is summing these three values with different weights.

Let's calculate!

It's not hard to see that the relative luminance of black is 0, and white is 1. Calculating their contrast ratio gives (1 + 0.05) / (0 + 0.05) = 21. We can calculate any other color's contrast ratio against black and white by the following (where "c" is the color's relative luminance):

against black: (c + 0.05) / (0 + 0.05)
against white: (1 + 0.05) / (c + 0.05)

We have a requirement of a contrast ratio of at least 4.5, therefore:

against black: (c + 0.05) / (0 + 0.05) >= 4.5
against white: (1 + 0.05) / (c + 0.05) >= 4.5

Solving the two inequalities give:

against black: c >= 0.175
against white: 0.1833 >= c

In the end we get the relative luminance requirement of:

0.175 <= c <= 0.1833

The list of colors

Finally, I created a pen which iterates through the RGB color space, from black to white with increments of 0x11 = 17 per channel. Iterating through all of the colors would take some time and CPU, and I'm sure listing ~300k colors wouldn't be practical. So the pen iterates through the colors which can be described with 3-digit hexa notation, and lists 76 colors that matches our requirements. Use them wisely ;)

Two days ago I released Matter

Bence Szabo — Tue, 05 Mar 2019 23:07:01 +0000

This was the first release of Matter. I never did open source before, so this was my first release ever in the scene.

This project goes back to around half a year before, when I needed just a few nice looking components for a CodePen demo. Buttons, Slider, Switch, Textfield, some of the usual components of a web page. I'm a big fan of Material Design, and I couldn't find any lean and simple way to integrate these Material components into my Pen. I thought it shouldn't be hard to implement them.

I'm a big fan of Pure CSS Stuff too. I wondered if these components could be done without JavaScript. It turns out you can go a long way with this restriction. Not full blown functionality though, but enough for a lot of use-cases.

CodePen has a nice community, I received some good feedback for the Material components. Yet, the Pens were still kind of impractical. I mean, I spent quite some time to perfect each of them, and there was no easy way for others to benefit from them. Next step: open source.

In the last two months I have been figuring out solutions for the typical problems (I guess) of an open source project. The most time I spent on was testing, and I think it's one of the best things of the project! (But what do you test in CSS? - you might ask, well that's another story). Anyways, Matter has a 0.1.0 release. It ain't much, but it's honest work:

I can imagine a number of directions this project would go, I wonder which one will it be...