Why Being Too Polite in Web Design Is a Bad Thing…

“You’re too polite.”

These are words that were said to me the other day about my work by my frequent collaborator and brilliant designer, Dan MallWas I offended? Definitely not. I was reaffirmed. I had these thoughts about myself with the way I work as a web designer but couldn’t put it into a simple phrase. It resonated with me.

What does it mean to be “too polite” as a web designer? Here’s an example of our workflow to explain:

  1. Dan provides some art direction by spitting out the first draft homepage comp for a website redesign.
  2. I go into Pattern Lab to use what Dan has in mind for the design to style my already stubbed-out bland vanilla components.
  3. We both look at what I have created in code and iterate over the design with tweaks and changes, whether it is in the browser or a spot comp.
  4. We move onto a detail page template. Another spot comp is made, this time with some buttons and links that are styled differently than the homepage comp.
  5. I build it and style it in Pattern Lab again so it is in working code. We look at it, Dan suggests some things, and I make the changes in the browser.

This is a rough idea of how things went on a recent project.

The problem:

I just kept building stuff out the way Dan wanted me to build it out.

What is the matter with that? 

I never challenged Dan’s design exploration of changing up button and link styles. I just did it.

While Dan is a hell of a designer, it is my job as a developer to look at his designs, ask him why he changed his styles to something different, and collaborate with him to come to a good compromise on a few button and link styles to use in the site or design system. The same goes for him as a designer. After I challenge his designs, he should ask questions about why I think this is a good or a bad idea and challenge my reasoning. Compromise are key here, but both sides can have strong opinions. Don’t let your ego get the best of you, though.

You need compromise because the more styles you add, the less cohesive the site/design system gets, the larger your project size gets, and the more time and effort you need to maintain all of the variations of components as this site/design system develops further.

While we work in a very collaborative fashion (don’t go chasing waterfalls), it is necessary to ask questions and simply talk.

Dan’s role is designer in this project. He’s in charge of making this thing look good by exploring different paths early on that represent the values and brand of the site/design system we are creating.

My role is frontend developer in this project. I am in charge of building this stuff out as well as keeping the components of the site/design system organized and consolidated. 

Dan isn’t in charge of the organization and consolidation of components early in the project. I am. Sure, Dan needs to be aware of keeping variations minimal for an initial launch, but the majority of the responsibility lies on my shoulders. Because of this, I need to challenge his decisions when his art direction takes us off the path away from this consolidation and organization.

I have worked with clients who are also “too polite” as well. Their culture is built around their designers comping and then throwing it over the cubicle wall to the developer to build out. The designer says, “Do this,” and they do it. No challenge. No discussion. The developer is challenged by a designer building something a certain way that can’t be implemented or is difficult/unreasonable to implement in code. But, yet, the developer forces it into place because the design was confirmed by the executives/product owners without taking into consideration the actual product being created. Don’t be a pushover. Be constructive. Don’t be a jerk, though.

The key to fixing this is by having the designers and developers talk about the design while the work is still in progress rather than after the fact. This way the designer understands why you are questioning the 30 button styles he/she has comped up while the developer also understands why the designer styled these components the way he/she did. Better products are made this way.

The “I want this thing this way, now make it so” process needs to stop. Change it to an “I want this thing this way, but let’s talk about if it makes sense, let’s compromise, iterate, and then make it so” process. It may seem like more work initially, but that little bit of extra time will save you the mass amounts of time trying to put out fires later on.


Introducing Style Guide Guide, Gatsby Edition!

Brad Frost and I are happy to introduce to the world a new React-based Style Guide Guide, Gatsby Edition! Brad and I built the design system reference site boilerplate Style Guide Guide a year of so ago that used Jekyll and regular HTML, CSS, and Javascript to build it out. Because more and more companies seem to be turning to React for the base of their work (because it is the new hotness), we decided to build a clone of Style Guide Guide, but one that is built in React-based Gatsby and not Jekyll. Both of these style guide guides have been created from client projects that actually used this setup, which is pretty cool.

style guide guideStyle Guide Guide, Gatsby Edition gives a head start to companies or anyone to take what we built and use it for their own use to build out a storefront for the shiny patterns, guidelines, and principles that revolve around a design system. It also gives some good examples on where to find inspiration for the different sections of the Style Guide Guide, like accessibility for instance. It is intentionally built to have basic functionality and little style so that it can be reused by different companies to put their own brand and style on this.

While a design system should be a language agnostic platform, it doesn’t hurt to build the storefront of the design system in a way that represents the company and in a way that is easier to port over components from actual products that use this language. With a company that creates a bunch of React-based applications, this is probably a better option than the vanilla Style Guide Guide because it would be easier to port over components from a React-focused platform to another React-focused platform, rather than jumping through more hoops to get to that point. It is important, however, to always have some way to get regular HTML though, since the newest shiny thing will not always be React.

Similar to the vanilla version, this project uses Markdown files in the content folder to create the actual data that Gatsby sucks in. The components folder within the src folder houses the components that are being used to build Style Guide Guide. These are not the components that will get imported into the actual component detail page as variations (i.e. the Card page under Blocks and Cards) since we want a separation between the structure of this site and the design system that powers the company’s actual products. The examples live in ds-components, and then are sucked into ComponentExample in the src/components folder.

component detail

We tried our best to make it very similar to the Jekyll version in terms of structure to help learn how to use this quicker if you are familiar with the vanilla Style Guide Guide or Jekyll in general. There are some things that are still in flux that would be great to get help with:

  • The components themselves could use a better way of being included (more dynamic way since it is pretty manual right now). Also, a flatter file may be better for importing from more workshop-like environments like Storybook.
  • There is no iframe yet for the component example, so there isn’t the ability to resize this component based on the size of the iframe.
  • Getting HTML and React code snippets formatting better (indentation, line breaks) and getting the actual component tag to show up in the React tab.

I’d say aside from the items in flux, the site is pretty much identical to the Jekyll site in terms of the main tasks of this product. I’m sure the great web community will find other issues and improvement suggestions as well, and that’s fantastic. We understand this is an MVP and can use some love. We hope this can help you and your teams with future design system work! Thanks for letting us share this with you all!

