Achievements

Development of a life trajectories web application

Design of a sociological questionnaire application with custom D3.js data visualization at the Grenoble Computer Science Laboratory.

Internship (university research)Vue.jsJavaScriptD3.jsPostgreSQLRecherche

Visual proof

Screenshots and demos from real projects.

User profile selection

Entry screen allowing the user to choose between interviewer and respondent roles.

Interviewer workspace
Local CAP2vie interface started from the internship repository.

Survey creation

Flow for creating a sociological survey in the CAP2vie application.

Sequential questionnaire

Guided input interface allowing interviewers to collect trajectory data.

Multi-screen connection

Real-time screen synchronization through Socket.io to support interview sessions.

Date conflict handling

Example of resolving temporal inconsistencies during trajectory input.

Presentation

A five-month internship completing an application designer-developer program.
I carried out this project from May to September 2024 as part of my Application Designer-Developer training. This professional title is registered in France's National Directory of Professional Certifications, or RNCP, at level 6, corresponding to bachelor's degree level. The internship had to place me in a situation where I designed a complete application rather than merely executed isolated technical tasks. It was therefore both a professional experience and a practical application of the design, development, and initial delivery preparation skills acquired during the program.
A project hosted at the Grenoble Computer Science Laboratory.
The internship took place at the Grenoble Computer Science Laboratory, generally referred to by its French acronym LIG. It is a computer-science research laboratory affiliated notably with Université Grenoble Alpes, the CNRS, and Grenoble INP. I worked in the IMAG building on the Saint-Martin-d'Hères university campus. IMAG is a location that hosts the LIG and several of its teams; it was not the name of my team. This distinction places the project accurately within a university research environment without assigning it to a structure that I cannot confirm.
Supervision by a professor-researcher working on sociological uses.
I worked under the direction of a professor-researcher involved in designing tools for sociological studies. A professor-researcher divides her activity between university teaching and producing knowledge through research. Her role in the project was to provide the scientific requirement, knowledge of the survey methodology, and a vision of future uses. My role was to turn that idea into a first interactive system that sociology specialists could observe, manipulate, and criticize.
CAP2vie, a name built around a person's “life course.”
The name CAP2vie evokes the course followed by a person's life, in other words the direction taken by their journey over time. The project was not intended to reduce a person to a single data point. It had to represent a story made of events, changes, and relationships between several dimensions of existence. The name therefore summarizes the application's central subject: making a trajectory understandable while preserving its chronological evolution.
The life trajectory as an object of study.
In sociology, a life trajectory can be understood as the history and direction of a person's path observed through several common dimensions. It may include the places where the person lived, schooling and education, professional career, family situation, important people they knew, and geographical movement. Value does not come only from every event considered separately, but from their sequence: when a stage began, how long it lasted, what happened in parallel, and how one transition may have influenced another.
A tool for comparing paths and informing decisions.
The broad scientific objective was to provide professors and sociologist interviewers with more modern tools for collecting and then studying trajectories. By comparing several paths, researchers can look for correspondences—situations or developments shared by several people—and then build hypotheses about the factors accompanying them. As an illustration, a study could observe the transport methods used by students aged 18 to 25 living in Grenoble to reach university, then use these observations to inform mobility policies. This example explains a possible purpose of the method; it is not a result produced by CAP2vie during my internship.
Replacing data collection performed mainly on paper.
Before the application, information was gathered through paper forms. This medium supports an interview, but becomes difficult to maintain when questions evolve and complex to analyze when several trajectories must be compared. Answers have to be reread, transcribed, and restructured before they can feed a visualization or comparison. The project therefore sought to digitize collection during the interview and produce an organized representation progressively, without waiting for a complete manual re-entry after every survey.
Intended use during face-to-face and field interviews.
CAP2vie was designed to support a real meeting between an interviewer and a participant, whether the interview took place in a university environment or directly in the field. The application was not designed as an automated questionnaire completed alone at a distance. It had to support the sociologist's methodology, allowing them to adapt question order or wording and request clarification. The interface therefore needed to remain a tool serving the conversation rather than impose a rigid journey that replaced human interview practice.
Two complementary roles within the same interview.
The interviewer was the sociologist responsible for asking questions according to their methodology and recording relevant information. The participant answered questions about their history. This separation was represented in the application through interfaces suited to both roles. The interviewer needed controls for conducting and structuring data collection, while the participant needed to understand the representation of their path without accessing survey-management functions.
A visualization shared across several screens.
Multi-screen operation allowed participants to watch their trajectory take shape while the sociologist asked questions and entered answers. This simultaneous update turned the chart into a discussion aid: the participant could recognize their history, point out a misunderstanding, or add detail when an event appeared at the wrong point in time. Synchronization therefore had to transmit changes from the interviewer's interface to the viewing screen without requiring both people to handle the same device.
Questions organized around event content and context.
The questionnaire had to collect the elements needed to understand a trajectory: what happened, when, where, how, and why according to the person's account. These questions could concern education, work, family, important relationships, or places of residence. The application had to preserve answers in an exploitable structure while respecting interview logic. It was not meant to present a sociological interpretation as an automatic truth; analysis remained the researchers' responsibility.
Sensitive information requiring anonymization after the interview.
A life trajectory can reveal personal information about family, places visited, relationships, education, or career. The research process therefore required data to be anonymized after the interview so that answers used for analysis did not remain directly associated with the participant's first or last name. Anonymization involves removing or transforming elements that allow direct identification. The prototype did not yet automate this operation within the application: designing an integrated, verifiable mechanism suited to the collected data was one of the subjects left for a later release.
A project started from an idea rather than existing software.
When I arrived, the team had the idea for the tool, but not an application, code repository, or prototype that I could simply extend. I therefore started from scratch. This situation required me to move from a need expressed in research vocabulary to a concrete organization of screens, data, and exchanges between components. The prototype also had to make open questions visible: a first usable interface allowed researchers to clarify requirements that would have been difficult to describe completely before any implementation existed.
A cross-cutting scope spanning visualization, backend, and real-time communication.
The prototype was developed by a team of three interns. My two colleagues primarily handled the form and database, while I developed the backend, D3.js visualization, and Socket.io interconnection. The backend receives requests and applies server logic; D3.js turns answers into an interactive browser representation; Socket.io synchronizes that representation between screens. My scope therefore connected several essential layers without including every part of the prototype's development.
A technical stack selected collectively to build the first prototype.
The development team selected the technologies according to the requirement and its existing knowledge. Nuxt 3 and Vue 3 structured the Web interface; Express.js exposed server functions; Prisma connected the code to PostgreSQL, the relational database system; D3.js supported a custom trajectory visualization; Socket.io transmitted updates between screens in real time. A technical stack is the coherent collection of tools used to run an application. These choices defined the first foundation without claiming to be the only possible architecture for future releases.
A research prototype as the expected outcome.
The result requested after five months was in no way a finished product or a system ready for large-scale deployment. It had to be a functional prototype that the professor-researcher, teachers, and sociologist interviewers could try and present. A prototype is used to verify an idea, observe use, and gather initial feedback before investing in a stabilized release. Internship success therefore depended on the application's ability to materialize the questionnaire, trajectory, and multi-screen interaction clearly enough to inform the next stage of research.

Back to contents

Objectives, context and stakes

