development on Ashley Kolodziej - Boston Freelance Web Designer

How I added Webmentions support to my static website

ashley@lastletterdesign.com (Ashley Kolodziej) — Sun, 19 Jun 2022 22:00:00 +0000

Reading Miriam Suzanne’s excellent article on the complexity of implementing Webmentions got me thinking about the IndieWeb again. I stepped away from social media a while back, but the one thing I’ve consistently missed is having a way to record all the little moments that make up who I am. Since I’m on break from classes and teaching, I decided to challenge myself by adding Webmentions to my own site and documenting the process. Hopefully it’ll help someone else out!

Step one: Choose a tech stack

I’m told this is a lot easier if you use WordPress or a CMS. That said, despite WordPress being my day-job-specialty, the last evidence of WordPress on my personal site is over here on archive.org. So here we are: the tough road. I promise it’s not as tough as it looks.

These days (and by these days, I really mean “a decision I made six years ago that I haven’t had time to change yet”), I use Hugo to generate a static site. I didn’t want to redesign my entire website to try out Webmentions, so I chose a few online services that paired nicely with my setup. Tech stacks are always a negotiation between personal preference, your current knowledge, how much rework you want to do, and in my case, the path of least pain. I feel very at home with HTML, CSS, npm, and GitHub Actions, so my tech stack is based around those:

Hugo (for site generation)
Netlify CMS (for content management)
IndieLogin (for login)
RSS (for syndication)
GitHub Pages (for hosting - this is how I added Netlify CMS)
GitHub Actions (for deployment)
Webmention.io (for receiving and testing receiving)
Webmention.app (for sending)
Webmention.rocks (for testing sending)

If you’re on a static site generator, great! Keep reading, and swap out your generator, hosting, and deploy technologies as needed. The bones of this setup will still be helpful to you.

Step two: Add IndieLogin

Logging into Webmention.io is super easy - just use your URL! - if you have IndieLogin set up. Fortunately, it’s super easy to set up your site to work with IndieLogin. Just add rel="me" to your social media links, and you’ll be able to authenticate with your existing social media services.

Step three: Connect Webmention.io to your site

When you log in, you’ll find a settings page with some code somewhat like this, but specific to your username:

<link rel="webmention" href="https://webmention.io/username/webmention" />
<link rel="pingback" href="https://webmention.io/username/xmlrpc" />

I added my personalized version of that code into the head tag of my website.

Step four: Test that a Webmention elsewhere shows for you

Luckily, Webmention.io comes with a handy dandy form at the endpoint for you to test this with. Head on over to your personalized Webmention link from above, and you’ll see a simple form to send a happy little mention on over to yourself, Bob Ross-style.

The source URL will be a page that mentions something about you, and the target URL will be the page that the Webmention should be associated with. Perhaps you already have a mention out there you’re aware of. If you are me, you don’t because you deleted all your social media and most people didn’t know you existed in the first place, making this without question the most difficult part of the entire IndieWeb implementation process.

I digress.

In these cases, perhaps it’s clearest to just Webmention yourself. I wanted node-webmention-testpinger to work so badly, but I couldn’t get it to work like I expected. Let me know if you can get it to work and how, because I love the variety of formats it tests.

In my case, the source was this post’s URL, and the target was https://ashleykolodziej.com/learning-to-love-hugo/. After you submit the form and see a “pending” message, give it a refresh. With luck, you’ll see it change to “Success”!

Head back on over to your dashboard at Webmention.io, and you’ll see a brandy-new Webmention.

Step five: Add microformat classes to your content

I noticed many posts stop right around getting other people’s Webmentions to your website, which sure seems like the type of thing you could get away with doing if people knew about you. If, like me, your problems are more centered around people not knowing about you, adding the ability to send Webmentions is one way to fix that. And to do that, we need to do some markup work so the right data is going out with these mentions.

First, identify the type of content you’re likely to create a Webmention with, and then take a look at the Microformats specification to see which microformat matches best. In my case, it’s a blog post, so I chose to use the h-entry microformat. After taking a look at my markup, I needed to add an h-entry class around my entire blog post, a p-name class to my title, a p-author to show that I am (indeed) the author of the post, an h-card which talks a bit more about me (I’ll expand on that in a moment), a u-url class as well as my permalink, and a dt-published class.

Step six: Add an h-card

