Skip to Main Content
Jessica G. Abejar

Unplugged Retreat

Developed a website for the Unplugged Retreat based on a Photoshop design comp (a Skillcrush project).

  • Main Skills & Tools: Adobe Photoshop, HTML5, CSS3 (Responsive Web Design, Media Queries, Flexbox)
  • Other Skills & Tools: Visual Studio Code, HTML5 Boilerplate, Google Fonts, Font Awesome, Chrome DevTools, Git, GitHub, GitHub Pages,, W3C HTML & CSS Validation, ChromeVox, VoiceOver, WAVE Accessibility Checker, AChecker, Lighthouse
Screenshot of Unplugged Retreat Project

Creating a Better Web Development Process

As the final project for Skillcrush's "Coding Responsive Websites" course, the task was to develop a responsive website based on the designs provided by a group of Photoshop files, which included images, fonts, colors, icons, and text content. The site is a three-page business site that includes features such as a navigation menu, footer with contact info and links to social media accounts, an FAQ section, and an embedded map.

While this was an opportunity to practice my development skills in responsive design, especially with Flexbox, I wanted to take this opportunity to rethink my own web development process. I wanted a much more systematic process of developing websites. I wanted an organized way of writing code initially so that few revisions are made during the process; however, if changes were necessary then I wanted to ensure that there was a quicker and smoother process for implementing them. I knew I also wanted to include web accessibility, and so determined that functionality should be separate from styling.

unplugged 001
Image: The printed design comps of the same webpage across different-sized browsers. Designs were created for three pages on three devices each.

I found it necessary to prepare and examine the design files thoroughly, identifying key patterns in how content was presented, laid out, and styled. This also helped determine the role of each element and identify any landmarks. This would be particularly useful in coding the site in HTML only, a format that could easily assess if the website met basic web accessibility standards (I aimed for at least WCAG 2.0 Level A compliance).

Styling was also done systematically. Previously I had styled elements individually, finding only patterns in recurring elements like text headings. However, since my aim was to create a smoother development process, I decided to put the majority of my work in first identifying patterns. I sought out finding reusable UI patterns in layout, text, and styling. Finding patterns in layout meant creating less <div> elements and targeting similar elements using a class name. Understanding text patterns meant creating a new system for styling heading text that never compromised accessibility. Lastly, remaining styles were applied to individual elements; by that time, most styles had already been applied, leaving only unique properties of each element to be added.

This entire process helped not only in writing and styling content but also in troubleshooting. The process anticipated possible challenges before any code was written, and whenever a change needed to be made mid-process, the elements or actual code affected were only a few. It was a rather painless process to debug any issues. Using both Git and GitHub assisted with addressing issues and tracking progress and provided an outlet to explain why certain decisions were made, which unexpectedly helped me to understand my own coding patterns and development choices. A final QA check included validating code; checking for any other accessibility issues; testing across browsers, device sizes, and assistive devices; and auditing performance.

In the end, not only was I proud of the final product but I was extremely proud of the process that I had developed. I hope to use the process of building this project as the framework for how I complete all my processes in the future.

Pre-Planning: HTML

After printing out the design comps, I identified the different parts of each page, dividing the website into components based on the content. I divided each page into a header, a main section, and a footer, with each of these sections broken down further into sub-sections. Each sub-section component was then broken down further into elements. I also took this opportunity to assign most of the components and elements a class or ID, to be used for CSS.

unplugged 002
Image: The printed design comps with accompanying sticky notes identifying the different components, elements, and the HTML tags to be used across the three pages of the site.

After identifying each element, I started comparing the layouts of each page across the different device sizes, in this case - mobile, tablet, and desktop layouts. This would later help in determining how to write media queries for each element, and because of that, it confirmed which elements should be grouped together.

unplugged 004
Image: The printed design comps of the same webpage across different-sized browsers. The green sticky notes on the left of the design identify content and HTML. The pink sticky notes on the right of the design determine layout and subsequent changes in layout across different-sized browsers.

Coding the HTML

After planning each page’s content and layout by pen and paper, the pages were then coded. The HTML5 Boilerplate was used to provide a framework for the website files. HTML was implemented first, using semantic HTML to ensure readability and accessibility. Comments were also included to separate and easily identify elements and components.

unplugged 006
Image: Text editor with early-implemented HTML code that includes comments identifying each section of the page as well as comments for future sections, elements, or content to be added.

HTML was tested for errors using the Nu Html Checker. The site was also tested for accessibility using the ChromeVox and VoiceOver screenreaders as well as tested for keyboard accessibility manually. The website was viewed with HTML only to ensure that the content was still presented logically even without styling, allowing for users with limited or slow Internet to be able to access, navigate, and understand the content of the site.