Personal Note

This project allowed me to embrace React more, dig in, and actually learn how to build these components with reusability in mind. If you are familiar with React, it is easy to get caught up in the context of a component rather than reusability. With reusability in mind, I was able to build components that on a page/template level was context based, but on a component level was more generic. With any newer product, there is some struggle, but in the end you start to get it and feel good about yourself for learning it. I am happy with the progress but I will continue to get my hands dirty with React until the newest hotness appears on the horizon. Thanks!

30 Years of Living, 30 Items of Lessons Learned

30 things I have learned in the exactly 30 years I have lived:

  1. Good family and friends makes a big difference
  2. Laugh every goddamn day
  3. Be a nice person and people will usually be nice back
  4. I will always quote Dumb and Dumber, Tommy Boy, Happy Gilmore, Billy Madison, and Forrest Gump no matter how old I am.
  5. Enjoy both work and your life. Otherwise, one of those will get to you eventually.
  6. Giving to people is better than receiving.
  7. Failing my first calculus class freshman year of college was one of the best lessons of my life. It taught me to work my ass off (my entire meteorology program taught me that actually)
  8. Be grateful every goddamn day.
  9. If you predict your life 10 years from today you will be wrong most of the time. Was I planning on being a web designer 10 years ago?
  10. Being a meteorologist turned web designer always turns some heads
  11. Helping people out is why I have enjoyed working in the fields I have worked in.
  12. You’re only as old as you feel and act. Hell I act 15, so therefore I’m 15.
  13. Never stop trying.
  14. Never stop learning.
  15. Never feel sorry for yourself, because there is always someone out there in a worse situation.
  16. Force feed positivity into negative situations.
  17. Quit it with your damn temper, Ian. My wife taught me a lot about dealing with that.
  18. 30 is the first start of a decade where most people aren’t in the same situation. Some are single, some married, some with kids, some struggling to make ends meet, some successful, some posing with Buddy the Elf cardboard cutouts.
  19. Go with the flow, but create your own path at the same time.
  20. I’m a better listener than talker.
  21. If you’re not happy change it.
  22. Luck plays into your life occasionally. Sometimes it’s bad luck, though.
  23. Do what you enjoy doing. I love hiking and basketball. I will never stop doing that stuff because it makes me happy.
  24. Make people laugh. I hate serious situations or really fancy restaurants because it makes me uncomfortable. Crack a joke or quote, “Lieutenant Dan ice cream!” at your fancy dinner.
  25. Exercise. I used to take 4 hour naps freshman year of college, then I found lifting weights.
  26. Indulge every once in a while.
  27. See the world. I’ve been very fortunate to do this and it teaches you a lot about yourself and society.
  28. Stop comparing yourself to others. You control your fate, not anyone else.
  29. Hockey is the best sport to watch on TV and live. I thank my college roommates for getting me into it. P.S. Let’s go Pens!
  30. Be yourself, just don’t be an asshole. People will like you for you. If they don’t, they’re not worth putting an act on for.

Ode To Gramps


“Uncle Bob”

To me and many of his other grandchildren: “Gramps.” 7 children. 13 grandchildren. 10 great-grandchildren and soon to be 11. He wouldn’t have it any other way as he showed how much he loved his family every single day. His love for his wife, family, and life in general was out of this world.

He was married to my Gram for 62 years before she passed away. They met at Mercy Hospital in Pittsburgh, as she was a receptionist there when he worked there. They took in extended family members who were struggling and treated them like their own. Their love and respect for each other are a stunning example of true love. They are both true role models of mine.

Gramps’ storytelling skills are the best I’ve ever seen, drawing in both the oldest and youngest family and friends to quiet down to lend him their ears. From him and his brother creating scuba helmets out of cut-out, old rusty barrels and going down to the creek to test them out in Patton, PA to their family cow getting loose and ending up at the movie theater in town, his stories never got old, no matter how many times he told them.

His humor. Holy shit. He will always be the funniest person I will ever know. His laughter and happiness was infectious.

“You’re looking good today, Gramps.”
“Well, that’s because you’re looking at the wrong end.”

He enlisted in the military during WWII and was stationed in Washington and Alaska.

He was a doctor for over 50 years, starting off in general medicine as one of the few doctors in the North Hills of Pittsburgh and eventually transitioning to an eye doctor in the 1950s. He wasn’t your doctor-of-today though. He would have to make house-calls in the middle of the night to deliver babies while old Miroslav (or insert Slovak name) would be revving his motorcycle in the basement. His payment: $25 – $30 for twins or manure for his garden sometimes. He was my eye doctor for a good portion of my life. He would have people come up to him and church, thanking him for taking care of their sick family member or delivering their child.

He was an entrepreneur and incredibly creative, always building or fixing something. He loved riding up and down the hill in his backyard on his tractor. He loved it so much that he fixed the same tractor for at least 3 decades. He built a dirt tennis court in the backyard along a steep hill and put in an in-ground swimming pool by directing a natural spring to fill it. It was 60 degrees when we’d swim in it, but we didn’t care because it was a blast. The spring would also keep our pop cold while we swam.

He was a musician, playing songs on the piano with my Gram or upright bass with his family and friends in the backyard. They both definitely ingrained the music bug into me and much of my extended family.

He was an insane cross-country runner, running at Franklin & Marshall. Him and his team were honored in the early 2000s for their championship in the early 1940s.

He accomplished so much in his long, almost 95 year old life, but yet he was so humble. He never had to brag, but the people who he surrounded himself with know how incredible he was. They know they were lucky enough to spend time with him. I know I was lucky enough to spend 29 years with him. His stories, lessons, compassion, and impact on so many people’s lives will continue on with the people he touched so deeply. Your memories will forever stay with me. I’m proud to call you my Gramps. You are an inspiration to us. While I am sad you are gone from this Earth, I am so happy you are reunited with your true love, Gram, in heaven.

“Here’s a dollar. Go buy yourself a root beer.”