An h-card lets the web know (programmatically) who you are as a person. This standardized markup is what allows other websites using Webmentions to show your name and avatar next to mentions or comments. I used MDN’s excellent h-card example as a starting point for a card to add my own to the bottom of all my posts. It’s pretty simple to build and modify—just add any h-card supported property as a class to your HTML, and other IndieWeb users will get a nicely structured JSON object about you and who you are when you send a Webmention.

I chose to leave out the physical address and keep my email discoverable, and add a rel="author" attribute since I use this website to write articles. I also followed Aaron Parecki’s lead regarding bios by using the p-note class to wrap around my entire bio.

I was curious if the parser would pick up any data that is generally structured with these types of classes, so I added a p-pronouns class, which isn’t officially supported, to see if it would.

<aside class="p-author h-card">
 <h2>About the author</h2>
 <img class="u-photo" src="https://ashleykolodziej.com/img/profile.jpg"
 alt="A white woman with with glasses and long, curled blonde hair at a
 park, wearing a colorful dress and smiling." />
 <p class="p-note">
 <a rel="author" class="p-name u-url"
 href="https://ashleykolodziej.com">Ashley Kolodziej</a>
 (<span class="p-pronouns">she/her/hers</span>) is an
 <span class="p-job-title">Associate Creative Director</span> in
 <a href="https://www.bu.edu/interactive-design/" class="p-org">
 Boston University's Interactive Design department</a>. She is
 currently working on her Master's degree in User-Centered Design
 at Brandeis University and teaches classes in design and web
 development. You can reach her at <a class="u-email" href="
 mailto:ashley@lastletterdesign.com">ashley@lastletterdesign.com</a>.
 </p>
</aside>

Step seven: Test your h-card

The pin13 microformats parser lets you test either a live URL or the HTML. When I tested this blog post, I was excited to see that I was right—my pronouns were listed among the properties!

It’s up to the folks who implement webmentions on their websites what they want to do with the data from here, and as always, you should check if something existing can be used in the spec to mark up your data. But I didn’t see anything at a glance that seemed appropriate for pronouns, so I’m happy to leave it. It’s also neat to see that the parser automatically grabbed the src and alt attributes from my photo and structured them nicely in the JSON.

{
 "items": [
 {
 "type": [
 "h-card"
 ],
 "properties": {
 "note": [
 "Ashley Kolodziej (she/her/hers) is an Associate
 Creative Director in Boston University's Interactive
 Design department. She is currently working on her
 Master's degree in User-Centered Design at Brandeis
 University and teaches classes in design and web
 development. You can reach her at
 ashley@lastletterdesign.com."
 ],
 "name": [
 "Ashley Kolodziej"
 ],
 "pronouns": [
 "she/her/hers"
 ],
 "job-title": [
 "Associate Creative Director"
 ],
 "org": [
 "Boston University's Interactive Design department"
 ],
 "photo": [
 {
 "value": "https://ashleykolodziej.com/img/
 profile.jpg",
 "alt": "A white woman with with glasses and long,
 curled blonde hair at a park, wearing a
 colorful dress and smiling."
 }
 ],
 "url": [
 "https://ashleykolodziej.com"
 ],
 "email": [
 "mailto:ashley@lastletterdesign.com"
 ]
 }
 }
 ],
}

Step eight: Add RSS support, if you don’t have it

You’ll need an RSS feed for the next step. Since I’m using Hugo, I followed Justin James’s excellent instructions to add an RSS feed template to my Hugo theme. Adding the default template will enable a feed for every content type, like so, and it will also automatically enable feeds based on a category, such as this site’s design RSS feed. Right now, I don’t have images in the feed. I’ll add images to my RSS feed later, since I don’t need that to test Webmentions.

Step nine: Set up automatic Webmentions notifications

A good next step is to test that your new Webmentions functionality shows up properly for someone else. I took inspiration from James Mead’s awesome instructions to do this with https://webmention.app/.

In his instructions, James abstracted the sending script to its own GitHub repo and watched for changes to the RSS feed. But since I’m already building Hugo with a GitHub Action to host on GitHub Pages, I know exactly when my RSS feed has been rebuilt, and it’s at the end of my action. That’s the approach I’m going to take here.

First, install the webmention.app CLI by running npm install @remy/webmention --save-dev in your project’s folder. I used this to test Webmentions locally before adding them to the GitHub action.

Then, run npx webmention https://your-rss-link-here.xml --limit 1 --debug using your RSS feed URL to see if your latest post has a valid webmention without actually sending it. Once you’ve verified you have valid Webmentions to send out, you can add the CLI command to your GitHub Actions script.

