Project Context
French cultural heritage is full of often-overlooked historical treasures. Despite their richness, these sites sometimes struggle to capture public attention. Our team of six students was tasked with creating a web application using open data to promote French heritage. This is why our project, ChateauTresor, was launched to fulfill this mission.
Our application allows users to create and participate in treasure hunts within the estates of our partner castles. It targets three types of users: participants, organizing teams (which can be companies or individuals), and castle owners who rent their castles to organizing teams.
Project Objectives
The main goal of ChateauTresor is to promote the castles of the Loire Valley by boosting tourism and preserving this historical heritage. The application addresses the specific needs of three types of users:
-
For treasure hunt participants, we offer a fun and immersive experience by turning them into detectives. By solving puzzles and searching for hidden QR codes, they discover anecdotes and historical secrets, making their visit enriching and memorable.
-
For organizers, whether companies or associations, we provide a tool to create and manage treasure hunts. This allows them to diversify their activities, generate revenue, and offer captivating experiences to participants.
-
For castle owners, we offer a solution to enhance their estates by hosting treasure hunts. This enables them to generate income for the maintenance and preservation of their heritage while giving them full control over their schedules and organized events.
Organizational Measures
Time Management
We adopted a simple yet effective approach to manage our time. Instead of creating a complex schedule, we set specific dates for each project milestone. Each week, we divided tasks based on individual preferences and skills. For example, someone more comfortable with front-end development handled user interfaces, while another focused on back-end development or data management. This method kept us motivated and allowed us to work on topics that interested us.
As the project manager, I designed a Gantt chart to visualize project progress and tasks to be completed.
Deliverable Tracking
For deliverable tracking, we adopted an approach inspired by agile methods. The project was divided into small steps, each with clear objectives. For example, one week could be dedicated to creating the API and model, another to designing user interfaces. This method allowed us to deliver functional versions regularly and quickly validate features. We used GitLab for version control.
Technical Overview
Modeling
The initial modeling of the application relied on several tools and diagrams to organize data and processes.
A use case diagram was created to illustrate the different possible interactions with the system based on user roles.
The system is based on a hierarchy of roles derived from a generic role, User, centralizing common functionalities while defining specific rights for each role:
- User: Account creation, login, personal information updates, treasure hunt data consultation.
- Organizer: Full management of treasure hunts (creation, modification, deletion), access to statistics, management of participants, teams, and clues.
- Participant: Registration for treasure hunts, clue consultation, registration status tracking, without modification rights.
- Guest: Basic information consultation, without active interaction.
This modular structure facilitates the addition of new roles and ensures clear management of rights and responsibilities.
The Entity-Relationship Diagram (ERD) identified the main entities (User, Castle, Hunt, Puzzle, etc.) and their relationships.
It was then translated into a Logical-Relational Schema (LRS), guiding the technical design of the database.
Technical Choices
The technological choices were motivated by the desire to develop a modern and high-performance application while meeting the project's specific needs. TypeScript was chosen for its static typing, aimed at reducing errors and improving code robustness. This language was paired with React to create dynamic and modular user interfaces. Next.js was preferred for its server-side rendering (SSR) and static generation (SSG) capabilities, optimizing performance and SEO.
For data management, PostgreSQL was chosen for its robustness, while Supabase simplified its integration with its tools. For the interactive map, we used the React Leaflet library, which leverages the OpenStreetMap API. The application is hosted on Vercel, optimized for Next.js, facilitating deployment.
General Assessment
Strengths
The ChateauTresor project was successful in several aspects. First, we almost achieved all our functional objectives within the given timeframe. Although the application is not 100% complete, all the main features have been implemented and are functional. This demonstrates good time management and effective task distribution within the team. Additionally, smooth communication and collaboration among team members greatly contributed to this success. Finally, using tools like Discord for communication and GitLab for code management ensured solid organization throughout the project.
Weaknesses
Despite these successes, we encountered some difficulties, particularly with managing types, classes, and Data Access Objects (DAO). At the beginning of the project, we had doubts about how to transform database data into models, which is what Object Relational Mappings (ORMs) do.
We developed the API and transformations manually, which cost us a lot of time, in addition to being a source of errors and security vulnerabilities.
Moreover, we had not sufficiently prepared the model during the modeling phase. As a result, during the implementation of features, we often had to modify types and classes, which slowed down our progress.
Possible Improvements
If we were to redo this project, we would make some adjustments to gain efficiency. First, we would not use TypeScript. Although this language offers advantages in terms of strong typing, it frequently caused us to lose time due to its complexity. Instead, we would choose JavaScript, which perfectly meets our needs and would simplify development.
For the modeling phase, we would create a class diagram beforehand to avoid repetitive changes during implementation.
Finally, for the development phase, we would use an existing ORM solution to secure our data and speed up the development process.
Conclusion
The overall feeling about this project is very positive. Despite technical challenges and necessary adjustments, we are proud of the result. The application meets our initial objectives, and we all enjoyed working on this project. Collaboration within the team was excellent, and everyone contributed according to their skills and interests. This project allowed us to learn a lot, both technically and organizationally, and we gained a very enriching experience from it.