Hi Mike!

I've used Framer and Principle for prototyping UI animations. Both have their strengths and limitations. Framer is the most flexible of the two and I really like how well it integrates with Sketch. That's handy.

The biggest draw back of either of those, or similar tools, is how little can transfer over to production code or assets. You usually have to entirely rebuild it for production, which can be a deal-breaker.

I really like prototyping animation ideas in CSS and JS whenever possible. It can feel slower at first, but there's a better chance some of the code or assets can be reused, or at least be a starting point, in production.

Good for you for taking on teaching! That's such an important task, and a challenging one!

I think focusing on teaching your students a well-rounded approach to the basics of front-end dev is a good approach to take. Trends and tech change so quickly on the web, but anyone with a solid foundation in code (HTML, CSS and JS) and an appreciation for what makes good UX will always have the tools they need to keep up. It's those basics and the people skills that make for a strong web career!

My first impression of a site is always based on the design for sure. If the site looks interesting or unique visually, I'm more likely to stick around and see what's there.

Good design absolutely can build trust between users and a company. I think expressing your brand's personality or point of view in your design choices is essential to creating any kind of emotional connection or being memorable for your audience.

For me personally, this is especially true when a design looks really dated. It's hard not to feel a bit uneasy when going through a checkout process that looks like it was designed10+ years ago and hasn't been touched since!

Oh, this is a tough one. There are so many possibilities! One thing I think will be a big trend in 2017 is VR and web VR. With things like AFrame it's easy to experiment with and it's so new there's so much to be explored. And hey, good animation skills will be helpful for all that VR stuff too.

Hi Marsha! There are a couple of other options for making SVGs besides Illustrator, Sketch and Ink Scape will both author SVG files. I'm not a huge fan of Sketch for SVGs, personally, but that might be because I've used Illustrator for so long. I don't know too much about Ink Scape but I've heard good things so it sounds worth a try at least.

Hi Ida!

Some things I would love to see come to CSS in 2017 are subgrid and 3D CSS transforms on child SVG elements.

Everything I've heard from Jen Simmons and Rachel Andrew lately has gotten me super excited about grid and what it's going to do for layout on the web. And it sounds like it will be more powerful and fleixble with subgrid too. (If it's not already on the roadmap for support.)

Not being able to use 3D CSS transforms on elements within an SVG gets me every time. I keep forgetting that it's not possible. I should probably ask for more SVG attributes to be accessible via CSS first, but this one is top of mind right now.

I'm also excited to see where the Motion Path Module goes in 2017.

Hi Regina!

I'm a fan of both system fonts and web fonts. It's definitely okay for web sites to use system fonts. Combining web fonts and system fonts in a project can be a smart solution. It depends a lot on the project itself of course. Some projects really need high end web fonts to do their thing, and others can get away without them.

For most client projects I'll use either Typekit or Cloud Typography manage my web fonts. For demos and tutorials I tend to use Google Fonts (which has gotten a heck of a lot better than it used to be!). No matter which one you use, always give your font stack a little extra attention. Having more than just your web font and "serif" or "sans-serif" will make your typography stronger across all the various devices and contexts.

p.s. My two favourite system fonts are Georgia and Verdana. They're some amazingly hard working and durable fonts.

Hi Michael!

Personally I'm not a big fan of layout frameworks. They can make it difficult to make unique or interesting design choices and usually lead to having lots of unused code bogging things down.

I think layout frameworks can be a good solution for certain projects, but I don't think they're the right answer for every project. And they definitely feel overused these days.

I might recommend them for prototyping out a quick solution but I find that developing a design system and creating the layouts and components a specific project needs is a more enduring approach.

Hi Patricia!

Accessibility is definitely important. And there's so much to learn about it!

As far as accessibility and web animation goes, animation can both help and hurt accessibility. Animation can help by reducing cognitive load or making things easier to understand or follow. But it can also have some negative implications for folks with vestibular disorders or other conditions.

I wrote about some of the implications for folks with vestibular disorders and what to do about it on A List Apart a while back: alistapart.com/article/designing-safer-web-animat… and I have a whole chapter on animating responsibly in Designing Interface Animation (rosenfeldmedia.com/books/designing-interface-anim…). There is definitely a lot to be considered.

My general advice for animating responsibly is to make sure any animation you use has a defined purpose (branding, UX, etc..), provide meaningful context for large amounts of animation so people aren't ambushed by something they aren't expecting, and give users control whenever possible. Offering some method for reducing animation can be a welcome compromise in cases were large amounts of animation are called for. (http://holohalo.net/ does this well). There are some efforts in the works to make this idea of reducing motion easier which is really great.

The dev stack I use changes a lot per project. Since most of my work is done as a consultant, I use whatever my client's current set up is for the most part. I like how that lets me try out lots of different ways of getting things done.

When it's up to me, I like to keep my dev stack as simple as possible. If I can get away with just Sass, autoprefixer, grunt, and minimal JS libraries, I totally will.

As for Pittsburgh hills, Squirrel Hill has the best name and Polish Hill is the most useful. A former co-worker showed me how to "cut across the hill" a few years back and it's still the most Pittsburgh thing I know how to do!

Oh, that's a fun one! I think projects that involved random numbers for colours or positioning elements can be super fun and easy for beginners. Animation is always a hit too. Getting something moving on screen with code is always a fun moment for folks that are new to programming. (And it's super fun to teach!)

If you haven't read it already, Learning Processing is my favourite intro to programming book. I love how it gets you making things, even if they're just small things, right from the early chapters.

I both like and dislike Material Design :)