2017 Web Roundup, Gratitude, and Looking Ahead

On a macroscopic level, 2017 was not the most favorable year in terms of morality and humanity in my opinion. However, I try to look at the glass as half full. I have seen people care more about what is going on in the world and about the rights of other human beings. I hope that continues, because at the end of the day, humanity should come down to feeling loved, happy, and healthy and wanting that for others, too. In order to do that, we need to help and care about others. Keep doing that.

On a more personal scale, 2017 has been a great one. It has been another year of learning in the world of web design. I am fortunate to work with wonderful people on some amazing projects. Here are some of those accomplishments from the year:

  • Celebrated my 2 year anniversary switching from meteorology to web development working with my brother, Brad Frost at Brad Frost Web.
  • Finished up building my first design system for ExxonMobil in early 2017. Probably the experience of 2016-2017 where I learned the most, felt the best about our code after building it, and really enjoyed working with their team and my team.
    Screen Shot 2017-12-15 at 11.35.46 AM
  • Redesigned the Harvard Business School Digital Initiative website and style guide. I built the front end of the site and the corresponding style guide. It was an honor working with their fantastic team and very humbling to be surrounded by so many interesting and intelligent people. It gave me a better perspective of the Harvard brand and how truly welcoming and down-to-earth the folks were there.
    Harvard Business School DI site
    Screen Shot 2017-12-15 at 12.10.18 PM
  • Built my first Shopify site for a friend and local company in Pittsburgh called Puzzle Pax. I had worked with Jekyll before so using Liquid was fairly straightforward and it was the first site taking on the design, development, and CMS work without another person to back me up. It was a great learning experience and favor for a friend.
    Screen Shot 2017-12-18 at 10.38.58 AM
  • Built a Jekyll site in twelve days with Brad for the Brian Forde For Congress campaign. It was the quickest project turnaround I have had and to be honest, was fun to build and put the pressure on. It was also great meeting Brian and reading about his views on the country and his accomplishments.
    Screen Shot 2017-12-15 at 12.06.48 PM
  • Started building a design system for a company that eventually didn’t use anything we helped build and went in a separate direction.
  • Other various projects and tweaks. Pattern Lab demo development. Frost Finery website tweaks. Helped a tad bit with the redesign of bradfrost.com. Helped Brad build out a few components from several different sites the day before a workshop on design systems. A few other personal/internal projects that tend to get pushed to the side when bigger projects come to fruition and then returned to later.
  • Took more than 100 trips to the post office and fulfilled well over 1,000 Atomic Design books (also helped redesign the shop page to its current state in Shopify). Very proud of Brad’s success with the book, but man, a week without going to the post office would be great.

It has been a fairly busy year. It has been a year where I feel like I have finally settled into web development, while still feeling like I do not know enough about it after looking at the incredible stuff other people are creating. That being said, I am looking forward to my current and future work in 2018:

  • Redesigning a larger company’s websites and building a design system alongside these sites. I am enjoying working with my team and we are doing some really awesome things with implementation of patterns into the actual site.
  • Redesigning a friend and local company’s website. The current site needs a lot restructuring, love, and responsiveness, so I am looking forward to helping him out and hopefully improving his user experience, ability to write content using a proper CMS, and business in general.
  • Potential web site and design systems projects are in the works, but nothing is set in stone at this point. I’m always looking forward to helping people out with a website redesign, style guide, or design system work. I learn something new from each experience.
  • I hope to redesign this website, because I haven’t had much time to dig into it and it hasn’t been designed since Brad set it up for me when I was a meteorologist. I started, and like many other lower-priority projects, it got pushed to the side. I really wanna get this done so it doesn’t look terrible.
  • I hope to share what I’ve learned with other people somehow. I’ve thought about teaching a basic WordPress class or the way we build websites, but I’m not sure what I want to do yet. The web community has been great to me the short time I have been involved in it and I want to do the same for others. Helping people is one of the reasons I got into meteorology and I want it to continue with web design as well.

