Project Overview

I (Will) met CAVE founder, Maurlfox, through the Healthy Gamer Discord server, specifically the Neurospicy Job Club that she hosts weekly. I was a full-stack web developer working for an IT consulting company and I was unhappy with my job. In the long term, I wanted to transition into freelance website development for small businesses, so when I found out about CAVE and their need for an official website, I jumped at the opportunity to help out.

The project had been attempted before, but it had petered out when a previous CAVE member got a full time job in web application development and no longer had free time to contribute. I read back through chat messages to analyze the existing site plan:

• Home Page with sections detailing how to join the Discord and participate in projects
• Collaborators Page where CAVE affiliated members can promote themselves
• Projects Page with blog posts detailing past or ongoing CAVE projects
• About Page with additional details about the organization and its operations
• Contact Page with details on how to reach out to the organization
• Events Page synced with the Discord server’s events

Project Planning

I compared those requirements to the messages about the pre-existing development plan to address them, and decided that things could be streamlined. Instead of using React for frontend code and a Node.js server for managing backend data and users, I made the decision to drastically simplify the infrastructure to just an Astro project and start from scratch. Aside from allowing me to work faster from a fresh start, this was beneficial for a two reasons.

First, while React is a great library for web applications it’s overkill to work with for a content driven website. It also makes SEO (Search Engine Optimization) complicated because it relies on filling the web page with content on the fly, which can often appear to Google as an empty page for search indexing purposes. Astro on the other hand builds the content on the server so Google always knows exactly what is on the page, which is a big SEO improvement.

Second, a backend API was simply not needed. Backend APIs that require databases and user management are good for large apps like Facebook or your banking website, but this site was going to serve largely as a landing page for the organization as well as a way to feature projects and community members. Put simply, it doesn’t need to be that involved. Because of that reason, we can largely just manage content either as developers updating the files or administrators using a content management system that I’ll talk about later. Cutting out the backend server allows us to also cut out the technical complexity of frontend to backend API communication and database management so that we can finish the project more quickly, and maintain it more easily.

Additionally, I decided to cut out the Events Page for the purposes of the MVP (Minimum Viable Product). This page would require integration with Discord’s API, reintroduction of our own backend API to control that connection safely, and development of custom frontend components to display the event data on a calendar. I’ve had to make calendar components before for full-scale web applications, and they get complicated. All of this is perfectly possible, but the work required would be equal to if not greater than the rest of the site combined, so with the goal of delivering a project quickly I made the call to cut that from the MVP and revisit it later down the line if necessary.

Project Execution

We ended up developing the project in multiples stages.

1. A wireframe design to confirm content and think about general layout
2. Design moodboard to plan the site’s visual design direction
3. The full design in Figma, excluding mobile versions and hover-based interactions
4. The completed website developed in Astro with mobile responsiveness and interactions
5. The content management system for non-technical administrators

Wireframe Design

This stage allowed us to reconfirm that our interpretation of Maurlfox’s description was accurate to how she wanted the site to function. This step can be integral to ensuring everyone stays happy and expectations are met. The wireframe looks like a website skeleton, using only gray colors, placeholders for images, and one font-face such that we can remove opinions on design direction from this stage of the project entirely.

The CAVE wireframe in Figma

Design Moodboard

At this stage, we searched Pinterest for design ideas around the aesthetic direction of the website. This helps make sure everyone is on the same page when it comes to how we envision the final site looking. We included images focusing mainly on colors, fonts, and other design elements that could make the site interesting. Once we had approval there, we could move onto actually designing the website’s appearance.

The Moodboard for the CAVE website design

The Full Design

We copied over each wireframe page into a new section, and began designing how the website would actually look, including font-faces, color palettes, images, shadows, and more. We built this out fully, taking care to be as exact as possible with pixel measurements to ensure quick translation between the Figma design and the website code. With approval on this stage as well, we moved on to development.

The final Figma file for the CAVE design

The Completed Website

This stage involved translating our Figma design into HTML and CSS, leveraging the additional benefits provided by Astro for components, markdown-based blogs (like this one), and image optimization. We built out each page individually, ensuring they remained responsive on different device sizes. We also added functionality for hover effects and certain interactive components, like the project carousel on the main page. I often find myself making tweaks to the design at this stage because I have to stare at it for hours, so its not uncommon to adjust spacing, font-sizes, or colors (all of which and more occurred).

Content Management System

Not everyone is a programmer, so it’s helpful to have a content management system that lets non-technical administrators make updates to some parts of the website content. For us, those parts were the Collaborator Profiles, and the CAVE Project Posts. Astro already gives us a way to store that content as markdown collections, so all we needed was a flexible interface for non-technical users to login with and update these items as they would a social media post.

Traditionally, content management systems (CMS) are relatively involved and often cost money, but recently a new type of CMS called a git-based CMS has gained popularity by addressing these issues. This works by integrating with the code’s existing git repository (the version-control system for the codebase). This way, we can manage the content for the website using an existing and free system instead of running something separate. I chose an open source option called Decap CMS which mainly handles creating an interface and providing tools to integrate it with content. I also wound up coding a very simple backend API to handle administrator logins. This allows us to avoid handling the authentication ourselves, instead we have administrators make accounts with GitHub and login to our site using their O-Auth provider, similar to logging into a webpage with your Google account. The backend API server I made simply sends requests to GitHub, asking them to authenticate the administrators for us. If successful, they are redirected from GitHub back to our DecapCMS admin page, and they can now edit content.

Conclusion

We’re very proud of the website that we built for CAVE, and we all love to see the collaborator profiles and project posts grow in number. Anyone listed on this project as a contributor would be happy to answer questions related to the creation of the website or websites in general, so feel free to reach out!