unplugged 007
Image: Each page of the Unplugged Retreat website in the browser, HTML only without CSS styling.

GitHub Flow

The GitHub Flow is a process I use even as a single developer. A master branch is created at the lowest level (boilerplate with pages). Development takes place in a separate branch that is tracked on GitHub (one branch for HTML, a new one for CSS, plus a few other branches including clean-up and one for final features). The branch is then merged using a pull request, allowing me to easily compare changes and write comments and notes to myself to check for better solutions, to clean up blocks of code, to remind myself to test for accessibility, etc. Once approved, the branch is pulled into the remote master branch. The remote master is then fetched and merged into the local master branch. A pull request is usually made at each major feature, in this instance, one after all the HTML is written, one after all the CSS.

Pre-Planning: CSS

The CSS is then planned out, mobile-first. The major part of determining how to style each component and element consists of identifying patterns. While I also identify each element’s individual style including flexible layout, font, color, and other features, I also compare the elements' stylings and identify patterns before code is written. Repeating patterns are given a class name for higher CSS specificity and to not affect semantic HTML and content logic. These patterns are then compiled into a library.


The website was designed to have a responsive layout. The first part was determining which section components were flexible, meaning which had children whose width was fluid and whose layout and placement changed at certain breakpoints. The second step was to then determine the behavior of the child elements, for example, going from full-width (arranged in a single column) to half-width (arranged in two columns) or even one-third-width (arranged in three columns). Elements that exhibited similar behavior at certain breakpoints were given the same class name rather than simply assigning these properties and values to the element itself. Their behavior was observed going from mobile stylings first (acting as default styling), onto tablet styling, and finally desktop.

unplugged 008
Image: Post-it notes that identified patterns in layout behavior and breakpoints at which they changed. Elements were grouped by their mobile layout first.

Text Stylings

Determining text stylings was also a tedious process that involved identifying each text element’s styling including font-family, font-size, line-heighting, font-weight, text-decoration, text-transform, and text-align. These properties were also identified across each media query breakpoint.

unplugged 009
Image: Post-its on printed design comps identifying CSS properties for each text element.

Patterns were then identified based on these properties. After grouping the elements and defining a root font-size at each breakpoint, the font-sizes of each group were converted into rem. Then any repeating sizes (based on rem) from one breakpoint to another were determined; this was to ensure that code did not have to repeat if it was not needed, for example if a style remained 1rem from mobile to tablet, then no tablet styles needed to be written.

unplugged 010
Image: Spreadsheets grouping, sorting, and identifying text elements with similar property patterns. Font-family, font-size, line-height, text-transform, and text-align were some of the properties and values determined.

Individual Styles

Individual styles were then determined last, this included properties and values of background images, forms, icons, maps, and definition lists.

Coding the CSS

CSS was coded after each pre-planned section: layout, text styles, then individual styles. This process was chosen rather than coding all the CSS together as it would be easier to maintain, troubleshoot, and track issues if necessary.

Layout was coded first, starting mobile-first and then adding appropriate media queries. The site was quickly viewed using Chrome DevTools to test its behavior across browser sizes and devices.

Text styles were then added, followed by individual stylings. As mentioned earlier, margins and paddings were later added as they were initially left out by mistake.


The last part of the process was to do last minute checks on the website. These are some of the checks that were included (with links to the tools provided):

  • Checking content for grammar and spelling errors (One way to check the content is by turning on a screen reader such as VoiceOver, JAWS, or ChromeVox to read your content)
  • HTML Validation
  • CSS Validation
  • Responsive design across devices : Chrome DevTools & Matt Kersley's Responsive Design Tool
  • Screenreader accessibility : VoiceOver & ChromeVox
  • Keyboard navigation (manually navigating a page with the keyboard only)
  • Accessibility : Wave (live sites only)
  • Accessibility : AChecker (live sites only)
  • Performance, Accessibiity, Best Practices, & SEO Audits: Lighthouse

Some accessibility issues, in particular, were related to design (such as low color contrast with the light green accent and lack of label on the form). Overall, I worked to make sure that the page was accessible, navigable, and easy to understand.

In Summary

A plan to create a more systematic approach to design led to a speedier and efficient process. Design choices drove development, and understanding and identifying those design patterns created a smoother process for implementation and even troubleshooting. The process of breaking down design patterns but also identifying repetitive patterns and how they fit to the whole site helped in creating a page that is close to "pixel perfect." I imagine that my process for developing code from design comps would look similar in the future and that I'll be able to identify issues (such as forgotten margins and padding) earlier in the process.