I have been very fortunate to work on some pretty amazing projects, but they wouldn’t have been as amazing without my teammates. I also want to thank the speakers at Clarity Conf. Thanks to these special people:

  • Brad Frost – Always thankful to have him at my side (literally, since we sit next to each other in the office) building great things on the web. Always grateful for him allowing me to work with him after I moved back to Pittsburgh. It has been a cluster of fun, mistakes, learning from these mistakes, lunch break jamming, late nights, and organized, thoughtful web work. Over 2 years working together and we still haven’t beaten each other up. I guess the 18 years of sleeping in the same room helped with that.
  • Dan Mall – An amazing designer, project head, colleague, and, most importantly, friend. I’ve had the honor of working with him on several projects and he never fails to amaze me with his designs and knowledge in general. Whether we are in a project meeting or playing basketball north of Philly until 2am, he’s a great guy to be around and I am thankful for that.
  • Josh Clark – An awesome project manager, facilitator, project politics absorber, colleague, and friend. He’s the guy who could make your worst day into the best day. He can turn the mood of a bad meeting into butterflies and rainbows by the end of it. I am grateful for him for allowing me to work on projects with him as well as picking me up when I my confidence slips in the wrong direction. You da best.
  • Jesse Gardner – A fantastic WordPress and backend guy who I worked closely with on the Harvard Business School Digital Initiative project. A guy I can now call my friend after working with him. I appreciate his willingness to help me out when I needed it and for putting up with my requests when I was feeling a bit behind or confused. Definitely a guy I would like to keep around since he is a positive influence on people’s lives and knowledgeable about WordPress and SEO stuff. Thanks for the good work!
  • Kevin Hoffman – The guy that I had heard a lot about from lots of people but never had the opportunity to work with until the Harvard Business School Digital Initiative project. He is a magician with UX, strategy, and pulling people into his very organized methods for working together. He’s a guy who I could talk to about random, goofy subjects when I was feeling a little out of the loop when conversations turned to the topics like Bitcoin. You know you will be friends with him when you pull a Lady and the Tramp with a donut in Boston. Thanks for your help!
  • Abby Fretz – An awesome producer who would make sure to DM me in Slack to make sure I got my shit done on the Harvard Business School Digital Initiative Project. Super down-to-earth and very professional, she knew how to keep everyone on the same page during the project. I am happy to now call her my friend. Thanks for always keeping me on my feet and keep making that honey.
  • Octavius Newman – A great designer and comic book/movie guru. Was a pleasure working with you on the Harvard Business School Digital Initiative project. You have such a thirst for knowledge. I envy your ability to ask questions and speak up when you don’t know something or when you have an opinion. Thanks for being a good dude and friend.
  • Jamie Kosoy – What can I say about him? He’s a ridiculously talented developer who has been building web stuff since the 90s but somehow manages to take the time to teach someone like me who is newer to the game. I am thankful to get to work on our current project together and hope to learn more from you. I’m glad that we can goof around and do incredible work together. I’ve thoroughly enjoyed it.
  • Crystal Vitelli – Am awesome person to handle the politics of a big project like the current one we are working on. Great with strategy as well as making sure our team knows what is going on from all of the angles information is flowing in from. While we haven’t talked much, it has been a pleasure getting to know her and I look forward to building great websites and design system with you. Thanks for all you do.
  • James Hall – A very talented backend developer who somehow managed to understand what we were writing on the front end and implement it into the actual website. I’ve appreciated the random movie/television quotes and GIFs as well. Glad our humor is on the same page. Thanks for the help with this current project.
  • Jon Jackson – An up-and-coming designer who I had the chance to meet before we even worked on this current project. He is someone who wants to learn from anyone he meets and has done a great job on this current project. I can relate to him since he is newer to the web design world, so it is great to see the parallels there. Thanks for helping with the design of this current project.
  • Mary van Ogtrop – Fantastic copywriter who seems insanely busy but somehow manages to make time to talk to you about writing copy. While I haven’t talked to her too much during the project, it is great to work with a copywriter to see some of her process and I look forward to her continuing work. Thanks for helping with the project.
  • ExxonMobil Team – Working with them was awesome. It was a great experience building the design system along with them, hearing their questions and concerns, and transforming our project plan based on their feedback. It was also great eating Torchy’s and listening to Journey together.
  • Harvard Business School Digital Initiative Team – I can say nothing but kind words about them. They are all some of the smartest people I have met, but they also are some of the nicest, down-to-earth people I have met. They didn’t make themselves out to be more important than anyone else on the project and were a fantastic group to work with (especially since they brought in delicious donuts…twice). Thanks for being a wonderful and cooperative group to work with.
  • Clarity Speakers/Organizers: Jina, Cameron Moll, Debbie Millman, Una Kravets, Abi Jones, Cap Watkins, Diana Mounter, Elyse Holladay, Henri Helvetica, Isha Kasliwal, Josh Silverman, Linh Yao Pham, Mina Markham, and Miriam Suzanne – Thank you all for a great conference and for sharing your knowledge with me. I learned a lot. It was a pleasure getting to know some of you and I look forward to seeing what great stuff you continue to build and talk about in the future.

Thanks to these folks and everyone else who made 2017 a fantastic year. I don’t know what will happen in 2018 but let’s keep creating, building, and making the web great! May everyone have a safe holiday and a happy and healthy new year!

2 Frontend Designers. 12 Days. 1 Website. How We Did It

Brian Forde screenshot

  1. Stock up on La Croix.
  2. Make sure another big project is going on to make things even more challenging
  3. Make a great website using guidelines we have used in all projects starting last summer as well as quick and efficient design themes.

The Client: Brian Forde. Who is Brian Forde you ask? He worked under former President Barack Obama as the Senior Technology Advisor. He helped launch President Obama’s Climate Data Initiative and, as a former practicing meteorologist, I think that is fantastic. He’s running for Congress in southern California and after talking with him, he seems like a good, down to earth guy with a positive message.

The Site:  forde.com.

The Start

On Friday July 7th, the project began. When I say the project began, my portion of the project began. Brad got contacted by the client a couple days before and agreed on a launch date on July 19th. For those who don’t understand web design, most projects I’ve worked on take about 3 months with more than 2 people doing the design and frontend development work. Brad agreed to do the work with the deadline in mind. As for me, I am currently involved in another big project and thankfully it was in a bit of a lull period from the development side of things, so I agreed to help Brad out. Like with most projects we do anymore, Pattern Lab was the tool of choice. Why use Pattern Lab when we could just crank out everything on the actual site?

  1. Brad and I do our best and fastest work in Pattern Lab. Mustache is a great thing. Gulp tasks are great things. Build fast; build efficiently.
  2. Doing your work in Pattern Lab allows you to create pages and templates as well as a pattern library/pattern playground for your client.
  3. Atomic Design. Brad knows a little bit about that.
  4. Pattern Lab is where I learned web design. Yes I took codecademy classes and read books to learn too, but getting my hands dirty in Pattern Lab allowed me to fail and learn from my mistakes.

A little nervous of the timeline, I dove into the project with Brad. We cranked out components based on one comp with colors and a few grayscale comps that we received from the client. Did we use these comps? Sort of. Did we use the colors in the one comp? Only for one of the theme options to see what it would look like. Why? Because every site we make we care about the identity of the client and, frankly, the colors in one of the comps weren’t working for what we wanted to build him and how the public would perceive him solely from the website design.

We built a collection of components in Pattern Lab and the general IA (example of it below included between a header and footer) of what content should go where. Grayscale components nonetheless, but these grayscale components are the foundation of iterative workflow. These would change a bit over time and that is okay. Our process starts with building the foundation. Then we add styles. Iterate. Massage styles. Iterate. Massage. It’s a great workflow, and it all happens within code, making it easier to get the ball rolling and easier to import into the actual site.

Screen Shot 2017-07-20 at 12.21.04 PM


The Design