The action itself is very simple—just add the same commands you’d run locally. Don’t forget to switch out the URL if you’re an avid copy/paster like I am.

- name: Install Dependencies
 run: npm install
- name: Test Webmentions
 run: npx webmention https://your-rss-link-here.xml --limit 1 --send

Step ten: Test that your Webmention shows elsewhere

To test if the Webmention actually shows on test content, I used https://webmention.rocks. Each of the links on their homepage tests a different type of HTML that could be used to create a Webmention. I used Test 1 to find out if my test post correctly sent a Webmention through Webmention.io. It went through completely smoothly and without a hitch right away.

Kidding.

Realistically, this took me several tries to figure out. My advice is to take a close look at your microformats, and use the pin13 microformats parser to help with debugging. One thing I found out as a result of this is that it looks like Webmentions don’t duplicate if you push them out multiple times using webmention.app—they just update.

Bonus time: Add support to Hugo for inline attributes

If you want to add classes to your Markdown, you can update Hugo’s Markdown renderer, Goldmark, to do that. Set block to true, and then add your attributes or classes to any block you like in your Markdown. I’m considering using this to add h-cite and u-in-reply-to classes to add context around my mentions where it makes sense, such as where I’m extending an idea. My thinking is this is generally similar to displaying a tweet. I don’t know if this is actually a good idea since this is my first time trying this out, though. If you’ve got any thoughts on that, let me know.

But wait, Webmentions aren’t showing on this site yet!

That’s absolutely right! I’m not at the point where I am actually showing the data for Webmentions on my site yet. That’s because Webmentions can cover a myrid of types of interactions you might take on a social media site. Liking, retweeting, bookmarking, citing, referencing, replying, commenting… the list goes on, and the data can too. Some of these deserve a slightly different user interface treatment, and I don’t know what that is for me yet. I do know it deserves its own post, and from here, you can choose how your mentions show on your website. Happy mentioning!

Why excellent markup is the foundation of accessible content

ashley@lastletterdesign.com (Ashley Kolodziej) — Fri, 21 May 2021 17:18:10 +0000

Happy Global Accessibility Awareness day, my friends!

One of the things I didn’t learn until late in my career as a frontend developer was just how important HTML is to accessibility. When I first started learning to write code, HTML felt like a means to an end - something I just needed to get out of the way in order to be able to write CSS.

How wrong I was.

This post is for all the newbies out there who might be tempted to skip the fundamentals of HTML. Today, we’re going to look at what exactly it is HTML does, and why that’s so important for making your websites accessible.

What is HTML, really?

HTML is a language of intent - the bridge between what you mean to say, and how the computer interprets it.

Okay, I realize that sounds a little weird. But hear me out. As a markup language, HTML is all about telling a computer how your content is structured.

Why should you care about how a computer understands your content?

Computers are the interface between your content and the rest of the world. This comes up in two contexts: search engine optimization, and accessibility.

Search engines and screen readers are both computer-based interfaces that help people access information they might not otherwise be able to access. They do two different jobs, and are aimed at two different use cases, but fundamentally, they are the same: computers that interpret human intent in content. This is why so many best practices for accessibility also happen to coincide with good SEO practice.

Using semantic HTML tags in your layout helps these tools understand your intent in organizing the content, and how to navigate it.

Think about what it’s like to navigate a new neighborhood.

Imagine if you suddenly placed in an unfamiliar neighborhood that you’ve never been in, and needed to find out how to get to the nearest store to buy a drink.

You might ask someone for directions.

You might think about some rules you know are usually true - the sun sets in the west. Streets are normally in a grid pattern. Usually, they intersect about once every block.

You might look for street signs, or traffic signals. These help you understand where you are.

Why is HTML so important for accessibility?

HTML provides these types of rules and structure to make it possible to navigate content using a computer. Using a screen reader, you can ask HTML for directions - landmarks around the content. Where’s the nearest main content? What are some of the most important pieces of information in this article, and where can I find them?

HTML also has some rules that are usually true. Well-formatted HTML headings are always ordered from h1 to h6, without skipping levels. Skipping a level is kind of like when a road you thought was straight suddenly veers off into a bunch of confusing curves. It can make it difficult to understand where you are in the neighborhood, relative to where you started.

How do I write more semantic HTML?

