Select Page

Category: Article

Visual Email Builder Apps

I bet y’all know that apps like Campaign Monitor and MailChimp have visual email builders built right into them. You drag and drop different types of content right into a layout. You edit text right within the email. It’s nice. It’s a lot nicer than editing the quagmire of HTML underneath, anyway! But not everybody needs all the rest of the features that those apps bring, like list management and the actual sending of the email. Perhaps you have an app that already handles that kind of thing. You just need to design some emails, get the final HTML,...

Read More

A Poll About Pattern Libraries and Hiring

I was asked (by this fella on Twitter) a question about design patterns. It has an interesting twist though, related to hiring, which I hope makes for a good poll. Note: There is a poll embedded within this post, please visit the site to participate in this post’s poll. I’ll let this run for a week or two. Then (probably) instead of writing a new post with the results, I’ll update this one with the results. Feel free to comment with the reasoning for your vote. Results! At the time of this update (September 2017), the poll has been up for about 6 weeks. 61% of folks said they would be more likely to want a job somewhere that were actively using (or working toward) a pattern library. That’s a strong number I’d say! Especially when 32% of folks responded that they don’t care. So for 93% of folks, they either are incentivized to work for you because of a pattern library or don’t mind. So is a pattern library good not only for your codebase and business, for attracting talent as well. Only 7% of folks would be less likely to want to work there. Presumably, that’s either because they enjoy that kind of work and it’s already done, or find it limiting. Read the comments below for some interesting further thoughts. A Poll About Pattern Libraries and...

Read More

Using ES2017 Async Functions

ES2017 was finalized in June, and with it came wide support for my new favorite JavaScript feature: async functions! If you’ve ever struggled with reasoning about asynchronous JavaScript, this is for you. If you haven’t, then, well, you’re probably a super-genius. Async functions more or less let you write sequenced JavaScript code, without wrapping all your logic in callbacks, generators, or promises. Consider this: function logger() { let data = fetch('') console.log(data) } logger() This code doesn’t do what you expect. If you’ve built anything in JS, you probably know why. But this code does do what you’d expect. async function logger() { let data = await fetch('') console.log(data) } logger() That intuitive (and pretty) code works, and its only two additional words! Async JavaScript before ES6 Before we dive into async and await, it’s important that you understand promises. And to appreciate promises, we need go back one more step to just plain ol’ callbacks. Promises were introduced in ES6, and made great improvements to writing asynchronous code in JavaScript. No more “callback hell”, as it is sometimes affectionately referred to. A callback is a function that can be passed into a function and called within that function as a response to any event. It’s fundamental to JS. function readFile('file.txt', (data) => { // This is inside the callback function console.log(data) } That function is simply logging the...

Read More

How do you start a sentence with “npm”?

This npm. Asking this question was a fun little journey. Right on the npm website, the very first sentence starts with “npm”, and they do not capitalize it. That’s a pretty good precedent for not capitalizing it. It certainly looks awkward though, which is why I asked the question to begin with. It doesn’t feel right to me to start a sentence that way, and I’m sure other some other people would look at it and see a mistake. Their own documentation forbids capitalization as well: Straight from Raquel Vélez, an employee: always npm, even if starting the sentence....

Read More

More CSS Charts, with Grid & Custom Properties

I loved Robin’s recent post, experimenting with CSS Grid for bar-charts. I’ve actually been using a similar approach on a client project, building a day-planner with CSS Grid. It’s a different use-case, but the same basic technique: using grid layouts to visualize data. (I recommend reading Robin’s article first, since I’m building on top of his chart.) Robin’s approach relies on a large Sass loop to generate 100 potential class-names, even though less than 12 are used in the final chart. In production we’ll want something more direct and performant, with better semantics, so I turned to definition lists and CSS Variables (aka Custom Properties) to build my charts. Here’s the final result: See the Pen Bar chart in CSS grid + variables by Miriam Suzanne (@mirisuzanne) on CodePen. Let’s dig into it! Markup First Robin was proposing a conceptual experiment, so he left out many real-life data and accessibility concerns. Since I’m aiming for (fictional) production code, I want to make sure it will be semantic and accessible. I borrowed the year-axis idea from a comment on Robin’s charts, and moved everything into a definition list. Each year is associated with a corresponding percentage in the list: 2000 45% 2001 100% There are likely other ways to mark this up accessibly, but a dl seemed clean and clear to me – with all the data and associated pairs...

Read More