Materializing a research method in a prototype.
The broad objective was to turn an idea from sociological research into a first usable application. The goal was not to deliver a final platform, but to verify that an interview, dated answers, and a trajectory representation could be combined in one experience. This prototype had to give teachers and interviewers something concrete enough to evaluate the method, provide feedback, and decide on later development.
Limiting the initial core to two mandatory functions.
Two elements absolutely had to work by the end of the internship: the survey form and life-trajectory display as a chart. The form collected events described by the participant. The chart turned those answers into a chronological representation. If either remained unusable, the concept could not be demonstrated: the questionnaire alone would merely reproduce a standard digital form, while a chart without structured collection could not faithfully represent the interview.
Starting from a questionnaire defined by the researchers.
The prototype used a set of questions provided for the experiment. Sociologists were not yet expected to create, modify, or version their own questionnaires within the application. A dynamic questionnaire would have required an administration interface, management of multiple field types, and rules allowing a form to evolve without making previous answers incompatible. This feature was relevant to a future release, but was not needed to verify the central principle during the five months.
Collecting text, dates, and periods.
Answers included textual descriptions and temporal information. For a job, education, place of residence, or another event, the interviewer notably requested a start and end date. The participant could provide exact dates when known or estimates when precise information was unavailable. This flexibility was essential: a sociological trajectory may cover several decades and cannot demand the same precision as a recent administrative record.
Turning every event into a chronological interval.
Collected dates positioned an event on a timeline. A period is an interval between a beginning and an end; it can, for example, show that a job occurred while a person lived in a particular city. The visual length and position of an event on the chart had to match the period described during the interview. This correspondence between answer and display was the first criterion for trajectory correctness.
Representing dimensions separately and simultaneously.
The visualization had to provide several readings. Dimensions such as education, work, family, relationships, or places of residence could be viewed separately to keep each path readable. They could also be overlaid or brought together in a shared view to observe simultaneous events. This dual reading addressed the sociological need: understand every area of life and then look for temporal relationships between several areas without confusing them.
Preserving narrative fidelity rather than producing only an attractive chart.
A trajectory was considered correct when displayed events matched the periods described by the participant. Success therefore did not depend solely on the visualization's clarity or originality. The chart had to preserve event order, duration, and dimension without suggesting a different chronology. The technical objective remained subordinate to the accuracy of the research aid.
Making the form usable by the interviewer.
Form user experience was part of the success criteria. The interviewer had to follow their methodology, enter information without unnecessarily interrupting the conversation, and retain the context needed to complete an event. User experience, or UX, here means the ease with which a person understands the interface, completes their objective, and corrects an error. A technically functional but slow or confusing form would have disrupted the interview and reduced answer quality.
Making the trajectory understandable to the participant.
The visualization was not intended only for researchers after the interview. Participants also had to recognize their own path and understand how their answers were translated on screen. This readability allowed the chart to serve as a discussion aid and reveal a misplaced event earlier. The prototype was therefore evaluated through two complementary experiences: data entry for the interviewer and reading for the participant.
Adding multi-screen interconnection during the project.
The requirement evolved during the internship. Initial scope focused on the form and visualization, after which researchers asked for the trajectory to be displayed live on a second screen for the participant. I took ownership of designing this extension using Socket.io and real-time event communication. This addition changed the prototype from a single-interface application into a coordinated experience between two users.
Isolating each interview in a communication room.
The participant's screen joined a room associated with the interviewer's screen. In Socket.io, a room is a logical group of connections that allows an event to be sent only to the relevant participants. When an answer changed the trajectory, the server could therefore send the update to the correct viewing screen. This mechanism prepared separation between several interviews, even though complete management of multiple surveys and people was not yet part of the expected prototype.
Not blocking the interviewer if the secondary screen disconnects.
Interconnection had to enhance the interview without becoming a critical dependency for data entry. If the participant's screen lost its connection, the shared visualization could stop updating, but the interviewer still had to ask questions and record answers. This asymmetry was deliberate: data entry was the main journey and the secondary screen a visual aid. Restoring the connection could be handled separately without losing the entire interview flow.
Evaluating the prototype through use rather than production scope.
Success criteria remained focused on the form and visualization quality, with screen interconnection added later. Sociologists had to be able to try these functions, understand the journey, and provide useful feedback. Complete campaign management, questionnaire creation, answer export, and delivery to analysis platforms were not required for this evaluation. The expected outcome was a usable proof of concept, not a solution deployable to every researcher.
Explicitly preparing handover to another developer.
The prototype had to continue evolving after the internship. Handover was therefore part of the objectives from the outset. Alongside the application, we created a documentation website with Docusaurus. Docusaurus is a documentation site generator that organizes written explanations, guides, and technical references in a navigable interface. This documentation had to explain setup, architecture, and important functions so that a future developer would not depend solely on a conversation with the original team.

Back to contents

Risks and mitigation measures