The simple answer is to always ask yourself if your non-semantic HTML elements are really the best choice for your content’s meaning. Could your div be a section instead? In some cases, you need to add HTML to style something in a purely decorative way, and that tag doesn’t have any new meaning. But in many cases, section, aside, and other elements are much better choices.

There are over 100 elements in HTML - it’s easy to get overwhelmed. The videos above will introduce you to the most common semantic HTML elements, so if you’re not sure where to start, start with those.

I’m always happy to connect!

🐰 @ashleykolodziej on Twitter 🐰 Professor K Explains on YouTube

The Golden Rules of Code Review Etiquette, as explained by teeny tiny bunnies

ashley@lastletterdesign.com (Ashley Kolodziej) — Tue, 18 May 2021 17:21:25 +0000

Inspired by this #DevDiscuss on Twitter:

Time for #DevDiscuss!

Tonight’s topic is… improving code reviews.

- Any tips on giving effective feedback in code reviews with someone you don't know well?
- Have you ever felt embarrassed after a code review? How did you handle it?
- How do you handle feedback anxiety? pic.twitter.com/rd0PTAo6ew
— DEV Community 👩‍💻👨‍💻 (@ThePracticalDev) May 19, 2021

This is the advice I gave folks in my department when starting our code review process up, and three years later, it’s still going strong.

Bunny gifs are critical to the messages that follow and are included here for improved understanding of the rules.

Keep your review requests small and focused.

This helps your reviewer get feedback to you in a timely manner.

Try to get to a review the same day it is requested.

Most folks depend on code for upcoming meetings, releases, and to keep moving on our ideas. Don’t let review requests sit.

Approve or request changes, but never comment only.

Comments don’t give the author clear direction on whether or not they can move forward. They’re great for discussion, but it’s important to be clear about next steps too.

Be clear about what needs addressing.

If you request changes, be clear about what types of changes are required for approval, and what aren’t, in the overall description for your review.

Review with teaching in mind.

Code review is about helping each other and sharing our knowledge. Phrase your feedback and ideas in a way that helps others around you to learn more about your area of expertise! Don’t make assumptions or get frustrated. Help your coworkers improve instead.

Review with empathy.

Deadlines are hard. Being new is hard. Learning is hard. We are all working to be the best people we can be, so take extra care to call out the cool ideas you see and be positive with your feedback. Use fun and appropriate emoji liberally! 🐰 Be aware of your voice and tone - humor is easily misinterpreted in text.

Review with common sense.

If you get a review the same morning as a meeting or the week of launch, approve it, but leave your feedback anyway for when the designer or developer won’t be scrambling to improve things. Be deliberate about what’s okay to leave for later.

Be aware that changes introduce bugs.

Each change that has to be made can impact the stability of the code. Keep this in mind as you review around tight deadlines.

Don’t require perfection.

Your job as a reviewer is to act in the best interest of the code and the people you’re working with. Early on, asking someone to refactor repetitive or overly complex CSS or JS is a good call. During QA, it is not.

This list was taken from a code review training I ran for my department a few years ago. Check out the full training on Google Slides.

Seven HTML debugging tips for complete beginners

ashley@lastletterdesign.com (Ashley Kolodziej) — Sat, 15 May 2021 17:15:01 +0000

I teach introductory web development classes to students who don’t have any programming experience whatsoever, and one of the questions I always get is - how do I debug my code when I don’t even really know how to write it just yet?

Debugging can be overwhelming if you’re new to coding or a particular language. Luckily, you don’t need to know a language by heart to debug your code. Debugging is just a method of thinking and checking things step by step, one at a time, until you’ve discovered what’s happening. Anyone can do it with the right checklist!

So with that in mind, here are my tips for debugging in HTML, including a practice problem and video explanation at the end.

Tip 1: Talk through what you expected

When you’re stuck, one of the best things you can do is to try talking through what you expected to see, step by step. Talking through what you expected is a great way to start identifying some of the places something might have gone wrong in your code. You can also try writing down some key words while you talk so you don’t forget them, such as what elements aren’t working like you thought they would. This will help you down the road if you need to Google it.

Tip 2: Make sure your code is properly indented

Once you’ve identified the problem and talked through what you expected to see, the next thing that you can do to help get unstuck is to make sure all your code is properly indented. This is a great step to take because it will force you to go line by line and make sure everything makes sense to you, and it will naturally get you to work on the next tip, which is…

Tip 3: Make sure all tags are closed

