From Local Server to Live Site

With the right tools and some simple software, your WordPress development workflow can be downright delightful (instead of difficult)! That's why we built Local by Flywheel, our free local development application.

Now, we've launched Local Connect, a sweet feature embedded in the app that gives you push-pull functionality with Flywheel, our WordPress hosting platform. There’s no need to mess with downloading, uploading, and exporting. Pair up these platforms to push local sites live with a few quick clicks, pull down sites for offline editing, and streamline your tools for a simplified process! Download Local for free here and get started!

(more…)

Accessibility Testing Tools

There is a sentiment that accessibility isn't a checklist, meaning that if you're really trying to make a site accessible, you don't just get to check some things off a list and call it perfect. The list may be imperfect and worse, it takes the user out of the equation, so it is said.

Karl Groves once argued against this:

I’d argue that a well-documented process which includes checklist-based evaluations are better at ensuring that all users’ needs are met, not just some users.

I mention this because you might consider an automated accessibility testing tool another form of a checklist. They have rules built into them, and they test your site against that list of rules.

I'm pretty new to the idea of these things, so no expert here, but there appears to be quite a few options! Let's take a look at some of them.

(more…)

ABEM. A more useful adaptation of BEM.

BEM (Block Element Modifier) is a popular CSS class naming convention that makes CSS easier to maintain. This article assumes that you are already familiar with the naming convention. If not you can learn more about it at getbem.com to catch up on the basics.

The standard syntax for BEM is:

block-name__element-name--modifier-name

I'm personally a massive fan of the methodology behind the naming convention. Separating your styles into small components is far easier to maintain than having a sea of high specificity spread all throughout your stylesheet. However, there are a few problems I have with the syntax that can cause issues in production as well as cause confusion for developers. I prefer to use a slightly tweaked version of the syntax instead. I call it ABEM (Atomic Block Element Modifier):

[a/m/o]-blockName__elementName -modifierName

(more…)

Keeping Parent Visible While Child in :focus

Say we have a <div></div>.

We only want this div to be visible when it's hovered, so:

div:hover { 
  opacity: 1; 
}

We need focus styles as well, for accessibility, so:

div:hover,
div:focus { 
  opacity: 1; 
}

But div's can't be focused on their own, so we'll need:

<div tabindex="0">
</div>

There is content in this div. Not just text, but links as well.

<div tabindex="0">
  <p>This little piggy went to market.</p>
  <a href="#market">Go to market</a>
</div>

This is where it gets tricky.

(more…)

How Would You Solve This Rendering Puzzle In React?

Welcome, React aficionados and amateurs like myself! I have a puzzle for you today.

Let's say that you wanted to render out a list of items in a 2 column structure. Each of these items is a separate component. For example, say we had a list of albums and we wanted to render them a full page 2 column list. Each "Album" is a React component.

(more…)

Evolution of img: Gif without the GIF

Colin Bendell writes about a new and particularly weird addition to Safari Technology Preview in this excellent post about the evolution of animated images on the web. He explains how we can now add an MP4 file directly to the source of an img tag. That would look something like this:

<img src="video.mp4"/>

The idea is that that code would render an image with a looping video inside. As Colin describes, this provides a host of performance benefits:

Animated GIFs are a hack. [...] But they have become an awesome tool for cinemagraphs, memes, and creative expression. All of this awesomeness, however, comes at a cost. Animated GIFs are terrible for web performance. They are HUGE in size, impact cellular data bills, require more CPU and memory, cause repaints, and are battery killers. Typically GIFs are 12x larger files than H.264 videos, and take 2x the energy to load and display in a browser. And we’re spending all of those resources on something that doesn’t even look very good – the GIF 256 color limitation often makes GIF files look terrible...

By enabling video content in img tags, Safari Technology Preview is paving the way for awesome Gif-like experiences, without the terrible performance and quality costs associated with GIF files. This functionality will be fantastic for users, developers, designers, and the web. Besides the enormous performance wins that this change enables, it opens up many new use cases that media and ecommerce businesses have been yearning to implement for years. Here’s hoping the other browsers will soon follow.

This seems like a weird hack but, after mulling it over for a second, I get how simple and elegant a solution this is. It also sort of means that other browsers won’t have to support WebP in the future, too.

Calendar with CSS Grid

Here’s a nifty post by Jonathan Snook where he walks us through how to make a calendar interface with CSS Grid and there’s a lot of tricks in here that are worth digging into a little bit more, particularly where Jonathan uses grid-auto-flow: dense which will let Grid take the wheels of a design and try to fill up as much of the allotted space as possible.

As I was digging around, I found a post on Grid’s auto-placement algorithm by Ian Yates which kinda fleshes things out more succinctly. Might come in handy.

Oh, and we have an example of a Grid-based calendar in our ongoing collection of CSS Grid starter templates.

The User Experience of Design Systems

Rune Madsen jotted down his notes from a talk he gave at UX Camp Copenhagen back in May all about design systems and also, well, the potential problems that can arise when building a single unifying system:

When you start a redesign process for a company, it’s very easy to briefly look at all their products (apps, websites, newsletters, etc) and first of all make fun of how bad it all looks, and then design this one single design system for everything. However, once you start diving into why those decisions were made, they often reveal local knowledge that your design system doesn’t solve. I see this so often where a new design system completely ignores for example the difference between platforms because they standardized their components to make mobile and web look the same. Mobile design is just a different thing: Buttons need to be larger, elements should float to the bottom of the screen so they are easier to reach, etc.

This is born from one of Rune's primary critiques on design systems: that they often benefit the designer over the user. Even if a company's products aren't the prettiest of all things, they were created in a way that solved for a need at the time and perhaps we can learn from that rather than assume that standardization is the only way to solve user needs. There's a difference between standardization and consistency and erring too heavily on the side of standards could have a water-down effect on UX that tosses the baby out with the bath water.

A very good read (and presentation) indeed!

Slate’s URLs Are Getting a Makeover

Greg Lavallee writes about a project currently underway at Slate, where they’ve defined a new goal for themselves:

Our goal is speed: Readers should be able to get to what they want quickly, writers should be able to swiftly publish their posts, and developers should be able to code with speed.

They’ve already started shipping a lot of neat improvements to the website but the part that really interests me is where they focus on redefining their URLs:

As a web developer and product dabbler, I love URLs. URLs say a tremendous amount about an application’s structure, and their predictability is a testament to the elegance of the systems behind them. A good URL should let you play with it and find delightful new things as you do.

Each little piece of our new URL took a significant amount of planning and effort by the Slate tech team.

The key takeaway? URLs can improve user experience. In the case of Slate, their URL structure contained redundant subdirectory paths, unnecessary bits, and inverted information. The result is something that reads more like a true hierarchy and informs the reader that there may be more goodies to discover earlier in the path.

On Building Features

We've released a couple of features recently at CodePen that I played a role in. It got me thinking a little bit about the process of that. It's always unique, and for a lot of reasons. Let's explore that.

(more…)

​HelloSign API: Your development time matters

We know that no API can write your code for you, but ours comes close. We've placed great importance on making sure our API is the most developer-friendly API available — prioritizing clean documentation, an industry-first API dashboard for easy tracking and debugging, and trained API support engineers to personally assist with your integration.  Meaning, you won't find an eSignature product with an easier or faster path to implementation.  It's 2x faster than other eSignature APIs.  

If you're a business looking for a way to integrate eSignatures into your website or app, test drive HelloSign API for free today.

(more…)

icon-anchoricon-closeicon-emailicon-linkicon-logo-staricon-menuicon-nav-guideicon-searchicon-staricon-tag