Requirements likely to evolve with the prototype.
The project started from a research idea rather than a fully stabilized specification. Researchers could refine their requirement only after seeing and handling a first release. Adding the second screen illustrates this risk: it was not part of the initial core, then became useful enough to join the prototype. Scope management involved accepting changes that directly strengthened the experiment while postponing questionnaire administration, exports, and external integrations.
An architecture impossible to get entirely right on the first attempt.
Starting from scratch with an exploratory requirement created a risk of choosing a code organization that no longer matched later discoveries. This risk materialized: when a direction proved unsuitable, I had to revise part of the architecture. Software architecture defines how interfaces, logic, data, and exchanges are separated and connected. Corrections were part of prototyping, but consumed time and confirmed the need to keep components as independent as possible.
A visualization matching no standard chart.
The main technical risk was failing to build the representation imagined by the researchers. Ready-made charting libraries generally provide configurable lines, bars, pie charts, or scatterplots, but not the expected combination of temporal trajectories and dimensions. D3.js was chosen because it provides low-level primitives for turning data into visual elements. This freedom made the result possible, but transferred responsibility for calculating positions, scales, shapes, and interactions to me.
A visually plausible but scientifically incorrect chart.
An error could produce a trajectory that appeared coherent while placing an event at the wrong date, in the wrong dimension, or with an inaccurate duration. This risk was harder to detect than an obvious display error because the browser could operate normally. I had to compare the representation with source answers and have sociologists verify the result. Validation therefore covered the meaning of the chart as much as its technical execution.
A representation capable of influencing interpretation.
Event size, color, overlap, or position can give it importance that neither the participant nor the researcher intended. The chart could therefore distort the narrative even when dates were accurate. Iterations with sociologists helped identify these effects and verify that the representation matched the methodological intention. The application had to support analysis, not silently produce its own conclusion.
Disagreements belonging to sociological method.
Researchers broadly agreed on how to represent a trajectory, but could disagree on how certain events should be included in the chart. This kind of debate could not be resolved through a development preference or JavaScript library. My role was to make alternatives understandable and technically feasible, then let specialists decide on the rule suited to their methodology. Coding a disputed interpretation too early would have hardened a scientific decision that remained open.
A form experience capable of disrupting the interview.
A slow, rigid, or difficult-to-correct form could distract the interviewer and break the conversation's rhythm. It could also encourage incomplete entry simply because a field was misunderstood. Demonstrations and iterations with sociologists confronted the interface with their actual questioning practice. Control went beyond checking that a button worked: the tool had to remain compatible with their interview methods.
A multi-screen extension adding a new point of failure.
Live sharing added a network connection and another state to synchronize. An event could be correctly recorded by the interviewer without appearing on the participant's screen, or a screen could join the wrong exchange if association was incorrect. Socket.io rooms limited this risk by logically separating connections. The viewing screen nevertheless had to remain secondary so that loss of synchronization did not prevent the main interview from continuing.
An interruption that could not block data entry.
If the participant's connection was interrupted, that user temporarily lost trajectory updates. The interviewer, however, had to retain the form and continue the interview. This continuity reduced the impact of a connection problem, but the prototype did not yet handle every possible reconnection and resynchronization scenario. A version intended for regular use should notably guarantee that a returning screen retrieves a complete and current state.
Local operation that did not prove Internet robustness.
The prototype was intended for face-to-face interviews and ran in a controlled local environment. It did not have to solve network restrictions, latency, or interruptions associated with remote Internet use. This limit was acceptable for demonstrating the multi-screen experience, but prevented any conclusion that the same architecture would work without adaptation in every field setting. A future deployment should test real networks, connection security, and offline or degraded behavior.
Possible information loss in a prototype.
An interview contains work that is difficult to reproduce: if answers disappear, it may not be possible to ask the participant to repeat their complete account. The prototype had to test entry and visualization, but was not yet a production system offering every backup, recovery, and traceability guarantee. This limitation required use in an experimental setting and, before a final release, an explicit strategy against data loss.
Anonymization not automated within the application.
Trajectory data could be sensitive. The process required anonymization after the interview, notably by separating first and last names from analyzed answers. The prototype did not automatically perform this transformation. It should therefore not be presented as a complete data-protection solution. A later release should define which information to remove or replace, when, with which permissions, and how to check that a combination of events does not make indirect identification too easy.
Access features still limited by scope.
Complete management of multiple surveys, multiple people, and their permissions was considered, but was not the purpose of the prototype. Local operation reduced exposure during demonstrations without replacing a genuine access policy. A deployed release should authenticate users, separate studies, and limit each researcher to authorized data. Postponing these features was acceptable for a proof of concept, but incompatible with large-scale real data collection.
No export or delivery to a specialized platform.
The first release could not export answers or charts and did not transmit data to an analysis tool. Adding export involves more than creating a file: it requires a stable format, preservation of estimated dates, representation of dimensions, and protection against exposing removed identifiers. These questions were left for the project's continuation so that the five months remained focused on validating the form and visualization.
A flexible deadline but an outcome expected within five months.
The university context did not create production pressure comparable with a commercial product. The five-month limit therefore did not threaten an activity or public launch. It was nevertheless the duration of my internship: a prototype had to be presentable before I left. The main risk was not contractual delay, but dispersing time across too many functions and finishing without an object coherent enough to gather feedback.
Future continuation dependent on handover quality.
My departure was known from the beginning. Without documentation, the code could become difficult to continue, especially the D3.js visualization and synchronization between screens. The Docusaurus site reduced this risk by gathering instructions and technical explanations. It was not sufficient by itself: code also had to remain structured, important choices justified, and setup reproducible. The objective was to transfer a working foundation, not merely a demonstration that ran on my computer.

Back to contents

The steps — what I did

