Making software better without sacrificing user experience.

The X220 ThinkPad is the Best Laptop in the World

2023-09-26T10:00:00Z

The X220 ThinkPad is the Best Laptop in the World

2023-09-26

The X220 ThinkPad is the greatest laptop ever made and you're wrong if you think otherwise. No laptop hardware has since surpassed the nearly perfect build of the X220. New devices continue to get thinner and more fragile. Useful ports are constantly discarded for the sake of "design". Functionality is no longer important to manufacturers. Repairability is purposefully removed to prevent users from truly "owing" their hardware.

It's a mess out there. But thank goodness I still have my older, second-hand X220.

Specs

Before I get into the details explaining why this laptop is the very best of its kind, let's first take a look at my machine's basic specifications:

CPU: Intel i7-2640M (4) @ 3.500GHz
GPU: Intel 2nd Generation Core Processor
Memory: 16GB DDR3
OS: Arch Linux / OpenBSD
Resolution: 1366x768

With that out of the way, I will break down my thoughts on the X220 into five major sections: Build quality, available ports, the keyboard, battery life, and repairability.

Build Quality

The X220 (like most of Lenovo's older X/T models) is built like a tank. Although the inner pieces are sourced from mostly plastic, the device is still better equipped to handle drops and mishandling compared to that of more fragile devices (such as the MacBook Air or Framework). This is made further impressive since the X220 is actually composed of many smaller interconnected pieces (more on this later).

A good litmus test I perform on most laptops is the "corner test". You grab the base corner of a laptop in its open state. The goal is to see if the device displays any noticeable give or flex. In the X220's case: it feels rock solid. The base remains stiff and bobbing the device causes no movement on the opened screen. I'm aware that holding a laptop in this position is certainly not a normal use case, but knowing it is built well enough to do so speaks volumes of its construction.

The X220 is also not a lightweight laptop. This might be viewed as a negative for most users, but I actually prefer it. I often become too cautious and end up "babying" thinner laptops out of fear of breakage. A minor drop from even the smallest height will severely damage these lighter devices. I have no such worries with my X220.

As for the laptop's screen and resolution: your mileage may vary. I have zero issues with the default display or the smaller aspect ratio. I wrote about how I stopped using an external monitor, so I might be a little biased.

Overall, this laptop is a device you can snatch up off your desk, whip into your travel bag and be on your way. The rugged design and bulkier weight help put my mind at ease - which is something I can't say for newer laptop builds.

Ports

+ +

Ports. Ports Everywhere.

I don't think I need to explain how valuable it is to have functional ports on a laptop. Needing to carrying around a bunch of dongles for ports that should already be on the device just seems silly.

The X220 comes equipped with:

3 USB ports (one of those being USB3 on the i7 model)
DisplayPort
VGA
Ethernet
SD Card Reader
3.5mm Jack
Ultrabay (SATA)
Wi-Fi hardware kill-switch

Incredibly versatile and ready for anything I throw at it!

Keyboard

The classic ThinkPad keyboards are simply that: classic. I don't think anyone could argue against these keyboards being the golden standard for laptops. It's commendable how Lenovo managed to package so much functionality into such a small amount of real estate. Most modern laptops lack helpful keys such as Print Screen, Home, End, and Scroll Lock.

They're also an absolute joy to type on. The fact that so many people go out of their way to mod X230 ThinkPad models with X220 keyboards should tell you something... Why Lenovo moved away from these keyboards will always baffle me. (I know why they did it - I just think it's stupid).

Did I mention these classic keyboards come with the extremely useful Trackpoint as well?

Battery Life

Author's Note: This section is very subjective. The age, quality, and size of the X220's battery can have a massive impact on benchmarks. I should also mention that I run very lightweight operating systems and use DWM as opposed to a heavier desktop environment. Just something to keep in mind.
+

The battery life on my own X220 is fantastic. I have a brand-new 9-cell that lasts for roughly 5-6 hours of daily work. Obviously these numbers don't come close to the incredible battery life of Apple's M1/M2 chip devices, but it's still quite competitive against other "newer" laptops on the market.

Although, even if the uptime was lower than 5-6 hours, you have the ability to carry extra batteries with you. The beauty of swapping out your laptop's battery without needing to open up the device itself is fantastic. Others might whine about the annoyance of carrying an extra battery in their travel bag, but doing so is completely optional. A core part of what makes the X220 so wonderful is user control and choice. The X220's battery is another great example of that.

Repairability

The ability to completely disassemble and replace almost everything on the X220 has to be one of its biggest advantages over newer laptops. No glue to rip apart. No special proprietary tools required. Just some screws and plastic snaps. If someone as monkey-brained as me can completely strip down this laptop and put it back together again without issue, then the hardware designers have done something right!

Best of all, Lenovo provides a very detailed hardware maintenance manual to help guide you through the entire process.

+ +

My disassembled X220 when I was reapplying the CPU thermal paste.

Bonus Round: Price

I didn't list this in my initial section "breakdown" but it's something to consider. I purchased my X220 off eBay for $175 Canadian. While this machine came with a HDD instead of an SSD and only 8GB of total memory, that was still an incredible deal. I simply swapped out the hard-drive with an SSD I had on hand, along with upgrading the DDR3 memory to its max of 16.

Even if you needed to buy those components separately you would be hard-pressed to find such a good deal for a decent machine. Not to mention you would be helping to prevent more e-waste!

What More Can I Say?

Obviously the title and tone of this article is all in good fun. Try not to take things so seriously! But, I still personally believe the X220 is one of, if not the best laptop in the world.

Bypassing the WiFi Hardware Switch on the Lenovo X201

2023-04-02T10:00:00Z

Bypassing the WiFi Hardware Switch on the Lenovo X201

2023-04-02

I recently received a ThinkPad X201 to start using as my daily driver. I purchased the X201 to replace my existing X260. Although some might look at this as a "downgrade" in terms of specs and hardware, I would have to disagree.

The X201 is an absolute masterpiece in laptop hardware design and only faulted by some of the constraints set by the motherboard, namely the lack to support more than 8GB of RAM. Other than that, I think it's perfect. Well...almost perfect. There is one small annoyance:

The physical WiFi kill switch.

This thing can become really flaky on these older devices and countless people on the web report connection issues across multiple operating systems. I too ran into this issue not long after getting Alpine setup nicely on my machine.

Some remedies include re-installing hardware drivers, flicking the hardware toggle off and on repeatedly, or even simply logging out of the current user session. All these options seemed like a pain in the ass.

So I listed out my possible options:

Whitelist my BIOS WiFi settings (requires flashing BIOS) and install a newer wifi card, hoping the problem fixes itself
Purchase a replacement WiFi card (maybe mine was just buggy??)
Block PIN20 on the existing Wifi card
Somehow disconnect the hardware killswitch (requires soldering which I have ZERO experience with)

Out of pure laziness, I chose option three. In case you were unaware, PIN20 on older PCIE WLAN cards is the "wifi disable" and used as an RF killswitch. By "blocking" this PIN, we stop the system from being able to disable the WiFi connection. Losing the ability to disable WiFi on the hardware level didn't bother me much, so I moved forward with this easier approach.

Opening Up the X201

To access the WiFi card, you'll need to remove the keyboard and touchpad palm rest cover. It might sound daunting for newcomers but I assure you it is very simple. These machines were built during a time when Lenovo expected their users to tinker with their devices and built them with modular components in mind. Yet another reason for my decision to swap this laptop for my more "locked down" X260.

Note: I'm not sure how important this is, but I made sure to set my WiFi hardware toggle switch into the "ON" position before doing any of the other steps.
+

You can follow the very beautiful visual instructions provided by Lenovo below. Just remember to always power off you machine and remove the battery before tinkering.

Electrical Tape Fixes Everything

Now that the WiFi card has been safely removed from its port (you most likely do not need to disconnect the cables though!) it is time to block PIN20.

On the Centrino Advanced-N 6200 card PIN20 is located on the back side, since the front is designated to all odd-set pins. You'll need to cut a ridiculously thin piece of electrical tape to cover this single pin. I found this part to be the most taxing of my patience during the entire process. Just keep thinking happy thoughts and you can do it!

Once it is on PIN20, place your card back into its port, rebuild you X201, pop in your battery and boot up! If things were done properly, your WiFi should now be rock solid.

Best of all, you don't have to worry about accidentally toggling your WiFi toggle switch - it does nothing! Mine is actually set in the "OFF" position all the time now.

Enjoy less flaky WiFi.

WP Enqueue for Beginners

2020-05-05T10:00:00Z

WP Enqueue for Beginners

2020-05-05

Throughout my career designing, developing and auditing WordPress themes, I've come across many that include their custom styles / scripts as static HTML elements inside their respective header and footer templates. This is perfectly fine, but there is a cleaner way to include these files.

This post is purposefully catered for WordPress beginners, so if this seems overly simple, then you're probably already developing WordPress themes that utilize these techniques. (Which is awesome!)

Introducing WP Enqueue

The description of Wp Enqueue from the WordPress documentation:

+
+ Registers the style [script] if source provided (does NOT overwrite) and enqueues +
+

In a nutshell: Placing a wp_enqueue_script or wp_enqueue_style script in the functions.php of your custom theme tells WordPress to pull external files into the header or footer of your website. Best practice being: styles into the header, scripts into the footer.

I suggest you read the official documentation for more details: wp_enqueue_script and wp_enqueue_style.

Enqueue Stylesheets

The default script to enqueue a CSS stylesheet:

wp_enqueue_style( $handle, $src, $deps, $ver, $media );
+

$handle - the name associated with your stylesheet
$src - URL pointing to the directory of the stylesheet itself
$deps - An array of any other stylesheets needed as dependencies
$ver - The version number of the stylesheet (used for cache busting)
$media - Specify media type (all, print, screen, etc.)

So, with all those parameters in mind, here is what a standard default enqueue of a CSS stylesheet looks like:

wp_enqueue_style( 'google-fonts', 'https://fonts.googleapis.com/css?family=Montserrat:200,300,300i,400,600,700,800,900', '', '1.0', '');
+

In this example we have rendered the following:

$handle: google-fonts
$src: https://fonts.googleapis.com/css?family=Montserrat:200,300,300i,400,600,700,800- 0
$deps: Null (left blank)
$ver: 1.0
$media: Null (left blank)

Important: Keep in mind that the wp_enqueue_style script will render the stylesheet link into the WordPress header automatically.

Enqueue Scripts

The default script to enqueue an external JS file:

wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
+

$handle - the name associated with your script
$src - URL pointing to the directory of the script itself
$deps - An array of any other scripts needed as dependencies
$ver - The version number of the script (used for cache busting)
$in_footer - Set whether the script is loaded in the <head> or just before the </body>

With all those parameters in mind, here is what a standard default enqueue of a Javascript file looks like:

wp_enqueue_script( 'bxslider', get_template_directory_uri() . '/js/bxslider.js', array('jquery'), '1.0.0', true );
+

In this example we have rendered the following:

$handle: bxslider
$src: get_template_directoryri() . /js/bxslider.js'
$deps: array(jquery')
$ver: 1.0.0
$in_footer: True (places script before closing body tag)

Packaging Everything Together

Now that we have the custom stylesheet and script ready to be loaded into our custom WordPress theme, we just need to properly package them together as a function in our functions.php file:

// Add styles and scripts to the header/footer
+function custom_enqueue_scripts() {
+        wp_enqueue_style( 'google-fonts', 'https://fonts.googleapis.com/css?family=Montserrat:200,300,300i,400,600,700,800,900');
+        wp_enqueue_script( 'bxslider', get_template_directory_uri() . '/js/bxslider.js', array('jquery'), '1.0.0', true );
+}
+
+add_action( 'wp_enqueue_scripts', 'custom_enqueue_scripts');
+

That's it! Hopefully this helps prevent WordPress newbies from statically rendering their external CSS and JS files directly in template files. Let WordPress do that for you!

Setting Up Jekyll on Windows

2022-09-02T10:00:00Z

Setting Up Jekyll on Windows

+2022-09-02 + +I've recently been playing around with using Windows 10 as my daily operating system. So far, it has been going fairly well. Nothing will probably ever feel as "optimized" as running a Linux-based system but it works well for my current needs. Getting a Jekyll development environment setup was a different story though... + +One of the first issues with using Windows 10 is the need to run a few of my open source projects that are built off Jekyll locally. This process initially seemed a like complex process to get things running smoothly but in the end was very straightforward. The main issue came from needing to bounce around through a handful of separate tutorials to get everything running smoothly. + +So, I thought I would make this quick write-up to help those in the same situation (or even for my future self the need arises). Let's get into it. + +

WSL

+The first step involves installing WSL in order to run Linux alongside the main Windows OS. The documentation is well written and will get you up-and-running in no time. For quick reference, it essentially comes down to: +

+ +

Opening PowerShell or Command Prompt as an administrator
Installing via the command: wsl --install
Restarting your machine after the install completes
Creating your UNIX username and password

Installing Ruby & Dependencies

+Once logged into your UNIX terminal session (with your created user) you can begin installing everything we need for Jekyll to work properly. The first step is to installing rvm and the official project documentation does a very good job of walking you through this. +

+ +

Be sure dependencies as installed: sudo apt-get install software-properties-common
Add the PPA and install the package:

+ +

sudo apt-add-repository -y ppa:rael-gc/rvm
+sudo apt-get update
+sudo apt-get install rvm
+

+ +

Add your existing user to the rvm group: sudo usermod -a -G rvm $USER

+You will need to close and restart your session to your Ubuntu system for these changes to take. After that, we can use rvm to install the latest version (at this time of writing) of ruby: + + +

rvm install 3.1.2
+

+ +That's it! + +

Jekyll - Finally!

+The final step is to update our gems and install Jekyll: + + +

gem update
+gem install jekyll bundler
+

+ +Once complete you can now run your Jekyll projects locally through WSL! Nothing ground-breaking but still pretty helpful for first-time users. And best of all, at least I have a good reference point in the future if I ever run into this issue again!

Width or Flex-Basis?

2018-11-28T10:00:00Z

Width or Flex-Basis?

2018-11-28

Creating rows and columns of elements that adapt dynamically can be a little tricky depending on the desired outcome. Let's breakdown how to solve this issue using both inline-block paired with width and flex-basis.

Width

Setting the width of the inner children to a divisible value and setting their display to inline-block, we are able to create self-wrapping elements:

.width-container {
+    display: block;
+}
+.width-container__item {
+    display: inline-block;
+    width: calc(33% - 3px); /* Fix for wonky inline-block margins */
+}
+

Pros

Full browser support (as far back as IE6)
No floats needed

Cons

Buggy margin workaround needed
Wrapped elements cannot dynamically fill remaining empty parent space

Flex-basis

This is my personal preference for dynamically wrapping inner children elements. Simply set the parent as display: flex, allow flex-wrapping and then set the flex-basis of the children to any percentage value.

.flex-container {
+    display: flex;
+    flex-wrap: wrap;
+}
+.flex-container__item {
+    flex: 1 1 auto;
+    flex-basis: 33%;
+}
+

You will also notice the flex property set to 1 1 auto. This is important if you require your wrapped elements to fill the remaining space of the parent container.

Pros

No buggy margins to play with
Dynamically renders children to fill parent container if flex is set
Scales well across screen / device sizes

Cons

Some versions of IE struggle with browser support

CodePen Demo

Feel free to play around with a slightly more stylized version of both options below:

CodePen Demo: Width or flex-basis

Stop Using Custom Web Fonts

2023-03-14T10:00:00Z

Stop Using Custom Web Fonts

2023-03-14

I recently read an excellent post by Manu Moreale titled A rant on web font licenses. I highly recommend you give it a read (it's relatively short) since Manu makes a solid argument against existing font licenses. After reading, I found myself thinking about it throughout the rest of the day.

I was trying to understand how we ended up in a situation where web/UI designers (myself included) have started to insist on using proprietary, custom web fonts. Do any users actively benefit from custom web fonts? Are there any useful and measurable goals achieved by including them? Do end-users actually care about a website's typeface?

For the most part, I believe the answer to all those questions is: not really.

System Fonts Look Good

We are no longer in the early days of the internet. Browsers have matured. Operating systems already ship with usable and often times pretty typefaces. The "wow factor" of having a custom web font on a website is completely gone. Not to mention, recent trends see designers including terrible typefaces that actually make things more difficult to read and break basic accessibility.

All of this for the sake of a company's "brand". I say: fuck your brand. Your end-users should always trump your design "guidelines". Period.

"Think of the Consistency!"

Often times designers will argue that designs will look too different across browsers/operating systems. I'm not sure why this is seen as a bad thing. First, users will be familiar with the fonts already available to them. Second, as designers our work should never rely on one point of failure (in this instance: fonts). Your designs should be agnostic of your typeface selection.

And what about users with browser extensions that already block your custom web fonts? Screw them I guess?

People work on different systems with different constraints and settings. Embrace that - don't try to override it.

Loss of Personality

The web is not the same medium as graphic design. Digital designers often get this confused. Web applications serve an action or purpose. The user wants to complete a task - not look at a pretty poster. I understand this sounds harsh, but many designers design more for their own ego and portfolio rather than the end-user. That extra flair on your lowercase "t" doesn't help the user better interact with your features or UI. It just slows them down.

Hurting Performance & Wasting Resources

A lot of designers I've worked with or talked to in the past tend to be big supporters of reducing their carbon footprint and minimizing their individual output of "waste". What I always find interesting is how that never seems to translate into their work.

It might be small in the grand scheme of things, but having an extra HTTP request (or more) for your custom fonts and requiring your users to consume more bandwidth on their end is not "eco". As designers we should cut the fat and reduce software bloat in the small areas that we're able to: the front end.

My hope is that even one designer reading this decides to rollout a web app or marketing page without dumping a bunch of custom fonts on their users. It's just the nice thing to do.

Running VSCode in Chromium on OpenBSD

2023-06-05T10:00:00Z

Running VSCode in Chromium on OpenBSD

2023-06-05

VSCode and its many variations are not available on OpenBSD. This doesn't cause issue with many OpenBSD users, but those making the jump from Linux might miss access to such a popular editor. Lucky for us, there is a hacky workaround to solve this problem.

VSCode in the Browser

I tried my best to build something like code-server locally and run that directly in my browser - but I failed miserably. Instead, I fell back on vscode.dev which is essentially a remote version of code-server.

Getting things to work seamlessly proved a little more challenging. I found the best performance was running everything through Chromium with special parameters enabled on launch.

Note: The following assumes you have already installed chromium
+

First we need to disable unveil for Chromium. This will allow us to access our system files through vscode.dev using the "Open folder..." or "Open file..." commands without issue:

chrome --disable-unveil
+

Everything should work pretty solid right out the box now - except it doesn't. Syntax highlighting does not work without enabling WASM/WebAssembly. Your experience might be different, but I had to include the following when launching Chromium from the terminal:

ENABLE_WASM=1 chrome --enable-wasm
+

Success! We can avoid typing out these complex commands everytime we want to launch our editor by setting up an alias (in my case via .zshrc):

alias vscode="ENABLE_WASM=1 chrome --enable-wasm --disable-unveil"
+

That's it! Now I can just pop open VSCode on OpenBSD by simply running vscode in my terminal. Hopefully this can help others slowly transition over to OpenBSD - which you should do because it is amazing!

Icons Should be Complementary - Text is Always Better

2021-12-17T10:00:00Z

Icons Should be Complementary - Text is Always Better

2021-12-17

Designing[^1] software is a complex thing. A great deal of real-world testing and user feedback is needed to create the best solution to the problem you are trying to fix. Obvious requirements are to keep things simple, make it easy to understand by looking at it, and build it to be headache-resistant for future updates. All these things are easier said than done. This is the challenge of a designer's dat-to-day.

But with this term of "simplicity" modern designers tend to take this approach too much to heart. In my 12+ years involved in UI/UX software design, I have lost count how many initial iterations of interfaces suffer from the same "dumbing down" decision making:

Using icons to represent an action or function without textual information.

If you decide to stop reading the rest of this article, at least take away this one important thing:

Always try to use text to convey your designs
+

After achieving this, you should start reiterating those designs to include iconography. Even then, not all UI instances will require you to do that. Designers will find this process difficult, which is why it is important to get right.

Icons make an ass out of u and me

Icons make general assumptions about what the user may or may not understand. Leading with this in your designs will end poorly for you. Trust me - I've learned this through failed designs many times over. A certain visualization might be common knowledge to you, while differing greatly to someone else with a different set of experiences.

I've found the only thing you should ever assume is that the user knows nothing. Please note - I'm not referring to their intelligence but instead their software literacy.

Take a look at our now "famous" save icon used in almost every piece of software; the floppy disk. Do any software users below the legal drinking age even understand the initial reasoning for using this icon? In all honesty, it was a terrible icon decision even when first introduced. No "hard copy" of the save action is taking place, software creates this save in a digital space[^2]. Yet, it was adopted and people (ie. designers) went along with it.

Quality is not measured by mass appeal.

The argument could be made "People learned to associate "Save" with a Floppy Disk icon..." and my response would be "But what alternatives were they given?"

Original software designers (and developers) held all the power in early UI decision making. General users didn't know any better. Things were new and fresh. Now our response is to shrug our collective shoulders and say, "That's how the save icon has to be now!"

Hogwash. Make it a button that says, Save File. I'm not kidding. Oh, it doesn't work with your current design? Then your initial design wasn't future-proof then, was it? I sound snarky here but many designers put up imaginary walls around their design systems, making them incredibly rigid and difficult to adapt.

Take the time to do even a small thought / wireframe experiment: redo the layout and flow of your application without using a single piece of iconography. If you can't achieve this with even limited success, something is wrong with the design.

The hamburger menu is the 7th circle of Hell

Normally, the inclusion of a hamburger menu is indicative of an overly complex application. Too many cooks and all that jazz. Enterprise applications don't get a pass here either, as they tend to be the worst culprits of pouring out everything on to the user as software vomit. Sweeping all this interaction under the hamburger "rug" does not make for a cleaner design.

New features are great, but stop dumping so much of it behind hidden, unintuitive sub-navigation. This design is such a "quick fix" and plagues far too many software apps[^3]. Both desktop computers and mobile devices allow users to scroll, let them.

I've discussed this in further detail here: Using Hamburger Menus? Try Sausage Links

But what of the "advanced" users?

I understand applications will have advanced or "pro" users that have full knowledge of the product and wouldn't need things spoon fed to them. This is a more difficult problem that I myself haven't been able to solve without approaching each one on a case-by-case basis. Unfortunately, there is no "one size fits all" method to this. But, although solving for advanced users proves difficult doesn't mean we should dismiss the merits of avoiding icons as a crutch.

Try for yourself

As I stated above, try doing a quick design experiment by replacing all your existing iconography in your application with simple text. I assure you that at least you'll discover interesting design flaws in your system.

Refs

By "design" I'm referring to visuals not programming or system engineering
Early software programs did save to an external floppy disk. My point stands that many digital file storage applications copied this iconography blindly.
Not to mention how rampant it is on plain ol' regular websites. If you're hiding five menu items behind a hamburger menu for "mobile users", you're doing it wrong.

Using User-Select

2019-06-04T10:00:00Z

Using User-Select

2019-06-04

Highlighting text in order to copy, cut or paste content is a staple action across the web. Now, what if I told you the ability to control what a user can select is configurable with a single CSS property?

Introducing the CSS property

Simply put, the user-select property is defined as follows:

user-select controls whether the user can select text (cursor or otherwise)
+

The CSS

The property's available attributes are very straightforward (just remember to target specific browsers for full support!)

/* Default */
+p.default {
+    user-select: auto;
+    -moz-user-select: auto;
+    -webkit-user-select: auto;
+}
+
+/* Disable the user from selecting text */
+p.no-select {
+    user-select: none;
+    -moz-user-select: none;
+    -webkit-user-select: none;
+}
+
+/* Select all text when user clicks */
+p.select-all {
+    user-select: all;
+    -moz-user-select: all;
+    -webkit-user-select: all;
+}
+

Let's see it in action

Try selecting the separate paragraph elements in the CodePen below:

Live CodePen Example

Browser Support

The great news is user-select is fully supported across all modern browsers (even as far back as IE10!)

They Won't Wait: A Warning for Slow Websites

2019-06-25T10:00:00Z

They Won't Wait: A Warning for Slow Websites

2019-06-25

Your website is probably slow. I'm not trying to make you feel bad or dismiss all the hard work you've put into your project. Heck, performance might have been a core value of the design. But websites can always be faster.

People have become increasingly more impatient over the last decade when it comes to technology, specifically non-native web-based interactions. Users expect your website to load almost instantly or they will leave and try another site, probably one of your competitors. Why should they stick around if your competitors' websites load half a second faster?

Users are tired of being bombarded with tracking scripts, having to download massive component libraries, forced to deal with "accept cookies" prompts, playing a small mini-game of "close those ads!", and then being subjected to never-ending loading screens. This is not the internet we were promised.

It's in my nature, I always liked speed.
+
- Guy Lafleur
+

We can do better

If there is only one thing that you learn from this post, hopefully it's knowing to better value the time and money of your users. It's a user's choice to visit your website, so taking advantage of their time is extremely careless. Don't be arrogant and ignore the cost of data on most mobile plans either. Eating up a chunk of someone's data just for hitting your website is rage-inducing. That's how you can lose customers permanently.

Let's do an analogy, because I love stupid analogies:

Imagine going to your local hardware store because you need to buy a new hammer. Once you get to the entrance a woman holds the the door closed and asks you if it's alright for someone to follow you around the store today. You say no. She then follows up by asking if you accept their hardware store agreement before proceeding inside - you tell her "sure". She finally opens the door and lets you in. As you walk into the store she quickly stuffs a few advertisements for other local businesses into you hand. "Thanks", you mutter.

Once inside you realize the hardware store is very big and manually looking for a hammer might take a while. You walk up to the front desk to ask where you can find a hammer but notice the cashier is playing with their phone behind the counter. You try to get their attention but they simply raise their hand and shout "Be with you in a minute". After a short while they get off their phone and finally listen to your question. They then tell you where to find the hammers.

Does this sound like a fast and easy experience?

As silly as this hypothetical trip to the hardware store might be, it's exactly what many current websites are putting their users through. Users - read customers - are coming to your website with a specific goal in mind; checking out a product, consuming information or just satisfying their curiosity. Stop putting so many blockers and excessive bloat in front of them.

Data doesn't lie

If my terrible analogy wasn't enough to convince you to implement better performance on your website, then maybe some "BIG DATA" will.

Amazon (PowerPoint, slide #15): 100 ms of latency resulted in 1% less sales.
Google (video): 500 ms caused a 20% drop in traffic.
Walmart (slide #46): a 100 ms improvement brought up to 1% incremental revenue
Mozilla: Shaving 2.2 seconds off page load time increased downloads by 15.4%
Yahoo: 400 ms resulted in a 5 to 9% drop in traffic

All data taken from [instant.page](https://instant.page) (which I am a huge fan of ♥)

The fact something as small as 100 ms can have such a profound impact on your bottom-line should be eye-opening. You're leaving money of the table by not tackling even the low-hanging, easy performance wins. You need to start valuing your users' time and stop serving them excessive garbage they never asked for.

Small and easy wins

Not all of these suggestions can work for every project (due to restrictions, brand guidelines, required marketing targets, etc.) but for most developers/designers they should be easy to implement: (in no particular order of importance)

Reduce the number of web requests +
- HTTP Requests
+
Use web-safe fonts when available or if using custom fonts utilize the font-display property +
- CSS Font Stack
- Font Display for the Masses
+
Make proper use of critical CSS +
- How to Use Critical CSS
- Automatically generate CSS based on "above the fold": criticalCSS
+
Process all media (images / videos) through 3rd party tools +
- Cloudinary
- Kraken.io
- Piio
- Sidenote: this blog uses the jekyll-cloudinary plugin to automatically process images
+
Use "just-in-time" preloading (highly recommended for improved UX) +
- Instant Page
+
Avoid using heavy tech-stacks whenever possible +
- Unless it is a critical use-case, users should not have to process or download extra resources
- This also includes remove ads, pop-ups, 3rd party sign-up prompts, cookie notifications, over-the-top element animations, and all other garbage. This impacts UX performance, which is just as crucial as website loading speed
+

No need to be extreme

These quick "guidelines" are just a solid jumping-off point when tackling new projects or re-working current websites. There isn't some agreed upon golden standard when it comes to web performance, but I find these rules work as a great place to start. Hopefully it can help others as well.

Text Align: Justify

2019-05-22T10:00:00Z

Text Align: Justify

2019-05-22

The text-align property is fairly well known in the world of CSS, even among those just starting out with the language. Values such as center, left and right are used often with this property, but a more forgotten option is justify.

What does justify do?

The MDN web docs define the justify value for text-align as such:

+
The inline contents are justified. Text should be spaced to line up its left and right edges to the left and right edges of the line box, except for the last line.
+ MDN web docs +

See it in action

Live CodePen Example

When should I use this?

It isn't always appropriate to use justify in most instances, although it becomes very useful for long form articles or blog posts. Since it takes a heavy influence from original print book layouts, the justify value helps improve readability for larger chunks of content.

Fair warning: it is best to remove any justify values when targeting smaller screen sizes. Mobile devices and/or tablets tend to be small enough to break up the content already. This CSS value is better suited for larger viewports.

Browser support

The good news is that all major browsers support the justify value for the text-align CSS property. So have some worry-free fun with it!

The Wonders of Text Ellipsis

2016-11-15T10:00:00Z

The Wonders of Text Ellipsis

2016-11-15

A common issue when working with constrained UI elements is text overflowing outside of it's parent or breaking into addition lines (thus breaking the layout).

This is most commonly seen with the direct and placeholder values for input fields on form elements. For example, the following input placeholder will be cutoff from the user's view:

CodePen live example

Luckily, 3 simple CSS parameters can fix this.

input::placeholder {
+    overflow: hidden;
+    text-overflow: ellipsis;
+    white-space: nowrap;
+}
+

This allows the user to understand there is more content cut out from their current view. It's not ideal to ever have content overflowing outside of the parent container, but if you need to the best workaround is to use text-overflow.

Making Tables Responsive With Minimal CSS

2019-06-11T10:00:00Z

Making Tables Responsive With Minimal CSS

2019-06-11

+ Update (Oct 2019): @aardrian wrote a previous post about how changing the display properties on tables can impact screen readers. I highly recommend his excellent article Tables, CSS Display Properties, and ARIA +

I find that the need to create responsive table layouts pops up far more often than most developers would expect. The gut reaction might to be implement some sort of custom grid-system or pull in a pre-built library. Don't do this - just use tables and some simple CSS.

My recent article, Write HTML Like It's 1999, received far more attention than I ever expected on HackerNews. With this attention came a few comments mentioning how table elements don't play nice with mobile devices or that it's not possible to have a useable layout on smaller screens. This simply isn't true.

Included below are two separate demos showing how to optimize table HTML for mobile devices using only a minimal amount of CSS. These implementations may not be perfect, but they are far superior to injecting a bunch of custom div elements to look like tables.

Demo 1: Just let them scroll

Okay I will admit, this implementation isn't the greatest but I find it does work well with huge datasets. Simply set a min-width on your parent table element and the browser will just require the user to scroll the contents horizontally.

table {
+    min-width: 800px; /* Set your desired min-width here */
+}
+

Check out the CodePen below to see it in action:

Live CodePen Example

I actually prefer this method because of its simplicity and function. Users on mobile are familiar with scrolling since it is one of the most basic actions required. Seeing a "cut-off" table gives them an instant visual cue that they have the ability to scroll the content.

Demo 2: More flexible than you think

Using something like flexbox tends to work better when you are working with smaller table datasets. All you need to do is add some minor flexbox layout at your targeted mobile screen size.

/* Using 800px as mobile screen in this example */
+@media(max-width: 800px) {
+    /* Hide the table headings */
+    table thead {
+        left: -9999px;
+        position: absolute;
+        visibility: hidden;
+    }
+    table tr {
+        border-bottom: 0;
+        display: flex;
+        flex-direction: row;
+        flex-wrap: wrap;
+        margin-bottom: 40px;
+    }
+    table td {
+        border: 1px solid;
+        margin: 0 -1px -1px 0; /* Removes double-borders */
+        width: 50%;
+    }
+}
+

Check out the CodePen demo

There are some caveats with this approach:

We currently hide the thead row when in mobile view (only visually - screen readers can still scan it)
Some more custom work might be needed depending on how many items per flexbox row makes sense (based on project and dataset)

You could keep the table headings and style them the same as the tbody contents, but I find hiding them a little cleaner. That choice is entirely up to your personal preference. You can also decide to add heading span elements inside the main tbody elements like so:

/* Default span styling - hidden on desktop */
+table td span {
+    background: #eee;
+    color: dimgrey;
+    display: none;
+    font-size: 10px;
+    font-weight: bold;
+    padding: 5px;
+    position: absolute;
+    text-transform: uppercase;
+    top: 0;
+    left: 0;
+}
+
+/* Simple CSS for flexbox table on mobile */
+@media(max-width: 800px) {
+    table thead {
+        left: -9999px;
+        position: absolute;
+        visibility: hidden;
+    }
+    table tr {
+        border-bottom: 0;
+        display: flex;
+        flex-direction: row;
+        flex-wrap: wrap;
+        margin-bottom: 40px;
+    }
+    table td {
+        border: 1px solid;
+        margin: 0 -1px -1px 0;
+        padding-top: 35px; /* additional padding to avoid heading overlap */
+        position: relative;
+        width: 50%;
+    }
+    /* Show the heading span */
+    table td span {
+        display: block;
+    }
+}
+

Live CodePen Example

Updated: As pointed out by user mmoez, it is far less repetitive to use :nth-child pseudo selectors to implement the heading fields on mobile (as outlined in this CSS-Tricks article).

Why should I care to use `table` elements?

Simply put: accessibility and proper semantics.

Why use a screwdriver when you need a hammer? Sure, you can make that screwdriver look and almost work the same as a hammer, but for what purpose? Just use the damn hammer¹.

Have fun making your tables responsive!

¹ I know, this is a terrible analogy...

Tabbed Content Without JavaScript

2019-01-28T10:00:00Z

Tabbed Content Without JavaScript

2019-01-28

Creating tabs is a fairly trivial and common practice in web design, but many times it requires JavaScript to properly implement. Fortunately it is possible to create tabbed content with only using CSS.

Live CodePen Example

Sidenote:

While this method is semantic and accessible, you might consider using a pre-existing plugin for tabbed data.

This component tends to feel a little "stiff" compared to more fleshed out variations available. This pure CSS version is better suited as a fallback for when users have disabled JavaScript.

The HTML

The skeleton for this component is fairly basic - we just need the following structure:

Parent element for each tab item
Default radio input
Label linked to corresponding input
Inner content associated with each tab item

<!-- Simple main container for all elements -->
+<div class="tabs">
+
+    <!-- Parent container holding for individual tab item -->
+    <div class="tab-item">
+
+        <!-- Default radio input -->
+        <input class="tab-input" type="radio" name="tabs" id="tab-1">
+
+        <!-- Label connected to radio input via `id` and `for` attributes -->
+        <label class="tab-label" for="tab-1">Tab 1</label>
+
+        <!-- Full inner content of current tab item -->
+        <div class="tab-content">Content goes here</div>
+
+    </div>
+
+</div>
+

Full HTML for reference:

<div class="tabs">
+
+    <div class="tab-item">
+        <input class="tab-input" type="radio" name="tabs" id="tab-1">
+        <label class="tab-label" for="tab-1">Tab 1</label>
+        <div class="tab-content">Content goes here</div>
+    </div>
+
+    <div class="tab-item">
+        <input class="tab-input" type="radio" name="tabs" id="tab-2">
+        <label class="tab-label" for="tab-2">Tab 2</label>
+        <div class="tab-content">Content goes here</div>
+    </div>
+
+    <div class="tab-item">
+        <input class="tab-input" type="radio" name="tabs" id="tab-3">
+        <label class="tab-label" for="tab-3">Tab 3</label>
+        <div class="tab-content">Content goes here</div>
+    </div>
+
+</div>
+

The CSS

First, we need to set each input, label and inner content into their own parent containers:

/* Main parent that holds all contents */
+.tabs {
+    height: 100%;
+    min-height: 250px;
+    position: relative;
+}
+
+/* Each tab items (includes heading & content) */
+.tab-item {
+    display: inline;
+}
+

Next, we will hide the default radio input and design our labels to resemble a basic web tab element. The z-index property on the label is important for how we will be stacking our content on the z-axis (labels above inner content for example).

/* Hide the default radio inputs */
+.tab-input {
+    position: absolute;
+    visibility: hidden;
+}
+
+/* The main tab headings */
+.tab-label {
+    background: white;
+    box-shadow: inset 0 -4px 4px rgba(0,0,0,0.02);
+    color: lightgrey;
+    cursor: pointer;
+    display: inline-block;
+    font-weight: 600;
+    margin: 0 5px 0 0;
+    padding: 10px 20px;
+    position: relative;
+    text-align: center;
+    z-index: 0;
+}
+

The main inner content of each tab needs to have an absolute position set as it's default, since the one currently selected will switch to relative on mobile (more on that in a moment):

/* The inner tab content */
+.tab-content {
+    background: white;
+    bottom: 0;
+    box-shadow: 0 6px 8px rgba(0,0,0,0.02);
+    left: 0;
+    overflow: scroll;
+    padding: 20px;
+    position: absolute;
+    right: 0;
+    top: 50px;
+    z-index: 0;
+}
+

The final step is just telling the browser to style both the label and inner content of the currently selected radio input:

/* Style the currently selected tab label */
+.tab-input:checked + .tab-label {
+    border: 1px solid #eee;
+    border-bottom: 0;
+    box-shadow: 0 -6px 8px rgba(0,0,0,0.02);
+    color: #268bd2;
+    z-index: 2;
+}
+
+/* Show the currently selected tab content */
+.tab-input:checked ~ .tab-content {
+    border: 1px solid #eee;
+    z-index: 1;
+}
+

It's as simple as that! For reference, here is the entire CSS file for easier access:

/* Main parent that holds all contents */
+.tabs {
+    height: 100%;
+    min-height: 250px;
+    position: relative;
+}
+
+/* Each tab items (includes heading & content) */
+.tab-item {
+    display: inline;
+}
+
+/* Hide the default radio inputs */
+.tab-input {
+    position: absolute;
+    visibility: hidden;
+}
+
+/* The main tab headings */
+.tab-label {
+    background: white;
+    box-shadow: inset 0 -4px 4px rgba(0,0,0,0.02);
+    color: lightgrey;
+    cursor: pointer;
+    display: inline-block;
+    font-weight: 600;
+    margin: 0 5px 0 0;
+    padding: 10px 20px;
+    position: relative;
+    text-align: center;
+    z-index: 0;
+}
+
+/* The inner tab content */
+.tab-content {
+    background: white;
+    bottom: 0;
+    box-shadow: 0 6px 8px rgba(0,0,0,0.02);
+    left: 0;
+    overflow: scroll;
+    padding: 20px;
+    position: absolute;
+    right: 0;
+    top: 50px;
+    z-index: 0;
+}
+
+/* Style the currently selected tab label */
+.tab-input:checked + .tab-label {
+    border: 1px solid #eee;
+    border-bottom: 0;
+    box-shadow: 0 -6px 8px rgba(0,0,0,0.02);
+    color: #268bd2;
+    z-index: 2;
+}
+
+/* Show the currently selected tab content */
+.tab-input:checked ~ .tab-content {
+    border: 1px solid #eee;
+    z-index: 1;
+}
+

Don't forget about mobile

With only a few extra lines of CSS we can ensure that our custom tabs will stack on top of each other and look solid on mobile devices:

@media(max-width:38em) {
+    .tab-label {
+        display: block;
+        width: 100%;
+    }
+    .tab-content {
+        display: none;
+    }
+    .tab-input:checked ~ .tab-content {
+        bottom: auto;
+        display: block;
+        position: relative;
+        top: auto;
+    }
+}
+

One minor caveat

Even though I'm a pretty big fan of implementing tabs this way, there is a small drawback:

The height of the inner content doesn't grow dynamically since it defaults as absolute, so a min-height or height value is required on the parent element. This could become a problem in certain situations where you don't have the luxury of setting a static height.

Other than that, enjoy building some JavaScript-free tabs!

Super Mario Blocks in CSS

2019-02-15T10:00:00Z

Super Mario Blocks in CSS

2019-02-15

Just because we can, let's make a quick demo on how to build interactive elements based off the original Mario punch blocks.

What our final product will look like:

Live CodePen Example

The HTML

The set of Mario blocks doesn't require a huge amount of effort for it's html structure, we only need:

Parent div for each block
Checkbox input
Checkbox label
Inner label divs to represent the block "dots"

Sidenote: This is only how I chose to add the inner dots to the Mario blocks. There are many other ways to create these, so please feel free to implement them however you see fit.

<!-- Main parent block -->
+<div class="mario-block">
+
+    <!-- Checkbox input (disabled by default) -->
+    <input type="checkbox" id="1" disabled>
+
+    <!-- Checkbox label -->
+    <label for="1">
+        <!-- Inner dots for blocks -->
+        <div class="dot"></div>
+        <div class="dot"></div>
+        <div class="dot"></div>
+        <div class="dot"></div>
+    </label>
+
+</div>
+

Now we just add as many default blocks we want, along with the interactive punch block (.mario-block--question):

<div class="mario-block">
+    <input type="checkbox" id="1" disabled>
+    <label for="1">
+        <div class="dot"></div>
+        <div class="dot"></div>
+        <div class="dot"></div>
+        <div class="dot"></div>
+    </label>
+</div>
+
+<div class="mario-block">
+    <input type="checkbox" id="2" disabled>
+    <label for="2">
+        <div class="dot"></div>
+        <div class="dot"></div>
+        <div class="dot"></div>
+        <div class="dot"></div>
+    </label>
+</div>
+
+<div class="mario-block mario-block--question">
+    <input type="checkbox" id="3">
+    <label for="3">
+        <div class="dot"></div>
+        <div class="dot"></div>
+        <div class="dot"></div>
+        <div class="dot"></div>
+        <div class="question-mark"></div>
+    </label>
+</div>
+
+<div class="mario-block">
+    <input type="checkbox" id="4" disabled>
+    <label for="4">
+        <div class="dot"></div>
+        <div class="dot"></div>
+        <div class="dot"></div>
+        <div class="dot"></div>
+    </label>
+</div>
+

The CSS

First we need to remove the default checkbox input styling and place all new styling on it's corresponding label.

/* Mario block parent div */
+.mario-block {
+    display: inline-block;
+    height: 80px;
+    margin-right: -7px; /* Fixes inline-block margin bug */
+    position: relative;
+    width: 80px;
+}
+
+/* Hide default checkbox input */
+.mario-block input {
+    position: absolute;
+    visibility: hidden;
+    z-index: -1;
+}
+

Now to target the label elements found inside the block:

/* Style checkbox label accordingly */
+.mario-block label {
+    background: #F88D2E;
+    border: 4px solid #070000;
+    box-shadow: inset -4px -4px 0 #965117, inset 4px 4px 0 #FAB89B;
+    display: block;
+    height: 100%;
+    position: relative;
+    width: 100%;
+}
+

Next we style our included .dots elements to be placed in the four corners of each block:

.mario-block .dot {
+    background: #070000;
+    height: 5px;
+    position: absolute;
+    width: 5px;
+}
+.mario-block .dot:nth-child(1) {
+    left: 4px;
+    top: 4px;
+}
+.mario-block .dot:nth-child(2) {
+    right: 4px;
+    top: 4px;
+}
+.mario-block .dot:nth-child(3) {
+    bottom: 4px;
+    left: 4px;
+}
+.mario-block .dot:nth-child(4) {
+    bottom: 4px;
+    right: 4px;
+}
+

Punch-able block

Now we need to include the "question mark" SVG and custom CSS for the interactive Mario block. You can download a copy of the custom svg question mark I created.

.mario-block--question label {
+    cursor: pointer;
+}
+.mario-block--question .question-mark {
+    background-image: url('/public/images/mario-block-question-mark.svg');
+    background-position: center;
+    background-repeat: no-repeat;
+    background-size: 40px;
+    bottom: 0;
+    left: 0;
+    position: absolute;
+    right: 0;
+    top: 0;
+    z-index: 1;
+}
+

The last piece

The last item we need to design is the checked state of the interactive question mark block. The extra inner dark dashes will be added as pseudo elements:

/* Mario block in `checked` state */
+.mario-block input:checked + label {
+    background: #885818;
+    box-shadow: inset -4px -4px 0 #68400B, inset 4px 4px 0 #FAB89B;
+}
+
+/* Hide both the default dots and question mark svg on checked */
+.mario-block input:checked + label .dot,
+.mario-block input:checked + label .question-mark {
+    display: none;
+}
+
+/* Shared pseudo element styling */
+.mario-block input:checked + label:before,
+.mario-block input:checked + label:after {
+    content: '';
+    height: 20px;
+    position: absolute;
+    transform: rotate(45deg);
+    width: 20px;
+}
+
+/* Right dash */
+.mario-block input:checked + label:before {
+    border-right: 4px solid #070000;
+    right: 18px;
+    top: 15px;
+    transform: rotate(45deg);
+}
+
+/* Left dash */
+.mario-block input:checked + label:after {
+    border-left: 4px solid #070000;
+    left: 18px;
+    top: 15px;
+    transform: rotate(-45deg);
+}
+

That's it!

Taking it further

As always, you can take this concept and flesh it out even further. I was trying to mimic the "pixel" style of the original Mario games, but you could make the lighting and depth more realistic with some extra subtle gradients or filter properties.

I Want to Suckless and You Can Too

2022-12-23T10:00:00Z

I Want to Suckless and You Can Too

2022-12-23

The Desire to Suckless

While I have been happy with my previous desktop setup using Wayland on Alpine Linux, I just couldn't shake the urge to fully embrace the suckless ecosystem. Although, this meant ditching Wayland and returning to X11, which is apparently the new "cool thing to hate" in Linux land. At least, that's what I've seen online lately.

But I'm getting ahead of myself...

What is Suckless?

I'm not going to spend too much time repeating what you can already read on the suckless.org website itself, but in a nutshell:

Software with a focus on simplicity, clarity, and frugality.
+

The developers also pride themselves on catering to advanced and experienced computer users, which is actually a refreshing take in my opinion. There are enough pre-existing open source solutions for non-technical or average Linux users looking for a desktop system. Having an option that requires users to deep-dive into the code, compile the programs manually, and better understand the software they are running is a welcome addition.

This process of "owing your software" was one of the core concepts that initially grabbed my attention. I've always been mildly mediocre at reading and writing C (ie. enough to be dangerous), so the thought of jumping head first into a system that would require me to better learn that language was tempting[^1]. And that temptation was enough to give it a shot!

Let's Get Started

So I made my decision. I would (at the very least) try switching my daily driver over to a completely "suckless" system. But I was immediately faced with my first obstacle: which distro should I use?

I'm sure many would suggest Gentoo, since it follows the principles of suckless more than any other distribution on the market. But I don't hate myself enough to go down that insane rabbit-hole. I'm hardly advanced enough to take on such a steep challenge, not to mention my plan was to build out a "setup script" so others could roll their own suckless build. Something like that looked daunting under Gentoo. Maybe in the future...

So what's left? Void? Arch? Something fresh, like Metis? I really didn't know the "best" choice. Maybe there were just too many options?

Luckily, I did know of a distro that was my go-to for most projects...

Trying Alpine

Alpine Linux is one of the best distributions available. If you disagree, you clearly haven't achieved galaxy-brain levels of intelligence and I feel sorry for you[^2].

Having just rolled my own installer script for Wayland/Sway on Alpine, I figured why not piggyback off that existing project? Work smart not hard, right? So I started putting together an absolute bare minimum list of requirements I needed to get a proper desktop system running:

working suspend/awake
working audio
working wifi/networking
reduced screen tearing (X11 gave me problems in the past with this)

As you can see, I have very low expectations. But there were issues....

I could not build my blog locally (built via Jekyll) since the sass-embedded dependencies has not been built against musl-libc.
VSCodium would require the extra "bloat" of the flatpak manager (not to mention the spotty support some applications have through flatpak/snap).
The distro/system feels like it was better designed with Wayland in mind. Too often I felt like I was losing an uphill battle wrestling against Alpine.

Getting Sucked into the Void

After mentioning my struggles on Mastodon, some helpful friends suggested taking a look at Void. I always knew of the project but never used it as a "daily driver". Since this was overall one large experiment, I figured I'd give it a shot.

I'm glad I did. Void Linux is pretty great.

The installer seemed more complex than Alpine at first, but I found an excellent walkthrough here (which I was more beginner-friendly than the official docs). Once everything was set, it was time to run my suckless "installer".

Introducing void-suck

If you don't care about the nitty-gritty details, feel free to just jump over to the void-suck repo on scourehut and read through the code yourself. There is nothing groundbreaking here. A huge inspiration came from mad-ara's "void-rice" project on Github - so a big thanks to him for making that project in the first place!

You can find the basic instructions in the README of the project itself, but it pulls in just the required dependencies along with my own custom suckless tools. You can easily swap out these with your own or simply default to the standard ones provided by suckless.org.

Everything should work out of the box, but in case it doesn't please open a ticket or submit a patch. I'm certain I overlooked some items!

Closing Thoughts

We'll see how things go. So far I'm enjoying my time with a much simpler desktop and the "forced" push towards getting better with C is an added bonus. I still love Alpine, but Void is slowly winning me over...

Refs

I find this to be the best way to learn new things. Reading technical books are helpful, but concepts never stick with me unless I am forced to implement them.
This is a joke. Alpine is certainly not for everyone. There are many more "fully featured" distros available and everyone should use what they enjoy! Try not to take my blog posts so seriously...

Launching Sublime Text with dmenu on Alpine Linux

2023-04-13T10:00:00Z

Launching Sublime Text with dmenu on Alpine Linux

2023-04-13

Everyone seems to be running some version of VSCode as their main editor these days. But not me. I find VSCode to be too bloated for my needs - not to mention being built on top of electron instead of native code. I prefer running programs that don't try to devour all of my machine's available memory or spike my CPU.

Note: It's important to remember my personal machine is a ThinkPad X201 with only 6GB of RAM (plan to upgrade to 8GB soon!). Obviously your mileage may vary if you're using a beefier laptop or desktop...
+

In case the title of this post didn't make this obvious, my editor of choice is Sublime Text. It's fast, has a robust plugin ecosystem, and a very friendly community of users. Because of its popularity, troubleshooting any issues you might encounter becomes much easier with the amount of information freely available online.

The only minor downside is that it isn't fully open source. Personally, I think it is well worth buying a license directly from the developers to support their efforts.

If you haven't played around with it yet, I highly recommend giving it a try. At the very least, I guarantee you'll be impressed with the editor's performance and speed! [#1]

One Small Problem...

Sublime is precompiled against glibc and Alpine uses musl. This makes things a little difficult. Luckily we can get around this roadblock by falling back on flatpak (which is unfortunately still locked at version 3 for Sublime).

You'll need to install flatpak, give your current user permission to install flatpak apps, and then install Sublime.

(The following snippets assume you are using doas. If you are using sudo, be sure to swap accordingly)

apk add flatpak
+adduser <YourUsername> flatpak
+flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
+

Congrats. You now have setup flatpak on your machine! Next we install Sublime Text:

flatpak install flathub com.sublimetext.three
+

You could stop now and simply open Sublime anytime by running the following command in your terminal:

flatpak run com.sublimetext.three
+

This works perfectly fine but I find it a little cumbersome. I would much rather open my programs directly through dmenu. Let's set that up.

Creating System Links

doas ln -s ~/.local/share/flatpak/exports/bin/com.sublimetext.three /usr/bin/sublimetext
+

Now that those directories are linked, simply open dmenu and start typing sublimetext. Done and done. No more terminal commands needed to open Sublime!

+1. I am aware that using a terminal-based editor such as vim or emacs would be even *more* efficient. For my own personal use I find more classical "IDE" applications to work best for me. +

Stripe Menu Dropdowns (CSS)

2020-03-31T10:00:00Z

Stripe Menu Dropdowns (CSS)

2020-03-31

In a previous article I wrote, Minimal CSS: Dropdown Menus, I showed how you could create a basic menu dropdown with only 121 bytes of CSS. While this demo is great for simple text-based menu dropdowns, it doesn't show just how complex (in a good way) you can make CSS-only menus. So, let's do just that.

What we want to emulate

I think, like most designers, that the UI and web design work from the Stripe team is pretty fantastic. Their clean approach using subtle animations and minimal elements make for a pleasant experience. Unfortunately, there is one problem with their current dropdown menus on their main website:

They don't work if JavaScript is disabled.

But we can easily fix that. So enough chit-chat, let's rip-off their menu design and recreate it with only CSS!

Original (Stripe Website)

+ +

Stripe's default menu dropdown (using both CSS & JavaScript) (direct link to image)

Our recreation (CodePen Demo)

+ +

Our recreation with pure CSS (zero JavaScript) (direct link to image)

Although our redesign is far from an exact replica (some subtle animations are missing which could always be added) - it's still impressive what you can do with some bare-bones CSS. Just something to keep in mind the next time you decide to reach for a JavaScript library to implement a similar design.

See it live in action

Load in the CodePen below and play around with the menu dropdown. Feel free to re-use, break. share or steal this for any and all purposes. Enjoy!

Live CodePen Example

Yes, I Still Use jQuery

2019-04-15T10:00:00Z

Yes, I Still Use jQuery

2019-04-15

I have seen a handful of condescending comments from front-end developers since the newest build of jQuery (3.4.0) released a couple of days ago. While I understand not all developers share the same work-style or are using the same tech-stack, dismissive comments towards any useful library comes off as entitled or elitist.

"Why would you use jQuery nowadays?"
"People are still developing this library?"
"Why use jQuery when you can use [insert latest trendy web tech here]".

I still use jQuery. Well, I may not use the library for all projects since every project is different - but I certainly don't avoid using it solely because "its jQuery". I've always believed in using the best tools for the job.

Use what works for you

If you produce better work in a shorter amount of time using one of the latest and greatest technologies (React, Vue.js, Angular, etc.) then you should absolutely do so. If another developer can be just as productive building their projects with jQuery, what does it matter in the grand scheme of things?

My thought-process is this: a large percentage of web projects are done for clients not involved in the day-to-day happenings of the developer world. What they want is a solution to a particular problem. Clients don't care how things are done behind the scenes - so long as it is done efficiently and properly.

I tend to follow these principles when working on a project (with shared equal importance):

fast performance
accessible
simple UI
intuitive UX

As long as all of these items are accomplished, I don't care if the project was a direct export from Microsoft Word straight to the web¹. If it works great, then it works great.

So use whatever tools make you a happier developer, as long as your projects don't suffer because of them.

¹This would obviously be terrible for development, but its just an extreme example

Stop Using Sticky Navigation on Mobile

2019-10-06T10:00:00Z

Stop Using Sticky Navigation on Mobile

2019-10-06

Stop styling your web elements to be "sticky" on mobile. This creates a horrible experience for your users and also looks like trash from a UI perspective. Don't style your navigation (or any components for that matter) to be "sticky" on mobile. They create poor experiences for your users and take away valuable screen space.

What do you mean by "sticky"?

The concept of sticky elements include but are not exclusive to:

Navigations that follow users as they scroll
Chatbot prompt bubbles eating up half the bottom of the screen
Banners or modal prompts that pester the user to "sign up, accept cookies" etc.

These are bad and you should feel bad for implementing them. Spacing and layout is a critical part of a product’s design and greatly impacts the experience of its users. Stop screwing it up with ugly sticky elements.

First, let's breakdown "sticky" navigations and why they're terrible. We'll also go over some easy solutions to avoid making these bad design decisions in the first place.

The stalking navigation

When you make a decision to eat away >50px of space at the top of the page for your site's navigation - you're hurting your users. You're also making their time interacting with your website more painful.

"Wait!" I hear sticky-nav defenders exclaim, "this navigation bar makes it so the user can easily interact with the site's pages!"

What absolute rubbish. A user should only see a website's navigation when they need to use it. This isn't rocket science.

Let's a take a look at the problem:

+ +

Fixed navigation: you lose valuable space for an element that might only be used once per visit (direct link to image)

Knowing when to show navigation can be easily solved where the user isn't bogged down with a chunk of their screen permanently taken away, all the while still having access to the navigation. This can be fixed by simply understanding the user context at a given time. See below:

+ +

Static navigation: users can focus on what is important - the content (direct link to image)

Here the navigation flows up with the rest of the page as the user scrolls the main content into view. Don't worry about creating confusion - the user knows the navigation is still at the top of the page because they watched it scroll out of view. This is best paired by having a matching navigation in the footer of the page as well. That way, when the user makes it to the end of a specific view they can change pages right in the "footer". No need to scroll back to the top.

The best of both worlds?

Maybe you want to hide the navigation without losing the flexibility of it always being accessible at the top of the page? This is possible, although I find it still somewhat intrusive on the user. An easy way achieve this is by displaying the navigation when users perform a specific action, such as:

Long or multiple upward swipes on the page
Pull down menu from top of current view (easily shown to user)

+ +

Dynamic navigation: show the user the top navigation when a certain action is performed (direct link to image)

Navigations aren't the only culprits

I wish that navigation items were the only sinners of the "sticky" position on mobile - but they are not alone. A few other problematic components include:

Chatbot or support "bubbles"
"Agree to our cookies" prompts
Time-based pop-up modals

Every time you implement one of these components, somewhere in the world a puppy dies. Seriously - don't be part of the problem and build these things. Push back on "marketing research" or team leads who tell you that this crap works. You're making the mobile web worse for everyone and setting a terrible precedent for future developers.

Stay static, my friends!

Stay Hungry

2018-02-12T10:00:00Z

Stay Hungry

2018-02-12

It can feel daunting in this developer / designer landscape to keep yourself up-to-date with the latest and greatest technologies available. Which new framework should I invest the most time into? Will it even be maintained a couple years down the road? Is it just a fad?

What about programming languages? Should I learn as many as possible or should I become an expert in one specialized area? Should designers code? The list of possible new things you could be learning continues to grow. +This is sarcasm. Please don't take this seriously...

Jumping right in

Want my advice? Pick something and dive head first into it. Don't worry if it's not the most popular programming language or if it's a new design system that isn't gaining much traction. Do you find it interesting? Awesome - that's what matters most. How can you teach yourself something new when you have zero interest in it?

Less talk, more action

So what am I currently doing to keep my mind fresh and thinking outside of my comfort zone?

Teaching myself the R programming language
Deep diving into the ggplot2 package
Developing my first side project website using blogdown and Hugo
Trying out Figma as my exclusive design program for the next few months

Programming your brain to learn something new can be frustrating and pull you out of your comfort zone. Don't let this become stressful - instead use it as inspiration to push yourself through the struggle.

There is no real reason to avoid learning something new outside your current circle of knowledge - only crappy excuses.

Get on it.

Migrating from GitHub to sourcehut

2022-11-14T10:00:00Z

Migrating from GitHub to sourcehut

2022-11-14

It has taken a little bit longer than I anticipated, but I have finally started to port over all my personal open-source projects to sourcehut.org. I'll get into the why and how momentarily, but first let's take a look at all the impacted projects:

Ported Projects

Still WIP

1kb.club
phpetite.org

Some others are being worked on but have less "popularity"

Why?

GitHub has landed itself in some hot water with their recent lawsuit(s) surrounding their Copilot feature. I was already on the fence about keeping GitHub as my main "code forge" after they were scooped up by Microsoft, who then killed off Atom and then started collecting telemetry data through VSCode. This seemed like a good excuse as any to finally leave the platform. The straw, if you will.

>> Sourcehut has entered the chat <<

We, as designers and developers, shouldn't be supporting crap like this. I would much rather put my money where my mouth is and directly support a truly transparent alternative^1]. Although I might only be paying for the Typical Hacker tier on [sourcehut, I like to think that every little bit helps the platform. Even if you choose a different code forge, please consider donating to support independent alternatives!

Git Email? Jump into the Deep End

One aspect of sourcehut that initially scared me off was the lack of a proper "PR-flow", web UI-based system[^2]. Instead, reporting bugs, creating tickets, and submitting PATCHES are generally done through regular, plain-text email.

In the end, I'm glad I stuck it out. I'm still pretty slow with this new workflow (so please be patient with me if you submit a patch on a project!) but it actually seems cleaner. The phrase "streamlined" is what comes to mind.

And really, if you think about it, at one point in time GitHub's PR system would have been "new" for most users. Everything takes time to learn. This workflow is no different.

Drew (creator of sourcehut) actually put together an extremely helpful guide on getting setup with git send-email. I still reference back to this if/when I need to get up-and-running on a new machine. I highly recommend checking it out.

Wrapping Up

That's it really. I'm still in the process of moving over some projects, archiving original GitHub repos and becoming more adapted to the whole sourcehut "workflow". I'm enjoying it and it feels good to pay for something that is not only useful but open source at its core.

Will I be deleting my GitHub profile outright? Maybe. I'm not sure. For now the first step is removing any dependence I once had on that platform. Baby steps.

For those interested, my sourcehut public profile is: https://sr.ht/~bt/. Maybe I'll see you on the other side ;)

Refs

I keep an up-to-date document of all the open source software/communities I pay for on my "Uses" page for reference.
Put your pitchforks and torches away - I'm aware that a web-facing UI exists on sourcehut as well!

Never Do Spec Work for Free

2022-11-07T10:00:00Z

Never Do Spec Work for Free

2022-11-07

Your time is valuable and shouldn't be taken for granted. Let me say that again for the people in the back: your time is valuable and shouldn't be taken for granted. Time is the most precious commodity we have as human beings, so never waste that time on free "spec" work. It's never worth it. Ever.

I've had up-and-coming designers reach out to me multiple times and ask specifically about completing spec work or "challenges" presented by hiring staff. My first question is normally, "Are they paying you for it?". If the answer is no, then I tell these individuals to move on. The company and the role is not worth their time.

There are plenty of companies that respect the hiring process and will pay you for your time. Good on them. These are the places that you should be striving to work with/for. Avoid those who don't. If they don't respect your time before they even consider hiring you, what makes you think they'll respect it once you're on the team?

Never?

Never. If a company or individual is considering you for a role, so much so that they are interested in seeing how you would work with them directly, they need to pay you. These companies (large or small) would laugh at the concept of doing something free for you. Why is their time respected but yours isn't?

Asking for Free Spec Work? Stop.

If you're implementing these practices at your place of business, then you're part of the problem. Maybe you need a more robust candidate review process, so those interviewees you are willing to pay for "code challenges" or spec work are more finely tuned. Maybe you just need to re-evaluate how much you value the workers you're looking to hire.

The software world is a strange beast where we have adapted this "work for free before we think about paying you". Imagine implementing this system for something like a plumber?

"Hey, could you install this new sink for me - for free? Then, if I think you did a good job, I can start to pay you for other work around my house?"

Good luck with that.

Be Confident

This post is mostly targeted to new designers and developers, but can certainly still apply to those with years of experience under their belts. I've been guilty of doing free spec work years ago when I was first starting out (my grey hairs are showing...) and it never paid off. Literally and figuratively. Learn through my own mistakes and just walk away from people asking you to work for free.

No matter what you think about your skill level or real-world experience, you need to have at least a bare-minimum standard for yourself:

Never work for free -- Unless you choose to work for free on something like a personal or open source project. That is obviously a different situation!

SOMA Inspired Terminal Display with CSS

2021-05-29T10:00:00Z

SOMA Inspired Terminal Display with CSS

2021-05-29

A few years back I played (and loved) SOMA, a first-person sci-fi horror-adventure game. The story was intriguing and the developers nailed the overall atmosphere of Pathos-II. Though both those aspects were great, what I found the most enjoyable were the interactive computers and displays found sprinkled throughout the world.

Three years ago I wanted to see if I could recreate one of those terminal displays with HTML & CSS. And I did just that.

So, why am I writing about this three years later? Well, I never did a proper write-up explaining how I achieved it. I'm sure someone out there in the wild west of the web could get some value out of this tutorial, right? I hope so!

The Live Demo

Live CodePen Example

The HTML

Nothing fancy going on here - just some simple div elements holding a few paragraphs and spans:

<div class="outer-frame">
+    <div class="screen">
+        <div class="screen-guts">
+            <h2>Key Control</h2>
+            <p><span>Panel Chip</span> (Connector)</p>
+            <p class="column">
+                Security Keys: 023-027<br>C819738-23
+                <br>
+                <span class="error">Error: Key Expired</span>
+                <br>
+                <em>Please update...</em>
+            </p>
+            <p>
+                <span>Permission</span>
+                <br>
+                Standard ThetaCipher
+                <br>
+                <span>Secop-Jstrohweier</span>
+            </p>
+            <button class="update-button">Update Chip</button>
+        </div>
+        <div class="bottom-controls">
+            <button class="back-button">Back 背部</button>
+        </div>
+    </div>
+</div>
+

The CSS

Let's just dump all the CSS right here (don't worry, it looks far more complicated than it really is):

@import url('https://opentype.netlify.com/sansation/index.css');
+
+* {
+    box-sizing: border-box;
+}
+
+body {
+    background: #333;
+    font-family: "Sansation", sans-serif;
+    padding: 3rem 0;
+}
+
+button {
+    appearance: none;
+    border: 0;
+    cursor: pointer;
+    font-family: "Inconsolata", "Consolas", mono;
+    font-size: 18px;
+    transition: 0.3s ease all;
+}
+
+.outer-frame,
+.screen {
+    display: block;
+    margin: 0 auto;
+    position: relative;
+}
+
+.outer-frame {
+    background: #ccc url("https://preview.ibb.co/iS9nz7/screen_grunge.webp") no-repeat center;
+    background-size: cover;
+    border-radius: 5px;
+    box-shadow: 0 5px 20px rgba(0,0,0,0.6);
+    height: 560px;
+    width: 750px;
+}
+.outer-frame:before {
+    background: rgba(0,0,0,0.3);
+    border-radius: 5px;
+    box-shadow: inset 5px 5px 10px rgba(0,0,0,0.4), 1px 1px 1px rgba(255,255,255,0.3);
+    content: '';
+    height: 538px;
+    left: 15px;
+    position: absolute;
+    top: 11px;
+    width: 720px;
+}
+
+.screen {
+    background: #000 url("https://image.ibb.co/gOqSz7/screen_dust.webp") no-repeat center;
+    background-size: cover;
+    border-radius: 5px;
+    height: 450px;
+    left: 75px;
+    padding: 60px;
+    position: absolute;
+    top: 55px;
+    width: 600px;
+}
+.screen:after {
+    background: url("https://s13.postimg.org/85ryuy1o7/dust.webp") no-repeat center;
+    background-size: cover;
+    border-radius: 5px;
+    box-shadow: inset 0 0 20px rgba(0,0,0,0.5), inset 5px 5px 10px rgba(0,0,0,0.4), 1px 1px 1px rgba(255,255,255,0.3);
+    content: '';
+    height: 100%;
+    left: 0;
+    opacity: 0.8;
+    pointer-events: none;
+    position: absolute;
+    top: 0;
+    width: 100%;
+    z-index: 2;
+}
+
+.screen-guts {
+    border-bottom: 2px solid #8fc8c8;
+    border-top: 2px solid #8fc8c8;
+    height: calc(100% - 50px);
+    position: relative;
+    width: 100%;
+    z-index: 0;
+}
+.screen-guts:after {
+    border: 2px solid #8fc8c8;
+    color: #8fc8c8;
+    content: '键';
+    padding: 5px 8px;
+    position: absolute;
+    right: 0;
+    top: 5px;
+}
+.screen-guts h2 {
+    background: #8fc8c8;
+    color: #fff;
+    display: inline-block;
+    font-size: 24px;
+    margin: 0 0 30px 0;
+    padding: 10px;
+}
+.screen-guts p {
+    color: #8fc8c8;
+    font-size: 18px;
+    margin: 0 0 30px 0;
+}
+.screen-guts p.column {
+    column-width: 200px;
+}
+.screen-guts p span {
+    text-transform: uppercase;
+}
+.screen-guts p span.error {
+    color: #f37c56;
+}
+.screen-guts p span em {
+    text-transform: none;
+}
+.screen-guts button.update-button {
+    background: #889314;
+    bottom: 10px;
+    color: #fff;
+    padding: 15px 20px;
+    position: absolute;
+    right: 0;
+}
+.screen-guts button.update-button:hover {
+    background: #515905;
+}
+
+.bottom-controls {
+    background: #8fc8c8;
+    border-radius: 0 0 5px 5px;
+    bottom: 0;
+    display: flex;
+    left: 0;
+    height: 50px;
+    padding: 5px;
+    position: absolute;
+    width: 100%;
+}
+.bottom-controls button.back-button {
+    background: rgba(0,0,0,0.2);
+    color: #fff;
+    line-height: 20px;
+    padding: 8px 20px;
+    text-transform: uppercase;
+}
+.bottom-controls button.back-button:hover {
+    background: rgba(0,0,0,0.6);
+}
+

The overall styling is fairly simple (which is great for browser support) with only a couple pseudo elements. It's important to include the custom Sansation typeface, since this is what the game uses for most UI elements and terminals. (I'm loading in this font via my OpenType side project)

The most important properties that truly bring this design together are those associated with the .outer-frame and .screen pseudo elements. Both of these elements use custom background-images that give a little more depth and life to the terminal - in this case fingerprints, dust and smudges.

Feel free to swap these image textures out with your own and alter the terminal as you see fit!

Embracing Slow Tech

2022-11-22T10:00:00Z

Embracing Slow Tech

2022-11-22

I'm writing this post on my "new" X260 ThinkPad running Garuda Linux through Wayland/Sway and it is going well so far. Setting things up was much easier than I initially expected. There were only a few minor tweaks I had to make, such as setting vim as the default EDITOR and installing a small collection of applications (Bitwarden, qutebrowser etc).

I ran into some headaches with generating proper SSH keys but that was solved by calling in ssh-agent whenever launching a new instance of Alacritty. This could certainly be cleaned up further, but for now everything works fine. (A more detailed post about this X260 is in the works!)

"Okay", I hear you say, "But what does this have to do with slow tech?"

Good question! Let me explain.

Purposely Unplugged

For the longest time I have had some form of "smart" device on my persons while performing tasks away from my main computer. Whether that was grocery shopping, playing with the kids in the backyard, going on road trips - you name it. This was never a bad thing or something I actively looked to change. In fact, I hardly used these devices to connect much to the internet anyway[^1]. But I did notice that I would check things like Mastodon or my email every so often.

What I started to realize was that I was checking these "online" items out of pure habit. I hardly ever responded to any email on my iPhone (it doesn't help that Apple Mail on iOS is horrendous for plain text emails) and engaging in Mastodon, while fun, was certainly not a priority while out of the office. My attitude towards being "always online" started to shift towards being what I call purposely unplugged. I decided to make a personal change towards my online access:

If something is important, then I will take the time to complete that task at my office computer. I do not need to be "always online".
+

It really makes you wonder how people back in the late 90s or early 2000s ever managed their lives without being connected online 24/7. I certainly remember a time where you booted up a family computer to browse the internet, respond to emails, and complete work items. When you were done - you were done. You shutdown the machine and went about your life. "I'll check back later tonight before bed" or "Hopefully there will be an email response by tomorrow morning" was the normal thought process after logging off. Now there is no "logging off". It's just switching devices. I don't think it is healthy and really who benefits? Certainly not the individual.

Hardware (computers specifically in this case) serve a purpose. They are meant to serve the individual using them. When did we cross-over into a world where we seem to be serving our devices? You are not important enough to be "available online" all the time. Sorry, but it's true.

Mobile Sucks Anyway

Browsing the web is an absolute shitshow on mobile devices. Every service and their grandma begs you to install their native app. Adblockers are pretty much non-existent, which makes the modern web almost intolerable to visit. Then you have the issue of walled gardens, security breaches, planned EOL for perfectly functional hardware, increased e-waste - the list goes on.

Functional computing and online interactions have already been perfected. It's called a computer[^3]. Computers (desktops and laptops) give us the ability to control our devices at the OS-level, granting us incredible freedom to tweak things to our individual preferences. Unless you are technical enough to fiddle around with "beta" mobile Linux devices, the majority of users are stuck with what they are given. And it isn't much.

The corporate push to move everyone over to "mobile computing" is no accident. The ability to ban certain apps, push ads to users, collect customer details, and harvest user data is more than enough motivation for companies to usher in a future of "mobile" computing.

Not to mention cost. New, top-of-the-line mobile devices sell for the same, if not more, than a standard laptop or desktop. You give up flexibility, customization and freedom for what exactly? A really good camera? Built-in GPS navigation?

Get a real camera and grab a standard GPS. I'm serious. If that sounds ridiculous than you probably never really needed those things in the first place. Use the proper tool for the job. Smushing everything into one, locked-down device is a recipe for disaster.

Overall - just use a real computer.

Don't Flip-Out

So, with all of that in mind, I swapped out my iPhone SE (2020) smart phone for the ZTE Cymbal 2 "dumb" flip phone.

The screen is extremely small with low resolution. The camera is absolute garbage. Writing text messages requires use (and knowledge) of the T9 composer[^2]. Most modern applications besides email or the photo gallery are non-existent.

But I absolutely love it.

It's a phone. It makes phone calls and allows me to send texts. Texts themselves are a little more time consuming, which forces me to be more concise in my writing. Anything that requires great detail should probably be an email - which is what my computer is for. What else do I need? If I ever drop it and smash into a million pieces I can replace it for <$50. I have the ability to replace the battery - not to mention battery life is measured in days not hours. It's rugged, so I don't need to be so delicate with it or slap some huge protective case on it.

It does its job. No more, no less.

"Good for You"

I know that some of you reading this might think that this workflow is fine for me but would never be suitable for your needs. Maybe that's true, but I'd probably disagree. I think people have just been conditioned to believe that most day-to-day activites would be impossible without a smart device or a connection to the internet. If not, many would at least feel that without such access things would become far too inconvenient. My stance remains: the majority of people do not need constant access to a computer in their pocket.

It's completely fine to enjoy your own setup and device preferences - I'm not trying to convert anyone but instead just describing my own experiences. So please, keep your torches and pitchforks at home.

Thanks for reading.

Refs

It helps that I have pretty much zero active accounts across most "popular" social media platforms.
Some of you readers might not have ever experienced the wonders of T9...
I understand that even smart phones can be classified as "computers". I am using this term in the classical sense.

Converting My X201 ThinkPad into a Slabtop

2023-05-01T10:00:00Z

Converting My X201 ThinkPad into a Slabtop

2023-05-01

I recently wrote about physically disabling the WiFi toggle switch on my X201 which was a fun "hack" to an annoying issue I was running into. Since then, the laptop has been running flawlessly.

The only other minor issue I had was the poor display quality. The screen works perfectly fine but the X201's age prevents it from being the best possible display for day-to-day tasks. Both the resolution and viewing angles are quite poor.

So, what were my options to remedy this problem?

Swap out and upgrade the laptop's display (not many options for this though)
Connect an external display, keyboard, mouse and dock the X201
Something else?

Looking into "Something Else"

I found that the possible replacement screens weren't worth the cost/hassle to swap out. And setting the laptop aside, docked with external peripherals sounded fine in theory - but then I would be missing out on the X201's amazing classic keyboard...

Then I thought to myself, "Why not just remove the display entirely?"

So that's what I did.

+ +

The X201 display (still inside the top lid) disconnected from the body of the laptop.

Removing the entire top lid was easier than I initially thought it would be. The beautiful thing about these older, classic ThinkPads is the ability to completely dissemble them. I won't go into heavy details on how to take one of these machines apart, since great documentation already exists. But once you have the keyboard and hinge screws removed it is essentially as easy as lifting the lid out of the chassis. (After disconnecting the small display connectors, of course)

Ditching Alpine for Debian

I love Alpine Linux. It's normally my go-to distro (paired with dwm) for most of my laptop devices. Unfortunately, I find tiling window managers a slight pain to use on larger, 4K displays. I also wanted this slabtop to "just work", instead of needing to fiddle around with WiFi, xrandr, audio etc. Not to mention that Debian is rock solid stable. Defaulting to the XFCE DE was a no-brainer as well since this device is somewhat old.

+ +

The X201 "slabtop" connected to my 27" 4K monitor via the ThinkPad UltraDock.

Closing Thoughts

This slabtop gives me those old-school "Commodore64" vibes (or more recent devices like the Raspberry Pi 400). This setup certainly isn't for everyone but for my use case it's working well. Traveling with a machine like this might prove a little more challenging - although you could simply pair it with a smaller travel monitor (I'm sure the overall carrying weight would be similar to the standard X201).

If nothing else, it is good to keep this option in mind if you ever break your laptop's display and don't feel like spending the money to fix it. Just grab an external monitor you have laying around and make a slabtop!

Skip to Content Button

2019-03-25T10:00:00Z

Skip to Content Button

2019-03-25

One of the golden rules for testing your website's accessibility is the "keyboard-only" audit. This is where you test navigating through your entire site without the use of a mouse, but instead rely solely on tabbing through your content.

Unfortunately, one item is normally overlooked during this audit - a "skip to content" context button. Including a "skip to content" navigation item in your project is extremely useful because:

speeds up user interaction with the content you want them to see
on subsequent pages the user shouldn't need to tab through the entire navigation each time

The HTML

For the sake of this demo we will assume that we currently have the following navigation setup in our project:

<nav role="navigation">
+    <a href="/">Home</a>
+    <a href="/about">About</a>
+    <a href="/archive">Archive</a>
+    <a href="/atom.xml">RSS</a>
+</nav>
+

Now for the easy part - adding our simple content skip link with it's own custom skip-content class:

<nav role="navigation">
+    <!-- Skip to content button -->
+    <a class="skip-content" href="#main">Skip to Content (Press Enter)</a>
+    <a href="/">Home</a>
+    <a href="/about">About</a>
+    <a href="/archive">Archive</a>
+    <a href="/atom.xml">RSS</a>
+</nav>
+

+ Sidenote: in this demo we are making the assumption that the main content block has an id of "main" associated with it. Hence the skip content button linking to #main. +

The CSS

Our first task is to make sure this new link isn't visible or interactive by default unless the user explicitly tabs through the navigation. We do so by positioning the link outside of the main content view. It is important to use this absolute position style instead of setting the display property to none, since the display property technique will fully remove the element from the DOM (bad accessibility practices).

a.skip-content {
+    background: grey;
+    color: white;
+    left: -9999px;
+    padding: 0.5rem;
+    position: absolute;
+    top: 0;
+}
+

Almost there

Now we just re-position the element when the user focuses on the link with a keyboard tab:

a.skip-content:focus {
+    left: 1rem; /* Whatever desired position */
+}
+

All Done

This is a very basic accessibility win you can implement in your current projects with next to zero effort. Enjoy!

Simple Navigation Setup in Jekyll 3.9.0

2020-09-29T10:00:00Z

Simple Navigation Setup in Jekyll 3.9.0

2020-09-29

I have found that there is a lot of information on the internet in regards to setting up "dynamic" navigation in Jekyll. The problem I've noticed is that a good amount of these implementations are overly complex. Here is the simplest way that I tend to use when building out nav elements in Jekyll (3.9.0 as of this writing).

Creating the Directories & Files

In your Jekyll project, at the top level, you need to create a directory called _data. Inside this folder we will be creating a new file called navigation.yml. The contents of this file will contain all your navigation links and they are rendered like so:

- title: Home
+url: /
+
+- title: Articles
+url: /articles/
+
+- title: About
+url: /about/
+

Dynamically Rendering the Navigation

The next and final step is rendering out the navigation with a simple loop:

{% for item in site.data.navigation %}
+    <li>
+        <a href="{{ item.url }}"><span>{{ item.title }}</span></a>
+    </li>
+{% endfor %}
+

Highlight Current Page

It's also very easy to extend this method to add a CSS class based on whether a user is on the currently selected page or not:

{% for item in site.data.navigation %}
+    <li>
+        {% if item.url == page.url %}
+        <a class="active" href="{{ item.url }}"><span>{{ item.title }}</span></a>
+        {% else %}
+        <a href="{{ item.url }}"><span>{{ item.title }}</span></a>
+        {% endif %}
+    </li>
+{% endfor %}
+

/* Custom styling for active class */
+li a.active { color: red; }
+

Congrats! You now have fully functional, dynamic navigation on your Jekyll site.

Simple Does Not Mean Ugly

2019-03-26T10:00:00Z

Simple Does Not Mean Ugly

2019-03-26

I see new blog posts popping up now and again advocating for designers to keep their products as simple as possible - and I couldn't agree more.

A lot of designers tend to think they need to reinvent the wheel when it comes to UI concepts that are standard defaults and expected by most users. Not only does this add extra work for your design and development cycles, but also increases the potential of frustration for your users when they are using your product.

Your job as a designer is to focus on the user experience journey and understand what those users expect to happen - not what you want to happen. This is a very delicate balance of design “give and take”, hence why simple designs always seem to work best.

But simple does not mean “ugly”.

Ugly Simple

Anyone who has read some of my opinion pieces on here in regards to UI know that I have a profound distaste for the overused “flat design” trend. Many designers consider this trend a clean and “simple” approach to most UI conventions - which is complete nonsense to most professionals in the industry (at least those not drinking the kool-aid).

Using the term “simple” in the context of UI is currently quite damaging to modern application and product development. Designers take these definitions too literally, leading to stripped down interfaces with little to no usability for their end-users.

Cap Watkins wrote a post back in 2014 where he explained his admiration for boring designers and how they tackled design problems using the most boring or “lazy” techniques. While I don’t agree completely with his arguments, nor do I think one should try to attain the status of “boring designer”, I can understand his main sentiment: everyone can appreciate obvious and clever design.

Fixing Simple

I hate when people point out problems without at least attempting to suggest some sort of solution - which is exactly what I’m going to do here (with only a few set examples of course, otherwise the post would become a book). Let’s take a look at the major culprits I find around the web: navigations, buttons and form elements.

1. Hidden Navigations

How many native apps that you use regularly rely on the trusty “hamburger” menu icon navigation system? What about news sites, video streaming services, or blogs? Maybe you’ve implemented this concept in your own projects as well, advocating for it’s “cleaner” approach to navigation.

The hamburger is a great example of “ugly simple”. You are purposely hiding the main structure that allows your users to move around your product freely behind an additional interaction. That is the opposite of simple.

The only time you should be using the “hamburger crutch” as I call it, is for very small screen sizes or when targeting mobile user agents directly. That’s it. If your users are viewing your product on a larger screen, for the love of God, use the space available.

2. Buttons Not Looking Like Buttons

It’s difficult for users to actually do the action you want them to perform when your buttons look like text. I’m not exactly sure why designers have pivoted towards removing all stylings that regular users have come to expect from button elements, but it’s plaguing far too many websites.

Buttons should be eye-catching, colorful, fun to interact with, and support all proper CSS states. Clients and agencies will tend to push for “cleaner” buttons - which most of the time refers to setting the buttons as simple underlined text items. Do not be brainwashed into thinking this is better:

You tell me what looks more interactive...

3. Overriding Form Elements

Designers should rarely rebuild the browser structure for web form elements in their projects. I should clarify - I’m not suggesting that you use the barebones default styles provided by the browser, I’m saying that you shouldn’t hide the elements themselves just to replace them with mimicking components. I find this practice is becoming more and more noticeable with the growing popularity of component-based frameworks. Don’t fall into these bad design habits.

For example, you should leave the following select element as is:

<select>
+    <option>
+</select>
+

Instead of doing something like this:

<select style="display:none;"></select>
+<div class="custom-select-container">
+    <span>Option</span>
+</div>
+

There are cleaner ways to customize web forms with straightforward CSS. Have a look at my own open source project Normform if you’d prefer to just use a lightweight plugin to do this for you. (Shameless plug, I know)

Simple Can Be Good

Having a boring or lazy design thought-process doesn’t mean you should develop ugly UI for the sake of “simple”. Too often that word is associated with “minimalism” or “less content” and that is only half true.

The experience is what needs to be simple for your users - the UI itself should still be beautiful.

Simple Accessibility

2018-09-07T10:00:00Z

Simple Accessibility

2018-09-07

Implementing proper accessibility practices can seem a little daunting at first, but there are a few basic standards you can introduce into your project work-flow that are fairly straightforward:

Basic design

Test that your project has the proper contrast color settings between type, backgrounds, icons etc.
Only use "fancy" grid-ordering for minor layout design - avoid rearranging important content via CSS

Content

Use proper HTML structures (aside, header, main, footer elements as needed)
Make use of the aria-label attribute
Ensure your website/app can be navigated completely (and properly) with only a keyboard

Images

Avoid using CSS backgrounds for content images (should only be used for patterns, layout design etc.)
Ensure proper alt attributes are provided on all images

It isn't much - but follow these basics and you'll be one step closer to providing better accessibility to your users.

Shiny, Animated CSS Buttons

2021-04-27T10:00:00Z

Shiny, Animated CSS Buttons

2021-04-27

Everyone can appreciate fancy, animated buttons - but often times they come with a performance cost: JavaScript. Luckily for us, we can create our very own shiny, animated buttons with pure CSS.

The Demo

Live CodePen Example

The HTML

Nothing fancy going on here, just a set of ahref elements with specific button classes added:

<a href="#" class="button green"><span>Green Button</span></a>
+<a href="#" class="button blue"><span>Blue Button</span></a>
+<a href="#" class="button orange"><span>Orange Button</span></a>
+<a href="#" class="button purple"><span>Purple Button</span></a>
+

The CSS

First we set the default base styling for all the buttons. We also place the inner text into span elements (I will explain why in a little bit):

.button {
+    background: white;
+    border: 1px solid #a5b1c2;
+    border-radius: 6px;
+    box-shadow: 0 4px 8px rgba(0,0,0,0.1);
+    color: #111111;
+    display: inline-block;
+    margin: 1rem auto;
+    min-width: 180px;
+    overflow: hidden;
+    padding: 15px 30px;
+    position: relative;
+    text-align: center;
+    text-decoration: none;
+    transition: .3s ease-in-out all;
+}
+.button span {
+    position: relative;
+    z-index: 2;
+}
+

Now we need to create our shiny element that will pass across the button on hover or focus. For this object we will use the before pseudo element:

.button:before {
+    background: linear-gradient(transparent 0%, rgba(255,255,255,0.6) 50%, transparent 100%);
+    content:'';
+    height: 200%;
+    position: absolute;
+    right: calc(100% + 20px);
+    top: -55%;
+    transform: rotate(-70deg);
+    transition: .6s ease-in-out right;
+    width: 80px;
+    z-index: 0;
+}
+

Next, we tell the before element to swipe across the main .button parent element when the user hovers or focuses on it. Remember placing our inner content into a span element? That insures that our shiny/swipe element doesn't position itself over the text, but instead flows under it:

.button:hover:before {
+    right: -100%;
+}
+/* Extra visual styling for buttons on hover - optional */
+.button:hover, button:focus {
+    box-shadow: 0 8px 12px rgba(0,0,0,0.1), inset 0 10px 30px rgba(255,255,255,0.3), inset 0 2px 2px rgba(255,255,255,0.2);
+    color: white;
+}
+

All that's left is adding some visual flare to each individual button - in this case background-color and border-color:

.button.green:hover, button.green:focus { background: #20bf6b; border-color: #20bf6b; }
+.button.blue:hover, button.blue:focus { background: #0984e3; border-color: #0984e3; }
+.button.orange:hover, button.orange:focus { background: #ff793f; border-color: #ff793f; }
+.button.purple:hover, button.purple:focus { background: #6c5ce7; border-color: #6c5ce7; }
+

Browser Support

These buttons work across all browsers flawlessly. See the details on the caniuse report itself.

The Live CodePen

You can find the live demo embedded at the top of this post, or directly on CodePen here.

This Site is Now a Shinobi Website

2022-05-13T10:00:00Z

This Site is Now a Shinobi Website

2022-05-13

Update 2023: this website is now built with barf

My personal website is now an RSS-focused blog, generated from a collection of plain text files.

But before we get into greater details about the switch, let me first introduce the concept of a "shinobi website".

The Shinobi Website Project

Instead of repeating myself in this post, feel free to read up about the project at the official site:

https://shinobi.bt.ht

To summarize: by using a simple shell script I'm able to render all my plain text files (which is now how I solely write my articles) into a structured RSS 2.0 xml file. Subscribers can now consume my posts directly in their RSS reader of choice without the need to directly visit the article's URL.[^0]

Why the Change?

I'm a hardcore minimalist at heart and have a tendency to make my own personal projects leaner all the time. I also have been trying my best to find the most refined writing workflow to keep myself posting consistently (and hopefully keeping the quality high). My first iteration towards this step was switching over to hand-coding everything via HTML & CSS[^1]. That worked well - for a very brief time.

After recently launching the Shinobi project, I kept toying with the idea of switching my personal website over to use the same format. There was a heavy internal debate about ditching HTML in favour of plain text. What kind of impact would this have on both my site and audience? Would people be pissed about yet another radical change?

After sleeping on it for a couple nights, I decide to say screw it. This is my personal website and it should ultimately reflect who I am and what I prefer. Dwelling too long on the opinion of others (as much as I respect any of you kind enough to follow along) can lead to decisions that negatively impact ones own well being.

So here we are. Blogging in plain text.

Avoiding Link-Rot

I've manually added this blog post to my original feed.xml, in order to help inform those of you following that feed of this change. But this will be the last entry of that feed.

If you decide not to re-sub, I completely understand and thank you for your time! Those of you choosing to still follow along: welcome aboard a new adventure!

As for the older HTML-based articles, no worries. They will remain on this site under the standard blog directory so that old links don't break or cause conflicts. You can find that directory here:

https://tdarb.org/feeds/posts.xml

Tutorials and Demos

I will still be writing up detailed tutorials and interactive demos going forward - no need to worry. My plan is to link directly to a collaborative coding site like CodePen, etc. I haven't decided on the best option yet (want to keep things as easy for my readers as possible) so only time will tell what my decision will be.

Feel free to comment below if you have any suggestions! Preferably one that respects user privacy and advocates for a more open web.

Speaking of Comments...

Since the old commenting system[^2] required me to manually add each comment individually, I assumed I would just do the same here. Then I got a hack-y idea. What if I used a mailing list linked through this website's sourcehut project?

It might not be the most user friendly or sustainable but I think it could be an interesting experiment at the very least!

Now each new article will have a link (which I will generate manually) that users can email directly to in order to share their comments. I have no idea how spam will work with this concept. This whole idea could blow up in my face. Only time will tell.

Closing Thoughts

This workflow is clean and simple. It allows me to open a blank text file and instantly start writing. Once I'm happy with it, I run a simple shell command to update the RSS feed and sync it with my web server. Local testing is dead simple too since everything is set as .txt.

Some may like the concept of reading my new articles in their RSS reader, others might hate it. I've learned over the years that you can't please everyone.

Thanks for taking the time to read my jumbled thoughts.

Refs

Users can of course still visit the individual article .txt files in their browser, if they so wish.
https://tdarb.org/blog/my-static-blog-publishing-setup.html
https://tdarb.org/blog/poormans-comment-system.html

Sharing The Things We Use

2021-07-24T10:00:00Z

Sharing The Things We Use

2021-07-24

I always love stumbling across personal websites that include some form of a "uses" page. A place where the author lists out all the tools they use on a regular basis - whether it be hardware, software or something else entirely. It allows readers to get a slightly more personal peek into the daily work-life of that author and maybe even provides better context for how they work.

Since I realized how much I enjoy reading other people's uses pages, I've decided to finally publish my own! My list of hardware and software is fairly boring and predictable for a designer/developer - but sharing is caring! My hope is that even one personal out in the great-wide web can find something useful (pun intended!) or least inspiring about my personal setup.

Fell free to check it out: The Things I Use

PS. I plan to add a desktop picture of my complete setup once I find the time!

Blogging for 7 Years

2023-06-24T10:00:00Z

Blogging for 7 Years

2023-06-24

My first public article was posted on June 28th 2016. That was seven years ago.

In that time, quite a lot has changed in my life both personally and professionally. So, I figured it would be interesting to reflect on these years and document it for my own personal records. My hope is that this is something I could start doing every 5 or 10 years (if I can keep going that long!). This way, my blog also serves as a "time capsule" or museum of the past...

Fun Facts

This Blog:

I originally started blogging on bradleytaunt.com using WordPress, but since then I have changed both my main domain and blog infrastructure multiple times. At a glance I have used:

Jekyll
Hugo
Blot
Static HTML/CSS
PHPetite
Shinobi
pblog
barf Currently using!

Personal:

As with anyone over time, the personal side of my life has seen the biggest updates:

Married the love of my life (after knowing each other for ~14 years!)
Moved out into rural Ontario for some peace and quiet
Had three wonderful kids with said wife (two boys and a girl)
Started noticing grey sprinkles in my stubble (I guess I can officially call myself a "grey beard"?)

Professionally:

Pivoted heavily into UX research and design for a handful of years (after working mostly with web front-ends)
Recently switched back into a more fullstack development role to challenge myself and learn more

Nothing Special

This post isn't anything ground-breaking but for me it's nice to reflect on the time passed and remember how much can change in such little time. Hopefully I'll be right back here in another 7 years and maybe you'll still be reading along with me!

Setting Up a Free SSL

2018-08-07T10:00:00Z

Setting Up a Free SSL

2018-08-07

I never had to worry about SSL certificates when I originally hosted my blog through Github Pages, but since switching over to Surge.sh I lost my ability to utilize https protocol.

Luckily, Cloudflare offers a very simple way to implement SSL on your website - and it's free!

SSL in 3 easy steps

You will need to have a Cloudflare account - you can setup one here. Be sure to select the 'Free' pricing plan (unless you want some extras features)
Follow the process on updating your nameservers to the proper Cloudflare servers and wait for your domain to update the changes. (This can take up to 24 hours)
From the main Cloudflare dashboard navigate to the Crypto tab. Then under the SSL section, select "Flexible" from the dropdown.

Enjoy your newly secure site

That's it! Give it a bit of time and soon your website will support https and best of all it costs you nothing!

I suggest checking out the other interesting features Cloudflare offers while your playing with the dashboard as well. They have a lot of impressive options that can really improve the overall performance of your site / web app.

Self-Hosting Fathom Analytics with DigitalOcean

2021-02-02T10:00:00Z

Self-Hosting Fathom Analytics with DigitalOcean

2021-02-02

Since my previous post walked through the process of setting up Fathom PRO on Netlify, I figured it made sense to create a similar tutorial for the "Lite" variation, self-hosted on DigitalOcean.

Please note that while I think the PRO version of Fathom Analytics is truly great, for my small, niche blog it seemed overkill compared to self-hosting. Switching over from $14/mo to $5/mo while retaining most of the same functionality was a no-brainer. Choose the option that best suits your needs (or in the case - budget & bandwidth).

With that cleared up - let's get into it!

Prerequisites

One or more website(s) where you would like to include analytics
DigitalOcean account (this link will give you a $100 credit!)
Positive attitude and passion for privacy-respecting analytics!

Create a Droplet

Once your DigitalOcean account is setup, navigate to the Marketplace and search for Fathom Analytics. Then click the Create Fathom Analytics Droplet.

From here you'll be brought to a page that allows you to customize the specifications of your new droplet. If you're a smaller traffic site (personal blog, etc) selecting the $5/month Basic Shared CPU option is your best bet.

+ +

Creating the new droplet (direct link to image)

Select the data-center region based on where most of your traffic originates from. I would suggest enabling IPv6 and setting up your authentication via SSH instead of a regular password system. Adding backups is entirely at your own discretion.

Once you're ready, click Create Droplet.

Enter the Matrix (not really)

Once DigitalOcean finishes spinning up your new droplet, open a terminal and connect to it by entering:

ssh root@YOUR_DROPLET_IP
+

If you setup your login via SSH everything should work as-is. If you went the password route, you'll given a prompt to enter it.

Now that you're connected, Fathom will guide you through a simple configuration setup. It's fairly straightforward and painless. Once complete, move to the next step.

Domains

You'll most likely want to host this instance on your own domain or subdomain - instead of connecting directly via the droplet's IP. Head over to your Networking page in the sidebar of DigitalOcean and add your custom domain.

Then, click on that newly added domain - we need to add some new records. You're going to add two new A records to this domain:

+ + + + + + + + + + + + + + + + + + + +

Type	Hostname	Value
A	@	YOUR_DROPLET_IP
A	www	YOUR_DROPLET_IP

The last thing you need to do is set your nameservers to point to DigitalOcean:

ns1.digitalocean.com
+ns2.digitalocean.com
+ns3.digitalocean.com
+

Give it some time to propagate and you'll be in business!

SSL FTW

There is hardly a good reason not to practice security on the web, so setting up your new analytics to be served over HTTPS is just the smart thing to do. Did I mention that this is completely free as well? See - no excuses.

In order to get a free SSL certificate setup, you'll need to install certbot. While connected to your droplet, enter the following:

sudo apt-get install python-certbot-nginx
+

Once installed, enter the following to setup SSL (remember to swap out the domain with your own):

certbot --nginx -d your-cool-domain.com
+

Follow the steps (it's very quick and easy) and you'll have HTTPS setup in a jiffy!

The Final Lap

The last thing to do is login to your newly self-hosted Fathom instance, add your site you wish to track, grab the generated tracking code and then slap that badboy on whatever pages you need to track!

Congrats! You're now officially running your own set of analytics tools. You should be happy about what you've accomplished and proud for respecting your users' privacy!

What Happened to Self-Hosted Blogs?

2018-10-18T10:00:00Z

What Happened to Self-Hosted Blogs?

2018-10-18

I remember a time on the internet¹ when everyone and their grandmother was running a personal blog. And I mean personal - not hosted on some side platform or a tacked-on addition to the rest of their website.

Nowadays companies and individuals alike use platforms like Medium to host and promote all of their articles, essays and case studies. I understand the draw, and can even list out the positives:

A large community already exists under the Medium brand
It's easy to promote your own work and follow others
The platform is fairly easy to setup and implement

Unfortunately this has had a pretty severe impact on the blogging community as a whole - no one controls their own blogs anymore. I remember when finding a new blog was an interesting and fun experience:

how did they decide to layout the page design?
what typefaces have they decided to use?
what back-end are they using?
how does it look and feel on mobile?

These custom self-hosted blogs inspired other developers and designers to create their own blogs or tweak current ones. In a way it was a small factor in pushing what we could do on the web further and further, as designers engaged in friendly competition trying to one-up each others' creations.

I also believe this inspired people to write better content instead of opting for clickbait garbage in order to get "featured" or boosted promotion on the main blogging platform. But I don't even think that's the worst to come of this mass-migration to a singular blogging platform.

All² blogs look identical now. I'm not sure if that was Medium's intention, but either way I personally think it's horrible. The individual personality of most design and development blogs has been completely stripped away.

Maybe I'm just a salty designer with a narrow-minded, pessimistic view on where our blogging communities seem to be heading - or maybe I just have higher standards.

Refs

¹ the design world of the internet
+² by "All" I mean the majority

Schools Should Be Using Open Source Software

2022-05-30T10:00:00Z

Schools Should Be Using Open Source Software

2022-05-30

I firmly believe that proprietary software has no business in any school environment. Educational institutions lean heavily on Windows systems in the name of "security" or "easier platform management". This approach forces students into using locked-down, closed sourced software applications.

Word, Excel, PowerPoint. Why have these become the "standard" of text manipulation and processing?

Photoshop. Illustrator. Why are these the first applications used for image editing and creation?

Schools should only be allowed to use and teach with open source software. Starting students off down the path of vendor lock-in is only beneficial to the companies building those software systems.

The Internet

I'm an older fart, so my elementary school experience only included computers near the tail-end of mid-school. As such, it was forgivable to have students locked-in to using Internet Explorer (which would have been version 4 or 5 during my time) since there wasn't a great deal of competition.

The major problem is that IE/Edge is still the default and often times ONLY browser available in these classrooms. Again, I believe IT departments use the excuse of "security" to keep students on such dated browsers.

Firefox, anyone? LibreWolf? Pale Moon?

Any of these browsers can be easily managed and secured by school IT departments. It doesn't HAVE to be IE...

Reducing Hardware Cost

By shifting towards a purely "open" software stack, schools then have the ability to purchase older, cheaper hardware. Instead of running bloated spyware (Windows) IT departments could opt to use any one of the lightweight Linux distros available.

This would reduce e-waste, save school districts significant amounts of money (no need to purchase Windows licenses or beefy hardware to be able to even run the operating system) all while still maintaining a high level of user/network security.

Heck, you could even have a fleet of Raspberry Pi devices as your main student "computers". The cost of replacement also becomes less significant (these are children using these devices remember).

Security

I briefly mentioned user and network security above but figured it deserved its own section. A great deal of push-back comes from stubborn IT professionals[^0] determined to keep things running on Windows - since this is mostly what they are familiar with.

My mother-in-law was an "at-risk" educator for most of her career. She explained to me that their IT department did a major switch over to use BRAND NEW Apple laptops for all the students just before her retirement. I can't even begin to imagine the cost associated with this change. Not to mention the cost of repair for any of these devices when (not if) damaged.

Who the hell is making these decisions? Even worse, who is approving them?! The school board had the opportunity to switch away from Windows devices and decided on Apple? Education reform is greatly needed[^1].

What About The "Job Market"

I'm not ignorant to the fact that many businesses in the real world require familiarity with some of these more popular closed source applications (Word, Excel). I don't have a magic solution to instantly convert all applications used by the companies, but beginning the process in the education system is a solid start. Over time, the standard will become these open platforms. The initial change just needs to be made.

It should also be mentioned that these open source applications carry over a lot of similar functionality to their closed-sourced counterparts. So it isn't as if a user with extensive LibreOffice experience would be utterly lost while using Microsoft Word.

Looking Under the Hood

Another bonus in using fully open source software is the ability for the students to deep dive into the code itself. This can be a great resource for early programming fundamentals and beginner coding classes. Why not dissect the very program used in your other classes? Here's an example of a possible class project: students could build out their own plugins or extensions for an existing application!

Suggested Alternatives

So what are these "open source" alternatives? Check out my simple suggestions below:

MS Office Suite ==> LibreOffice Suite[^2]

Photoshop ==> GIMP

Illustrator ==> Inkscape

IE/Edge ==> Firefox[^3]

Coding IDE (optional) ===> vim

You could easily expand upon these options, but for most elementary school task these are more than enough.

Refs

Not all IT workers in the school system fall into this category. But most of the underlining structure prevents them from changing much.
At least in my country of Canada. I can't speak for others.
groff would be my personal suggestion instead, since it helps introduce children into the structure of basic file formatting and "programming". I'll go into greater details about this in another post.
As mentioned in the beginning of the post, I'd even suggest forks of Firefox -> LibreWolf or Pale Moon (if possible)

Enabling Safari Extensions with the macOS Catalina Patcher

2021-09-23T10:00:00Z

Enabling Safari Extensions with the macOS Catalina Patcher

2021-09-23

I have an old 2011 MacBook Air that is running the latest version of macOS Catalina thanks to the very wonderful Catalina Patcher by dosdude1. This project has made it possible for me to run and test some of the latest software from Apple - namely Safari 15.

I ran into a small bug early on though – Safari extensions couldn’t be activated via the preferences menu. Luckily I discovered a very simple fix. My hope is this might help others (as small of a demographic that might be) who run into the same issue with the Catalina Patcher.

Close/Quit Safari completely
Open the Finder and use the shortcut ⌘ Shift G
Paste the following to navigate to the proper folder: ~/Library/Containers/com.apple.Safari/Data/Library/Safari/AppExtensions
Open the Extensions.plist in your favourite text editor (I’m a big fan of Panic's Nova)
Below each extensions <dict> tag, add the following: <key>Enabled</key><true/>
Save the file and relaunch Safari

Reference of what it should look like (AdBlock for this example):

<key>org.adblockplus...</key>
+    <dict>
+        <key>AddedDate</key>
+        <date>2021-09-23T14:00:47Z</date>
+        <key>Enabled</key>
+        <true/>
+    <key>WebsiteAccess</key>
+    <dict>
+        <key>Allowed Domains</key>
+        <array/>
+        <key>Has Injected Content</key>
+        <true/>
+        <key>Level</key>
+        <string>All</string>
+        </dict>
+    </dict>
+

After following those simple steps you should have working extensions in Safari. Have fun on your old, "unsupported" Apple devices!

Dear Apple, Please Fix Safari's Default Dark Mode Link Color

2022-04-18T10:00:00Z

Dear Apple, Please Fix Safari's Default Dark Mode Link Color

2022-04-18

Supporting dark mode on the modern web falls under the realm of accessibility and should not be ignored. It is important and helps keep the visual flow of your content to match that of your users' operating system UI. Not to mention, it's easy to implement and keep consistent across browsers.

Support Dark Mode with Zero CSS

A common practice is to include a @media query via CSS to target styling changes based on whether dark-mode is active. I tend to believe this is overkill for basic websites. Many developers aren't aware of the HTML color-scheme parameter. (This website itself is using it in place of CSS media queries)

HTML "color-scheme"

Adding the following meta tag inside your document's head element, you can enable dark mode instantly with zero configuration:

<meta name="color-scheme" content="dark light" />
+

There are minor caveats:

You should not be specifying any background styling to your body or html elements
You should be not specifying any color styling across any of your readable content (paragraphs, headings, lists, blockquotes)

That's it! In case you were curious, all major browsers support this color scheme meta tag: https://caniuse.com/mdn-htmlelementsmetanamecolor-scheme

But Wait, What's This About Safari?

Even though by adding the color-scheme meta tag we get ourselves good dark mode support across all browsers - Safari has one big oversight: link color. Take a look at the comparison screenshots below (based on one of my older articles). The first one is taken in Firefox, the second in Safari:

+ +

Firefox's default dark mode link color

+ +

Safari's default dark mode link color - yuck!

Luckily for us there is a simple solution using minimal amounts of CSS[^1]:

@supports (color-scheme: dark light) {
+    @media screen and (prefers-color-scheme: dark) {
+        a:link {color: #9e9eff;}
+        a:visited {color: #d0adf0;}
+        a:active {color: red;}
+    }
+}
+

We are brute-forcing Safari to implement the same color HEX codes used by both Firefox and Chrome browsers. How a horrible accessibility oversight could happen within a company as large as Apple is astounding...

Apple: Fix Your Browser's Dark Mode

My hope if that even one Safari design or development team member stumbles across this article and raises this ticket to the rest of the team[^2]. It's an unbelievably easy fix and would save developers the headache of overriding these things ourselves.

Thanks for reading and happy dark mode to you all!

Refs

Special thanks to Seirdy for suggesting the use of :link and :active support. I recommend you check out his take on dark mode / theme support.
This has an open ticket through Webkit Bugzilla

Installing Ruby with RVM on Alpine Linux

2023-03-16T10:00:00Z

Installing Ruby with RVM on Alpine Linux

2023-03-16

For some on-going projects I need to switch to different versions of ruby. Although there exist many step-by-step instructions on installing and configuring rvm for most Linux distros, there aren't many focused on Alpine "daily drivers".

So this post is more or less a helpful document for my future self. If it happens to help others then that's an added bonus!

Simple Setup

Make sure you have the basic packages first:

apk update
+apk add curl gcc gnupg gpg dirmngr procps musl-dev linux-headers zlib zlib-dev openssl openssl-dev libssl1.1
+

Next download the latest stable version of rvm from Github, unpack it, place it in the proper user directory (~/.rvm) and install any required libs:

curl -sSL https://github.com/rvm/rvm/tarball/stable -o rvm-stable.tar.gz
+echo 'export rvm_prefix="$HOME"' > ~/.rvmrc
+echo 'export rvm_path="$HOME/.rvm"' >> ~/.rvmrc
+mkdir rvm && cd rvm
+tar --strip-components=1 -xzf ../rvm-stable.tar.gz
+./install --auto-dotfiles --autolibs=0
+

Now we can remove everything and properly link to rvm:

cd ../ && rm -rf rvm-stable stable.tar.gz rvm
+source ~/.rvm/scripts/rvm
+

Now you can freely install any version of Ruby that you desire!

rvm install ruby-X.X.X
+

RSS Hacks With XSLT

2022-05-23T10:00:00Z

RSS Hacks With XSLT

2022-05-23

In my spare time I've been further tinkering (hopefully for the better) with my humble Shinobi Website[^0] script. The most recent update in patch-1 came with a solid amount of QoL improvements. If you're interested, I wrote about it on the official Shinobi blog[^1].

The next feature I wanted to tackle was designing a custom layout for the XML files directly in the browser. I was greatly inspired to create something similar to Len Falken's main directory listing[^2], since that blog was one of the original inspirations for Shinobi. I'm not able to copy what's there though, since our feed builds are quite a bit different.

I then proceeded to fall down the XSLT rabbit hole.

It Never Works the First Time, Does It?

Since the shinobi script generates valid RSS code by default, I didn't want to mess around too much via XSLT and risk breaking validation. I also wanted to keep the "plain text" look-and-feel for consistency with the rest of the site, even though the XSLT template would render into standard HTML. Minor CSS styling and placing the content directly inside pre tags solved these issues.

My first attempt was to use the available sort parameter (in XSL version 1.1+) targeting the dc:date type linked to the pubDate element:

<xsl:sort select="pubDate" data-type="dc:date" order="descending"/>
+<!-- each individual post's content here -->
+

This did not work as intended. RSS 2.0 requires that the pubDate content is set to comply with the RFC-822 date-time[^3], which shinobi handles perfectly fine. The issue came from the XSL sort parameter not honoring this setting across all dates. My best guess is that it struggles to properly organize posts from their "month" parameter, so it sets the posts in order of date in what I refer to as "monthly sections".

If anyone knows why this failed to consistently order the posts via pubDate, please let me know using the comment link below. I'm far from an XSLT expert and might have overlooked something painfully obvious!

RSS Hack: Categories

After spending far too much time reading over documentation, official manual pages and Stack Overflow comments I gave up on the dc:date sort. I realized I could sort the posts much easier if they were converted into a format similar to ISO 8601. But pubDate is required to be in RFC-822, so I couldn't alter that in the final XML file.

Then I remembered the category tag which shinobi does not utilize by default.

First I needed to convert the RFC-822 formatted date (found on the first line of all blog post text files) and render it inside a category tag. This was simple enough:

$(date -j -f "%a, %d %b %Y" "$(head -n 1 $file)" +"%Y/%m/%d/%u")
+

In a nutshell, this converts the RFC-822 date into the format "2022/05/24/2". Simple numbers that can be sorted much easier by XSL. Now all that was needed was setting to sort parameter properly:

<xsl:sort select="category" order="descending"/>
+

Everything worked perfectly and the RSS was still valid!

Patch-2 Pending

I've ported these changes over to this blog to perform some "in the wild" testing. You can see the custom feed list in your supported browser by visiting:

https://pblog.bt.ht/feed.xml

As for the shinobi project itself, I have not merged these updates into the main master branch (at the time of publishing this article). They can be found sitting on patch-2[^4]. My plan is to get this merged ASAP once a little more real-world testing is finished and I can include a better "setup/install" section for newcomers.

Shinobi Updates

If you're interested in more updates and details about the shinobi project itself, feel free to sub to that specific feed below. This post was more focused on hacking RSS parameters that happened to involve shinobi, but in the future all updates specific to the project will be posted there:

https://shinobi.bt.ht/feed.xml

Refs

https://shinobi.website/
https://shinobi.website/posts/patch-1.txt
http://len.falken.directory/
https://validator.w3.org/feed/docs/error/InvalidRFC2822Date.html
https://git.sr.ht/~tdarb/shinobi-script/tree/patch-2

Clickable Links Inside XML

2022-06-20T10:00:00Z

Clickable Links Inside XML

2022-06-20

With the recent patch to the Shinobi Website project, I thought it would be best to share my experience implementing clickable links inside a rendered XML RSS file directly through a browser. This is made possible thanks to the awesome power of XSL formatting.

Before we begin, it should be noted that both Safari for macOS and all browsers on iOS do NOT support the ability to render XML files. Instead you are required to download the feeds as static files to your system. Major bummmer. Hopefully this will be fixed in the near future.

The Code

Rendering your entry links as interactive URLs is fairly intuitive. You just need to:

Tell the file which tag it needs to render as the "a:link" element
Set the inner child attribute to "href"
Set the value of that attribute to use the entry's link parameter

<xsl:element name="a">
+    <xsl:attribute name="href">
+        <xsl:value-of select="link"/>
+    </xsl:attribute>
+    <pre><xsl:value-of select="title"/></pre>
+</xsl:element>
+

In the instance above I am rendering the entry title as a clickable element which will direct users to the specific entry URL. You could simply render the full entry link URL text as the interactive link if you prefer. Something like:

<xsl:element name="a">
+    <xsl:attribute name="href">
+        <xsl:value-of select="link"/>
+    </xsl:attribute>
+    <pre><xsl:value-of select="link"/></pre>
+</xsl:element>
+

Live Example

In a supported browser, you can see the code in action here: https://pblog.bt.ht/feed.xml

That's really all there is to it.

Refs

https://shinobi.bt.ht/posts/patch-3.txt

Quick and Dirty Theme Switcher

2020-06-04T10:00:00Z

Quick and Dirty Theme Switcher

2020-06-04

Update: This article is no longer relevant since my blog design has changed. I'm keeping this post up since it will still be useful for those wanting to implement a theme switcher on their own site.

I recently added a fairly straightforward color scheme (theme) switcher to my personal website. You can toggle this simple color switcher in the footer of the site to see it in action. In case anyone else had the desire to add such functionality to their own sites/projects, I figured I'd write up a quick post explaining how to do so. Let's get into it.

+ +

My website color scheme switcher in action (direct link to image)

The HTML

First we need to include the “buttons” that will trigger the theme to switch based on which one is selected. (Note: you could always render these as options in a select element if you preferred that method)

<div class="color-select">
+    <button onclick="toggleDefaultTheme()"></button>
+    <button onclick="toggleSecondTheme()"></button>
+    <button onclick="toggleThirdTheme()"></button>
+</div>
+

That's it! Don't worry too much about the onclick parameter right now, we'll come back to that when adding our JavaScript. The only remaining item is adding a default theme class to our html element, like so:

<html class="theme-default">
+

The CSS

Next we need to style both the color-select buttons, along with the custom color schemes that will alter the entire website. We will start with the color schemes.

For these themes to swap seamlessly between each other, we will be setting our altering color sets as CSS variables:

.theme-default {
+--accent-color: #72f1b8;
+--font-color: #34294f;
+}
+
+.theme-second {
+    --accent-color: #FFBF00;
+    --font-color: #59316B;
+}
+
+.theme-third {
+    --accent-color: #d9455f;
+    --font-color: #303960;
+}
+
+body {
+    background-color: var(--accent-color);
+    color: var(--font-color);
+}
+

Finally, we style the user-facing color swatches:

.color-select button {
+    -moz-appearance: none;
+    appearance: none;
+    border: 2px solid;
+    border-radius: 9999px;
+    cursor: pointer;
+    height: 20px;
+    margin: 0 0.8rem 0.8rem 0;
+    outline: 0;
+    width: 20px;
+}
+
+/* Style each swatch to match the corresponding theme */
+.color-select button:nth-child(1) { background: #72f1b8; border-color: #34294f; }
+.color-select button:nth-child(2) { background: #FFBF00; border-color: #59316B; }
+.color-select button:nth-child(3) { background: #d9455f; border-color: #303960; }
+

The JavaScript

We need to have each color swatch button trigger it's corresponding theme and swap out the theme-default class that we have originally attached to the main html element. We also need to store what the user has selected into localStorage, so their choice persists when reloading or navigating to other pages.

// Set a given theme/color-scheme
+function setTheme(themeName) {
+    localStorage.setItem('theme', themeName);
+    document.documentElement.className = themeName;
+}
+
+// Toggle between color themes
+function toggleDefaultTheme() {
+    if (localStorage.getItem('theme') !== 'theme-default'){
+        setTheme('theme-default');
+    }
+}
+function toggleSecondTheme() {
+    if (localStorage.getItem('theme') !== 'theme-second'){
+        setTheme('theme-second');
+    }
+}
+function toggleThirdTheme() {
+    if (localStorage.getItem('theme') !== 'theme-third'){
+        setTheme('theme-third');
+    }
+}
+
+// Immediately set the theme on initial load
+(function () {
+    if (localStorage.getItem('theme') === 'theme-default') {
+        setTheme('theme-default');
+    }
+    if (localStorage.getItem('theme') === 'theme-second') {
+        setTheme('theme-second');
+    }
+    if (localStorage.getItem('theme') === 'theme-third') {
+        setTheme('theme-third');
+    }
+})();
+

And that's it! Now it just depends on how custom you want each individual theme style to be. The possibilities are endless!

Extra Improvements

You could improve this concept even further hiding the color-select item if the user has JavaScript disabled. For my needs, I felt it was a fine trade-off to keep the non-functioning color swatch pickers if JavaScript was disabled. However, your project/site might need better fallbacks.

Pure CSS Simple Dropdown Plugin

2018-09-20T10:00:00Z

Pure CSS Simple Dropdown Plugin

2018-09-20

I find myself blowing away default browser select styling and implementing my own custom dropdowns far more often than I'd like. So, I recently created a very simple and clean component using just pure CSS.

Check out the CodePen below and feel free to morph it as you see fit for your own projects!

Live CodePen Example

Publishing Simple Books With Jekyll

2019-06-20T10:00:00Z

Publishing Simple Books With Jekyll

2019-06-20

When thinking about writing, designing and ultimately publishing an ebook, most people don't think of using a static site generator. Having products like Amazon Publishing, LaTeX or even Microsoft Word available, why should you use Jekyll?

Two reasons:

extremely easy to use
total customization

I know these same arguments could be made towards the other options mentioned above, but I'm biased towards Jekyll since I love the simplicity of HTML and CSS. Hopefully, after reading this post, you will feel the same as well!

No developer skills needed

You won't need any hardcore development skills or in-depth knowledge of Jekyll to get the most out of this publishing technique. The theme (Jekyll Book Theme) will allow you to focus on your book's content rather than wrestling with typography and page layouts. A basic command line script will perform all the heavy lifting for us at the end.

What are we creating?

You can see the demo of the online and PDF versions of the book below:

So without wasting anymore time, let's get started!

Setup Jekyll
Using the "Book" Jekyll Theme
Writing Chapters
HTML to PDF
Closing Thoughts

1. Setup Jekyll

Before we can really do anything else, you will need to install and setup Jekyll. The best way to do so is by following the instructions on the official Jekyll website:

Installing Jekyll

Run through the simple step-by-step installation instructions based on your operating system.

Basic requirements

Ruby version 2.4.0 or above
RubyGems
GCC and Make (in case your system doesn’t have them installed)

2. Using the "Book" template

The example we will be referencing in this post is the open source Jekyll theme called "Jekyll Book Theme". This theme as been designed and optimized for publishing ebooks with Jekyll.

Simply following the instructions on the main README page of the jekyll-book-theme repo.

Important: Take the time to edit the title, and author properties in the _config.yml file in the root directory. Make sure these reflect your own book's content.

That's it. Now let's tell Jekyll how we want it to format our chapters.

3. Working with chapter collections

By default, Jekyll will look for latest posts in the _post directory. This is useful for blogs and basic static websites - but not for us. We want chapters.

Using custom collections

Thankfully, Jekyll is flexible and allows us to set our own custom "collections". Collections are ways to group related content together for easier use dynamically. Our plan is to setup a collection that will house our chapter markdown files in numeric order. You can see this in the "book" template top level directory. It should look like the following:

_chapters +
- 01.md
- 02.md
- 03.md
- etc..
+

But the template already has this setup

By default the Jekyll Book Theme template has this chapters collection implemented and working as intended. The reason I broke it down step-by-step is so that you can have some better understanding about what is happening "under the hood".

Teach a person to fish and all that jazz.

Now all you need to do is break your chapters down into their own numbered markdown files inside _chapters.

4. HTML to PDF

Before you can convert your digital book "website", you need to install the wkhtmltopdf package. Download and follow the instructions below:

wkhtmltopdf

Command line conversion

In your terminal, navigate inside the _site folder of your jekyll build and then run the following command:

for f in *.html; do wkhtmltopdf -g -s Letter --no-background "$f" "${f/_*_/_}.pdf";done
+

Shortly after you should have a generated PDF file inside the _site folder - most likely named index.html.pdf. That's it! Enjoy your fully formatted PDF version of your book!

5. Closing Thoughts

There are a good amount of pros and cons to this approach of "publishing" PDF versions of your book. Since I'm a sucker for good and bad bullet lists, let's do just that:

The Good

Online version and PDF versions share same styling (keeps things consistent)
Chapters are written in markdown (increased flexibility of writing apps etc.)
Very fast and streamlined build process
PDF format renders out the chapter headers for built-in navigation

The Bad

Chapters are spit out as one long, single page (I'm sure this could be rectified with some custom work)
More suited for short stories, papers, essay articles (not so great for epic novels)
I'm sure there are other cons I am missing?

In the end, using something like LaTeX would certainly grant the user more flexibility in design and layout of the final "print" PDF product - but I'm a sucker for using Jekyll when I can.

Please let me know if you decide to use this method and end up publishing your own book 😀 I would love to check it out!

PS4 Download UI with Pure CSS

2021-06-20T10:00:00Z

PS4 Download UI with Pure CSS

2021-06-20

Overall, I'm fairly impressed with the user interface design of Sony's PS4 system OS. It's minimal and keeps the content front and center. Even with it's sometimes spotty performance hiccups, I've come to enjoy interacting with it.

One of the key UI items I've always been a fan of is the download progress view under the Notifications settings. So I figured I'd try my hand at recreating this with pure CSS. Here is the final result:

Live CodePen Example

Although I've added some of my own improvements (typography spacing, tweaks to the progress bar animation) - the concept it still pretty close to the original.

But enough chit-chat, let's walkthrough how to make it!

The HTML

As with most of my demos, the HTML is very minimal and straightforward. The PS4 system OS download view needs to show the following:

The game's title
Full game size, amount downloaded and time remaining
Visual progress bar

So we will place the game's title inside our h2 with a class of title (shocking, I know). The details about game size, downloaded amount and time remaining gets placed under a parent div with an accompanying details class. Finally, we create our progress bar by including a parent div with a class of progress that contains a child div with a class of inner-progress.

Pretty clean and easy to understand.

<div class="wrapper">
+    <img src="https://upload.wikimedia.org/wikipedia/commons/0/00/PlayStation_logo.svg" alt="PS4" class="logo">
+    <h2 class="title">Detroit: Become Human</h2>
+    <div class="details">
+        <p>Update File</p>
+        <p>13.45/17.50 GB (21 Minutes Left)</p>
+    </div>
+    <div class="progress">
+        <div class="inner-progress"></div>
+    </div>
+</div>
+

The CSS

Now it's time to utilize all those classes in the HTML above to craft our PS4 UI recreation. I'll break this section down into digestible chunks to avoid overwhelming you by vomiting out a bunch of CSS spaghetti.

First we'll add a bunch of QOL improvements to help better showcase the demo (adding custom fonts, center content etc.).

This part is completely optional:

/* Import fonts */
+@import url('https://fonts.googleapis.com/css2?family=Source+Sans+Pro:wght@200;400&display=swap');
+
+/* Gradient background styling, height overrides */
+body {
+    background: linear-gradient(#226AB6 0%, #144E8A 100%) no-repeat;
+    color: white;
+    display: block;
+    font-family: 'Source Sans Pro', sans-serif;
+    font-weight: 200;
+    height: 100vh;
+}
+
+/* Wrapper to center content */
+.wrapper {
+    margin: 0 auto;
+    max-width: 800px;
+    padding: 4rem 0 0;
+}
+
+/* Optional PS4 logo */
+.logo {
+    display: block;
+    filter: invert(1);
+    margin: 0 0 2rem 0;
+    opacity: 0.5;
+    width: 60px;
+}
+

Now for the styling that actually matters. First we will style the game's title and accompanying details (flexbox to the rescue again!):

h2.title {
+    font-weight: 400;
+    margin: 0;
+}
+
+.details {
+    display: flex;
+    justify-content: space-between;
+    margin: 0.2rem 0 0;
+}
+.details p {
+    margin: 0;
+}
+

Not a whole lot of code to get things looking proper, eh? Next we move on to the progress bar. This is slightly more interesting since we are going to utilize the before pseudo element - which sounds more complex than it actually is. Pay close attention to the pseudo element and how it calls the progress-bar-shine animation - more on that later.

.progress {
+    background: #226AB6;
+    border: 1px solid white;
+    height: 15px;
+    margin: 2rem 0 0;
+    position: relative;
+    width: 100%;
+}
+.progress:before {
+    animation: progress-bar-shine 2.5s infinite;
+    background: linear-gradient(to left, white 0%, transparent 100%);
+    border-radius: 10px;
+    content:'';
+    filter: blur(8px);
+    height: 100%;
+    opacity: 0.8;
+    position: absolute;
+    transform:translateX(0);
+    width: 50px;
+}
+.inner-progress {
+    background: white;
+    height: 100%;
+    opacity: 0.6;
+    width: 450px;
+}
+

Almost finished! We just need to animate that before pseudo element with a simple keyframes at-rule:

@keyframes progress-bar-shine {
+    to {
+    transform:translateX(450px);
+    opacity:0;
+    }
+}
+

Wrapping Up

Although far from perfect, this experiment still explores what can be created (or in this case, recreated) in the browser using just pure CSS. Remember, you don't have to reach for JavaScript just because you can!

Proper UI Hierarchy

2019-02-05T10:00:00Z

Proper UI Hierarchy

2019-02-05

I often feel like an old man when I complain about flat design and how designers these days have lost (or willfully forgotten) the skill to create accessible UIs with proper visual hierarchy. A skill which at it's core seems so simple - yet is overlooked in almost every current modern interface.

I'm unable to pinpoint the exact reason why designers swapped out depth, hierarchical layouts and accessibility for muted colors, abstract imagery, illegible typography, and unimaginative flat designs.

But then again, maybe I'm just a design-dinosaur of a time long forgotten. Maybe I need to adapt and move with the times. Or maybe the current design trends are just lazy.

I'm pretty sure it's lazy design trends.

Stop complaining and do something

As an example, I'm going to breakdown the process of improving the overall design on a set of "flat" button elements.

Hopefully this demo article inspires even one designer to rethink their method when approaching UI design and push away from what is currently accepted as the "correct way to design UI".

And one final note before we deep dive into this demo:

The statement that flat design is inherently worse than it's predecessor is not subjective. By stripping away the visual cues that help users distinguish between interface elements you are purposely making a worse experience for them. Designers need to stop designing for other designers.

What we will be designing

In this demo we will be improving the default flat design inspired button layout of the following:

Live CodePen Example

Designing the skeleton

This will be our basic HTML structure, along with it's default styling (based on today's UI standards):

The HTML

<div class="buttons-container">
+    <button>Sign Up</button>
+    <button>Log in</button>
+</div>
+

The CSS

/* Parent container for the buttons */
+.buttons-container {
+    background: #E0E9EE;
+    border-radius: 5px;
+    display: flex;
+    padding: 20px;
+    margin: 0 auto;
+    max-width: 300px;
+    width: 100%;
+}
+
+/*Shared button styles */
+button {
+    appearance: none;
+    border: 0;
+    border-radius: 5px;
+    color: #fff;
+    cursor: pointer;
+    display: inline-block;
+    font-size: 14px;
+    font-weight: bold;
+    padding: 15px 20px;
+    width: 50%;
+}
+
+/* Sign up button */
+button:first-child {
+    background: #2FBC3D;
+    margin-right: 10px;
+}
+
+/* Log in button */
+button:last-child {
+    background: #459BCF;
+}
+

Adding simple improvements

Gradients (not solely on their own mind you) within UI systems were initially used to help humans make connections with their analog counterparts. Something like toggles or switches matching those found in the real world, allowed users to mentally connect what that element's function did almost instantly.

Be warned not to confuse this with skeuomorphic design - an element sharing similar qualities as it's analog sibling does not instantly make it so.

If you ever run into a designer who rolls their eyes or scoffs at you for proposing the use of something such as gradients (in a tactful way, of course) it is safe to assume they have been brainwashed by the modern design hive-mind.

To disregard the use of gradients simply because the belief is "gradients are bad" is idiotic. Worse still is to do so based on the belief that "gradients aren't in right now". As a designer, your job is to design a beautiful and usable product - not win high-fives among your peers. /end rant.

Adding subtle gradients

When gradients are implemented properly, most users won't even be aware of their presence. The difference in color (specifically on buttons in this example) helps give the illusion of a light source in the interface, which designers can use to their advantage (ie. pull more attention to elements by "lifting" them forward on the page).

The subtly improved CSS

/* Sign up button */
+button:first-child {
+    background-image: linear-gradient(-180deg, #1EB52A 0%, #0D941C 100%);
+}
+
+/* Log in button */
+button:last-child {
+    background-image: linear-gradient(-180deg, #489FD2 0%, #0A6DAC 100%);
+}
+

More depth & light

With our subtle gradients we are closer to creating a solid contrast between interactive elements, but we can improve this even further. By adding some more depth with a harder light source and more pronounced outlines, we allow the button elements to stand out on their own more strongly.

This is fairly easy to accomplish with CSS using the very basic box-shadow, text-shadow and border properties:

/* Parent container */
+.buttons-container {
+    background-image: linear-gradient(0deg, #BBC6CD 3%, #E2EBF0 100%);
+    border: 1px solid #8D8D8D;
+    box-shadow: 0 2px 4px 0 rgba(42,42,42,0.40), inset 0 1px 3px 0 rgba(255,255,255,0.50);
+}
+

/* Shared button styling with text-shadows */
+.buttons-container button {
+    text-shadow: 0 2px 4px rgba(0,0,0,0.30);
+}
+

/* Sign up button */
+.buttons-container button:first-child {
+    background-image: linear-gradient(-180deg, #1EB52A 0%, #0D941C 100%);
+    border: 1px solid #0C6B16;
+    box-shadow: 0 1px 5px 0 rgba(9,116,21,0.50), inset 0 -1px 6px 0 rgba(0,0,0,0.20), inset 0 1px 0 0 rgba(255,255,255,0.50), inset 0 2px 4px 0 rgba(255,255,255,0.50);
+}
+

/* Log in button */
+.buttons-container button:last-child {
+    background-image: linear-gradient(-180deg, #489FD2 0%, #0A6DAC 100%);
+    border: 1px solid #0A486E;
+    box-shadow: 0 1px 5px 0 rgba(9,85,133,0.50), inset 0 -1px 6px 0 rgba(0,0,0,0.20), inset 0 1px 0 0 rgba(255,255,255,0.50), inset 0 2px 4px 0 rgba(255,255,255,0.50);
+}
+

For easy reference, here is the CSS styling in it's entirety:

/* Parent container */
+.buttons-container {
+    background-image: linear-gradient(0deg, #BBC6CD 3%, #E2EBF0 100%);
+    border-radius: 5px;
+    border: 1px solid #8D8D8D;
+    box-shadow: 0 2px 4px 0 rgba(42,42,42,0.40), inset 0 1px 3px 0 rgba(255,255,255,0.50);
+    display: flex;
+    padding: 20px;
+    margin: 0 auto;
+    max-width: 300px;
+    width: 100%;
+}
+
+/* Shared button styling */
+button {
+    appearance: none;
+    border: 0;
+    border-radius: 5px;
+    color: #fff;
+    cursor: pointer;
+    display: inline-block;
+    font-size: 14px;
+    font-weight: bold;
+    padding: 15px 20px;
+    text-shadow: 0 2px 4px rgba(0,0,0,0.30);
+    width: 50%;
+}
+
+/* Sign up button */
+button:first-child {
+    background-image: linear-gradient(-180deg, #1EB52A 0%, #0D941C 100%);
+    border: 1px solid #0C6B16;
+    box-shadow: 0 1px 5px 0 rgba(9,116,21,0.50), inset 0 1px 0 0 rgba(255,255,255,0.50), inset 0 2px 4px 0 rgba(255,255,255,0.50);
+    margin-right: 10px;
+}
+
+/* Log in button */
+button:last-child {
+    background-image: linear-gradient(-180deg, #489FD2 0%, #0A6DAC 100%);
+    border: 1px solid #0A486E;
+    box-shadow: 0 1px 5px 0 rgba(9,85,133,0.50), inset 0 1px 0 0 rgba(255,255,255,0.50), inset 0 2px 4px 0 rgba(255,255,255,0.50);
+}
+

Going even further with this UI

This demo article only showcases how to improve on a basic button UI structure with a focus on proper hierarchy between elements.

Once completely developed, these element should support all interactive states (hover, active, disabled) and animations to make for a more engaging experience.

Poor Man's CSS Full-Bleed Layout

2020-10-07T10:00:00Z

Poor Man's CSS Full-Bleed Layout

2020-10-07

I recently came across the very well written and interesting article, Full-Bleed Layout Using CSS Grid, while browsing my daily designer feeds. I won't go into the post's specifics here (I recommend you read the article for yourself) but it details how to render full-bleed element effects utilizing the CSS grid property.

While the approach in the article works perfectly fine, I thought to myself, "Is there not a simpler, more backwards compatible way to do this?". Indeed there is.

Don't care about the tutorial? Skip down to the live demo

Make the Web Backwards Compatible

I try my best when creating specific element designs or layouts to have everything render consistently across almost all browsers. This tends to include the obvious front-runners: Chrome, Firefox, Safari - but I also try my best not to ignore the oldies: IE11, Edge and older versions of Opera. I believe if most web designers even loosely followed this concept we wouldn't be stringing together barely implemented CSS properties and hacking together polyfills for all the unsupported browsers. Just my two cents.

What does this have to do with full-bleed exactly? Well, the CSS we will be using in this demo is fully compatible with pretty much any browser that can run the basic version of CSS rendering. If the browser you're targeting supports max-width and margins - then have no fear, full-bleeds are here.

Our HTML Example

Let's create a single-column blog layout for this example. We will include a heading, some paragraphs, an image, and a blockquote to keep it simple:

<main>
+    <article>
+        <h1>Main Heading</h1>
+        <p>Et non consequat eiusmod minim fugiat. Magna duis veniam ex reprehenderit occaecat sit. Nisi ut ex aliquip magna enim.</p>
+        <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Laborum repellat ab earum commodi, consequuntur totam adipisci doloremque asperiores quae at quia non temporibus ipsam voluptate voluptatem ipsa nostrum suscipit aliquid!</p>
+        <img src='https://images.unsplash.com/photo-1569083692634-f8db90c093ef?ixlib=rb-1.2.1&q=85&fm=jpg&crop=entropy&cs=srgb&ixid=eyJhcHBfaWQiOjE0NTg5fQ' alt="Some Image">
+        <p>Ex excepteur Lorem reprehenderit dolore in consequat voluptate commodo ipsum consequat ea et. Nisi tempor proident anim tempor. Laboris est sunt cillum deserunt culpa proident cillum laborum voluptate. Est exercitation Lorem reprehenderit eu ipsum nisi et.</p>
+        <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Ducimus dicta perspiciatis vel ex officiis, nisi optio nihil aspernatur exercitationem sed nobis architecto maxime eaque omnis eos, repellendus necessitatibus provident explicabo?</p>
+        <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Aliquid placeat ipsum totam, facere animi tenetur explicabo at veniam, culpa vitae debitis hic modi velit cum perferendis minima quos sit quisquam.</p>
+        <blockquote>
+            <p>To be, or not to be, that is the question:<br>Whether 'tis nobler in the mind to suffer<br>The slings and arrows of outrageous fortune,<br>Or to take Arms against a Sea of troubles,<br>And by opposing end them: to die, to sleep;</p>
+            <cite>- Some guy</cite>
+        </blockquote>
+        <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Ducimus dicta perspiciatis vel ex officiis, nisi optio nihil aspernatur exercitationem sed nobis architecto maxime eaque omnis eos, repellendus necessitatibus provident explicabo?</p>
+        <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Aliquid placeat ipsum totam, facere animi tenetur explicabo at veniam, culpa vitae debitis hic modi velit cum perferendis minima quos sit quisquam.</p>
+    </article>
+</main>
+

This works well as it is, but we will need to "section" off our different areas of content based on whether we want them full-bleed or not. We do this with - you guessed it - the section element. In this demo we want the image and blockquote to become full-bleed when rendered, so we'll add the full-bleed class to those sections for now (more on that later):

<main>
+    <article>
+        <section>
+            <h1>Main Heading</h1>
+            <p>Et non consequat eiusmod minim fugiat. Magna duis veniam ex reprehenderit occaecat sit. Nisi ut ex aliquip magna enim.</p>
+            <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Laborum repellat ab earum commodi, consequuntur totam adipisci doloremque asperiores quae at quia non temporibus ipsam voluptate voluptatem ipsa nostrum suscipit aliquid!</p>
+        </section>
+        <section class="full-bleed">
+            <img src='https://images.unsplash.com/photo-1569083692634-f8db90c093ef?ixlib=rb-1.2.1&q=85&fm=jpg&crop=entropy&cs=srgb&ixid=eyJhcHBfaWQiOjE0NTg5fQ' alt="Some Image">
+        </section>
+        <section>
+            <p>Ex excepteur Lorem reprehenderit dolore in consequat voluptate commodo ipsum consequat ea et. Nisi tempor proident anim tempor. Laboris est sunt cillum deserunt culpa proident cillum laborum voluptate. Est exercitation Lorem reprehenderit eu ipsum nisi et.</p>
+            <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Ducimus dicta perspiciatis vel ex officiis, nisi optio nihil aspernatur exercitationem sed nobis architecto maxime eaque omnis eos, repellendus necessitatibus provident explicabo?</p>
+            <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Aliquid placeat ipsum totam, facere animi tenetur explicabo at veniam, culpa vitae debitis hic modi velit cum perferendis minima quos sit quisquam.</p>
+        </section>
+        <section class="full-bleed">
+            <blockquote>
+                <p>To be, or not to be, that is the question:<br>Whether 'tis nobler in the mind to suffer<br>The slings and arrows of outrageous fortune,<br>Or to take Arms against a Sea of troubles,<br>And by opposing end them: to die, to sleep;</p>
+                <cite>- Some guy</cite>
+            </blockquote>
+        </section>
+        <section>
+            <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Ducimus dicta perspiciatis vel ex officiis, nisi optio nihil aspernatur exercitationem sed nobis architecto maxime eaque omnis eos, repellendus necessitatibus provident explicabo?</p>
+            <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Aliquid placeat ipsum totam, facere animi tenetur explicabo at veniam, culpa vitae debitis hic modi velit cum perferendis minima quos sit quisquam.</p>
+        </section>
+    </article>
+</main>
+

That's it for the HTML!

The Magic CSS (Not Really)

Now take a deep breath and get ready for some hard CSS work:

article {
+    width: 100%;
+}
+
+article section {
+    margin: 0 auto;
+    max-width: 480px; /* This can be whatever you want */
+    width: 100%;
+}
+article section.full-bleed {
+    max-width: 100%;
+}
+

That's it. Really. Now any element (blockquotes, specific headers, navigations, footers, etc) that you want to layout as "full-bleed", just wrap it in a section tag and sick the full-bleed class on it. Done and done.

Obviously you'll want to add more styling to clean-up and make your full-bleed layouts more beautiful. This demo was just more of a starting point.

Maybe Not-Quite-Full-Bleed?

You could also further customize your options by including a class like half-bleed, which maybe only expands slightly outside the main section max-width:

article section.half-bleed {
+    max-width: 960px;
+}
+

Sidenote

For those concerned about accessibility: The section element is a flow content element, so it can contain almost all HTML elements.

Live Demo

Live CodePen Example

My Cheapskate Commenting System

2022-02-03T10:00:00Z

My Cheapskate Commenting System

2022-02-03

My blog now has comments! Well, kind of...

I went down a two day long rabbit-hole trying to find the best solution for implementing comments on my static website (generated via Jekyll FYI). There are a ton of options out there and many open source models that allow you to spin up your own instance with something like DigitalOcean or AWS. But I'm a cheap bastard. I refuse to spend $5/month on a blog mostly used for fun and one that I have zero incentive to "monetize".

So, what free options did this old miser have left to chose from? To my surprise, there were two solid options that initially caught my eye! Let's take a look then, shall we?

Remarkbox

Overall I don't have many bad things to say about Remarkbox. It looks nice, is easy to implement and runs a "pay what you can" pricing model. What more could you ask for?! The major issue (for me, personally) is precisely that; the free model. This makes it difficult for me to trust 100% that this system will still be around in 3-4 years. Now I know - even paid systems can shutdown unexpectedly, but I find free tier options end up shutting their doors sooner. There is an option to self-host Remarkbox, but that requires a yearly license and also comes back to the point I made about not wanting to pay for hosting...

Utterances (Github-based)

The other major option was Utterances. This system was almost the winner due to it's pretty great feature set:

Open source
No tracking, no ads
All data stored in GitHub issues
Free!

But take a look above at point number three. The fact that readers wishing to leave a comment are required to have a Github account. For me, this is a non-starter. I don't want to force my audience to sign up for or sign in to any account just to leave a simple comment on my humble blog. Considering a number of my readers are part of the FOSS community, this just seemed like a bad fit.

Finding Inspiration

I absolutely love the solar.lowtechmagazine.com website (both for it's content and design) and indirectly found my comment system inspiration there. Okay let's be honest, I completely stole their commenting system "concept". Imitation is the sincerest form of flattery, right?

My Comment System is...

E-mail. It's just plain e-mail.

I've setup a basic comment-prompt.html in my _includes folder that contains a mailto action button[^1]:

<a href="mailto:myemail.com?subject=RE: { { page.title | uri_escape } }">
+    <button>Comment via email</button>
+</a>
+

This include template is placed at the bottom of every article automatically. Then, that action pulls in the article's title as the e-mail subject line in the user's default mailing app. That's it.

Pros

No third party application needed
Privacy focused
More direct interaction with my audience/readers
Builds a much more close-knit community
Completely free!

Cons

Must be manually curated and posted
No notifications
No "built-in" reply functionality
Has the potential to become unwieldy...

Fun Experiment

I figure either way, this will be an interesting experiment. I don't know my audience size (since I don't use any type of tracking) but I assume it's very small. Those willing to write me a personal e-mail in order to share their thoughts on my stupid little blog probably have something interesting to say. At least I hope so.

Let's see how this thing goes...

Plain Text Emails, Please

2019-09-09T10:00:00Z

Plain Text Emails, Please

2019-09-09

When it comes to website / product design and development most devs should try to keep things simple. By only using as much code as absolutely necessary, projects avoid growing out of scope or becoming bloated. So, why isn't this same approach taken for email?

A brief history of email

Email has been possible since the 1960s with time-sharing computers being used to share files and messages across early devices. Around the 80s and 90s it seemed as though GOSIP would dominate the market, but this was knocked out in favor of SMTP, POP3 and IMAP in 1995 when the National Science Foundation ended its sponsorship of the Internet backbone, and all traffic relied on commercial networks.

+ +

The first computers to send and receive email. Source: Wikipedia

Things were looking pretty good at this point. Most operating systems now had a shared foundation of sending and receiving emails on the internet, allowing for a set of standards to be slowly developed and agreed upon over time. These were simpler times, with the default content sent between machines being plain text. No embedded images, no CSS3 fallback support, no fluff - just content.

Sidenote:
+Now, I'm not going to sit here and pretend to be some expert on the history of email (or the internet in general), so I suggest you take the time to read about the history of the internet if you're into that kind of thing.

Looking at some data

Data isn't everything
+

I understand that the data being used is currently 16 years old - but not many extensive research studies have been performed (specifically for email-type preference in general)

In 2002^[1], a small-set survey was run by ClickZ was created to gauge the details of personal email data. The main data we will focus on is the user preference between HTML or plain text formats:

Do you prefer receiving HTML or text email?

+ + + + + +

Response	Percentage (%)
HTML	41.95
Plain Text	31.52
No Preference	26.53

+On initial review, one could make the argument that the general public prefers HTML email over plain text (~42% vs ~32%) - but I would disagree with this analysis. The roughly 27% of respondents who answered with No Preference should not be dismissed so easily.

Since the No Preference respondents don't care whether emails they receive are designed in HTML format, why not send them plain text variations by default? The positives of plain text greatly outweigh those of HTML:

Plain text has reduced file size +
- Don't forget that many users have limited data usage across much of the world
+
HTML is more likely to be flagged as spam by email clients +
- This is due to extra code, tracking scripts, 3rd party assets / resources being called
+
HTML / CSS can be inconsistent or even limited in support across email clients
Text only requires less design work for your development team +
- Don't forget about testing all the various email clients too
+

Add to this that 53% of emails are opened on mobile - so any "fancy" marketing email designs need to look great on mobile screens and also take into account slower connections. What looks better and loads faster than simple plain text? 😛

But what about marketing!?

Sorry to say, but marketing should never trump user experience. Teams love to track email opens / click ratios, who subscribed / unsubscribed or who shared the campaign with others - but it's all bloat on the user's end.

Greg Kogan wrote up a great article / case study about his experience switching over a client's campaign from HTML templates to plain text with some really interesting results. I highly recommend you give it a read for a better understanding about how the marketing goals and customer goals don't always align.

Simple or lazy - it doesn't matter

Plain text can certainly have a reputation for looking lazy or cheap, but I feel this is mostly perpetuated in the design and marketing communities. I can assure you that your average day-to-day users are much less opinionated about your email campaign design than you are. Look to satisfy your customers' needs before your own.

Life is really simple, but we insist on making it complicated.
+
- Confucius
+

That being said, at the end of the day, companies will justify their own reasons to use HTML email templates over plain text. You can't convince everyone. My own personal experience with email template design, along with analyzing some of the data, leaves me to believe that most businesses should default to plain text. At the very least, you should try to convince your team to perform some simple A/B testing with your next email campaign.

The results might just surprise you.

Refs

This is the "latest" detailed survey I could find on email design preference

Setting Up 1.1.1.1 for Families on a Pi-Hole

2021-10-28T10:00:00Z

Setting Up 1.1.1.1 for Families on a Pi-Hole

2021-10-28

After seeing Cloudflare's 1.1.1.1 for Families mentioned on the front page of HackerNews, I thought it might be helpful to show those currently using a pi-hole device how to include 1.1.1.1 alongside it.

Keeping Things Updated

It should go without saying that you should be running the latest stable pi-hole version for security and full feature support. To do so, simply ssh into your device (or connect to it directly if you prefer) and run the following to check your pi-hole version:

pihole -v
+

And if your version is out of date, run:

pihole -up
+

Once it completes the update everything will be good to go!

Adding 1.1.1.1 (1.1.1.2)

Now you need to navigate to your main pi-hole admin in your browser (most likely the url will be pi.hole). Login in using your credentials and the do the following steps:

Navigate to Settings
Navigate to DNS
Under "Upstream DNS Servers" enter:

Custom 1 (IPv4): 1.1.1.2
Custom 2 (IPv4): 1.0.0.2

+ +

PiHole DNS settings (link to hi-res image)

Ad-Block & Malware Protection

You now officially have protection against both intrusive advertisements and sites flagged with malware. Happy (and now safer) browsing!

Stuffing an SSD Inside the Raspberry Pi 400

2021-08-13T10:00:00Z

Stuffing an SSD Inside the Raspberry Pi 400

2021-08-13

I have successfully jammed an mSATA SSD into the main shell of my Raspberry Pi 400. It wasn't as straightforward as I thought it would be - in fact, most real hardware tinkerers will probably vomit in their mouths once they see how I achieved this...

But I'm happy with my build. Those with better skills and knowledge can most likely improve upon this concept (and please do if you can - I'd love to see it!)

Enough chit-chat - on to the build!

The Finished "Masterpiece"

Below you can see the final look of my modded Raspberry Pi 400, which I have personally named the Raspberry Pi 400X:

+ +

The finished Raspberry Pi 400X (link to hi-res image)

Do you see that ugly black USB-C to USB-A cable jutting out from the top? That little guy connects directly to the mSATA SSD inside the plastic keyboard structure and allows us to boot via USB. It also gives us the flexibility to easily unplug the internal SSD for times when we desire to boot from micro SD or a different USB device altogether.

So, how did I make this?

The Shopping List

Before we deep dive into the terrible hardware modifications I've made to my Pi, I'll list out all the items/tools I used during the making of this monstrosity:

mSATA 64GB SSD Half Size (KingSpec) → AliExpress
mSATA to USB 3.1 enclosure (gutted) → Amazon
Dremel rotary tool with soft sanding bits
Metal cutting scissors / knife
Electrical tape
Patience

Modding the Raspberry Pi 400

The final product requires us to attach the half size mSATA SSD to the (gutted) enclosure and then insert that directly inside the Pi (next to the lock port / ethernet). Our first step will be to disassemble the Pi 400, safely remove the keyboard module and remove the metal heatsink.

With your trusty metal cutting scissors (or whatever tool you prefer) you will need to cut out room for our enclosure internals to fit within:

+ +

I drew the outline of the enclosure on the metal first before cutting. (direct link to image)

Next you will need to carefully remove the Pi board itself from the red part of the case. Once placed safely aside, it's time to bust out our sanding dremel and remove the jutting plastic blocking our soon-to-be-added SSD. Remember to wear a mask during this phase, since breathing in plastic dust and fumes is not fun!

Important to note: this will remove one of the screw slots needed to secure the heatsink into the board. Not a big deal if you ask me...

+ +

Here you can see my terrible sanding job on the far left plastic snap-lock (direct link to image)

While you have the Pi board removed you should also cut out a slot for the USB-C to USB-A cable to connect our mSATA to one of our USB 3 ports on the Pi. For this I've opted to butcher the lock port (will I ever really use that anyway?)

+ +

Don't judge...I'm sure most people could do a cleaner job! (direct link to image)

Now all that's left is to insert our gutted mSATA enclosure (with the half size SSD attached of course) +, tape it down with some hideous electrical tape and close this bad boy back up!

+ +

Take note of the tiny triangle piece of foam on the Type-C connector. This helps avoid direct contact with the back of the keyboard module! (link to hi-res image)

That's it! You now have the portable power of the Raspberry Pi 400, but now with the speed and performance of an SSD!

The Performance Gains

+ + + + +

Storage Type	Seq. Write	Random W	Random R
Micro SD Card	17818 KB/sec	812 IOPS	2335 IOPS
mSATA SSD	206738 KB/sec	14615 IOPS	17925 IOPS

+I think it's pretty clear that the SSD blows the default micro SD card out of the water...

Closing Thoughts

Now clearly you could just plug-in an external SSD and walk away with the same performance boosts - but where is the fun in that?

If anyone decides to improve on this or make a cleaner approach, please do share it with me. I'd love to see it!

89 Blog Posts in a Single HTML File

2021-04-22T10:00:00Z

89 Blog Posts in a Single HTML File

2021-04-22

This is no longer the current setup of my blog. I have switched back to Jekyll for performance reasons. I'll be leaving this post up as a point of reference though :)

This is my personal blog (if that wasn't already obvious). I currently have 89 blog posts living here. But I have done something magical today:

All of these articles are rendered inside a single HTML file. 🤯

What Sorcery is This?!

No magic here - I'm just using my own personal static site generator called PHPetite. You can find all the code and more information about PHPetite on the official Github repo page. Please note that this project is still very much a WIP, so go easy on me when pointing out bugs or issues!

Pingdom Stats

Before we get into more details on how everything is built, let's take a quick look at some of my website stats (not that pure numbers are 100% accurate of user experience):

99 Performance Grade
951 ms Load Time
231.3 KB Page Size (thank you Netlify compression!)

See all the Pingdom details for yourself

Now the Page Size will certainly change as more blog posts are added over time, but if the total webpage size is roughly 230 KB with 89 blog posts, I figure that gives me the ability to add another 200 or so posts before I cross the 1MB threshold

I'll deal with how to load in the content more efficiently when that times comes...

What About Images?

Good question. Since a large portion of my articles tend to be focused on design and CSS, visual examples are somewhat important. So how do I avoid loading in all the individual images on every single post into this single HTML "website"?

Easy - I don't load any images at all.

I now simply set any images that are not included in the current, visible section to display: none. This avoids breaking things with the RSS feed.

Here is an image example of an old Dribbble shot I created years ago:

+ +

Click the placeholder to load in the real image
Example Dribbble shot for testing. Feel free to click the default image in order to load the correct Dribbble source. View full size image.

I have noticed that Safari / Firefox on iOS renders the imagery as broken image links - I plan to look into this further to avoid that confusion. For now it works well on desktop Chromium and Firefox.

<figure>
+    <div class="img-parent">
+    <img loading="lazy" src="/placeholder-image.webp" onclick="this.src='https://res.cloudinary.com/bradtaunt/image/fetch/q_auto:low/v1570124593/https://uglyduck.ca/public/images/aqua-ui-css-buttons.webp'" alt="Aqua UI buttons">
+    </div>
+    <figcaption><b>Click the placeholder to load in the real image</b><br>Example Dribbble shot for testing. Feel free to click the default image in order to load the correct Dribbble source. <a href="https://res.cloudinary.com/bradtaunt/image/fetch/q_auto:low/v1570124593/https://uglyduck.ca/public/images/aqua-ui-css-buttons.webp">View full size image</a>.</figcaption>
+</figure>
+

How's the SEO?

Probably terrible to be honest. One single file for all blog posts is something Google will most likely frown upon. Whatever - it's my personal blog so I don't really give a shit.

RSS Feed

If you recently added my old RSS feed, I'm sorry, but you'll have to update. The new feed is located at tdarb.org/feeds/posts.xml. I made this change to avoid spamming the current feed users.

Tasty Dog Food

At the end of the day, by moving my personal blog over to PHPetite, it makes me more aware of current bugs and restrictions within the project. I feel like this will help me to improve this static site generator even more over time, instead of letting it die a slow death ignored on Github.

I hope you enjoyed this little breakdown and maybe even want to try out PHPetite for yourself? 😉

My Changing Opinion on Personal Website Design

2021-05-19T10:00:00Z

My Changing Opinion on Personal Website Design

2021-05-19

Hey would you look at that - my personal blog has been redesigned again! Although I am still using good ol' Jekyll for the backend, I have now added a more fleshed-out CSS design which also includes a set of open source custom typefaces.

Gasp! "How could you?!" I hear you ask. Let me explain.

Personal sites should feel personal

I can see how this change might seem hypocritical (it took some convincing myself) but I decided to follow in to footsteps of Kev Quirk and added a little whimsy and character to my website. After all, personal websites should feel personal. My obsession with barebones HTML & CSS serves its purpose on other public projects, but seems limiting for my own little space on the interwebs.

Banned from my own club

I had originally converted this blog's design to use zero CSS and instead rely solely on default browser styling. The main reasoning for doing so, was to have the ability to include my own personal website in the XHTML Club project. (I never said it was a good reason)

After giving it some thought, I've decided that this limitation seemed too extreme even for me.

Moving forward

I know I always say "With this new design, I can finally focus on just writing content!" - but this is a lie. I'll probably be fiddling with my personal website until the day I die. The good news is that I do have a few tutorial blog posts lined up to publish soon - so be on the lookout for those!

Thanks for reading through my pointless ramblings about personal websites. It's good to just vent about these things sometimes...

Create a Performance-Focused WordPress Blog

2021-09-08T10:00:00Z

Create a Performance-Focused WordPress Blog

2021-09-08

With my recent switch back to WordPress, and having read Kev Quirk’s latest post about Core Web Vitals, I wanted to make sure my blog still prioritized speed and performance above all else. I’m happy to say that I have closely replicated the same speed of my original static Jekyll-based version of this blog.

And I've achieved this with barely any effort at all. All that's needed is:

a lightweight WordPress theme
two free WordPress plugins
cheap & fast web hosting

Let me breakdown each component so those of you interested can do the same without hitting any roadblocks.

Choosing Your WordPress Theme

Selecting an existing theme or trying to build your own can be a daunting experience. For my needs, I forced myself to find an existing theme and just run with it. This gives me more time to focus on writing instead of constantly tweaking the blog’s visuals.

I would suggest either using the default starter theme (as of this writing: Twenty Twenty One theme by Automattic) or looking for specific “lightweight” themes across the web. I highly recommend checking out Anders Norén’s theme collection. Others can be found on the official wordpress.org website.

Two Simple Plugins

Once you have decided on a theme, you'll also want to be sure to install two very important plugins that greatly help with performance:

Jetpack Boost – wordpress.org/plugins/jetpack-boost/
Yoast SEO – wordpress.org/plugins/wordpress-seo/

Jetpack Boost

This plugin is fantastic. Not only will it run a proper audit (based off Google’s Lighthouse tool) but also gives you the ability to activate optimized CSS, lazy image loading and deferring non-essential JavaScript (if applicable). All of this is done in a super-clean user interface directly inside your WordPress admin.

Check out my own testing site metrics below:

+ +

The Jetpack Boost metrics for this website (and yes, that 99 score for mobile kills me)

Yoast SEO

If you’ve worked with WordPress at all you have surely heard of Yoast. Adding this plugin to your site is really a no-brainer. The automatic generation of meta data and SEO tags can save you a lot of time while also improving your overall Lighthouse score.

Here is the Lighthouse audit for the test WordPress website:

+ +

It might not be perfect, but it’s pretty damn close!

Those scores were achieved without any custom work on my end – I simply activated the plugin and let it work it’s magic. Great stuff.

Host Everything on EasyWP

Up to this point we haven’t spent a single penny. Unfortunately, web hosting isn’t free and you’re going to need it if you actually want your website to have a home on the interwebs!

I know – I can hear your collective voices shouting out:

Isn't web hosting a little expensive just for my simple hobby blog/site?
+
-- Some of you
+

I host this test blog for just $3.88/month and the service is actually good. Unreal, right? That’s the price of a medium coffee, so I’m pretty sure it won’t break the bank.

This “cheap” hosting is through EasyWP and the Starter plan ($3.88/month) comes with the following:

10 GB SSD storage
50k visitors/month
Unlimited bandwidth
Backups (though not automatic)
SFTP access
EasyWP Cache plugin (and it's actually good!)

You will need to snag your own SSL certificate though, but this is easily obtained with something like letsencrypt.org.

Best of all, if in the future you require more features the next pricing tier is still only $7.88. Not too shabby!

Try Yourself

The fact that EasyWP gives you a free month trial, there really is no reason not to try spinning up your own blog or online store or whatever the heck you want to build. The more people with personal spaces on the web the better.

Yet Another Static Site Generator Switch

2022-07-06T10:00:00Z

Yet Another Static Site Generator Switch

2022-07-06

If you're an RSS subscriber, I've probably blown up your feed reader (again). This seems to be an on-going theme with this blog. I can't help it.

This website now uses my new Pandoc-based static blog generator: pblog. I won't go into great detail about it's features (or lack thereof) - if you're interested in that, check out the "Introducing pblog" article.

The bigger question is, "Why the change?"

Where's the Love for "Shinobi"?

Switching over to pblog wasn't caused by a dislike of using Shinobi. In fact, I still really enjoy the work flow that that plain-text focused SSG provides. The main issues that popped up for my own blog was accessibility and poor user experience.

I had multiple readers reach out and mention poor rendering of content in their RSS reader of choice. That's kind of a big deal. I test that project as best I can with my limited access to all available RSS readers - but I can only test so much. It became one of those "Well, it works on my machine!" meme. So instead of spending an untold amount of time debugging every RSS reader known to man, I figured my best bet was to render things as HTML.

The next big issue was accessibility. Screen readers can read txt formatted files perfectly fine but since elements aren't categorized everything ends up with the same level hierarchy. This can cause confusion between headers, list items, URLs, footers etc. For my personal use-case (sharing tutorials and covering design topics) it didn't make sense to sacrifice user accessibility for minimalism.

The Search for Simplicity

My initial thought process was to include some form of "plus" add-on to the existing Shinobi build script. The idea was to render HTML versions of each post and dump those into the generated RSS file. Although maybe good in theory, it ended up impractical because:

No utility or existing tool could render the style of text-based formatting I implemented as semantic HTML (at least not without heavy customization and tinkering)
I was actually adding extra bloat to the Shinobi project (true minimalism is the point, right?)

So, that option was ruled out pretty quickly.

The next option didn't take me long to land on: Pandoc. I've used Pandoc for years and have nothing but great experiences tweaking it for my own needs. I knew that I could piggyback off the original shell commands in the Shinobi project and alter them as needed to incorporate Pandoc.

I honestly didn't run into many issues while rolling this out. Fairly seamless!

New Workflow

With this new blog switch I also decided to try out a new deploy workflow. I've used rsync for the longest time but wanted to have something more GUI-based on macOS. I know, blasphemy!

Since I already have a Transmit license, that seemed like the best fit since it is designed specifically for macOS. Now my workflow process is as follows:

Write new posts in my root posts folder
Rebuild the pblog with make
Use the built-in sync function of Transmit to mirror my local _output with my web server

Wrapping Up

Will there be bugs with this switch-over? Most likely. Will some URLs be left behind or broken? Possibly. These small issues will be ironed out over time. For now, I'm quite happy with keeping things minimal on the workflow side of things, while preserving accessibility and user experience with the output.

Thanks for reading!

Happily Paying For macOS Apps

2022-06-29T10:00:00Z

Happily Paying For macOS Apps

2022-06-29

It's no secret that I am a huge advocate for open source software. A solid chunk of my day-to-day workload is done so via FOSS[^0] systems. I also manage a handful of fun side projects that are normally shipped under either MIT or GPL licensing. But that doesn't mean I still don't enjoy some non-free, proprietary software.

So, I thought I would share my collection of macOS applications that I happily paid for. (There aren't many since my needs are limited)

Design Tool: Sketch

My day job requires me to use Figma, which is totally fine but not nearly as polished as Sketch. Yes, Figma is cross-platform. Yes, Figma can run directly in the browser. Yes, Figma is free for most smaller team sizes.

But sorry - Sketch is just better.

Since the team at Bohemian Coding have crafted Sketch specifically for macOS it feels native, runs extremely well and fits in with the rest of the ecosystem. The pricing model is okay in my books too, balancing a fine line between optional yearly subscriptions and one-time purchases. It's a smart move and I much prefer it to a forced subscription plan.

URL: https://www.sketch.com/

Password Manager: Secrets

I was originally a subscriber to 1Password but couldn't justify spending $7CDN a month for what it was offering. Also, subscriptions suck. After doing some research I stumbled upon Secrets and noticed some things about it that instantly caught my eye:

No subscriptions! One-time price forever.
iCloud Sync across devices
Browser extension support (although I don't use this personally)
Developed by a one-man team (support indie devs!)

I purchased both the macOS and iOS versions of Secrets after trying out the free version almost immediately. It's wonderful. The UI is clean and flows well with the rest of the Mac ecosystem to give it a native "Apple" feel. Syncing my laptop and iPhone works seamless via iCloud.

And best of all - no monthly fees.

URL: https://outercorner.com/secrets-mac/

Transferring Files: Transmit 5

The folks at Panic make incredible Mac and iOS apps. I see them as one of the best in the industry. In the early days of my web development career, I used to run Coda exclusively. I've since moved on the Sublime Text but I still have fond memories of the old Panic editor.

As for FTP access, I still use Panic's Transmit to this day. Beautiful UI that feels snappy even when transferring massive files across servers. Transmit is also a one-time purchase. Thank goodness. (Have I mentioned that I hate software subscriptions?)

URL: https://panic.com/transmit/

Wrapping Up

I know this list only includes 3 applications, but that's truly all the ones I've spent money on. If in the future I happen to purchase any others I will be sure to update this post accordingly.

Refs

Free & open source software

Over-Nesting

2019-01-06T10:00:00Z

Over-Nesting

2019-01-06

I think since our design industry moves so quickly and exciting new technologies get released almost daily, that we often forget some of the basics when writing CSS. I bring this up because I've recently worked on a few projects that show a slight disregard for proper class/selector nesting.

Now it's completely understandable why designers and teams alike shrug off the concept of "over-nesting":

As a team we know the structure of our code (no outside party needs to interact with it)
Everything is written in insert pre-processor here - so it's cleaner/compiled anyway
It's technically DRY

I personally believe these are all weak excuses that don't justify the poor experience future maintainers of your code will face. You should always write your code with the idea someone completely new to the project will have to maintain it.

Let's look at an average example of poor nesting that I've seen out in the wild:

/* These children elements can't be used outside 
+of the parent - not very flexible */
+.main-container {
+    .child-container {
+        /* This class specificity is too deep */
+        .sub-child-container {}
+    }
+}
+

Even if you know a child element will never be structured outside of it's parent, what harm does it cause to still place it out of such deep specificity?

/* This code is far more reusable */
+.main-container {}
+.child-container {}
+.sub-child-container {}
+

Exceptions

As with anything, there are exceptions to the rule. If the nested elements pertain to the parent itself, it makes complete sense to group these stylings together. A button or link item are excellent examples of this:

.btn-lg {
+    &:hover {}
+    &:active {}
+    &:disabled{}
+}
+
+.link-item {
+    &:hover{}
+    &:focus{}
+}
+

Of course, this is all easier said than done. Limitations exist within teams or even on an individual level that might make this impossible to change. Maybe you don't have the authority to rework your current CSS or it would eat up too many cycles and time is valuable - especially in the world of startups.

I'm not saying this is the only way to structure CSS - I'm only trying to make the lives of future designers/developers easier moving forward.

Over-Engineering an Oil Tank Gauge

2020-09-09T10:00:00Z

Over-Engineering an Oil Tank Gauge

2020-09-09

I almost went down the path of investing a huge amount of time and effort into fixing a stuck oil fuel tank float-gauge in my house. Recently, the float mechanism became stuck and permanently displayed empty regardless of how much fuel was in the tank - not ideal. It's a 20 year-old tank, so I wasn't surprised that the float finally gave out.

Being the wannabe tinkerer that I am, a light bulb went off in my head and I started thinking on how to incorporate some ultrasonic system to display the accurate fuel reading digitally. Obviously my first thought was just to replace the float gauge with a new one and be done with it. That didn't sound very fun though.

I briefly looked at other similar projects and started brainstorming the best way I would implement this for my own situation. The best option I came across seemed to be this: DIY Ultrasonic Fuel Gauge / Level Sensor

An ultrasonic system with a cool mini display sounded pretty rad - much cooler than just replacing the broken gauge with a new float arm. So it was settled.

My oil think-tank

I quickly thought through my options in my head before jumping too far into things (and even included a "poor-mans" temperature strip option):

+ + + + + +

Solution	Cost	Time
Ultrasonic Gauge	$40-50	~2-3 hours
New Float Gauge	$25-30	~45 minutes
Temperature Strips	$10	~2 minutes

+My mind was still set on building and implementing the ultrasonic option. It would be a great learning experience at the very least!

So, before I ordered any parts or started designing a case that would house this new super-cool device, I went to investigate/remove the float gauge to get a better look at the damage. With the help of some penetrating oil (the original installer went crazy with the pipe dope) and my trusty wrench, I opened up the gauge cap, partly lifting the float from the tank. Right away I noticed that the float and shaft were slightly stuck together in one small area. I poked it with my finger.

The float set itself back into the correct position. It was fixed.

How could I have been so dumb. I was so excited about building something that I jumped into implementation before fully realizing the problem. Talk about a metaphor for web dev, am I right?

Overthinking simple problems

I can't speak for all designers / developers out there, but I catch myself (far more often than I'd like to admit) over-engineering a solution because of some perceived notion that it is the "best" option. Most of the time it isn't actually better, it just seems more fun.

Now don't get me wrong, fun is a good thing most of the time. It's just that some instances call for the quickest, cleanest, easiest solution in the name of efficiency - just be sure to have fully explored the problem first.

Final decision

So I ended up doing nothing. I simply re-threaded the cap and placed the float back inside the tank. I know I saved myself time and money, but I can't help but feel like I failed...

Just like in the world of software, it's best to avoid over-engineering simple problems.

Open Source Typeface Pairings

2018-01-25T10:00:00Z

Open Source Typeface Pairings

2018-01-25

I always love finding new typeface pairings to use across my personal and client projects, but I find many suggested pairings come with a hefty price tag (rightly so - premium typefaces are normally always worth their cost).

So, I've curated this personal list of 5 exceptionally beautiful typeface pairings that will cost you absolutely nothing. Open source FTW.

ET-Book & Gill Sans

Download: ET Book, Gill Sans

+ +

ET-Book & Gill Sans are based off the font pairings of my personal Jekyll theme: ET-Jekyll Theme.

Playfair Display & Roboto

Download: Playfair Display, Roboto

+ +

Playfair Display & Roboto I find work really well for microblogs or short essay format posts.

Karma & Open Sans

Download: Karma, Open Sans

+ +

Karma & Open Sans give readers a little more breathing room between characters. Good choice if trying to keep accessibility in mind.

Libre Baskerville & Oswald

Download: Libre Baskerville, Oswald

+ +

Libre Baskerville & Oswald oozes character and takes inspiration from a more print-based medium.

Fanwood & League Spartan

Download: Fanwood, League Spartan

+ +

Fanwood & League Spartan paired together allow the main content to be easily readable, while the headers instantly grab the user's attention.

Building openring with Jekyll Build

2022-12-02T10:00:00Z

Building openring with Jekyll Build

2022-12-02

I think it's great when bloggers post their own personal "reading list" of blogs they themselves follow. Whether this is a customized Blogroll page or footnotes in their individual articles, I find it really helpful to find more interesting content on the "indie" web. This isn't a new concept by any means, but I wanted something a little more "dynamic"[^1] for my own blog.

After some digging I came across openring and it's great. Fully customizable, lightweight and completely open source. What more could you ask for?

So, I thought others might be interested in how I've implemented openring through my own Jekyll build system.

Installing openring

You can pull the project directly via SourceHut if you wish, but I would recommend installing through your default package manager. I'm running Arch, so for me it was as simple as running:

yay -S openring
+

That's it. I now have full local access to openring!

Jekyll Includes

You could setup a whole new directory specifically for your openring files, but that seems like overkill. Instead, we will simply add two new files to our existing _includes directory. We will name these files openring-in.html and openring-out.html.

openring-in.html Contents

<!-- License-Id: CC0-1.0 -->
+<section class="webring">
+  <h3>Articles from blogs I follow around the world wide web</h3>
+  <section class="articles">
+    {{range .Articles}}
+    <div class="article">
+      <h4 class="title">
+        <a href="{{.Link}}"  rel="noopener">{{.Title}}</a>
+      </h4>
+      <p class="summary">{{.Summary}}</p>
+      <small class="source">
+        via <a href="{{.SourceLink}}">{{.SourceTitle}}</a>
+      </small>
+      <small class="date">{{.Date | datef "January 2, 2006"}}</small>
+    </div>
+    {{end}}
+  </section>
+  <p class="attribution">
+    Generated by
+    <a href="https://git.sr.ht/~sircmpwn/openring">openring</a>
+  </p>
+</section>
+<style>
+.webring .articles {
+  display: flex;
+  flex-wrap: wrap;
+  margin: -0.5rem;
+}
+.webring .title {
+  margin: 0;
+}
+.webring .article {
+  flex: 1 1 0;
+  display: flex;
+  flex-direction: column;
+  margin: 0.5rem;
+  padding: 0.5rem;
+  background: #eee;
+  min-width: 10rem;
+}
+.webring .summary {
+  font-size: 0.8rem;
+  flex: 1 1 0;
+}
+.webring .attribution {
+  text-align: right;
+  font-size: 0.8rem;
+  color: #555;
+}
+</style>
+

Sidenote: You will get minor Liquid Syntax warnings in the console when running your website via serve or build. I don't really mind those warnings but if you do, feel free to move these files out into their own sub-directory in your project folder.
+

openring-out.html Contents

This will generate itself for us every time we rebuild our Jekyll website. It is important to note that any changes you make in this file will be overwritten the next time you rebuild! All custom styling or layout changes should be made in the openring-in.html file.

Our "New" Build Script

To simplify things, we are going to place our main commands in a single build script in the root directory of our Jekyll project. For my personal blog, I've named this file build-site.sh. I know - I'm extremely creative.

Place the following inside that file:

openring \
+  -s https://example.com/feed.xml \
+  -s https://example.com/feed.xml \
+  -s https://example.com/feed.xml \
+  < _includes/openring-in.html \
+  > _includes/openring-out.html
+bundle exec jekyll build
+

Edit `_config.yml`

Next we need to make sure we exclude our new build-site script file, since we really don't need that pushed up to the main server:

# Includes / Excludes
+exclude:
+  - build-site.sh
+

Almost Done...

Now you just need to decide where you want your openring feed outputs to render. For this example, we will place them at the bottom of every blog post inside the _layouts/post.html file, like so:

{% raw %}{% include openring-out.html %}{% endraw %}
+

Build It & They Will Come

This next step is only for those using SourceHut Pages to build and host their websites. If you use a different platform (ie Netlify, Vercel, GitHub Pages) the concept should be similar but will most likely require more tweaking on your end. Just a fair warning.

I won't go into great detail about build script for SourceHut Pages, but feel free to take a look at my very own build file for this website. That should work out-of-the-box for most standard Jekyll websites. (Just be sure to edit with your own details!)

That's it. You now have links to blogs you enjoy that will update with each build. Of course, the "latest" blog posts shown will become out-of-date if you don't blog (or at least re-build your website) on a regular basis. But for me, I see this as a good motivator to keep pushing out content!

Happy sharing!

Refs

Well, as dynamic as a static website can be!

My Coffee Maker Just Makes Coffee

2023-01-09T10:00:00Z

My Coffee Maker Just Makes Coffee

2023-01-09

I had to replace my dual Keurig coffee maker twice over a period of five months. This occurred a year ago and these are my findings.

Built to Fail?

I followed the manufactor's suggested cleaning schedule and took care of the appliances. My initial conclusion was that the product's design wasn't thought-out well. "It's built to fail!" I said to my wife the morning of the second machine's failure. Another product replaced under warranty, while the broken one's tossed aside. More e-waste because why not?

But after some further reflection, I came to realize the "poor design" was a symptom of a greater cause:

The product tries to do too much.

I'm beating a dead horse by referencing suckless software again, but that core philosophy applies here too. Both digital and industrial design suffer from bloat. Far too often I witness fellow designers over-engineer customer requests. Or they add excessive bloat to new product features. It's almost a rarity these days to find designers who tackle work as single items. Everything expands. Everything needs to do one little extra "cool" thing. Nothing is ever taken away.

I'm sure the designers meant well with the creation of this dual coffee maker. It's interesting to combine both a standard 12-cup percolator and "pod-based" serving options. In theory it sounds quite handy. One appliance that tackles two use-cases. Think of the counter space you'll save!

Unfortunately, in practice, it fails.

Product Decline

I've felt product quality decline in both household appliances and software. Companies no longer seem content with doing one thing well. Everyone needs to reach out into many verticals. Everyone copies their competitors.The need to "grow" their existing features. Adding things that no one asked for. Products are getting slower and losing focus.

People tend to place all that blame on top-level management or developers. They do deserve some blame - but not all. Designers cause a lot of these issues on their own and it's easy to understand why.

The design field drops new designers into a world of bloat. They don't stand a chance. The initial programs introduced to them are behemoth, proprietary pieces of garbage. No other options are available. No one is making strides in this field of "design tool software" because it's a massive uphill battle. Those that try, get snatched up by existing platforms. Designers don't have the luxury of "choice" as much as developers do (within reason). It's a very locked-down industry.

So of course designers will carry this mentality into their own work. It's all they have known. "X and Y companies designed their insert-feature-here with all these extras, so we'll do the same". Everything is a copy of a copy of a copy.

The only advice I can give to designers is this: try not to add to the problem. I'm not asking you to move mountains. But consider working somewhere else if your career only adds more bloat to the world. (Easier said than done, I know). Or keep doing what you're doing. What do I know - I'm only some guy who rambles on the web. +

Back to the Coffee Maker

So the Keurig is gone. Trashed. The company doesn't want the product back, they tell you to scrap it. "We'll send you a new one for free". Such a waste.

Instead, I snagged the cheapest and most basic coffee maker I could find. It cost me $12. It has no clock, no programming options, no base settings or cleaning functions. Hell, there aren't even level numbers on the water reservoir tank.

You add your scoops of coffee grounds, along with desired amount of water. Then you switch on the (only) button at the side of the machine. After a handful of minutes, you have coffee.

And it's been running perfect for over 8 months now. I clean it every so often by brewing with a small mixture of vinegar and water. That's it. No need for "specialty cleaners" that cost almost as much as the machine itself. The points of failure get reduced as well, since the machine is bare-bones. Nothing can break when there is nothing to break...

"Brewing" Software

At least, for me, I plan to only design what needs to be. If someone asks for a "coffee", they'll get a cup of hot, black coffee and nothing else.

Billing for One CSS Change

2019-11-29T10:00:00Z

Billing for One CSS Change

2019-11-29

Every second you spend working as a designer should be billed back to the client. A simple button color change? Bill them. Additional links added to an existing menu? Send that invoice over. Some basic typeface changes? Don't do it for free.

You need to be charging for all design work, regardless of difficulty or time required.

This concept might seem extremely obvious to more senior level workers but I have seen a good amount of junior devs make the mistake of "working for experience" or better yet "strengthening the client relationship". Early on in my career I was just as guilty of doing this kind of thing. It was and still is a very foolish practice.

Do you really bill for one CSS change?

Absolutely. From the client's perspective it may seem like they are being billed for one CSS change and 30 seconds of a designer's time. In reality, they are paying for the designer's years of experience to be able to solve that problem in only 30 seconds.

Would the client be happier with a significantly less qualified designer charging the same amount of money but taking 3 hours to complete the task? In the end, what's the difference?

If it is a simple change that they believe should cost nothing, then why aren't they doing it themselves?
+

We as developers and designers work in an odd industry. A lot of people (read clients) outside of our bubble tend to think they have a much better understanding of the work we do. Because of this, they tend to preface work requests with phrases like:

"This should be a simple change"
"This shouldn't take more than a couple of minutes"
"This seems like an easy fix"

Most of the time these comments are harmless, but other times they are a subtle way of downplaying your skill and experience required to complete these work items. That skill and experience shouldn't ever come free. It makes you wonder if these same people expect free work from trades-people (electricians, plumbers, etc) when they need what they think is a "simple" fix in their house.

Do you think workers in most other industries travel out to someone's home and fix "small" issues for free? Hell no.

So why are developers and designers doing work for free? I truly don't know - but it needs to stop.

A simple but useful system

You should live by the rule that every second you spend working for someone else is billable. I don't mean that you should literally bill per second, but instead round to nearest estimated time slot (whether you are billing hourly, daily, sprint-based or per project). This ensures that your efforts are paid for and that the client will begin to truly value your time. Doing this from the get-go will save you headaches in the future.

I'm sorry if this comes off as preachy, but I'm just trying to inspire designers to value their work more. Don't sell yourself short - your talent is valuable and shouldn't be taken for granted.

Obvious Javascript 'Injection' Fallback

2020-12-04T10:00:00Z

Obvious Javascript 'Injection' Fallback

2020-12-04

Sometimes websites and web apps might require content to be "injected" via Javascript. I should mention that I am strongly against this practice - but often this kind of thing is out of one's hands. So, the least I can do is setup these "injections" to have proper fallbacks for users who disable JS. You would be surprised how many developers build empty HTML elements with the assumption they will be filled via Javascript.

Our Hypothetical Project

Let's pretend that we have a total tally that pulls in the number of current users using our fake SaaS app. We would do something like this:

HTML

Here we create an empty h2 tag that will update with the current number of users via js:

<main>
+    <h2 class="total-tally"></h2>
+</main>
+

Javascript

You'll have to use your imagination here and assume that the totalTally variable pulls in the numbers dynamically via API:

var totalTally = "273,677" /* This would pull something dynamically in prod */
+document.getElementsByClassName("total-tally")[0].innerHTML=totalTally;
+

The Problem

The big issue we have now occurs when a user visits this page without JS enabled. The h2 tag will remain empty and they won't see anything. I know this seems like a very avoidable issue, but you would be surprised how often it actually happens on the web.

The (overly simple) Solution

The easiest way to avoid these types of empty tags - add static content. I know - mind blowing, right?

HTML (updated)

<main>
+    <h2 class="total-tally">200,000+</h2>
+</main>
+

You might be reading this and saying to yourself, "Wow! Thanks Captain Obvious!" and that's a fair reaction. This is an obvious demo on purpose. If even one single reader learns to avoid leaving empty HTML tags that are solely dependent on Javascript injection, then I'd say this demo was a huge success.

Rule of thumb: don't make assumption about your users. Play it safe.

RE: Creating a Simple HTML/CSS Notice Box

2022-09-22T10:00:00Z

RE: Creating a Simple HTML/CSS Notice Box

2022-09-22

I recently read Kev Quirk's post, How to Create a Simple HTML/CSS Notice Box and loved the simplicity of it. I'm a sucker for using pseudo elements in creative ways but still managing to make them useful. Of course, this got me thinking as to whether or not the same style of box could be achieved without the use of static, pseudo elements...

Bad Semantics

I need to make it clear right away: these implementations are not semantic. They are valid HTML, but I am technically using these tags incorrectly. You have been warned!

Setting Fieldsets

The first approach is to wrap everything inside HTML fieldset tags:

<fieldset>
+    <legend>Notice</legend>
+    <p>Lorem ipsum, dolor sit amet consectetur adipisicing elit. Totam nihil velit vitae sed beatae earum assumenda deleniti, inventore repellendus, sequi distinctio delectus porro explicabo quidem hic quo quasi voluptas temporibus.</p>
+</fieldset>
+

Then you can include minor styling to closely match the design of Kev's notice box:

fieldset {
+    border: 3px solid;
+    font-family: sans-serif;
+    padding: 30px 10px 10px;
+    position: relative;
+}
+fieldset legend {
+    background: #AACCFF;
+    border-bottom: 3px solid;
+    border-right: 3px solid;
+    left: 0;
+    margin: 0;
+    padding: 5px 10px;
+    position: absolute;
+    top: 0;
+    text-transform: uppercase;
+}
+

The Devil is in the Details

The other option is utilizing the HTML details tag:

<details open>
+    <summary>Notice</summary>
+    <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Assumenda sequi esse reprehenderit facilis aperiam labore optio minus doloremque nesciunt! Voluptatem esse tempore asperiores recusandae rerum facere, reiciendis officia repudiandae similique?</p>
+</details>
+

You'll obviously want to include the open attribute to avoid users needing to toggle the content manually (unless that is your desired UX). Then add similar styling options to match the fieldset example:

details {
+    border: 3px solid;
+    font-family: sans-serif;
+    padding: 0 10px 10px;
+}
+details summary {
+    background: #AACCFF;
+    border-bottom: 3px solid;
+    border-right: 3px solid;
+    display: inline-block;
+    margin-left: -10px;
+    padding: 5px 10px;
+    text-transform: uppercase;
+}
+

Important to note: you can hide the default "arrow toggle" on summary elements by including the following:

details > summary {
+list-style: none;
+}
+details > summary::-webkit-details-marker {
+display: none;
+}
+

Seeing is Believing

I've put together two versions of each implementation (one custom designed and one using default browser styling). You can check them out in the CodePen below:

Live CodePen Example

News Websites Are Dumpster Fires

2019-05-29T10:00:00Z

News Websites Are Dumpster Fires

2019-05-29

Online news outlets are a dying breed and many users have decided to consume information elsewhere. Why? Because the news industry has become a cesspool of anti-consumer and blackhat practices that has eroded trust for the sake of money.

What news sites get wrong

I could write up an entire essay about all the shady practices that most news sites are guilty of, but here are just a few top level issues:

Clickbait headings with misleading information
Disabling the user from reading if ad-block is present
Tracking the user with 3rd party scripts
Taking massive performance hits (specifically on mobile due to huge JavaScript blocks)
Pop-up ads
Fixed headers or footers which leads to harder readability / accidental element interactions

But they need ad revenue!

If your business is solely dependent on tracking scripts, tricking users with clickbait titles and using archaic ads - then you're destined to fail regardless. These practices create an unsafe and unhealthy web for everyday users - not to mention most browsers have announced that future updates will be blocking ads by default. News outlets need to adapt or die.

What's the solution?

I don't have a fix all band-aid to replace current revenue streams for news websites. I'm sure someone much smarter than I can come up with better ideas, but just off the top of my head:

Switch over to a monthly subscription plan (if no one pays for it maybe you weren't as useful of a source as you thought)
Partner with brands to create sponsored articles (without ruining the user experience of course)
Place a larger emphasis on user donations or promotions

The News Shouldn't be Spam

Most traffic flowing into news websites are there for one thing: the content. News outlets should not be spamming their main revenue supply (the users) or misleading people with false information.

If you're a regular consumer of news and you happen to run across a platform that is guilty of any of these practices, shoot them an email explaining why you won't be returning to their website (unless they change their ways). These anti-consumer practices will only stop when these organizations start losing money.

Using Netlify for Dynamic URL Redirects

2021-12-03T10:00:00Z

Using Netlify for Dynamic URL Redirects

2021-12-03

With the recent domain switch that took place on this website, I needed to have a dependable setup to forward my old domain URLs to the new one. While using something like "URL forwarding" through your domain provider could work, it doesn't natively support dynamic linking. Let me explain using a basic example:

A user clicks on a link that targets a post on your old domain:
olddomain.com/random-post
You want that link to forward using the same permalink structure:
newdomain.com/random-post
"URL forwarding" through your domain provider does not support this

Simple stuff. So, let's breakdown how to easily set this up on Netlify for free.

Setting Up Netlify

Create an account (or login to an existing one) and setup a new site[^1]
Change your "old" domain name nameservers to match Netlify's (normally done through your domain register) +
- dns1.p03.nsone.net
- dns2.p03.nsone.net
- dns3.p03.nsone.net
- dns4.p03.nsone.net
+
Back in Netlify: under Domain Settings you need to add your custom "old" domain under the Custom domains section under Domain management
Lastly, add the following content inside a _redirects file (no extension) to your website content/build (changing to your own domains, of course)

https://olddomain.com/* https://newdomain.com/:splat 301!
+

That's it! Now Netlify will dynamically forward all your pre-existing URLs from your old domain to the new one. No pesky .htaccess files or running your own basic web server(s)!

Hopefully this helps others trying to dynamically redirect their domains without the headache.

Refs

I normally set this up through Github / git hosting

CSS: Indenting Text

2019-04-05T10:00:00Z

CSS: Indenting Text

2019-04-05

A lot of developers tend to do the bare minimum when it comes to implementing proper website typography. This isn't an insult - I'm happy that typography is given any thought at all during development, I just believe more can always be done to improve upon it.

In today's TypeTip we're going to play around with the text-indent property, look into when it's best to use it and how to implement it properly.

The property and browser support

Browser support is actually pretty great for such a regularly over-looked CSS property. All major desktop and mobile browsers support it:

+ +

Full support across all browsers.

Now that doesn't mean you should just slap this property on all your type elements and call it a day - there are specific use cases for text-indent and some basic rules to follow:

Use Cases

Increasing readability of large text blocks that would otherwise overwhelm the reader
Replicating book or report typography layouts

Basic Rules

Best to set this property on inner type children only - meaning items like p or blockquotes instead of main headings
When used on paragraph tags it's best to target only p elements that directly follow a sibling tag (see "The CSS" below)

The CSS

Adding the property is extremely trivial, all you need is the following:

/* Best practice for paragraphs */
+p + p {
+    text-indent: 1rem; /* whatever you want */
+}
+

Let's see it in action

Live CodePen Example

My Static Blog Publishing Setup and an Apology to RSS Subscribers

2022-03-21T10:00:00Z

My Static Blog Publishing Setup and an Apology to RSS Subscribers

2022-03-21

In case you missed it, this website is now generated with pure HTML & CSS. Although, generated isn't the proper way to describe it anymore. Written is a better description.

No more Markdown files. No more build scripts. No more Jekyll. Clean, simple, static HTML & CSS is my "CMS". More on that in a moment. First, I must apologize.

I'm Sorry Dear RSS Subscribers

RSS feeds are tricky things for me personally. I always botch them with a site redesign or a re-structure of my previous posts. Those of you subscribed via RSS were likely bombarded with post spam when I rebuilt this website. Sorry about that - I know how annoying that can be.

Fortunately, that all stops today. Moving forward my RSS feed (Atom) will be edited manually with every new post I write. Each entry will feature the post title, post url, and post date. No summaries or full-inline content will be included (since that would involve a great amount of extra overhead). RSS subs will need to follow the link directly if they are interested in the article itself. I hope this doesn't anger too many readers...

Again, sorry everyone.

What is this New Blog "System"

This publishing flow isn't for everyone and is less flexible than pre-existing static site generators (referred to as SSGs moving forward). For me though, it works. I find it more flexible than most SSGs.

There are a couple articles that explain the reasoning behind this system better than I could (plus, why would I repeat the same points?):

So, what does my blog-posting system look like?

Simple Explanation

Copy an existing article's HTML file
Change file name, edit the page title, heading, post date and comment link
Write the new article content
Make manual new entry in RSS feed
Save changes, push to git repo
Sync new file(s) / changes to remote server

Pretty simple, eh? Let's break things down into greater detail though...

Detailed Explanation

Text Editor

I code and write everything exclusively in Sublime Text on my MacBook Air. I know, it's not an open source editor, but I love how incredibly fast and intuitive it is. I used VSCode in the past but ended up requiring far too many plugins to get things setup the way I like it. Sublime Text works best for me even right out of the box. (I do need Emmet and theming changes though).

I perform the following for a new article:

Copy an existing article, ie. blog-post-1.html
Rename article file name, ie. blog-post-2.html
Open this newly created file and change: +
- page title tag
- page h1 heading and top bar text
- time tag to match publish date
- comment mailto: link url
+
Start writing content inside the article section

Once the article is complete, I add a static entry in my feed.xml and run a crude rsync script. More on that below.

Git

Normally I would pull, commit and push directly in my Terminal - but lately I've been enjoying my time using Sublime Merge. I'm a sucker for visually appealing GUI applications and Merge is the perfect balance of simplicity and beauty. I recommend it if you haven't tried it yet.

Hosting

This blog is now hosted through NearlyFreeSpeech. I could opt for a free service like Netlify or DigitalOcean Apps but I feel it's important to help support communities that align with my own core beliefs. From their about page:

NearlyFreeSpeech.NET is about three things: fairness, innovation, and free speech.
+

Hard to argue with those principles. If you're feeling generous, I'd greatly appreciate anyone who considers contributing to offset this website's hosting costs through NearlyFreeSpeech (code: tdarb). No money is directly handed to me, it pays NFS directly for hosting fees. Donate if you feel like this humble blog of mine has helped you in any way. No pressure!

NFS gives me server access via SSH (and even SFTP if I desire) which makes things simple to sync my local files with production code. This is handled via rsync with a basic deploy.sh script:

rsync -vrzc --exclude 'deploy.sh' --exclude '.git' --delete ./ username@my.remote.nfs.server:
+

The included parameters ensure files with a conflicting checksum are updated on the server, instead of re-syncing all the files every time the script runs. That would be overkill.

Closing Thoughts

I love this new setup. It's portable, lightweight, has zero dependencies, and gives me the opportunity to write directly in HTML. Others may find this workflow idiotic or cumbersome but I couldn't disagree more. Site wide changes can be made with simple Find/Replace actions or even whipping up a basic script. Things should be as complex as you wish to make them!

At the end of the day, anything that helps you be more efficient and gets you producing more content is a winning strategy in my book. Who knows, this concept could even inspire one random reader out there to do the same.

My Raspberry Pi Desktop

2020-09-02T10:00:00Z

My Raspberry Pi Desktop

2020-09-02

I use a Raspberry Pi 4 as my personal daily driver and it's pretty great. I know these types of devices tend to be used for smaller pet-projects or fun experiments, but I thought I would share my experience using one as my main computer. Hopefully this can be a solid guide to help others who might be interested in creating a similar setup.

My desktop Pi working away on a regular morning:

+ +

The final Raspberry Pi desktop in all it's glory. (direct link to image)

My Use Case
The Hardware
The Software
Performance & Stats

My Use Case

I'm a web designer and developer by trade. Therefore, I require a decent amount of functionality from my computer - more than just simple web browsing and document editing. When I first set out testing if the RPi4 could become my main device, I was surprised at how capable the hardware / software was at running all my required applications. My workload comprises of:

Using Github/Gitlab to pull/push repos, open PRs, etc
Run SSG (Jekyll mostly) locally for testing
Run multiple WordPress instances locally
Edit design files (Photoshop, Illustrator, direct SVGs)
Simple web chat / email

Basic stuff, but I was originally doubtful of the RPi4 to be able to handle it all smoothly. I'm happy to say I was wrong.

The Hardware

The following hardware list is what I use specifically for my intended use case. I'm also a sucker for having cool looking SBC builds. By no means is this the "best setup" for everyone - I'm sure other combinations of gear might better suit your own personal needs.

Note: products in the hardware section are Amazon affiliate links
+

Raspberry Pi 4
X857 V1.0 mSATA SSD Shield Expansion Board (I'm using the X856)
128GB mSATA SSD
Acrylic Case with Heatsinks & Fan
Raspberry Pi Keyboard & Mouse
21.5" Acer Monitor

The Software

The 32-bit version of Raspberry Pi OS ('Debian Buster' at the time of writing) is my OS of choice. Stable, reliable, and officially supported by the RPi community. It does the job.

The Pi has been overclocked to 2GHz in order to squeeze just a little extra out of the hardware. This has caused zero issues.

I'm also booting directly from the mSATA SSD (via USB booting) instead of relying on a slower microSD card. You can find tons of tutorials online on how to do the same, but I would recommend this one: How to Boot Raspberry Pi 4 From a USB SSD or Flash Drive

After that, I simply installed my required apps / configs (where applicable):

Chromium (preinstalled)
Firefox ESR
Pale Moon
Code OSS
Terminal (preinstalled)
Libre Office Suite
Evolution
Figma (Web - no install needed)
Apache2 / MySQL
Blueman (helpful GUI for bluetooth)

What my plain desktop looks like:

+ +

My very basic Raspberry Pi desktop/wallpaper view. (direct link to image)

Performance & Stats

Using this build day-to-day, I can honestly say I don't hit any hiccups or lag at all. Multiple applications and WordPress instances are running in the background, while 10-15 tabs are open in the Chromium browser. The little Pi just chugs along without breaking a sweat.

My average CPU temperature sits around 51° (with heatsinks & fan active) while CPU usage never really cranks past 90% during even "intensive" processes.

Since actual data speaks louder than anecdotal chit-chat, I performed a very simple read/write test on my mSATA SSD.

First, clear the cache to avoid conflicting data:

sync; echo 3 | sudo tee /proc/sys/vm/drop_caches
+

Write

Write script run:

dd if=/dev/zero of=~/test.tmp bs=500K count=1024
+

Write output:

524288000 bytes (524 MB, 500 MiB) copied, 1.95478 s, 268 MB/s
+

Read

Read script:

dd if=~/test.tmp of=/dev/null bs=500K count=1024
+

Read output:

524288000 bytes (524 MB, 500 MiB) copied, 0.770993 s, 680 MB/s
+

This gives a total read/write value of: 268 MB / 680 MB per second. Compare that to average microSD card speeds floating around 22 MB / 170MB per second and you can see (and feel) the massive speed difference. Things are just snappier.

Note: Obviously extremely high-end (read: expensive) microSD cards might hit read/write speeds similar to that of an SSD. The issue is that you are more likely to corrupt or reach end-of-life with a microSD card - hence why I don't recommend them.

Final Thoughts

I love that I can use a fairly cheap Raspberry Pi 4 as my main, personal desktop. Of course, some people might roll their eyes at this build and say, "why not just get a cheaper, more powerful laptop off eBay?". To that I would respond: you're missing the point.

It was fun to put together this simple desktop. The fact that it runs fast and stable enough to be my daily driver is a great bonus. If this build interests you at all, I highly recommend giving it a go.

Using Multiple CSS Background Images

2018-09-28T10:00:00Z

Using Multiple CSS Background Images

2018-09-28

It isn't something developers have a need to do very often, but you can set multiple background images on a single element.

Example:

.element {
+    background: url('image_path') center repeat, linear-gradient(transparent 0%, #000 100%) no-repeat;
+}
+

What can you do with this? It's only limited by your imagination, but I'm personally a fan of always using as few elements as possible when working on a project.

Why I Stopped Using an External Monitor

2023-03-03T10:00:00Z

Why I Stopped Using an External Monitor

2023-03-03

For the longest time I've been using a Samsung 27" UHD monitor as my main display. This monitor was connected to my ThinkPad X260 (in clamshell mode) through the official Lenovo dock. It wasn't a bad setup, but I have since changed my ways.

Instead, I now only use the X260's panel as my main display. Let me explain my reasoning...

The Switch to Suckless

Over the past year I switched away from a traditional desktop environment to a window manager - dwm to be specific. This also involved changing most of my daily software programs to utilize the full suckless "suite". In doing so, the shift away from floating windows and virtualized desktops happened quickly.

I continued to use my UHD monitor with this new environment but slowly started running into minor (yet still inconvenient) roadblocks:

Tiled mode was not the most optimized for such a large monitor. I found myself defaulting into "floating" mode which defeats the purpose of a WM.
The screen was almost too large - making content placed on the far edges of the screen difficult to view at a glance.
I stopped using tags, since I ended up piling applications on top of one another in a single view. Again - defeating the point of a WM.

All of these issues were close to making me ditch the external monitor altogether, but it was my day-to-day job that struck the final blow...

Designing for Everyday Users

As a UX/UI front-end designer by trade, my job requires me to create and tweak interfaces that essentially go unnoticed by the end-users. If you finish a task you sought out to complete without even thinking about how you did it - then I succeeded at my job. The problem is, we designers and developers tend to forget the constraints a majority of our users experience. In this case - screen resolution.

A study performed by BrowserStack via statcounter (2022) shows the worldwide market share based on device type:

58.33% mobile
39.65% desktop
2.02% tablet

The mobile aspect is certainly important, but we are focusing on the desktop data. Of that total the top two screen resolutions are:

1920×1080 (9.94%)
1366×768 (6.22%)

That is a fairly significant chunk of desktop users. Although almost 10% have access to screens set at 1920x1080, I found the amount of those stuck at 1366x768 to be quite shocking. Here I was, developing large-set interfaces on an UHD 4K monitor while a large portion of my end-users would never benefit from those "pixel-perfect" designs.

Hell, some of these users were being shown the tablet-based view of the applications since our breakpoints were so ridiculously large. Yikes.

So, I said screw it and retired the external monitor. Now my X260 is propped up and proudly showing off its 1366x768 display. It only took a day or so to adapt to this new setup and I don't think I could go back to another massive display.

Here are some benefits at a glance:

I no longer have to worry about "context switching" if I decide to un-dock my laptop and work somewhere mobile. The desktop experience remains intact.
Working inside dwm is a much cleaner experience. I mostly operate single applications within their own confined tag - with some exceptions of course.
I'm able to instantly understand frustrations of everyday users while developing new features or tweaking existing UIs. Being able to advocate for our end-users by using legit use cases is extremely helpful. (Removes the "design by gut-feeling" mistakes)

+ +

My ThinkPad X260, along with my MageGee wired mechanical keyboard and Logitech Pebble mouse. Small notebook and pen for note-taking.

A Little Extreme

Yes, I am aware that I could simply keep the UHD monitor and perform my work within a constrained portion of the screen. The problem that remains is "quality". Most 1366x768 panels are not even close to the level of hi-res found on most 4K monitors. By using such a display I would be cheating myself of the standard experience a good portion of my end-users endure.

I want to see the fuzzy text, slightly blurred imagery and muted button shadows. I want to see these things because that's how some users will experience it.

Maybe that's extreme - but it works for me.

Installing Older Versions of MongoDB on Arch Linux

2023-09-11T10:00:00Z

Installing Older Versions of MongoDB on Arch Linux

2023-09-11

I've recently been using Arch Linux for my main work environment on my ThinkPad X260. It's been great. As someone who is constantly drawn to minimalist operating systems such as Alpine or OpenBSD, it's nice to use something like Arch that boasts that same minimalist approach but with greater documentation/support.

Another major reason for the switch was the need to run older versions of "services" locally. Most people would simply suggest using Docker or vmm, but I personally run projects in self-contained, personalized directories on my system itself. I am aware of the irony in that statement... but that's just my personal preference.

So I thought I would share my process of setting up an older version of MongoDB (3.4 to be precise) on Arch Linux.

AUR to the Rescue

You will need to target the specific version of MongoDB using the very awesome AUR packages:

yay -S mongodb34-bin
+

Follow the instructions and you'll be good to go. Don't forget to create the /data/db directory and give it proper permissions:

mkdir -p /data/db/
+chmod -R 777 /date/db
+

What About My "Tools"?

If you plan to use MongoDB, then you most likely want to utilize the core database tools (restore, dump, etc). The problem is you can't use the default mongodb-tools package when trying to work with older versions of MongoDB itself. The package will complain about conflicts and ask you to override your existing version. This is not what we want.

So, you'll have to build from source locally:

git clone https://github.com/mongodb/mongo-tools
+cd mongodb-tools
+./make build
+

Then you'll need to copy the built executables into the proper directory in order to use them from the terminal:

cp bin/* /usr/local/bin/
+

And that's it! Now you can run mongod directly or use systemctl to enable it by default. Hopefully this helps anyone else curious about running older (or even outdated!) versions of MongoDB.

Using a New Domain and Switching Static Hosts

2021-11-25T10:00:00Z

Using a New Domain and Switching Static Hosts

2021-11-25

As you can most likely tell by looking at your browser's URL - I've swapped over to a new domain for my personal website: tdarb.org. I'm a fickle person and this is a random change - but it is one I've been planning to do for some time.

Let me give some minor background information and then get into the changes...

What about Ugly Duck?

I had originally used the uglyduck.ca domain for this personal blog as a loosely based reference to the "ugly duckling" story. This was based on the fact that I mainly focus on CSS and making the web more visually appealing - or beautiful, if you will - so the comparison to an ugly duckling becoming a swan made sense in my oddball mind.

But overtime I came to somewhat dislike[^1] it and set out to change it.

So what the heck is "tdarb"?

I explain this on my updated about page but I will mention it again here:

tdarb[^2] is simply my first name and last initial spelt backwards – Brad T. Mind blowing, right?

I've switched over to this naming convention to avoid having such a random "phrase" domain name while at the same time having a little more fun than just mylegalname.com. I also am a sucker for .org TLDs (although I don't know why).

I'm sure some readers will prefer it, some will be indifferent and others will hate it. Either way, it's my personal site and I'll do as I please!

Breaking My Website for a Day and Fixing Potential Link Rot

The transition I made yesterday from uglyduck.ca to tdarb.org was rough. I thought that I could simply launch the identical content on the new domain, test everything, and then simply set a URL redirect from the old domain through Namecheap[^3]. Oh boy, was I wrong!

The bulk of my evening was spent figuring out why the redirect wouldn't propagate across all networks and why multiple forwards were occurring. In the end, I just tossed uglyduck.ca back up on Netlify and set global redirect rules in their handy-dandy _redirects file. (I will write-up a small post about this soon to help others). After a few minutes everything was working perfectly fine and best of all - no broken links or potential link rot! All thanks to the :splat parameter in the redirects.

As for my RSS feed, everything should forward correctly? I state that as a question since I can't confirm this 100% and RSS feeds are not my expertise. If I broke this for any of you, I apologize. I will pray to the internet gods for your forgiveness...

From Github to Sourcehut

That's right, I've switched this static site's hosting over to sourcehut pages and couldn't be happier. My reasons for switching:

I'm happy to pay and support the ongoing work at sourcehut (open source alternatives to Netlify, Github, etc. is important)
I've been wanting to become more comfortable with the sourcehut ecosystem - there might be projects in the future I would like to help with on that platform and it helps if you know how to use it :P
Sourcehut pages are fast - I mean really fast

It was slightly confusing for my ape brain to figure out the setup, but I got there eventually. I plan to do a detailed step-by-step tutorial to help those like me who may find it a little daunting. It's well worth the minor effort.

The Lifespan of uglyduck.ca

I still have ownership of the old domain for almost another full year. I feel like that gives users enough time to adjust and become accustomed to the new one. My plan is to let the domain die entirely when it goes up for renewal but who knows - I might very well keep it going if the mood strikes me.

That's All Folks!

I don't have much else to report besides having made minor tweaks to this website design (yet again) and I have also finally added a picture of workstation on the "Things I Use" page. That's it.

Refs

not hate - just discontent
pronounced tee-darb
Namecheap support were very helpful - this was more of a limitation of what their redirects can do

Minimal CSS: Dropdown Menu

2019-04-26T10:00:00Z

Minimal CSS: Dropdown Menu

2019-04-26

I love the idea of stripping away as much CSS as possible, while still maintaining the original UI concept. Let's build out a demo example with a simple menu dropdown element.

Interesting facts about our final CSS menu:

Total weight 121 bytes minified! (not including any resets etc.)
No complex HTML structures
Accessibility support

Now to see the final code in all it's glory:

HTML

<nav>
+    <ul>
+        <li><a href="">Home</a></li>
+        <li><a href="">About</a></li>
+        <li><a href="">Services</a>
+            <ul>
+                <li><a href="">Design</a></li>
+                <li><a href="">Development</a></li>
+                <li><a href="">Custom Pizzas</a></li>
+            </ul>
+        </li>
+        <li><a href="">Contact</a></li>
+    </ul>
+</nav>
+

CSS

/* resets - optional */
+ul { list-style: none; padding: 0; }
+ul li { display: inline-block; position: relative; }
+
+/* minimal dropdown CSS */
+ul li > ul {
+    left: -9999px;
+    position: absolute;
+    visibility: hidden;
+}
+ul li:hover > ul, ul li:focus-within > ul {
+    left: 0;
+    visibility: visible;
+}
+

Live demo on CodePen

Feel free to check out the live demo on CodePen here.

Mini Interactive Keyboard with Pure CSS

2020-05-13T10:00:00Z

Mini Interactive Keyboard with Pure CSS

2020-05-13

Lately, I've become obsessed with trying to see what I can create using only HTML and CSS (besides websites of course). Since playing with the concept of faking 3D elements, I wanted to circle back around to an older CodePen I created: a mini, interactive undo keyboard.

See it in action

Below you can view a live demo of the mini keyboard itself. This demo is nothing special, but takes design inspiration from Apple's magic keyboards (if that wasn't already obvious).

Live CodePen Example

So now that we have seen what we plan to build, let's break down the process of creating this stupid, fun project!

The HTML

The core skeleton of this project is very simple, since the keyboard consists of only 2 interactive buttons on top of a basic base element:

Keyboard base
Command button
'Z' letter button

<!-- This is keyboard main base -->
+<div class="base">
+
+    <!-- Command Button -->
+    <button class="command"> 
+        <svg viewBox="0 0 24 24" stroke="currentColor" stroke-width="2" fill="none" stroke-linecap="round" stroke-linejoin="round"><path d="M18 3a3 3 0 0 0-3 3v12a3 3 0 0 0 3 3 3 3 0 0 0 3-3 3 3 0 0 0-3-3H6a3 3 0 0 0-3 3 3 3 0 0 0 3 3 3 3 0 0 0 3-3V6a3 3 0 0 0-3-3 3 3 0 0 0-3 3 3 3 0 0 0 3 3h12a3 3 0 0 0 3-3 3 3 0 0 0-3-3z"></path></svg>
+        <span>command</span>
+    </button>
+
+    <!-- "Z" Letter Button -->
+    <button class="z">
+        <span>Z</span>
+    </button>
+
+</div>
+

The CSS

Here is where all the magic happens. Let's break these elements into their own sections, starting with the base styling:

/* Custom typeface */
+@import url("https://fonts.googleapis.com/css?family=Muli");
+
+/* Basic layout styling */
+body {
+background: #d2dcff;
+margin: 80px 0 40px;
+}
+

We then tackle the basic keyboard base element:

.base {
+background: linear-gradient(180deg, #eee 0%, #d8d8d8 100%);
+border-radius: 20px;
+box-shadow: inset 0 3px 5px rgba(255,255,255,0.3), inset 0 1px 3px rgba(255,255,255,0.5), 0 10px 0 #afafaf;
+display: flex;
+height: 310px;
+margin: 0 auto;
+position: relative;
+width: 620px;
+}
+
+/* This pseudo element is used for more realistic drop-shadows */
+.base:after {
+bottom: 0;
+box-shadow: 0 10px 80px rgba(0,0,0,0.5);
+content: '';
+height: 50px;
+left: 7.5%;
+position: absolute;
+width: 85%;
+z-index: -1;
+}
+

Next, we target all shared styles between the 2 keyboard buttons to avoid repeating ourselves later on:

.command, .z {
+    -webkit-appearance: none;
+    background: linear-gradient(180deg, #fff 0%, #f2f2f2 100%);
+    border: 0;
+    border-radius: 20px;
+    box-shadow: inset 0 1px 3px rgba(255,255,255,0.5), 0 10px 0 #c9c9c9, 0 10px 6px rgba(0,0,0,0.3), 0 12px 8px rgba(0,0,0,0.5);
+    cursor: pointer;
+    display: inline-block;
+    height: 260px;
+    margin: 15px 0 0 20px;
+    outline: 0;
+    position: relative;
+    width: 300px;
+    z-index: 2;
+}
+
+.command span, .z span {
+    font-family: 'Muli', 'Helvetica', sans-serif;
+}
+
+/* Styling when pressed */
+.command:active, .z:active {
+    box-shadow: inset 0 10px 10px rgba(0,0,0,0.2), inset 0 10px 30px rgba(0,0,0,0.6), 0 1px 0 rgba(255,255,255,0.6);
+    margin: 25px 0 0 20px;
+}
+

All that remains is to add the custom styling for each independent button:

/* Custom Command styling */
+.command svg {
+    height: 60px;
+    right: 15px;
+    position: absolute;
+    stroke: #9f9f9f;
+    top: 15px;
+    width: 60px;
+}
+.command span {
+    bottom: 15px;
+    color: #9f9f9f;
+    font-size: 58px;
+    left: 0;
+    position: absolute;
+    width: 100%;
+}
+
+/* Custom "Z" Letter styling */
+.z {
+    width: 260px;
+}
+.z span {
+    color: #9f9f9f;
+    font-size: 150px;
+}
+

Taking it further

You could easily improve upon this concept by rendering an entire interactive keyboard, if you so desired. But this is maybe something I would tackle at a later date when I have a little more free time 😉 For now, a simple mini undo keyboard is fun enough to play with.

Menu Toggle with Pure CSS

2020-10-19T10:00:00Z

Menu Toggle with Pure CSS

2020-10-19

When thinking through navigation designs for mobile devices sometimes the best option is to store away the content behind a toggle button. This button would then display the menu items upon interaction. Let me show you how to create such an element with only CSS - no need for JavaScript today!

Before we begin

I would like to point out that the concept of "toggling" the main menu (even for mobile) is not always the best solution. If you're interested, you can take a look at a previous article I wrote explaining why: Using Hamburger Menus? Try Sausage Links

Now that we have mentioned possible pitfalls of relying so heavily on toggle menus, let's build one!

Our Final Product

Live CodePen Example

The HTML

To implement this design you really don't need much in terms of HTML:

A single checkbox input
A label that corresponds to the checkbox
A nav element to house our unordered list items

<!-- The checkbox input & label partner -->
+<input type="checkbox" id="menu-toggle">
+<label for="menu-toggle">Menu</label>
+
+<!-- The navigation we wish to toggle -->
+<nav>
+    <ul>
+        <li><a href="">Home</a></li>
+        <li><a href="">About</a></li>
+        <li><a href="">Articles</a></li>
+        <li><a href="">Colophon</a></li>
+        <li><a href="">Contact</a></li>
+    </ul>
+</nav>
+

That's it!

The CSS

The first thing we need to do is "hide" the checkbox input element. It's important to avoid using display: none or visibility: hidden in order to achieve this. Those CSS properties can negatively impact accessibility (specifically screen readers). So we will be relying on the position, z-index and opacity properties to help us out.

/* Set the input position to absolute, send it off screen with zero opacity */
+input[type="checkbox"] {
+    left: -9999px;
+    opacity: 0;
+    position: absolute;
+}
+

Then we give our corresponding label a minor face-lift to make it appear more button-like:

/* Minor visual styling to make the label more button-y */
+label {
+    border: 1px solid currentColor;
+    border-radius: 4px;
+    cursor: pointer;
+    padding: 10px;
+}
+

For our main nav element, we want to set it's position to absolute in order to avoid any janky page rendering issues that might occur when toggling the menu:

` +

/* Set nav to absolute (avoids odd page rendering space pop-in) */
+nav {
+    opacity: 0;
+    position: absolute;
+    z-index: -2;
+}
+

The last step is to actually show the menu if the user toggles the checkbox:

/* Show nav when checkbox is checked */
+input[type="checkbox"]:checked ~ nav {
+    opacity: 1;
+    z-index: 1;
+}
+

It might not look like much, but you now have a fully functional menu toggle - made with pure CSS!

With Great Power...

Although this design is very simple to implement, please remember to use these types of menus wisely. Just because you can do something, doesn't always mean you should.

Replacing My Eero Mesh Network with Two Mangos

2023-03-09T10:00:00Z

Replacing My Eero Mesh Network with Two Mangos

2023-03-09

It has been one week since I retired my Eero mesh network setup and replaced it with two Mango Mini Travel Routers (GL-MT300N-V2). There were some obvious reasons to make this switch but I was initially unsure how the overall performance on the Mangos would hold up compared to the "cutting edge" tech that Eero devices claim to have.

Spoiler (in case the post title didn't give it away): I was pleasantly surprised.

Goodbye Amazon

I was a big supporter of the original "kickstarter" project when Eero first launched. I pre-ordered and they even sent me a device free-of-charge since there were logistic problems shipping to Canada. I received my V1 routers, hooked them up and enjoyed a seamless, wifi mesh system. Everything was going great.

Then, in 2019 they were acquired by Amazon. Sigh...

I should have jumped ship then, but I waited to see what would happen. After all, my internet was still working perfectly fine. Then the half-baked and sometimes completely broken updates started rolling out. On more than one occasion they needed to perform complete version roll-backs. This sometimes knocked out my internet for hours at a time.

They also started pushing (although not outright requiring) users to login using their Amazon account. While not a massive deal breaker, the constant pestering to do so rubbed me the wrong way.

During this time, my first son was born and we moved out of the city into our first house. So fiddling with my internet setup took the backseat for a while. Once everything settled down, I started seeing more broken updates and certain features being put behind their premium "Eero Secure" platform. Features that were available as default for most other router hardware providers.

So, I started to look at other options.

Why the Mango?

It is important to mention, that because I live out in rural Canada, my internet options are extremely limited. All providers are satellite-based since fiber cables are unheard of out in these areas. Because of this, my main internet speeds are limited to 25Mbps baseline. This is important to note, since my experience and router choice took this into consideration. If you're a current Eero user with 300Mbps+ speeds and are looking to switch wifi systems - the Mango is probably not the best for you.

Luckily for me, the Mini Mangos were perfect for my basic requirements:

Max. 300Mbps Wi-Fi Speed (more than enough for my use-case)
Running open-source software via openwrt
Hardware VPN toggle
Tiny physical footprint
Extremely portable

Setting Up the Yellow Squares

+ +

The little yellow mango in all its glory...

Setup was a breeze compared to the Eero experience (which could only be performed through their mobile app via bluetooth and a great deal of repositioning the devices). The full process is essentially:

Power up the first Mango
Connect laptop to the Mango via ethernet (you can also connect through wifi)
Follow the login instructions
Change SSID name, set device in router mode
Enjoy your internet!

Since my office is fairly far away from the placement of the "main" Mango router, I placed the second device near my desk. I followed the same setup as above, except I set the mode as "repeater".

For my use case I actually set this device up with a separate SSID. This was just my personal preference. You don't have to do this. If you give both devices the same SSID name most modern devices will treat your network as if it was a mesh network. Pretty neat stuff.

I plan to eventually add my Pi Zero running AdGuard Home back into the mix, but for now I just installed a small adblock package directly onto the router:

adblock package

Performance Comparisons

Everything below is just some basic testing I performed. Obviously it should be noted that your experience might be entirely different based on interference, building size, amount of devices connected, etc.

Stats for my original Eero mesh setup:

1 eero 6 pro, 1 eero 6+, 1 eero beacon
Average internet testing speed: 25Mbps
Consistent signal throughout the house

Stats for the new Mini Mango setup:

2 mini mangos (one in router mode, the other set as repeater)
Average internet testing speed: 25Mbps
Consistent signal throughout the house

Extras

Some additional data comparisons for those interested. Prices shown are in Canadian dollars.

+ + + + + + +

	Eero	Mango
Power	5W	2.75W
Size (mm)	139x139x55	58x58x22
Bands (GHz)	2.4/5	2.4
Cost (per unit)	$99+	$39

+That mostly covers it. I'm extremely happy with my switch away from the locked-down, "upsell" heavy Eeros. My only regret is that I didn't make this change sooner.

Working with `git` Patches in Apple Mail

2023-05-11T10:00:00Z

Working with `git` Patches in Apple Mail

2023-05-11

Before we begin: You could likely automate this process in a more streamlined way, but for most use cases this workflow should be fine.
+

I recently covered how to work with git email patches in Evolution on Linux, so I thought it would make sense to walk through a similar workflow for those using Apple Mail on MacOS. The idea is essentially the same, with just a little extra work involved.

Create a "Patches" Mailbox

The first thing you'll need to do is make a new Patches mailbox folder inside your existing mail account. Once done, your default Mail sidebar should look similar to the following:

+ +

The Apple Mail sidebar with the "Patches" folder present

Applying Patches

Now navigate to the email message containing a git patch. Right-click and select Move to > Patches. Now in the sidebar, right-click your Patches folder and select Export Mailbox.... You'll be prompted to save this folder locally. I suggest having a top-level folder named Patches to make things consistent.

Inside this folder you should see something similar to the following structure:

+ +

The contents of the saved Patches mailbox folder

Once saved, open your terminal, navigate to the project you wish to apply this new patch to:

cd my-path/very-cool-project
+

and then run:

git apply ~/Patches/<saved-patches-mailbox-folder>/mbox
+

Congrats! You've successfully applied a git email patch through Apple Mail! Well, kind of. The terminal did most of the real work. Just be sure to periodically purge your local Patches folder to keep things clean!

Create a Mac App Icon with Pure HTML and CSS

2021-04-13T10:00:00Z

Create a Mac App Icon with Pure HTML and CSS

2021-04-13

I have always been a huge fan of Bogdan's work on Dribbble and was recently inspired to see if I could replicate one of his awesome icon designs with only HTML & CSS. What was the outcome? I think it's a half-way decent copy - of course the original will always look significantly better.

Don't care about reading through the tutorial? No problem! You can jump right down to the live demo

The Comparison

Let's take a look at the original Dribbble shot:

+ +

The original Dribbble shot (direct link to image)

And now let's see what we will be creating with only HTML & CSS:

+ +

What we are going to create with pure HTML & CSS (direct link to image)

Like I said - far from perfect but still a fun experiment!

The HTML

Let's jump right in and build out the main skeleton of our project:

<div class="white-square"></div>
+<div class="blue-square">
+    <div class="row">
+        <div class="item"></div>
+        <div class="item"></div>
+    </div>
+    <div class="row">
+        <div class="item"></div>
+        <div class="item"></div>
+    </div>
+    <div class="row">
+        <div class="item"></div>
+        <div class="item"></div>
+    </div>
+    <div class="row">
+        <div class="item"></div>
+        <div class="item"></div>
+    </div>
+    <div class="row">
+        <div class="item"></div>
+        <div class="item"></div>
+    </div>
+    <div class="row">
+        <div class="item"></div>
+        <div class="item"></div>
+    </div>
+    <div class="row">
+        <div class="item"></div>
+        <div class="item"></div>
+    </div>
+</div>
+<div class="play-button">
+    <div class="triangle"></div>
+</div>
+

- The white-square element is the white, rounded square in the background + - The blue-square is the main blue square of the icon + - The row elements inside the blue-square will be our individual lines spread across the icon + - The play-button is obviously - the play button

Right now it will look like nothing, but we can change that by adding the most important part...

The CSS

Pasting the entire CSS styling here would end up looking a little daunting. Instead, I'm just going to breakdown each individual section to make things more digestible.

Defaults & the White Square

* {
+    box-sizing: border-box;
+}
+:root {
+    --row-distance: 42px;
+}
+

.white-square {
+    background: white;
+    border-radius: 105px;
+    box-shadow: inset 0 -5px 8px rgba(0,0,0,0.25), 0 12px 10px rgba(0,0,0,0.15), 0 2px 4px rgba(0,0,0,0.1);
+    height: 420px;
+    left: 165px;
+    position: absolute;
+    transform: rotate(-8deg);
+    top: 95px;
+    width: 420px;
+}
+

See that --row-distance variable? That will come into play a bit later. For now, we want to lay the Blue Square on top of this newly creating White Square:

.blue-square {
+    background: linear-gradient(#04BDFD 0%, #0585E4 100%);
+    border-radius: 105px;
+    box-shadow: inset 0 5px 8px rgba(255,255,255,0.5), inset 0 -5px 8px rgba(0,0,0,0.32), 0 12px 10px rgba(0,0,0,0.18), 0 2px 4px rgba(0,0,0,0.15);
+    height: 420px;
+    left: 205px;
+    padding: 75px 0 0;
+    position: absolute;
+    top: 75px;
+    width: 420px;
+}
+

Targeting the Inner Rows

So far so good. The next part looks like a lot, but I assure you it's fairly straightforward. We need to include each row inside the Blue Square like in the original Dribbble shot (7 total). First we start with the parent row styling:

.blue-square .row {
+    display: flex;
+    height: 20px;
+    justify-content: space-between;
+    padding: 0 55px;
+    position: absolute;
+    width: 100%;
+}
+

Now we style each individual row item via the nth-of-type attribute:

.blue-square .row:nth-of-type(2) { margin-top: var(--row-distance); }
+.blue-square .row:nth-of-type(2) .item:nth-of-type(odd) {
+    width: 85px;
+}
+.blue-square .row:nth-of-type(2) .item:nth-of-type(even) {
+    width: calc(100% - 100px);
+}
+.blue-square .row:nth-of-type(3) { margin-top: calc(var(--row-distance) * 2); }
+.blue-square .row:nth-of-type(3) .item:nth-of-type(odd) {
+    width: 115px;
+}
+.blue-square .row:nth-of-type(3) .item:nth-of-type(even) {
+    width: calc(100% - 130px);
+}
+.blue-square .row:nth-of-type(4) { margin-top: calc(var(--row-distance) * 3); }
+.blue-square .row:nth-of-type(4) .item:nth-of-type(odd) {
+    width: 185px;
+}
+.blue-square .row:nth-of-type(4) .item:nth-of-type(even) {
+    width: calc(100% - 200px);
+}
+.blue-square .row:nth-of-type(5) { margin-top: calc(var(--row-distance) * 4); width: calc(100% - 115px); }
+.blue-square .row:nth-of-type(5) .item:nth-of-type(odd) {
+    width: 105px;
+}
+.blue-square .row:nth-of-type(5) .item:nth-of-type(even) {
+    width: calc(100% - 120px);
+}
+.blue-square .row:nth-of-type(6) { margin-top: calc(var(--row-distance) * 5); width: calc(100% - 140px); }
+.blue-square .row:nth-of-type(6) .item:nth-of-type(odd) {
+    width: 65px;
+}
+.blue-square .row:nth-of-type(6) .item:nth-of-type(even) {
+    width: calc(100% - 80px);
+}
+.blue-square .row:nth-of-type(7) { margin-top: calc(var(--row-distance) * 6); width: calc(100% - 160px); }
+.blue-square .row:nth-of-type(7) .item:nth-of-type(odd) {
+    width: 40px;
+}
+.blue-square .row:nth-of-type(7) .item:nth-of-type(even) {
+    width: calc(100% - 55px);
+}
+.blue-square .row .item {
+    background: white;
+    border-radius: 20px;
+    box-shadow: inset 0 -2px 4px rgba(0,0,0,0.06), inset 0 2px 4px rgba(255,255,255,0.1), 0 4px 6px rgba(0,0,0,0.05);
+    width: 40px;
+}
+.blue-square .row .item:nth-of-type(even) {
+    background: #3FC0F5;
+    width: calc(100% - 55px);
+}
+

Take a few moments to read everything over - it will help you better understand what's going on. Basically, we are adding two inner elements to each row element. We calculate the margin-top distance by using that --row-distance variable I mentioned earlier. The inner elements are then styled based on their placement inside the row (nth-of-type).

The Play Button

Now we finish things off with a much simpler element to style:

.play-button {
+    backdrop-filter: blur(6px);
+    border-radius: 9999px;
+    box-shadow: inset 0 4px 0 rgba(255,255,255,0.3), inset 0 20px 15px rgba(255,255,255,0.6), 0 8px 12px rgba(0,0,0,0.1), 0 4px 6px rgba(0,0,0,0.05);
+    height: 220px;
+    overflow: hidden;
+    position: absolute;
+    right: 140px;
+    top: 320px;
+    width: 220px;
+}
+.play-button::before {
+    background: rgba(255,255,255,0.9);
+    border-radius: 9999px;
+    content:'';
+    filter: blur(40px);
+    height: 150%;
+    left: -25%;
+    opacity: 0.8;
+    position: absolute;
+    top: -25%;
+    width: 150%;
+}
+
+.triangle {
+    position: absolute;
+    left: calc(50% - 2em);
+    background-color: #315074;
+    top: calc(50% - 2.1em);
+    text-align: left;
+}
+.triangle:before,
+.triangle:after {
+    content: '';
+    position: absolute;
+    background-color: inherit;
+}
+.triangle,
+.triangle:before,
+.triangle:after {
+    width:  3.2em;
+    height: 3.2em;
+    border-top-right-radius: 30%;
+}
+
+.triangle {
+    transform: rotate(-90deg) skewX(-30deg) scale(1,.866);
+}
+.triangle:before {
+    transform: rotate(-135deg) skewX(-45deg) scale(1.414,.707) translate(0,-50%);
+}
+.triangle:after {
+    transform: rotate(135deg) skewY(-45deg) scale(.707,1.414) translate(50%);
+}
+

Thanks to meduz for pointing out the backdrop-filter property. This allows for a frosted glass look on Chromium & Safari (although sadly not on Firefox). The triangle element could also be improved by using an embedded SVG but I was determined to use only CSS for this experiment :P

That's really all there is to it! You can see the embedded CodePen example below or check it out directly here →

Special Thanks

Thanks to Bogdan for letting me butcher the original Dribbble shot :D

bg-d.net
Bogdan on Dribbble

Live Demo (CodePen)

Live CodePen Demo

Convert Files to HTML with macOS Automator Quick Actions

2022-01-28T10:00:00Z

Convert Files to HTML with macOS Automator Quick Actions

2022-01-28

Since a few people have reached out and thanked me for my previous post Batch Converting Images to webp with macOS Automator, I thought I would continue to share more of my own custom Automator Quick Actions. Today's post will cover the ability to convert any text-based document into pure HTML.

I know - there are over 6 billion conversion apps that do this very same thing. But our way of doing it is cooler. Our conversion tool:

Will run directly inside macOS Finder (right-click actions FTW)
Can batch convert multiple files at once
Can convert mixed files types at the same time

And it can do all of this for free on your existing macOS system. No apps required. So, enough chit-chat, let's get started!

The Dependencies

Unfortunately, setting things up isn't as simple as clicking a single Install button and calling it a day. But don't start to panic! I assure you everything we'll be doing is actually quite easy to breeze through - trust me.

Our main requirements will consistent of the following:

Homebrew
Pandoc
Ability to open Terminal

Installing Homebrew

Homebrew is a simple package manager for macOS. The beauty of having Homebrew is the flexibility in the future for installing other custom packages. Overall it's just a nice piece of software to have on your machine.

If you have already installed Homebrew in the past, ignore this step and continue down the page. If not, simply open your Terminal and run:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
+

Let that finish and you're done! Also feel free to read more about Homebrew on the official website. Knowledge is power!

Installing Pandoc

The package that is going to be doing all the heavy-lifting for us is pandoc. Because we have Homebrew on our machine now, installing this package is as simple as opening our Terminal again and running:

brew install pandoc
+

Wait for everything to finish and you're done!

Our Custom Automator Quick Action

Next you'll want to open the macOS Automator app and create a new "Quick Action" when given the prompt to do so.

+ +

After opening Automator, select "Quick Action" from the menu (link to hi-res image)

Now do the following (reference the image further below to make sure your parameters match):

Set "Workflow receives current" to documents in any application
In the search bar type in "Run Shell Script"
Drag-and-drop the "Run Shell Script" from the left pane into the right pane
Set the "Shell" parameter to /bin/bash
Set "Pass input" as as arguments

Once all that is done, simply paste the following in the open text field within the "Run Shell Script" item:

for f in "$@"
+do
+/opt/homebrew/bin/pandoc -o "${f%.*}.html" "$f"
+done
+

If you've done everything correctly it should look something like this:

+ +

This is what your finished Automator quick action should look like (link to hi-res image)

Save this new Quick Action (Name is something like "Convert to HTML" to keep things simple). That's it! Amazing, right?

Time to Convert

Now it is finally time to see our Quick Action is action! Navigate to any document file in a Finder window and follow along.

First, right-click on the file you wish to convert. (Figure 1)
In the pop-up container, scroll down and hover over Quick Actions.
A secondary pop-out will appear. Look for the action Convert File to HTML and click it. (Figure 2)

+ +

Figure 1: Finding and right-clicking on your desired file (link to hi-res image)

+ +

Figure 2: From the "Quick Actions" menu, select "Convert to HTML" (link to hi-res image)

If everything was set up properly (and depending on the size of the file) you should see your converted HTML file show up right next to your existing document. Time to celebrate!

Don't forget - you can also batch convert multiple files and multiple file types at once. The possibilities are endless!

+ +

Our converted document is now available in HTML. Absolutely glorious. (link to hi-res image)

No Limits

Although this article has mainly focused on converting documents to HTML, pandoc is so powerful you could do any number of conversions. Re-using these steps above, you have the ability to make as many different conversion quick actions as your heart desires!

Have fun converting!

My Robotic Mower Woes

2023-05-19T10:00:00Z

My Robotic Mower Woes

2023-05-19

A Brief Background

I'm no stranger to robotic lawnmowers. When my wife and I moved into our rural home just over five years ago, we picked up the Husqvarna 450X Automower since I was far too lazy to manually mow my property and the cost was equal to that of a standard riding mower. It was a no-brainer.

+ +

The Husqvarna 450X (not mine but same model)

Fast-forward five years. Everything is still going great with the Automower. Some minor repairs were needed but that was mostly my fault since I was allowing the mower into places it shouldn't have been (ie. root systems and dirt "craters"). Then lightning struck our backyard at the beginning of April this year. The mower was fine, since we stow it away inside for the winter but the charging station, charging brick and perimeter wire we not so lucky...

The lightning traveled along the main perimeter wire and went straight to the charging station. Boom. The charging dock was quite literally blown up into a million tiny pieces and scattered across my backyard. Giant trenches were carved up where the perimeter wire had been embedded in the lawn. This surge also followed the path towards the main power adapter and exploded that as well. All of this happened even with the charging station / adapter turned off and unplugged from any outlet. At least my mower was safe...

Shopping for Automower Parts

I realized I was going to have to buy another charging station, power adapter and also pay for a dealer to re-install the perimeter wire. This idea didn't thrill me but at least all-in the expense wouldn't be that high. Or so I thought...

I contacted my local dealer and he quoted me directly from the Husqvarna supplier:

Charging base station: $749 CDN
Power adapter: $599 CDN
Perimeter wire install: ~$550 CDN

I thought the cost for both the charging station and the wire install seemed about right - but $599 for a power adapter?! Are you kidding me? Best of all, these parts were on back-order. So even if I shelled out the ridiculous asking price, it was anyone's guess when I would get them. May was fast approaching and I would need to start cutting my property soon. I started to look at other options.

Husqvarna EPOS Mowers

Husqvarna recently launched their "perimeter-free" automowers for the general public (originally designed only for "fleet" enterprise use). These units use GPS and RTK position to map the desired cutting area of a property. Already my interest was piqued. Moving away from a perimeter wire seemed like a significant upgrade. It would also make my wife happy by allow her to garden freely, without worrying about severing an embedded lawn wire.

So I contacted my local dealer again about these specific units. I came away with some interesting information:

They were quite expensive for my taste ($5000+ CDN - before install!)
They were also on back-order here in Canada

Sigh. The mower gods were trying to tell me something. It seemed Husqvarna was just not meant for me anymore.

Luba to the Rescue!

While researching "wireless" automowers, I came across the Luba Series 5000 (referral link) and kept it in my "maybe" pile to follow-up on if needed. So follow-up I did.

+ +

The Luba Series 5000 AWD (not mine but same model)

This mower seemed to check all my boxes:

Decently priced
2-year warranty
All wheel drive
I could set it up myself
No perimeter wires
No-go zones available

It did have a few minor cons associated with it:

Fairly new product / company
No close dealer in my area
iOS and Android apps are more or less "beta"

Next, I watched a few early reviews and went through some comments/feedback from beta users. I was convinced enough and bought the AWD 5000 model.

Arrival and Setup

The mower (who we named Lawna, and shall be referred to as such moving forward) arrived just after the first week of May. The hardware setup (charging station and RTK antenna) was very straight-forward, so I won't go into great detail about that here. Once Lawna was synced with the RTK and GPS system, it was time to map my property.

I broke my property into 4 main "tasks" as the app calls them. The 5000 model allows you to create up to 10, but for my needs 4 was fine for full coverage. I mapped each one, added a handful of no-go zones to each and told Lawna to get to work. She happily obliged.

The First Week

I've had (almost) zero issues with Lawna after a week and a half of running her daily. She alternates from the front to the back of the property every other day. The app allows you to setup automatic scheduling, but I prefer to run things manually every morning, based on whether an area should be skipped, grass it dried out etc.

The only minor problem I have run into is the need to manually clean grass build-up from under the small cutting blades after Lawna cuts a couple "task" areas. I swapped the default blades to use Husqvarna's endurance type, since they use a large slotted insert hole as opposed to Mammotion's two single insert holes. This change makes cleaning the blades faster, safer, and easier to maintain. I realize that a riding mower would require similar maintenance but a truly autonomous device shouldn't require human intervention.

Moving Forward

My hope is that the software continues to improve over time and that the core hardware lasts as long as my 450X did. Which now reminds me - I need to sell that thing...

Hopefully this post helps others looking to snag their own robotic mower. So far, I can safely recommend Luba.

Looping Through Jekyll Collections

2022-08-12T10:00:00Z

Looping Through Jekyll Collections

2022-08-12

I recently needed to add a couple new items to my wife's personal recipe website (cookingwith.casa) which I hadn't touched in quite a while. The Jekyll build still worked fine, but I realized I was statically adding each collection by hand on the main homepage[^1].

Not so good.

Of course, this wasn't difficult at all to fix. Now everything is much more "hands free" moving forward. I figured I would share the details here in the hopes that others mind find it useful. Plus, it's my blog - so I'll do what I want!

Looping Our Collections

We want Jekyll to make things as streamlined as possible for us. This means that if I decide to add a new collection it will automatically render it along the others on the homepage.

Work smart not hard!

Let's take a look at the bare-bones collections loop:

{% for collection in site.collections %}
+    <!-- Our code goes here -->
+{% endfor %}
+

Then we need to include an if statement to avoid pulling in standard post items (or leave this in if that is desired):

{% for collection in site.collections %}
+    {% if collection.label != 'posts' %}
+    {% endif %}
+{% endfor %}
+

Now for my specific use case, we want to display each collection label and then list its corresponding items below that label (see the site[collection.label] for reference)

{% for collection in site.collections %}
+    {% if collection.label != 'posts' %}
+        <h2>{{ collection.label }}</h2>
+        <ul class="recipe-list">
+        {% for item in site[collection.label] %}
+            <li>
+                <a href="{{ item.url }}">{{ item.title }}</a>
+            </li>
+        {% endfor %}
+        </ul>
+        <hr>
+    {% endif %}
+{% endfor %}
+

That's it! Now if I plan to add any new collections down the line, I just need to include it in the _config.yml file and I'm set. The homepage will take care of the rest once rendered.

Enjoy looping through your Jekyll collections!

Refs

Just the sections were statically rendered. All the recipes were pulled in dynamically - I'm not that insane!

Fixing LocalWP on Fedora 32

2020-05-06T10:00:00Z

Fixing LocalWP on Fedora 32

2020-05-06

I recently upgraded from Fedora 31 to 32 and everything went very smoothly - except for one application: LocalWP. After the upgrade, all local WordPress builds would fail and complain about two missing packages:

libnettle6
libhogweed4

After wasting far too much time rolling back to older LocalWP versions and reaching out into the community forums, I found a simply solution to the problem. You just need to download and install the following packages manually:

libnettle6: libnettle6-3.4.1-lp152.3.1.x864.rpm
libhogweed4: libhogweed4-3.4.1-lp152.3.1.x864.rpm

Although these packages are built for OpenSuse, it still worked perfectly fine for me. My hope is that this quick post might be helpful for others who possibly run into the same issue.

For reference, here is the Local Community ticket I created: Local not working with Fedora 32

Click to Load Website Images

2021-03-25T10:00:00Z

Click to Load Website Images

2021-03-25

In my previous post about switching my Jekyll blog over to PHPetite, I briefly mentioned how I only loaded in article images if the user clicked or tapped the empty file element.

In this post, I'm going to quickly breakdown the update I've done to my blog's images since then and how you can easily implement the same thing in your own project.

Update

As pointed out by Gabriel in this Github issue, this concept breaks things slightly for RSS users. Since then, I have just set the default images on this blog to display: none and render them as block elements when their specific section is loaded into the DOM visibly.

The example below is remaining the same as it was, to still provide context for this post.

Live Demo

Before we jump head first into the details, let's take a look at what we will be creating:

+ +

Click the placeholder to load in the real image
Example Dribbble shot for testing. Feel free to click the default image in order to load the correct Dribbble source. View full size image.

Pretty neat, eh? Well let's get into the nitty gritty.

The Code

Personally, I place everything into a figure element to keep things contained and clean - but this isn't required by any means. We then include our img and figcaption elements. That's it.

<figure>
+    <img src="/placeholder-image.webp" onclick="this.src='https://res.cloudinary.com/bradtaunt/image/fetch/q_auto:low/v1570124593/https://uglyduck.ca/public/images/aqua-ui-css-buttons.webp'" alt="Aqua UI buttons">
+    <figcaption><b>Click the placeholder to load in the real image</b><br>
+        Example Dribbble shot for testing. Feel free to click the default image in order to load the correct Dribbble source.
+        <a href="https://res.cloudinary.com/bradtaunt/image/fetch/q_auto:low/v1570124593/https://uglyduck.ca/public/images/aqua-ui-css-buttons.webp">View full size image</a>.
+    </figcaption>
+</figure>
+

The Image Element

This is where the magic happens. By default all images will target the default placeholder image: placeholder-image.webp. This image is just 16KB in size and only needs to load in once.

Next we include an inline onclick attribute, which targets the current image's src attribute and changes it based on the URL provided. (Note: I use Cloudinary for my blog's image storage, but you could even host your images relative to your root directory if you wanted)

Now when a user clicks on the placeholder image, the inline onclick pulls in the correct image in it's place.

Disabled JavaScript

For users who have JavaScript blocked or disabled we have a decent backup. By including a direct link to the image URL in the figcaption element, we give the user the ability to still view the image in a separate browser tab.

You could get extra fancy and include some noscript tags in your project that maybe render a different placeholder image mentioning they have JavaScript disabled etc, but for my needs that would be overkill.

Cool - But Why Do This?

Bandwidth is a limited resource for a lot of users around the world. As designers and developers it's best to respect this fact and only load in elements as the user requires them. Every little bit helps.

Linux Mint MacBook Air Setup

2020-08-16T10:00:00Z

Linux Mint MacBook Air Setup

2020-08-16

I don't like the idea of throwing away old or outdated tech (within reason), so I try to find a new purpose for some of my "retired" devices. This article will cover how to switch over a mid-2011 model MacBook Air to utilize Linux Mint.

Important: This setup will completely wipe your existing disk and create a fresh install of Linux Mint on the SSD. You have been warned.

The Specs

My old MacBook Air has a pretty decent spec sheet:

Processor: 1.7GHz dual-core Intel Core i5
Memory: 4GB of 1333MHz DDR3
Graphics: Advanced Intel HD Graphics 3000
SSD: 128 GB

And let's take a look at the basic system requirements Linux Mint suggests:

2GB RAM
Dual Core Processor
20GB free disk space

We are looking pretty good!

Step 1: Download Linux Mint

For this setup we will be using the latest, stable version (at this time of writing) of Linux Mint 20 "Ulyana" - Xfce which is 20. You can download the necessary files here:

Linux Mint 20 "Ulyana" - Xfce [1.8GB]

Step 2: Flash Linux Mint to USB Stick

Next we just need to flash the Linux Mint OS to a USB storage device. If you need to purchase some, you can easily find them on Amazon (affliate link):

Kootion 10 Pack 4GB Flash Drive 4gb USB 2.0 Flash Drives Keychain USB Drive Bulk Thumb Drive Swivel Memory Stick Black
+
Download Balena Etcher for your current operating system
+
Run the installer
+

Once installed, open Etcher do the following:

Select your downloaded Linux Mint ISO file
Select your USB stick/device as the media
Flash media
???
Profit!!

Step 3: Boot from USB

Make sure your Macbook Air is turned off
Plug your newly flashed USB stick into the MacBook Air
Turn on the MacBook Air
Immediately hold down the alt/option button (keep holding until the prompt screen is visible)
You will be shown drive "icons" - you want to select your USB drive (normally the far right icon)
Press Enter
Select the first item in the list that appears "Start Linux Mint"

After this you will boot into a "live session" of the Linux Mint operating system.

Step 4: Installing Linux Mint

Linux Mint makes it very easy for you to install it's OS step-by-step (similar to most other Linux distros). Simply double-click on the "Install Linux Mint" CD icon on the main desktop.

Choose your language. then hit Continue
Select your preferred keyboard layout, then hit Continue
Optional: You might be asked to connect to a WiFi network, if you are set it up now
I would suggest downloading the multimedia codecs to make things easier, then hit Continue
For installation type, select "Erase disk and install Linux Mint", then hit Continue +
- WARNING: This will wipe your current drive completely - make sure you are okay with this!
+
It will issue you with a warning prompt, simply click Continue
Select your timezone, then hit Continue
Enter your name, a username, a name for your computer, and set a password (you will use this to login moving forward)
Wait for the installation to complete
Once complete, you will be prompted to reboot your system
After a reboot you will be prompted to remove the USB device and then press Enter
Welcome to Linux Mint!

Conclusion

Linux Mint is not only a great operating system, but it is also an excellent starting point for newcomers to Linux in general. It's stable enough to be used as a daily driver and popular enough that most minor issues can be solved with a quick internet search.

Hopefully this inspires others to try "recycling" their older Apple products instead of tossing them away or having them collect dust.

The Linux Desktop is Hard to Love

2022-07-14T10:00:00Z

The Linux Desktop is Hard to Love

2022-07-14

I want to love the "Linux Desktop". I really do. But I've come to the realization that what I love is the idea of the Linux Desktop. The community. The security and core focus on open source. The customizable environments. Tweaking as much or as little of the operating system as I please!

I just can't stick with it. I always end up back on macOS. And I'm starting to understand why.

What the Linux Desktop Gets Right

To be fair, there is an incredible amount of things that the Linux desktop does really well:

Complete user control
Ability to drastically change the desktop UI +
- Gnome, KDE, XFCE, etc.
+
Overall good and welcoming communities
Extensive documentation for almost everything

These things make Linux a solid experience overall - but not a great one...

What the Linux Desktop Gets Wrong

If I had to summarize in a word what Linux lacks compared to macOS it would be: cohesion.

Apple's macOS keeps a solid consistency throughout its entire design. Everything looks and feels like it is part of the same system. Which is what a fully-fledged OS should feel like. The argument can be made that macOS suffers some fragmentation with things like homebrew, applications directly from developers vs. applications via the Mac App Store.

While this is true, I believe Linux desktops suffer far worse in terms of fragmented systems. Users building applications from source, snap packages, flathub packages, custom package managers shipped with separate distros, etc. And with this fragmentation comes the constant debates and discussions around which to use and which to avoid.

This can become overwhelming for average computer users. This is something we tend to forget in our "tech hubs". Most users want to boot up their machine and get to work. Linux can absolutely do this, but if a user hits a minor snag, then I guarantee they will have more difficulty fixing it compared to an issue found in macOS.

User Experience

Design is important. The user experience will make or break an operating system. This is another issue I've found with many Linux desktops.

Let's take Bluetooth for example. It works flawlessly in macOS. I have never had a single device bug-out or refuse to connect. Devices connect almost immediately when pairing. The UI is intuitive and gives the user clear feedback to what the system is doing while pairing, disconnecting, and so on.

Now, compare this to an average Linux DE experience - not so seamless. The fact that some distros require you to hop into a terminal in order to properly configure Bluetooth is pretty terrible. Sure, most have GUIs setup similar to that of macOS, but I find myself time and time again needing to pop open that trusty ol' Terminal. This is fine for someone like myself, but for the average computer user? No way.

Looking for another example? Printers. Yes, printers are terrible machines created in the depths of Hell itself, but they are a necessary evil. And again, macOS handles "plug-and-play" printer functionality like a champ. Linux on the other hand is a mixed bag. I've had some luck with specific Linux distros working with printers in this "plug-and-play" fashion, while others become a battle of attrition[^1]. Let's not even begin to talk about wireless only printers and setting up their proper drivers on Linux.

Quality Hardware

Another advantage macOS has over most other Linux desktops is tailored hardware. Apple produces the hardware created to run their own operating system, meaning it was specifically built for that task. Linux desktops are designed to run on almost any[^2] piece of hardware. Though this is fantastic in terms of technological sustainability (avoids dumping old devices when they lose "support") it ends up causing more support issues. Needing to support such a wide range of chip sets and drivers spreads the focus on a streamlined UX a little more thin. It becomes difficult to perfect a cohesive experience user-to-user when some many variables can be different. I should note that some distros[^3] are making fantastic strides in this area but are still far from ideal.

I Still Use Linux

I might have attacked the overall Linux desktop experience in favor of macOS a little harshly in this post, but it's a simple reflection of a individual who has used both extensively. I still work with multiple Linux machines daily. I still like using Linux.

I just don't love it.

Refs

People swear by CUPS working well on Linux, but this has caused issues for me in the past as well. Unsure why macOS handles it fine...
Depending on the desired distro, resources required, etc.
A couple that come to mind are Zorin OS and elementary OS

Installing Custom Fonts on Linux from the Command Line

2022-09-20T10:00:00Z

Installing Custom Fonts on Linux from the Command Line

2022-09-20

Installing custom fonts is a fairly streamlined feature on operating systems like MacOS and Windows. Linux, on the other hand, struggles to make this workflow easy for everyday users. Many newcomers tend to get frustrated with using the default "Fonts" application managers shipped with most Linux distros.

But I'm here to tell you to ditch those GUI font installers. Let's install our custom fonts in the command line!

Get Your Font Files

You can't install custom fonts if you don't have any. For this tutorial we are going to assume that we are trying to install a typeface set named LinuxFont. We are going to assume that we have already downloaded and extracted a folder named LinuxFont into our Downloads directory.

Inside this hypothetical folder is a collection of OTF (opentype) font files. This will be important information in a moment.

Terminal Time

Now our goal is to simply copy this new typeface folder into our user font directory. Open Terminal and run the following from your Downloads directory:

sudo cp -r LinuxFont /usr/local/share/fonts/opentype/
+

Important: If your font files are NOT opentype format, be sure to copy your files to the proper directory (truetype for TTF, etc.)

Next we need to make sure we have full read and write privileges for this new folder:

sudo chmod -R 0777 /usr/local/share/fonts/opentype/LinuxFont
+

The last thing we need to do is reload the font cache on our system:

sudo fc-cache -fv
+

That's it! You should now have access to your custom typeface in all your applications system wide.

How to "FLOSS" as a Web Designer

2020-02-07T10:00:00Z

How to "FLOSS" as a Web Designer

2020-02-07

I have a profound respect for the open source community. I most likely wouldn't have the skills or knowledge I do today with it. Unfortunately, when I was just starting out in "web dev" some 10 years ago, proprietary software was the main go-to for a newbie designer.

Dreamweaver. Fireworks (those were the days). Photoshop. Illustrator. Adobe products basically had a stranglehold on the web design community. Any company you joined at the time more than likely required you to know and use these tools, making it hard for designers to try out new software for their day-to-day needs. Not to mention the cost associated with these products.

Fast forward a handful of years and we have a lot more options in terms of design / development software (whether Windows, Mac or Linux). UI design tools like Figma, Sketch and Adobe XD have since popped up and become the most popular among designers. New text editors and terminals hit the scene, fighting for developer attention (Atom, Sublime Text, VSCode, LightTable, iTerm2, Hyper, etc.).

But what if a designer wanted to go completely FLOSS?

Below you will find my own personal list of FLOSS applications I use across design, development and simple document management:

FLOSS Application Breakdown

Web Browsers

Firefox https://www.mozilla.org/en-CA/firefox/
Brave https://brave.com/

Visual Design

Nothing special

This small list I've compiled isn't earth-shattering by any means, but I wanted to put this out into the world for any newbie designer that might be starting out. You don't need to spend a ridiculous amount of money just to get your feet wet in the design industry. By using the tools listed above, beginners can get a solid head-start on creating for the web without burning a hole in their pocket.

The Lazy Developer's Dark Mode

2021-04-12T10:00:00Z

The Lazy Developer's Dark Mode

2021-04-12

After recently jumping back to Jekyll for my personal blog, I decided to take a closer look at how I was supporting dark mode for my visitors. I was using the proper CSS query to target those who had system-wide dark mode enabled, but I found that the code had far too many caveats and targeted too many custom classes.

So I thought to myself, "There has to be a simpler way..."

Introducing Dark Mode - The Lazy Way

Here is the default dark mode for my current website in all it's glory:

@media (prefers-color-scheme: dark) {
+    body{background:#2d2d2d;filter:invert(1);}
+    img,.cp_embed_wrapper,pre{filter:invert(1);}
+}
+

Not much to look at, eh? Well, let's still break it down.

First we set the body to use a nice dark background color (avoid using #000000 directly since that can cause some minor eye strain). Next we tell the browser to invert all the child elements by using filter:invert(1). At this point, you could consider your work done - but there are some edge case elements...

Images, CodePens & Code - Oh My!

Most of my articles on this site will include either an image(s), embedded CodePen examples or code snippets directly in the page. For these elements we probably don't want to invert their color/text etc. All we need to do is run the filter property on these a second time (after the main body attribute):

@media (prefers-color-scheme: dark) {
+    img,.cp_embed_wrapper,pre{filter:invert(1);}
+}
+

Of course, YMMV depending on what other custom elements you want to avoid inverting.

Minor Caveats

I should mention that since my website doesn't use any custom coloring for anchor links, inverting ahref elements works out of the box. Certain projects might still require some custom overrides if the inverted version of a certain custom color looks poor.

That's it - enjoy being lazy!

ThriftyName: $5 Brand Names

2021-02-25T10:00:00Z

ThriftyName: $5 Brand Names

2021-02-25

It's been a while since I've written anything on this blog, but for good reason - I've been working on a handful of side projects. I plan to drip-feed release these projects over time, but for today I'm announcing ThriftyName.

What is ThriftyName?

In case this post title wasn't clear enough (or you avoided going to the product site itself) ThriftyName is a place where indie devs, start-ups or entrepreneurs can go to get a custom brand name for just $10.

This "service" started out as an almost gimmicky joke in my head, but once I began building out the main website I realized that this could be quite useful for cash-strapped indies. After all, not all developers love to sit around wasting precious time thinking about product names, when they could use that time to build their product.

Learn More

If you're really interested in the reasoning behind making this project, check out the official about page on the site itself. I go into a little more depth about my thought process.

More Side Projects Incoming...

Like I said at the beginning of the post, keep a look out for my other side projects that I'll be rolling out slowing. I'm still not sure of the best "method" to do this (release one every week? every month?) - but I'll figure it out as I go along.

Thanks for reading!

Keynote Slides with Pure CSS

2020-06-22T10:00:00Z

Keynote Slides with Pure CSS

2020-06-22

There are a great deal of options available on the web and built into most operating systems when you need to create presentation / keynote slides. You could use native software like LibremOffice Impress, Powerpoint, Apple's Keynote, etc. You could also decide to use preexisting web-based apps like Google Slides or an open source project such as RevealJS. All of these are good options.

But thinking more about how overly complex these apps are implemented, it got me wondering if I could quickly code up a presentation slide framework with pure CSS and barely any code.

This is what I came up with:

The Demo

Live CodePen Example

Yes, I know this is ugly, but this was created as a barebones skeleton for others to build upon. The demo uses a simple set of radio inputs that correspond to their own individual slide element. The framework looks at the currently checked input, then changes the opacity and z-index of its corresponding slide item. Pretty straightforward stuff!

Let's break down each piece:

The HTML

<div class="slider">
+    <input type="radio" name="pagination" value="1" checked>
+    <input type="radio" name="pagination" value="2">
+    <input type="radio" name="pagination" value="3">
+    <input type="radio" name="pagination" value="4">
+    <input type="radio" name="pagination" value="5">
+
+    <div class="slide">
+        <h2>Slide 1</h2>
+    </div>
+    <div class="slide">
+        <h2>Slide 2</h2>
+    </div>
+    <div class="slide">
+        <h2>Slide 3</h2>
+    </div>
+    <div class="slide">
+        <h2>Slide 4</h2>
+    </div>
+    <div class="slide">
+        <h2>Slide 5</h2>
+    </div>
+</div>
+

There isn't a whole lot going on here. We are just including a set of radio inputs (based on how many slides are desired) along with their corresponding slide class elements. You might notice we don't do anything to specifically target each individual slide item - you'll see why we don't need to in the CSS section!

The CSS (SCSS)

/* Basic default styles */
+.slider {
+    height: 100%;
+    left: 0;
+    position: fixed;
+    top: 0;
+    width: 100%;
+
+    .slide {
+        height: 100%;
+        opacity: 0;
+        position: absolute;
+        width: 100%;
+        z-index: -2;
+    }
+}
+
+input[type="radio"] { cursor: pointer; }
+
+/* Target slide item based on currently checked radio */
+input[type="radio"]:nth-of-type(1):checked ~ .slide:nth-of-type(1),
+input[type="radio"]:nth-of-type(2):checked ~ .slide:nth-of-type(2),
+input[type="radio"]:nth-of-type(3):checked ~ .slide:nth-of-type(3),
+input[type="radio"]:nth-of-type(4):checked ~ .slide:nth-of-type(4),
+input[type="radio"]:nth-of-type(5):checked ~ .slide:nth-of-type(5) {
+    opacity: 1;
+    z-index: 1;
+}
+
+/* Individual slide styling */
+.slide:nth-of-type(1) { background: dodgerblue; }
+.slide:nth-of-type(2) { background: crimson; }
+.slide:nth-of-type(3) { background: rebeccapurple; }
+.slide:nth-of-type(4) { background: goldenrod; }
+.slide:nth-of-type(5) { background: pink; }
+

Again, not much to see here. We use CSS to look down through the DOM for each radio elements slide "partner". We do this by targeting the nth-of-type on both elements. Simple stuff.

Some drawbacks to this approach:

You need to manually target each new slide you add (color, styling, content, etc.)
Lack of animations might require extra work to implement (maybe 3rd party libraries- ke AOS?)
Probably won't be best for extremely long/complex presentation slides

That's it! Hope you enjoy playing around with it.

Using Parent Selectors in CSS

2018-12-19T10:00:00Z

Using Parent Selectors in CSS

2018-12-19

I recently saw a Twitter thread posted by Tommy Hodgins on implementing highly requested styling features in CSS with only a minimal amount of JavaScript. Many of his examples are great, but the parent selector instantly peaked my interest.

Being able to target an element's parent always becomes a minor annoyance (since vanilla CSS does not support it) - so you always end up having to do something a little ugly like:

var el = document.getElementById('custom-div');
+var parent = el.closest(selectors);
+

And then add any custom styling to the parent element directly in JavaScript - or toggle a class which opens a whole other can of worms.

Save the day with jsincss-parent-selector and qaffeine

By using the jsincss-parent-selector and qaffeine plugins we can target an element's parent in CSS without breaking a sweat. Let's break it down:

Import the packages

npm install jsincss-parent-selector qaffeine
+

HTML (ex. index.html)

Now we add our very simple HTML skeleton:

<!doctype html>
+<html>
+    <head>
+        <link rel="stylesheet" href="output.css">
+    </head>
+    <body>
+        <header>
+            <main>
+                <h2>This is a header</h2>
+            </main>
+        </header>
+    </body>
+    <script src=output.js></script>
+</html>
+

JavaScript (ex. input.js)

const qaffeine = require('qaffeine')
+const parent = require('jsincss-parent-selector')
+
+qaffeine(
+{
+    stylesheet: {},
+    rules: {
+    parent
+    }
+},
+'input.css',
+'output.js',
+'output.css'
+)
+

CSS (ex. input.css)

header {
+    display: block;
+}
+main[--js-parent] {
+    background: blue;
+}
+

Then simply run node against your js file. That's it! I would also suggest checking out Tommy's video covering this topic if you prefer to follow along.

Transferring Media from macOS to a Jellyfin Server (Raspberry Pi 4)

2022-03-12T10:00:00Z

Transferring Media from macOS to a Jellyfin Server (Raspberry Pi 4)

2022-03-12

I run a personal media server using Jellyfin on a Raspberry Pi 4 in my home. It's pretty great and works well across most devices - Google TV, iOS and Android devices, Chromebooks, etc.

The only small headache is adding content (ie. audio, videos) to the existing hard drive that Jellyfin reads from. The last thing you want to do is connect a keyboard and monitor to your Pi to add a few files. Especially if your Pi is setup like mine and buried at the back of a hidden cabinet.

More annoying would be the need to remove the hard drive itself, connect it to your device that has the new files you wish to transfer and then port them over. Big ol' pass on that system.

SSH/SCP to the Rescue

Important: before we begin, I should mention that this article assumes the following:

The files you plan to transfer from are on a macOS device
You have setup Jellyfin on your Raspberry Pi device
SSH is enabled and accessible on the Pi (across your local network)
The Jellyfin server's hard drive is mounted in the root directory via something like /mnt

Good? Moving on then...

Open your terminal of choice and use the following command:

scp movie.mp4 pi_user_name@PI_IP_ADDRESS:/mnt/movies/movie.mp4
+

movie.mp4 is the file in the current macOS directory we plan to copy over
pi_user_name is the username you setup on your Raspberry Pi
PI_IP_ADDRESS is, of course, your Pi's IP address
The appended :/mnt/movies/movie.mp4 is the directory your Jellyfin server uses to pull-in media

You'll be prompted for the user password. Once entered the file will begin copying over to your remote Jellyfin server. That's it! Although, I should mention a little bonus feature that you should always have in your back pocket, since Jellyfin can sometimes be picky with media file formats:

Converting Media Files with Ease

This is where your new best friend FFmpeg comes into your life (if they weren't there already).

Download and install FFmpeg --> ffmpeg.org/download.html

Now navigate to the directory containing the media file you wish to convert via your Terminal and run the following command:

ffmpeg -i input.mp4 output.mkv
+

input.mp4 is the initial file we wish to convert
output.mkv will be the name and file type of our converted media

Now you can circle back and run the previous scp command once you have converted your files to the desired format. Hopefully Jellyfin doesn't complain about the formatting!

Hosting a Jekyll Site on Sourcehut

2021-12-06T10:00:00Z

Hosting a Jekyll Site on Sourcehut

2021-12-06

I recently decided to switch my personal, static site's hosting from Netlify to sourcehut pages. The process went fairly smoothly with only a couple minor hiccups; nothing rage-inducing. After everything was up and running smoothly, I figured writing out a step-by-step tutorial might help others who are thinking of doing a similar switch (or looking to host their first static site).

But first, let me briefly explain why I made the switch in the first place...

Why sourcehut pages?

Using Netlify as your static host is simple, intuitive and comes packed with a great deal of extra functionality you can easily add-on. So, why would I decide to switch over to sourcehut? The best answer comes directly off the main homepage of sourcehut.org:

Absolutely no tracking or advertising
All features work without JavaScript
Many features work without an account
The fastest & lightest software forge
100% free and open source software

After realizing all that, it's pretty difficult to stick with Netlify's proprietary stack...

Free but not "free"

I should note that using sourcehut pages does require you to be a contributing (read: paying) member on the platform. I'm a cheapo and selected the $2/month option but you might be inclined to donate more. Paying this "fee" is perfectly fine for me, considering the hosting quality (speed and storage) it affords me. It also doesn't hurt that I get the "feel good vibes" of supporting an important, open source product.

Keeping that in mind, let's get into setting up our static site!

Setting up your repo locally

Create a new account on sourcehut (or log in to an existing one)
Setup your billing to contribute monthly (tier amount is up to you)
Create a new repo under the git section[^1]
Connect this repo locally (as you would via any other git host)
In this new local directory, place all your Jekyll files as you would with any other static hosting provider

The sourcehut build file

In order to have your Jekyll site build and push the correct files live, you will need to use sourcehut's build system. This will run every time you push out a new change to your repo (new blog post, page content changes, styling updates).

To make things easier, you can copy the build file below (remember to use your own information for usernames, git repo naming etc):

image: debian/stable
+oauth: pages.sr.ht/PAGES:RW
+packages:
+- ruby-full
+- ruby-dev
+environment:
+site: yourusername.srht.site
+sources:
+- https://git.sr.ht/~yourusername/your-repo-name
+tasks:
+- install-bundler: |
+    sudo gem install bundler
+- build: |
+    cd your-repo-name
+    bundle install
+    bundle exec jekyll build
+- package: |
+    cd your-repo-name/_site
+    tar -cvz . > ../../site.tar.gz
+- upload: |
+    acurl -f https://pages.sr.ht/publish/$site -Fcontent=@site.tar.gz
+

Save this file as .build.yml and place it in the root directory of your Jekyll source code.

Then, you just need to push your changes to the repo. If everything was setup properly, you'll be able to see your live site at https://yourusername.srht.site (just give it a little bit of time to run the full build process)

Custom Domains

If you're like me and want to use your own custom domain - have no fear! This process is actually quite easy.

First, add a new A Record through your domain provider:

@ IN A 173.195.146.139
+

Then change the following environment parameter inside your existing .build.yml file:

environment:
+site: yourcustomdomain.com
+

And that's it - custom domain set! If you run into any issues check out the official documentation on custom domains.

Wrapping Up

Hopefully this helps to streamline the process for others to host their static sites through sourcehut. Having open and healthy competition among host providers and git workflows is essential to avoiding vendor lock-in.

Even low-effort support for open-source products (like where you host your static site or FOSS projects) can go a long way. Just some food for thought.

^1]: Thanks to [McSinyx for pointing out that the repo used for creating your website can be named anything (instead of defaulting to your sourcehut username)

Setup Jekyll from Scratch on a New Linux System

2022-09-19T10:00:00Z

Setup Jekyll from Scratch on a New Linux System

2022-09-19

Special Note: Credit needs to be given to user Achraf JEDAY for putting these instructions together on Stack Overflow (although his comments were targeting an older version of Ruby). This post is more for my own personal notes than anything else.

I find myself constantly running into small issues when trying to setup existing Jekyll projects on new Linux systems. I could use something like Docker, but that just seems so beefy and slow to me. So here is a step-by-step way (and foolproof from my own testing) to get Jekyll running smoothly in no time!

Figuring out Ruby First

The first item of business is removing the default Ruby that ships with most Linux distros:

sudo apt-get remove ruby
+

Then we check for updates and install everything we need:

sudo apt update
+sudo apt install git curl libssl-dev libreadline-dev zlib1g-dev autoconf bison build-essential libyaml-dev libreadline-dev libncurses5-dev libffi-dev libgdbm-dev
+

Now we can install rbenv and ruby-build:

curl -sL https://github.com/rbenv/rbenv-installer/raw/main/bin/rbenv-installer | bash -
+

After both of those install, you will want to add those to your system PATH:

Bash

echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
+echo 'eval "$(rbenv init -)"' >> ~/.bashrc
+source ~/.bashrc
+

ZSH

echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.zshrc
+echo 'eval "$(rbenv init -)"' >> ~/.zshrc
+source ~/.zshrc
+

With that complete, we can now install the version of Ruby we wish to use and set it globally (at this time of writing it is 3.1.2):

rbenv install 3.1.2
+rbenv global 3.1.2
+

And rehash so our changes take:

rbenv rehash
+

Now you should see the properly set Ruby version when you run the following:

ruby -v
+

Getting Ruby Gems

In case you don't have it installed already, be sure to grab rubygems:

sudo apt install rubygems
+

Running Jekyll

We are almost done! Navigate to your Jekyll project's directory and run:

gem install jekyll bundler
+bundle install
+

That's it! Now if you run bundle exec jekyll serve you'll find your Jekyll project running locally! Hopefully this helps others when needing to port any Jekyll projects over to a new Linux system. I know it will save me time!

Alpine Linux on Wayland

Save yourself a world of trouble: just use docker. The docker image below (jekyll-serve) works out-of-the-box:

https://github.com/BretFisher/jekyll-serve

Then run the following inside your project:

docker run -p 4000:4000 -v $(pwd):/site bretfisher/jekyll-serve
+

Introducing PageRoast

2021-03-11T10:00:00Z

Introducing PageRoast

2021-03-11

Following up with my concept of releasing small side projects weekly, I have officially launched PageRoast. What is PageRoast I hear you ask?

Receive a detailed report analyzing your landing page with actionable items to improve your conversion rate.
+

In simple terms that just means I will roast your landing page. Included in a page roast report is:

Fully detailed ABCD Framework report
Proposed content & design changes
Page performance audit

And you get all of this for just $100 (currently 50% until April 1st with coupon code PHROAST). Alright, enough with the "sales pitch" - why did I make this side project?

From the main launch blog post on PageRoast itself I wrote:

I've always been obsessed with developing landing pages that produce high conversion rates. It's what I've done for a large portion of my web development career.
+

That's really all there is to it. If you would like to learn more, check out the following links:

Introducing Notez

2021-01-13T10:00:00Z

Introducing Notez

2021-01-13

I have always been a fan of simple note taking applications, since I tend to take a lot of random notes throughout the work day. Sometimes I reach for simple pen and paper, but other times it's nice to stay focused jotting down notes on the same device I'm working on.

Previously, I just created quick notes.txt files in my open code editor or fell back on the default OS note apps. These worked perfectly fine but often got in my way (or even worse - lost among everything else).

So I said the hell with it and built Notez.

What makes Notez special?

Nothing, really. It's actually a pretty "stupid" app compared to others on the market. But this one is mine. Plus, it was fun to piece it together on a random evening before bed.

For those curious, let's take a look at the feature list:

free and open source (github.com/bradleytaunt/notez)
uses localStorage to keep changes persistent (helpful for browser crashes, etc)
includes basic export functionality to download content as a simple output.txt file

That's it. Mind blowing stuff, eh?

Making stuff is fun

My main takeaway when building this tiny, dumb app was to just enjoy building fun stuff. It crossed my mind several times how there are already hundreds of note taking apps across the vast Internet. I also thought about how others might look at the code I wrote and go, "Oh my God - why did he do it that way? What an idiot!". But I don't care - I had fun making it.

Hopefully you enjoy using it as well!

Improving Tufte CSS for Jekyll

2019-11-01T10:00:00Z

Improving Tufte CSS for Jekyll

2019-11-01

After creating the ET-Jekyll theme almost two years ago, I finally got around to revamping the structure and improving a lot of minor performance issues. Items that have been surely needing of updates for the last couple of years.

Introductions

I've always been a sucker for Edward Tufte's incredibly simple, yet powerful design work used in his books and handout projects. So, in 2018 I released a Tufte CSS inspired Jekyll theme for the open source community. I called it ET-Jekyll (so original, I know). Tufte CSS was a great starting point for my Jekyll theme, but there were areas I thought could use some minor improvements.

Feel free to read all the details on the design here: ET-Jekyll theme details

Minor Fixes One Year Later

When I finally circled back to this project recently, I noticed some minor issues that could be improved right away with little to no effort. Let's see the changes made at a glance:

Sidenote, marginnote and figure element restyling (flexbox)
Table styling fixes (right alignment issues)
Switch MathJax over to SVG embeds (performance fixes)
Simplify HTML skeleton of main pages, remove overkill classes
Remove lazysizes.js to save on load times
Fallback on font-display for font loading
Inline all CSS for faster initial paint
Minor link :hover coloring (accessibility)
Add missing image link on example page
Update details post structure

You can view all the updates in more detail here.

So what did this accomplish? Let's break it down below.

First Contentful Paint & Input Delay

The new improvements have netted the theme a savings of 300ms on first paint and reduced the input delay by 150ms. Small wins - but wins nonetheless since every millisecond counts.

+ +

First contentful paint savings: 300ms (direct link to image)

+ +

Reduction in input delay: 370ms down to 220ms (direct link to image)

Fixing Render Blocking Items

The original theme reported a few items that were slowing down the initial render for the end-users:

+ + + + + +

URL	Size (KB)	Savings (ms)
/css/style.css	2.0	150
/lazysizes@4.0.1/lazysizes.js	5.0	960
MathJax.js?config=TeX-MML-AMHTML	18.0	1,260

These items were resolved by:

Rendering all styling inline (therefore removing the extra HTTP request)
Removing the lazysizes library altogether (browsers plan to support lazy loading natively in the future) +
- The future plan is to integrate something like Cloudinary for out-of-the-box image processing
+
Switch over MathJax to render equations as embedded SVGs (saves on bandwidth rendering an entire extra typeface)

Lighthouse Numbers

Though it might not look like much, the updated theme receives a 4-point boost to its performance rating during a Lighthouse audit. Having a perfect score would be even better, but I can settle for 2-points under (for now).

Old Version

+ + + +

Performance	Accessibility	Best Practices	SEO
94	100	100	100

New Version

+ + + +

Performance	Accessibility	Best Practices	SEO
98	100	100	100

Final Thoughts

This project could still use some more fine-tuning, but for now I'm fairly happy with the outcome. Even the smallest boost in performance and rendering time makes me feel like I accomplished something worthwhile.

Please don't hesitate to suggest features or point out any issues you happen to stumble across if you plan to use ET-Jekyll. Thanks for reading!

Improving Receipt UX

2019-05-15T10:00:00Z

Improving Receipt UX

2019-05-15

There was a pretty interesting article posted a couple days ago about rethinking the standard receipt design that I found quite compelling. Although, as good as the concept is, I think it can be improved (simplified) even further.

What was the redesign exaclty?

Overall Susie Lu did a wonderful job tackling such an old and forgotten design. She fixed some major pain points with the current receipt layout:

Bubble chart to visually indicate total spent per category
Categorized items by percentage of total spent
List individual items in descending order based on cost
Bar charts to compliment the item listing order

Curious how her redesign looks? Take a look at the original article

What did this concept get wrong?

Simply put: paper waste.

Using bubble and bar charts from a visual design perspective is great - but not so eco-friendly in this instance (since we are dealing with physical paper waste). It might seem like a small nitpick but with hundreds of thousands (if not millions) of receipts printed daily, this extra paper space required would add up quickly.

Fortunately, I think with some minor tweaks we can keep the underlying principles of the new redesign, while creating a more eco-friendly layout. We can save more space and therefore save on the overall paper needed.

Receipt Redesign

Let's take a look at my redesign concept:

With this layout we are able to keep all the key concepts that Susie Lu initially introduced with her receipt design while preserving more space.

Categories are still listed by percentage of total spent
Individual items are organized in descending order based on cost
Uppercase and lowercase elements are used to distinguish parent / child items instead of additional space or dividers

Final thoughts

The original redesign from a visual perspective is wonderful but when you start to think about implementing it into the real world, it seems slightly impractical. My redesign concept is far from perfect (I'm sure I've overlooked some use cases) but I think it's a strong step forward for redesigning our archaic receipt layouts.

Improving Github's New Design

2020-07-07T10:00:00Z

Improving Github's New Design

2020-07-07

Like many other Github users, I am not a big fan of their recent repository page redesign. In my mind it seems like a change just for the sake of change - the original UI worked perfectly fine.

Sigh.

I was planning on recreating the original Github layout with custom CSS but decided against it. Tackling such a big change in design would cause headaches if Github ever changed even one simple class or id on a given element. My final conclusion was to just improve their new design with my own personal quality of life improvements.

So, enough chit-chat. Let's get into it.

Current Design (2020)

The default view for a repo's homepage and ticket items are locked at a set max-width. This causes some visual strain in comparison to the full-width headers and navigations directly above. I use a decently sized montior when using your app Gitub - let me use all the space available to me!

+ +

The current design of a repo's homepage. (direct link to image)

+ +

The current design of a ticket item (direct link to image)

My Improvements

Your users shouldn't have to jump around the page looking for the important information they want to see. Resetting the basic repo information to the left side of the screen allows user to instantly read-up on the project details. (This design is catered towards left-to-right readers mind you).

We now also utilize all the available screen space, dependent on the user's browser window size.

+ +

The repo's homepage now uses all available space (direct link to image

We make similar updates to the ticket item view and also remove the out-of-place margin-bottom from the project link headers.

+ +

Github ticket items now align better with their header siblings (direct link to image)

Try It Yourself!

You can very easily implement these custom CSS changes with an extension for the browser of your choice:

Firefox: Stylus + Chrome: Stylebot

Then create a new custom CSS file to target github.com with the following properties:

.container-xl {
+    max-width: 100%;
+}
+
+.repository-content .gutter-condensed.gutter-lg {
+    flex-direction: row-reverse !important;
+}
+
+.repository-content #discussion_bucket .gutter-condensed.gutter-lg {
+    flex-direction: row !important;
+}
+
+.repohead > div.d-flex {
+    margin-bottom: 0 !important;
+}
+
+#show_issue {
+    display: flex;
+    flex-direction: row;
+    flex-wrap: wrap;
+}
+
+.repository-content #discussion_bucket,
+#partial-discussion-header {
+    width: 100%;
+}
+

That's it! Feel free to improve on this and further make it your own! I might create a new repo for this project if I end up adding even more improvements to the core CSS.

Write HTML Like It's 1999

2019-06-06T10:00:00Z

Write HTML Like It's 1999

2019-06-06

I am sure it's safe to say that most developers love to use the latest and greatest web tools available. Helpful resources such as preprocessors, template engines, syntax formatters - you name it - can all make a developer's life easier. Unfortunately, this sometimes comes at a cost: the HTML structure.

This is why I try my best to write HTML as if I'm stuck with the constraints of the 90s (within reason). What does this mean exactly? It means that tables are coded with table elements. Navigations are coded with nav and ordered/unordered list-items. Form inputs are not set with display: none and replaced with custom containers. You know, semantic HTML.

To be clear, I'm not advocating for creating projects that look like they belong in the 1990s. I would just prefer developers / designers be more conscious of their HTML skeleton.

Bad HTML practices

Let's do a very simple breakdown of some of the more common HTML no-nos:

Using span or div elements for navigations or list components
Implementing custom div layouts for forms while removing items like select or radio
Creating tables built out of custom div elements
Over-nesting elements or making overly complex depth to simple components
Content being heavily reliant on JavaScript "injection"

Good HTML practices

So what should you do in place of these bad HTML implementations?

Use proper nav, ul and ol for navigations or list components
Style form elements directly this is already supported in browsers
Build tables using table element structure (mind-blowing, I know!)
Keep element hierarchy as slim and top level as possible
Avoid injecting any content via JavaScript (I understand this is difficult for certain apps, but try to minimize this as much as possible)

My basic "structure" test

I've found a pretty simple starting point for testing the bones of a website by using the following single line of CSS:

* {
+    border: 2px dotted black;
+}
+

This property simply outlines all elements on the current page in a dotted border. By placing a border on every HTML element you can instantly see how overly complex or ugly your structure might be under the hood.

"Thanks, Captain Obvious!"

I know, this stuff is pretty basic. The point of this post isn't to tell you (developers) something brand new or mind-blowing, but instead should inspire you to keep things simple.

Don't forget that there is always someone new into the world of design and development. Hopefully this post steers others towards keeping HTML code semantic and clean.

Update to this article

Since this post received so much more attention than I ever expected, I've decided to touch on a few small points brought up in the comments.

What is the benefit of semantic HTML? + - Accessibility. Programs like screen readers are built around the foundation of proper HTML hierarchy. I highly recommend testing all your projects with a screen reader - it will open your eyes to a lot of issues users with disabilities suffer through.
+
Tables not being responsive + - This simply isn't true. It is much more semantic to layout your tables as you would normally, then for mobile devices you can target specific inner elements and alter them with flexbox etc. (You can see responsive tables in action here)
+
Instead of the CSS one-liner, simply use Firefox debugger + - Fair point. Firefox is great!
+

HTML Dark Mode

2023-04-11T10:00:00Z

HTML Dark Mode

2023-04-11

I wrote an article back in 2021 called The Lazy Developer's Dark +Mode where I explained how to implement +a very basic "dark mode" by using the prefers-color-scheme CSS attribute. +This stills works perfectly fine, and in fact there is a cleaner variation of +this created by jacksonchen666: These 3 Lines of CSS Will Give You Dark Mode for Free.

But today I wanted to show how to add dark mode functionality to a website +without any CSS at all.

<meta name="color-scheme" content="dark light">
+

Add that line inside the head tags on your HTML files and you're good to go.

Minor Caveat

I mentioned this same issue on the official barf blog +post but it doesn't hurt to repeat it here. +Safari still has minor ahref / link color issue when defaulting to browser dark +mode. If supporting that browser is a deal-breaker for you, I suggest looking +at my hacky solution.

Hopefully this helps others to add dark mode to their existing websites and +projects with minimal effort!

Using HTML Validator Badges Again

2019-07-05T10:00:00Z

Using HTML Validator Badges Again

2019-07-05

There was a time on the Internet when websites wore badges of honor, declaring that their code was semantic and followed the W3C guidelines. The validators we used weren't great (and still aren't perfect) but they represented a community that took pride in caring about the quality of their work. I think it's time we bring HTML badges back.

Getting the flaws out of the way

Of course, there were reasons why these badges slowly faded out of popularity. Some of the reasoning made sense, but most felt like a stretch in logic from my perspective. I always looked at it as a "the good outweighs the bad".

Jukka Korpela's post way back in 2003, HTML validation is a good tool but just a tool, highlighted a lot of problems with relying so heavily on these HTML validators. I suggest you give it a read if this kind of thing interests you. I found it fascinating, even though I disagree with most of the points he makes.

Some negatives used to dismiss HTML badges:

The badge system is outdated + - Dismissing the worth of something based on how long it has been around is foolish. Many tools and frameworks are "outdated" but are still used to this day with great success.
HTML5 doesn't require validation + - Technically no subset of HTML requires validation - but developers should aim for it. The W3C validators perform a solid job of keeping a standard for web development, so by following a standard we can keep experiences consistent for users.
Validation is too formal + - I believe in the ability to achieve your desired outcome based on almost any constraints. If a project leans you towards invalid or non-semantic structure to fulfill requirements, a better approach needs to be evaluated. We as developers tend to settle too quickly on the easiest option available to us.
Websites / web apps are just too complex to follow the W3C guidelines + - I call BS on this argument. The complexity of a website should have nothing to do with keeping semantic standards. This is your job.
It only exists to catch syntax errors + - For the record, I still see this more of a positive take on using validators. Subtle and nuanced syntax mistakes can be easily overlooked by the human eye.

"Nobody puts badges in a corner"

A large of amount of designers / developers tend to forget that there are new people entering our industry everyday and they might not be as well versed in the basics of the web (HTML & CSS specifically). Since so many newcomers start out with JavaScript frameworks or jump onto pre-existing projects, they don't always grasp the core foundation of valid markup. Some frameworks even break basic standards for visuals or easier development environments - setting their initial expectations that ugly semantics is acceptable code. The ends justify the means, etc.

Guiding first-timers towards HTML validators let's them rethink their structure when building products or at least give some forethought to their outputted code. We, the more verteran members of the community, have the knowledge of proper semantics since we grew our careers around this "trend". We shouldn't assume newbies have the same understanding. The basics are important.

Open source HTML5 badge

Since the W3C doesn't officially produce any badges for HTML5 validation ¹, I've gone ahead and open sourced SVG and PNG versions of a badge based off the current W3C designs. You can check out the Github repo: HTML5 Valid Badge

If you decide to use these badges, be sure to link these images to your valid passing URL (html5.validator.nu). You can see an example of the link in the footer of this website.

Please feel free to reach out and share your websites / projects that pass as valid HTML and include an HTML valid badge. I'd love to check them out!

Refs

¹ Interview with Mike Smith: "There won't be any proper Valid HTML5 icon forthcoming, so if you'd like to use one in your content, you'll probably need to create one on your own."

Goodbye WordPress, Hello Jekyll (Again)

2020-08-13T10:00:00Z

Goodbye WordPress, Hello Jekyll (Again)

2020-08-13

For the past four months this blog has been running on WordPress - but that ended today. I've officially switched back over to Jekyll. I'm not going to spend too much time delving into why I made the transition back, but I'll leave some cliff-notes for any interested parties.

The big issues with my WordPress setup

I have to state that these problems existed based on my own setup / hosting choices with WordPress - this is not a direct reflection of WP itself.

No theme editor access

- I was using EasyWP (Namecheap etc.) for my web hosting. It only cost me $3.88/month, which was very cheap for the quality of service provided. Unfortunately, this low price came with some setbacks. EasyWP doesn't allow users to edit header.php or functions.php files directly in the theme editor. Having to resort to FTP for simple one-line change was annoying.

+ +

Super cache

- Caching web pages is wonderful for users on subsequent visits, but EasyWP took this to the extreme. Making minor styling updates sometimes required code changes in the header.php file directly in order to persist (see problem with editing these files in point #1).

+ +

Monthly cost

- As I stated above, spending $3.88 on a monthly basis was peanuts in the grand scheme of things. Still, an extra monthly subscription for a side hobby seemed overkill for my use case.

+ +

Future proofing

- In the end, having the core website generate itself into static files means it will stand the test of time on the interwebs. HTML & CSS FTW.

What I lost in the switch

Comments

- I loved the concept of owing / hosting comments directly on each post but this seemed like a fair trade-off when compared to the positives listed above. I might circle back around and use something like Commento or Gitment

+ +

Blog anywhere

- Having the ability to hop on any machine, log in to my site and blog was awesome. Over time though, I found myself not doing this very often. Most times when composing an article I found I would write it out, edit and publish all in one sitting. Cool concept - just not as useful.

Moving forward

I've learned to stick with what keeps me productive (and in this case, keeps me writing consistently). I still love WordPress and won't hesitate to reach for it when the need arrives. Unfortunately, it seems my personal website isn't one of those instances.

Converting HEIF Images with macOS Automator

2023-07-21T10:00:00Z

Converting HEIF Images with macOS Automator

2023-07-21

Often times when you save or export photos from iOS to iCloud they often render themselves into heif or heic formats. Both macOS and iOS have no problem working with these formats, but a lot of software programs will not even recognize these filetypes. The obvious step would just be to convert them via an application or online service, right?

Not so fast! Wouldn't it be much cleaner if we could simply right-click our heif or heic files and convert them directly in Finder? Well, I've got some good news for you...

Basic Requirements

You will need to have Homebrew installed
You will need to install the libheif package through Homebrew: brew install libheif

Creating our custom Automator script

For this example script we are going to convert the image to JPG format. You can freely change this to whatever format you wish (PNG, TIFF, etc.). We're just keeping things basic for this tutorial. Don't worry if you've never worked with Automator before because setting things up is incredibly simple.

Open the macOS Automator from the Applications folder
Select Quick Option from the first prompt
Set "Workflow receives current" to image files
Set the label "in" to Finder
From the left pane, select "Library > Utilities"
From the presented choices in the next pane, drag and drop Run Shell Script into the far right pane
Set the area "Pass input" to as arguments
Enter the following code below as your script and type ⌘-S to save (name it something like "Convert HEIC/HEIF to JPG")

for f in "$@"
+do
+/opt/homebrew/bin/heif-convert "$f" "${f%.*}.jpg"
+done
+

Making Edits

If you ever have the need to edit this script (for example, changing the default format to png), you will need to navigate to your ~/Library/Services folder and open your custom heif Quick Action in the Automator application.

Simple as that. Happy converting!

If you're interested, I also have some other Automator scripts available:

Stop Using Hamburger Menus (Sometimes)

2023-05-05T10:00:00Z

Stop Using Hamburger Menus (Sometimes)

2023-05-05

I recently tooted about my hatred of website hamburger menus which was met with a surprising amount of support from other users. It seems like most people don't actually like hamburger menus. So why do we, as developers, keep using them in our products and designs? Is it our only option? Or is it because we have become conditioned to expect it?

The Core Problem with Hamburger Menus

The biggest headache when coming across these menus on the web is the complete disregard for accessibility. Performance and solid user experience is almost always thrown out the window in favour of a "prettier" design layout. You might have made the overall design "cleaner" for your users, but you sacrificed all usability to do so.

I challenge you to visit a webpage or web app with a hamburger menu and try to navigate solely with your keyboard and screen-readers (or better yet - try these screen readers on mobile!). Within seconds you will find a whole mess of issues. Now try the same test with JavaScript disabled... Yikes.

"But I Have No Choice!"

I see this argument pop-up frequently when taking to design leaders or developers. I call bullshit on this excuse. You absolutely have the choice to avoid implementing bad designs - that's your job! Either you're not fighting hard enough against those pushing for it, or you're just trying to build a "pretty" portfolio.

Best Alternative: Sitemap Footer

So instead of just whining about hamburger menus, I will actually offer up a solid replacement: sitemap footers. Simply place all your website/application links into the bottom footer and link directly to them from your header. Be sure to also include some form of "Top of the page" link for quick access back to the initial scroll view.

That's it. There is nothing else you need to do for this to just work. It might sound oversimplified and that's because it is. Looking for an example? This very website utilizes this technique, so give it a spin! Try using just your keyboard or even better - use a screen reader. Disable JS and CSS and watch it work flawlessly still.

Pros:

Keyboard navigation accessible
Excellent screen-reader support
Works on all devices/screens by default (no media queries!)
Stays out of the way until called upon (UX goodness)
Requires ZERO CSS or JavaScript

Cons:

Footer can become large with many links (although I really don't see this as a big deal)

No Excuse

There really is no excuse to still be using hamburger menus. Users expect them to be present only because we as designers have conditioned them think that way. They deserve a better experience on the web. The least we can do is improve something as simple as website navigation...

Using Hamburger Menus? Try Sausage Links

2019-06-14T10:00:00Z

Using Hamburger Menus? Try Sausage Links

2019-06-14

When designing medium to large sized menu navigations on the mobile web the default go-to, for some time now, has been hamburger menus. This isn't necessarily a bad thing, but there is a simpler alternative for certain use cases.

Before we get into the nitty-gritty details (and a simple demo) of the sausage link concept, let's take a quick look at the pros and cons of hamburger menus.

Hamburger Menus

The concept of the hamburger menu isn't horrible by any means, in fact it does solve a lot of problems from a visual perspective. Unfortunately, that doesn't mean it exists without some annoying flaws.

The Good

Minimizes the amount visual space the menu requires
Fairly commonplace now that a good portion of users understand it's functionality
Makes the lives of designers easier by tucking all items away on mobile 😛

The Bad

Requires extra testing/work to ensure the menu will play nice with screen readers and keyboard-only users
Can get overly complex with the presence of children dropdown elements, help text etc.
Adds bloat to projects that might require additional JavaScript to render these menus (CSS only hamburger menus avoid this issue)
Adds an additional point of interaction from the user (click to open, then proceed to read through available options)

As you can see, the bad points listed above aren't that bad. I see them more as minor potholes along the UX journey for your end-users. A good portion of hamburger menu examples in the wild work perfectly fine and should remain as they are. However, those outliers who abuse or misuse the hamburger concept should be introduced to sausage links.

Sausage Links

I should start by mentioning that this concept is far from new. There are a good number of websites that already implement this menu type in some form or another. The point of this post isn't to blow your mind with some new-never-thought-of navigation design. I'm just trying to bring awareness to another available menu concept.

Enough chit-chat, let's take a look at sausage links in action:

Live CodePen Example

The above CodePen adds a good amount of visual design fluff, so let's take a look at the bare minimum HTML & CSS needed to accomplish this menu:

<nav class="sausage-links">
+    <ul>
+        <li><a href="">Homepage</a></li>
+        <li><a href="">Categories</a></li>
+        <li><a href="">Filter Properties</a></li>
+        <li><a href="">Edit Optional Tags</a></li>
+        <li><a href="">Research Papers</a></li>
+        <li><a href="">Contact Our Team</a></li>
+    </ul>
+</nav>
+

/* Sausage Links Nav Container */
+.sausage-links {
+    position: relative;
+}
+
+/* The left and right "faded" pseudo elements */
+.sausage-links:before, .sausage-links:after {
+    content: '';
+    height: calc(100% - 2em);
+    pointer-events: none;
+    position: absolute;
+    top: 1em;
+    width: 10px;
+    z-index: 2;
+}
+.sausage-links:before {
+    background: linear-gradient(to right, rgba(255,255,255,0) 0%, white 100%);
+    right: 0;
+}
+.sausage-links:after {
+    background: linear-gradient(to left, rgba(255,255,255,0) 0%, white 100%);
+    left: 0;
+}
+
+/* Basic flexbox to prevent items from breaking lines */
+.sausage-links ul {
+    display: flex;
+    flex-wrap: nowrap;
+    overflow: auto;
+    -webkit-overflow-scrolling: touch;
+}
+
+.sausage-links ul li {
+    white-space: nowrap;
+}
+
+.sausage-links ul li a, .sausage-links ul li a:visited {
+    display: inline-block;
+}
+

Pretty simple, eh?

Update: Thanks to @dany0w for pointing out that I forgot to include -webkit-overflow-scrolling: touch for momentum scrolling on iOS.

The Good

Extremely minimal amount of CSS required
Screen reader / keyboard-only safe
Zero JavaScript needed
No need for hacky hidden radio inputs for toggling parent containers etc.
Users can see first few available options without any interaction

The Bad

May not look the most visually appealing for certain project designs (ugly scrollbar in some instances)
Better suited for small to medium menu lists compared to massive sitemaps
Without proper fade / cut off visual cues, users may not understand they can scroll

So, should I use hamburger menus or sausage links?

That really depends on your project or overall mobile design (I know, such a helpful answer). I'm sure there are even a few use cases where it would make sense to have sausage links within a toggle-based hamburger menu. The menu possibilities could be endless!

That's it. I hope I've inspired you to try out sausage links in the near future or at least made you think more deeply about mobile navigation design!

...is anyone else really hungry now?

Goodbye CSS Preprocessors

2017-09-07T10:00:00Z

Goodbye CSS Preprocessors

2017-09-07

I have been using preprocessors across all my side projects since they first popped onto the scene. Sass, Stylus, LESS — you name the CSS preprocessor and I've most likely used it because CSS preprocessors are awesome.

But that all changes moving forward. I'm going back to basics with CSS. Straight vanilla, man.

Why? And who cares?

Let's start by breaking down the main positives about preprocessors:

Nested syntax
Definable variables
Advanced mathematical functions
Reusable mixins

All of these features are great and I completely understand the draw (I was also sucked into the hype) - but now let's see the negatives.

1. Debugging is a chore

So you found some weird padding clobbering an element's default styles on line 255 of your main complied CSS file? Excellent! Now you just need to figure out which file that property comes from.

This might sound trivial or that you can fix this with rendered comments but if you ever work on a project with hundreds of Sass/Stylus/LESS files all importing and compiling into each other - it can get out of hand.

Solution: Using plain CSS makes using browser dev tools a breeze. See a bug on line 255? No problem, let me fix line 255.

2. Dependencies for development

Building a project with a preprocessor brings with it unnecessary baggage; dependencies. You'll need to be running some sort of task runner (see grunt or gulp) that will compile and minify your CSS. I see this as extra overhead both during the initial setup of the project for new team members and the testing environment.

By using plain CSS, you avoid including an extra package in your package.json file (if applicable) or having to rely on third party compilers such as codekit (although I do recommend this app).

3. Variables & mixins become unwieldily

Both variables and mixins are great in small doses, but if your project has any real size to it these helpers become a hinderance. By using comma-delimited CSS selectors you can achieve the same outcome without the horror of needing a specific preprocessor file to handle just variables and mixins.

Basic example:

selector, selectTwo, .css-class {
+    /* shared styling */
+}
+

4. Welcome to nesting hell

Honestly, I've never been a fan of nesting. From a file structure perspective it is indeed very "clean", but you sacrifice that cleanliness in the final compiled production code. You're making your development environment easier to glance at and work through at the cost of your production-ready, customer facing code.

You also run into another big no-no in my eyes: extreme selector specificity. The DOM target search starts to get out of control once you start having classes and selectors building up towards 10 or more steps.

Bad:

body #home .container .modal nav .inner-nav > ul > li > a {
+    color: red;
+}
+

Good:

.inner-nav a {
+    color: red;
+}
+

Don't forget the amount of work needed to override styling with such deep selector specificity. That's where you end up diving into the world of !important tags.

Final thoughts

It should go without saying that this is just my personal preference, there is no law behind this. If you use and absolutely love preprocessors - more power to you. All I suggest is using plain old vanilla CSS for your next project and see how it works out.

And do you know what I've learned to appreciate after switching back to vanilla? CSS is more beautiful when developed in it's rawest form.

Applying Email-Based Git Patches in Evolution on Linux

2023-04-25T10:00:00Z

Applying Email-Based Git Patches in Evolution on Linux

2023-04-25

Users who work with git patches through email most likely use a terminal-based program such as aerc or mutt. CLI email clients tend to have built-in support for easily applying patches directly to their local repos. But what about people who prefer to use graphical email apps?

Lucky for us, it is actually fairly simple to replicate a similar workflow to that of a CLI client. In this example I will be focusing on the Evolution email client, but the core principles should work in most other GUIs.

The Basics

Note: The following assumes you already have git installed and setup on your existing system.
+

I find it best to first create a top-level folder on your system named patches. We will use this folder as a temporary location for reviewing any git patches submitted via email. I normally place this under /home/<username>/patches.

Next, locate the email patch in Evolution and right-click on it. Select "Save as mbox..." and place this file inside your newly created patches folder.

Now simply open your terminal, navigate to your project and run:

git am <path-to-patches-folder>/<patch-filename>.mbox
+

This should apply the patch directly to your project without issue. You are now free to test these changes locally. If everything looks good, you're able to instantly push these changes remotely.

Done and done.

Feel free to purge your patches folder regularly or keep them around for future reference if you prefer!

Simplifying the Craigslist Gallery

2022-10-03T10:00:00Z

Simplifying the Craigslist Gallery

2022-10-03

This article was updated on October 11, 2022

I'm a big fan of craigslist.org and the overall UX used throughout their application. My own website is an ever-changing example of "brutalist" or minimalist design, so I'm always inspired by existing web apps out in the wild using the same principles.

One nitpick I have with the current craigslist design is their approach to image galleries inside their listings. They use a chunk of bloated JavaScript (more than 380kB total) to render something as simple as a collection of images. This seems like overkill to me.

+ +

The current look of image galleries on craigslist

Simplifying Things

My first suggestion would be to remove JavaScript altogether. We can replicate most of the required features with just HTML & CSS. Let's start with our core HTML structure:

HTML

<div class="gallery-wrapper">
+    <div class="full-size">
+        <a name="p1"><img src="https://picsum.photos/id/100/400" alt="Picture 1" class="gallery-item"></a>
+        <a name="p2"><img src="https://picsum.photos/id/101/400" alt="Picture 2" class="gallery-item"></a>
+        <a name="p3"><img src="https://picsum.photos/id/106/400" alt="Picture 3" class="gallery-item"></a>
+    </div>
+    <div class="thumbnails">
+        <a href="#p1"><img src="https://picsum.photos/id/100/100" alt="Picture 1 Thumbnail" class="thumbnail-1"></a>
+        <a href="#p2"><img src="https://picsum.photos/id/101/100" alt="Picture 2 Thumbnail" class="thumbnail-2"></a>
+        <a href="#p3"><img src="https://picsum.photos/id/106/100" alt="Picture 3 Thumbnail" class="thumbnail-3"></a>
+    </div>
+</div>
+

Here we are placing the full-size gallery images directly inside a single div.full-size as - you guessed it - img elements. This already helps us avoid the pitfall of building out spaghetti div containers.

Below this parent container we have another element, div.thumbnails, which will be used for our separate, smaller thumbnail versions of our main images. The most important items to note are the associated ahref elements surrounding each img element. By setting the id parameter on our thumbnails to match that of the name on our full-sized images, we can "scroll" the proper image into view without the need for JavaScript.

Now for the fancy stuff - the CSS!

CSS

.gallery-wrapper {
+    position: relative;
+}
+.gallery-wrapper:before {
+    background: rgba(255,255,255,0.8);
+    content: "Scroll / Swipe 🡢";
+    display: block;
+    padding: 5px;
+    position: relative;
+}
+
+.full-size {
+    display: flex;
+    scroll-snap-type: x mandatory;
+    margin-bottom: 10px;
+    max-width: 400px;
+    overflow-x: scroll;
+}
+.full-size .gallery-item {
+    scroll-snap-align: start;
+}
+

.thumbnails img {
+    cursor: pointer;
+    margin-right: 10px;
+}
+

Okay, so it isn't that fancy. It's actually very basic, which is exactly what we were going for. The images are "stacked" inline thanks to the parent container being set to display: flex, even though it has a set width of 600px. The included scroll-snap-type: x mandatory tells the browser to allow users to scroll/swipe horizontally through the parent container.

The last important piece of this CSS is the scroll-snap-align: start added to the individual image elements. This parameter snaps the next image into the starting position of the parent container on scroll, giving a behavior users have come to expect from media galleries.

You will also see the included :before pseudo element attached to the main .gallery-wrapper element. This isn't required but it certainly helps from a UX standpoint.

Live Demo

Check out the embedded CodePen below to see it in action. More functionality could always be built on top of this, such as rendering all images dynamically on "build", but for a starting point I think it's great.

Live CodePen Example

Chrome OS Could Become the Future Leader of Computing

2022-01-06T10:00:00Z

Chrome OS Could Become the Future Leader of Computing

2022-01-06

FOSS Enthusiasts: This article discusses the use of proprietary software and places it in a positive light. You have been warned. No angry emails please...

Google has created one of the best operating systems designed with the everyday user¹ in mind: Chrome OS. It is undeniably simple, reliable, easy to setup, and ships with several years of support before any form of EOL kicks in. New models have built-in support for the Google Play Store and Android applications, which is helpful for application development and debugging.

In addition, Chrome OS devices allow you to run Linux in a separate container alongside the main OS (on supported devices). You can't complain about that!

Let's take a quick look at other positive features worth mentioning:

Verified boot
Sandboxed environment (similar to how Chrome tabs work)
Automatic updates[^2]
Incredible battery life (were talking 10+ hours with heavy usage)

My Personal Experience

A handful of months ago I snagged the Lenovo Chromebook Duet when it was on sale for my wife. Since she does all her work directly through an Android phone, I thought of this as a nice companion device. And indeed it was/is.

In that time, I played around with the tablet myself to have a better grasp of the ecosystem and it's obvious limitations. But a funny thing happened. I found that those "limitations" slowly started to disappear the longer I worked with the device.

I decided to get my own Chrome OS device and snagged the Lenovo 10e Chromebook Tablet (on sale).

+ +

Introducing the Lenovo 10e Chromebook tablet. This bad boy can do close to everything your current computer can do but it'll cost you $129...

10.1" display (1920 x 1200) / 400 nits
4GB of RAM
32GB of eMMC storage
Processor: MediaTek MT8183 Processor (2.00 GHz, 4 Cores, 1 MB Cache)

Now, I know that your initial reaction is likely: "Wow, those specs are pretty barebones!" and you would be correct. But it's all you need for this ecosystem to work. As cringe-inducing as it may sound, everything you plan to do on these devices should happen in the cloud. (Let's take a moment to avoid vomiting in our collective mouths)

Instead of using a few marketing buzz words, let me breakdown how I personally tailor Chrome OS to my needs as a designer / developer:

Daily Tasks
Programming
Design
Gaming

Daily Tasks

I feel like going into great detail explaining how to do basic, daily computing tasks is a little overkill here. Spreadsheets, word documents, Zoom meetings, and streaming media work as expected. You have the ability to use Google's own web apps for these things or reach for other vendors such as Microsoft and Libre Office. Not being "locked in" to Google software is nice and I appreciate the Chrome OS team being flexible.

Programming

This one is a mixed bag and your own mileage may vary depending on your specific requirements. Personally, I use Github for almost all my main development work. Because of this, I utilize Codespaces. For those unfamiliar with the service, you are running your Github repo in VSCode through the browser. It's pretty impressive.

If you happen to be a user who uses GitLab or BitBucket to store your project files, Gitpod is a similar product to Codespaces (which I've used on occasion). This works if your prefer.

Others may not like this programming setup but for me it works great. If running code remotely isn't your jam, you could always take a look at running VSCodium locally via Linux.

Design

There is flexibility yet again in this category. Personally, I tend to use Figma almost exclusively as my main design tool. The best thing about Figma? It runs directly in the browser. A perfect fit for Chromebooks[^3].

I do open Gimp periodically for photo-specific work. It runs in its own Linux container and chugs along smoothly, even with 4GB of available memory. If all else fails, one could use Photopea to keep everything working through the browser (if Linux isn't your cup of tea).

Those of you in love with MacOS specific apps like Sketch - I can't help you. You're stuck with Apple's ecosystem. (Not that there is anything wrong with Sketch!)

Gaming

There are other options (that we will get into) but the main gaming champion here is Stadia[^4]. As long as your internet speeds are over 10mbps, mind you. I use garbage satellite internet (counting down the days for Starlink to become available here...) with an average speed of 18-20mbps and Stadia runs like a dream. Even wirelessly. Now pair this with the portability of a Chromebook device and you've got yourself a beefier Nintendo Switch.

You have solid secondary options like GeForce Now and Microsoft's xCloud (beta) for an even larger catalogue of games. Not to mention the ability to play a lot of Android games natively on Chromebooks that support Play Store applications.

Eye Rolling & Scoffing

I can hear the screeching across the interwebs: "Wait - this is Google! They are literally Satan in disguise! No one can use products from that evil mega corporation!". And while I agree with the sentiment, I think going down this pure, 100% elitist approach to software doesn't work with the everyday casual user. Not to mention the large swath of developers/designers screaming "Google is bad!" while working off an Apple device...

Hell even I, a vocal advocate for open source software and privacy, can see the great benefits to using Chrome OS as a daily driver.

Testing out Chrome OS with your non-technical friends and family could help reduce a lot of headaches found in more "popular" systems. That doesn't mean advanced users have to switch over. Use what works the best for you. For my immediate family members and social circles, I have nothing but positive things to say about Chrome OS.

I have no crystal ball to see what the future of Chrome OS holds but it looks pretty promising to me.

Refs

"Users" referring to those mainly using their devices for word documents, spread sheets, media consumption, programming, messaging, minor interactivity (no heavy video or production editing)
These updates go unnoticed, compared to that of MacOS or Windows...
Your mileage may vary depending on how much RAM you have on your device
Although, Stadia's current game selection leaves a lot to be desired

Prescription Form UI Improvements

2019-03-13T10:00:00Z

Prescription Form UI Improvements

2019-03-13

I was browsing the Clearly website a few days ago and ended up using their prescription form to update my worsening eyesight. The design of this form wasn't bad per se, but it could certainly be improved.

Current design of the prescription view

As I stated, this design isn't horrible by any means, but right away we can notice some problems:

the layout causes the users' eyes to jump between left-to-right and top-to-bottom without good correlation
title content and next buttons are centered, while dropdowns are presented as left-to-right
anchor link coloring is inconsistent
too much whitespace between interactive sections
dropdown height overly large

Starting to make some changes

Let's tackle these problems one at a time. First, we want a more defined page layout so the user can scan through the content more easily (left-to-right, down to the next line, then repeat).

We have now left-aligned the title content to be flush with the OD/OS elements below it to help keep the reading flow consistent.

The previous layout also had the PD in-line with the OD/OS element rows which created a problem of resetting the user thought-process. Since it requires the user to jump from the "right eye" option to the "PD" option, then back to "left eye" option it breaks the flow of user "tasks". The new UI shifts the PD down into it's own row, grouping the unrelated tasks on the page separately.

You'll also notice that I've updated the dropdowns to use a monospace font to convey that these options are number inputs.
+

Finally we place the button actions in-line with the PD block since it previously ate up far more real estate than was necessary.

Adding some color

The original design has some inconsistencies with the link coloring - some being a muted grey while others use the accented blue. Updating all interactive links to use Clearly's default blue accent color would make for a better disconnect from non-interactive elements.

Finishing touches

Now that the most important aspects of the refreshed UI are complete (layout, UX flow), we can implement all the visual extras to cleanup our basic wireframe.

make default select styling include depth and importance (this is the main action of the page afterall)
round out harsh corner edges on elements
set labels and row items with more pleasing backgrounds (while still maintaining contrast)
give the next button visual importance (make it look like a real button)

That's it!

Adaptable Flexbox Grid

2018-11-22T10:00:00Z

Adaptable Flexbox Grid

2018-11-22

You can use flexbox for many tricky layout "hacks" and implementing a grid layout is no different.

Check out the CodePen below to see how you can implement a flexbox grid system that adapts automatically based on how many items you insert per row (maximum 6 children in this example).

Live CodePen Example

Pure CSS Bar Graphs with Graceful Mobile Fallbacks

2020-12-08T10:00:00Z

Pure CSS Bar Graphs with Graceful Mobile Fallbacks

2020-12-08

I recently published a new open source project, Flexbox Bar Graphs, and wanted to share a simple breakdown of how it was built. It isn't anything mind-blowing, but I like the idea of placing bar graphs in a web page with zero Javascript.

So in the end, this is what our bar graphs will look like on desktop:

+ +

The flexbox bar graph in desktop view (direct link to image)

And this is how it will look on smaller devices:

+ +

The flexbox bar graph on mobile devices (direct link to image)

Let's get into the details!

The HTML

The main "secret" of this project is that our graphs are constructed out of HTML tables. Now before you freak out - this is perfectly fine and works in our favor quite well.

If the user has JS disabled --> they will still see our graphs
If the user has CSS disabled --> they will see a standard data table set

All bases are covered!

<!-- Using a basic table with our custom data-id -->
+<table data-id="flexbox-bar-graph">
+    <caption>Web Performance Results</caption>
+    <thead>
+        <tr>
+            <th>Test Performed</th>
+            <th>Before</th>
+            <th>After</th>
+            <th>Difference</th>
+        </tr>
+    </thead>
+    <tbody>
+        <tr>
+            <th>Initial Load Time</th>
+            <td>
+                <!--
+                    WTF are these CSS variables?
+                    See the CSS section below
+                -->
+                <span style="--data-set:4.7/5;"></span>
+                <p>4.7</p>
+            </td>
+            <td>
+                <span style="--data-set:2.7/5;"></span>
+                <p>2.7</p>
+            </td>
+            <td>
+                <span style="--data-set:2/5;"></span>
+                <p>2</p>
+            </td>
+        </tr>
+    </tbody>
+</table>
+

Nothing crazy is happening here - just your standard HTML table structure. The one main thing to notice is the --data-set CSS variable placed inline on each data point. This will be important for our CSS to configure the individual bar graphs properly.

The CSS

This might look overwhelming if I just dumped the whole CSS file in one big code block, so instead I'm going to break them down into two parts:

Baseline styling (mobile)
Desktop styling

Baseline

Here we target just our table elements with the data-id of flexbox-bar-graph. This allows us to avoid worrying about adding classes or IDs and also avoids conflicts with other non-graph styled tables in our projects.

The base :root element holds all of our bar graph colors. Change these as you see fit!

/* Bar Graph color variables */
+:root {
+    --bar-color-1: #357EC7;
+    --bar-color-2: #E42217;
+    --bar-color-3: #4CC417;
+    --bar-color-4: #7D0541;
+    --bar-color-5: #FFD801;
+}
+

[data-id="flexbox-bar-graph"] {
+    border-collapse: collapse;
+    margin: 4rem 0 6rem;
+    width: 100%;
+}
+[data-id="flexbox-bar-graph"] caption {
+    text-align: left;
+}
+[data-id="flexbox-bar-graph"] thead th {
+    text-align: right;
+}
+[data-id="flexbox-bar-graph"] thead th:nth-child(1),
+[data-id="flexbox-bar-graph"] tbody th {
+    text-align: left;
+}
+[data-id="flexbox-bar-graph"] tbody th {
+    font-weight: normal;
+    font-style: italic;
+}
+[data-id="flexbox-bar-graph"] tbody td {
+    text-align: right;
+}
+[data-id="flexbox-bar-graph"] tbody td p {
+    margin: 0;
+}
+

Desktop

Now we set your "visual" bar graphs to show at a set width (in this example it is 1000px and above). That way the "default" styling can target the mobile device screen sizes.

The thead tr th:nth-child(x):before elements create the square "legends" beside each individual data point heading
The tbody tr td:nth-of-type(x) span elements are the bars themselves

@media(min-width: 1000px) {
+    [data-id="flexbox-bar-graph"] {
+        background: transparent;
+        display: block;
+        min-height: 400px;
+        padding: 0;
+        position: relative;
+        width: 100%;
+    }
+
+    [data-id="flexbox-bar-graph"] caption {
+        display: block;
+        font-size: 2rem;
+        text-align: center;
+        width: 100%;
+    }
+
+    [data-id="flexbox-bar-graph"] thead {
+        display: block;
+        margin: 2rem 0 3rem;
+        width: 100%;
+    }
+    [data-id="flexbox-bar-graph"] thead tr {
+        border-bottom: 1px solid lightgrey;
+        display: flex;
+        justify-content: center;
+        padding-bottom: 1rem;
+    }
+
+    [data-id="flexbox-bar-graph"] thead tr th {
+        display: inline-block;
+        margin: 0;
+        padding: 0;
+        position: relative;
+        text-align: right;
+    }
+    [data-id="flexbox-bar-graph"] thead tr th:before {
+        content:'';
+        display: inline-block;
+        height: 10px;
+        margin: 0 0.5rem 0 2rem;
+        position: relative;
+        width: 10px;
+    }
+    [data-id="flexbox-bar-graph"] thead tr th:nth-child(1),
+    [data-id="flexbox-bar-graph"] thead tr th:nth-child(1):before {
+        display: none;
+    }
+    [data-id="flexbox-bar-graph"] thead tr th:nth-child(2):before {
+        background: var(--bar-color-1);
+    }
+    [data-id="flexbox-bar-graph"] thead tr th:nth-child(3):before {
+        background: var(--bar-color-2);
+    }
+    [data-id="flexbox-bar-graph"] thead tr th:nth-child(4):before {
+        background: var(--bar-color-3);
+    }
+    [data-id="flexbox-bar-graph"] thead tr th:nth-child(5):before {
+        background: var(--bar-color-4);
+    }
+    [data-id="flexbox-bar-graph"] thead tr th:nth-child(6):before {
+        background: var(--bar-color-5);
+    }
+
+    [data-id="flexbox-bar-graph"] tbody {
+        display: flex;
+        justify-content: space-between;
+        min-height: 300px;
+        width: 100%;
+    }
+
+    [data-id="flexbox-bar-graph"] tbody tr {
+        display: flex;
+        flex-direction: column-reverse;
+        flex-wrap: wrap;
+        justify-content: flex-end;
+        padding: 0 50px;
+        position: relative;
+        width: 100%;
+    }
+    [data-id="flexbox-bar-graph"] tbody tr th {
+        font-size: 90%;
+        position: absolute;
+        text-align: center;
+        top: 100%;
+        width: calc(100% - 100px);
+    }
+    [data-id="flexbox-bar-graph"] tbody tr td {
+        align-items: center;
+        display: flex;
+        flex-direction: column;
+        height: 95%;
+        justify-content: flex-end;
+    }
+
+    [data-id="flexbox-bar-graph"] tbody tr td span {
+        display: block;
+        height: calc(var(--data-set) * 100%);
+        width: 20px;
+    }
+    [data-id="flexbox-bar-graph"] tbody tr td:nth-of-type(1) span {
+        background: var(--bar-color-1);
+    }
+    [data-id="flexbox-bar-graph"] tbody tr td:nth-of-type(2) span {
+        background: var(--bar-color-2);
+    }
+    [data-id="flexbox-bar-graph"] tbody tr td:nth-of-type(3) span {
+        background: var(--bar-color-3);
+    }
+    [data-id="flexbox-bar-graph"] tbody tr td:nth-of-type(4) span {
+        background: var(--bar-color-4);
+    }
+    [data-id="flexbox-bar-graph"] tbody tr td:nth-of-type(5) span {
+        background: var(--bar-color-5);
+    }
+
+    [data-id="flexbox-bar-graph"] tbody tr td p {
+        font-size: 90%;
+        margin: 0;
+        text-align: center;
+    }
+}
+

Bonus Styling

In the Flexbox Bar Graph repo, I've also included the ability to display these bar graphs horizontally, like so:

+ +

The flexbox bar graph in the horizontal layout (direct link to image)

The change in CSS is actually quite simple to pull this off - you just need to include the data-layout attribute on the table itself.

[data-layout="horizontal"] tbody {
+    min-height: auto;
+}
+
+[data-layout="horizontal"] tbody tr {
+    flex-direction: column;
+    padding: 0 40px;
+}
+[data-layout="horizontal"] tbody tr th {
+    width: calc(100% - 80px);
+}
+
+[data-layout="horizontal"] tbody tr th {
+    text-align: left;
+    top: calc(100% + 20px);
+}
+
+[data-layout="horizontal"] tbody tr td {
+    flex-direction: row;
+    height: auto;
+    justify-content: start;
+    margin: 10px 0;
+}
+
+[data-layout="horizontal"] tbody tr td span {
+    height: 20px;
+    width: calc(var(--data-set) * 100%);
+}
+
+[data-layout="horizontal"] tbody tr td p {
+    margin-left: 10px;
+}
+

That's All Folks!

That just about sums things up. Feel free to check out the Github repo itself, open any issues you find or fork it for your own!

Github: https://github.com/bradleytaunt/flexbox-bar-graphs
Live Demo: https://flexbox-bar-graphs.netlify.app/

First Letter Pseudo Element

2019-05-03T10:00:00Z

First Letter Pseudo Element

2019-05-03

In today's TypeTip we will be taking a look at the often overlooked :first-letter CSS pseudo element. Though you might only use this for specific article-format web pages, it's still a nice-to-have in your web dev toolset.

The HTML

Like most pseudo elements, nothing has to change with your pre-existing HTML structure:

<article>
+    <p>It was a bright cold day in April, and the clocks were striking thirteen.</p>
+</article>
+

The CSS

Here's where the magic happens:

p:first-letter {
+    color: orangered;
+    font-size: 250%;
+}
+

Live CodePen

Live CodePen Example

February 2022 Update

2022-02-23T10:00:00Z

February 2022 Update

2022-02-23

It's been a little quiet around here lately and for good reason: my wife gave birth to our third child last Thursday. Her name is Harmony and she was born in the late afternoon weighing in at 7 pounds 8 ounces.

Besides the lack of sleep, everything has been going very well and our boys are happy to finally have their sister “out” in the real world. She caught a small cold at the beginning but soldiered through it well.

As for personal life / work life, I've taken a couple weeks off until Harmony is in a bit more of a routine to make transitioning back to full time easier. I still have a few articles in the works (like setting up a T60 Thinkpad with Linux Mint and using FreeBSD for the first time on an EOL Chromebook) but those will come in time.

I guess I should get back to being a proper dad (I'm writing this on my phone as she sleeps on me and the boys are napping) but I'll be back here posting stupid things in no time.

See you on the other side!

Setting Up Fathom Analytics with Netlify

2021-01-19T10:00:00Z

Setting Up Fathom Analytics with Netlify

2021-01-19

It's no secret that I'm passionate about open source software, but I'm also extremely adamant about protecting the privacy of all users across the web. So when I decided to implement analytics on my own personal website, I ended up choosing Fathom (get a $10 credit using that link!).

You should research further into the company yourself if you're interested, but in a nutshell the Fathom platform provides:

GDPR, ePrivacy, PECR and CCPA compliance
ad-blocker bypasses (in a good way -> zero impact on users)
anonymous visitor stats
software created by indie developers

Although this might sound like a "paid" blog post, I can assure you this is completely based on my own opinions and experience with the service. I'm just very pleased with the product :)

Enough chit-chat - let's breakdown how to setup Fathom on your own site hosted through Netlify!

Step 0: Assumptions

I'm going into this tutorial with the assumption that you:

Have an active Fathom account (or are at least trying the 7-day free trial)
Have a website already setup on Netlify (custom domain optional)

And that's all you need.

Step 1: Adding a Custom Domain (DNS Setup)

Even though you have the option to use the default tracking script URL, I would highly recommend setting it up through your own domain. This helps avoid any browser extensions or firewalls that might block outside URL request made by individual sites.

Navigate to the Fathom Settings page in the bottom footer (must be logged in)
Select Domains from the sidebar
Enter your custom domain in the Add a new custom domain input
Select Start Process
Keep note of both the CNAME and VALUE (we will copy this in a moment)

Open a new tab, and login to your Netlify account:

From your Team Overview page, navigate to the top-level Domains page
Select the domain you plan to add Fathom to
Under DNS settings > DNS records select Add New Record
Select CNAME from the dropdown of available options
Paste the Fathom CNAME (from the steps above) into the Name input
Paste the Fathom VALUE (from the steps above) into the Value input
Click Save

That's it for DNS setup!

Step 2: Adding Fathom Your Website

Now that we will be using our own custom domain for the script, it's time to actually add it to our website. From the same Fathom Settings page as before:

Navigate to the Sites page in the sidebar
Enter your custom domain in the Add a new site input and click Get site code
In the modal prompt, select your custom domain from the dropdown list (you'll see the script code change accordingly)
Copy the tracking code snippet and add it to all the pages you plan to track on your site
When ready, select Verify site code
If everything went correctly you should be done!

Step 3: Watch Those Live Stats!

Open a cold beer (or a bubbly soda if you prefer) and watch your website visitor stats come rolling in on the dashboard! Not only do you now have solid analytics on your website but you have the piece of mind that your users' privacy isn't being invaded. Everybody wins!

Faking 3D Elements with CSS

2020-04-29T10:00:00Z

Faking 3D Elements with CSS

2020-04-29

Although not always practical, creating the illusion that some of your web elements are 3D can be a fun experiment. I set out to see if I was able to create such an illusion with only 2 HTML elements and as little CSS as possible.

This is what I ended up creating:

Live CodePen Example

The HTML

Prepare for your mind to be blown:

<div class="main-orb">
+    <div class="inner-orb"></div>
+</div>
+

That's it - I wasn't kidding when I said we would use only 2 HTML elements. The .main-orb is the core shape (set to 400x400) and the .inner-orb is placed on top of it's parent at a slightly smaller size (360x360) - but more on that below in the CSS portion.

The CSS

First we give the bigger orb element (.main-orb) the default styling needed to represent a 2D circle:

.main-orb {
+    background: linear-gradient(#fff 0%, #eee 10%, #2E86FB 50%, #1A237E 100%);
+    border-radius: 9999px;
+    height: 400px;
+    margin: 4rem auto;
+    position: relative; /* This is important for the inner orb element later */
+    width: 400px;
+}
+

Next, we include both :before and :after pseudo elements for our orb's drop shadow. You could do this with a simple box-shadow property on the .main-orb itself, but I've explained in a previous post why that's not the best approach.

/* Shared styling for both pseudo elements - Remember DRY */
+.main-orb:before, .main-orb:after {
+    border-radius: 200px 200px 9999px 9999px;
+    bottom: -10px;
+    content:'';
+    filter: blur(20px);
+    height: 40px;
+    position: absolute;
+    z-index: -1;
+}
+

/* Bigger, lighter shadow */
+.main-orb:before {
+    background: rgba(0,0,0,0.4);
+    left: 7.5%;
+    width: 85%;
+}
+

/* Smaller, darker shadow */
+.main-orb:after {
+    background: rgba(0,0,0,0.7);
+    left: 20%;
+    width: 60%;
+}
+

With our main orb complete we can move on to the .inner-orb element to help bring slightly more depth to our floating ball of CSS:

.inner-orb {
+    background: linear-gradient(#fff 0%, #2E86FB 60%, #283593 100%);
+    border-radius: 9999px;
+    box-shadow: 0 8px 20px rgba(0,0,0,0.5);
+    height: 360px;
+    filter: blur(18px);
+    left: 20px;
+    position: absolute;
+    top: 15px;
+    width: 360px;
+}
+

Poor-man's 3D elements

Clearly implementing something like this will never come close to generating true 3D renders on a website, but it is a fun exercise to see how much further we can push simple CSS. Feel free to fork the above CodePen to play around with different colors and shadow placements.

ET-Jekyll Theme

2018-01-14T10:00:00Z

ET-Jekyll Theme

2018-01-14

ET-Jekyll theme is based off of Dave Liepmann's awesome Tufte CSS - which takes it's style and inspiration from the wonderful book and handout designs of Edward Tufte.

The differences are subtle when comparing my variation to Tufte CSS, but these changes were made out of personal preference and are not in any way "better". If you prefer the original CSS styling - please use it!

This theme is an open source side project by Bradley Taunt - made with passion and care. Edit, improve, customize or butcher this theme as much as you'd like. If you spot an issue or find a better solution for any user pain-spots, please don't hesitate to open a PR with your changes.

Enjoy ET-Jekyll!

Styling Empty Table Cells

2019-07-17T10:00:00Z

Styling Empty Table Cells

2019-07-17

Often when designing tables on the web you're bound to come across empty pockets of data. These will be rendered as "blank" table cells, which isn't always the intended outcome. Let's take a quick look at how to target and style empty table cells.

The easy `:empty` way

The most popular way to target any empty element is by using - you guessed it - the empty pseudo-class. This pseudo-class is incredibly simple. You target an element's empty state that same way you would target hover or active:

table tr td:empty {
+    opacity: 0;
+}
+

Check out the CodePen examples below for more advanced styling options:

Live CodePen Example 1

You can also include additional pseudo elements to give the user more context about what the empty cells represent:

Live CodePen Example 2

More specific `empty-cells` property

Although using the :empty pseudo-class can be helpful, it isn't used just for tables. It can be used for any HTML elements that have a lack of content. So, is there a CSS specific property that can target just table cells?

Let's take a look at the empty-cells property:

table {
+    empty-cells: hide;
+}
+

Live CodePen Example 3

Pros of using empty-cells:

Only one CSS property
Targets the table elements specifically
No need for custom styles since it simply hides empty cell borders

Some downsides to using this property:

No styling customization
Trickier to use pseudo-element helpers without invoking the :empty state

Pick your preference

It doesn't matter semantically which option you decide to take when styling / hiding empty table cells. Using the :empty state gives you a lot more flexibility in terms of what you can target (full rows, columns etc), but using the empty-cells property let's you simply hide the cells and focus on more important items.

Setting Up a Pi-hole Server with Eero

2022-03-14T10:00:00Z

Setting Up a Pi-hole Server with Eero

2022-03-14

For the past few years, I've been using a set of Eero routers as my home mesh network. It's worked fairly great in that time and even seamlessly transitioned without any hiccups when my family moved house. During the initial setup, I installed Pi-hole on a Raspberry Pi Zero WH because advertisements and tracking scripts suck.

It was an easy process to get everything up and running, but I did notice a lack of detailed steps online for those specifically using Eero systems. So, I thought I would document this process here with the hope that it will help someone else along the way (or at the very least remain a semi-permanent place for my own reference).

FYI: You can pay for Eero Secure and allow them to handle ad/tracker blocking for you. Personally, I prefer to have complete control over my blocklists and usage data. YMMV.

Setting Up the Pi-hole Server

Before we get into the step-by-step details, here are the required items you'll need:

Raspberry Pi device (I recommend the Pi Zero for simplicity and low cost)
microSD card preloaded with Raspberry Pi OS Lite (having a desktop GUI is overkill for our use case)
micro USB to ethernet adapter (check your local Amazon)
Patience!

Before you place your microSD card into the Pi and boot it up, connect it to your local computer (via USB adapter) - we will need to add some files first. Once loaded into the boot folder, add an empty file simply called ssh (no extensions). Next open your preferred text editor and enter the following code, editing the content to match your own country code and home network settings:

country=US
+ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
+update_config=1
+
+network={
+    ssid="WIFI_SSID"
+    scan_ssid=1
+    psk="WIFI_PASSWORD"
+    key_mgmt=WPA-PSK
+}
+

Save this file as wpa_supplicant.conf and add it to the boot directory as well.

You can now safely eject the microSD card and place it into your Raspberry Pi.

Plug it in and Boot!

Connect power to your Pi and give it a bit of time to boot up. Once you see a nice solid green LED, go back to your local computer's terminal and enter the following command:

ssh pi@raspberrypi.local
+

If everything was set up properly you will be asked to trust this device. Next, you will be prompted to enter the device password. The default password will be: raspberry

Important: This is assuming you don't currently have any other Pi devices using this hostname parameter!

Once you are connected directly to the Pi, it's best to check for updates:

sudo apt update
+

...and if updates are in fact available, install them via:

sudo apt upgrade
+

This next step is optional but I highly recommend it for security purposes. You should change both the hostname and password of this soon-to-be Pi-hole server. To do this simply run:

sudo raspi-config
+

Edit Hostname: navigate to System Settings --> Hostname
Edit Password: navigate to System Settings --> Password

Once complete, reboot the Pi. Just remember that when you try to reconnect to this device via SSH you'll need to use both of these new parameters instead of the defaults.

Installing Pi-hole

This is the easy part:

curl -sSL https://install.pi-hole.net | bash
+

Pi-hole runs a full install script that walks you through step-by-step on setting things up. It's best to use the suggested defaults during the install - everything is pretty simple.

Near the end of the setup you'll be show the newly created static IP for this Pi-hole server (both IPv4 and IPv6). Write these down for easy reference in a moment.

Once it's finished, shutdown the Pi safely by running:

sudo shutdown now
+

Hardware Setup

With the Pi shutdown you can safely relocate it to where you have your modem and gateway Eero setup. Connect your new Pi-hole device to the secondary ethernet port on your gateway Eero[^1] and power it up. (This is where the microUSB to ethernet adapter for our Pi device is needed)

See the crude diagram below for visual reference:

+ +

Internet modem --> Eero gateway --> Pi-hole device

Grey Wire: Incoming internet connection from ISP
Blue Wire: Ethernet cord connecting modem to gateway Eero
Red Wire: Ethernet cord connecting secondary Eero port to Pi Zero

That's all we need to do on the hardware side of things.

Configuring the Eero App

With everything connected properly it's finally time to setup our custom DNS settings through Eero.

Open the Eero app (iOS or Android)
Navigate to Settings > Network Settings > DNS
Select Customized DNS and enter both your saved IPv4 / IPv6 values
Eero will prompt you to reboot your network - do it

Next we need to add your Pi-hole's address as an IPv4 reservation:[^2]

In the Eero app, navigate to Settings > Network Settings > Reservations & port forwarding
Tap Add a reservation and include your Pi-hole's IP address

After the system reboots everything should be working as intended! You can check by navigating to your Pi-hole IP address in your browser.

Closing Thoughts

None of this stuff if groundbreaking, but my hope is that even one person across the internet finds this helpful! If you run into any major bugs, please leave a comment below and I'll do my best to help out!

Best of luck blocking those pesky ads and trackers!

Refs

You don't have to use your Eero gateway for this step (credit: /u/RollMeAway83)
Thanks to u/YankeesIT for pointing out that this is required not optional

Easy Toggle Switches

2019-02-18T10:00:00Z

Easy Toggle Switches

2019-02-18

Sometimes there is a need to use toggle elements in-place of the default checkbox inputs. The problem is, I tend to see a lot of developers reaching for plugins or JavaScript components in order to implement these toggles.

This is overkill. You can create your own custom input elements to mimic toggles perfectly with just a small amount of CSS.

What we will be building

Live CodePen Example

The HTML

The build structure for these toggles is really simple, we only need:

a parent container to hold all our corresponding elements
a checkbox input element (which we will hide)
an empty label designed to represent the slider
a text label that references the input

/* Main toggle parent container */
+<div class="toggle-switch">
+    /* Checkbox input, hidden with CSS */
+    <input class="toggle-input" type="checkbox" id="toggle-1">
+    /* The toggle slider element */
+    <label class="toggle-slider" for="toggle-1"></label>
+    /* The text label to the right of the slider */
+    <label class="toggle-label" for="toggle-1">Toggle Switch</label>
+</div>
+

And that's everything we need for the HTML.

ProTip: Don't forget to increment both the id and for attributes when adding additional toggles. This seems like a no-brainer but it's overlooked more than you think.

The CSS

To get things started we will add the styling to the .toggle-switch item directly (using flexbox in this demo for easier layout).

Sidenote: You will notice the inclusion of CSS variables in this demo - if you are unfamiliar with how to use root variables in CSS, take a look at one of my previous posts: CSS variables.

:root {
+    --primary-color: #4A90E2;
+}
+
+.toggle-switch {
+    align-items: center;
+    display: flex;
+    font-size: 14px;
+    justify-content: center;
+    margin: 20px 0;
+}
+

Next we will hide the default browser checkbox element since we won't be needing it:

.toggle-input {
+    position: absolute;
+    visibility: hidden;
+    z-index: -1;
+}
+

Let's also add some base styling for the label containing the text corresponding to it's input sibling:

.toggle-label {
+    color: #ccc;
+    cursor: pointer;
+    font-weight: bold;
+    padding-left: 10px;
+    text-shadow: 1px 1px 0 rgba(255,255,255,0.3);
+    transition: ease all .3s;
+}
+

Now we target the .toggle-slider label and add the styling for the main slider base:

/* This is just the main slider base */
+.toggle-slider {
+    background: #eee;
+    border-radius: 9999px;
+    box-shadow: inset 0 2px 4px rgba(0,0,0,0.1), 
+                inset 0 4px 8px rgba(0,0,0,0.1), 
+                0 1px 1px rgba(255,255,255,1);
+    cursor: pointer;
+    display: inline-block;
+    height: 20px;
+    position: relative;
+    transition: all ease .3s;
+    width: 40px;
+}
+

We could include a separate element for the circle toggle switcher itself, but instead we will use the :before pseudo element:

.toggle-slider:before {
+    background: white;
+    border-radius: 9999px;
+    box-shadow: 0 4px 8px rgba(0,0,0,0.1), 
+                0 2px 4px rgba(0,0,0,0.2);
+    content:'';
+    height: 16px;
+    left: 2px;
+    position: absolute;
+    top: 2px;
+    transition: all ease .3s;
+    width: 16px;
+}
+

Interaction

Right now we just have a static toggle that does nothing when the user interacts with it. Let's change that by moving the pseudo element's position based on the checkbox input state and updating the label text color:

.toggle-input:checked + .toggle-slider {
+    background: var(--primary-color);
+}
+.toggle-input:checked + .toggle-slider:before {
+    /* Move 100% of the width minus it's own width plus initial 'left' */
+    left: calc(100% - 18px);
+}
+
+.toggle-input:checked ~ .toggle-label {
+    color: var(--primary-color);
+}
+

And because we already included the transition property on both the base slider and label text, everything animates nicely between state changes.

Final code

To make things easier, you can find the HTML & CSS is their entirety below:

HTML

<div class="toggle-switch">
+    <input class="toggle-input" type="checkbox" id="toggle-1">
+    <label class="toggle-slider" for="toggle-1"></label>
+    <label class="toggle-label" for="toggle-1">Toggle Switch</label>
+</div>
+<div class="toggle-switch">
+    <input class="toggle-input" type="checkbox" id="toggle-2">
+    <label class="toggle-slider" for="toggle-2"></label>
+    <label class="toggle-label" for="toggle-2">Toggle Switch</label>
+</div>
+<div class="toggle-switch">
+    <input class="toggle-input" type="checkbox" id="toggle-3" checked>
+    <label class="toggle-slider" for="toggle-3"></label>
+    <label class="toggle-label" for="toggle-3">Toggle Switch</label>
+</div>
+<div class="toggle-switch">
+    <input class="toggle-input" type="checkbox" id="toggle-4">
+    <label class="toggle-slider" for="toggle-4"></label>
+    <label class="toggle-label" for="toggle-4">Toggle Switch</label>
+</div>
+

The CSS

:root {
+    --primary-color: #4A90E2;
+}
+.toggle-switch {
+    align-items: center;
+    display: flex;
+    font-size: 14px;
+    justify-content: center;
+    margin: 20px 0;
+}
+.toggle-input {
+    position: absolute;
+    visibility: hidden;
+    z-index: -1;
+}
+.toggle-slider {
+    background: #eee;
+    border-radius: 9999px;
+    box-shadow: inset 0 2px 4px rgba(0,0,0,0.1), 
+                inset 0 4px 8px rgba(0,0,0,0.1), 
+                0 1px 1px rgba(255,255,255,1);
+    cursor: pointer;
+    display: inline-block;
+    height: 20px;
+    position: relative;
+    transition: all ease .3s;
+    width: 40px;
+}
+.toggle-slider:before {
+    background: white;
+    border-radius: 9999px;
+    box-shadow: 0 4px 8px rgba(0,0,0,0.1), 
+                0 2px 4px rgba(0,0,0,0.2);
+    content:'';
+    height: 16px;
+    left: 2px;
+    position: absolute;
+    top: 2px;
+    transition: all ease .3s;
+    width: 16px;
+}
+.toggle-input:checked + .toggle-slider {
+    background: var(--primary-color);
+}
+.toggle-input:checked + .toggle-slider:before {
+    left: calc(100% - 18px);
+}
+.toggle-label {
+    color: #ccc;
+    cursor: pointer;
+    font-weight: bold;
+    padding-left: 10px;
+    text-shadow: 1px 1px 0 rgba(255,255,255,0.3);
+    transition: ease all .3s;
+}
+.toggle-input:checked ~ .toggle-label {
+    color: var(--primary-color);
+}
+

Enjoy your custom toggles!

Easy Custom Radio Inputs

2019-01-21T10:00:00Z

Easy Custom Radio Inputs

2019-01-21

Default radio inputs are notoriously horrible looking and are something designers tend to over-think when trying to customize them. Let's walk through how to create custom radio buttons with pure CSS, while still preserving performance and accessibility.

The Final Product

This is what we will be designing:

Live CodePen Example

The bones of our radio inputs (HTML)

<input class="radio-btn" name="radio-collection" id="radio-1" type="radio">
+<label class="radio-label" for="radio-1"><span>I am very satisfied</span></label>
+
+<input class="radio-btn" name="radio-collection" id="radio-2" type="radio">
+<label class="radio-label" for="radio-2"><span>I am satisfied</span></label>
+
+<input class="radio-btn" name="radio-collection" id="radio-3" type="radio">
+<label class="radio-label" for="radio-3"><span>I am indifferent</span></label>
+
+<input class="radio-btn" name="radio-collection" id="radio-4" type="radio">
+<label class="radio-label" for="radio-4"><span>I am unsatisfied</span></label>
+
+<input class="radio-btn" name="radio-collection" id="radio-5" type="radio">
+<label class="radio-label" for="radio-5"><span>I am very unsatisfied</span></label>
+

I know it looks like a lot is going on here, but it's pretty straightforward so let's unpackage line by line:

Radio inputs

<input class="radio-btn" name="radio-collection" id="radio-1" type="radio">
+

This is the default radio input. We give it:

a name (inputs with a shared name are grouped together)
an id (so our label can target this input)
a class (so we can style it later)

Important: be sure to have a unique id for each input so your labels don't end up connected to multiple radios. In this demo we are simply incrementing them by one.

Labels

Adding the labels is fairly straightforward, we just include the corresponding input's id in the label's for attribute. The label content is wrapped in a span - which I will explain the reasoning for later.

For styling purposes we also add the radio-label class.

<label class="radio-label" for="radio-1"><span>I am very satisfied</span></label>
+

This is looking pretty terrible - but that's nothing some good ol' CSS can't fix!

The flesh of our radio inputs (CSS)

First we give some basic styling to our label and input classes (along with hover states). The radio element is actually hidden from view, but by using the visibility attribute we still keep it accessible for screen-readers.

.radio-label {
+    background: white;
+    border: 1px solid #eee;
+    border-radius: 5px;
+    box-shadow: 0 2px 4px rgba(0,0,0,0.05);
+    cursor: pointer;
+    display: inline-block;
+    font-weight: 600;
+    margin: 0 auto 10px;
+    /* This 65px padding makes room for the custom input */
+    padding: 20px 20px 20px 65px;
+    position: relative;
+    transition: .3s ease all;
+    width: 100%;
+}
+.radio-label:hover {
+    box-shadow: 0 4px 8px rgba(0,0,0,0.05);
+}
+.radio-btn {
+    position: absolute;
+    visibility: hidden;
+}
+

Remember that span element inside the label? We set it's user-select property to none so we avoid any possible issue with the user selecting the text on-click:

.radio-label span {
+    -webkit-user-select: none;
+    -moz-user-select: none;
+    user-select: none;
+}
+

Next we include the default empty selection element (to mimic the original radio input) via a pseudo element:

.radio-label:before {
+    background: #eee;
+    border-radius: 50%;
+    content:'';
+    height: 30px;
+    left: 20px;
+    position: absolute;
+    /* Half the height of it's parent minus half of it's own height */
+    top: calc(50% - 15px);
+    transition: .3s ease background-color;
+    width: 30px;
+}
+

A Few Final Steps

The final step is adding the custom styling for when an input item is selected (:checked).

You will notice the use of a base64 element for the custom checkmark - feel free to subsitute this for an actual image or none at all (this is just my personal design preference).

.radio-btn:checked + .radio-label {
+    background: #ECF5FF;
+    border-color: #4A90E2;
+}
+.radio-btn:checked + .radio-label:before {
+    background-color: #4A90E2;
+    background-image:  url('data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c3ZnIHdpZHRoPSIyNiIgaGVpZ2h0PSIyMCIgdmVyc2lvbj0iMS4xIiB2aWV3Qm94PSIyLjAyOTY4IC00MC4wOTAzIDI2IDIwIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIj48IS0tR2VuZXJhdGVkIGJ5IElKU1ZHIChodHRwczovL2dpdGh1Yi5jb20vaWNvbmphci9JSlNWRyktLT48cGF0aCBkPSJNMjcuOTc0MywtMzYuMTI3MmMwLDAuNDQ2NDI4IC0wLjE1NjI1LDAuODI1ODkzIC0wLjQ2ODc1LDEuMTM4MzlsLTEyLjEyMDUsMTIuMTIwNWwtMi4yNzY3OSwyLjI3Njc5Yy0wLjMxMjUsMC4zMTI1IC0wLjY5MTk2NCwwLjQ2ODc1IC0xLjEzODM5LDAuNDY4NzVjLTAuNDQ2NDI4LDAgLTAuODI1ODkzLC0wLjE1NjI1IC0xLjEzODM5LC0wLjQ2ODc1bC0yLjI3Njc5LC0yLjI3Njc5bC02LjA2MDI3LC02LjA2MDI3Yy0wLjMxMjUsLTAuMzEyNSAtMC40Njg3NSwtMC42OTE5NjUgLTAuNDY4NzUsLTEuMTM4MzljMCwtMC40NDY0MjkgMC4xNTYyNSwtMC44MjU4OTMgMC40Njg3NSwtMS4xMzgzOWwyLjI3Njc5LC0yLjI3Njc5YzAuMzEyNSwtMC4zMTI1IDAuNjkxOTY1LC0wLjQ2ODc1IDEuMTM4MzksLTAuNDY4NzVjMC40NDY0MjksMCAwLjgyNTg5MywwLjE1NjI1IDEuMTM4MzksMC40Njg3NWw0LjkyMTg4LDQuOTM4NjJsMTAuOTgyMSwtMTAuOTk4OWMwLjMxMjUsLTAuMzEyNSAwLjY5MTk2NCwtMC40Njg3NSAxLjEzODM5LC0wLjQ2ODc1YzAuNDQ2NDI4LDAgMC44MjU4OTMsMC4xNTYyNSAxLjEzODM5LDAuNDY4NzVsMi4yNzY3OCwyLjI3Njc5YzAuMzEyNSwwLjMxMjUgMC40Njg3NSwwLjY5MTk2NCAwLjQ2ODc1LDEuMTM4MzlaIiB0cmFuc2Zvcm09InNjYWxlKDEuMDAxOTgpIiBmaWxsPSIjZmZmIj48L3BhdGg+PC9zdmc+');
+    background-repeat: no-repeat;
+    background-position: center;
+    background-size: 15px;
+}
+

And that's it.

For easier reference the entire CSS file can be found below:

.radio-label {
+    background: white;
+    border: 1px solid #eee;
+    border-radius: 5px;
+    box-shadow: 0 2px 4px rgba(0,0,0,0.05);
+    cursor: pointer;
+    display: inline-block;
+    font-weight: 600;
+    margin: 0 auto 10px;
+    padding: 20px 20px 20px 65px;
+    position: relative;
+    transition: .3s ease all;
+    width: 100%;
+}
+.radio-label:hover {
+    box-shadow: 0 4px 8px rgba(0,0,0,0.05);
+}
+.radio-label:before {
+    background: #eee;
+    border-radius: 50%;
+    content:'';
+    height: 30px;
+    left: 20px;
+    position: absolute;
+    top: calc(50% - 15px);
+    transition: .3s ease background-color;
+    width: 30px;
+}
+.radio-label span {
+    -webkit-user-select: none;
+    -moz-user-select: none;
+    user-select: none;
+}
+.radio-btn {
+    position: absolute;
+    visibility: hidden;
+}
+.radio-btn:checked + .radio-label {
+    background: #ECF5FF;
+    border-color: #4A90E2;
+}
+.radio-btn:checked + .radio-label:before {
+    background-color: #4A90E2;
+    background-image:  url('data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c3ZnIHdpZHRoPSIyNiIgaGVpZ2h0PSIyMCIgdmVyc2lvbj0iMS4xIiB2aWV3Qm94PSIyLjAyOTY4IC00MC4wOTAzIDI2IDIwIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIj48IS0tR2VuZXJhdGVkIGJ5IElKU1ZHIChodHRwczovL2dpdGh1Yi5jb20vaWNvbmphci9JSlNWRyktLT48cGF0aCBkPSJNMjcuOTc0MywtMzYuMTI3MmMwLDAuNDQ2NDI4IC0wLjE1NjI1LDAuODI1ODkzIC0wLjQ2ODc1LDEuMTM4MzlsLTEyLjEyMDUsMTIuMTIwNWwtMi4yNzY3OSwyLjI3Njc5Yy0wLjMxMjUsMC4zMTI1IC0wLjY5MTk2NCwwLjQ2ODc1IC0xLjEzODM5LDAuNDY4NzVjLTAuNDQ2NDI4LDAgLTAuODI1ODkzLC0wLjE1NjI1IC0xLjEzODM5LC0wLjQ2ODc1bC0yLjI3Njc5LC0yLjI3Njc5bC02LjA2MDI3LC02LjA2MDI3Yy0wLjMxMjUsLTAuMzEyNSAtMC40Njg3NSwtMC42OTE5NjUgLTAuNDY4NzUsLTEuMTM4MzljMCwtMC40NDY0MjkgMC4xNTYyNSwtMC44MjU4OTMgMC40Njg3NSwtMS4xMzgzOWwyLjI3Njc5LC0yLjI3Njc5YzAuMzEyNSwtMC4zMTI1IDAuNjkxOTY1LC0wLjQ2ODc1IDEuMTM4MzksLTAuNDY4NzVjMC40NDY0MjksMCAwLjgyNTg5MywwLjE1NjI1IDEuMTM4MzksMC40Njg3NWw0LjkyMTg4LDQuOTM4NjJsMTAuOTgyMSwtMTAuOTk4OWMwLjMxMjUsLTAuMzEyNSAwLjY5MTk2NCwtMC40Njg3NSAxLjEzODM5LC0wLjQ2ODc1YzAuNDQ2NDI4LDAgMC44MjU4OTMsMC4xNTYyNSAxLjEzODM5LDAuNDY4NzVsMi4yNzY3OCwyLjI3Njc5YzAuMzEyNSwwLjMxMjUgMC40Njg3NSwwLjY5MTk2NCAwLjQ2ODc1LDEuMTM4MzlaIiB0cmFuc2Zvcm09InNjYWxlKDEuMDAxOTgpIiBmaWxsPSIjZmZmIj48L3BhdGg+PC9zdmc+');
+    background-repeat: no-repeat;
+    background-position: center;
+    background-size: 15px;
+}
+

But wait - we can get even fancier!

Since this demo is based off a survey-type questionaire, wouldn't it be interesting to give the different selectable options their own styling based on their context? Take a look at the further customized version below:

We can do so by adding positive, neutral and negative class names to the radio inputs with their own respective properties:

.radio-btn.positive:checked + .radio-label {
+    background: #EAFFF6;
+    border-color: #32B67A;
+}
+.radio-btn.positive:checked + .radio-label:before {
+    background-color: #32B67A;
+}
+.radio-btn.neutral:checked + .radio-label:before {
+    background-image: url('data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c3ZnIHZlcnNpb249IjEuMSIgdmlld0JveD0iMCAtMTUgMzAgOC41NzE0MyIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayI+PCEtLUdlbmVyYXRlZCBieSBJSlNWRyAoaHR0cHM6Ly9naXRodWIuY29tL2ljb25qYXIvSUpTVkcpLS0+PHBhdGggZD0iTTMwLC0xMi4zMjE0djMuMjE0MjljMCwwLjczNjYwNyAtMC4yNjIyNzcsMS4zNjcxOSAtMC43ODY4MywxLjg5MTc0Yy0wLjUyNDU1NCwwLjUyNDU1NCAtMS4xNTUxMywwLjc4NjgzMSAtMS44OTE3NCwwLjc4NjgzMWgtMjQuNjQyOWMtMC43MzY2MDcsMCAtMS4zNjcxOSwtMC4yNjIyNzcgLTEuODkxNzQsLTAuNzg2ODMxYy0wLjUyNDU1MywtMC41MjQ1NTMgLTAuNzg2ODMsLTEuMTU1MTMgLTAuNzg2ODMsLTEuODkxNzR2LTMuMjE0MjljMCwtMC43MzY2MDcgMC4yNjIyNzcsLTEuMzY3MTkgMC43ODY4MywtMS44OTE3NGMwLjUyNDU1NCwtMC41MjQ1NTMgMS4xNTUxMywtMC43ODY4MyAxLjg5MTc0LC0wLjc4NjgzaDI0LjY0MjljMC43MzY2MDcsMCAxLjM2NzE5LDAuMjYyMjc3IDEuODkxNzQsMC43ODY4M2MwLjUyNDU1MywwLjUyNDU1NCAwLjc4NjgzLDEuMTU1MTMgMC43ODY4MywxLjg5MTc0WiIgZmlsbD0iI2ZmZiI+PC9wYXRoPjwvc3ZnPg==');
+}
+.radio-btn.negative:checked + .radio-label {
+    background: #FFF2F2;
+    border-color: #E75153;
+}
+.radio-btn.negative:checked + .radio-label:before {
+    background-color: #E75153;
+    background-image: url('data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c3ZnIHdpZHRoPSIyMCIgaGVpZ2h0PSIyMCIgdmVyc2lvbj0iMS4xIiB2aWV3Qm94PSIxLjg1MTg1IC0zOS42OTcgMjAgMjAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiPjwhLS1HZW5lcmF0ZWQgYnkgSUpTVkcgKGh0dHBzOi8vZ2l0aHViLmNvbS9pY29uamFyL0lKU1ZHKS0tPjxwYXRoIGQ9Ik0yMS43Mjk5LC0yMy40NzFjMCwwLjQ0NjQyOCAtMC4xNTYyNSwwLjgyNTg5MyAtMC40Njg3NSwxLjEzODM5bC0yLjI3Njc5LDIuMjc2NzljLTAuMzEyNSwwLjMxMjUgLTAuNjkxOTY0LDAuNDY4NzUgLTEuMTM4MzksMC40Njg3NWMtMC40NDY0MjgsMCAtMC44MjU4OTMsLTAuMTU2MjUgLTEuMTM4MzksLTAuNDY4NzVsLTQuOTIxODcsLTQuOTIxODhsLTQuOTIxODgsNC45MjE4OGMtMC4zMTI1LDAuMzEyNSAtMC42OTE5NjQsMC40Njg3NSAtMS4xMzgzOSwwLjQ2ODc1Yy0wLjQ0NjQyOCwwIC0wLjgyNTg5MiwtMC4xNTYyNSAtMS4xMzgzOSwtMC40Njg3NWwtMi4yNzY3OSwtMi4yNzY3OWMtMC4zMTI1LC0wLjMxMjUgLTAuNDY4NzUsLTAuNjkxOTY1IC0wLjQ2ODc1LC0xLjEzODM5YzAsLTAuNDQ2NDI5IDAuMTU2MjUsLTAuODI1ODkzIDAuNDY4NzUsLTEuMTM4MzlsNC45MjE4OCwtNC45MjE4OGwtNC45MjE4OCwtNC45MjE4OGMtMC4zMTI1LC0wLjMxMjUgLTAuNDY4NzUsLTAuNjkxOTY0IC0wLjQ2ODc1LC0xLjEzODM5YzAsLTAuNDQ2NDI4IDAuMTU2MjUsLTAuODI1ODkzIDAuNDY4NzUsLTEuMTM4MzlsMi4yNzY3OSwtMi4yNzY3OGMwLjMxMjUsLTAuMzEyNSAwLjY5MTk2NCwtMC40Njg3NSAxLjEzODM5LC0wLjQ2ODc1YzAuNDQ2NDI5LDAgMC44MjU4OTMsMC4xNTYyNSAxLjEzODM5LDAuNDY4NzVsNC45MjE4OCw0LjkyMTg4bDQuOTIxODcsLTQuOTIxODhjMC4zMTI1LC0wLjMxMjUgMC42OTE5NjUsLTAuNDY4NzUgMS4xMzgzOSwtMC40Njg3NWMwLjQ0NjQyOSwwIDAuODI1ODkzLDAuMTU2MjUgMS4xMzgzOSwwLjQ2ODc1bDIuMjc2NzksMi4yNzY3OGMwLjMxMjUsMC4zMTI1IDAuNDY4NzUsMC42OTE5NjUgMC40Njg3NSwxLjEzODM5YzAsMC40NDY0MjkgLTAuMTU2MjUsMC44MjU4OTMgLTAuNDY4NzUsMS4xMzgzOWwtNC45MjE4OCw0LjkyMTg4bDQuOTIxODgsNC45MjE4OGMwLjMxMjUsMC4zMTI1IDAuNDY4NzUsMC42OTE5NjQgMC40Njg3NSwxLjEzODM5WiIgdHJhbnNmb3JtPSJzY2FsZSgxLjAwNTYxKSIgZmlsbD0iI2ZmZiI+PC9wYXRoPjwvc3ZnPg==');
+}
+

I hope this shows new designers that simple custom radio inputs aren't so hard to implement after-all and can actually be pretty fun to design.

Dynamic Checkboxes

2019-07-30T10:00:00Z

Dynamic Checkboxes

2019-07-30

Checkboxes are used quite frequently on forms across the web. Whether you're selecting a pricing plan during a site's sign-up process or just simply selecting to opt-out from a newsletter, you have most likely interacted with some form of checkbox element.

What if we could make everyday checkboxes more beautiful and more intuitive? It's easier than you think. We only need a small amount of CSS and JavaScript to make considerable improvements to your average checkbox UX.

Let's get into it.

What we are building

Take a look and play around with the CodePen below to get an idea of what we are going to build. The premise is a simple add-on pricing form which calculates the additional monthly total to the user in real-time.

Live CodePen Example

The Structure (HTML)

As always, we will start by breaking down the "bones" of the HTML structure for this checkbox form. Let's take a look at the HTML in it's entirety (don't worry, it is a lot more simple than it seems at first glance):

<h2>Add-ons</h2>
+
+<input class="checkbox-btn" name="checkbox-collection" id="checkbox-1" type="checkbox" value="49">
+<label class="checkbox-label" for="checkbox-1">
+    <span>
+        White-labeled Domain
+        <em>Use your own custom domain with SSL security included.</em>
+    </span>
+    <span>$49/mo</span>
+</label>
+
+<input class="checkbox-btn" name="checkbox-collection" id="checkbox-2" type="checkbox" value="49">
+<label class="checkbox-label" for="checkbox-2">
+    <span>
+        API Access
+        <em>Make API calls to perform custom serving and account actions.</em>
+    </span>
+    <span>$49/mo</span>
+</label>
+
+<input class="checkbox-btn" name="checkbox-collection" id="checkbox-3" type="checkbox" value="349">
+<label class="checkbox-label" for="checkbox-3">
+    <span>
+        Priority Support
+        <em>A dedicated account manager to assist your team with ongoing deployments.</em>
+    </span>
+    <span>$349/mo</span>
+</label>
+
+<div class="total-cost">
+    <h2>Your Plan</h2>
+    <div>
+        <span>$</span>
+        <span id="total-cost-inner">0</span>
+        <input id="output" type="text" value="0" disabled/>
+        <span>/mo</span>
+    </div>
+</div>
+

The checkbox inputs & labels

<!-- #1 -->
+<input class="checkbox-btn" name="checkbox-collection" id="checkbox-1" type="checkbox" value="49">
+
+<!-- #2 -->
+<label class="checkbox-label" for="checkbox-1">
+
+    <!-- #2i -->
+    <span>
+        White-labeled Domain
+        <em>Use your own custom domain with SSL security included.</em>
+    </span>
+    
+    <!-- #2ii -->
+    <span>$49/mo</span>
+
+</label>
+

This input will be hidden via position:absolute by default. All checkbox inputs need to share the same name value and all checkboxes require their our custom id that will link with the corresponding for value on the label.
+
This label needs it's for value to correspond with it's partnered checkbox.

- i) The first span holds the title and description information of the add-on + - ii) The last span holds the cost associated with the current add-on

The total cost container output

<!-- #1 -->
+<div class="total-cost">
+
+    <h2>Your Plan</h2>
+
+    <!-- #2 -->
+    <div>
+
+        <!-- #2i -->
+        <span>$</span>
+
+        <!-- #2ii -->
+        <span id="total-cost-inner">0</span>
+
+        <!-- #2iii -->
+        <input id="output" type="text" value="0" disabled/>
+
+        <!-- #2iv -->
+        <span>/mo</span>
+
+    </div>
+
+</div>
+

A simple div with a class we can easily target later
+
A div parent container is needed to house all the total spans together (more on this when we get into the CSS) + - i) The first span holds the static currency symbol + - ii) The second span is where our updated cost will be injected + - iii) This input field is required for us to take-in the value of the associated :checked inputs and add them together. This current value is then used for the injection into the second span + - iv) The final span simply holds the static monthly duration content
+

All that's all we need for the HTML!

The Visuals (CSS)

Again, lets take a look at the entire file before we break it down step-by-step:

.checkbox-label {
+    align-items: center;
+    background-color: none;
+    border: 1px solid lightgrey;
+    border-radius: 5px;
+    cursor: pointer;
+    display: flex;
+    font-weight: 600;
+    justify-content: space-between;
+    margin: 0 auto 10px;
+    padding: 20px 20px 20px 70px;
+    position: relative;
+    transition: .3s ease all;
+    width: 100%;
+}
+.checkbox-label span:last-child {
+    padding: 0 0 0 20px;
+}
+.checkbox-label:hover {
+    background-color: rgba(255,255,255,0.2);
+}
+.checkbox-label:before {
+    background-repeat: no-repeat;
+    background-position: center;
+    background-size: 15px;
+    border: 1px solid lightgrey;
+    border-radius: 50%;
+    content:'';
+    height: 30px;
+    left: 20px;
+    position: absolute;
+    top: calc(50% - 15px);
+    transition: .3s ease background-color;
+    width: 30px;
+}
+.checkbox-label:hover:before {
+    background-image:
+        url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="23.571429" height="23.571429" viewBox="0.000000 -47.142857 23.571429 23.571429"><path fill="lightgrey" d="M23.571429 -36.964286L23.571429 -33.750000C23.571429 -33.303571 23.415179 -32.924107 23.102679 -32.611607C22.790179 -32.299107 22.410714 -32.142857 21.964286 -32.142857L15.000000 -32.142857L15.000000 -25.178571C15.000000 -24.732143 14.843750 -24.352679 14.531250 -24.040179C14.218750 -23.727679 13.839286 -23.571429 13.392857 -23.571429L10.178571 -23.571429C9.732143 -23.571429 9.352679 -23.727679 9.040179 -24.040179C8.727679 -24.352679 8.571429 -24.732143 8.571429 -25.178571L8.571429 -32.142857L1.607143 -32.142857C1.160714 -32.142857 0.781250 -32.299107 0.468750 -32.611607C0.156250 -32.924107 0.000000 -33.303571 0.000000 -33.750000L0.000000 -36.964286C0.000000 -37.410714 0.156250 -37.790179 0.468750 -38.102679C0.781250 -38.415179 1.160714 -38.571429 1.607143 -38.571429L8.571429 -38.571429L8.571429 -45.535714C8.571429 -45.982143 8.727679 -46.361607 9.040179 -46.674107C9.352679 -46.986607 9.732143 -47.142857 10.178571 -47.142857L13.392857 -47.142857C13.839286 -47.142857 14.218750 -46.986607 14.531250 -46.674107C14.843750 -46.361607 15.000000 -45.982143 15.000000 -45.535714L15.000000 -38.571429L21.964286 -38.571429C22.410714 -38.571429 22.790179 -38.415179 23.102679 -38.102679C23.415179 -37.790179 23.571429 -37.410714 23.571429 -36.964286ZM23.571429 -36.964286"></path></svg>');
+}
+.checkbox-label span {
+    -webkit-user-select: none;
+    -moz-user-select: none;
+    user-select: none;
+}
+.checkbox-label span em {
+    display: block;
+    font-size: 80%;
+    font-style: normal;
+    font-weight: 400;
+    line-height: 1.2;
+}
+.checkbox-btn {
+    position: absolute;
+    visibility: hidden;
+}
+.checkbox-btn:checked + .checkbox-label {
+    background-color: white;
+    border-color: mediumpurple;
+    box-shadow: 0 2px 4px rgba(0,0,0,0.05);
+}
+.checkbox-btn:checked + .checkbox-label:before {
+    background-color: mediumpurple;
+    background-image:
+        url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="25.948661" height="19.888393" viewBox="2.025670 -40.011161 25.948661 19.888393"><path fill="white" d="M27.974330 -36.127232C27.974330 -35.680804 27.818080 -35.301339 27.505580 -34.988839L15.385045 -22.868304L13.108259 -20.591518C12.795759 -20.279018 12.416295 -20.122768 11.969866 -20.122768C11.523438 -20.122768 11.143973 -20.279018 10.831473 -20.591518L8.554688 -22.868304L2.494420 -28.928571C2.181920 -29.241071 2.025670 -29.620536 2.025670 -30.066964C2.025670 -30.513393 2.181920 -30.892857 2.494420 -31.205357L4.771205 -33.482143C5.083705 -33.794643 5.463170 -33.950893 5.909598 -33.950893C6.356027 -33.950893 6.735491 -33.794643 7.047991 -33.482143L11.969866 -28.543527L22.952009 -39.542411C23.264509 -39.854911 23.643973 -40.011161 24.090402 -40.011161C24.536830 -40.011161 24.916295 -39.854911 25.228795 -39.542411L27.505580 -37.265625C27.818080 -36.953125 27.974330 -36.573661 27.974330 -36.127232ZM27.974330 -36.127232"></path></svg>');
+    border-color: mediumpurple;
+}
+
+.total-cost {
+    align-items: baseline;
+    border-top: 1px solid lightgrey;
+    display: flex;
+    justify-content: space-between;
+    margin-top: 40px;
+    padding: 40px 20px 0;
+}
+.total-cost div {
+    align-items: baseline;
+    display: flex;
+}
+.total-cost span:nth-child(1) {
+    align-self: flex-start;
+    padding-top: 5px;
+}
+.total-cost span:nth-child(2) {
+    font-size: 32px;
+    font-weight: bold;
+}
+.total-cost input {
+    display: none;
+}
+
+@media(max-width:480px) {
+    .checkbox-label {
+        align-items: flex-start;
+        flex-direction: column;
+        flex-wrap: wrap;
+    }
+    .checkbox-label span:last-child {
+        padding: 10px 0 0 0;
+    }
+}
+

The checkbox label

/*
+This is the main element for each checkbox "container".
+Inside it houses the title, description and price.
+*/
+.checkbox-label {
+    align-items: center;
+    background-color: none;
+    border: 1px solid lightgrey;
+    border-radius: 5px;
+    cursor: pointer;
+    display: flex;
+    font-weight: 600;
+    justify-content: space-between;
+    margin: 0 auto 10px;
+    padding: 20px 20px 20px 70px;
+    position: relative;
+    transition: .3s ease all;
+    width: 100%;
+}
+.checkbox-label:hover {
+    background-color: rgba(255,255,255,0.2);
+}
+
+/* Update the label styling when the input is :checked */
+.checkbox-btn:checked + .checkbox-label {
+    background-color: white;
+    border-color: mediumpurple;
+    box-shadow: 0 2px 4px rgba(0,0,0,0.05);
+}
+

The custom checkbox input

We need to hide the browser's default checkbox input and replace it with our own using pseudo selectors.

/* Hide browser default input */
+.checkbox-btn {
+    position: absolute;
+    visibility: hidden;
+}
+
+/* Our custom input checkbox */
+.checkbox-label:before {
+    background-repeat: no-repeat;
+    background-position: center;
+    background-size: 15px;
+    border: 1px solid lightgrey;
+    border-radius: 50%;
+    content:'';
+    height: 30px;
+    left: 20px;
+    position: absolute;
+    top: calc(50% - 15px);
+    transition: .3s ease background-color;
+    width: 30px;
+}
+
+/*
+Here we add a simple '+' icon on hover
+to our custom pseudo element.
+Adding it as an inline SVG gives us the
+ability to fully customize it's styling
+*/
+.checkbox-label:hover:before {
+    background-image:
+        url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="23.571429" height="23.571429" viewBox="0.000000 -47.142857 23.571429 23.571429"><path fill="lightgrey" d="M23.571429 -36.964286L23.571429 -33.750000C23.571429 -33.303571 23.415179 -32.924107 23.102679 -32.611607C22.790179 -32.299107 22.410714 -32.142857 21.964286 -32.142857L15.000000 -32.142857L15.000000 -25.178571C15.000000 -24.732143 14.843750 -24.352679 14.531250 -24.040179C14.218750 -23.727679 13.839286 -23.571429 13.392857 -23.571429L10.178571 -23.571429C9.732143 -23.571429 9.352679 -23.727679 9.040179 -24.040179C8.727679 -24.352679 8.571429 -24.732143 8.571429 -25.178571L8.571429 -32.142857L1.607143 -32.142857C1.160714 -32.142857 0.781250 -32.299107 0.468750 -32.611607C0.156250 -32.924107 0.000000 -33.303571 0.000000 -33.750000L0.000000 -36.964286C0.000000 -37.410714 0.156250 -37.790179 0.468750 -38.102679C0.781250 -38.415179 1.160714 -38.571429 1.607143 -38.571429L8.571429 -38.571429L8.571429 -45.535714C8.571429 -45.982143 8.727679 -46.361607 9.040179 -46.674107C9.352679 -46.986607 9.732143 -47.142857 10.178571 -47.142857L13.392857 -47.142857C13.839286 -47.142857 14.218750 -46.986607 14.531250 -46.674107C14.843750 -46.361607 15.000000 -45.982143 15.000000 -45.535714L15.000000 -38.571429L21.964286 -38.571429C22.410714 -38.571429 22.790179 -38.415179 23.102679 -38.102679C23.415179 -37.790179 23.571429 -37.410714 23.571429 -36.964286ZM23.571429 -36.964286"></path></svg>');
+}
+
+/*
+When the checkbox input is :checked we need to
+update the inline SVG to use a checkmark symbol
+*/
+.checkbox-btn:checked + .checkbox-label:before {
+    background-color: mediumpurple;
+    background-image:
+        url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="25.948661" height="19.888393" viewBox="2.025670 -40.011161 25.948661 19.888393"><path fill="white" d="M27.974330 -36.127232C27.974330 -35.680804 27.818080 -35.301339 27.505580 -34.988839L15.385045 -22.868304L13.108259 -20.591518C12.795759 -20.279018 12.416295 -20.122768 11.969866 -20.122768C11.523438 -20.122768 11.143973 -20.279018 10.831473 -20.591518L8.554688 -22.868304L2.494420 -28.928571C2.181920 -29.241071 2.025670 -29.620536 2.025670 -30.066964C2.025670 -30.513393 2.181920 -30.892857 2.494420 -31.205357L4.771205 -33.482143C5.083705 -33.794643 5.463170 -33.950893 5.909598 -33.950893C6.356027 -33.950893 6.735491 -33.794643 7.047991 -33.482143L11.969866 -28.543527L22.952009 -39.542411C23.264509 -39.854911 23.643973 -40.011161 24.090402 -40.011161C24.536830 -40.011161 24.916295 -39.854911 25.228795 -39.542411L27.505580 -37.265625C27.818080 -36.953125 27.974330 -36.573661 27.974330 -36.127232ZM27.974330 -36.127232"></path></svg>');
+    border-color: mediumpurple;
+}
+

The total cost container

We only need some very basic flexbox styling for our bottom "total" container:

.total-cost {
+    align-items: baseline;
+    border-top: 1px solid lightgrey;
+    display: flex;
+    justify-content: space-between;
+    margin-top: 40px;
+    padding: 40px 20px 0;
+}
+.total-cost div {
+    align-items: baseline;
+    display: flex;
+}
+.total-cost span:nth-child(1) {
+    align-self: flex-start;
+    padding-top: 5px;
+}
+.total-cost span:nth-child(2) {
+    font-size: 32px;
+    font-weight: bold;
+}
+
+/*
+This input is used in our JavaScript - look at the
+function part of this post to understand why
+*/
+.total-cost input {
+    display: none;
+}
+

Last but not least - mobile

Now we just ensure that on smaller devices our checkbox labels render nicely:

@media(max-width:480px) {
+    /*
+    Avoids the inner label content from squishing together
+    and becoming unreadable
+    */
+    .checkbox-label {
+        align-items: flex-start;
+        flex-direction: column;
+        flex-wrap: wrap;
+    }
+    .checkbox-label span:last-child {
+        padding: 10px 0 0 0;
+    }
+}
+

That's it for the styling!

The Function (JS)

As you can see below, we only need a very minor amount of JavaScript to accomplish our total cost "injection".

window.onload=function(){
+
+// Place the default browser checkbox inputs into a variable
+var inputs = document.getElementsByClassName('checkbox-btn')
+
+// Now we loop through the inputs and check if they are
+// greater than zero. If so, we run our function.
+for (var i=0; i < inputs.length; i++) {
+
+    inputs[i].onchange = function() {
+
+        // Create `add` variable which takes the :checked input value
+        var add = this.value * (this.checked ? 1 : -1);
+
+        // We grab the current total value on our hidden input field and return it
+        // as a floating point number
+        // (since in this use case it will be a price number based on currency)
+        var new_total = parseFloat(document.getElementById('output').value);
+
+        // Now we simply add the existing total value with the newly ":checked" input value
+        var updated_total = document.getElementById('output').value=new_total + add
+
+        // Place the new updated total directly inside the `total-cost-inner` span element
+        document.getElementById('total-cost-inner').innerHTML = updated_total;
+    }
+
+}
+}
+

That's it! Feel free to play with the demo some more at the top of the post, or check out the CodePen source directly.

Bringing dwm Shortcuts to GNOME

2023-11-02T10:00:00Z

Bringing dwm Shortcuts to GNOME

2023-11-02

The dwm window manager is my standard "go-to" for most of my personal laptop environments. For desktops with larger, higher resolution monitors I tend to lean towards using GNOME. The GNOME DE is fairly solid for my own purposes. This article isn't going to deep dive into GNOME itself, but instead highlight some minor configuration changes I make to mimic a few dwm shortcuts.

For reference, I'm running GNOME 45.0 on Ubuntu 23.10

Setting Up Fixed Workspaces

When I use dwm I tend to have a hard-set amount of tags to cycle through (normally 4-5). Unfortunately, dynamic rendering is the default for workspaces (ie. tags) in GNOME. For my personal preference I set this setting to fixed. We can achieve this by opening Settings > Multitasking and selecting "Fixed number of workspaces".

+ +

Screenshot of GNOME's Multitasking Settings GUI

Setting Our Keybindings

Now all that is left is to mimic dwm keyboard shortcuts, in this case: ALT + $num for switching between workspaces and ALT + SHIFT + $num for moving windows across workspaces. These keyboard shortcuts can be altered under Settings > Keyboard > View and Customize Shortcuts > Navigation.

You'll want to make edits to both the "Switch to workspace n" and "Move window to workspace n".

+ +

Screenshot of GNOME's keyboard shortcut GUI: switch to workspace

+ +

Screenshot of GNOME's keyboard shortcut GUI: move window to workspace

That's it. You're free to include even more custom keyboard shortcuts (open web browser, lock screen, hibernate, etc.) but this is a solid starting point. Enjoy tweaking GNOME!

Dynamic Viewports with CSS

2023-02-08T10:00:00Z

Dynamic Viewports with CSS

2023-02-08

I think it's safe to assume most web designers and developers are familiar with the standard vh and vw parameters in CSS. These parameters are used for setting an element's height and/or width, relative to the viewport (v) height (h) or width (w). For example:

If I want my .box element to take up the entire height of a device's screen:

.box {
+    height: 100vh;
+}
+

Or I want my .box element to take up the entire width of a device's screen:

.box {
+    width: 100vw;
+}
+

These are wonderful options to have - specifically for those of us designing web applications. But there are some minor issues with vh and vw.

The setting does not take into account device-specific UI (status bars, toolbars, search fields etc.)
In some instances these will not play nice with box-sizing properties

Have No Fear, Dynamic Viewport is Here!

Lucky for us there exists an awesome new-ish CSS API called dynamic viewport-percentage units: dvh & dvw. They are defined as follows:

The dynamic viewport-percentage units (dv) are defined with respect to the dynamic viewport size: the viewport sized with dynamic consideration of any UA interfaces that are dynamically expanded and retracted. This allows authors to size content such that it can exactly fit within the viewport whether or not such interfaces are present.
+

So our examples above would translate into:

.box {
+    height: 100dvh;
+    width: 100dvw;
+}
+

What About Browser Support?

Can I Use Stats / ~67.17% coverage.

Note: Even though the caniuse page states that Firefox 109+ and iOS Safari 16.3 do not support dvh, in my experiments they do. I'm not sure what testing was done for those two browsers, so YMMV.

If you want to play it safe, use dynamic viewports with standard "traditional" viewports as backup. That way you support all use cases while still taking advantage of newer CSS properties.

Don't Make a Blog, Make a Brain Dump

2022-09-10T10:00:00Z

Don't Make a Blog, Make a Brain Dump

2022-09-10

Not enough people have personal blogs. This is a point brought up by many of those passionate about the "golden age" in the timeline of the modern internet. A time when websites were more like a small collection of winding side-streets and flea markets. Today, it's all shopping malls, hostile pedestrians, and corporate buildings. People have their one or two "outlets" that make it easier for them to meet-up with friends and family. There's no need for these people to have their "own thing". Someone else has already built it for them. They're become fully adjusted to their internet slums.

Okay, sorry about the terrible metaphors. But you get my point. Convenience breeds laziness. Laziness breeds mediocrity.

What's a "Brain Dump"?

A brain dump is a better way to look at sharing your own experiences or thoughts on the web. The term "blog" has a lot of baggage connected to it, so newcomers are quickly scared away by the concept. Or even worse - they decide to only share themselves on locked-in, walled gardens[^1].

Another problem arises when you finally do convince someone to start "blogging" online; self-doubt.

"What could I possibly have to share?"
"What if everyone hates what I post?"
"What if my content sucks?"

Just dump it. Who cares. It's the internet after all, so who are you trying to impress? The point is that your sharing your own experiences that are unique to you as an individual. Posting something that you think is pointless or mundane might be extremely helpful or, at the very least, entertaining for someone else.

Write up what you did over the weekend, a new recipe you tried out, review a movie/book or video game you enjoyed, list step-by-step instructions on how you installed a new appliance in your house - anything! Just write and be part of what made the internet fun, exciting and personal again.

But let me reiterate: stay away from walled gardens! Control your own space on the internet. Be the master of your own brain dump! Say "screw you" to app algorithms and trending bullshit. Just be you.

Convinced? Awesome. Now let's get into setting things up. I'll break these down into two separate categories: one for those with limited web/software experience, and one for those wanting a little more control.

No Code Solutions

Before I get into my suggested options in this "no-code" category, I would like to mention why WordPress is not listed here. Personally, I think WordPress gets in the way of users wanting to "just blog". There once was an era where blogging was WP's main focus, but that is now a time long forgotten. It tries to do too much. The back-end is a cluttered mess. Initial learning curves for security, plugins and themes is far too great for newbies. Gutenberg - dear God.

That's not even mentioning hosting costs, installation, backups, etc. My personal take - just steer clear. This option is better suited in the second category for those with more web experience.

With that out of the way, let's see my top selections for "no-code":

Blot

Blot has been around for quite a while. You simply post to a third-party service like Dropbox, Google Drive or a git repo and Blot takes care of the rest.

$4/month (includes custom domain use, hosting & support)
Easy sign up
Multiple themes to choose from

Bear Blog

Bear Blog is an excellent platform that focuses on content and not much else.

Free ($25/year for extras)
Easy sign up
No trackers, no javascript, no ads

Mataroa Blog

Mataroa follows in the same vein as Bear Blog, a simple blogging platform focused on writing.

Free (with optional $9/year for premium features)
No ads, no tracking
Open source

Write.as

Write.as is another good option for those looking to just get words down and shared on the internet.

Free with optional paid tiers (custom domains, themes etc.)
Option to self host via Write Freely

Build Your Own

If you're deep into this section of the post, I think it's safe to assume your technical level is fairly decent. So, I won't be into great detail with the options below:

SourceHut Pages

This very website you're reading is built and run off of SourceHut Pages. I highly recommend the service.

$3+/month (depending on what you choose to pay)
No javascript, no trackers
Customizable build settings
Support open source software!

Sidenote: If you're interested in setting up a SSG (such as Jekyll or Hugo) through SourceHut, feel free to fork this very website as a starting point. I also wrote up how to publish/build a Jekyll site on SourceHut in a separate post if you wish to see all the nitty-gritty details.

WordPress

As I mentioned above, I find this platform can be a little overkill for a simple "blog" (or in this case, a brain dump). I'm aware that many devs might already be familiar with WP, so it makes sense to include it here.

Free options (custom domains, premium features will require some form of paid hosting)
Room for growth with extensive plugins / themes
Huge amount of documentation and resources

Static HTML and a Web Host

Why not, right? Using a service like NearlyFreeSpeech or spinning up a cheap VPS with DigitalOcean and then dropping static HTML files on your server is pretty straightforward. You don't need any fancy scripts or syncing tools - an FTP client and a text editor is more than enough!

$2-5/month (depending on service provider)
"Drag-and-drop" workflow
Easily portable to other hosting services in the future

GitHub Pages

Since GitHub is used by almost every developer across the globe, it makes sense to mention their free website hosting option via GitHub Pages. I personally don't advise newcomers to use this platform, but you're free to do as you like!

"Free"
Fairly limited (no static site plugin support)

Wrapping Up

There are many services in both categories above that I did not include. That's okay. I didn't exclude them because I dislike them but instead focused on what I believe to be the easiest solutions for both camps (techies and non-techies).

At the end of the day - who cares what you choose. Just choose something. Stop looking at it as "blogging" or trying to "capture an audience". Dump your brain's thoughts out into the internet, on your own piece of the internet, and help make the world wide web as fun as it used to be!

[^1]: Facebook, Twitter, Reddit, Instagram, etc. These should be completely avoided for the sake of both your health and your internet freedom.

Two Weeks with the DuckDuckGo Browser

2022-05-17T10:00:00Z

Two Weeks with the DuckDuckGo Browser

2022-05-17

After using the beta apps for the new DuckDuckGo browser for both macOS and iOS, I have returned to Safari.

This switch back doesn't mean that these browsers are bad by any means. Both browsers are decently fine for casual users. Unfortunately, they aren't ready for prime time "power" users. I'm happy to see another company jump into the browser market (and one that is using WebKit instead of another Chromium clone) but for my day-to-day needs it doesn't cut it.

Let's break things down:

The Good

Clean UI with a mix between Chrome and Safari
The "Leave No Trace" fire button to purge data, cache and cookies
Feels snappy and responsive
Based on WebKit NOT Chromium

The Not So Good

No sync options between systems (that I could find)
No extension support

Now you might look at this list and notice there are more listed points set under the Good category. Keep in mind that quantity does not always equal quality. The main negative of not allowing user extensions cannot be overstated. I think that when building a browser in this $CURRENTYEAR it's imperative to allow for total user control. Don't wall things off. Don't assumeyou know best for your users.

This is a huge issue since a good majority of friends, family and coworkers I talk with use more elaborate ad-blocking. One of the first things I tested with the DuckDuckGo browser on desktop was to watch a YouTube video. I was immediately slammed with multiple ads - both in video form and as banner pop-ups.

Overlooks like this shouldn't happen. This is UX 101.

Another obvious overlook is history and account syncing across devices. Unless I missed something obvious, I could not figure out how to seamlessly sync content from my macOS browser to my iOS one. Again, this function greatly improves the experience of jumping between desktop and mobile clients. Don't make me think![^1]

Closing Thoughts

I appreciate the effort from the DuckDuckGo team. I'm certain this project will get better over time, as they are listening closely to user feedback during the beta. With future improvements I could see myself giving things a second chance.

As it stands now, this feels like something that should be an extension[^2], not a standalone browser.

Refs

https://sensible.com/dont-make-me-think/
Technically this already exists as a Safari extension here

Designers Need Thicker Skin

2017-07-10T10:00:00Z

Designers Need Thicker Skin

2017-07-10

I'm not normally one to comment or even really care about "drama" within our design industry. Opinions are just that and should just be consumed at face value. But this week I was moderately annoyed with a subset of designers in design-land.

Critique the critics

Designer/design critic Eli Schiff tweeted his thoughts about the newly released promo video from Framer showcasing their new gradient feature. See the initial tweet below:

+ +

Eli Schiff just telling it how it is.

Let me begin by saying my views on this comment: I don't care. I honestly don’t feel strongly one way or the other about them making a video promo for gradients. Could it have just been a simple text tweet? Sure. Does it really matter that they decided to make a video for it? Not at all.

But this isn’t the problem.

Other designers took to Twitter and started attacking Eli, not even as a design critic but as a person. This was ugly to see. What happened to civil discussion and giving the other side a chance to say their piece? Calling to "ban him" from sites such as DesignerNews or suggesting to unfollow him on Twitter is unbelievably childish - in an industry that we tote as "accepting of everyone" no less.

That's all I'm going to say because I don’t want to spend too much time on this foolishness, but honestly designers - get some thicker skin.

Yeesh.

Disabling Comments in WordPress

2020-12-28T10:00:00Z

Disabling Comments in WordPress

2020-12-28

I seem to come across a decent amount of clients and users online that have a difficult time knowing how to disable comments for both future and previous blog posts. It isn’t the easiest for both use cases, so let’s break it down.

Back to the future

Disabling comments on all future blog posts is fairly straightforward:

Navigate to your WordPress admin dashboard
Go to Settings > Discussion
Uncheck Allow people to submit comments on new posts
That’s it!

But what about old posts?

Have no fear - “Bulk Actions” are here to save the day! In order to retroactively disable comments on older posts, do the following:

Navigate to Posts
Select the specific posts you would like to disable comments on (or select all of them)
Click the Bulk Actions drop-down menu and choose Edit
Press Apply
In the Bulk Edit view, look for the Comments drop-down
Select Do Not Allow and click Update
That’s it!

I hope this article saves others any headaches in the future. WordPress itself could certainly make this more streamlined, but for now what we have works. Happy (not) commenting!

Unsolicited Design Review - Dropbox

2017-10-10T10:00:00Z

Unsolicited Design Review - Dropbox

2017-10-10

Earlier last week the design team at Dropbox unveiled their new branding / design system for the company as a whole. If you haven't seen the updated design yet, you can do so here: dropbox.design (Take your time, I can wait).

I won't mince words when I say I believe this is a huge step backwards for their brand. Not only is it uninspired and broken, but it also shows how our industry is plagued with a need to redesign things just for the sake of redesigning them.

So without anymore fluff - let's get into it. Please leave your bias at the door.

Purpose

It's good to try and understand the motive or problem that a company is trying to solve when redesigning something as fundamental as core branding, but this is where the first red flag appears for Dropbox. There is no real problem to solve.

On the marketing site promoting the new design system, the Dropbox team doesn't mention a single problem that this branding redesign is meant to fix. Were users confused by the previous system? Is there data showing large drop-off and a lack of conversion directly connected with the design system itself? All they state is they needed a change with zero reasoning as to why.

+
We realized our brand needs to change
+

As I stated at the beginning of this review - it's a redesign for the sake of a redesign. Sometimes this can be acceptable if done correctly, but this is not the case for Dropbox.

+
Our new brand system shows that Dropbox isn't just a place to store your files - it's a living workspace that brings teams and ideas together.
+ Dropbox marketing website +

Let's stop right there. "A place to store your files" is literally 99% of what Dropbox does. I get that they want to be involved in more than that but Dropbox is a cloud storage service. Why is there a desperate need to shift away from that?

There isn't much else to speak of in terms of 'purpose' regarding the redesign since there doesn't seem to be one. Let's move on.

Design Principles

I hate to be that guy who bases design on a written list of principles, but when it works it works. Dieter Rams states it best:

Good design is innovative
Good design makes a product useful
Good design is aesthetic
Good design makes a product understandable
Good design is unobtrusive
Good design is honest
Good design is long-lasting
Good design is thorough down to the last detail
Good design is environmentally friendly
Good design is as little design as possible

1. Good design is innovative. There is zero innovation in this re-brand, it's simply following the trend of quirky / brutal / modern flat elitism that is currently sweeping the industry. It's a fad and will be out-of-date rather quickly.

2. Good design makes a product useful. Looking through their reasoning and explanations I can see no boost or improvement to the usefulness of the product. Not to repeat myself, but without any supporting data as to why this change was made we have nothing to base it off of.

3. Good design is aesthetic. See #1.

4. Good design makes a product understandable. Were customers not able to understand the Dropbox brand prior to this update? Were users misinformed about what the product could do for them? The previous design did a wonderful job of getting out of the way and showing the user exactly what they needed / wanted.

5. Good design is unobtrusive. Talk about going backwards on this one. Original system was clean, readable and friendly to new users. Their current system uses an illegible typeface, colors with terrible contrast and a lack of support for the visually impaired, crude illustrations that give no explanation as to what they represent (more on that later), and a lack of browser support / performance issues.

6. Good design is honest. Dropbox still maintains this principle. They don't over-promise or outright lie about who and what they are as a product.

7. Good design is long-lasting. See #1 & #3 again.

8. Good design is thorough down to the last detail. The fact that even their marketing site crashes latest Firefox, lags on Safari for iOS and stutters in Chrome on desktop shows the lack of performance testing that was done. Not to mention the complete disregard for those with visual impairments with their color palette, typeface and contrast selections.

9. Good design is environmentally friendly. Doesn't really apply here.

10. Good design is as little design as possible. This new brand system is incredibly over-designed.

+
Our users...tell us they feel overwhelmed and distracted during the workday...we want to change this, by building products and a brand that help people focus on meaningful work, instead of busywork.
+

Then maybe your design system should get out of the way. To me, this seems like you want your design to take center-stage over the user's content.

Remember: a great design system should go completely unnoticed.

Accessibility

Any persons with visual impairments need not apply. This design system is not built for you - seek shelter elsewhere.

+
With 259 fonts, our new typeface Sharp Grotesk gives us lots of versatility, allowing us to "speak" in a variety of tones.
+

+ +

Not a single one of these typeface styles is initially readable

The typeface they have chosen looks terrible at any view-port size and readability takes a backseat. I can't help but feel this falls into the "let's be trendy" category and ends up sacrificing almost all good usability practices for gimmicky type.

+
Our users run the gamut from business professionals to scientists and creative types. Most of these folks tell us they feel overwhelmed and distracted during the workday, and that this is one of the biggest barriers to creating work they’re proud of.
+

Irony at it's finest. "Our users tell us that they hate being distracted and overwhelmed, so we've decided to use headache inducing color palettes, crude illustrations, a barely legible typeface, and some of the most visually loud photography throughout our system". I hate coming off as mean-spirited - but this is some elaborate joke, right?

+ +

Oh Dropbox...my eyes!

After running it through a color contrast accessibility checker:

+ +

Multiple accessibility failures

Next we have the child-like 'scribble' illustrations. Now don't get me wrong, I love seeing different illustration styles and I actively use 'sketch / scribble' artwork myself, but I don't believe this is the best fit for a brand like Dropbox. These cartoon visuals conflict with the business enterprise service Dropbox should be trying to convey.

Another issue with these illustrations is their usage. Look at the image below and ask yourself if you would correlate it with an error page if no accompanying text was present.

+ +

What does this have to do with a 404 error page?

Closing Thoughts

I could go into even deeper analysis (including the oversimplification of their box logo, etc.) but I believe I've spent enough time defending my initial reaction as well as my thoughts after a week of soak time. In my opinion this redesign was completely unnecessary. I think this was a problem of too many designers with too much time without a proper project to channel all that talent.

Unfortunately because they decided to just follow the current trend and design with a lack of purpose, I see Dropbox launching another redesign within the next year once this current design fad dies. My only hope is that the next brand system sets out to solve an actual problem, instead of just trying to be trendy.

Personal Remarks

I love Dropbox as a product and use it every single day. I'm inspired by many of the designers who work there and this article is by no means a personal attack on the company or it's employees. This is merely a blunt and honest review of their new brand design system.

Modern Improvements for Default Browser Styles

2021-11-09T10:00:00Z

Modern Improvements for Default Browser Styles

2021-11-09

This website almost exclusively uses the browser's (whichever one that might be) default styling to render it's HTML. I firmly believe, and have stated in a previous post, that the default HTML styling across all browsers is a thing of beauty. "Consistent and boring" is how I tend to refer to default browser styles - and I mean that in a good way.

But that doesn't mean some minor, modern improvements couldn't be made...

Boosting Margins and Increasing Font Size

A little extra breathing room for a website's content never hurts. Browser defaults set the inner content too close to the main window borders, creating mild eye strain to focus on the far edges of the screen when reading. Pair this with a typeface set too small and you've got a recipe for disaster (in terms of user experience and accessibility). Luckily for us, adding two basic CSS properties fixes all of our readability woes. All that is required is a simple boost to the existing margin property set on the body element (I personally lean towards a very specific 1.5em) and overriding the default font-size to 18px[^1]:

body {
+    font-size:18px;
+    margin:1.5em;
+}
+

There is one small caveat with setting the font-size across the whole body element: code elements set in monospace. They will stand out larger than the other fonts found in the document (due to variations in different typeface heights, spacing etc.) so we will need to target these elements specifically:

code {
+    font-size:14px;
+    /* Word wrap is optional if you plan to have long inline code snippets */
+    word-wrap:break-word;
+}
+

Code & Pre Tags

Since we've mentioned code elements, let's fix those as well. The existing styling for inline code snippets and larger pre-formatted text sections leave a lot to be desired. They don't provide any means to wrap their inner content or make use of overflow properties to avoid vertically scrolling on smaller device screens. Sharing code examples becomes quite a pain when your webpage's flow and layout is broken just by including them. Browsers could fix this easily enough by defaulting to:

pre {
+    overflow:auto;
+}
+

Basic Dark Mode Support

Barebones styling in current web browsers have no sane defaults[^2] for system-level dark mode. What a huge letdown. This is where the most "drastic" changes will be implemented with our browser default updates. We will need the browser to change the main background-color, along with resetting both the text and anchor link color for improved accessibility. Browser defaults for anchor link color in "light mode" are blue/purple - so I've opted towards using gold, orange and orangered in dark mode respectively:

/* Dark mode */
+@media (prefers-color-scheme: dark) {
+    @media not print {
+        html {background:#0e0e0e;color:#e1e1e1; }
+        a {color: gold;}
+        a:visited {color: orange;}
+        a:hover,a:focus{color: orangered;}
+    }
+}
+

That is probably the most streamlined dark mode on the web...

The "Reading Length" Debate

Proper reading length tends to be quite the point of contention on the web. Hell, even I've written about it quite a bit in the past (and many of my side projects follow that standard). The main problem I have with this is lack of user control. I don't think the browser (or designers for that matter) should determine the best reading length for my own personal reading preferences. UX testing and group feedback has (somewhat) agreed upon 66-75 characters per line to be the most optimal reading experience. That is good to know. I still believe it should come down to user preference.

Do you want to know an incredible feature built into browsers? Window resizing. Abandon the idea that you "know better" than your users and give them the power to adjust as they see fit. The web was meant to be personal and flexible.

Conclusion

There isn't much else to say, really. I think these tiny tweaks would greatly improve the default browser experience and maybe even convince others to just use these defaults instead of falling down the CSS rabbit hole (as fun as that might be sometimes). For easier convenience, I'll leave the full set of CSS changes below:

body {
+    font-size:18px;
+    margin:1.5em;
+}
+code {
+    font-size:14px;
+}
+pre {
+    overflow:auto;
+}
+@media (prefers-color-scheme: dark) {
+    @media not print {
+        html {background:#0e0e0e;color:#e1e1e1; }
+        a {color: gold;}
+        a:visited {color: orange;}
+        a:hover,a:focus{color: orangered;}
+    }
+}
+

Refs

18px seems to be the perfect sweet spot between "almost too large, yet not small enough to strain my eyes"
At the time of this article's publish date

Very Basic Form Styling

2019-11-13T10:00:00Z

Very Basic Form Styling

2019-11-13

Web forms can be great - I'm borderline obsessed with them. I love tinkering with pre-existing logins / sign up pages and I've also open sourced a minimal CSS form-styling plugin: Normform. While simple CSS plugins like these can be helpful, I often feel like we are over-engineering our web forms. I'm certainly guilty of it.

That's not to say developers should just use default browser styling for their forms and call it a day - that is far from ideal. Just pull-back on adding so much styling garbage to the forms themselves.

Let's check out an embedded demo below to see what some bare-bones form styling could look like:

Live CodePen Example

This form isn't going to win any design awards or blow anyone away with its creativity. That's okay - because it gets the job done. Users understand it's a form and items are broken down into digestible chunks. Mission accomplished, right?

Breaking the form down

Let's take a look at the HTML of the entire form:

<form action="">
+    <fieldset>
+        <legend>Personal Details</legend>
+        <label for="username">Desired Username:</label>
+        <input type="text" id="username">
+        <label for="name">Full Name:</label>
+        <input type="text" id="name">
+        <label for="email">Email Address:</label>
+        <input type="email" id="email">
+        <label for="date">Date of Birth:</label>
+        <input type="date" id="date">
+    </fieldset>
+    <br>
+    <fieldset>
+        <legend>Contact Details</legend>
+        <label for="address">Home Address:</label>
+        <input type="text" id="address">
+        <label for="postal">Postal Code:</label>
+        <input type="text" id="postal">
+        <label for="phone">Phone Number:</label>
+        <input type="tel" id="phone">
+    </fieldset>
+    <br>
+    <fieldset>
+        <legend>Select an Option</legend>
+        <label for="radio-1">
+            <input type="radio" id="radio-1" name="radio-choice">
+            The option is pretty nice
+        </label>
+        <label for="radio-2">
+            <input type="radio" id="radio-2" name="radio-choice">
+            This option is a little bit better
+        </label>
+        <label for="radio-3">
+            <input type="radio" id="radio-3" name="radio-choice">
+            This option is the best
+        </label>
+    </fieldset>
+    <br>
+    <fieldset>
+        <legend>Notifications</legend>
+        <label for="checkbox-1">
+            <input type="checkbox" id="checkbox-1">
+            I would like to receive email notifications
+        </label>
+        <label for="checkbox-2">
+            <input type="checkbox" id="checkbox-2">
+            I would like to subscribe to the weekly newsletter
+        </label>
+    </fieldset>
+    <br>
+    <input type="reset" value="Reset">
+    <input type="submit" value="Submit">
+</form>
+

Notice the fieldset and legend elements? I bet you don't see or hear about those HTML items very often. By default, fieldset allows sibling or related inputs to be semantically grouped together. The legend elements give the user great visual cues about which items are grouped together, helping to focus on each section individually as they complete the form. Use these grouping elements as much as possible (when it makes sense of course) for a better guided experience for your users.

Avoid making your own custom sections and instead use these existing HTML semantics.

Almost no CSS at all

Now it's time to style this form with only 6 property declarations:

form label {
+    display: block;
+}
+form input {
+    display: inline-block;
+    margin-bottom: 10px;
+    padding: 10px;
+    width: 100%;
+}
+form input[type="radio"],
+form input[type="checkbox"],
+form input[type="reset"],
+form input[type="submit"] {
+    width: auto;
+}
+

Of course, you can always add minor adjustments (like in my demo example above)

Legend typeface and sizing
Form and fieldset background colors
Extra margin and padding
Custom reset / submit buttons

But the main point of this post is to showcase how little CSS is needed to implement decent web forms - so any further improvements are up to you, dear reader.

Just try not to reinvent the wheel.

Final rant - don't ignore the reset

A lot of "modern" web forms have moved away from including the reset input on their forms, which I think is fairly short-sighted. Resetting all form fields might be a smaller edge case, but it is certainly a better option than relying on the user to refresh or in some cases, individually deleting each input. Yikes.

Happy form building!

The Death of Personality

2017-11-01T10:00:00Z

The Death of Personality

2017-11-01

On September 18, 2013 truly original product design (everything from icon and app design to UI and experience interactions) began it's fast decline into the abyss with the release of Apple's iOS 7 update. It was called revolutionary. It was seen as a 'new age' of design. I think it was a big mistake.

Stepping backwards

Let me start off by saying I understand where they were trying to take mobile app design as a whole. "Less is more", "cleaner UI to let the content be the focus", "more touch based interactions". The problem is that they cranked the dial too far in the other direction.

Because of this, a large movement was created based around the idea that skeuomorphic design is garbage, flat design is the future. And everyone drank the kool-aid without a single objection. +I'm using this ironically.

Icons with no identity

Do you remember Instagram's original app icon and UI? Do you remember how everyone initially praised it? Show those old designs to the same designers who loved it only a few years ago, and they will now laugh at how "bad" it is.

+ +

They completely butchered the contrast and initial readability to appease the 'flat' trend style. The personality died.

Unfortunately the same can be said for Apple's system icons across both iOS and macOS.

I believe Apple took the concept of a 'consistent' design system across their iconography too literally. All the system icons should compliment one another, but they shouldn't lose their own individual look and feel.

+ +

Look at the depth and thought put into the original iOS icons. The "newer" icon designs look like lazy and uninspired wire-frames.

Lackluster UI

The once inspiring and hierarchically consistent interface of both iOS and macOS was also quickly swatted away. In it's place we as users saw the removal of depth, initial visual cues as to what was interactive and what was static, and sadly even the overall color was muted.

+ +

More ugly wire-frame skeleton design compared to it's original counterpart. Where is the call to interact with any of these elements? Where is the hierarchy?

Impact on the web

This may not have been a bad thing if it was self-contained to Apple itself. The problem is that Apple has such a huge influence on the design industry - although that is starting to diminish, due to disasters like the iPhone X - that everyone starts to mimic and copy their style. This includes designers of sites and progressive web apps.

+ +

Comparison of button states. Which states are more instantly recognizable?

With the evolution of websites morphing into progressive web apps, designers have felt the need to start implementing this bland style for their design systems.

What we got in return:

washed out colors
zero gradients for depth
the removal of all drop shadows (in meaningful ways that is)
the same generic Helvetica-based typefaces
the absence of hover states on interactive elements
a lack of any proper information density
an overkill of whitespace
one dimensional buttons (you know, the thing you want the user to interact with)
a complete disregard for original design not based off every other popular product

+ +

The minimal / flat toggles look like unfinished prototypes.

Breaking free of the 'modern era'

Thankfully, there are still a few good designers who continue to create original and inspiring work not based solely on current trends.

Flexibits recently launched a new contact app for macOS called Cardhop. While the UI still shifts a little too far to the 'flat trend' for my liking, they thankfully hired the very talented David Lanham to design the beautiful application icon.

This is where visual design shines. Icon designs like Cardhop's are what allow individual applications to stand out in the dock or mobile home-screen among all the others. So how is that not UX design?

+ +

The gorgeous Cardhop app icon by David Lanham.

The current trendy thought process from designers that "visual design doesn't involve UX design" is garbage. Neither are mutually exclusive and I think anyone who believes so is being incredibly short-sighted.

If you're a designer, please stop riding trends and make your work visually beautiful. That doesn't mean you need to sacrifice usability or function, but just put more love and confidence into your profession. Companies like Apple and Google don't control how everyone else's apps and sites should look, and based on their current design decisions - they shouldn't.

Cut Your Forms in Half

2019-05-09T10:00:00Z

Cut Your Forms in Half

2019-05-09

Building web forms can sometimes feel like a boring or daunting task. Don't pass this dread on to your users - rip out as many of your form fields as possible.

Web forms tend to get a bad rep, mainly because so many horrible design choices are made without the user experience set at the forefront. Often times clients demand that they need those twenty input fields or else how will they collect critical information from their users? Normally when I'm approached with such a statement I simply ask them:

"How many form fields would you be willing to fill out for an emergency situation?"
+

"My form isn't for emergencies though", they might reply. In that case ask them why they feel it acceptable to waste their users' time just because it isn't urgent. Time is valuable.

Fixing a form in the wild

Let's use a real-world form off the Great West Life Insurance website as an example (left is original, right is updated):

Breaking things down

So what exactly have we changed?

Combined first and last name fields into a single input
Removed the overkill "retype" email & password field (with the optional show password this becomes redundant)
Minor position changes for optional subscription sign up and input field descriptions
Removed recovery email + - This is something that should be prompted to the user after successful registration - don't bog them down before they even sign up

Helpful Micro improvements

You don't need to be extreme when gutting form fields - just be practical.

Don't use "first" and "last" names as separate inputs, instead use something like "Full Name"
Make complex questions use preset answers via checkbox or radio inputs
Avoid select items whenever possible (these are clunky and most times unnecessary)
Include easy to understand, real-time error prompts

CSS Value: `currentColor`

2019-04-13T10:00:00Z

CSS Value: `currentColor`

2019-04-13

There are a large number of nuanced and mostly unheard of CSS value types, but today we are going to focus on currentColor. So what is the currentColor value type anyway?

The currentColor value type will apply the existing color value to other properties like background-color, etc.
+

See it in action

Let's assume with have a single div with the following properties:

div {
+    color: dodgerblue;
+}
+

If we wanted to use that same color for other properties on elements inside that initial div, it's simple - we just need to call currentColor like so:

div {
+    color: dodgerblue;
+}
+
+div header {
+    background-color: currentColor;
+}
+
+div a {
+    border-bottom: 1px solid currentColor;
+}
+

Sidenote: If you re-declare the default color property further along in your CSS, the currentColor value will update according to the last color set.

And that's it. Best of all, this value type is supported across all major browsers!

CSS Video Backgrounds

2018-04-16T10:00:00Z

CSS Video Backgrounds

2018-04-16

With the release of Safari 11.1 on macOS and Safari on iOS 11.3, developers now have the ability to support background videos (mp4 support only - at the time of this article) with pure CSS.

Example:

.video-background {
+	background-image: url('path-to-video.mp4);
+}
+

See it in action

Check out the very basic CodePen I created below to see it live (make sure you view it in latest Safari or else you won't see anything :P)

CSS Video Background (Safari Only)

You can read up on all the new features implemented in 11.1 Safari here:

New WebKit Features in Safari 11.1

CSS Variables

2018-03-24T10:00:00Z

CSS Variables

2018-03-24

The CSS language is becoming even more awesome and powerful everyday. In this quick article I'd like to focus specifically on the "new" CSS variable function that you can start using in your projects right now.

Getting started is easy

Let's just jump right in - this is how you create variables in vanilla CSS:

:root {
+    --base-color: #e0e0e0;
+    --text-color: #111;
+}
+

We are using the :root selector at the very top of our CSS file in order to call these variables into any elements in the rest of our document. This is normally the safest way to include variables.

As for the variables themselves, you declare that they are variables using the -- tags, followed by the variable's name and it's property. Pretty simple stuff, right?

Now let's use those variables:

.header {
+    border: 1px solid var(--base-color);
+}
+
+.main-container {
+    background-color: var(--base-color);
+    color: var(--text-color);
+}
+

That's it! It's also good to know that CSS variables have pretty decent browser support (who likes IE11 anyway).

Why not just use a preprocessor?

I'm a pretty big fan of Sass and Stylus, but sometimes it's refreshing to just use vanilla CSS for certain projects. Most preprocessors have had the ability to use variables and mixins for a while, but I prefer to avoid build scripts when not absolutely necessary.

Get out there and have fun with some variables!

CSS Slope Graphs

2021-06-07T10:00:00Z

CSS Slope Graphs

2021-06-07

I am a huge sucker for simplistic and beautifully designed visual data on the web. Most data tends to be graphed via line or bar systems - which is fine - but I think slope graphs are highly underrated. Let's change that, shall we?

The Demo

I'm basing this demo off the design patterns found in Edward Tufte's visualization work, specifically his slope graph designs:

Live CodePen Example

The HTML

For this concept we will actually be building this graph out of tables - crazy, right? The greatest benefit of rendering all the data inside of a table element is the ability to easily support smaller screens and mobile devices. Larger viewports will get to see the pretty slope graph, while those below a certain threshold will view a simple table.

(But more on that in the CSS section)

<p>Sales of the leading frozen pizza brands of the United States from 2011 to 2017 (in million US dollars) <br><em>Source: Statisa 2018</em></p>
+<table>
+    <thead>
+        <tr>
+            <th>Pizza Brand</th>
+            <th>2011</th>
+            <th>2017</th>
+        </tr>
+    </thead>
+    <tbody>
+        <tr>
+            <td data-set="677.0">DiGiorno</td>
+            <td><span>677.0</span></td>
+            <td data-name="DiGiorno">1014.6</td>
+        </tr>
+        <tr>
+            <td data-set="294.8">Private Label</td>
+            <td><span>294.8</span></td>
+            <td data-name="Private Label">524.8</td>
+        </tr>
+        <tr>
+            <td data-set="286.1">Red Baron</td>
+            <td><span>286.1</span></td>
+            <td data-name="Red Baron">572.3</td>
+        </tr>
+        <tr>
+            <td data-set="257.9">Tombstone</td>
+            <td><span>257.9</span></td>
+            <td data-name="Tombstone">270.6</td>
+        </tr>
+        <tr>
+            <td data-set="164.5">Totino's Party Pizza</td>
+            <td><span>164.5</span></td>
+            <td data-name="Totino's Party Pizza">347.2</td>
+        </tr>
+    </tbody>
+</table>
+

As you can see, nothing too fancy is happpening here. Pay close attention to the data-set and data-name variables though - those will be important for the CSS portion of this design, mainly the rendering of the line elements.

The CSS

To avoid overwhelming your brain all-at-once, let's break the CSS down into bite-sized chunks, starting with the base styling:

@import url('https://opentype.netlify.com/et-book/index.css');
+* {
+    box-sizing: border-box;
+}
+
+html {
+    height: 100%;
+}
+
+body {
+    background: #fffff8;
+    font-family: "et-book", serif;
+    height: 100%;
+    margin: 0 auto;
+    max-width: 800px;
+    padding: 0 0.5rem;
+}
+
+p {
+    font-size: 18px;
+    margin: 4rem 0 6rem;
+}
+
+table {
+    border-collapse: collapse;
+    text-align: left;
+    width: 100%;
+}
+

Pretty basic stuff.

Now we need to design how our slope graph will look on larger screens / desktops. For this instance, we will target these larger devices with a min-width media query of 800px. The rest of the CSS might look a little confusing but I assure you it is quite simple.

On larger devices we hide the first thead tr th element with display: none
The first and second td elements inside each tbody row need to be set as position: absolute to avoid duplicate content
The inner span that we include in our HTML inside the second tbody tr td also needs to be display: none
Remember that data-set variable? We now use that for our :before pseudo element for table tbody tr td:nth-of-type(1)
Remember that data-name variable? We now use that for our :before pseudo element for table tbody tr td:nth-of-type(3)
After that, you can see the simple customization we include to render the angle / position of the slope lines and the corresponding labels

@media(min-width:800px) {
+    table {
+        display: block;
+        position: relative;
+        margin-bottom: 25rem;
+    }
+
+    table thead th {
+        border-bottom: 1px solid lightgrey;
+        font-size: 24px;
+        position: absolute;
+        top: -50px;
+        width: 45%;
+    }
+    table thead th:nth-child(1){ display: none; }
+    table thead th:nth-child(2){ left: 0; }
+    table thead th:nth-child(3){ right: 0; text-align: right; }
+
+    table tbody tr td:nth-of-type(1),
+    table tbody tr td:nth-of-type(2) { position: absolute;}
+
+    table tbody tr td:nth-of-type(2) span { display: none; }
+    table tbody tr td:nth-of-type(1):before {
+        content: attr(data-set);
+        margin-right: 10px;
+        position: relative;
+    }
+
+    table tbody tr td:nth-of-type(2) { padding-left: 10px; }
+
+    table tbody tr td:nth-of-type(3) {
+        position: absolute;
+        right: 0;
+    }
+    table tbody tr td:nth-of-type(3):before {
+        content: attr(data-name);
+        margin-right: 10px;
+        position: relative;
+    }
+
+    /* Custom individual slopes -- Left */
+    tbody tr:nth-child(1) td:nth-child(1),
+    tbody tr:nth-child(1) td:nth-child(2) { top: 60px; }
+    tbody tr:nth-child(2) td:nth-child(1),
+    tbody tr:nth-child(2) td:nth-child(2) { top: 140px; }
+    tbody tr:nth-child(3) td:nth-child(1),
+    tbody tr:nth-child(3) td:nth-child(2) { top: 165px; }
+    tbody tr:nth-child(4) td:nth-child(1),
+    tbody tr:nth-child(4) td:nth-child(2) { top: 220px; }
+    tbody tr:nth-child(5) td:nth-child(1),
+    tbody tr:nth-child(5) td:nth-child(2) { top: 270px; }
+
+    /* Custom individual slopes -- Right */
+    [data-name="DiGiorno"] { top: 0; }
+    [data-name="Red Baron"] { top: 65px; }
+    [data-name="Private Label"] { top: 100px; }
+    [data-name="Tombstone"] { top: 180px; }
+    [data-name="Totino's Party Pizza"] { top: 150px; }
+
+    /* The custom visual lines */
+    tbody tr:after {
+        background: black;
+        content: '';
+        height: 1px;
+        left: 14.5%;
+        position: absolute;
+        width: 70%;
+    }
+    tbody tr:nth-child(1):after {
+        top: 40px;
+        transform: rotate(-6deg);
+    }
+    tbody tr:nth-child(2):after {
+        left: 17.5%;
+        top: 130px;
+        transform: rotate(-4deg);
+        width: 65%;
+    }
+    tbody tr:nth-child(3):after {
+        left: 15%;
+        top: 125px;
+        transform: rotate(-10.25deg);
+        width: 70%;
+    }
+    tbody tr:nth-child(4):after {
+        left: 16%;
+        top: 210px;
+        transform: rotate(-4deg);
+        width: 68%;
+    }
+    tbody tr:nth-child(5):after {
+        left: 22%;
+        top: 222px;
+        transform: rotate(-16deg);
+        width: 56%;
+    }
+}
+

All that's left are some minor styles to make everything look nice on mobile:

@media(max-width:800px) {
+    p {
+        margin: 2rem 0;
+    }
+    table td, table th {
+        border-bottom: 1px solid grey;
+        padding: 10px;
+    }
+    table td:last-of-type, table th:last-of-type {
+        text-align: right;
+    }
+}
+

Not the most practical

This slope graph concept is far from perfect for use in real-world situations. The fact that you need to manually render each point of data yourself makes this implementation quite annoying for more in-depth projects.

But it was fun to mess around with and create, so who cares!

A Reality Where CSS and JavaScript Don't Exist

2021-11-03T10:00:00Z

A Reality Where CSS and JavaScript Don't Exist

2021-11-03

This is my personal opinion. Please leave your pitchforks at the door...

I love CSS. I can spend hours deep diving into a website's CSS system and never find myself getting bored. It's pretty amazing to see the problems other designers are able to solve with just a little bit of custom styling and determination.

I like JavaScript. It serves it's purpose and makes complex functionality on the web easier to wrangle in and understand.

But I think both should have never come into existence.

Heresey!

I know, I know - this website itself uses a little, teeny-tiny amount of CSS. I am indeed a hypocrite - but did I ever claim that I practice what I preach? At least this personal website is JavaScript-free... (apart from a handful of CodePen examples embedded in some of the tutorials).

Moving On...

I'm not a complete idiot. I realize that the web has evolved significantly over the years, and to propose that it should have remained stagnant with it's original concept of "paged documents" is foolish. But that is what I'm suggesting - at least, partially.

Consistent & Boring

Out there in the multiverse is a reality where the web is a complete borefest. Information is the only driving factor to visit a "web page" and PWAs have never come to exist. Custom styling, fancy interactive animations and single-page functionality isn't even something that can be implemented. The web is just a system of HTML/plaintext documents sharing information and data. Users browse the web in quick bursts to satisfy their queries or read something interesting. Then, they return to real life.

My goodness what a beautiful reality that would be. Consistent, boring and wonderful.

"Wait - Aren't You a Designer?"

Yes - and again more hypocrisy. My livelihood depends on software requiring custom UIs and properly audited UX flows. By suggesting this change I am throwing myself under the bus and putting myself out of work. All my experience would become worthless and the world of software design would cease to exist.

I would be okay with that. If it meant the web as a whole was a better place - so be it.

A Look at the "New World"

Sometimes it is easier to visualize a concept instead of just discussing it. Below you can find an example of a "converted" website[^1] showcasing how sites would look and feel in this design-less reality:

Wealthsimple: Current Website / New Version

As you can see, all the fluff has been removed from the existing design and only the content remains. No scroll-jacking or extra JavaScript libraries are downloaded. Users can easily skim through all the content and screen readers won't struggle through any custom elements. It also loads incredibly fast.

Of course, to our[^2] eyes, this design might look ugly or seem as though the site's CSS failed to load - but in a reality where this is the standard, it is beautifully minimal. Either way, I find that this was at least a fun thought experiment and hopefully leaves you thinking about how the web could have been as well.

Now, back to designing UIs for the web...

Refs

Selected site based on my own personal preference
Referring to current users of the web

Web Development on a $200 Chromebook

2020-01-07T10:00:00Z

Web Development on a $200 Chromebook

2020-01-07

This blog post was written, edited and tested locally on a cheap $200 Chromebook. The article draft was composed in Sublime Text. Jekyll (the SSG this website uses) was generated via the Linux Beta Terminal running alongside Chrome OS. It was then pushed to the Github repo from the same Terminal and published automatically to Netlify. But more on that later.

First, we need to ask an important question: why use a Chromebook for web development? Maybe a better question might be: why not?

Mild interest turned into an experiment

Looking from the outside, I always liked the concept of the Chrome OS ecosystem. It had a solid list of features that appealed to me, specifically:

Blazingly fast boot times
Long lasting battery life (roughly 8 hours with consistent usage)
Extremely cheap entry point for "low-end" devices
And, more recently, support for Android & Linux apps

The obvious downside to using a Chromebook is the lack of a "real" operating system. A Windows, Mac or Linux machine will always have more flexibility and depth than a simple Chromebook. But I've found that simple is all I need - or want.

Side note: I wrote an article not to long ago about blocking Google from my website and I can see how this current post may come across as hypocritical. Since the search/AMP teams are not that same as the Chrome OS / Chromebook development team, I can view each of those projects based on their own merits. If you still view me as a hypocrite, that's fine :)

My use case (YMMV)

I ended up grabbing the Acer 11 N7 Chromebook off of Amazon for $200 (on sale and in Canuck bucks). It comes packed with 4GB of RAM with an Intel Celeron (1.6GHz) and 32GB of storage. Fairly barebones stuff.

My day-to-day use cases are fairly straightforward. I work with git, static site generators, WordPress locally and on staging servers, edit documents, send emails and watch stupid YouTube videos. You know, the basics. My dirt-cheap Chromebook handles all of these things with ease.

My Chromebook setup is as follows:

Linux Beta (ships with git, etc)
Sublime Text (you can always use VSCode if you prefer)
Terminal
Local by Flywheel (local WordPress development)
Figma in Chrome (UI design / mockups)

That's it. I understand other developers may require a lot more than this, but with Linux running in a container alongside Chrome OS you can pretty much run anything you could possibly need (excluding exclusive Mac & Windows apps, of course).

Can a $200 Chromebook be your next web dev machine?

For me? Yes. For you? Maybe.

I mean, it really just depends on what you need your machine to accomplish. If you can be productive and the apps you use are just as fast and responsive as they would be on a more robust OS - then I say go for it. You don't even need to be a cheapo like me, instead you can snag a fancier Chromebook or Google's own Pixelbook. There are a ton of options when it comes to Chrome OS based devices.

If you wanted to experiment to see if the Chrome OS ecosystem could work with your development flow, you can always check out something like CloudReady to test on your current machine before pulling the trigger.

In the end, it doesn't matter what operating system or apps you use to get your development work done - so long as it is productive and easy-to-use.

For my current situation, all I need is my cheap little Chromebook.

Portable Pi: Cheap Raspberry Pi Zero Hacker Terminal

2020-09-16T10:00:00Z

Portable Pi: Cheap Raspberry Pi Zero Hacker Terminal

2020-09-16

I recently came across the incredibly cool design for an "ultimate Raspberry Pi computer" by NODE and was inspired to create my own "portable" Pi device. Although, with my concept, I decided to set a few restrictions on the build:

I wanted to keep the total cost as low as possible +
- including the Pi Zero and extra hardware
+
I wanted to avoid any custom casings or need for 3D printed materials
I wanted to make the full design extremely portable / lightweight
I wanted to keep the build as user-friendly as possible (no soldering, odd hacks etc.)

With these constraints put in place, I built my very own Raspberry Pi Zero "hacker" terminal. You can see the finished product below:

I'm pretty happy with the final outcome and best of all - you can easily recreate this yourself with little-to-no effort!

So enough chit-chat - let's build this bad-boy!

Note: Most items in the hardware section are Amazon affiliate links
+

Setting Expectations
The Hardware
The Software
Getting Setup
Final Summary

Setting Expectations

This hardware will not replace your laptop or any other "high-powered" portable device. Honestly, you're mobile phone would (most likely) work better in terms of a compact-sized computer. The concept behind this "portable pi" project was to make something for fun.

Please reserve any sassy comments about how buying a cheap $50 laptop off eBay would be more efficient than building out something like I have done here. You're missing the point entirely.

Moving on for those still interested...

The Hardware

I live in Canada, so some of the options are based on available hardware near my location. You're likely to find similar hardware close to your own country for better pricing / shipping costs.

Note: I've decided to use a wireless, USB dongle-based keyboard. You can opt to use a bluetooth-based keyboard, but I just find them more trouble than they are worth (keeping a charge, losing connections, interference from other devices)
+

SBC: Raspberry Pi Zero WH
Storage / OS: 64GB Micro SD Card (Always have an SD backup!)
Battery HAT: Li-ion Battery HAT
Battery: This depends on your location. I was able to order online through Walmart, but if you live in the USA there are plenty of battery-specific vendors available. Find whatever works best for your needs!
Display: KeDei 3.5-inch TFT Display
Keyboard: Mini USB Wireless Keyboard
Adapter: Micro USB OTG Cable

Raspberry Pi Zero WH

You will need a Raspberry Pi Zero W with GPIO header pins already soldered on to the board. (You could also do this yourself manually if you have the tools and skill to do so)

Li-Ion Battery HAT

This HAT holds a single li-ion battery and for our purposes will connect with our Pi Zero via the GPIO header pins. You could also look into double-set battery HATs if that is something you would prefer - for my needs a single rechargeable battery works fine.

Since our main "OS" is purely terminal based, I find you don't really need a li-ion battery with a massive amount of power storage. 2500mAh will easily last a handful of hours mucking about with emails, files and web browsing. Plus, you can always carry a few extras for swapping out on-the-go.

3.5-inch TFT Display

A simple and fairly cheap touchscreen display. We won't require our display to render videos or pretty graphics (since we will be entirely terminal-based) so this works just fine for our needs. I am using version 6.3 for this build.

Micro USB OTG Adapter

As mentioned above, this item is optional if you feel more comfortable with using a pure bluetooth keyboard. I just personally prefer this method.

Wireless Keyboard

In my product demo image at the beginning of the article, I'm actually using an old Logitech wireless keyboard since this one still hasn't arrived. I plan to swap them out once I have it - the Logitech is far to large to be deemed "portable".

The Software

Operating System: Raspberry Pi OS Lite
Display Driver: KeDei 3.5 Driver
Email: Neomutt (via Mutt Wizard)
Web Browser: Lynx
Text Editor: Nano
Code Editor: Vim

Getting Setup

I will be setting up this "portable pi" via headless installation with my main Raspberry Pi 4 desktop. Included below are some quick instructions on how to setup the Raspberry Pi Zero for ssh access.

Preparing the microSD card

Use Raspberry Pi Imager to write the Raspberry Pi Lite OS to your microSD card +
- Once complete, remove the microSD storage device and then re-connect it
+
Navigate to the boot folder of the microSD device - we will be adding 2 files here +
- First add a completely empty file and name it ssh (no file extension)
- Next add an empty file named wpa_supplicant.conf
+
Open the wpa_supplicant.conf file in a code / text editor and paste the following (be sure to change country to your proper country code, as well as properly setting your network name / password):

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
+update_config=1
+country=US
+
+network={
+    ssid="Your network name/SSID"
+    psk="Your WPA/WPA2 security key"
+    key_mgmt=WPA-PSK
+}
+

Unmount the microSD device, then place the microSD card in your RPi Zero
Assemble the Raspberry Pi Zero with the Battery HAT (li-ion battery attached) connected via GPIO pins, and the 3.5 display connected on-top of the battery HAT's pins
Turn on the battery HAT switch to power the RPi Zero. Give the device roughly 90 seconds to perform the initial boot

Note: the display will turn on but only show a white screen - this is normal
+

Connecting to your Zero via SSH

Open the terminal on your Raspberry Pi desktop and enter the following command:

ssh pi@raspberrypi.local
+

You will then be asked if you wish to trust this device (say yes), then prompted for the pi user's password - which is raspberry. After a moment you will be directly connected to your Raspberry Pi Zero. Hooray!

We just want to make a couple small configuration changes before going forward (mostly for security):

Run the command sudo raspi-config
Select "Change User Password" from the menu and change the password

+ +

After that, select "Network Options" and change your device name

- This will avoid any conflicts of connecting to newer RPi devices down the line

That's it!

Installing display driver

Next we will need to download and run the drivers needed for our 3.5-inch display to play nicely with our Pi Zero (just a blank white screen doesn't help us much). While connected to our RPi Zero via SSH, run the following commands:

wget http://kedei.net/raspberry/v6_1/LCD_show_v6_1_3.tar.gz
+

If you have snail-paced rural internet like I do, now is a good time to go and grab a coffee while this download completes.

Once the download has finished, extract the contents and navigate to the new directory and install the driver:

sudo tar xzf LCD_show_v6_1_3.tar.gz
+cd LCD_show_v6_1_3
+sudo ./LCD35_v
+

Once completed, the RPi Zero will reboot and everything should work as expected!

Installing software

I'm not going to jump into heavy details about installing terminal-based software for this setup. The links I've attached in the software section should provide you with more than enough information to get started. For reference, I'm using a very basic set of applications:

Neomutt (emails)
Lynx (quick and simple web browsing)
Nano (writing notes / blog posts in a hurry)
Vim (making any config edits or project work)

Final Summary

There you have it - a terminal-based, portable Raspberry Pi Zero "hacker" device.

Is it practical? Not really. Can it replace any other portable device you might own? Probably not. Is it fun to make and experiment on? You bet! And in the end - isn't that what matters most with pet Pi projects?

Chasing Performance

2017-11-20T10:00:00Z

Chasing Performance

2017-11-20

Update

This post is no longer relevant since this blog has been redesigned since. I'm keeping this article up as a point of reference.

So I decided to participate in Smashing Mag's Front End Performance Challenge, not only for the potential of winning the prize but to further experiment with optimizing my site. (Web performance is a passion of mine)

Below I will breakdown the before & after statistics of my personal site and what changes I made in great detail.

I will be using both my homepage and the image-heavy article I recently wrote, The Death of Personality, as the basis for my tests.

Lighthouse Score - Homepage

Full source original stats // Full source updated stats

+ + + + + + + + + + + + + + + + + + + + + + + + +

Stats	Before	After
Performance	82	98
Accessibility	100	100
Best Practices	75	94

Lighthouse Score - Article Page

Full source original stats // Full source updated stats

+ + + + + + + + + + + + + + + + + + + + + + + + +

Stats	Before	After
Performance	39	96
Accessibility	97	100
Best Practices	69	94

Web Page Test - Homepage

Full source original stats // Full source updated stats

+ + + + + + + + + + + + + + + + + + + + + + + + +

Stats	Before	After
Initial Load Time	0.91s	0.41s
Visually Complete	0.9s	0.7s
Fully Loaded	0.94s	0.65s

Web Page Test - Article Page

Full source original stats // Full source updated stats

+ + + + + + + + + + + + + + + + + + + + + + + + +

Stats	Before	After
Initial Load Time	4.7s	0.5s
Visually Complete	3.1s	0.8s
Fully Loaded	4.8s	0.67s

Quick Look

Though my homepage only made some minor speed performance enhancements, my article post's initial load time was slimmed down by a whopping 4.2 seconds! That's pretty incredible and very noticeable from an end-user's perspective.

So - What Changed?

Webfonts

I'm not using any webfonts but instead defaulting to the user's OS System Fonts. I love custom typefaces but performance takes just too much of a hit on my personal site to bother with them.

body {
+font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen,Ubuntu,Cantarell,"Open Sans","Helvetica Neue",sans-serif,"Sans Serif",Icons;
+}
+

For reference, there are some things you should to look out for when using custom typefaces:

Readability and accessibility
Possible extra overhead loading in a custom @font-face
Try to avoid any FOUT, FOIT, FOFT
Don't go down the rabbit hole of using 3rd party plugins to optimize something as basic as a typeface

Critical CSS

This part was easy. In order to avoid the weird styling 'pops' present on some websites when initially loading with slow connections, it's best to place all your most critical styling inline and then load your external CSS once everything else has loaded.

On top of that, I decided to also implement Filament Group's loadCSS function to load my CSS asynchronously. If you are not currently using this in any of your projects; stop reading this and go do it! It's a game changer.

Critical JavaScript

My personal site only uses a small amount of JavaScript on the article post Jekyll template pages. By using the defer property I can be sure to load the IntersectionObserver API polyfill after the rest of the DOM as finished loading.

<script src="https://cdn.polyfill.io/v2/polyfill.min.js?features=IntersectionObserver" defer>
+

I could probably optimize this further by only calling these scripts if an image is actually present in the article post, but this fits my needs nicely as is.

Responsive Images

The only images I use are those included in supported blog posts, so the first step was making sure to only call iolazy.min.js on those specific template pages. The next step was defaulting to webp image formats with a lossless jpg fall-back with the help of the picture element:

I've also included responsive image sizes for further optimization based on screen size and loading speeds.

<figure>
+<picture
+    <source type="image/webp"
+    data-srcset="
+    /images/articles/webp/flat-design-toggles_p0v2hv_c_scale,w_200.webp 200w,
+    /images/articles/webp/flat-design-toggles_p0v2hv_c_scale,w_1400.webp 1400w"
+    class="lazyload"/>
+    <img
+    sizes="(max-width: 1400px) 100vw, 1400px"
+    data-srcset="
+    /images/articles/flat-design-toggles_qfre51_c_scale,w_200.webp 200w,
+    /images/articles/flat-design-toggles_qfre51_c_scale,w_727.webp 727w,
+    /images/articles/flat-design-toggles_qfre51_c_scale,w_1065.webp 1065w,
+    /images/articles/flat-design-toggles_qfre51_c_scale,w_1400.webp 1400w"
+    src="/images/placeholder.webp"
+    alt="Toggles Comparison"
+    class="lazyload"/>
+</picture>
+</figure>
+

What about users with JavaScript disabled I hear you ask? It's time for noscript to save the day:

<noscript>
+    <picture>
+        <source type="image/webp"
+        srcset="
+        /images/articles/webp/flat-design-toggles_p0v2hv_c_scale,w_200.webp 200w,
+        /images/articles/webp/flat-design-toggles_p0v2hv_c_scale,w_1400.webp 1400w">
+        <img
+        sizes="(max-width: 1400px) 100vw, 1400px"
+        srcset="
+        /images/articles/flat-design-toggles_qfre51_c_scale,w_200.webp 200w,
+        /images/articles/flat-design-toggles_qfre51_c_scale,w_727.webp 727w,
+        /images/articles/flat-design-toggles_qfre51_c_scale,w_1065.webp 1065w,
+        /images/articles/flat-design-toggles_qfre51_c_scale,w_1400.webp 1400w"
+        src="/images/articles/flat-design-toggles_qfre51_c_scale,w_1400.webp"
+        alt="Toggles Comparison"/>
+    </picture>
+</noscript>
+

HTTPS & Caching

The Lighthouse audit also suggested implementing an SSL certificate (something I've been meaning to do for a while anyway) and also utilize CDN caching. So it was Cloudflare to the rescue!

Since my website is hosted through Github, setting up a free SSL certificate and enabling site-wide caching was a breeze. If you're interested in setting this up yourself, step-by-step instructions can be found here.

This simple update helped boost my best practices score from a 69 to a 94. Yet another performance enhancement you should be enabling for all your current and future projects!

Performance Happiness

Overall I'm pretty content with the major performance boost my site has received from these fairly minor updates and I hope this article inspires other designers and developers to jump into updating their own site/app performance speeds. The pay-off is truly worth it!

Some Extra Reading Material

Web Performance in Action by Jeremy Wagner
Responsible Responsive Design by Scott Jehl
Designing with Progressive Enhancement: Building the Web that Works for Everyone by Todd Parker, Scott Jehl,‎ Maggie Costello Wachs,‎ Patty Toland

CSS Character Unit

2019-04-23T10:00:00Z

CSS Character Unit

2019-04-23

When it comes to proper readability with large portions of text, the golden standard is to have no more than 75 characters per line. This is easy to achieve in the world of print but on the responsive, ever-changing web - statically defined typography becomes a little more difficult.

You could go through the long process of setting up media queries for every possible screen size, adjusting text size and padding accordingly - but there is a better way.

Introducing character units

By setting your main containers or text elements with the CSS character unit (ch), you need to set the character length only once. Let's look at a simple example for reference.

Let's say you have an article which will fill the entire length of the screen. Something like this:

<div class="container">
+    <p>Reprehenderit aliqua in quis eiusmod ea culpa aliquip. Velit duis est irure voluptate occaecat labore laborum ut pariatur ex veniam deserunt esse est. Esse sunt exercitation id reprehenderit deserunt elit commodo sit ullamco amet commodo magna consequat. Excepteur voluptate tempor consectetur eu aliqua aliquip laboris aliquip veniam excepteur labore.</p>
+    <p>Voluptate excepteur sint magna ipsum occaecat irure sit. In occaecat excepteur in id ullamco id est incididunt irure et. Consectetur veniam exercitation occaecat exercitation labore nulla excepteur irure ex anim. Commodo sint anim non ad excepteur exercitation eiusmod Lorem nisi. Tempor ut ipsum do adipisicing dolore.</p>
+</div>
+

With this structure, you might normally set the default max-width property with your desired maximum width (whatever you believe is the best reading length):

.container {
+    max-width: 38em;
+}
+

This works - but it isn't ideal. Time for character units to save the day! You will still target the max-width property but this time we set it to use the ch value like so:

.container {
+    max-width: 66ch;
+}
+

This setting makes sure content will not exceed more than 66 characters per line, making for a better reading experience with little effort.

Browser support

The character unit attribute has pretty great support - even partial IE11! Check out the supported browsers here.

Browser History Sucks

2019-04-20T10:00:00Z

Browser History Sucks

2019-04-20

Have you ever needed to step back through your browser history to find a particular site or product? Do you remember that experience being good? Most likely not.

Much like printers, the design of browser history interfaces hasn't changed in years. This would be fine if these UIs had been well thought out and optimized for an easy user experience - but they weren't.

Browser history views rely on the user's own memory for more in-depth searches. This defeats the whole purpose of having a robust, documented history. The browser should be doing this heavy-lifting.

What browsers get wrong

Modern browsers give the general public too much credit when it comes to memory (I don't mean this as an insult!). To assume users remember the URL or site name when browsing random pages is short-sighted. I find myself asking these types of questions when jumping back into my view history far too often:

"That article had something to do with CSS..."
"I remember seeing a beautifully designed site a month ago but have no clue what the URL was..."
"My browser crashed and I can't recall that [example website] I had pinned in my tab for weeks..."

For reference, let's take a look at the current Chrome (73) history view:

As you may have noticed - this UI is lackluster at best. An oversimplified search field in the header is the only means of filtering items.

Why not use extensions?

I know using browser extensions or tagging favorites can alleviate some of these issues. This is great, but why not simplify everything by having these features inside the history view? If an extension can add these features, why not have those extras built-in?

Two subtle improvements

A little goes a long way. With just two small changes, we can drastically increase the history view's UX.

We start by adding a date picker. Users open the new calendar icon to filter by days, months or years before searching. Seems trivial, but this saves the headache of filtering through all saved history.

The second small functional change we can make is including extra subcategories. These new options allow users to focus their searches based on:

Session length
Number of return visits
Last restored tabs

Session length

Allow users to display their history filtered by session duration. This helps when searching for an stagnant page or pinned site during a user's long session. An example default would allow filtering by:

longest to shortest
shortest to longest
pinned tabs

Return visits

When users make repeat visits to a site or web app, the browser should keep a record of return sessions. This allows the user to refine their search by many or singular visits.

Last restored tabs

A basic concept, but the ability for users to view all previous instances of restored tabs is helpful. This would fix most edge cases not covered by the other two categories.

Far from perfect

The Chrome (or any browser for that matter) browser history view is simplistic to a fault. The current UI is prone to human error, since it makes assumptions and relies heavily on user memory.

These are simple fixes that attempt to boost the basic UX of the history view. Are these concepts absolutely perfect? Not at all. Is it at least an improvement? I believe it is. When products decrease the effort required of it's users, I see that as a positive.

Bidirectional Scrolling: Why Not Both?

2020-11-09T10:00:00Z

Bidirectional Scrolling: Why Not Both?

2020-11-09

I recently came across Adam Silver's post about the merits and pitfalls of bidirectional scrolling and found myself conflicted with the design arguments put forth in the article. It's a very good article overall, and I suggest giving it a read before digging deeper into my post here.

The Premise

The original article argues that displaying page content via horizontal scrolling (and therefore slightly hiding interactive content) creates a few major issues:

it increases the chance users won't see it
there's a greater reliance on digital literacy
it's generally more labour intensive for users

Adam also makes a solid statement here:

Having to scroll down and across in a zig zag fashion can be tiresome, especially for people with motor impairments.
+

But I don't believe these issues create a need to completely remove the horizontal "scrolling" design altogether. You can still implement the See All Items category link, while allowing the horizontal content to load in dynamically. Balance is always key.

Not All At Once, Please!

So what exactly do I mean by dynamically loading in horizontal content?

The user is shown the top 4 items in a given category
From there, the user can use the See All Items link to jump into a full category page
If they so desire, they can begin scroll horizontally in a given category row +
- Once they reach the end of the row, 4 more items will load in automatically to expand the list
- To avoid a never-ending list, it might be best to limit total row items to ~20 items. At this point the UI could prompt the user to View All Items in that category.
+

By loading the row content in piece-by-piece, initial loads for users will be faster and subsequent list items will load quickly as well (since they would limit to a set default - in this case only 4).

Final Improvements

Below you can find a quick, static version of this concept. Here you can see the horizontal list items, along with their corresponding See All Items links. You'll have to use your imagination for how new items would load once you each the end of a horizontal row. (I'm too lazy to spend extra time building out that functionality for a hypothetical blog post)

Live CodePen Example

Better Box Shadows

2019-01-08T10:00:00Z

Better Box Shadows

2019-01-08

Box shadow on HTML elements has been widely supported across most browsers for a while now, but I find the default options don't allow for much visual manipulation of the shadows in general.

Let's take a look at a default configuration of box-shadow:

.box-container {
+    box-shadow: 0 4px 8px rgba(0,0,0,0.3);
+}
+

In the example above the first property number is the origin of the x-axis, the second number is the origin of the y-axis and the third is the amount of blur.

We should also add some minimal styling to cleanup the .box-container a little bit for our example:

<div class="box-container"></div>
+

.box-container {
+    box-shadow: 0 4px 8px rgba(0,0,0,0.3);
+    /* Styles to make it less ugly */
+    background: white;
+    border-radius: 10px;
+    border: 1px solid #eee;
+    height: 200px;
+    padding: 10px;
+    position: relative;
+    width: 250px;
+}
+

Which would render as this:

Not bad - but we can do a lot better than this.

Please sir, I want some more (depth)

We just need to add a simple child div (or use a pseudo element if you prefer) inside our main element we want to apply the shadow to:

<div class="box-container">
+    <div class="box-container-inner"></div>
+</div>
+

Now we make our inner child element absolute and set it's height and width dynamically to be slightly smaller than it's parent (percentages work best for this).

Remember to set this child element behind it's parent by adding z-index: -1.

.box-container {
+    /* No box-shadow needed on this element anymore */
+    /* Styles to make it less ugly */
+    background: white;
+    border-radius: 10px;
+    border: 1px solid #eee;
+    height: 200px;
+    padding: 10px;
+    position: relative;
+    width: 250px;
+}
+

Inner Containers

We also need to target the box-container-inner element set inside the current parent to reflect our custom shadow styling:

.box-container-inner {
+    bottom: 0;
+    /* The box-shadow is added here now */
+    box-shadow: 0 4px 12px rgba(0,0,0,0.3);
+    height: 94%;
+    left: 3%;
+    position: absolute;
+    width: 94%;
+    z-index: -1;
+}
+

Which will make the drop-shadow render with a little more realistic depth:

But wait - there's more!

We could stop now and have a decent drop-shadow that is certainly easier on the eyes - but we can make this even better with one extra property - filter:blur();.

So your final code would look like this:

.box-container {
+    /* Styles to make it less ugly */
+    background: white;
+    border-radius: 10px;
+    border: 1px solid #eee;
+    height: 200px;
+    padding: 10px;
+    position: relative;
+    width: 250px;
+}
+
+.box-container-inner {
+    bottom: 0;
+    box-shadow: 0 4px 12px rgba(0,0,0,0.3);
+    filter: blur(6px);
+    height: 94%;
+    left: 3%;
+    position: absolute;
+    width: 94%;
+    z-index: -1;
+}
+

Which renders out into a much smoother blend of a drop-shadow, creating a more realistic illusion of depth:

+ +

Hosting with Codeberg Pages

2022-07-29T10:00:00Z

Hosting with Codeberg Pages

2022-07-29

I recently switched the pblog project repo over from Sourcehut to Codeberg (mostly for UX reasons) and it got me looking into Codeberg Pages. It seemed like a cleaner approach to host my personal blog on the same platform I planned to also share the source code.

I decided to share the setup process here since I couldn't find a straightforward guide explaining everything required to get going. So, let's dig in.

Create the Repos

Disclaimer: My personal blog uses pblog, so although these instructions will be catered towards that SSG the same concept should apply for any other generator (Jekyll, Hugo, Next, etc.).

The first step is to create the main repo that would house the core files of pblog. Then we need to make a separate repo simply called pages. This second project is where all the generated "static" files get rendered.

Side note: Be sure to at least include a README file in that pages repo. This will avoid any errors or warnings when setting up our submodules in the next steps.

Configuration Edits

Once your two repos are created, you will need to make some minor edits to the _config.sh in the core pblog project to tell the build script where the generated files should go (in this case the pages repo):

OUTPUT="_output/pages/"
+

The Submodule

Using terminal, navigate to the _output/ directory in your core pblog project. Run the following, remembering to replace the USERNAME parameter with your own:

git submodule add git@codeberg.org:USERNAME/pages.git
+

If everything worked correctly you should now have a .gitmodules file in your main pblog project. If you get any errors, you might need to include the name of the directory at the end of the command:

git submodule add git@codeberg.org:USERNAME/pages.git pages
+

The Workflow

Now you can make changes, add new posts and pages in the main pblog project and have those generated files render into your other pages repo. For this workflow, I simply push commits to both projects when I am happy with my changes but I'm sure you could look into automating this process (ie. a single push from the pblog repo forces a the pages repo to also update).

Now you can navigate to the standard Codeberg Pages URL to see it in action:

USERNAME.codeberg.page
+

If you want to use your own custom domain (who doesn't?) then continue reading.

Custom Domains (Optional)

The first thing you will need to do is add a .domains file to your pages root directory. In this file you will want to list your custom domain on the first line, followed by the standard Codeberg pages URL below it. Like so:

yourcustomdomain.com
+USERNAME.codeberg.page
+

I'm keeping this very basic, but I suggest you look further into the official documentation if there are any extra settings you'd like to tinker with.

The final step is configuring a CNAME DNS setting through your registrar:

@ -> USERNAME.codeberg.page
+

Give the DNS settings a bit of time to take (24-48 hours) and you'll have your custom domain working just fine.

Happy hosting!

Being More Efficient as a Designer and Developer

2019-09-28T10:00:00Z

Being More Efficient as a Designer and Developer

2019-09-28

I recently began working on a small side project (a marketing site / blog for an upcoming UX book I'm writing, but I have nothing to promote yet - sorry) and found myself circling around different static site generators (SSG) in the initial design concepts. The thought of learning an entirely new blogging platform was inspiring and seemed like a good excuse to expand my skillset.

Although I've used 11ty and Hugo in the past for client work, this personal website runs on Jekyll. I'm very familiar with Jekyll and can push out a point-of-concept site in a flash with little-to-no effort. So, why was I looking to jump into a SSG I hadn't used before?

And that got me thinking... Why am I moving away from being efficient?

Before we begin...

I should preface everything else I'm going to mention in this post with this: learning new stuff is awesome. You should expand your knowledge as much as you can, no matter what industry you find yourself in. I've found it to be a great catalyst for boosting my passion in design and development.

Okay, I've made it clear that learning is important to the growth of your career - so please keep that in mind before you read my next statement:

Just use what you already know.

By using your current experience (maybe even expertise) with a design system, CSS framework, blogging platform, programming language, etc. you can get something built. Not to mention you can get that thing built in a fraction of the time. After all, building things is kind of the point of being a designer (or developer), right?

My current side project may be a slight edge case in this regard. Since it's a personal "dev" website, most of the tech stack choices comes down to personal preference - not client requirements. But I believe my point still remains: you shouldn't reach for something new and shiny just because it's new and shiny.

Some vague examples

It might be easier to understand what I mean by using some possible real-world examples:

+ + + + + +

Problem	New Way	Efficient Way
A local bakery needs product and e-cart functionality	Learn a new custom ecommerce platform	Use a popular pre-existing library you're familiar with
Create an add-on blog for a medical clinic	Try a custom built static site generator and hook in a git-based CMS	Spin up a quick WordPress site and hand-off
UI mockups for a workout iOS app	Test out the newest design tool just released	Use your go-to default design tool you (Sketch, Figma, etc)

I know all of this is very much "common sense", but you would be surprised how often we reach out for the latest and greatest tools (we are creative problem-solvers, after-all). If a current project allots you the time to learn a new skillset alongside outputting a quality product - then more power to you. In my experience that's a rare luxury, so my advice is to focus on shipping quality work (whether that's code, design, analytics, content, etc) instead of getting caught up in the "new and shiny".

But wait, how / when do I learn new things?

It isn't exactly ground breaking to state that you should keep things simple as a developer. There are probably hundreds of posts on the web advocating for the exact same thing - which is good. At the same time, we as designers and developers need to avoid stagnation - something that can happen all too easily.

So how do we learn new things? This is a hard thing to answer. Really, the best response would be: it depends on the designer / developer. I know, what a cop-out. Unfortunately, it's true. There is no one solution to learning anything new.

The best I can do is offer up some possible options:

Learn outside of work
+ +
- Reading / listening to a technical book on your commute or before bed
- Take an online course you can work on after hours
+
Contribute to an open source project that you aren't familiar with but are interested in
+ +
- Even tiny contributions go a long way, don't doubt yourself so much
+
Ask your current company (if not a freelancer that is) to learn on their time
+ +
- It's a valid argument that your company should have vested interest in you becoming a better developer / designer
+

Easier said than done

Sometimes, even the suggestions above don't work for certain individuals. Life is hectic and other important things can pop-up taking precedence. Don't let it get you down - there are more important things in life than mastering the newest framework that released 25 minutes ago.

My motto is to keep shipping quality products that you actually give a shit about. Otherwise it doesn't matter how "new" it is.

Improving Laptop Battery Performance on OpenBSD

2023-06-13T10:00:00Z

Improving Laptop Battery Performance on OpenBSD

2023-06-13

It is no secret that OpenBSD has poor battery performance on laptops. Although not as impressive as something like Alpine Linux or FreeBSD, you can tweak OpenBSD just enough to squeeze more life out of your machine's battery.

Our New Best Friend: `ampd`

I won't go into great detail about ampd here - that's what the incredible documentation is for. You'll want to make sure to start it before trying to configure it:

doas rcctl start apmd
+

If already running in a live session, you can default to -A (auto) but I suggest setting cpu performance to low:

apm -L
+

To make these changes permanent on boot:

doas rcctl set apmd flags -L
+

Optimizating battery life via ampd will have the most noticable impact but you can improve things even further by implementing some extra "small" performance wins.

Small Performance Wins

Reduce your screen's brightness (xbacklight -set 50)
Use a lightweight window manager instead of a beefer desktop environment
Enable battery saving options in your system BIOS (if available)
Disable the fingerprint scanner and bluetooth in your system BIOS (if available)
Use utilities such as mpv and ffmpeg for media consumption
Reduce the number of open applications at any given time

Batch Converting Images to webp with macOS Automator

2021-10-15T10:00:00Z

Batch Converting Images to webp with macOS Automator

2021-10-15

A great deal of my time working as a web/UI designer is spent exporting and/or converting images for software products and websites. Although a lot of modern applications can render image conversions at build time, a custom conversion is sometimes requested for an image to be set as webp.

You could download one of the many native apps from the Mac App Store to do this for you - but why not create your own script and run it with a simple right-click directly inside Finder? Let's do just that!

Basic requirements

Important!: As of this time of writing, the official libwebp package release is libwebp-1.2.1-mac-10.15. If this has been updated since then, change the command below to match that of the proper release version.

1) First you will need to download the libwebp package to your Downloads folder: developers.google.com/speed/webp/download + - Look for the "Download for macOS link"

2) Next we will need to copy the cwebp folder to our /usr/local/bin directory: + - Open macOS Terminal + - Run sudo cp /Downloads/libwebp-1.2.1-mac-10.15/bin/cwebp /usr/local/bin + - Note: if the /usr/local/bin directory doesn't exist, simply create it by running: sudo cd /usr/local && mkdir bin

Creating our custom Automator script

1) Open the macOS Automator from the Applications folder

2) Select Quick Option from the first prompt

3) Set "Workflow receives current" to image files

4) Set the label "in" to Finder

5) From the left pane, select "Library > Utilities"

6) From the presented choices in the next pane, drag and drop Run Shell Script into the far right pane

7) Set the area "Pass input" to as arguments

8) Enter the following code below as your script and type ⌘-S to save (name it something like "Convert to webp")

for f in "$@"
+do
+/usr/local/bin/cwebp -q 85 "$f" -o "${f%.*}.webp"
+done
+

For visual reference, it should look something like this:

+ +

(link to hi-res image)

And when right-clicking an image file in the Finder window, it should now give you the option to convert:

+ +

(link to hi-res image)

Making edits to your script

If you ever have the need to edit this script (for example, changing the default 85 quality parameter), you will need to navigate to your ~/Library/Services folder and open your custom webp Quick Action in the Automator application.

Simple as that!

Possible Hiccups

I was contacted by the very helpful Kev Quirk about a minor problem he encountered while following this tutorial. When trying to run cwebp he received the following error message:

cwebp cannot be opened because it's from an unverified developer
+

Doing the next steps seemed to have fixed this issue for him:

Click on the "Open in Finder" in the error message prompt
Double-click on the cwebp utility to open in Terminal
You'll then be prompted with a pop-up asking if you wish to execute

After following these steps, the issue should be resolved.

Basic Gulp Build for Sass

2019-01-15T10:00:00Z

Basic Gulp Build for Sass

2019-01-15

Some designers might shy away from build tools when first starting out and I can understand the reasoning - task runners like gulp and grunt can seem daunting at first. So, I've decided to showcase my go-to setup for gulp and explain what the heck it does step-by-step.

Here is the final gulp.js file in all it's glory:

var gulp = require('gulp');
+var shell = require('gulp-shell');
+var sass = require('gulp-sass');
+
+/* Build and watch Jekyll (change this task to whatever you need) */
+gulp.task('generate', shell.task('jekyll serve'));
+
+/* Compile SCSS files to CSS */
+gulp.task('styles', function () {
+    return gulp.src('_includes/assets/sass/styles.scss')
+        .pipe(sass({
+            outputStyle: 'compressed'
+        }).on('error', sass.logError))
+        .pipe(gulp.dest('_includes/assets/css/'));
+});
+
+/* Compile the assets */
+gulp.task('assets', gulp.parallel(
+    'styles'
+));
+
+/* Build */
+gulp.task('build', gulp.series(
+    'assets',
+    'generate'
+));
+

Trust me, it's not complicated at all.

Grabbing what we need

For our basic build file we are going to need only three modules: gulp, gulp-shell and gulp-sass.

var gulp = require('gulp');
+var shell = require('gulp-shell');
+var sass = require('gulp-sass');
+

gulp

This is the streaming build system, without it we can't do anything else.

gulp-shell

A gulp command line interface for us to interact with our terminal.

gulp-sass

Required for gulp to compile Sass into vanilla CSS.

Bonus tasks

You can also toss in gulp-minify to clean-up any JavaScript you might be using, but for this example we're just going to keep things simple and focus on Sass only.

Maybe I'll write about my js build workflow in a future article.

Generating the build

Our first step is to create the default task that will generate our build. In this example we are making the assumption that we're building a Jekyll website (but you can place any build command here):

gulp.task('generate', shell.task('jekyll serve'));
+

Don't worry if this generate isn't clear, we come back to that later.

Processing our pre-processor

We will name this next task styles since that's what it outputs - our styling. We start by telling gulp where our main scss directory is:

/* Change this directory to match yours */
+return gulp.src('_includes/assets/sass/styles.scss')
+

This next piece tells the plugin to compress our final compiled CSS, log any errors if there are issues with the build and then export it to our destination directory:

.pipe(sass({
+    outputStyle: 'compressed'
+}).on('error', sass.logError))
+

/* Change this to your destination directory */
+.pipe(gulp.dest('_includes/assets/css/'));
+

Building our assets

This step isn't 100% needed, but I like to include it for when more assets need to be added (minifying JavaScript, compressing images, etc)

/*
+Compile the assets
+*/
+gulp.task('assets', gulp.parallel(
+    'styles'
+));
+

Altogether now!

Now we add a task that runs all other tasks in our gulp file (in this case it will run both assets and generate)

/*
+Build
+*/
+gulp.task('build', gulp.series(
+    'assets',
+    'generate'
+));
+

And that's it - we're done! A very basic gulp build for compiling Sass.

Base64 All The Things! (Sometimes)

2020-03-18T10:00:00Z

Base64 All The Things! (Sometimes)

2020-03-18

An extremely overlooked process for displaying fonts, images, documents, spreadsheets, etc. on the web is the use of base64 encoding. Although it may not be the most efficient (or easy) way to display and include these elements it can be a lifesaver in certain situations.

What is base64 encoding?

It might be common knowledge, but I think breaking down exactly what base64 encoding is could be very helpful to beginner web developers:

+
Base64 is a group of binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation.
+ - Wikipedia +

In simpler terms: it is a encoded format that can change an element like this:

<img src="/path/to/image.webp" alt="Cool image">
+

Into this:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAABkAAAASwCAYAA...PnyMAAAAASUVORK5CYII=" alt="Cool image">
+

See it in action

+ +

This image is pulled in with an HTTP request (direct link to image)

+ +

This image is an inline base64 encoding

Should I use base64?

That completely depends on the situation. For most regular day-to-day web development - probably not. While base64 is useful, it is slightly less per-formant than directly using a source file (though, one could argue that making the extra browser request is less per-formant as well).

But that doesn't mean there aren't a few edge cases.

The speed of rendering the encoding out-performs the extra HTTP request
You only have access to a single set of specific HTML files (no access to current font, CSS or image directories)
Security issues that limit your ability to use external sources altogether

How do I encode my files?

There are a ton of freely available encoders out in the wild web, but my personal go-to is base64converter.com. Simply upload your file and convert.

Limitations

Images converted to base64 will be 20-25% larger in size (making for poorer performance on mobile for image-heavy websites)
Lacking any consistent use of CDN caching
Larger encodings can make for messy project files (unless run at build time of course)

Though these limitations can be deal-breakers in certain situations, I find it extremely helpful for developers to keep base64 encoding in their back pockets for a rainy day.

A Warning for New Designers: Avoid Dribbble

2022-09-08T10:00:00Z

A Warning for New Designers: Avoid Dribbble

2022-09-08

Everyday a new designer begins their journey into the world of [insert design industry here] and it is magical! Having a fresh pair of eyes untainted from the current trends of the time can help improve design as a whole. Newbies can even teach new things to older, grumpier luddites (like yours truly). But over the years I've noticed a concerning trend among junior designers; they rely too heavily on Dribbble.

Relying on Dribbble for minor inspiration is one thing. Referencing "shots" as justification for real-world design work? Not so much. I believe Dribbble shouldn't be used for either of these use cases, but I can at least give a pass at browsing for basic inspiration (colors, padding, layout).

Now, using concept shots to push for your own design decisions? That is a terrible idea. We "senior" designers need to step up and help newbies avoid this trap.

Designing for Other Designers

Dribbble is rarely a place for design feedback and discussion anymore. Hell, most people use it as a digital portfolio to share with prospective clients. Others use it like some form of "design Linkedin", which has its own host of problems.

Dribble is now (mainly) a place where designers post "work" for other designers. There is a small minority of users still looking for real, human feedback on their work - but they are a rarity.

Take a look at the popular shots category at any give time. Most shots are promo pieces used to attract potential clients. Nearly all design concepts are impractical or simply impossible to create in a real-life setting. This is incredibly damaging to newcomers trying to learn "good" design practices. Dribbble shots simply ride the wave of the current trends, which doesn't provide junior designers with a solid foundation or core understanding of design as a whole. It just causes them to endlessly chase the "latest and greatest" trend.

Shot posters rarely go into the reasoning behind their design decisions. No research or iterations are shared to show the process. Instead it simply states "here is a cool website layout for a company that doesn't exist". Zero constraints or goals needed to be met. No discussion about how one version of their design didn't perform as well when tested on real users. So of course it ends up looking so cool and original - it wasn't designed in reality.

I Don't Have All the Answers - But I'll Try

I am not the holy savior of all things design. I'm just a designer who has been around the block a few times. If new designers want to keep using Dribbble as their main source of guidance and think I should go kick rocks - that's fine. I will. But for those with a little more passion for the profession, might I suggest some humble alternatives to get you on a more consistent path?

Read some good design books (to get you started): +
+
Talk to real people +
- Chat with your team's marketers, customer support specialists, senior design leads, and developers about new features (they often have better insights than you)
- Perform customer interviews early and often (they use your product or service - let them tell you what they want!)
+
R ad through some quality UX reports and research +
- Nielsen Norman Group
- Baymard Institute
+
P y attention to real world design (good and bad) +
- Grocery item designs, labels packaging
- Vehicle analog and digital dashboards / safety features
- Warning and safety labeling (great for universal and minimal design inspiration)
- Government websites and applications (notoriously terrible - great for "what not to do" examples)
+
Your own experience (over time)

These are just my own suggestions to help new designers get a better foundation of core design concepts before falling down the Dribbble hole. Take it or leave it. I'm not your dad.

Most designers who are pro-Dribbble will most likely write me off as a grumpy old man yelling at a cloud. That's only half true. But if just one person reading this even considers avoiding Dribbble as a source for learning proper design - then it was worth it.

Now if you will excuse me, there are many more clouds to yell at...

Aqua UI CSS Buttons

2016-06-28T10:00:00Z

Aqua UI CSS Buttons

2016-06-28

Though it may feel like nostalgia, the old OS design for Mac was arguably better than the current iteration (as of this writing - High Sierra). I recently designed a quick Dribbble shot showcasing how the older operating system used to have so much more character and depth.

+ +

My initial Dribbble shot, which can be found here.

Since I've been wanting to dip my toes into more tutorial-based articles (maybe I'll even do some screencasts in the future), I decided to start out simple. Let's walk through how to implement these 'aqua' UI buttons with pure CSS.

Starting with a basic foundation

Since this project consists of only two buttons elements, the HTML or skeleton of this project is very straightforward:

<button class="cancel">Cancel</button>
+<button class="confirm">Confirm</button>
+

Styling the buttons

The first step is to remove the browser's default button styling by using the appearance property. This will help avoid having to fight against the browser and minimize our CSS code.

button {
+    -webkit-appearance: none;
+    -moz-appearance: none;
+}
+

Next, we apply a fairly simple set of CSS that will be shared across both the confirm and cancel buttons:

(Pay attention to the transition property as we will be returning to that shortly)

button {
+    -webkit-appearance: none;
+    -moz-appearance: none;
+    border: 1px solid #ccc;
+    border-radius: 125px;
+    box-shadow: inset 0 13px 25px rgba(255,255,255,0.5), 0 3px 5px rgba(0,0,0,0.2), 0 10px 13px rgba(0,0,0,0.1);
+    cursor: pointer;
+    font-family: 'Lucida Grande', Helvetica, Arial, sans-serif;
+    font-size: 2rem;
+    margin: 5rem 1rem;
+    padding: 1.2rem 4rem;
+    position: relative;
+    transition: all ease .3s;
+}
+

Then we separate the specific confirm and cancel button styles into their own class selectors:

button.confirm {
+    background: #4A90E2;
+    border-color: #3672B6;
+    color: #fff;
+}
+

button.cancel {
+    background: #D0D0D0;
+    border-color: #B8B8B8;
+    color: #6F6F6F;
+}
+

Playing with pseudo elements

Now that the button is styled and structured with basic formatting, it's time to add that classic 'shine' seen in the original Dribbble shot.

The cleanest way to do this is by using the :before pseudo element paired with a linear-gradient background.

button:before {
+    background: linear-gradient(rgba(255,255,255,1) 0%, rgba(255,255,255,0) 100%);
+    border-radius: 125px;
+    content:'';
+    height: 50px;
+    left: 4%;
+    position: absolute;
+    top: 1px;
+    transition: all ease .3s;
+    width: 92%;
+}
+

Adding interaction

The final step is adding the user hover interaction: (Remember that transition property?)

button:hover {
+    box-shadow: inset 0 13px 25px rgba(255,255,255,0.8), 0 3px 5px rgba(0,0,0,0.2), 0 10px 13px rgba(0,0,0,0.2);
+    transform: scale(1.02);
+}
+

That's it!

See it live on CodePen

You can view this project on CodePen here.

Feel free to fork it or implement your own!

Audio Hotkeys on Linux Mint

2020-06-14T10:00:00Z

Audio Hotkeys on Linux Mint

2020-06-14

I recently switched out the OS on my old 2011 MacBook Air with Linux Mint. It's a distro I've used a few times in the past, but never set it as one of my main daily drivers until now.

Setting up all my go-to applications (Sublime, LocalWP, Riot, Evolution, etc) was a breeze. The only snag I ran into was properly setting up the volume shortcuts on my wireless Logitech MK235 keyboard. After looking a little too long on DDG & even Google, I finally found this forum thread with the solution.

For my own personal reference, I'm also going to include those code snippets here since you never know when you might need it again! And who knows, maybe this will help someone else stumbling around the internet.

// Volume Up
+pactl set-sink-volume @DEFAULT_SINK@ +5%
+

// Volume Down
+pactl set-sink-volume @DEFAULT_SINK@ -5%
+

// Toggle Mute
+pactl set-sink-mute @DEFAULT_SINK@ toggle
+

Animated Radio Tab Toggles

2021-01-05T10:00:00Z

Animated Radio Tab Toggles

2021-01-05

In this demo tutorial, we are making the assumption that we need to create a radio slide toggle for our made-up payment options. For this we want to display 3 simple payment choices to the user:

One-time payment
Recurring payment
Free tier payment

The Final Demo

Live CodePen

Let’s get started with the base skeleton.

The HTML

There isn't anything special happening here. We just contain all our labels and inputs into a .radio-toggles wrapper, make sure those labels are each properly connected to their corresponding inputs, and then add an empty .slide-item element (more on that later).

<div class="radio-toggles">
+    <input type="radio" id="option-1" name="radio-options">
+    <label for="option-1">One-Time</label>
+    <input type="radio" id="option-2" name="radio-options" checked>
+    <label for="option-2">Recurring</label>
+    <input type="radio" id="option-3" name="radio-options">
+    <label for="option-3">Free</label>
+    <div class="slide-item"></div>
+</div>
+

The CSS

Now for the main event – the CSS. First we want to style the wrapper that holds all of our pieces together. You can tweak this to your liking, but I prefer a simple and clean style:

.radio-toggles {
+    align-items: center;
+    background: #eee;
+    border: 1px solid lightgrey;
+    border-radius: 9999px;
+    display: flex;
+    justify-content: center;
+    margin: 20px auto;
+    max-width: 400px;
+    overflow: hidden;
+    padding: 4px;
+    position: relative;
+}
+

Next, we “hide” (only visually) the default radio inputs:

input[type="radio"] {
+    left: -9999px;
+    position: absolute;
+    z-index: -1;
+}
+

Then we give the corresponding label elements a little spacing and breathing room:

label {
+    cursor: pointer;
+    padding: 10px 20px;
+    text-align: center;
+    width: 33.33%;
+    z-index: 2;
+}
+

Remember that .slide-item I referenced earlier? That element will be the visual “slider” that animates between the individual radio options. We style that like so:

.slide-item {
+    background: white;
+    border-radius: 9999px;
+    box-shadow: 0 2px 4px rgba(0,0,0,0.15);
+    height: calc(100% - 8px);
+    left: calc(33.33% + 4px);
+    position: absolute;
+    width: calc(33.33% - 8px);
+    transition: left .4s;
+    z-index: 0;
+}
+

You'll notice the left, height, and width properties utilize the CSS calc attributes – this just gives some much needed padding and visual clean-up to the whole tabbed interface.

For the finishing touches, we just need to tell the .slide-item where to position itself based on which radio input is currently selected:

input[type="radio"]:nth-of-type(1):checked ~ .slide-item {
+    left: 4px;
+}
+input[type="radio"]:nth-of-type(3):checked ~ .slide-item {
+    left: calc(66.66% + 4px);
+}
+

That's pretty much it! You now have a fully functional, animated toggle slider with just a set of simple radio inputs and pure CSS.

Animated Card Tiles

2019-02-27T10:00:00Z

Animated Card Tiles

2019-02-27

The design trend of using "cards" or "tiles" to display interactive sections/article headings in an app or website remains a popular choice among designers. So, let's build a set of animated cards with only HTML & CSS.

What we will be building (live demo)

This is the set of animated card tiles we will be creating:

(try hovering)

Live CodePen

The HTML

For the base skeleton of these cards we only need:

a flexbox main container to hold everything
a .card-tile parent element
the inner child element that will display on :hover
proper h4 and p tags inside that child element

<div class="card-tiles-container">
+    <div class="card-tile">
+        <div class="text-content">
+            <h4>Card Title</h4>
+            <p>Inner card content text</p>
+        </div>
+    </div>
+</div>
+

That's all that is needed - for now. We will be returning to this code shortly to add some extra classes to make our lives easier.

The CSS

First we set the main housing container to use flex so we save ourselves the headache of aligning all the cards in a nice row:

.card-tiles-container {
+    display: flex;
+    font-size: 14px;
+    margin: 20px 0;
+}
+

Next we create the default styling for our tile cards and set the transform property to scale the card on :hover:

/* Default card tile styles */
+.card-tile {
+    border: 1px solid;
+    border-radius: 10px;
+    cursor: pointer;
+    height: 150px;
+    margin: 0 10px;
+    overflow: hidden;
+    position: relative;
+    width: 33.33%;
+}
+.card-tile:hover {
+    transform: scale(1.1);
+}
+

Where are my cards?!

Don't panic if you can't visually see any card elements in your demo yet - that's to be expected. We will be styling these card elements momentarily.

Our next step is to hide the default inner text-content and only show it on hover. We achieve this by setting it's position to absolute, placing it's opacity at 0 and pushing it's z-index back to -1.

When the user hovers over a main card tile, we change the text-content values of both the opacity and z-index to 1.

/* Card tile text content */
+.card-tile .text-content {
+    background: linear-gradient(rgba(0,0,0,0.4) 0%, rgba(0,0,0,0.6) 100%);
+    bottom: 10px;
+    border: 1px solid rgba(0,0,0,0.4);
+    border-radius: 5px;
+    box-shadow: inset 0 1px 1px rgba(255,255,255,0.8), 
+                0 2px 4px rgba(0,0,0,0.5);
+    height: 65px;
+    left: 10px;
+    opacity: 0;
+    padding: 10px;
+    position: absolute;
+    width: calc(100% - 20px);
+    z-index: -1;
+}
+.card-tile:hover .text-content {
+    opacity: 1;
+    z-index: 1;
+}
+

Finally we add some minor styling for the inner header and paragraph tags:

.card-tile .text-content h4,
+.card-tile .text-content p {
+    color: #fff;
+    margin: 0;
+    text-shadow: 1px 1px 1px rgba(0,0,0,0.6);
+}
+

Don't forget mobile

We want out UI to stack the cards if users are viewing them on smaller devices:

@media(max-width: 600px) {
+    .card-tiles-container {
+        flex-direction: column;
+    }
+    .card-tile {
+        margin: 0 0 10px 0;
+        width: 100%;
+    }
+}
+

Customizing each card

Remember how I mentioned that we would be adding more classes to the original HTML? Now is the time. We will be including a simple class on each card tile to provide it's own custom coloring:

<div class="card-tiles-container">
+    <!-- `Blue` class -->
+    <div class="card-tile blue">
+        <div class="text-content">
+            <h4>Card Title</h4>
+            <p>Inner card content text</p>
+        </div>
+    </div>
+    <!-- `Orange` class -->
+    <div class="card-tile orange">
+        <div class="text-content">
+            <h4>Card Title</h4>
+            <p>Inner card content text</p>
+        </div>
+    </div>
+    <!-- `Green` class -->
+    <div class="card-tile green">
+        <div class="text-content">
+            <h4>Card Title</h4>
+            <p>Inner card content text</p>
+        </div>
+    </div>
+</div>
+

And these color classes correlate to some new CSS styling:

/* Blue Card */
+.card-tile.blue {
+    background-color: #0093E9;
+    background-image: linear-gradient(0deg, #0093E9 0%, #80D0C7 100%);
+    border-color: #0093E9;
+    box-shadow: 0 4px 12px rgba(128,208,199,0.7), 
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+.card-tile.blue:hover {
+    box-shadow: 0 8px 18px rgba(128,208,199,0.4), 
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+

/* Orange Card */
+.card-tile.orange {
+    background-color: #FAD961;
+    background-image: linear-gradient(180deg, #FAD961 0%, #F76B1C 100%);
+    border-color: #F76B1C;
+    box-shadow: 0 4px 12px rgba(247,107,28,0.7), 
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+.card-tile.orange:hover {
+    box-shadow: 0 8px 18px rgba(247,107,28,0.4), 
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+

/* Green Card */
+.card-tile.green {
+    background-color: #096e40;
+    background-image: linear-gradient(0deg, #096e40 0%, #2AF598 100%);
+    border-color: #096e40;
+    box-shadow: 0 4px 12px rgba(9,110,64,0.7), 
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+.card-tile.green:hover {
+    box-shadow: 0 8px 18px rgba(9,110,64,0.4), 
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+

Adding transitions

We can now see the actual cards visually and have the ability to interact with them, but there is a problem - they don't animate.

Lucky we can target all elements we wish to animate with the transition property, like so:

/* Shared transitions */
+.card-tile,
+.card-tile .text-content {
+    transition: .3s ease all;
+}
+

Done and done.

The final code

To make things easier for reference, I have included all the html and css below. Please feel free to use these cards anywhere you like and change them as you see fit!

HTML

<div class="card-tiles-container">
+    <div class="card-tile blue">
+        <div class="text-content">
+            <h4>Card Title</h4>
+            <p>Inner card content text</p>
+        </div>
+    </div>
+    <div class="card-tile orange">
+        <div class="text-content">
+            <h4>Card Title</h4>
+            <p>Inner card content text</p>
+        </div>
+    </div>
+    <div class="card-tile green">
+        <div class="text-content">
+            <h4>Card Title</h4>
+            <p>Inner card content text</p>
+        </div>
+    </div>
+</div>
+

CSS

.card-tiles-container {
+    display: flex;
+    font-size: 14px;
+    margin: 20px 0;
+}
+/* Shared transitions */
+.card-tile,
+.card-tile .text-content {
+    transition: .3s ease all;
+}
+/* Default card tile styles */
+.card-tile {
+    border: 1px solid;
+    border-radius: 10px;
+    cursor: pointer;
+    height: 150px;
+    margin: 0 10px;
+    overflow: hidden;
+    position: relative;
+    width: 33.33%;
+}
+/* Blue Card */
+.card-tile.blue {
+    background-color: #0093E9;
+    background-image: linear-gradient(0deg, #0093E9 0%, #80D0C7 100%);
+    border-color: #0093E9;
+    box-shadow: 0 4px 12px rgba(128,208,199,0.7),
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+.card-tile.blue:hover {
+    box-shadow: 0 8px 18px rgba(128,208,199,0.4), 
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+/* Orange Card */
+.card-tile.orange {
+    background-color: #FAD961;
+    background-image: linear-gradient(180deg, #FAD961 0%, #F76B1C 100%);
+    border-color: #F76B1C;
+    box-shadow: 0 4px 12px rgba(247,107,28,0.7), 
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+.card-tile.orange:hover {
+    box-shadow: 0 8px 18px rgba(247,107,28,0.4), 
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+/* Green Card */
+.card-tile.green {
+    background-color: #096e40;
+    background-image: linear-gradient(0deg, #096e40 0%, #2AF598 100%);
+    border-color: #096e40;
+    box-shadow: 0 4px 12px rgba(9,110,64,0.7), 
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+.card-tile.green:hover {
+    box-shadow: 0 8px 18px rgba(9,110,64,0.4), 
+                inset 0 2px 1px rgba(255,255,255,0.6);
+}
+/* Card tile text content */
+.card-tile .text-content {
+    background: linear-gradient(rgba(0,0,0,0.4) 0%, rgba(0,0,0,0.6) 100%);
+    bottom: 10px;
+    border: 1px solid rgba(0,0,0,0.4);
+    border-radius: 5px;
+    box-shadow: inset 0 1px 1px rgba(255,255,255,0.8), 
+                0 2px 4px rgba(0,0,0,0.5);
+    height: 65px;
+    left: 10px;
+    opacity: 0;
+    padding: 10px;
+    position: absolute;
+    width: calc(100% - 20px);
+    z-index: -1;
+}
+.card-tile .text-content h4,
+.card-tile .text-content p {
+    color: #fff;
+    margin: 0;
+    text-shadow: 1px 1px 1px rgba(0,0,0,0.6);
+}
+/* All animations on hover */
+.card-tile:hover {
+    transform: scale(1.1);
+}
+.card-tile:hover .text-content {
+    opacity: 1;
+    z-index: 1;
+}
+@media(max-width: 600px) {
+    .card-tiles-container {
+        flex-direction: column;
+    }
+    .card-tile {
+        margin: 0 0 10px 0;
+        width: 100%;
+    }
+}
+

Adventures in Creating a Minimal Alpine Linux Installer

2022-12-08T10:00:00Z

Adventures in Creating a Minimal Alpine Linux Installer

2022-12-08

Introduction

I've made the switch to Alpine Linux as my main laptop/desktop hybrid +workstation and I love it - warts and all. This post will follow my process building my Alpine Linux "installer" I used for this workstation, along with covering some bugs I found during my adventure.

My main goals when starting this project were to have a daily driver that was:

free of any "real" desktop environment
Wayland based with SwayWM
as lightweight as possible

Overall, I think I achieved what I was aiming for. After logging in (there is no login manager, you do it directly through the boot terminal) you will see:

(You can view the full res image here)

For reference this is running on a X260 ThinkPad with 16GB RAM, docked and connected to a 27" 4K monitor.

If you'd prefer to just go straight to the installer, feel free to jump over to the project repo: https://git.sr.ht/~bt/alpine-linux-setup
+

Getting Started

My main reasoning for switching away from my previous setup (Garuda Linux running Sway) to Alpine was two fold:

I wanted a more lightweight, less resource hungry system
I wanted to go as "full" Wayland as possible

Benchmarks Comparisons

I should mention that these are not official "benchmark" applications or proper testing. I merely reproduced the same tasks, using the same applications, for the same amount of time and compared the usage. Just keep that in mind!

Garuda Linux
+ +
- SwayWM
- Firefox: 9 tabs (Figma included)
- qutebrowser: 7 tabs
- aerc: open/running
- tut: open-running
- Sublime Text: single project open
- Memory usage (range): 6.0-7.2 GB
+
Alpine Linux
+ +
- SwayWM
- Firefox: 9 tabs (Figma included)
- qutebrowser: 7 tabs
- aerc: open/running
- tut: open-running
- Memory usage (range): 1.0-3.5 GB
+

Switching over has basically cut my system memory usage in half. That ended up being a much better improvement than I predicted. These are beyond just numbers too - the system feels snappier.

So, from a speed and usability stand point I considered this a success already.

Crashes & Roadblocks

Of course, things didn't run 100% flawlessly out-of-the-box. There were some pretty annoying crashes and issues.

Greetings, tty

After installing tut I started walking through its guided setup. Once it prompted me to login via browser in order to authenticate, I clicked the link provided in the terminal. I was immediately thrown out of my session and into tty. Awesome.

I'll save you both the headache and large amount of time I wasted on this silly "bug" and just say it had to do with my user settings trying to launch "Chromium" as my default browser. I normally set qutebrowser as much default, so this was a change I needed to make anyway.

I put the following in my /etc/xdg/mimeapps.list (which is included by default with the installer)

[Default Applications]
+x-scheme-handler/http=org.qutebrowser.qutebrowser.desktop
+x-scheme-handler/https=org.qutebrowser.qutebrowser.desktop
+x-scheme-handler/ftp=org.qutebrowser.qutebrowser.desktop
+x-scheme-handler/chrome=org.qutebrowser.qutebrowser.desktop
+text/html=org.qutebrowser.qutebrowser.desktop
+application/x-extension-htm=org.qutebrowser.qutebrowser.desktop
+application/x-extension-html=org.qutebrowser.qutebrowser.desktop
+application/x-extension-shtml=org.qutebrowser.qutebrowser.desktop
+application/xhtml+xml=org.qutebrowser.qutebrowser.desktop
+application/x-extension-xhtml=org.qutebrowser.qutebrowser.desktop
+application/x-extension-xht=org.qutebrowser.qutebrowser.desktop
+image/bmp=feh.desktop
+image/gif=feh.desktop
+image/jpeg=feh.desktop
+image/jpg=feh.desktop
+image/png=feh.desktop
+image/tiff=feh.desktop
+image/x-bmp=feh.desktop
+image/x-pcx=feh.desktop
+image/x-tga=feh.desktop
+image/x-portable-pixmap=feh.desktop
+image/x-portable-bitmap=feh.desktop
+image/x-targa=feh.desktop
+image/x-portable-greymap=feh.desktop
+application/pcx=feh.desktop
+image/svg+xml=feh.desktop
+image/svg-xml=feh.desktop
+

You might have also noticed that I use feh as my default image viewer as well. That's just my personal preference, feel free to switch that out as you see fit.

Sidenote: Chromium now runs perfectly fine since the original crashes. I have no clue how or why. Wayland black magic, I assume? Maybe I installed a package that helped or an update occurred. Shrug

Screen Sharing

This has been a complete failure for me. I've tried both the Chromium and Firefox implementations of these "hacks" but neither work. For now I will fallback to my Garuda Linux OS boot and share my screen there. It's a silly workaround but I hardly ever need to "show my screen" in any capacity as is.

I can live without this for now. (Please leave a message in my personal inbox if you know of another workaround for this!)

Some Minor Tweaks

Some of these "hacks" or tweaks I had to implement might help others who run into similar issues when setting up their own Alpine desktops.

aerc-mail

It is important to install gawk since awk isn't "real" on Alpine. Once you have that on you system aerc will render emails out-of-the-box.[^1]

apk add gawk
+

Sublime Text

Sublime Text requires flatpak, so if that isn't your thing then you're better off snagging a different editor. I've tried multiple times throughout my career to use an alternate editor (preferably 100% open source) but keep finding myself returning to Sublime. Maybe one day...

apk add flatpak
+flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
+

Then reboot your machine for the changes to take. Login again and run:

flatpak install flathub com.sublimetext.three
+

FYI: You might need to run the above commands under sudo if your current user lacks proper permissions.

Cursors

This was an odd edge case. For the most part, the default system cursors worked out of the box. Then I installed Firefox. That caused me to go down a rabbit-hole of (still open) tickets referencing poor cursor rendering for Wayland Firefox. Apparently some users even have their cursors disappear completely!

Not to worry though - there is an easy fix!

Install capitaine cursors: + apk add capitaine-cursors
Make a new directory: + mkdir -p ~/.icons/capitaine-cursors
Copy the files over: + sudo cp -r /usr/share/icons/capitaine-cursors-dark ~/.icons/capitaine-cursors
The make your cursor changes using gnome-tweaks
Profit!

Closing Thoughts

Overall I'm decently satisfied with my "installer". I've included just enough packages to hit the ground running when using this on new hardware or even needing to recover existing devices. This project certainly won't cover the needs of all users, but my hope is that others can always fork their own and give it a spin! (Please do report any bugs or issues as you come across them!)

Alpine Linux can be more than just a "server distro". My daily driver proves it!

Refs

This is now included in my official installer script, but I originally had to install this manually.

Avoiding Featurism

2022-10-14T10:00:00Z

Avoiding Featurism

2022-10-14

I rather enjoy the term "featurism". I came across this term while reading the wonderful article Why I don't use Netscape, which the author credits to Bernd Paysan. Although it sums up the current "digital product" industry quite well the more specific terminology, creeping featurism, works better:

creeping featurism (noun)
+
A condition in which one or more people, often in the form of a committee, progressively increase the scope and complexity of a project until the project is deemed infeasible and subsequently cancelled to the detriment of all involved.
+

Throughout my career of designing and developing software I have run into this exact issue far too often. The major issue with getting sucked into a black-hole of "featurism" is there is no single person to blame. It probably seems easy to place all the responsibility on PMs or team leaders, but even if they are the ones adding excessive complexity to a given project, it is the role of developers and designers to speak up. It requires a team effort. Therefore, the whole team needs to be on-guard to avoid it.

Simple Guidelines

These "tips" are not perfect, nor will they work for every work environment. Hopefully they can at least be used as basic guidelines and expanded upon from there.

Explore the feature's benefit to the product. You need to confirm that this addition will be a net-positive for both customers and your bottom-line.
All team members assigned to a feature need to scope it out. Far too often I see feature sets that require design input being estimated solely by developers and vice versa.
Radically limit the scope of each individual task[^1]. Each task should be clear-cut, bite-sized and look almost trivial.
Lock-in tickets. Once they are agreed upon they cannot be altered[^2]. Anything that absolutely needs to be added should become a future ticket itself.
Follow-up with feature reviews. When a sprint or milestone is reached, it is important to reflect on what worked and what didn't. Call out any instances where the team steered away from the guidelines above.

That's it. Just a nice, simple baseline to branch off from to avoid "featurism". Some items listed won't make sense for certain teams and that's okay. If you take the time to at least reflect on your feature workflow, I guarantee you'll find areas to improve.

Creeping featurism can kill your product and the morale of your team. Avoid it like the plague!

Refs

This is easier said than done. Normally you will need to have developed some form of "point system" internally, so you know how to effectively divide features.
Taking away complexity, making changes that do not impact workload or reducing the ticket is fine - within reason.

Setting Up AdGuard Home with Eero

2022-11-04T10:00:00Z

Setting Up AdGuard Home with Eero

2022-11-04

Eariler this year I posted detailed instructions on setting up Pi-Hole with Eero and it seemed to help out a few people having troubles. With AdGuard Home recently popping up on the frontpage of HackerNews, I thought now would be a great time to post instructions of setting up that service alongside Eero devices.

What You'll Need

Raspberry Pi device (I recommend the Pi Zero for simplicity and low cost)
microSD card
Raspberry Pi Imager
micro USB to ethernet adapter (check your local Amazon)
Patience!

Setting Up the Raspberry Pi

The first thing we need to do is flash Raspberry Pi Lite onto our SD card. Open Raspberry Pi Imager, select the Lite version of the OS and your respective media (the SD card):

Don't flash anything just yet! Be sure to use the gear icon and edit the settings. Set a custom hostname, enable ssh and setup a proper user:

Plug it in and Boot!

Put the SD card into your Pi, connect power and ethernet. Give it a bit of time to boot up. Once you see a nice solid green LED, go back to your local computer's terminal and enter the following command:

ssh piguard@piguard.local
+

If everything was set up properly you will be asked to trust this device. Next, you will be prompted to enter the device password you setup.

Once you are connected directly to the Pi, it's best to check for updates:

sudo apt update
+

...and if updates are in fact available, install them via:

sudo apt upgrade
+

Installing AdGuard Home

Simply run the automated installer:

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v
+

Follow the instructions and you'll be setup in no time! To view your AdGuard dashboard at any time, you can now simply navigate to piguard.local.

If you run into any issues, I strongly suggest reading through the "Getting Started" guide.

Configuring the Eero App

Once your AdGuard Home server is installed and running, you can finally point your Eero network at it.

Open the Eero app (iOS or Android)
Navigate to Settings > Network Settings > DNS
Select Customized DNS and enter both your saved IPv4 / IPv6 values (These can be found under the Setup Guide tab in the main AdGuard Dashboard)
Eero will prompt you to reboot your network - do it

After the system reboots everything should be working as intended!

Closing Thoughts

I've personally switched over from Pi-Hole to AdGuard Home - it just feels more robust and the UI is significantly cleaner. Hopefully this helps others trying to do the same!

Making a Website Under 1kB

2022-08-02T10:00:00Z

Making a Website Under 1kB

2022-08-02

I recently launched (another) website club called the 1kB Club. Unlike the 1MB Club, it isn't as accessible for most modern websites to become official members. Building a website that actually serves useful content while squeezing its page size under 1,024 bytes is no easy feat.

But it is possible. And I did it myself!

Note: Big shout-out to Tanner, who inspired this whole "movement" with his own minimal website. (He also has some really great creations/articles there too!)

The HTML

For reference, you can view my "mini" website here: cv.tdarb.org. It is very minimal and serves only as a personal curriculum vitae. It also weighs only 920 bytes and is valid HTML.

Let's take a look at the full HTML and then break things down from there:

<!DOCTYPE html><link rel="icon" href="data:,"><meta name="viewport" content="width=device-width,initial-scale=1.0"><title>CV</title><p>Hi, I'm <a href="t">Brad Taunt</a>! I'm a UX designer.<p>Email: hello@tdarb.org<p>Resume<p>Senior Product Designer @ Donorbox, 2021-<br>Web Designer @ Purism, 2019-2021<br>Product Designer @ Benbria, 2013-2019<br>Web Designer @ Netvatise, 2009-2013<p>Projects<p><a href="1">1MB Club</a><br><a href="k">1kB Club</a><br><a href="p">pblog</a><br><a href="s">shinobi</a><br><a href="h">PHPetite</a><br><a href="v">Vanilla CSS</a><p>Writing<p><a href="d">The Death of Personality</a><br><a href="u">Simple Does Not Mean Ugly</a><br><a href="e">Plain Text Emails, Please</a><br><a href="tb">[more]</a>
+

Sneaky "Hacks"

The first thing you'll notice is that the HTML is compressed. White space adds extra bytes of data to the page weight - so it needs to go. Next, you might have caught the odd favicon meta tag:

<link rel="icon" href="data:,">
+

This is required to stop the browser from making the standard favicon request (normally pulling from favicon.ico). By adding this meta tag you are telling the browser to load in an empty image without running another server request. This saves about 400 bytes of bandwidth on its own!

The next two meta tags after the icon are technically optional. These are the viewport and title tags. You could save a good amount of data by excluding them altogether, but I had my own personal reasons for keeping them:

I wanted the web page to be responsive
I wanted the page to be valid HTML

So, I kept these tags but made them as minimal as I possibly could (looking at you title tag). After that, it was time to add my content!

Where We're Going, We Don't Need Tags...

The beauty of using HTML5 is the ability to ditch "default" and closing tags on most elements. Think of all those bytes we can save!

In the HTML above you will notice:

There is no html element
There is no head element
There is no body element
There are no closing p tags

Even with all those "missing" elements, the webpage is still valid HTML5! Craziness.

The final hack that saved a ton of bandwidth was implementing custom href URLs. Most of the links on the page take the user to another website altogether - which is fine. The problem is including these full domains inside the a:href tag. Those can start to eat up a lot of data.

Luckily, I host this mini-site through Netlify so I can take full advantage of their optional _redirects file. Links are now set with a single character (ie. "1" for the 1MB Club link) and the _redirects file simply forwards the user to the custom domain. Pretty sneaky!

Closing Thoughts

This is a silly project that isn't meant to be taken so seriously. That being said, I'd love to see what other pages people are able to create while being limited to just 1kB.

Do You Have an Extra $10?

2022-11-23T10:00:00Z

Do You Have an Extra $10?

2022-11-23

As software designers and developers, think of all the little things that we spend $10 on. Maybe it's a couple coffees over the course of a week. Maybe it's a TV streaming subscription. Maybe it's an impulse buy while we're out shopping for groceries. Maybe it goes into a mason jar on top of the fridge, stored away for a rainy day.

$10 doesn't seem like a ton of money, but a little does go a long way. What if, combined with other people, that $10 could grow and support an open source project? A project that you might even use every day without cost.

Plenty of people already do this - it's nothing new. If you already contribute to the open source community (whether through code or donations) then this post isn't really geared towards you. You're already helping out and are greatly appreciated. Feel free to stop reading right now and continue on with your day!

But, if you're like how I used to be, you might be one of those people who enjoys the idea of donating to a FOSS project instead of actually doing so. That's fine. Zero judgement here since I was doing exactly that for years. All I ask is for you to try it out for even a couple months. You'll soon realize that $10 doesn't break the bank, while at the same time, you get that "warm, fuzzy feeling" of supporting important projects/communities.

In a way, it's actually kind of selfish. You start doing it more for the feel good endorphin that kicks in each time you donate. At least, that's been my experience...

Open Source isn't Free

Maintaining any open source project takes years of prior design/development experience, along with sacrificing personal time. Contributors might enjoy working on their project. Most probably love connecting with their end-users and community - but their time is still a hard requirement.

I believe this time is worth paying for. If a project you depend on were to suddenly "shut down", how much time, effort, and income do you stand to lose? Is it more than $10 a month?

"Donating? In THIS Economy?"

Things aren't great for a lot of folks financially right now. I'm not ignorant to this fact and completely understand people tightening their belts. We all have to. I'm merely suggesting that if you have the means to support FOSS communities with any disposable income, you should. And I'm not suggesting a lot - just ten bucks.

Allow me to put my money where my mouth is and showcase my own $10 donation breakdown:

My $10 Breakdown

+ + + + + +

Service	Cost/month
sourcehut	$5.00
fosstodon	$3.00
qutebrowser	$2.00

+In case you are reading the post at a later point in time, the most up-to-date donation listing can always be found on my official Uses page.

SourceHut

To be fair, this is an active service which just so happens to be available for "free" in its current state. Drew mentions on the main pricing page that payment is currently optional, but will eventually require maintainers to upgrade (contributors will always have free access):

sr.ht is currently in alpha, and the quality of the service may reflect that. As such, payment is currently optional, and only encouraged for users who want to support the ongoing development of the site.
+

I still consider this "donating" since it helps keep this specific instance alive. It's also my main code forge since I've been migrating away from GitHub. I want to see SourceHut succeed, so while I could use the service completely free, I believe it's more than worth it to coverage my usage.

Fosstodon

fosstodon.org is my main "social" platform and the Mastodon instance I chose to join some time ago. The people I've interacted with have been nothing but helpful, insightful and fun. The maintainers are also very down to earth (shoutout to Kev specifically for making my initial experience great!)

Hosting a large Mastodon instance can become expensive. Not to mention the recent influx of Twitter users flocking to the platform in general. Fosstodon recently posted an update detailing how their server costs are now >$1800. That's insane.

The least I can do is toss a few bucks towards the service. I know it isn't much, but it certainly feels better than using such an awesome platform for absolutely nothing. Keep up the great work maintainers/mods!

qutebrowser

The best browser I have ever used. I refuse to go back to Firefox or even FireDragon/Pale Moon. I'm only currently donating $2 but my goal is to increase this in the future before adding any other services / communities to my "collection". If you haven't yet tried it, I highly recommend it.

Food for Thought

That's really all there is for me to say on the matter. It essentially comes down to personal preference and the financial ability to donate. As I said before: there is no judgement here. All I'm suggesting is that people do what they can to help support the FOSS projects they love.

And really, it's just $10.

Making software better without sacrificing user experience.

The X220 ThinkPad is the Best Laptop in the World

The X220 ThinkPad is the Best Laptop in the World

Specs

Build Quality

Ports

Keyboard

Battery Life

Repairability

Bonus Round: Price

What More Can I Say?

Bypassing the WiFi Hardware Switch on the Lenovo X201

Bypassing the WiFi Hardware Switch on the Lenovo X201

Opening Up the X201

Electrical Tape Fixes Everything

WP Enqueue for Beginners

WP Enqueue for Beginners

Introducing WP Enqueue

Enqueue Stylesheets

Enqueue Scripts

Packaging Everything Together

Setting Up Jekyll on Windows

Setting Up Jekyll on Windows

WSL

Installing Ruby & Dependencies

Jekyll - Finally!

Width or Flex-Basis?

Width or Flex-Basis?

Width

Pros

Cons

Flex-basis

Pros

Cons

CodePen Demo

Stop Using Custom Web Fonts

Stop Using Custom Web Fonts

System Fonts Look Good

"Think of the Consistency!"

Loss of Personality

Hurting Performance & Wasting Resources

Running VSCode in Chromium on OpenBSD

Running VSCode in Chromium on OpenBSD

VSCode in the Browser

Icons Should be Complementary - Text is Always Better

Icons Should be Complementary - Text is Always Better

Icons make an ass out of u and me

The hamburger menu is the 7th circle of Hell

But what of the "advanced" users?

Try for yourself

Refs

Using User-Select

Using User-Select

Introducing the CSS property

The CSS

Let's see it in action

Browser Support

They Won't Wait: A Warning for Slow Websites

They Won't Wait: A Warning for Slow Websites

We can do better

Data doesn't lie

Small and easy wins

No need to be extreme

Text Align: Justify

Text Align: Justify

What does justify do?

See it in action

When should I use this?

Browser support

The Wonders of Text Ellipsis

The Wonders of Text Ellipsis

Making Tables Responsive With Minimal CSS

Making Tables Responsive With Minimal CSS

Demo 1: Just let them scroll

Demo 2: More flexible than you think

Why should I care to use table elements?

Tabbed Content Without JavaScript

Tabbed Content Without JavaScript

The HTML

The CSS

Why should I care to use `table` elements?