First Term Recap

With the first term of our capstone project almost finished, I thought it might be good to go over the basics of what we completed over the past 10 weeks. Our team has been working on re-developing a website for the Soundbendor Lab. While majority of it was creating the two major technical documents needed to begin, we also laid out the bare bones of the site. We did this by starting to work with some of the tools we will be utilizing for the rest of the project.

Current Soundbendor Lab Website

Documents

The first step in the process was creating the requirements document, which is essential for any sort of complex project, like building a website. It’s basically an outline of what you need the end result to be. Requirements documents list out function, form, and feasibility requirements for the project at hand. Requirements can be functional, meaning they outline what the website or product needs to do. For example, a requirement might state that a website needs to have a search function. Form requirements deal with the look and feel of the site or product. Feasibility requirements focus on whether or not the project is actually possible given the resources and time constraints. Requirements documents are important because they help to keep everyone on the same page and ensure that the final product meets everyone’s needs.

The next step was creating the design document. It outlines the overall design of the site, including the layout, content and even things such as the aesthetic design. The technical document also specifies the functionality that will be included on the site. This can include contact forms, searchable databases, or e-commerce functionality. The design document is an important tool for communicating the vision for the project to the development team. In our capstone project, we spent a considerable amount of time developing the design document. We wanted to make sure that our website met all of the requirements of our client while also ensuring that our website was easy to navigate and understand.

Portion of the Table of Contents from Design Document
Portion of System Specifications from Requirements Document

Tools

One of the tools we used in our project was Strapi, an open-source, Node.js-based content management system (CMS). It enables developers to easily build and manage customizable APIs for their web applications. Strapi’s main goal is to make it easy for developers to create and manage APIs while also providing the option to use their own tools and frameworks. Strapi is also available as a headless CMS, which means that it can be used with any front-end technology such as the one we are utilizing, React. In addition, Strapi provides an intuitive admin panel that makes it easy to manage your content.

Strapi CMS Homepage

Another tool we used, which is used by the majority of developers today, was React, a JavaScript library for building user interfaces that was created by Facebook. It is Declarative, which means that it makes code easy to read and understand. React is also Component-Based, which means that it is easy to reuse code. Next.js is a React framework that enables the creation of static and server-side rendering React applications. We chose to use React with Next.js for our capstone project because we wanted to create a frontend that was static. This meant that we could host our application on their local computer, which would greatly reduce the overall cost.

AWS is a cloud computing platform that offers a variety of services, including storage, computing power, and databases. For our capstone project, we used AWS to store our media files in a shared directory on AWS Simple Storage Solution (S3) and to create a simple database instance on AWS Relational Database Server (RDS). AWS RDS is a relational database service that makes it easy to set up, operate, and scale a database in the cloud. Using AWS RDS, we were able to quickly create a database instance and connect to it from our web app. AWS S3 is a simple storage service that offers a secure, scalable way to store and retrieve data. By storing our media files in AWS S3, we were able to provide access to them from anywhere in the world without having to worry about server capacity or bandwidth limits.

Bootstrap is a frontend CSS framework that we used in our capstone project. It provides a responsive design that makes it easy to develop mobile-first projects. Bootstrap includes a number of pre-built components that can be used to create common web elements, such as buttons, progress bars, and form controls. In addition, Bootstrap provides a grid system that can be used to create fluid, responsive layouts. Bootstrap is easy to use and saves time by reducing the need to write custom CSS code.

Bare Bones setup of new website created with React and Bootstrap

I am really happy with the work we have done so far on our capstone project. In terms of the requirements and design documents, I feel as though we have set up a solid roadmap for what the nexts steps in the project are. And, I think using tools like Strapi, React, AWS, and Bootstrap will help us successfully develop the Soundbendor Lab website into something more customized to the client. I am looking forward to continued progress in the next two terms!

Blog Post 2

I am very excited to actually begin the “real” work on the project this week, as technical writing will probably be the death of me. While I understand that these documents are part of the process, honestly, I hate them. This is not a complaint, just a simple fact, and I would like it to be noted. I understand why people get the impression that STEM folks are all boring nerds, technical documents are so dry you will literally be physically and mentally dehydrated after reading one. In my opinion writing them is far worse, like crawling through a desert.

The one exception to my technical writing hatred is making figures. Figures are technically not part of the actual technical writing, but as they are essential to the overall technical document, I believe, technically, they count. They are my oasis in desert, a refreshing break in between the dunes of text. I don’t think anything would make me happier than if the only thing I was responsible for was spending hours on Figma making an aesthetically beautiful and functional mockup of our proposed site design.

Initial Proposed Home Page Mock-Up
Initial Proposed Team Page Wireframe

Also, it’s not just limited to making mock-ups and wireframes. I love a good database schema or ER diagram. I think tangibly organizing my thoughts so I have a better grasp of how the relationships between the entities might work is very satisfying. It also shows me the gaps in my logic or plan that I need to fill in or revise.

Initial Proposed Database Schema for Our “People” Object

Maybe it’s just part of being in STEM, but I believe a lot of my frustration creating these documents comes from the feeling that language alone can be incredibly limiting as far as communicating your ideas. I don’t want to try to explain in complete sentences how things will work because I don’t think I’m particularly good at it, I just want to show you. I could write paragraph after paragraph trying to verbally communicate how I think the home page should look and function, or I could make a mock-up with a couple notes and convey way more information with a much smaller margin for confusion.

One of the members of my team has a few years experience working as a professional software engineer, and they have been an integral part in the ease of this first phase of our project. They very clearly seem to have an image of how all the parts of this website need to come together, and getting to pester them with questions has greatly expanded my understanding of web development. They also mentioned that while these documents are genuinely part of the processes, very rarely are the actual developers the ones writing them. This information brought me much joy.

All in all I am very pleased with how the project is going thus far. There are almost always a few things you can find to to complain about, as with anything in life, but as long as the list of good stuff is longer than the list of bad stuff, I will be happy. If trekking through the technical writing desert is the most difficult part of the project, I’d say I’ve got it pretty good.