We now had the components and some sort of wireframes set up in PL. We needed a design direction quick. Brad set up a short 20-second gut test of sites for Brian’s team to look at and react to. I took notes on their reactions, especially Brian’s. After that we had an idea of some of the key desires they were looking for in their website. Bright colors, strong calls to actions, clear forms, as well as other points. We had their input. We just needed the design direction, which brings me to my favorite part of this project: building a theme and logo switcher with Brad. How did we do that? 6 buttons (5 themes and a logo button), some JavaScript, and two-tiered Sass variables that could be overridden depending on the 5 separate theme-CSS files we activated. We built it out, chose some color schemes, called the Brian Forde For Congress team. We were able to switch through different colors, fonts, etc. with the click of a button and we were able to switch through some of the logo designs they had sent over. I recreated the process below (obviously we used actual logos and font-sizes were better executed during the meeting, but you get the idea).  Brian was fortunately sold on the one theme and we had an art direction in a half hour meeting.


Bringing It All Together

Grayscale components. Check. Art direction. Check. The good part about the theme changer was that I could kill all the other themes and implement the theme they chose right into our Sass variables. Quick and easy. We replaced the placeholder blocks in the wireframes with actual components. We used CSS Grid Layout and Flexbox for layout-specific elements, making this the first project we used CSS Grid Layout on. I have never used floats in a project (aside from a text passage image), which shows how new I am to the web design game. For someone who is progressive like Brian and former Senior Technology Advisor in the White House, it only made sense to use the latest and greatest in CSS. The pages in Pattern Lab looked good enough to start implementing into a CMS.

After many iterations, this grayscale hero component…

Screen Shot 2017-07-20 at 12.05.58 PM

would eventually become…

Screen Shot 2017-07-20 at 12.06.12 PM

Building the Actual Site

The great thing about Pattern Lab is it all renders as HTML, CSS, and JS. The other great thing is while we built patterns in Pattern Lab, we could copy some of the key patterns into the Jekyll site, the CMS that would be used to spin up the website. Why did we use Jekyll instead of WordPress? Mainly time. Jekyll spins up static sites quickly and easily, and that’s what we needed with the website MVP. Is WordPress easier to use from a content management standpoint? Probably, but it is much slower to build out components and pages for a project consisting of mostly static pages anyways with only a little bit of functionality.

Most of the production work took place in Pattern Lab. Once the pages were built, we took some of the organisms (aka more complex components) and manually copied them over into the Jekyll site’s includes folder. This way we could include the same pattern on multiple pages. We built out the templates from Pattern Lab in the layouts folder of the Jekyll site. We managed the content of the pages within markdown files located at the root of the Jekyll site. With some help from the liquid templating language and some placeholder content, we were able to scaffold out the site. We would use Pattern Lab to massage the CSS further (adding box shadows, background bands, and spacing to add dimension). I then added a gulp task to copy over the CSS, images, icons, and JavaScript from Pattern Lab into the Jekyll site. All looked good in Chrome. But Safari, Firefox, and the dreaded IE/Edge were next to test.

Testing and Finishing Touches

Brad did the majority of the IE/Edge testing. I took on a bit of the small screen tweaks as well as Safari and Firefox testing. We included fallback CSS so browsers that don’t support CSS Grid Layout would look solid, but there were still some tweaks with the forms and other grid items. He realized that there needed to be wrappers around items within a grid component for them to render properly in IE/Edge. All the bugs were fixed. We had a site built! A day was left until the potential soft launch. Hoor…oh no…icons. IE/Edge does not like external source SVGs for some reason. We used a script called svg4everybody but that wasn’t working. Brad spent hours on it. We slept on it (sort of). I came in the next day and had to use my own personal site to test the SVG icons being included within the project. I ended up changing the script in the head to the one we included in another project. Refresh. Voila! Icons were showing up! We jumped for joy when we saw this. Were we done? Not yet. Brian and his team had to replace our placeholder content in markdown within Jekyll and we had a few content additions and design tweaks. By Wednesday afternoon, we finally finished the MVP site. Wednesday evening we launched the site with their team. Finally we could say, “Hooray!” I am hoping that all of the hard work we put into this project so far leads to a win for Brian.


Hard Work Is…

Hard work.

What is it?

Who does it?

Where is it?

Hard work is the nurse who cares for patients and cleans up their bodily fluids during a 12 hour shift while studying to be a nurse practitioner during every moment outside of work.

Hard work is risking your content life in your current location to move and work tirelessly to start your own businesses and improve your quality of life.

Hard work is growing up putting cardboard in your shoes during the Great Depression, becoming a doctor, and raising 7 kids.

Hard work is a refugee leaving the violence of his home country after losing family members to work a convenient store job just so his kids can grow up in a country that provides opportunity.

Hard work is a coal miner crawling through the mines overnight, risking his health to provide for his family.

Hard work is someone who loses the ability to walk in an accident and raises funds to build a center to help those in similar situations.

Hard work is putting your kids’ needs before your own, even if it means not showering for several days.

Hard work is a meteorologist working an entire day during a tornado outbreak to help save residents’ lives despite making slightly more than minimum wage.

Hard work is a deployed member of the military not only fighting for the freedom and safety of America, but for the stability and safety of other countries.

Hard work is a minority fighting for basic human rights despite the immense hatred that comes from people in their community.

Hard work is a teacher who spends her own time and money on supplies so her students’ have one less worry when it comes to learning.

Hard work is a single mother working 3 jobs just so she can afford to put a roof over her family’s head and some food on the table.

Hard work is an artist who spends months working on a piece for a hospital so that it creates some sort of joy and hope for the patients’ there.

Hard work is growing up in Section 8 housing and finding a way to graduate from college to make a better life for yourself.

Hard work is working 21 straight hours to finish a project on time.

Hard work is helping others in need even if you need a little help in yours.

Hard work is taking a stand for what is right when right isn’t in the majority of opinion.

Hard work is accepting that people may look, act, or believe in something different than you and having the empathy to work together to make humanity better.

Hard work is not about gloating.

Hard work is not easy.

Hard work comes from learning from failure.

Hard work is taking risks.

Hard work is having aspirations.

Hard work starts with you.

Hard work can change lives.

Learning the Web Using Atomic Design

