1.P: Frontend App
Introduction
Build an Application that solves a problem you have using React, HTML and CSS. We will not be able to persist data in database until Module 2, but there are still many useful apps we can build. If you want to try to create an Application with a rudimentary database please look at HTML's localStorage where we can manage JSON within our React Application.
Requirements
App Stack
This project must be a Frontend React Application that utilises React, HTML and CSS.
User Interface
Functionality
Complexity:
Application has at least 2 levels of components eg: App component and 1 or more child components
Application demonstrates the capability to lift up state
Code Quality
Application is organised as well as structured, it follows practices of component separation and has a good folder structure
The code is easy to comprehend and read
The Application contains meaningful variable and function names
Application contains components that can be reused
The Application preforms well without unwarranted rendering
The Application's code follows consistent coding conventions, regarding indentations and formatting
The Application follows the correct naming, casing and commenting best practices
Project Management
Application has been deployed with GitHub Pages
Git repository contains commits for each feature with descriptive commit messages
Application contains a README with the applications description, user stories and low-fidelity wireframes
The README contains instructions on how to run the Application
Ideas
The best ideas are ones that solve our own problems. Since we cannot persist data until Module 2, consider apps that do not require us to store data beyond the current session. For example: games, calculators, guitar tuners, colour matchers, visualisers. Games may be the most engaging to implement because they typically require more logic. Consult your section leader if you are struggling to decide on an idea.
Timeline
You will have roughly 4 course days to implement and complete this project. We will observe the following timeline to keep us on track.
Project Day | Checkpoint | Feedback |
---|---|---|
1 | Ideation phase 1 Post project ideas in Slack for feedback | SL to review ideas and share feedback |
2 | Ideation phase 2 Create planning docs: user stories, wireframes, kanban board | SL to review planning docs and share feedback |
3 | Start implementation | - |
4 | - | - |
5 | MVP deadline Users can complete the primary user story | SL to review code in GitHub, share feedback |
6 | Feature freeze No new features, focus on polishing existing features and code to be presentable | SL to review progress and share post-feature-freeze suggestions |
7 | Project presentations Practise explaining your work to others. Other batches will join and we will celebrate each others' hard work. | SL to review code in GitHub, share feedback in 30-minute post-mortem meeting |
8 | Demo video Record a demo video for employers and the public, embed in README | - |
Project Management Suggestions
Rocket recommends the following project management strategies and tools for all projects.
User Stories
Start with user stories. Who is our user and what is their job to be done? Be as specific as possible. After we articulate user stories we can proceed to design our app.
Example user stories for Project 1:
An interior designer wants to determine whether 2 or more colours match and what an optimal colour palette might be for given a base colour
A daily commuter wishes to play Flappy Bird during his 30-minute commute
A couple wishes to play a game of checkers against each other on their shared computer
Above user stories may not require persisting user data beyond the current session. From Project 2 onward we will learn how to persist user data for multiple users accessing our apps at multiple times on different devices.
Wireframes
After user stories, create simple wireframes to visually describe how users accomplish user stories with our app. Connect wireframes to form user flows for each user story. Only include what is needed to accomplish user stories, no more and no less. Rocket recommends Figma, a relatively simple and popular design tool.
Here is an introduction to wireframing with Figma. Rocket recommends only low-fidelity wireframes for our projects due to limited time. Below are example wireframes by Figma; we can create user flows by navigating to the Prototype tab in the right sidebar and adding connections between wireframes.
Kanban Board
After user stories and wireframes, Rocket recommends using a kanban board to track implementation progress. A kanban board is a progress-tracking board that contains broadly 3 lists of tasks: To Do, Doing and Done. Rocket recommends Trello for its simplicity, and the Trello Engineering Kanban Template for its relevance to SWE.
Each task on your board should take no more than 1 day to complete. If you think it will take longer than 1 day, break it down into smaller tasks. This will help you stay motivated and track progress more accurately. Move in-progress tasks to the Doing lists and completed tasks to Done.
Setup
Start by forking Rocket's Bootcamp Project 1 repo that contains an empty Vitejs app. This will make it easier for SLs to review your code by allowing us to submit projects via pull requests.
Deployment
If you would like to deploy your app to the internet, follow Vitejs GitHub Pages deployment instructions here this should be familiar as we are already using GitHub for code hosting.
Submission
Submit a pull request to Rocket's Project 1 repo
Add your Project 1 repo link to the Rocket Bootcamp Projects spreadsheet in your batch-specific sheet shared by your SL.
General Tips
Mobile First
Rocket recommends designing and building the mobile version of your project before the desktop version. It will be easier to add features to a UI for the desktop version than to remove features from a UI for the mobile version. Use Chrome DevTools to simulate smaller devices in Chrome.
Polish
Leave sufficient time to polish your app to be presentable. Fewer, more-polished features are generally better than more, less-polished features. Below is a sample checklist to run through.
Are there obvious bugs?
Are variable names concise and precise?
Do we have JSDoc comments above major functions and inline comments above code that could be confusing to others?
Is each function sufficiently small and modular to be easily readable?
Is the visual design clean?
Is the app layout responsive?
Did we update the app favicon and page title?
Did we populate the README?
Last updated