I really like that it's gotten more web folks thinking about motion as design element and how to do it well. Material Design's motion guidelines was the first time most devs had ever seen motion handled as something that applies to UX and good design. And that's great! I love the discussions around animation that get sparked from this. (And there are some very smart folks behind Material Design's motion guidelines.)

On the other hand, I don't think it makes sense to build 100% with Material Design's framework if you're not making something for Google or Google's ecosystem.

Material Design is Google's take on how design should be. There are some solid points and lots of good general rules in there. But Google's branding and point of view are also in there. It doesn't make sense to use Google's branding and point of view for something that's not related to them at all.

I think the better approach is to take what you like about Material Design but put your own spin on it. Add your brand or product's point of view to the general best practices that are in there instead. I don't think adding that point of view is ever a waste of time.

Hi Matthew!

Ah, yes. The before actually designing phase :)

I think it's important to take the brand or product's personality and point of view into account. That's something that should be reflected in the design of any new project. Establishing what the point of view is, and some general guidelines of how that should get across, helps you evaluate design decisions along the way.

Also the goals of the project from the audience's perspective. What is the main thing that a person needs or wants to accomplish on this site or in this app? Knowing that helps to keep the design focused and help you prioritize where the the design efforts should go.

Hi Jonathan! That's a good one! I'll try to make it a proper list:

1) Learn the foundations of CSS & HTML without frameworks or pre-processors

2) Learn the foundations of vanilla JS (Both of these will help you debug your code more easily and learn new frameworks/libraries/tools more easily.)

3) Learn some basic visual design and typography principles. (Even if you never call yourself a designer these will come in handy.)

4) Practice writing and sharing what you learn. (Communicating your ideas well helps others learn and is key to getting promoted.)

5) Read up on the history of the web/web design (The web things that came before now are both interesting and informative.)

I could probably make a longer list, but I think that's a good set of 5 to have :)

Hi Matthias!

Thanks for reading the pocket guide!

I think browsers are well equipped to handle heavyweight animations and even parallax. Browsers have gotten much more performant with pretty much every kind of animation in the last few years. It's still possible to push their limits of course, especially with webGL and such, of course.

In most cases I've seen, parallax preforms poorly more because it was implemented poorly. It's possible to make performant parallax animation but only if that's a priority, and it doesn't always seem to be, sadly. Paul Lewis has written a lot about how to make parallax performant, developers.google.com/web/updates/2016/12/perform… and his other articles on the topic are worth a read.

That's not to say that parallax should be everywhere on the web. It's a pretty heavy-handed effect and if it doesn't fit the context or the content even the most performant parallax isn't going to be a good experience for your audience.