There’s nothing like a missing close tag in HTML to throw you off! When styles are applying to more of the page than you think they should, or your layout is acting especially wonky with no clear reason in the CSS, a missing close tag is almost always the culprit. The best time to check this is while you are fixing your indentation.

Tip 4: Check for syntax errors

HTML is pretty permissive when it comes to syntax, but you can still run into trouble if you don’t have quotes around your attribute values, or you forget an equals sign, or even miss a closing > on a tag. These types of errors are called syntax errors - errors that stop your code from running correctly (or in some cases, from working altogether!). The w3c has a simple explanation of HTML syntax that can help you double check for these types of errors.

Tip 5: Use an HTML validator

Tips 1 through 4 will get the majority of HTML problems solved if you have sharp eyes. But what if you miss something, or you’ve written a tag that is syntactically correct, but doesn’t actually exist in HTML? This is where a validator can really help you out. Validators automatically check for things like missing close tags, syntax errors, and even tags that don’t exist.

So why not just jump straight to a validator? You can, but you might find some of the errors a little daunting at first. Going through these other preliminary steps can help get you in the right mindset to read and understand error messages in a validator.

The w3c’s validator service is a great tool for this that you’ll want to bookmark.

Tip 6: If the error looks weird and unfamiliar, double check your approach

If an error comes up in the validator that just plain does not make sense to you, it might be a good time to start doing some Googling and double checking your approach. Do you understand what the code is doing? Can you explain it line by line? You may have inadvertently used the wrong kind of tag. It’s surprisingly easy to do!

Alternately, you may find there are no syntax errors, in which case, it’s time for…

Tip 7: Use rubber ducky debugging

If worse comes to worse and you just don’t know what’s going on, try explaining the problem to your nearest inanimate object - or friend. Even if they don’t know how to write HTML, if you can explain your problem to someone who knows nothing about what you’re doing, it might help you discover a logical error - or an error in the way that your code is built that isn’t necessarily wrong or broken, but also doesn’t solve the problem you intended to solve in the first place. If you’ve ever heard the term “rubber ducky debugging”, this is what that is!

Code along and practice debugging

The best way to learn debugging is to practice and see how others debug. If you want to try some of these steps out, check out my video, 7 Beginner-Friendly Tips for HTML Debugging on YouTube. I’ve included a CodePen practice problem in the description, and I recorded myself explaining these tips step by step as I solve the problem. Try debugging your way first, and then compare it with how I did it, and see how far you can get in solving it.

Happy coding!

Use the WordPress code editor to pass attributes to your Gutenberg block variations

ashley@lastletterdesign.com (Ashley Kolodziej) — Sat, 10 Apr 2021 22:15:00 +0000

I’ve been learning Gutenberg block development lately, and one of the things I was struggling with was trying to figure out what parameters I could pass on to blocks defined in block variations. I was looking all over the place for documentation on the parameters each block takes, such as font size and color. Little did I know I had all the documentation I needed right in front of me, in the form of the WordPress code editor.

Wait, what’s a variation?

A block variation is an easy way of leveraging WordPress core blocks (and even custom blocks you build) to create your own sets of blocks without writing any React code. You’ll need to write a bit of JavaScript, but it’s a lot like writing an array or object. If you can do that, you can write a block variation.

I like using block variations to create recommended sets of content and help guide my users in content entry. You can nest blocks in block variations, and do things like pre-set the background or font size on them.

Use the editor to speed up block variation development

My new workflow with block variations is to build the variation just the way I like it in the visual editor, and then switch over to the code editor to grab the attributes I need from there. This lets me set hard-to-remember parameters the right way, like gradients, without having to guess and check, like so:

Once you identify the block you want to model your variation off of in the code editor, just grab those attributes and bring them back into your block variations code. Here’s what that looks like in my final code.

This works for both your variations and your innerBlocks. Here’s an example in my final code of how I used this in a nested block.

Block variations are a low key way to get into Gutenberg block development and get familiar with the ecosystem without getting into React or the more complicated bits. Check it out if you’re new to Gutenberg and looking for a place to start.

Full tutorial

If you’re new to JavaScript or Gutenberg, I recorded my full process of building block variations using this method in a beginner-friendly way here. I also put together sample code in GitHub you can use to get started with a new block variation.

Let's Just Build It: Seven Years of Framework Development at Boston University

ashley@lastletterdesign.com (Ashley Kolodziej) — Mon, 23 Jan 2017 00:00:00 +0000

