Project Proposals
Please take a moment to rank the proposals.
I have left comments on the proposals about where some of the open questions are. They will hopefully not scare you off from any particular project. There are also some main points that are important for all of them:
- Start by asking a lot of questions about how the site will work, thinking about all of the different people who will visit the site
- Establish the data models early
- Remember that we are shooting for an Iterative/Incremental process. Give yourself room for the iteration and find ways to meet simple goals while leaving the door open for growth.
- Think about scale. Design as if you had hundreds (thousands? millions?) of users. We won’t build the infrastructure to support that, but you want to design as if you were (including adding enough sample data to flesh it out).
Nexus, Circle, Connect, Relate (…not sure) : Your Personal Network Tracking App
Target Audience:
The primary target audience is people who are “networking”/relationship-building; however, this application is for anyone who needs to keep track of relationships in their lives. Students, people in the workforce, those who aren’t good at keeping in touch with people from afar and would like extra reminders to do so, those with poor memory, etc may also benefit from this application.
Main Functionality:
Many people, including myself, use spreadsheets to keep track of conversations they’ve had with people as they aim to build their professional networks. However, spreadsheets are clunky, outdated, and difficult to manipulate. There should be a modern, clean, and simple way to track the people you have met. Users should be able to log the people they meet, when they spoke with them, how they know/met them, what industry they work in, and any notes they had from their conversation so that in the future when they may be looking for a job, or hoping to learn more about a particular industry, they can be reminded of who they already know that may be able to help them. Users should be able to filter their connections by industry. Additionally, users should be able to log when they initialized contact with someone and the app should remind users to follow up after a period of time (set by the user). It can be difficult to track everyone that you reach out to and where those plans stand, so this feature will ensure users don’t forget to follow up or make a plan with someone. The application should also remind users to reach out to each connection every once in a while to maintain those relationships.
This seems well within the scope of a good project. There are opportunities for some interface design and some data modeling, and I think this sounds like a useful tool.
Clean Fridge Club, Save, Waste Not, Pulse, Pantry Pulse (TBD)
Target Audience:
The average American household wastes ~1/3 of the food they purchase/produce, costing them financially and contributing to greenhouse gas emissions. This application is for anyone who stores food, wants to save money, and aims to reduce their carbon footprint.
Main Functionality:
Users should be able to track how much longer they have until their food expires and receive reminders to eat food items that will go bad soon so that they don’t waste their food (and money) and contribute to CO2 emissions. One possible implementation would be for users to photograph/scan their grocery receipts and for the app to generate a virtual fridge containing each item, its quantity, and the date of purchase. The app would have an algorithm for each type of item, display how long each item has until it spoils, and alert users when items were close to their expiration dates. Of course, this implementation has limitations: it would likely work best for produce, but perhaps not as well for items with expiration dates. For example, a user could buy a carton of eggs with three weeks or three days left before the expiration date, and the app wouldn’t know any better by looking at the receipt. It would simply calculate a generic expiration date that wouldn’t be accurate. While these expiration dates are often false/misleading, they would be beneficial for the app to know and to incorporate into its own algorithm. So, users may also need to photograph/scan individual items and their expiration dates. Additional features, if time allows, could include recipe suggestions that utilize soon-to-expire food and offer personalized portions, and grocery list generation to provide users with actionable steps to take after receiving expiration updates.
I salute the goal behind this application (especially after just having to throw out a full package of bacon because my wife bought it, buried it in the fridge and forgot about it). However, as the description hints, there are some challenges to the use of this as a tool. The simplest answer would be to enter in each item and its use by date manually, but no one has time for that. Trying to scan, photograph, will bring in other technological requirements we won’t cover in this class (though some of you may be up to the task). The greater issue is that everything has different rules for shelf life. Meats and produce really do get peaky very quickly while for other things the sell by date is really just a suggestion and has nothing to do with the use by date – especially if sealed. You would also have the challenge of managing the ingest of a lot of images in an efficient manner.
A Mobile Ordering System for Grille and Crossroads
Target Audience:
The primary users of this application are Middlebury College students who purchase drinks and food from campus cafes such as Crossroads Cafe and The Grille.
Main Functionality:
Students frequently experience long lines and wait times during busy hours. This application aims to improve the ordering experience for students while helping café staff manage orders more efficiently.
Main Functionality 1. Browse Menu Users can view a digital menu of drinks and food items available at Crossroads or The Grille. Features include: Categories (drinks, snacks, meals, etc.) 2. Build an Order 3. Select Pickup Time Instead of waiting in line, users choose a pickup time slot. 4. Place Order Users submit the order through the web application. Payment options may include: Pay in person when picking up the order Optional integration with payment platforms such as Venmo Once submitted, the order is stored in a database. 5. Order Status Tracking 6. Staff Dashboard Café staff can view and manage incoming orders through an admin interface.
This has come up a couple of times. It isn’t a bad idea and I appreciate that it needs to support people with different roles. Integration with a payment system and having up-to-date menus will be a challenge.
MiddRide I : A Ride-Sharing Platform for Middlebury Students
Target Audience:
The primary users of this application are Middlebury College students. Many students do not have access to a car, making it difficult to travel off campus for groceries, skiing, or trips to nearby cities. At the same time, some students on campus do own cars and may be willing to offer rides. Drivers can use the platform to share rides and optionally earn some extra money, while riders gain a convenient and reliable way to travel. The platform also strengthens the campus community by enabling students to help each other with transportation. Other stakeholders include student organizations that organize off-campus trips and students traveling to common destinations such as Burlington or ski resorts.
Main Functionality:
Main Functionality 1. Ride Posting (Driver) Students who have cars can create ride listings. A driver can post: Destination (e.g., Burlington, Burlington Airport, Snowbowl, Bristol, Hannaford) Date and departure time Number of available seats Optional price per rider Contact information (phone or email) The ride will appear in the public ride board where other students can view available rides. 2. Browse and Search Rides (Rider) Students can browse available rides and filter 3. Ride Request Students who need transportation can also create ride requests. A request includes: Desired destination Preferred departure date/time Number of passengers 4. Contact Driver When a rider finds a ride they want to join, they can contact the driver using: Text message (phone number) Email Payment and final coordination can be handled outside the platform (e.g., Venmo or cash), keeping the system simple. 5. Student Authentication To ensure safety and trust within the community, the platform will only be accessible to Middlebury students. Users will need to sign in using their Middlebury email address before posting or viewing rides. 6. Ride Management Drivers will be able to: Edit or delete their ride listings Update the number of available seats Mark rides as full
MiddRide II
Target Audience
primary Users: Middlebury students without cars who need transport to off-campus locations (grocery stores, trailheads, Amtrak).
Stakeholders include student drivers seeking to offset gas costs and earn money, as well as the Student Government Association.
Main functionality:
The “what” is a central hub where students post requested trips. It includes a “Bounty/Credit” system where riders can offer gas money or pay for the lift.
Using React Router 7’s capabilities, the app provides a Driver View that shows a list of pending requests filtered by proximity. Drivers can claim a ride, which triggers a status change for the rider.
To maximize efficiency, multiple riders can join an existing trip request if they are headed the same way, automatically splitting the suggested contributions.
A strict authentication system ensures only users with @middlebury.edu credentials can access the system, creating a closed, high-trust environment compared to public ride-sharing apps.
Request a Ride (MiddRides III)
Target Audience
- For people (residents, students, tourists) in Los Angeles who need convenient, quick, and reliable transportation within the city. 2. The platform will connect riders with a limited set of company-approved drivers, rather than allowing anyone to sign up as a driver. 3. The company because they will be responsible for managing driver accounts, monitoring rides, and resolving customer issues.
Main functionality:
Main functionality: allowing riders to request quick and easy transportation and be matched with a pre-approved company driver. The system would focus on reliable ride scheduling, efficient driver dispatch, and safe payment handling. 1. One of the major epics would be user registration and rider profiles. Riders should be able to create and manage accounts within the application. This would include rider account registration, secure login, profile management (name, contact info), ride history, receipts, and saved pickup locations. This is important because it would allow riders to request rides quickly and track past trips. Ride history and payment records would be stored securely as well. 2. Second epic would be driver account which will be managed by administrators (drivers will not self-register). Under this would include name, vehicle information, driver availability (online/offline), and driver assignment tracking. This matters because it creates more safety and reliability for customers. It ensures that only trained and approved drivers can provide rides, giving the company a lot of control over service quality. 3. Epic three would be the ride requesting and driver dispatch. This includes entering pickup and destination locations, automatic or manual assignment of the nearest available driver, ride confirmation and estimated arrival time, and ride status update. This is important because it connects riders with drivers quickly and ensures they receive a transportation. 4. Epic four: Real-time tracking which has the GPS tracker on multiple drivers, a map displaying the selected driver’s path to the pickup location, route tracking during the trip, and estimated arrival time updates. This is important as it provides transparency, trust, and reliability where the rider can see where the driver is. 5. Epic five would be payment processing which provides the customer with a fare estimate before confirming a ride, a place to pay, and receipts. This is important because some people need to know the price before getting on a ride, some people may want to pay online and keep receipts.
This is a perennial favorite, and the fact that I got three separate proposals for the same basic application is a testimony to this. I debated about grouping the third version up there since it targets LA instead of Middlebury, but decided it is ultimately the same application with the same basic set of problems.
Teams that have tackled this have found it to ba a challenge. There is a lot of application flow to manage to coordinate drivers and a riders. Since this is a small community, you also want to think about some of the implications of that and the potentials for abuse (e.g., stalking exes, etc). Of course version 3 has the opposite problem of trying to design an app for a community that we are not currently in. The third version is also more fleshed out and adds even more complexity to the project.
ResourceRoute: Mutual Aid & Food Security Tracker
Target Audience:
Primary Users: Local residents facing food insecurity and community members looking to donate.
Stakeholders: Mutual aid organizers, food pantry volunteers, and local sustainability groups focused on reducing food waste.
Main Functionality:
The core reason for this app is to solve the “empty shelves” problem. Users can view a real-time status of specific fridges or pantries. Trusted volunteers can use a “Quick-Toggle” interface to update stock levels (Full, Low, Empty) for categories like “Proteins,” “Produce,” or “Dry Goods.”
To prevent “dumping” of unneeded items, this dashboard highlights “Urgent Needs” based on current low-stock data. It directs donors to the specific locations that need their items most.
A robust filtering system allows users to search by specific dietary needs (Halal, Kosher, or Gluten-Free) or pickup windows, ensuring that the most vulnerable populations find exactly what they can eat.
And to maintain data integrity, users can upload “shelfies” (timestamped photos of the fridge) to give others a visual confirmation of the stock before they make the trip.
This reads a little bit like the idea is a little more fleshed out in the contributor’s head than what we actually got. So, there are a lot of details missing here about the actual functionality. I suspect this would make a reasonable project, but there are many details that would have to be addressed to determine what this app actually does.
Real-Time Visual ASL Translator
Target Audience:
Primary Users: Hearing individuals (students, service workers, or travelers) who need to communicate immediate, basic information to a sign language user but do not know ASL.
Stakeholders: The DHH (Deaf and Hard of Hearing) community, ASL students, and organizations seeking to improve immediate accessibility in public spaces.
Main Functionality:
The Live-Text-to-Sign Epic: This is the primary feature. As a user speaks or types into the app, the interface identifies keywords and instantly renders the corresponding ASL sign. Rather than a static video, it uses a React-driven sequence of high-quality GIFs or video clips that flow together to represent the sentence.
The “Common Phrases” Dashboard: A highly interactive library of categorized “Emergency” or “Service” signs (e.g., “Where is the exit?”, “Do you need help?”, “Allergy”) that can be triggered with a single tap.
A “Sign of the Day” feature that uses React Router 7 to serve up mini-lessons, allowing users to build their own vocabulary over time.
Crowdsourced Video Validation: To ensure accuracy, users can verify if a specific video clip clearly represents the sign, creating a community-vetted database of visual communication.
I like this one, but it is possible that the scope isn’t a great match for what you will know. A lot of time will be spent coming up with the animations and the system to “translate” inputs into the appropriate animations. This will be particularly challenging if no one on the group knows any ASL.
Street-Art-Scout: The Global Mural
Target Audience:
Primary Users: Street art enthusiasts, urban explorers, and photographers.
Other Stakeholders: Local artists seeking to document their fleeting work, city historians, and neighborhood tourism boards.
Main Functionality:
Street art is often painted over, weathered, or tagged. Street-Art-Scout is a digital preservation society that turns the city into a living museum.
The “Augmented Timeline” Epic: This is our standout feature. Using React state, users can swipe through the history of a specific GPS coordinate. If three different murals have occupied the same wall over five years, the app allows users to see the “ghosts” of past art, preserving what has been lost to time.
The “Bounty” System: This gamifies the experience. High-profile “Scouts,” or artists, can post “Bounties” for specific locations (e.g., “Is the Banksy on 4th Street still there?”). Users earn “Scout Credits” by physically visiting the location and updating its status (fresh, fading, or defaced).
The Artist Fingerprint Portfolio: Instead of just a list of photos, the app uses a tagging database to group works by the same artist across different cities. This allows fans to follow an artist’s “path” through the world.
Interactive Urban Map: A mobile-first, real-time map that allows users to filter art by style (stencils, wheatpaste, murals) or by “vibe” (political, abstract, floral).
This is another project I like, but it does have two significant issues as a class project. First, it is very much mobile first and that isn’t ideal for us. Building websites that run on mobile devices is reasonable, but this seems like it would want some more access to things like the camera and GPS that would make it more appropriate as a real mobile app. The second issue is that we are in a very rural area that has very limited street art. There is some if one heads to Rutland or Burlington, but projects are easier when they can be done in situ.