Starting by documenting the requirement.
My first action was to record the necessary information before developing. The professor-researcher brought the prototype's three developers together to present the sociological context, interview method, and planned technical needs. This meeting helped us understand that the form and visualization were not independent features: answers had to be structured during entry to feed the trajectories correctly. Documenting this relationship from the outset prevented us from treating the project as a simple form with a chart added at the end.
Turning explanations into working materials.
We produced a specification document, developer-oriented requirements, tickets, and diagrams. The specification described the requirement and scope; detailed requirements clarified expected behavior; tickets divided the work into trackable items. We also reused diagrams created by the researchers to preserve their way of describing trajectories. My work involved connecting these domain representations to the objects the software had to store and display.
Not creating mockups that would not have reduced uncertainty.
We did not create conventional mockups before development. The form relied on familiar interface components, and its main difficulty concerned sequence rather than static appearance. For the visualization, a fixed image would not have supported proper evaluation of temporal scales, overlap, and interactive corrections. We therefore preferred to build an initial working chart quickly. Code served as the visual prototype here and allowed researchers to react to actual behavior.
Organizing the internship into iteration cycles.
The five months were structured around three broad activities: gathering the requirement, selecting the technical foundation, and then developing through iterations. An iteration was a cycle in which we implemented one part, presented it to stakeholders, gathered feedback, and corrected direction before continuing. This organization suited a research project because some expectations became precise only after observing the prototype. It allowed us to move forward without pretending that every decision was final from the first week.
Selecting Nuxt and Vue from the team's skills.
We wanted to use a JavaScript framework for the browser application. The main options considered were Angular, React, and Vue. The team knew the Vue ecosystem best, so we selected Vue 3 with Nuxt 3. A framework provides a shared structure, conventions, and tools for organizing pages and components. Choosing technology that was already familiar reduced learning time and supported collaboration between the three developers during a five-month internship.
Keeping a simple JavaScript backend with Express.
Server requirements remained relatively conventional: receive form data, apply the required logic, and communicate with the database. We selected Express.js, a minimal framework for building routes and APIs with Node.js. An API is the interface through which the frontend asks the server to read or change information. Using JavaScript on both sides limited the number of languages to maintain and made movement between frontend and backend more direct for the team.
Modeling data with PostgreSQL and Prisma.
PostgreSQL was selected as a relational database because the information formed linked entities and the technology was familiar to the team. A relational database organizes data in tables associated through identifiers. Prisma acted as the ORM, or object-relational mapping tool: it allowed us to describe models in code, create the database structure, and manipulate records without writing every SQL query manually. This combination simplified prototype setup and understanding of the model.
Defining the main domain entities.
The model notably distinguished surveys, participants, questions, answers, events, and trajectory dimensions. A survey grouped questionnaire context; an answer preserved information given for a question; an event turned that information into a dated element; a dimension indicated the area of life to which it belonged. This separation prevented all information from being trapped in free text that could not be positioned on the chart.
Building a single form organized with a stepper.
The questionnaire occupied one page, but was divided into successive stages through a stepper. A stepper is a component that guides a user through several sections while indicating progress. Each stage could correspond to a trajectory dimension. This organization avoided displaying every question at once and allowed the interviewer to focus on one area before moving to the next.
Adapting questions to previous answers.
The questionnaire was dynamic. For the professional trajectory, it could ask whether the person had held a job, then display questions about that job and its period only when the answer justified them. At the end of this entry, it asked whether another job should be added and repeated the sequence when necessary. This conditional logic allowed a variable number of events to be collected without imposing irrelevant fields on a person whose path was different.
Associating every answer with a dimension.
Each group of questions belonged to a known dimension, such as education, work, or places of residence. When an answer described an event, the application therefore preserved both its content and the dimension in which it should appear. This association formed the link between the form and chart. It allowed the visualization to separate rows by domain and then bring them together when the user requested an overlaid view.
Building periods from exact or estimated dates.
Start and end dates were the central information sent to the chart. When an exact date was unknown, we applied a rule consistent with the survey method. A missing start date could reuse the end of the previous event in the same dimension; an unknown end date could extend to the beginning of the next event. This estimate produced usable continuity while leaving the interviewer and participant able to correct the boundaries when their conversation provided more precise information.
Turning answers into temporal data for D3.js.
Before rendering, the application converted relevant answers into objects containing at least a start date, an end date, and a dimension. Descriptive content then supplemented the event, but these three pieces of information primarily determined its position. This transformation step isolated business logic from drawing code: D3.js received a consistent format regardless of which form stage produced the answer.
Building the chart with D3.js primitives.
We used SVG elements, axes, and time scales. SVG is a vector graphics format integrated into Web pages whose shapes remain sharp when resized. A time scale converts a date into a horizontal or vertical position within the available space, while an axis provides markers for reading that position. D3.js prevented us from reimplementing these basic calculations while leaving us free to compose a representation unavailable in a ready-made charting library.
Providing multiple dimension reading modes.
The chart settings panel included an option for switching representations. Users could view dimensions separately to follow each domain more clearly or request an overlaid view to observe events occurring during the same periods. Changing mode reused the same data and recalculated its layout; it did not create a separate independent version of the trajectory.
Evolving the chart through three main versions.
The first version separated the different dimensions. The second handled their overlap to bring several domains together on the same temporal reading. The third added answer correction and dynamic rendering updates. This progression allowed us to validate fundamental positioning first, then comparisons, before adding an interaction that changed data already represented.
Allowing correction from the form and chart.
During or at the end of the interview, the interviewer could return to an answer through the form or adjust dates directly from the representation. This feature addressed a real use: when seeing their whole life, a person may remember that an event began earlier, ended later, or ran in parallel with another. The chart therefore could not be a fixed final image, but had to become a second entry point into interview data.
Revising the architecture to make the chart editable.
Adding manual corrections required the team to revisit part of the chart's initial architecture. The first behavior primarily moved in one direction: answers produced the rendering. Allowing changes from the chart now required a reverse flow in which a visual interaction updated data and then recalculated the representation. We had to separate trajectory state more clearly from its drawing so that a change did not exist only in the SVG without being reflected elsewhere in the application.
Having periods checked during the interview.
The simultaneous presence of the sociologist and participant provided immediate validation. At every stage and at the end of the questionnaire, they could compare the chart with the account, identify a discrepancy, and then change dates. This human verification was essential because an algorithm could check that a date was technically valid without knowing whether it matched the person's memory or intention. The tool facilitated correction but did not decide for participants.
Taking the lead on adding interconnection.
When the second-screen requirement emerged, I took ownership of real-time communication implementation. Socket.io was then a widely used solution for establishing event-based exchanges close to WebSocket behavior in a JavaScript application. A WebSocket maintains a bidirectional channel between a client and server so that either can send an update without waiting for a new page request. This approach suited immediate chart sharing.
Creating an identified, password-protected room.
Before an interview, the interviewer checked existing rooms or created a new one with its own identifier. They set a password, then provided the identifier and password to the participant. The participant opened the application on their screen and entered the information to join the correct room. This protection suited a local demonstration and prevented accidental association between screens; it did not replace a complete authentication and authorization system for a deployed release.
Synchronizing only the state required by the second screen.
The interviewer retained the form and their own chart. The participant received only the data required to display their trajectory. When an answer or date changed the chart, the corresponding state was sent to the room and applied on the secondary screen. Limiting exchanged data to this need simplified the flow and prevented the participant interface from exposing controls reserved for conducting the interview.
Providing manual reconnection in the prototype.
We did not develop an advanced automatic recovery mechanism. If a connection was lost, the participant had to reopen or rejoin the application by entering the room identifier and password. The interviewer could continue using the form. This solution was sufficient for the local demonstration environment, but a production release should detect reconnection and automatically resend complete chart state.
Writing tests for the main functions.
We wrote tests to verify the form, chart, and synchronization. Tests allowed expected behavior to be replayed after a code change and detected when a rendering change broke a previously validated function. They were supplemented by demonstrations to researchers because a technical assertion could not determine by itself whether a trajectory remained understandable or faithful to sociological methodology.
Presenting progress every week.
We showed the prototype to sociologists every week. These recurring meetings presented new functions, identified misunderstandings, and decided on the next work. Tasks and issues were tracked in Jira, while the professor-researcher guided us in arbitrating subjects related to methodology. The ability to change dates after entry is a direct example of user feedback becoming a significant product change.
Versioning collective work in GitLab.
The frontend and backend were located in the same GitLab repository. Git recorded change history, while GitLab hosted the repository and collaborative work. Each of the three developers worked on a separate branch—a line of isolated development—after which code was merged into a shared integration branch. This organization limited direct conflicts and allowed us to verify assembled contributions before considering a release ready for demonstration.
Preparing two local demonstration configurations.
One command launched the application on localhost, the address through which a computer accesses a service running on itself. The interviewer could create or resume a survey, create a room, and set its password. For a demonstration on one computer with two displays, two browser windows joined the interviewer and participant interfaces. When two devices were used, each ran the project and the participant screen joined the room using the provided information.
Documenting setup and demonstration data.
The Docusaurus site gathered the information required to understand, launch, and continue the project. The installation guide also detailed PostgreSQL database setup and seed execution. A seed is an initial dataset injected automatically to provide consistent examples for development or testing. This procedure allowed the next developer to recreate a working environment without depending on files present only on our machines.
Stabilizing the prototype before the final presentation.
During the final phase, we cleaned the code, completed documentation, and wrote testing materials for professor-researchers. Cleanup did not involve adding new functions, but making the existing release more understandable and reliable for demonstration. We prioritized the ability to present and continue the prototype rather than a final extension that could destabilize its core.
Conducting a direct handover with the next developer.
Handover was not limited to the repository and Docusaurus site. We met the person continuing the project to present its objectives, application behavior, code, and documentation. This handover allowed them to ask questions while the original team was still available. It closed the internship by turning the prototype into a transferable working foundation rather than an achievement dependent on its first authors.

Back to contents

The actors — interactions

