Advice on Teaching Beginner Front-end Code

I’ve had the pleasure of teaching Intro to HTML/CSS for Girl Develop It here in Philly since our inaugural class! Sharing my knowledge of front-end code with women who want to learn it has been incredibly rewarding and one of my favorite things to do! GDI has chapters throughout the world and I’ve been asked a few times to share advice to first-time teachers about to head up a class.

  1. Don’t read/recite the slides - use them as a guide but make sure you are brining your expertise to the class. That’s what makes it different than the students reading the slides themselves.
  2. Make sure the students have access to the slides and the materials before class so they can have it locally on their machine - sometimes it’s hard to see the projector if it’s too bright or if the room is long/the student is in back of the room
  3. Encourage questions!
    • If people ask questions that are beyond the scope of the course, don’t shoot it down. Be sure to touch on the subject and where they can find more info if they want to seek out more. The pacing of beginner classes can vary greatly, so don’t go too fast, but enable those with a more solid understanding to push themselves further.
  4. Make sure the TA’s feel comfortable helping people out while you continue. There’s a LOT to cover in these the short span of an intro class, so you don’t want to stop the whole class for a how to question about how to copy/paste - but you should stop the class if the question is applicable to everyone.
  5. Take scheduled breaks and let students know at the beginning of class when it will be. This helps ease their minds in regards to things like parking meter refills, lunch, brain timeouts.
  6. Go around the room and ask how people are doing. Some people will not ask for help until pressed. I can’t tell you how many times you can say “any questions?” and everyone will say no. But go around the room and up to someone and say ‘hows it going?” and questions will start pouring out.
  7. HAVE FUN!! :)

I’m also currently teaching Intro to HTML on Skillshare. Teaching without feedback from being in the same room is a completely different ballgame! Remember that the energy of an in-person class can really add to the experience and use that to keep the class fun and engaging!

Disabling Typekit on Mobile

Edit: Typekit has posted some more info in response on their fantastic blog:

I’m putting some finishing touches on a talk coming up and I was looking into some details when including different web font options on our sites. I use Typekit a lot. I love it. I never really paid too much attention to the Kit settings > Mobile settings options before.

And I started thinking about the pay off between having custom fonts on mobile vs having our sites load faster. Chris Coyier wrote a great summary of some approaches to tackle this: and there’s a post on the Typekit blog from Jordan Moore about using multiple kits and loading them based on breakpoint size (since no bandwidth testing was available)

In this case, if we are using Typekit, should we just be disabling this mobile support that we have access to and letting fallback fonts be a browser/device safe font (i.e. Droid Sans)? It seems almost too good to be true to have these simple checkboxes, which are enabled by default, in which we can handle all the logic.

I read a bit more, such as in this Typekit blog post:, which says:

Following the pattern for our other supported mobile platforms, we’ve also added an option to disable support for Windows Phone in individual kits. You’ll find this option in the Kit Editor under Kit Settings > Mobile Settings. Uncheck the box for Windows Phone and republish your kit to turn off support. This option is useful if you’re building a responsive site that doesn’t require web fonts to be loaded on mobile platforms, or if you encounter issues with Windows Phone.

And I thought that certainly sounds like we can easily disable this. I did a very unofficial quick test to see what would load on mobile using one weight of Proxima Nova with everything enabled as on default which resulted in 32KB weight and 4 requests:

and then unchecked everything and ran it again and still had one Typekit JS request, resulting in 2 requests, 10KB

Sure, there are a ton of other things we can do to try to keep our page weights down, so maybe this isn’t the place to start? Here are questions that come to mind:

  • is there a better way to test this?
  • the speed index on this iOS test dropped from 3800 > 3000 when the mobile support was disabled , which still seems pretty high
  • will this work/save us enough to use it?
  • I only used one font/weight here, what if we disabled many?
  • should we be sacrificing type design for this?
  • are performance hits from web fonts on the top/middle/bottom of our list?
  • what about these mobile devices when connected to wifi? Is it cool that they never get the fonts? Worth the potential savings or no?
  • how should we be testing our fallback fonts? Is the extra testing/design time worth it?
  • are y’all disabling fonts through any of these approaches? If so, I’d love to hear about how it’s working out for you!!

So many questions!

Resources for Beginning Responsive Web Design

I occasionally receive questions through the Nerdary or over at my site about web topics. Often someone else has that same question, so thought I’d share some here. Here’s a question I received about getting started with responsive web design:

I built my website portfolio BUT! I need some resources for helping me make it responsive. Any hints or sites for help with this would be much appreciated!

Congrats on the new site! Isn’t HTML awesome? Responsive Web Design (RWD) is a great next step after learning the basics of HTML and CSS and once you know it, will be an integral part of every project!

Like anything out there, you can follow a lot of different paths when learning about RWD. There are great patterns to follow, important thoughts on content strategy for mobile, and ideas on what order to build it.

But if you are looking for practical first and theoretical second, the CSS that goes into RWD is a must know as well, so it’s a great place to start! While some people might throw a list of “200 things you absolutely must know about Responsive Web Design RIGHT NOW OMG!!!”, sometimes learning one thing at a time is the best ;) So I would start here and then move on to some of the deeper details.

The first article written on RWD was run on A List Apart by Ethan Marcotte and was a crazy, game changer:

Ethan is super awesome and followed that article up with a very east to read and understand book, Responsive Web Design from A Book Apart

Do you like videos? Check out this braindump on responsive web design on CSS Tricks from Chris Coyier.

Best of luck and high fives to you!

Using mousemove and touchstart to Detect Touch Devices

So you know I love hovers. I was recently trying to implement a hover that has the image as the link, and on hover the text of the link appears. The information that is hidden and shown on hover is vital to understanding what the link is and where it goes. Something that without knowing, a user might never want to click on the link. This hover/focus interaction works perfectly fine for keyboard and mouse users, but what about touch?

With touchable desktops coming out and tablets the size of tvs, using media queries with max-device-width isn’t as reliable as it used to be to show the hidden information by default for “mobile sized” devices. This led me to a few different searches for a new solution.

Josh Clark wrote about it the dilemma here: and talks and about how we have to design our UIs for touch. Great points, but going back to design wasn’t an option here.

I looked into Modernizr, but there are a slew of issues opened right now (such as that investigate how to make touch event detection more reliable without setting off false positives.

In this case, false positives using Modernizr wouldn’t be the worst thing in the world, as that falls back to the Josh Clark approach of designing for touch first. But we tried something else anyway..

Mark Huot and I opened up Codepen and decided to try out a few different tests around using the mousemove function. We figured, hey if there’s a mouse movement, it’s not touch right? This kinda worked, but we quickly found out that clicking on links on our iPad or clicking anywhere on our Android fired off the mousemove function. So that didn’t work. We ended up with a few different functions, until we finally reached this:

We style for touch first by default, so the product information shows. Then after the mousemove function fires, a class is applied of ‘hover-on’. With this class we adjust the styles appropriately to set the hover opacity to 0 and then to 1 on hover. Touch devices should never get that class, and therefore, always show the information.

When touchstart occurs and someone clicks on a touch device, it unbinds the function and never receives the class.

The down side, when you first load the page, until you mouse within the document you will see the information and then it will hide once you mouse anywhere. Adding a transition on the opacity will at least ease this so it’s not so jarring. Maybe you might even like it as an indicator to your users that there is more info???

This relies on touchstart running before mousemove, which in our limited tests it has. Please let us know what you find if you can test it out! Thanks!

Check out this Pen!