As many of you web designers and developers know, my brother Brad Frost’s book Atomic Design has recently been released into the wild. As many of you may also know, I work with him. What many of you don’t know is the way I learned web design was through Atomic Design. After packaging up tons of Atomic Design books over the past month and a half, I have realized how important it is to developers and designers.

The way you learn HTML, CSS, and JavaScript is not by jumping into processes like atomic design, but learning the actual languages first, which is what I did. After learning the languages via codacademy and Brad’s tips here and there, I only worked on one small project without atomic design before learning the process of it. I put it to use in the website for my sister-in-law’s jewelry company Frost Finery. Since then, I feel like most of my projects (both websites and design systems) have dealt with some sort of breakdown of components into the categories of atoms, molecules, organisms, templates, and pages. I have definitely grasped the benefits of what it has meant for me early on in my web designer/developer career.

Benefits of Learning Through Atomic Design

Although it is perfectly acceptable to learn web design in many different ways, I feel atomic design has a lot of benefit. The way I learned was through Pattern Lab, an easy-to-use prototyping tool that you can clone from GitHub. I use the mustache version because that was one of the only versions before the new version of Pattern Lab and I feel like it’s the easiest to understand for a beginner. You can also use the Node.js versions (using Grunt or Gulp). Pattern Lab helps paves the way for easier web development.

Without further adieu, here are the benefits of learning atomic design early in your career:

  • It organizes your components from small to large, making it easier to understand the structure of your site’s contents
    1. Here are some examples of each:
      • Atoms = Button
      • Molecules = Search input containing that button
      • Organisms = Header containing that search form
      • Templates = Homepage with that header at the top (“wireframey”)
      • Pages = Homepage with that header at the top but with the data and actual images included on the site
    2. I spent my early days of atomic designing (weird to say that) components caring too much about whether a certain form is a molecule or organism. Answer is, it doesn’t matter as long as your team agrees that the component’s location makes sense. No need for 500 stand-ups to decide where each component goes.
    3. Within atoms, molecules, etc., we also add additional folders in our recent projects (forms, blocks, messaging, etc.) to compartmentalize components by type. This also helps with trying to find the correct pattern in your directory.
      Screen Shot 2017-02-03 at 7.41.34 PM
  • Adds consistency across your site by reusing components.
    1. Atomic design is based on reusability. Say you build a button in your atoms folder. You can place that same button on another page or within a header and still have the same class name. This will keep a consistent theme across your entire site.
    2.  You can add a modifier class like .button--blue to .button (using BEM CSS syntax) to give the button a different background color instead of specifying where exactly the button is located in your HTML.
    3. If you are building a design system for a giant corporation like we just did, you can add theming into your CSS a lot easier by targeting less patterns since most of your base styling takes place within one class instead of multiple classes.
    4. The brand of your company’s site or client’s site can be represented across the board by keeping with consistency.
  • With reusability comes thinking about reusability
    1. Atomic design allows the designer/developer to think about each pattern and how it will get used within other components or pages in the site
    2. You can easily code a button on each page with different class names. However, if you think about how you are using the buttons you can consolidate these buttons into 1 class name and a handful of modifiers. Less CSS = better performance.
    3. You can learn more about the structure of the code with each pattern, rather than building it and then setting it and forgetting it (in the wise words of world- renowned Ron Popeil).
  • With thinking about reusability comes thinking about CSS structure
    1. CSS is another area that can turn into a rats nest if you bury a lot of class names within one another via Sass. I don’t suggest breaking each Sass partial into atoms, molecules, organisms, templates, and pages (although you could do that I guess). You should break down each Sass partial by component name (the same goes for JS before concatenation). That way it is easier to navigate to where you need to change CSS.
    2. Being that your HTML is based on component, you can do that with your CSS with classes. Start off with your base .button component. Then you can say, “Hey! I like headers and I like the color blue. Let’s put a blue button within the header.” You open up button.scss and you can either:
      • Make a modifier class called .button--blue if you use the button in more than just the header for example.Screen Shot 2017-02-07 at 10.27.16 AM
      • Or you can add a parent selector to the base button element. Using a parent selector like this allows you to focus on the button itself, rather than going to the header.scss Sass partial and sifting through all of the nested items before finding your button. It’s organized a a lot better since nesting child elements can get out of hand So the code would look like this:
        Screen Shot 2017-02-07 at 10.26.38 AM
    3. And remember, commenting is a wonderful thing. It’s an annoying task to do, but it is totally worth it when it comes to comprehension. We just finished a big company’s design system, and I will tell you that commenting on our CSS allowed two of our colleagues to write documentation on components that were mostly built by Brad and me.
  •  Atomic design stretches its hand out to visual designers
    1. If there’s one thing that helps a lot with a project is a visual designer who knows how to code. Atomic design (and specifically Pattern Lab) allows a designer who wants to code the ability to learn it without the intimidation of a large mass of code. I know a couple folks who are visual designers at heart but know how to code and have used Pattern Lab to help out with projects.
    2. If you know how to code as a designer, you can just go straight into Pattern Lab and prototype what you would’ve comped out in Sketch or in a PSD. It decreases the amount of time it takes to go from image to code.
  • Pattern Lab is designing in code. Once prepped, it’s ready to bake.
    1. Once you have your templates and pages built with all of your components in Pattern Lab, you can import the code into your WordPress project or Drupal project and tweak the PL code to fit whatever language you are using for your CMS.

Atomic design is a great method to pick up (I swear Brad did not tell me to say that). It’s easy to learn it whether you are 10 years into creating the web or 2 years into it. The web is becoming a more and more modular place to work in and less so about big “pages.” We literally went to a JavaScript workshop the other day that taught similar aspects of using a modular workflow to organize JavaScript. There’s a reason I packed and shipped a bunch of Atomic Design books across the world. Atomic design is a great thing and will only get better with the help of all designers and developers out there!

Just Wanted to Say Thanks

Mr. Feeny