Three intern developers working on the same prototype.
The implementation team consisted of three student interns, including me. None of us held an official technical-lead title. We therefore had to organize development collectively, divide features, and bring our contributions together in a shared release. This situation placed us in a similar learning relationship while allowing different responsibilities to emerge according to skills and ownership.
A professor-researcher acting as supervisor, computer scientist, and domain owner.
Our supervisor was a computer-science professor and developer, but she was also working on several subjects related to sociological surveys. She therefore did not develop the prototype alongside us every day. Her main role was to explain the scientific context, rules we could not infer on our own, and interview issues. She connected our computer-science work with researcher expectations and intervened when a decision required a deeper understanding of the method.
Tasks divided according to skills.
My two colleagues primarily handled the form and database. They built question sequences, display conditions, and answer persistence. I handled the backend, custom D3.js visualization, and screen synchronization with Socket.io. This division did not completely isolate the developers: data produced by the form had to match the format expected by my chart, while the backend had to work with the model created in the database.
D3.js visualization as my main personal responsibility.
My most important contribution came from my confidence with JavaScript. It allowed me to take ownership of the part we considered most difficult: building a trajectory representation that did not exist as a ready-made component. I had to understand temporal rules from the researchers, turn events into graphical data, and evolve rendering until it supported overlap and correction. This responsibility combined technical problem solving with understanding the scientific requirement.
Daily work supported by a shared office.
We worked together every day in the same office. This proximity allowed us to check a data format, demonstrate behavior, or resolve an integration conflict quickly without waiting for a formal meeting. A form question could immediately be compared with chart requirements, and a backend change could be explained to the people working on the database. The shared office therefore supported short coordination loops within the technical team.
Code reviews before every merge.
We reviewed changes before integrating them into the shared branch. A code review involves examining another developer's proposal to identify an error, check readability, and ensure it respects expected behavior. I performed most of these reviews and usually decided whether changes could join the main branch. This responsibility made me a de facto technical checkpoint even though I had not been assigned an official lead-developer role.
Technical disagreements resolved through collective analysis.
When a technical decision divided the developers, we took time to examine its advantages, limitations, and consequences for the rest of the application. We then sought a shared solution instead of making a decision based only on the preference of the most insistent person. If the disagreement involved a scientific requirement, a constraint we did not understand, or a decision that remained difficult to resolve, we consulted the professor-researcher. This method distinguished implementation debate from domain arbitration.
Prioritization guided by the professor-researcher.
The three interns could propose solutions and estimate their difficulty, but we asked our supervisor to set feature priorities. She could determine whether a change was essential to demonstrating the method or could wait for the continuation of the project. This division was logical: we understood technical effort while she knew the scientific value of functions. It limited the risk of spending several weeks on an improvement that interested developers but remained secondary to the experiment.
Three researchers or teachers involved regularly.
Approximately three sociologists or professors participated in recurring demonstrations. They did not all come from the LIG: some belonged to other French universities, notably Rennes. This diversity broadened feedback beyond our immediate working environment. The prototype had to remain understandable to people who shared a sociological approach without necessarily knowing our technical choices or having participated in every development decision.
Functional validation performed by specialists.
The professor-researcher and the teachers or sociologists validated the form, graphical representation, and event-inclusion rules. Developers could verify that a date was stored correctly or an SVG element appeared at its calculated position, but could not decide alone that the journey respected the survey method. Final behavior validation therefore belonged to the people capable of evaluating its scientific meaning.
A translation role between domain rules and prototype behavior.
Our main responsibility was to turn sociological explanations and rules into usable behavior. To do so, we asked questions until we understood vocabulary, exceptions, and the expected outcome. When the requirement remained abstract, we modeled it through diagrams, entities, or an initial interaction. A domain rule is a constraint originating from the field of activity; here, it describes how a survey or trajectory must work independently of the technology selected to implement it.
Scientific decisions that did not belong to developers.
Researchers broadly agreed on trajectory representation but could discuss how certain events should be included. When interpretations diverged, the professor-researcher made the final decision. Our role was to make options and consequences visible and then implement the selected rule. This boundary prevented a choice made to simplify code from unintentionally becoming a sociological methodology decision.
Validation performed through simulation.
During the internship, we did not participate in actual interviews with survey participants. Usage tests were conducted as simulations with researchers. This method allowed the journey, questions, and chart reactions to be verified without immediately involving real data. It was nevertheless a limitation: an actual research interview may reveal hesitation, unexpected accounts, and field constraints that a simulation between people already familiar with the tool reproduces imperfectly.
Documentation maintained by every developer.
Docusaurus ownership was shared. Every member updated the documentation when adding or changing a feature they owned. This rule kept explanation writing close to the time when context was still fresh. It also prevented one person from having to reconstruct at the end how components they did not develop worked. Documentation therefore became a continuous team output rather than an isolated task added on the last day.
A two-week handover to a new developer.
The person joining after our internship was responsible for turning the prototype into a real application and evaluating whether it could genuinely be used in sociological surveys. Handover lasted two weeks. We presented the complete project, code, launch procedures, and documentation. On my side, I could notably explain the areas I owned, such as the backend, D3.js, and Socket.io, while participating in the presentation of overall behavior.
A handover that supplemented written documentation.
Handover involved more than providing repository access. The new developer needed to understand why certain decisions had been made, which limitations deliberately belonged to the prototype, and which subjects remained open. Direct discussion allowed questions that the setup guide could not anticipate. Combining documentation with two weeks of availability reduced the risk that a temporary simplification would be interpreted as a final application rule.
Learning communication between research and development.
The project taught me that collaboration with researchers requires handling three dimensions simultaneously: technical feasibility, the domain rule, and communication during construction. A solution may operate without respecting the method, while a scientifically relevant request may require several reformulations before it becomes implementable. I learned not to respond only through code, but to verify what the feature was intended to reveal and why that observation mattered.
Iterations that could have been even shorter.
Despite weekly demonstrations, I believe we could have requested some feedback sooner. A shorter loop between initial implementation and validation would have identified misunderstandings earlier and improved quality progressively instead of accumulating several changes before presentation. This criticism does not negate the regular collaboration; it shows that a research subject benefits from confronting technical assumptions with the people who own the method as early as possible.

Back to contents

The results