From the teaser:

The inside look at how the four most terrifying words ever uttered in development history have worked out for Boston University. We’ll cover seven years of successes and lessons learned in framework development, including enforcing brand guidelines in the site, when to allow customization and when to say no, and how on earth to make one codebase flexible enough to accommodate the requests we foresee – and the ones we don’t. If you’ve ever considered using a theme framework to power your WordPress sites, this is the case study for you.

Presented with Steve Rudolfi at WPCampus Online 2017.

First Impressions: Hugo

ashley@lastletterdesign.com (Ashley Kolodziej) — Mon, 15 Feb 2016 11:21:48 -0500

I’ve been writing in Markdown for a few months now, and it’s been amazing. I mean, anything that enables my Sublime Text habit is going to make me pretty happy, but I know me, and at heart I’m a designer. If you give me the ability to design, I will design. Markdown prevents me from doing that so I actually write.

So when I finally decided to tackle the long overdue task of redoing my portfolio, a static site generator seemed like the natural choice. Because let’s be honest - I haven’t logged into my Wordpress backend in months.

Why static?

I’ll be the first to admit that static site generators sounded like some flaky fad when I heard about them a year or two ago. Why do I need that? I have Wordpress! This sounds like a lot of work. The list of complaints goes on.

For me, the ability to write in Markdown in my code editor is the big selling point. Markdown was easy for me to pick up and there was no going back once I got the hang of it. But as I thought more, I realized there were some other really nice benefits too:

In the end, all I’m uploading is HTML, CSS, and Javascript, which means I don’t have to worry about Wordpress security for my site.
I can work on my site offline. You can do this with Wordpress as well, but it’s a bit messier to set up.
I can easily version control my entire site, including content.

To static it was.

Attempt 1: Jekyll

I actually gave static site generators a try a few months ago. A coworker of mine was waxing romantic on Jekyll, so that was the first place I stopped. I didn’t stick with it. Part of this was likely that I wasn’t writing in Markdown regularly yet, but I had a tough time with a lot of other stuff:

Getting set up was difficult. I’m not sure if I was looking at the wrong documentation or what, but it took me a solid hour or two just to get things working.
Installing a theme was painful, and then I still had to try and figure out how to edit it. As “skeleton” as the theme was, it still had styling that was in my way.
It felt worse than trying to work in Wordpress. Significantly worse.

I can really stick it out when I’m trying to figure out a code or design problem, but when it comes to tools and UI, I have a very low tolerance for things not going smoothly. Jekyll just wasn’t right for me, and I set the issue aside for a while to deal with the holiday season.

Next: Hugo

As I write this, I’m actually working in Hugo - I only started work on the new site last night - and love it. Some quick notes on what’s working really well for me:

Very quick and easy setup. Completely painless and I had a site up in less than five minutes.
No assumptions made about how you want to structure your content. I was able to get my dream content structure together in about a night.
No assumptions made about styling your content - there is even a built in function to create a new skeleton theme, and true to form it only creates the basic directories. You’re responsible for creating markup and outputting content.
Easy livereload and watch support (I’m aware Jekyll has this too, but I was never able to get that far)
Templating for content! The render function makes it super easy to define a template for a small bit of content you might use in multiple places around the site. I use it to share markup for listing my related posts across different templates.

The only real issue I’ve run into is getting a reference of functions I have access to in Hugo all in one place. Everything is by example, which means I’ve had a smooth process getting things going quickly, but I’m ready to do some more creative work and wish I had a reference to see all of what I have available to me.

So far though? Hugo gets an A+ for me. I’m excited to dive in and learn more.

Faking Watercolor Bleed Using a Simple PNG

ashley@lastletterdesign.com (Ashley Kolodziej) — Sat, 13 Feb 2016 20:11:28 -0500

I have a confession to make. That watercolor bleed effect on Marcia Deihl? Nothing more than a simple PNG.

I just didn’t have the time to learn <canvas> this time around.

After I finished animating in the journal entries for The Good Life of Marcia Deihl, I found the article just needed a little something else. I wished I had a nice watercolor bleed effect to go with the watercolor background of the journals. Something to bring each item in and tie the whole article together, you know?

I saw a few ideas out there using <canvas>, but I needed something quick and reliable. I took a close look at what the real effects did, thought about it, and realized what makes a watercolor bleed look like a watercolor bleed is two things: a fade in, and the bleed stopping at irregular points with a brushlike texture.

