Hi there. I’m a front end designer & developer based in Chicago, IL. I love designing beautiful and functional user interfaces, building them from the ground up, knitting, playing video games, and playing with my cat. Scroll down for info about my work.
ideate
Let's explore. I research and discover anything and everything I can relating to a project - this is where the brainstorming comes in.
design
I use the latest technologies to design a product that is not only beautiful, but has the user in mind every step of the way.
develop
The project then is built with HTML, comes to life with some CSS, and becomes interactive with JavaScript.
Everywhere I’ve looked, many have been saying the same thing: “BUILD A BLOG. Document your process. Write things down. You’ll learn from it.” I’m not the best writer, but hey. Alright. I’ll give it a shot.
I asked myself the question we all dread - so what tech am I going to use?
Buzzwords like Jekyll, Gatsby, and Hugo were all over /r/webdev. I had no idea what a static site generator was, much less which one was best to use. I poked around a bit, and determined that Jekyll was probably the best way to go for me - the documentation was clear and detailed, and the learning curve of React/Gatsby didn’t sound appealing in my rush to get started. Jekyll uses a templating language called Liquid, and accompanied with Markdown, makes for a pretty powerful CMS.
From here on, I will discuss Jekyll as it pertains to my personal site. The Jekyll Docs have a great step-by-step setup tutorial you can view if you want to know more about how it works, and what other features are available.
Right out of the box, Jekyll has some powerful tools available at our disposal. I didn’t have to fiddle with Gulp or any other task runners, because Jekyll already auto-compiles Sass and spins up a local development server using the CLI command $ jekyll serve. I’m such a fan of how easy it is to get up and going with this CMS.
The includes & layout features encouraged me to keep my code as modular as possible. I used 3 includes throughout my site: head.html, nav.html, and footer.html. The first file held the basic HTML heading - the doctype, the <head>, the various meta tags, and the opening body tag. This saved me a lot of code repetition. The second held my navigation bar, and the ul including all of my nav items. Finally, footer.html was… the footer. I also included the closing </body> tag; I wanted my footer on every page anyway, so I didn’t have to remember to close every body tag in the individual layout files.
So with the main HTML skeleton taken care of, I was able to focus entirely on main content. Now I’ll share some fun stuff Jekyll has to offer that helped me build my blog.
My main goals for this site were documenting my learning process and branding myself into the dev world. So, keeping it simple would be my best bet, for the time being. I only had 2 pages (besides the home page) in mind. I should probably write a bit about who I actually am, and include a page on how to contact me in case any of my fans wanted to chitchat.
However, who knows if I wanted to expand on my site in the future. Maybe I would want to add a portfolio page sometime, with some projects. Maybe a gallery page for my film photography. Maybe a page just for my cat. Alas, I’m lazy. Every time I add a new page, I don’t want to add in a new <li> and edit my navigation file every time I expand. I want to focus on content. So, I discovered the power of conditionals and the front matter!
I headed on over to the Liquid Control Flow docs page and checked out what I had at my disposal. Yay! For loops! No problem. I’ll generate some <li>s by looping through every page.
{% for page in site.pages %}
<li>
<a href="{{ page.url | prepend: site.baseurl }}">{{ page.title }}</a>
</li>
{% endfor %}The above code basically says: for every single HTML page in my Jekyll site, make a list item with the linked title of the page, and display it in the navigation bar.
…but, it didn’t work. Not like I wanted it to. It literally put every page in the main navigation - including the archive pages for each of my tags. It looked something like this:
HOME ABOUT CONTACT HTML CSS JAVASCRIPT CONTENT-STRATEGY DESIGNSo on, and so forth. Definitely NOT what I wanted. I read a little more, and found a neat work around.
{% for page in site.pages %}
{% if page.navi %}
<li>
<a href="{{ page.url | prepend: site.baseurl }}">{{ page.title }}</a>
</li>
{% endif %}
{% endfor %}The key is this conditional if page.navi. Jekyll allows for custom variables in front matter - anything you want. navi is one of those custom variables. In the front matter of each page I wanted in the navigation, I set a custom variable navi: true. The code now will only make a <li> if the variable is present in the front matter.
Now, any time I create a new page, I can just put in that variable and I’m good to go!
My first impressions of Jekyll was pretty positive, however, there are a few things missing. One is a decent archiving & tagging system.
I could define a tag variable in front matter, no problem. However, I wanted the tags to be clickable, and when clicked take you to a page that listed all the posts with that respective tag. So, I found a neat plugin called jekyll-archives to do just that.
All I had to do was include the following in my config.yml file:
jekyll-archives:
enabled: all
layout: archives1
permalinks:
year: '/:year/'
month: '/:year/:month/'
day: '/:year/:month/:day/'
tag: '/tags/:name/'
category: '/category/:name/'
I defined a layout for each archive page, and specified the format and styling for which each post would be displayed. After a quick for loop, the plugin did the rest.
Even though ways to search by year, month, day, category, etc exists I’m pretty content with pages just for individual tags. As I write more posts, my plans are to add pagination, additional archive options, and a search feature. Until then, I’ll keep writing!
It’s true that Jekyll and Github Pages are quite a match. However, I chose to deploy my site with Netlify for a couple of reasons. One is that Github Pages does not support (most) Jekyll plugins - so I couldn’t get the archive feature I wanted. I felt that it limited me in a lot of ways.
Netlify also supports continuous deployment which allowed it to integrate into my Git workflow seamlessly. I didn’t have to sacrifice that GitHub benefit. Every time I use git push, Netlify automatically builds a new version of my site. Second, Netlify has an awesome form submission feature. All I have to do is add a netlify attribute to my form HTML, and I can receive submissions, no back end or API required! So, that’s dang cool.
Jekyll is a great and powerful tool that I’m happy I explored. I know I have only just barely scratched the surface; I’ve probably also used some things a bit wrong. I’m just excited to see what else it can do, and learn as much as I can. I wouldn’t personally use it for a freelance client’s website, as it’s a bit more developer oriented. However I can see it being great for micro sites, quick static mockups, and a variety of other possibilities.
It’s always nice to go back in time and look back at your past work, when you were just starting out. By nice, I mean extremely cringe-worthy. I know there are so many things I can improve on, and if I did it again, I would do it right.
In 2015, I offered to build a site for a local restaurant for some much needed practice. That restaurant is Skippy’s Gyros, and they describe themselves as “food for suburban hunger”. My goal was to build a site that made it quick and easy to find essential information about the business, showcase the menu, and represent their philosophy while being aesthetically pleasing.
I no longer have access to this code. It was before I knew of the wonders of Git, or cloud storage apparently. However, I will walk you through the top mistakes and issues I had while building this project, and explain what I would do now as to best optimize this design and site architecture.
Before I get into this, I will say that Bootstrap has its uses. However, the way I was using it in this project was not one of them. Bootstrap can be great for rapid prototyping and convenient for when deadlines are near. I pretty much only utilized the responsive grid capabilites and the responsive hamburger menu navigation. There are several problems with this.
One, is that it bloated the site. I loaded the full collection of bootstrap stylesheets and javascript files. Although they were minified, it still was completely unnecessary and took up bandwidth.
Flexbox would have been the best tool for the layout. All of the pages were simple section rows all of the way down, and did not require any sort of specific collapsing order. I could have aligned things with a simple property rather than playing with the different Bootstrap classes.
The navbar could have been made using simple JavaScript and CSS, instead of loading in a bunch of scripts that I’d never use. A resource I came across and loved very much was Tania Rascia’s Respoinsive Dropdown Navigation Tutorial.
When you do not have enough content to keep your footer at the bottom of the page, some misalignment can occur. On desktop, it aligns fine. However, below you can see the screenshot of what the footer looks like on mobile.
I’m honestly not sure why the footer aligns like this, but my best guess is that it has something to do with the Bootstrap column styles interfering with some bunk mobile styles and specificity issues I implemented. Looking back, I definitely did not understand CSS as much as I thought I did. Specifically, I barely understood Bootstrap.
The way I handle this now is actually extremely simple. It all basically boils down to the code below:
.content-container {
min-height: calc(100vh - 20vh);
}
.footer {
height: 20vh;
}In the min-height property, the 20vh represents the height of the footer. The height of the container before it is calculated by subtracting 20vh from the total height of the viewport. This assures that the footer will be at the bottom of the page, no matter the size of the content in the previous container.
The jumbotron image is HUGE. Extremely huge. 2.7 MB huge. I didn’t know how to properly serve a responsive background image, much less how to optimize images for production. It’s 2015! Internet is fast! Everyone has a great connection! Why would I have to worry about something like the main attention-grabbing image loading, when there could be something as small (sarcasm) as a 1% bounce rate increase for every 100ms delay in page load time?
Not to mention, the jumobtron image looks like a vague brown rectangle on mobile. I didn’t set the image to change between breakpoints - big mistake. You can’t tell what it is on some devices, and that’s a problem when you’re trying to convey a business and their atmosphere.
Since then, I have learned how to optimize images before uploading them and use media queries to serve the most appropriate version of the image depending on the device.
Overall, I like the design of this site. The color story and typography conveyed the suburban comfort vibe, while keeping it timeless and not overdone. However, I definitely think the content design limits the user experience.
From my own perspective, the main reason I would go to a restaurant’s website is to find the most vital information: where it is, the hours, the phone number, and the menu. This information should have been featured better on the home page of the website. Although the hours and specials have their own section, it is placed below the fold. The address is only placed in the footer of the website. Yes, there is a “location” page, but it is just a Google Map and still requires the user to go clicking around the nav to find it.
Perhaps the most heinous offense is that there is no call to action. What should the user do when they get to the site? Where should they go next? Skippys’ main goal was to increase business and encourage orders, so their should have been a button in the navbar or jumbotron to make it easier for the user to contact the restaurant to place an order.
I made a lot of mistakes with this one. I’ve made a lot of mistakes after this one. But it is really something to see just how far I’ve come. I went from someone who just wanted to make a website that looks super cool and shows off how pretty I can make things, to someone who wants to create a product that can get the user to their goal as quick and painless as possible, and make it look good doing it. My mistakes were invaluable, because I was able to directly see how my decisions affected a customer base.
Although I am overall pleased with the site’s design, the knowledge I have learned since then helps me provide a better user experience in my work. I’m excited for my more user-centered and optimized future, and all the mistakes that will come with it.
I began coding when I was 10 years old. It was 2004; the internet was stumbling out of it’s clumsy infant years, and so was I. Like many other women who code, my humble beginnings began on Neopets.com. I was given control over my pet’s “pet page”, and I was able to put whatever I wanted up with some HTML. I could even make the background as bright hot pink as I wanted with CSS. Immediately, I began reading up on anything I could about basic web coding (Thanks Lissa!) and started making graphics for myself and other Neopets users using MS Paint. When a family friend gave me a copy of Photoshop 5, my pet bios and user profile pages were plastered in gradients, flower pictures, and intense drop shadows.
There, I learned the basics of iterating through design decisions. I’d make multiple versions of things, coding them up, and seeing which designs “felt” better and easier to use. I developed an eye for composition, spacing, and even basic color theory based on trial and error. My work was not only praised, but genuinely appreciated by other young girls who didn’t know much about computers but still wanted to express themselves. Coding and graphic design gave me control over something: a means to create something that mattered. Back then, I didn’t have any control over a difficult home life. This meant everything to me, and was quickly rooted in my identity. I don’t know where I would be without the ~8 years I spent on that website.
I continued with design throughout high school, creating basic posters for my friends’ bands and a t-shirt design or two for various school clubs. It was around my junior year of high school when I realized: hey, I could probably make this my life’s work and feel pretty happy about it. When I graduated, I began to browse Craigslist, and got my first job at a local business as a Digital Marketing Consultant at 17.
Throughout my life’s ups and downs and even its sideways, my passion for this ever changing field only grew. I love learning, and even though it’s difficult to keep up when the frameworks/languages/libraries/buzzwords, I enjoy every second. Even when I’m screaming internally looking for that missing semi-colon. The goal is set: I will be a Front End Developer & Designer!
Over the past few years, at the opportunity of the wonderful open source community, I read books, ran through tutorials, watched videos, and hardly ever followed up with the knowledge I learned. Within the past 6 months or so, I started taking my goals and learning seriously. Giving back to the community while simultaneously applying my new knowledge is paramount to my growth as a developer. Thus, the blog is born.
I plan to document my learning process here. I want to make any charts, notes, and study tools to be published here for myself and others. I will review various learning resources, and post about projects I’m working on and why I do the things I do. I can’t wait. Thank you for taking this journey with me.