It’s That Time Again

Posted on by Lindsey

What time is it?

Time for me to announce I’m starting a new job! My time at Scripted was wonderful. I learned some really good life lessons and understand myself more as an engineer and a person. I’ve discovered I’m really interested in bridging that engineer to the world communication that is so necessary for both internal employees and translating your product to your audience. I’ve shifted from being a mostly backend engineer to a mostly front end engineer (as an aside is anyone else bothered by the fact that the accepted spelling for front end has a space but backend is one word???) and I feel like the topsy-turvy nature of the JavaScript ecosystem allows me to keep experimenting but also not take myself or my fellow engineers too seriously.

It's a secret

I can’t really talk about what I’m doing next as we’re still in a closed alpha. Surprisingly the image above is more of a clue than it seems. I’ll be working as a mostly front end engineer with a very good friend at another tiny startup and this time my goal is to learn. I’m going to be working with some really smart people and I want to soak it all up like a sponge.

Also, I would like to actually post more here. It’s become a bit of a wasteland and I need to figure out how to remedy that. I think my biggest problem is I feel like I need to be super tech professional here and that’s not my life. Well not all of it at least. I also write and knit and play video games and take too many photos of my cats. I tried focusing on that part of me in another place Everything Will Be Amazing but I couldn’t focus on that either. So maybe it’s time to unify. I’ll keep you posted.

New Hobbies, Old Hobbies

Posted on by Lindsey

I’ve been continuing to spend a lot of time outside of work not even thinking about programming. I’m not sure if that’s a good or bad thing in the long run, but for my mental health and happiness, it’s been amazing. I’ve been cycling through old hobbies and trying out new things, but they’ve mostly been duds. Knitting was always big for me but since I moved to California it’s a little harder to delight in making beautiful woolen things to keep me warm when I can count on one hand the number of times I’ve even seen rain this year.

So I went searching, reaching back into the depths of things I enjoyed. What kept coming up was back in college when I spent four years studying Chinese and how much I regretted losing most of my knowledge over the last eight or so years ago. So I went back to skool, started taking a night class in beginning Chinese and it came back to me much quicker than I expected. I’m not amazing at it or anything but I’m really enjoying it.

That's how you all remember hanzi right?
That’s how you all remember hanzi right?

Now, circling the wagons, I’m reflecting on my hobbies again. When I first decided to try to find a job as a software engineer, I had the very real fear that taking programming from a hobby to a job would make me lose my love of it. In some ways, I have to admit it has. Actual software engineering work, when you don’t try to be the 10x asshole, can sometimes be a little boring, when it’s just helping out marketing or maybe doing the same thing in the same routine.

Other times though programming feels a bit like flying. Everything clicks and time melts away. I wish I knew how to make myself feel like that more but I think the secret might be that most of us feel that way. We don’t hear about us because we’re just there doing our job, not making waves, or keynoting conferences, or releasing yet another JavaScript framework.

Or maybe I’m just a slacker and should run off to China and teach English. Thoughts?

Accessing accessibility: Some SEO-friendly tips

Posted on by Lindsey

This post was originally written for my work engineering blog. Check us out and see some interesting articles from my coworkers at goats.scripted.com.

According to the 2012 U.S. Census, almost 60 million Americans (nearly 20 percent of the U.S. population) have some form of disability. While not all of these disabilities may affect the way people interact with your website, a large population of your potential users probably can’t use your website the way you expect them to. For any company, but especially ones like Scripted that prides themselves on words, this is often an overlooked trap.

Accessibility is not just about making it easier for people with disabilities to interact with your site. Instead, making information easier to consume and understand should be your primary goal. These tweaks can be simple, such as using the appropriate H1 tag versus a stylized div for your main header and having links that are descriptive on their own rather than just saying ‘click me’ or ‘here’. Keeping accessibility in mind also allows you to build a better organized, more SEO-optimized, and easier-to-navigate app for all of your users.

A good place to start optimizing is by running your site through Addy Osmandi’s A11y tool. Running the online A11y URL checker against a page will give you a list of warnings.

A11y warnings for Scripted home page

In Scripted’s case, the home page had some warnings about hidden links and was missing some alt tags for images.

A11y warnings for Scripted order form

Scripted’s order page had some severe shortcomings regarding labeling inputs. Without input labels, many screen readers can only guess what your forms are trying to collect. And as a secret bonus, input labels make the clickable surface of your input bigger. A tiny radio button without a label means the user can only click on the radio dot to choose an option. With labels added, they can click anywhere on the radio or surrounding label to make a choice.

    <label for="content">
        Custom Content
        <input type="radio" name="content" value="custom">
    </label>

A11y passing tests

After adding the labels and making some of the other suggested tweaks to both the homepage and the order flow, the report is looking much better, but one file change won’t solve all your problems. Someone on your team might make a change next week and forget to include an alt on an important image without thinking about the impact. You need a plan! Whether it’s running the URL checker on a regular basis or asking the team to keep accessibility in mind during code reviews (and training them on what to look for), figure out a path that will help you maintain the accessibility of your site. For both quick fixes and good basics on accessibility, a great resource to start your team with is the A11y project.

Flexbox: Tables of the Future?

Posted on by Lindsey

This post was originally written for my work engineering blog. Check us out and see some interesting articles from my coworkers at goats.scripted.com.