A questionnaire usable from beginning to end.
By the end of the internship, an interviewer could complete the entire form and finish a simulated interview. The prototype was therefore not limited to a few independent fields intended to illustrate an interface. It supported movement through dimensions, conditional questions, adding several events when a situation repeated, and returning to answers. This result validated the first mandatory element defined at the beginning of the project.
Five trajectory dimensions genuinely available.
The questionnaire and visualization supported five life dimensions. Each dimension grouped events belonging to the same domain and had its own row or area in the representation. This separation gave researchers several reading angles without turning the trajectory into one undifferentiated sequence of events. It also provided an extensible foundation if the method later needed to add or reorganize domains.
Approximately twenty main questions supplemented by repeatable sequences.
The questionnaire contained more than twenty core questions. This number did not represent the maximum interview length because some groups could loop according to answers. The professional trajectory, for example, asked for a job description and then offered the option to add another. A person who had held several positions therefore generated multiple occurrences of the same sequence. The prototype could adapt collection to the richness of a path instead of imposing a fixed number of events.
A visualization matching answers and periods.
The second mandatory objective was achieved: entered answers produced a graphical trajectory in which events appeared at the expected periods. Start dates, end dates, and dimensions determined their position. The result could be checked during the interview and corrected when a period did not match the account. The visualization was therefore not a screenshot prepared for the demonstration, but a rendering calculated from form data.
Two functional reading modes.
Separate and overlaid views both worked in the final prototype. The separate view made one dimension easier to read, while overlap supported observation of concurrent events across several domains. A concurrent event occurs during all or part of the same period as another. Switching modes demonstrated that the same trajectory could support several analytical questions without requiring new data entry.
Corrections available from two entry points.
The interviewer could change dates from the form and chart. This result addressed feedback that a person may correct their account after seeing the complete trajectory. A change updated the data and then recalculated the representation rather than only moving a visual element without changing the stored answer. This consistency between interface and data was necessary for the chart to remain a working tool rather than merely an illustration.
An operational multi-screen demonstration.
Socket.io synchronization worked sufficiently for demonstrations. The interviewer could create a room, the participant could join it, and then receive trajectory updates on their screen. This result materialized the most significant change added during the internship: allowing both participants to share the representation without sharing form controls. It demonstrated feasibility of the experience in the local environment intended for the prototype.
Known defects remaining in synchronization.
Delivery was not bug-free. Graphical data synchronization was not yet perfect, and some sequences could produce a delay or inconsistent state between screens. This finding remained compatible with the proof-of-concept objective, but prevented real-time communication from being considered ready for unsupervised field use. The result is therefore a demonstrated interconnection accompanied by a clearly identified need for stabilization.
A fully passing but incomplete test suite.
Every written test passed at handover. They covered behaviors the team chose to automate and reduced the risk of breaking the form, chart, or synchronization during final changes. In hindsight, we could have written more scenarios, particularly around edge cases and connection loss. A green result means only that the described cases conform; it does not prove that every possible behavior has been tested.
Researchers believing that the project was moving in the right direction.
Final feedback from professors and sociologists was positive: the prototype appeared to be progressing in the expected direction. This assessment validated the general relevance of the form, representation, and shared experience. It did not yet constitute complete scientific validation. Researchers stated that they would need to test the tool in actual interviews to observe its behavior with real accounts, hesitation, and field constraints.
A method that could be evaluated but had not yet been validated in practice.
Researchers considered the prototype sufficiently mature to evaluate their proposal. Simulations allowed them to examine chronology, dimensions, and the effect of the chart during the interview. No result yet supported a claim that the tool genuinely improved an interview conducted with a person external to the project. This distinction protects the achievement's credibility: we produced the instrument required for experimentation, not the conclusions of the experiment itself.
Distribution still limited to the project circle.
To my knowledge, the final release was not presented during my internship to a wider audience than the researchers and teachers already involved. The prototype therefore produced no measurable result in terms of adoption, user count, or institutional distribution. Its immediate value lay in the quality of the handed-over foundation and its ability to support the study office's next decisions.
Successful installation by the next developer.
The person responsible for continuing the project succeeded in installing and launching the application using the documentation and handover. This result concretely verified part of the prototype's transferability. The setup guide, database configuration, and seed were not merely present: they enabled someone who had not built the first release to recreate the environment.
Technical continuation deferred for reasons outside the handover.
The new developer did not begin changing CAP2vie during the two handover weeks because they were occupied with other study-office work. This absence of immediate development therefore does not mean that installation or documentation failed. It does reveal the limit of what I can prove: we transferred a runnable foundation and explained how it worked, but did not observe the successor develop a first feature independently during that period.
Post-internship evolution that I cannot attribute precisely.
I do not know which components were ultimately retained or changed after the internship. Data and subsequent work became confidential, and I no longer had the necessary visibility. I therefore do not present a deployment, reuse, or adoption that I could not verify as an achieved result. The documented outcome ends with prototype delivery, its launch by the successor, and transfer of available knowledge.
A first technical foundation that did not exist before the internship.
The laboratory and study office initially had a research idea and diagrams, but not the corresponding application. When we left, they had a versioned repository, data model, dynamic questionnaire, custom visualization, multi-screen communication, tests, and a documentation website. Although these elements still required stabilization, they reduced the work needed to move from theoretical reflection to initial instrumented trials.
Creating a solution without a directly reusable equivalent.
The technical result I am most proud of is my ability to build the visualization from primitives when no component found online directly produced the requested representation. My resourcefulness involved researching available mechanisms, understanding how they worked, and combining them according to project rules. I did not invent D3.js or time scales, but used those building blocks to design a solution specific to a problem for which no ready-to-integrate answer existed.
A deeper understanding of D3.js.
The project taught me to use D3.js as a construction library rather than a chart catalog. A library provides reusable functions without imposing the complete architecture of a framework. I learned to bind data to SVG elements, use time scales, calculate positions, and update rendering when state changed. This approach gave me greater autonomy to produce custom visualization instead of searching only for a component close to the requirement.
Better understanding of real-time connection states.
Socket.io taught me that a connection is not limited to the case where two screens are available and receive events correctly. Room creation and closure, late client arrival, connection loss, reconnection, message order, and complete-state resynchronization must also be considered. The prototype did not yet handle every case perfectly, but the defects encountered showed me precisely why a stable connection requires explicit management of each one.
Progress in reading other developers' code.
Performing most reviews improved my ability to understand another developer's work quickly, identify its effects on my components, and formulate a correction request. Reviewing code requires distinguishing a personal preference from a real readability, consistency, or behavior problem. This responsibility gave me initial experience in collective quality control even without an official technical-lead role.
A direct contribution to earning my professional title.
CAP2vie was one of the achievements I presented to demonstrate the competencies expected in my Application Designer-Developer training. The project provided evidence of design, frontend and backend development, persistence, testing, collaboration, and handover. It therefore contributed directly to earning the title without being presented as its sole condition: evaluation also relied on other elements and competencies from the program.
Communication as the main human skill developed.
Discussions with two other developers, a professor-researcher, and several sociology specialists taught me to adapt my vocabulary and confirm understanding before coding. I had to explain a JavaScript constraint without overwhelming researchers with implementation details, then rephrase a scientific rule so that the technical team could use it. This communication was essential to prevent a computer-science solution from correctly implementing the wrong interpretation of the requirement.
Visible evidence already included in the portfolio.
The page already presents screenshots of profile selection, local interfaces, and the survey-creation journey. These elements show that the prototype existed and illustrate its general behavior without exposing actual participant data. Detailed text also explains technical choices and personal contribution. I limit evidence to what can be published: some project elements, code, and later developments remain confidential.
A benefit consisting of making experimentation possible.
The five months gave researchers a prototype for examining how digital tools could modernize sociological survey practice. Participation by professors from the LIG and other universities, notably Rennes, created potential value beyond one laboratory. I nevertheless describe potential across several French teams rather than a nationwide deployment that had already occurred. The demonstrated benefit was providing a concrete foundation for testing that ambition.

Back to contents

After the project