There’s not a day that goes by where I don’t think of how grateful I am for things in my life. I know it can be tough to appreciate things when life isn’t going the way you want, but it definitely helps to take a step back and reflect. I recently tweeted my 5 ways to living a happier life:

  1. Be grateful
  2. Challenge yourself
  3. Laugh
  4. Stop comparing yourself to others
  5. Respect/help others

With Thanksgiving coming up, it is a time to look back on your past year or your entire life to appreciate the small and large things in your life. There’s always something. Here are things I am grateful for over the last year:

Life. I am grateful to be able to breathe and enjoy life.

My wife. Honestly she is one of the hardest working people I know and she goes the extra mile to make sure I am happy in life. She pushes me to be a better person and supports most of my decisions. After being apart for 8 years, I appreciate everyday I come home to her.

Family. I am thankful to be living closer to my family now so I can be a part of my nieces lives as they grow up and have my family’s support or support them if needed. Whether a family member is still here on Earth or have gone, every member of my immediate and extended family has had a genuine impact on my life.

My brother, Brad Frost. Without him I probably would be working some shitty job that I didn’t enjoy. Thankful to be able to work with him and enjoy it, whether it is building websites, design systems, or workbenches.

Friends. You guys inspire me everyday, whether you are getting your PhD or successfully trudge your way through a rough patch in your life. Keep the positive attitude and always do the right thing.

Travel. I am grateful to have visited some amazing places over the past year. I took a road trip with my wife from LA to Seattle in 8 days, visiting a bunch of breathtaking national parks along the way. I got to go to the Outer Banks with my family. Seeing the world makes you a better person.

Work that I enjoy. I moved to Pittsburgh 3 days before my wedding 2 summers ago, scared shitless that I wouldn’t find a good job. It has been quite the transition from meteorology to web design, but I have enjoyed every minute of it. It’s pretty awesome to say you’ve built a website with a client in the center of Times Square and that you’ve helped build a design system for one of the largest companies in the world after such a short time in the field.

Basic needs. I have an apartment, food, clothes, and a mode of transportation. Some people aren’t so lucky. After getting back from San Francisco recently, it was sad seeing how many people don’t have these basic things.

Education. You never stop learning. I am thankful to have gone to college for a subject I loved. I am thankful for the books I have read that have helped me transition from meteorology to web design.

Failure. Weird to be thankful for it, but failing in life has allowed me to become a harder working individual.

Open mind. I am happy that I am laid back and respect someone for who they are as long as they respect me. With the recent escalation of hate, I am happy to be raised in a manner where race, gender, sexual orientation, religion, and disability do not make a person any less important.

Ability to listen well. I suck at talking. I mumble and take a while to spit out a story. But I am a good listener. If you try to teach me something, I will likely listen hard. If you have an opinion different than mine I’ll listen. If you are struggling with something, I’ll listen and try to help.

To these web people who have taught me a lot about web and life this year:

  • Dan Mall – Friend, coworker, and smart dude. Honestly privileged to have worked with you and hope to continue to work with you. Thanks for putting up with me.
  • Josh Clark – Friend, coworker, and smart dude. Privileged to have worked with you and hope to continue to work with you. Thanks for putting up with me.
  • Matt D. Smith – Friend, coworker, another smart dude. Privileged to have worked with you and hope to work with you again. Thanks for working with me.
  • Dave Olsen – Friend and collaborator on Pattern Lab 2 (PL PHP guy). One of the nicest guys who seems to enjoy hiking as much as I do. Thanks for being a good and helpful dude.
  • Brian Muenzenmeyer – Friend and collaborator on Pattern Lab 2 (PL Node.js guy). Super nice and bright guy. Just don’t ask him where he’s from. Thanks for your help and being a cool guy.
  • To all authors of books/articles I have read about the web, thank you for sharing your knowledge.
  • To all speakers at conferences I have gone to, thank you for your web and life lessons. I learned a lot from you. I have written about those speakers here at Web Design Day and An Event Apart San Francisco.

An Event Apart San Francisco 2016: Lessons Learned

After Web Design Day in Pittsburgh, I wrote about my personal takeaways from the web conference. So I am going to do the same thing with An Event Apart San Francisco.

This is my second time to San Francisco and, I must say, it feels weird. My first time here was for a research meteorology internship with Naval Research Laboratory, when I rode a research vessel out of San Francisco Bay into the Pacific Ocean. This time I come back as a front end web designer/developer. After seeing the sights on Sunday, it was time to sit back and absorb as much information as possible from the speakers.

My general takeaways were similar to the those I had at Web Design Day (maybe since a few talks were similar), but with additional ones. Here they are:

  • Empathy and respect towards a user keeps coming up as a very important topic. We should treat the experience we are creating on the web as an experience that leaves both the developer and user satisfied. After all, we are designing and developing for humans and humans have emotions.
  • Accessibility remains a relevant topic within designing and developing a website. Even though a designer or developer might not have a disability, designing and developing for someone with a permanent or temporary disability is vital for them to have a good user experience.
  • Diversity in who creates the web is very important. Everyone has a different story and a different perspective on issues just like every user.
  • The user’s opinion can matter more than the opinion of the company/client. After all, the user can represent the audience better than the CEO, developer, designer, etc.
  • Technology continues to evolve and allows for more opportunity in the years to come. Embrace this and create with these in mind.

These are only some of the lessons learned, but by using these in your web work, you can improve your own practices and your website’s user experience.

Here’s a more in depth look at each each speaker’s talk:

Jeffrey Zeldman

Jeffrey started off the conference by explaining how the web used to be and comparing it how the web works now. He specifically went into the book he wrote back in 2003, Designing with Web Standards (3rd Edition), and compared it to how the topics brought up in that book stand up to the standards of today’s web. For the most part, the standards discussed 13 years ago are similar to today’s standards, with only a few tweaks here and there. This just goes to show you that although the web is ever changing, concepts we come up with now can continue to be relevant in the future.

Sarah Parmenter

Sarah went into depth about branding, a process many people link to only the logo. There is a lot more that goes into branding, including the voice and tone, guidelines, consistency, and others. It’s the way the company represents itself as a whole instead of just slapping on a logo that has nothing to do with the message of the company. She used examples like Airbnb to show how they rebranded once they became more than just a “couch surfing” organization. There were a lot of points that you don’t think of when you look at the branding of a company.