The greatest CSS gif of all time

What is flexbox?

Most websites design around grid systems. A long, long time ago, in Internet years, this was done using frames and actual table grids. Then we all moved on to floats and percentage widths. The Holy Grail layout was often a mess of different solutions. Flexbox is a CSS layout mode that gives you complete control over the components you put in your grid, allowing you to keep sizing organized both inside and outside the box, as well as providing a unified layout styling no matter what screen size you view the components on.

How we use flexbox at Scripted

Flexbox is used at Scripted in a number of locations. Most of our marketplace pages are large grids of cards, and each card is itself a grid. In order to accommodate lots of information about each blog idea, we need to be able to keep sizing consistent with inconsistent data. Our CSS is compiled so we are able to make mixins for flexbox that do the heavy lifting (and solve a lot of cross-browser compatibility issues) for us on the fly.

Flexbox in actionFlexbox in action

On the page above, for example, each card uses our standard flex layout. We added the option of a column direction, meaning information should flow down the page, and each component in an individual card should stack. For the overall grid layout of an unknown number of cards, we use the standard with an additional wrap option so cards flow to new lines when we run out of space (versus trying to crowd them onto a single line).

Why not flexbox?

Unfortunately, like with most newer web standards, support and implementation haven’t had time to unify. For example, Internet Explorer — because it’s always the example with new designs — implemented an outdated flexbox interpretation in older versions. Even with current flexbox standards, different browsers render flexbox styles differently.

Other concerns, especially for sites trying to use flexbox for their overall layout, is the speed of rendering. While it’s a few years old, Ben Frain’s look at the speed of table CSS versus flexbox is a good start. Rerunning the tests now shows some better numbers for flexbox layouts.

We still use table layouts for assets that we want to just work; some of our feature charts are examples of this.

Other resources

While it still has some quirks, depending on your project and your commitment to polyfills, flexbox is a powerful tool to build some really nice layouts. To get started building your own, Sketching with CSS has the ultimate flexbox cheat sheet. And of course, Mozilla Developer Network has a full rundown of flexbox layouts and links to many tutorials.

Work From Home Friday: Emacs Maybe?

Posted on by Lindsey

So most of my nerdy friends have already lost their shit over emacs. I’ve avoided it with my tiny little Sublime bubble of comfort, but then more of them switched and suddenly I felt left out of the big kid pool. SO, I’m going to remedy this. So far, I’m just using the EXTREMELY AMAZING ohai-emacs initial setup and customizing from there. But seriously, ohai has a nyan cat (nyan-mode for those who know) to show me how far along I am in a file. I’m. In. Love.

shaq, cat wiggle

If you’ve never used emacs before I’d recommend starting with a tutorial, but if you want it to look pretty while you start learning get yourself over to the Ohai-emacs github page.

If Your Only Tool Is a Hammer Then Every Problem Looks Like a Nail

Posted on by Lindsey

Light on content again today. I’m having a bit of writers block I think. The life is boring but nice, so I don’t have as many existential crises to share with you. As a bit of a carry on to my dialogue last week, I’ve been thinking about the right tool for the job.

I have been wanting to track some stuff I’m working on and I wanted to be able to record a daily log. I spent a week looking at different frameworks and decided what database to use. Then I woke up Saturday morning and absolutely frustrated with myself, I started logging things in a spreadsheet. And my problems were solved. I can keep track of things, use pivot tables if I need more data and write quick charts. Hell eventually I can export it and parse it and put it in a database if I really need to. But do I really need to?

cat shakes head no

Analogous to this, is that shiny fancy bit of code that you’re super smug about because you figured it out and it’s bitchin’. It may be bitchin’ but it will in fact probably be a bitch for the next person to look the codebase to maintain. By no means should you take the easy way out, but if you are trying to use a slick one-liner in production code that takes a half hour PowerPoint to explain, save it for a blog post. Be kind to your fellow engineers. We’re generally quiet, but we will mentally curse you to the fate of having a problem that’s never been answered on Stack Overflow.

Work From Home Friday: Don’t be Afraid of Rebasing

Posted on by Lindsey

Little late today, I was busy working/running around/watching paint dry, so I’ll keep this brief. I’ve mentioned before that git can be like a game save, it protects your butt if things go wrong and you need to get back to a certain safer place. But I also like to use git commits as a well crafted story, or at least that’s what I want to present to the outside world. Having a lot of why doesn't this work or it does the things or rainbows and ponies (a real pr of mine at a job at one point) doesn’t really mean anything to anyone but me. And unfortunately it probably doesn’t mean much to me if I go back and look at it even a day later. So what’s a girl to do? Tell her own story of course.

First let me say, “rewriting history” in git is a bit of a controversial subject for some people. But at multiple jobs and in my preference I don’t have a problem with it as long as you’re not rewriting master or other people’s history. So what does that leave us? The ability to craft a really well documented pull request. I can explain you through the choices of my work. I can easily split out frontend and backend changes if different people need to look at different parts. I can make changes easier to find if they all happen on one file in one commit.

I’ve gotten lazier about this at my current job, but my goal is to get back in the habit. It’s good hygiene and leaves my mental health intact.

For better words than mine check out Nathan LeClaire’s Don’t Be Afraid of Git and a good visual tutorial can be found from the amazing Thoughtbot blog.