Enter the PNG: master of brushy textures.

I ended up going with animating in a PNG mask using the same watercolor brush as the edges of each watercolor photo, but in slightly different places. I gave it the same background color as my main article, but with an alpha value of something like .75 so you could see a bit of the image behind it. When you scroll any image into view, the mask scales and out until it no longer covers the image, and animates that alpha value down to 0. That combination of fading in and the mask “stopping” uncovering the watercolor paper beneath it at different times did the trick for giving the impression of watercolor bleeding in.

Voila! Watercolor bleed. You could theoretically even acheive this with plain ol’ CSS and HTML, if you didn’t mind the effect happening on load.

Realistic SVG Handwriting

ashley@lastletterdesign.com (Ashley Kolodziej) — Sat, 13 Feb 2016 19:34:59 -0500

View the live article here.

Fact: SVG letters will never look like real handwriting.

I knew I wanted a handwriting effect, and I knew you could animate SVGs. Some quick Googling led me to the most common technique - animate the stroke dash.

Here’s the idea: if you can find the length of a line, and make a dash so large it takes up the entire length of the line, you can animate the length of that dash so it looks like it’s being drawn in. Neat!

The trouble with this is you get very neat lines, and handwriting isn’t neat… especially handwriting from a diary. There’s texture, ink bleed, and variation in width and saturation of the ink depending on how quickly you write. No SVG stroke will ever have all these things. And without these things, you get very dead, very not-handwritten looking type. Trust me, I tried. After about a half hour of tracing in Illustrator (and an undisclosed number of horrifying flashbacks to my design school days) with upsettingly bad results, I realized this was not going to work.

Same stroke-dasharray, different angle

I really needed to be using the original source handwriting, and I needed it to look real. Not traced. I looked at my image, which nearly had a flat color background if you weren’t looking too closely.

You know what else has a flat color? My SVG stroke! What if instead of animating in… I animated out? A quick Codepen trial with a similar image, and I realized I was on to something.

All I needed to do was get the color close enough to the background of my image for the SVG to blend in and act as a mask. As the SVG stroke animates out, it reveals the letters in the image hidden behind it. As an added bonus, I didn’t have to make the mask look good in Illustrator. All it had to do was cover the letters sufficiently. Quicker and better results. I couldn’t have asked for more.

Making peace with layer order and animation order

Now, if you’re paying attention to that Codepen, you might have noticed that final t in Ballpoint doesn’t look so hot, since the mask for the final cross on that t sits over the main line. Obviously that’s not how writing works. What I ended up doing was determining - if you were writing - which areas you would “go over” twice, and creating a separate png layer for those areas. Anywhere there is a ligature, crossbar, or anything of that nature, I’ve carefully layered the PNG parts for that letter and the stroke that goes with it so that this doesn’t happen. On the smallest bits of handwriting, it’s not noticeable, but it was crucial for the header area.

What I realized when that happened was that the way I needed things layered in Illustrator for this to work correctly was not the same way I wanted them animated. Take, for example, an A. You can break that into two parts: something like an upside down V, and a crossbar. I need that V over the crossbar. If you know the DOM, you know that means that the SVG is going to put the crossbar first in code, and the V after, so that it is naturally on top. And if you go looking for lines in the SVG and putting them in an array to be animated, it’s going to say animate the crossbar first and the upside down V second, which is not how we write.

The simple solution to this is just to reverse the array so the order of animation is correct, but it was sort of neat, and something I wasn’t expecting to run into. Now I know, right?

Keeping it realistic

What’s the difference between a name and a scribble to my code? The speed at which you animate each stroke. It was pretty easy to turn this approach from my header into a small function. Loop through the SVG, find all the lines, animate them using the timing I like for that particular item. This made it very easy to create all the animations that followed. Everything from the scribbles, to the margin writing, to the diary after was as simple as quickly masking the letters in Illustrator and giving them a class of “animate”.

I used Waypoints to call that function once the item scrolls just into view. Since some of the animations take some time, it was better to start it earlier than later.

#OneBU

ashley@lastletterdesign.com (Ashley Kolodziej) — Thu, 20 Nov 2014 00:00:00 +0000

A tumblr theme for a photo contest held by Boston University Public Relations. I relied heavily on IFTTT to grab photos from a variety of sources, including Facebook, Twitter, Weibo, RenRen, Google Plus, and Instagram.

See more at: http://onebuphoto.tumblr.com/