A continuation mission deliberately broader than bug fixing.
The person joining after the three interns was expected to improve the tool and explore its transition from prototype to a more complete application. Their mission was therefore not limited to preserving the September 2024 demonstration unchanged. They had to understand existing choices, stabilize useful functions, and decide how to address the limitations left by our scope. Handover and Docusaurus provided a starting point, but product and research decisions still had to continue with the supervisors.
Synchronization as a priority workstream.
Known defects in graphical-data exchange were meant to be corrected after our departure. Real-time communication intended for regular interviews needed better handling of connection loss, reconnection, and bringing the participant's screen back up to date. The priority was consistent with the second screen's role: it still should not block the form, but needed to become reliable again without requiring technical intervention for every anomaly.
No real-world trial already scheduled at the end of the internship.
Researchers had stated that validation with actual participants would be necessary, but no experimentation schedule had been set when we left. The next methodological step still had to be organized: defining participants, protocol, consent conditions, and observation criteria. The prototype made this trial possible but did not determine its date or scientific organization.
Actual continuation that I cannot confirm.
I do not know whether CAP2vie officially continued development after handover. The new developer had successfully installed the project but was then working on other study-office assignments. I therefore do not turn an intention to continue into a verified result. Today I can describe the roadmap considered at the end of the internship, not the actual state of a later release to which I no longer have access.
Questionnaire creation not retained as an immediate priority.
An interface allowing sociologists to build their own questionnaires had been discussed as a possible evolution, but was not among the announced next priorities. Before adding this editor, the team needed to consolidate existing behavior. This choice avoided introducing a complex system of question types, versions, and answer compatibility while synchronization and prototype use still needed to be tested.
Management of multiple surveys and people as a planned evolution.
A more complete release was intended to store and organize several surveys and multiple participants. This feature required proper separation of datasets, retrieval of an interview, and preservation of relationships between questionnaire, answers, events, and trajectory. It had to turn the structure already prepared in the prototype into a genuine management area rather than a demonstration centered on one journey at a time.
Authentication and roles to add.
Local operation and a room password were insufficient for administering multiple studies. A future release needed to identify users and apply roles. Authentication verifies who is connecting; authorization then determines what that person can view or change. An interviewer, study manager, and participant viewing their trajectory do not require the same access. This evolution was essential before regular use with real data.
Automatic anonymization planned for continuation.
The application was ultimately intended to handle anonymization of collected data itself. This feature would separate identity information from answers used for analysis through a reproducible procedure. It still had to be designed with researchers: removing only a first and last name does not guarantee that a highly distinctive trajectory cannot be recognized. A future release therefore needed to define the affected fields, when transformation occurred, and who could access information before anonymization.
CSV as the planned export format.
CSV was the planned format for extracting data. A CSV file organizes information as rows and columns separated by a character, allowing it to be opened in a spreadsheet or imported into analysis software. Export had to preserve dimensions, dates, and events in an understandable structure. The exact destination platform was not yet known, requiring a format documented well enough to remain usable by several tools.
Local use retained as the main mode.
The application was intended to remain usable locally in the interview context. This choice limited dependency on public hosting and matched face-to-face use by interviewer and participant. It did not remove security or backup requirements: sensitive data remains sensitive when stored on a local computer. A complete release therefore needed to document installation, storage, and recovery without assuming that offline operation automatically protected all information.
Synchronization to make robust beyond the local demonstration.
Even if the application remained installed locally, communication between screens needed to evolve to support less ideal network conditions and possibly remote uses. This improvement involved handling latency, interruptions, and resynchronization without losing chart state. The distinction matters: installation mode could remain local while the communication channel became more robust and stopped depending on controlled office conditions.
Future quality evaluated through user feedback.
Researchers intended to assess the tool through feedback from interviewers and study participants. This feedback had to indicate whether the form properly supported the conversation, the trajectory was understood, and its presence helped correct or enrich the account. This qualitative evaluation was more relevant than a simple click count. It needed to confront the research hypothesis with actual use before generalizing the application.
Documentation intended to keep evolving.
Docusaurus was not meant to remain a fixed snapshot of the prototype delivered in September 2024. Future developers were expected to update setup, architecture, and functions as they made changes. Outdated documentation can become more dangerous than no guide when it describes a command or rule that no longer exists. Project continuity therefore depended on evolution of its explanation as much as its code.
An ambition involving a national network of partner universities.
In the long term, CAP2vie could be made available to a network of partner universities in France. Participation by researchers from the LIG and Rennes provided an initial setting for this ambition. Nationwide distribution would nevertheless have required a stable application, data governance, support, and a method validated in actual interviews. I therefore present this scale as the project's intended direction rather than adoption already achieved.
Confidentiality deliberately limiting my current follow-up.
I currently have no information about the project's state. If the laboratory asked me to contribute again, I could do so, but only on its premises and in compliance with its rules: code, data, and confidential materials must not leave. This constraint explains why I can neither publish a recent release nor verify the roadmap. It protects research information and requires me to limit the portfolio to evidence approved for distribution.
A visualization skill already reused in Business Intelligence.
I have not reused CAP2vie in sociology, but the knowledge gained from custom representations is directly useful in my current company. I apply it to a Business Intelligence, or BI, service intended to make operational data understandable. Business Intelligence covers methods and tools that turn data into indicators and visualizations supporting decisions. The context changes, but the approach remains similar: structure data and then build a representation suited to the question being asked.
A project professionally useful through skills rather than domain.
CAP2vie remains far removed from my current work around ERPs, APIs, and business tools. I therefore do not create an artificial continuity between sociology and Odoo. Its place in my journey comes from transferable skills: designing from a specialized requirement, creating visualization without a ready-made solution, managing a backend and real-time communication, reviewing code, and discussing requirements with non-developer experts. These achievements, rather than the scientific subject itself, continue to shape my profile.

Back to contents

My critical review