Krystal Higgins

Krystal discussed the importance of creating a separate experience for new users, but one that works with the consistency of the brand. One of the most important things she mentioned was to cater the experience in way that efficiently explains or shows the user what to do. Getting first-time users to subscribe/register for your product is important, but retaining them down the road is just as important. She also went into detail about how to create these onboarding processes, mentioning ways like guided interaction, free samples, and personal focus. Guided interaction helps the user follow along with the new process, free samples feel like this new product will be worth it, and personal focus feels like this product matters to you personally. A lot of these are things I never thought about more than just slapping a few alerts on a new user page.

Jen Simmons

I had the opportunity to listen to her at Web Design Day in Pittsburgh and many of the concepts were the same. Jen describes how web designers and developers have fallen into web layouts that are quite boxy and very similar to each other. She went into the design of books, magazines, and objects we see in everyday life and mentioned that there is a lack of this creative design in web work. Jen then went into layouts and how the way we layout websites over the years has changed and that it is about to change even more with CSS Grid Layout. Grid will allow flexibility with design (moreso than flexbox) that can take us back to the creative designs we have seen in old magazines and patterns we see everyday. Grid is on track to come out sometime next year and in my opinion, is a very exciting new adventure since CSS layouts have always been a little fuzzy to me.

Jen also presented a workshop in CSS Grid Layout, which was very helpful in the specifics that we will need to know when Grid officially arrives. A lot of the layouts reminded me of Microsoft WordArt (in a good way), formatting titles in a way that can be positioned vertically and to the left of the rest of the content with no problems. She also went into the history of language and the layouts used to portray these languages.

Rachel Andrew

Rachel went into CSS Grid Layout a bit more in depth, showing more technical aspects of it and taking layouts from everyday items and creating them using Grid in experimental browsers. She also went into ways we can use Grid in a way that has fallbacks that will look solid still when Grid isn’t supported in an older browser. Very insightful as to what to expect when working with Grid in the future.

Brad Frost

The first time seeing my brother speak in person was a good one as expected. After a long day of absorbing information from brilliant minds, he presented in a way that was both educational but funny to keep the audience’s attention. Brad went into the depths of Atomic Design, a process in which smaller components make up larger components that make up even larger components. For the short time I have been in this field, this is the way I learned and have approached many of the projects I have done. This talk solidified the reasoning as to why I have built websites using the principle of Atomic Design.

Jeremy Keith

Jeremy’s talk dove into evaluating technology, going through a history of technology and how the best technology isn’t solely created from nothing. It evolves. Technology is built on prior technology and so on and so forth. That is how technology improves. He showed us how certain technologies can be cool but not necessary and included a picture from the 1990s of a selfie stick with a camera well before the explosion of the smart phone and well before the selfie stick became popular over a decade or two later. One of my favorite quotes from his talk was one from Grace Hopper stating, “Humans are allergic to change.” I feel like it not only represents how humans struggle with change in technology, but with life as well. Jeremy went into detail about service workers and web components and how these are great tools. He also discussed the importance of “how well do tools fail,” since this is important in web development when browsers don’t support certain tools. All in all, I learned a lot both in web development and life from this talk.

Val Head

I have listened to Val talk about animation before at a local meetup since she is based here in Pittsburgh and she definitely knows her animation. Val went into the proper way to use animation in web design and development and how to persuade your company to use animation. She also discussed the tools she uses to design animation as well as the pros and cons of these tools. Val also emphasized the importance of storyboards and sketches and how these can be portrayed to the company rather than just describing the animation and having an opinion on it. She made me realize that showing something to a client speaks volumes compared to just saying what you want to do.

Jason Grigsby

Jason’s talk was about how responsive web design has helped to change the way we interact with content. The content changes in response to the viewport size, but when it comes to a click, tap, swipe, etc., the web has a harder time differentiating these. Jason went into the future of the web and how we may adapt to these different input changes in the best way possible. With the addition of virtual reality and other impressive technological advances, the web will have to continue to change and folks will need to get out of their comfort zone to adapt. A very insightful talk that made me think about the future and how things are ever-changing.

Derek Featherstone

Derek discussed the importance of accessibility. He included the audience by having them read a form with only the use of a straw sized hole in their hand. I, personally, find that it is difficult enough dealing with form fields let alone doing it with low vision. This was a perfect example of how to design for folks who are dealing with everyday or temporary handicaps. Derek also described how design can even look better when you have accessibility already in mind. It doesn’t even take a diagnosed handicap to get frustrated with the web as I’m sure we all know. Designing for ease of use for everyone is very important and decreases this frustration. After creating a design system recently with accessibility in mind, this talk definitely was relevant to me and a solid one.

Eric Meyer

I had heard much of Eric’s talk here in Pittsburgh when he came for Web Design Day, but there were some new topics discussed. Eric went into depth about how designers and developers need to stress test ideas and sites. Although we may have a picture of who the user is in our heads, we will likely have some in an audience that don’t fit this persona. Eric gave several personal examples of this and explained how it can deter people from returning to your site or using your application. Empathy is a huge part of web design and development and by thinking about the user we can design and develop our sites and applications better. By speaking the user’s language and catering to their mood, we can create better experiences.

Gerry McGovern

Gerry’s talk was the funniest of the talks as I was almost in tears during it. It was like a stand-up comedy routine, but with very important lessons included as well. Gerry went into detail about how companies’/clients’ hierarchies of tasks are most times different than the users’ hierarchies, and usually the user is who you want to pay attention to. He showed surveys that he helped with where companies had one idea but the users had another. When the company changed its mindset, the user not only had a better experience but the company itself did better. My favorite quote was “if you solve the customer’s problems, they’ll solve your problems.” After all, it is the customer who uses what you create and if they’re frustrated or delighted, that’ll reflect on the company. A brilliant talk and a great way to end the main part of the conference.

Thank you to all the speakers for all of your hard work and sharing it with us!