Team Meeting Notes: Team Meeting 001 (CSE-210-02 Meeting 001) Kickoff
Format: Hybrid (in-person at the CSE Building and remote on Google Meet)
Participants: Brian, Charlie, Jessie, Gage, David, Nathan, Kai and Jooahn
NOTE
These notes were transcribed by OpenAI's Whisper model and summarized by Claude. The summarized output has been edited for clarity and correctness by Brian
1. Project Scope and Goals
The project is a from-scratch graphing library plus a single-page website to showcase it. Existing charting libraries (e.g., Plotly and the many NPM options) can no't not to be used. Powell wants to see the engineering process rather than a finished product built on someone else's work.
The team is effectively its own "user." The group is unsure whether the library will be reused in a later project (a possible "part 2"), but agreed not to over-engineer for it.
Time is limited (roughly a weekend, plus the team video), so the priority is a simple working version first, with extras added if time allows.
Decision: Optimize for simplicity and build a minimal version first; no extra scalability (e.g., no classes) unless it is needed later.
Charlie's reasoning: scalability has a cost that isn't worth paying if it won't be used.
2. Data Formats and Data Parsing
Input formats considered: CSV or JSON. CSV is probably the easiest.
Data cleaning/validation is needed before plotting, since users may leave blanks or enter non-numeric values, which could break the site. Gage will act as a QA tester and try to break the tool with bad inputs (empty data, no headers, a 100,000-character title, etc.).
Decision: Accept CSV input and include a data parsing/cleaning step before graphing.
3. Shared Data Format and Chart Configuration
A shared object is needed so the scatter, line, and parsing work can proceed independently.
- Points: each point is a JSON object with X and Y (numbers/floats), and possibly a color. JavaScript has no tuples, so arrays were discussed as the alternative. Arrays and "pairs of variables" were seen as largely a style choice.
Ex: Point
{ "coordinate" : [x, y] }Chart Configuration
- Chart-level object: a chart title, X and Y axis labels, a units field (units as a separate field vs. part of the label was left open), X/Y min and max (useful, low cost), and an array of points. Axis scaling (e.g., log scales) is downstream of the object and does not need to be solved by whoever builds it.
{ "title" : ..., "x-axis-label": ..., "y-axis-label": ..., "points": [ {...} ] }The chart type (scatter or line) is passed in as a simple string option, since the library is a function the caller invokes.
Line chart: connects one point to the next with no interpolation or best-fit line. Points must be sorted by X first, using the built-in sort with a comparator. For small datasets, sorting cost is negligible. Scatter plots do not need sorting.
Decision: Use a plain JSON object (no classes) for the points and chart configuration, with an array of points inside the chart object.
4. Architecture and Technology
- The library is plain JavaScript and uses SVG for rendering.
- The chart function returns an SVG element that the caller inserts into the DOM. The chart itself is independent of the website.
- The library will likely be an NPM package that the website installs. It may not need to be published to NPM, but packaging makes CI/CD easier.
- CI/CD: use GitHub Actions to deploy the library. Host the site with GitHub Pages.
- A GitHub repository was created under the team's GitHub org, and members were invited.
- Components identified: points, line, axes/background/labels, data parsing, website skeleton, chart-type selector, and interactivity.
- Decision: Use standard JavaScript with SVG, with no third-party charting library.
5. Interactivity
- Tooltips on points (likely just showing X and Y) can be added to the SVG with a simple observer/hover listener.
- Interactivity is a later task, after the basic charts work.
- The user should be able to add data but not edit existing data, though the group acknowledged that people can always edit the code.
- Decision: Keep it simple and avoid over-complicating the design.
6. Website Design
- The site is a single page that embeds the chart and lets users upload a CSV, then generates the graph.
- Features: a short introduction/text, tabs to switch between scatter and line charts, a CSV input area, and a copy-SVG button.
- Design: a purple theme (Brian built a quick sample and shared the color), a chart in a rectangle with tabs on top, and the chart title inside the graph.
- Library name: tentatively a play on the instructor's own graph software ("Zing" chart naming was floated). Not finalized.
- Decision: Purple-theme (hex: #D0B7E5) single-page site with a layout like the sample Brian mocked up.
7. Documentation
- Use JSDoc comments in the code and generate documentation from them. Markdown files on GitHub are also an option.
- Everyone should document their own code, including why they made specific design choices. This will feed the video and report.
- Decision: Each member documents their code and the rationale behind choices, so trade-offs can be written up later.
8. Engineering Process and Tasking
- The instructor mainly evaluates the demonstrated team process and thought process.
- Tasking will be tracked with GitHub issues. Brian will put the component list on GitHub, and anyone who thinks of more tasks can add issues.
- Charlie suggested a timeline to track progress. A dependency view was also floated, though interactivity may not depend on other pieces.
- The team will not plan everything upfront (a waterfall approach was seen as unrealistic). Start building and adapt as issues come up.
- Trade-offs to mention in the report: simplicity and limited time. The team also debated the data format choices.
9. Role Assignments
| Person | Role |
|---|---|
| Kai | Scatter plot (using SVG, from Nathan's object) |
| Nathan | Build the chart object from ingested input data and chart type |
| David | Line chart (using SVG, from Nathan's object) |
| Gage | QA Tester Try to break the tool |
| Jessie | Website web design for the tool |
| Brian | Interactivity, CI/CD setup, repo/GitHub setup |
| Charlie | Chart work (points/line/background); general organization support |
| Jooahn | Additional support and coordination (in meeting we said check GH issues) |
Note: These roles are subject to change based on the team's evolving needs and individual expertise. Check the GitHub issues for confirmation.
10. Team Video
The video is about 4 minutes and is open-ended: team introduction, team reinvention/culture, task approach, results, and a demo.
Content ideas: introductions (name, plus a fun fact), the trade-offs made (simplicity, time), and the data format debate.
Powell plans to show videos in class, so it should be well made. A short script is recommended.
The group compared with example videos from other teams, which were recorded online. Recording separately and editing together is acceptable.
Decision: Hold the next meeting on Monday, sometime before 2 PM (around 1–2 PM). In-person is preferred if a room can be found; otherwise Zoom.
11. Meeting Logistics
Gage has an appointment Monday afternoon and may not attend after 2pm.
Room options explored: CSE building rooms (all taken), Geisel library rooms (may be noisy and small), other campus booking sites, and the conference room in Brian's apartment complex (a bike path across the bridge from the VA trolley stop, with parking).
Sunday is an alternative, though weather may be rainy, and Jessie may join on Zoom.
NOTE
Upon looking I was able to find a large enough room for in Geisel library. Check Slack for the reservation.