An answer-resolution algorithm insufficiently explored before initial integration.
My main mistake was not devoting enough time to the algorithm that transformed form answers before integrating the first features. An answer-resolution algorithm here means the set of rules that interprets answers, creates events, completes unknown dates, associates a dimension, and prepares chart data. While only simple cases were used, the first release appeared correct. More varied answers later revealed that this foundation needed revision.
A form-to-chart bridge that became the most frequently reworked area.
The architecture most often changed was the bridge between the form, stored answers, and their insertion into the visualization. A bridge, or transformation layer, connects two representations with different roles: the form produces answers close to interview language, while D3.js expects structured events with dates and a dimension. If this bridge combines validation, temporal estimation, and drawing, every new rule requires changes in several layers. We would have benefited from designing it as an independent, testable module from the outset.
Development that probably began too quickly.
The specification was precise enough to define the prototype, but that did not mean the internal algorithm had already been resolved. We probably started integration too early by confusing understanding of the broad requirement with mastery of every transformation case. This nuance matters: more domain documentation alone would not necessarily have been enough. We needed dedicated technical time to simulate several journeys, formalize rules, and verify their consistency before building interfaces around them.
A broadly balanced division of work.
I consider the distribution between the three interns appropriate. My colleagues handled the form and database while I worked on the backend, D3.js, and Socket.io. I would not have preferred to exchange my scope for more form or persistence work: the subjects assigned to me were those I found most interesting and stimulating. The main issue therefore did not come from a poor allocation of responsibilities.
Useful code reviews without excessive overhead.
Performing most reviews did not prevent me from progressing on my own tasks. The team did not produce enough commits for this responsibility to become a bottleneck. Reviews instead helped me understand the form and database on which my components depended. With a larger team or faster pace, this organization would have required rotation or more formal rules, but it remained proportionate to the prototype.
Insufficient testing of complex answer scenarios.
The main weakness in the test suite concerned the diversity of possible questionnaire paths. A conditional answer could add several jobs, produce an estimated date, leave a boundary unknown, or change an event afterward. Every combination could influence the bridge and final trajectory. We tested expected operation but not enough edge cases or combinations. A green suite therefore still concealed a space of underexplored behavior.
Disconnection and reconnection scenarios that deserved more testing.
We should also have explored Socket.io testing further. We needed to verify what happened when a screen joined a room late, disconnected during an update, entered incorrect credentials, or returned after several changes. These scenarios did not concern the ideal path, but determined the perceived stability of sharing. The known synchronization bug showed precisely that connection had been validated in its main operation without covering degraded states sufficiently.
Estimated periods capable of creating artificial continuity.
Reusing the end of the previous event as an unknown beginning or extending an event to the next one can create a period that appears more precise than it is. This risk was known and accepted in the sociological method used for the prototype. It does not make the algorithm incorrect in principle, but requires an estimate to be distinguished from a date stated with certainty. A more complete release should preserve this precision information so that the chart does not turn an interview convention into a certain fact.
Direct chart editing that was ambitious but appropriate.
I do not consider editing dates from the visualization to have exceeded the reasonable internship scope. It addressed a central need: allowing a person to correct their trajectory when viewing it as a whole. The feature caused an architectural revision, but its value justified the effort. The lesson is not to remove it; it is to plan earlier for the chart to be an interactive entry point into data rather than a read-only result.
Socket.io as a choice that remains relevant.
In hindsight, Socket.io remains an appropriate solution for sharing the chart between two screens. The library provided events, rooms, and basic connection handling required by the JavaScript prototype. Defects encountered do not prove the tool was wrong: they show that synchronization and recovery logic required further development and testing. Replacing the library would not have removed the need to manage the same network states.
Local operation consistent with a proof of concept.
Limiting the prototype to local execution did not reduce its value relative to the stated objective. It demonstrated the form, chart, and second screen without prematurely adding hosting, administration, and production security. This limitation would have been problematic if we had presented the tool as ready for a national network, but it was appropriate for initial validation on laboratory premises.
Room protection sufficient only in this controlled context.
A room identifier and password provided acceptable separation during local simulations. They prevented a screen from easily joining the wrong interview. I would not consider the same arrangement sufficient for actual deployment: it would notably lack researcher authentication, permissions, robust secret management, and network protections. The relevance of a security measure therefore depends on the level of exposure and sensitivity of the use it protects.
Automatic anonymization correctly postponed.
I do not think we should have handled integrated anonymization earlier. The internship first had to verify collection and representation while researchers continued defining the appropriate data treatment. Adding automated removal too quickly could have created a false impression of security. Postponement was reasonable as long as the prototype remained in simulated use and was not presented as a platform ready to collect real data at scale.
The absence of a real interview as the result's main limitation.
The most important restriction does not concern a library or screen: no person external to the project used CAP2vie during an actual sociological interview. Researchers knew the method and prototype, which made their simulations easier. A real user might have hesitated, interpreted a question differently, reacted to the chart, or described an event that did not fit our scenarios. Until this confrontation occurred, relevance under actual conditions remained a hypothesis.
Sufficient weekly meetings but end-to-end feedback obtained too late.
One demonstration per week was appropriate for the internship pace. What I would have liked earlier was not necessarily more meetings, but feedback as soon as the form was connected to chart data. This first complete chain was the point at which researchers could observe the real effect of their answers. Showing it earlier would have revealed bridge weaknesses before several features depended on its initial architecture.
Three decisions I would make differently.
If I restarted, I would first build a complete functional slice with a few representative questions from form to chart. I would then formalize the answer-resolution algorithm by listing edge cases before expanding the question set. Finally, I would ask researchers to test this first chain immediately and then add features according to observed defects. These decisions would focus effort on core solidity before prototype breadth.
D3.js mastery that I assessed at 6 out of 10.
At the end of the project, I assessed my level at 6 out of 10. I could build an original visualization, use SVG and time scales, and update rendering interactively. I nevertheless remained aware of D3.js's depth. The library covers many transformation, layout, interaction, and performance mechanisms that the prototype did not require. Chart success demonstrated useful mastery, not exhaustive expertise across the ecosystem.
Backend and Socket.io mastery assessed at 7 out of 10 at the time.
I placed my level then at 7 out of 10. I could design routes, connect application layers, create rooms, and transmit required updates. Synchronization defects nevertheless showed that I still needed to deepen failure scenarios, state recovery, and robustness in an application used for real work. This score reflects both the autonomy achieved and the prototype's observable limits.
A clearly higher backend level today.
Since 2024, I have developed and maintained backend functions used in production at my current company. Constraints there are stronger: service continuity, business data, security, integrations, and direct consequences of errors for users. This experience improved my ability to structure logic, diagnose a problem, and anticipate degraded cases. I do not give myself an artificial current Socket.io score without equivalent recent practice, but my general backend mastery is clearly higher than at the end of the internship.
A deliberately basic visual result.
The part of the prototype that satisfied me least was the chart's appearance. The result worked and demonstrated the expected representation, but its design remained simple. This level of finish was consistent with a proof of concept focused on algorithm and interaction. It would nevertheless have required further interface, visual-hierarchy, and accessibility work before being presented as a tool for regular use by a university network.
D3.js as a technical choice I still support.
Among the decisions made, D3.js remains the one I find most relevant. A prebuilt charting library would have accelerated display of a conventional chart but quickly blocked us on five dimensions, periods, overlap, and editing. D3.js gave us the required primitives without imposing an incompatible representation. Its depth increased the learning effort, but that complexity matched the freedom the project genuinely needed.
Allocating more time to architecture and algorithms.
The main advice I would give a team building a research prototype with changing requirements is not to confuse production speed with learning speed. Before multiplying screens, identify the algorithmic core, submit simple and extreme cases to it, then build one end-to-end chain. An architecture does not have to be final from the outset, but it should isolate what is likely to change. Time invested in this thinking reduces the rework that truly slows the project later.

Back to contents

Development of a life trajectories web application

Visual proof

A five-month internship completing an application designer-developer program.

A project hosted at the Grenoble Computer Science Laboratory.

Supervision by a professor-researcher working on sociological uses.

CAP2vie, a name built around a person's “life course.”

The life trajectory as an object of study.

A tool for comparing paths and informing decisions.

Replacing data collection performed mainly on paper.

Intended use during face-to-face and field interviews.

Two complementary roles within the same interview.

A visualization shared across several screens.

Questions organized around event content and context.

Sensitive information requiring anonymization after the interview.

A project started from an idea rather than existing software.

A cross-cutting scope spanning visualization, backend, and real-time communication.

A technical stack selected collectively to build the first prototype.

A research prototype as the expected outcome.

Materializing a research method in a prototype.

Limiting the initial core to two mandatory functions.

Starting from a questionnaire defined by the researchers.

Collecting text, dates, and periods.

Turning every event into a chronological interval.

Representing dimensions separately and simultaneously.

Preserving narrative fidelity rather than producing only an attractive chart.

Making the form usable by the interviewer.

Making the trajectory understandable to the participant.

Adding multi-screen interconnection during the project.

Isolating each interview in a communication room.

Not blocking the interviewer if the secondary screen disconnects.

Evaluating the prototype through use rather than production scope.

Explicitly preparing handover to another developer.

Requirements likely to evolve with the prototype.

An architecture impossible to get entirely right on the first attempt.

A visualization matching no standard chart.

A visually plausible but scientifically incorrect chart.

A representation capable of influencing interpretation.

Disagreements belonging to sociological method.

A form experience capable of disrupting the interview.

A multi-screen extension adding a new point of failure.

An interruption that could not block data entry.

Local operation that did not prove Internet robustness.

Possible information loss in a prototype.

Anonymization not automated within the application.

Access features still limited by scope.

No export or delivery to a specialized platform.

A flexible deadline but an outcome expected within five months.

Future continuation dependent on handover quality.

Starting by documenting the requirement.

Turning explanations into working materials.

Not creating mockups that would not have reduced uncertainty.

Organizing the internship into iteration cycles.

Selecting Nuxt and Vue from the team's skills.

Keeping a simple JavaScript backend with Express.

Modeling data with PostgreSQL and Prisma.

Defining the main domain entities.

Building a single form organized with a stepper.

Adapting questions to previous answers.

Associating every answer with a dimension.

Building periods from exact or estimated dates.

Turning answers into temporal data for D3.js.

Building the chart with D3.js primitives.

Providing multiple dimension reading modes.

Evolving the chart through three main versions.

Allowing correction from the form and chart.

Revising the architecture to make the chart editable.

Having periods checked during the interview.

Taking the lead on adding interconnection.

Creating an identified, password-protected room.

Synchronizing only the state required by the second screen.

Providing manual reconnection in the prototype.

Writing tests for the main functions.

Presenting progress every week.

Versioning collective work in GitLab.

Preparing two local demonstration configurations.

Documenting setup and demonstration data.

Stabilizing the prototype before the final presentation.

Conducting a direct handover with the next developer.

Three intern developers working on the same prototype.

A professor-researcher acting as supervisor, computer scientist, and domain owner.