For the final project, your team will choose a feature of the Computer Science Experience Labs’ web application to focus on implementing well to serve the UNC Computer Science population. Part of your task is designing the user experience around this feature, with design and technical specification documents. Therefore, the descriptions of each project is intentionally high level and goal-oriented.

Open Hours Editor

The hours in which the CS Experience Labs are opening, available for seat check-ins, and room reservations, is controlled by the OperatingHoursEntity class and corresponding coworking__operating_hours table. Each week, a member of the CSXL staff uses the HTTP API to add open hours for the coming week. This is a classic example of, “the cobbler’s children have no shoes.” We really need a nice, functioning administrative UI for managing our operating hours!

CSXL Staff Need:

1. The ability to add new operating hours
2. The ability to see upcoming hours and edit currently open or future hours
3. The ability to delete errant operating hours in the future

This feature should be integrated into the site using the administration gear on the top-level Coworking page. (For an example, in your DevContainer, login as Rhonda Root and click the gear on the home page to see how news is administered). Your group can design how hours are added and edited via the front-end web UI.

Stretch Goals:

1. Page through operating hours in the past
2. Open a page for current or historical operating hours and see an overview of stats (# desk reservations, # room reservations)
3. Open a page (same as #2) to see a complete list of reservations
4. The ability to safely delete operating hours that already have room reservations made (but not yet checked in or checked out)

Group Reservation for Meeting Rooms

The CS Experience Labs currently has 7 rooms available for reservation throughout the week. These rooms range in size between 2-seats, for pair programming to 7-seats, for larger teams.

At present, one person can reserve any of these rooms individually. For the most part, folks are using the spaces appropriately, although occassionally we will see folks reserve 7-seater rooms to work alone. This is fine, if no one else could have used the room at the time.

We would like to update the system to optimize for group usage with the following semantics: when a room reservation is made for more than 30-minutes in the future, the person reserving must add at least ceiling(room size / 2) fellow occupants. The user will need to add their fellow meeting room occupants to the reservation. Anyone added needs to also see the reservation show up, once saved. The back-end entities and API already supports adding multiple users to a reservation, however no logic for controls exist in the backend and no UI exists in the frontend. If a room is open at the moment a user attempts to make a reservation starting immediately, not in the future, this requirement can be relaxed and the room should be reservable for one hour.

Needs:

1. Front-end UI for adding additional people to a future room reservation
2. Logic for differentiating future room reservations from immediate room reservations and verifying validity of request full-stack per the logic above
3. A friendly user experience that makes expectations and instructions clear to the person making the reservation
4. Ensuring members added do not have conflicting reservations
5. The ability to see all members of a group reservation in the XL Ambassador view

Stretch Goals:

1. The ability to edit a reservation after it is confirmed to add/remove members and maintain expected logic
2. The ability for any member of the reservation to check-in once the reservation begins

XL Usage Statistics and Visualizations

(Note: This feature really needs a team where at least one member of the team is currently in, or has taken, COMP421: Databases. Computing these statistics in SQL requires more advanced SQL understanding than we are able to teach in COMP423.)

We would like an Admin page where statistics about the usage of the CSXL Co-lab, Room Reservations, and Office Hours are aggregated and presented. Ideally, this information would be presented in a combination of graphical and tabular presentations. Seeing trends at varying time intervals (days of the week, weeks of the semester, and so on) would be useful.

Needs:

1. Admin-only page where statistics over the past two weeks are shown
2. Useful visualizations (e.g. bar/column charts organized by date) of recent usage of co-lab seat reservations (perhaps stacked by type of seat: monitor vs. standing vs. communal)
3. Useful visualizations of recent room reservations (perhaps stacked by room size: 2-seater, 5-seater, 7-seater)
4. Useful visualizations of recent office hours tickets served (perhaps stacked by course)
5. Tabular representations of the data

Stretch goals:

1. The ability to control the time extents (start/end) of statistics as well as aggregation period (daily vs weekly)
2. The ability to export data to CSV formats
3. Other ideas for interesting stats (breakdown by unique people vs. repeat visits, leaderboards of users by usage)

Student Organization Roster Management and Members-only Features

Student Organizations currently have no form of membership or leadership represented in the CSXL database. If membership/leadership relationships were established with users, it would enable additional features for student organizations (such as members-only events, information, and so on). Some student organizations are open to all interested while others require application processes. A special case of an “organization” is the CS Department and CSXL, which do not have memberships.

Student Organizations Need:

1. The ability to distinguish type of organization (open to all, application/request-based, closed)
2. The ability for a user to request to join an organization that is not a closed organization
3. The ability for organization leaders to accept or deny requests to join (when application/request-based)
4. Memberships to be based on Academic Terms (e.g. joining for Fall 2024 and Spring 2025)
5. Memberships to have a “level” assigned to it (member, leadership)
6. Memberships to have optional titles (e.g. President, Treasurer)
7. Memberships to have an admin toggle which give a member privileges to edit CSXL website info/events for organization
8. The ability for an org to list its leaders (and members?) by academic term on their organization page

Stretch Goals:

1. The ability to post members-only information in markdown format (for things like links to Slack, etc.)
2. The ability to have members-only events (which do not show up in events feed unless you are a member)

User Achievements System

(Note: This feature really needs a team where at least one member of the team is currently in, or has taken, COMP421: Databases. Computing these statistics in SQL requires more advanced SQL understanding than we are able to teach in COMP423.)

We would like to have an achievements system where users can earn specific awards that incentive broad usage and adoption of the CS Experience Labs’ resources. The design of this feature is open-ended. When a user surpasses some threshold of completing an achievement, they should see some kind of user-interface modal or notification in the web app alerting them to the achievement. From their profile page, they should be able to navigate to achievements and see which they have not yet achieved. The implementation for checking achievements should not unnecessarily complicate any code unrelated to achievements.

Any individual user achievement should have an Entity representation stored in the database for longevity, even if the kind of achievement is time-limited (e.g. attended a spooky Halloween event). There should be a well thought out plan for being able to introduce new kinds of achievements in the future.

Some examples of possible achievements: first check-in to an XL standing desk, first check-in to an XL sitting desk, first office hours ticket for a course, Nth (e.g. 100th) of some meaningful event, added link to GitHub profile, applied to be a UTA, etc. Ideally, achievements could be applied retroactively.

Needs:

• Ability to persist Achievements in the system associated with a User
• Ability to see Achievements earned
• Ability to define new Achievements in an extensible way (requiring production code-base updates OK)
• Clean implementation that does not complicate code unrelated to achievements (e.g. the code for checking in to a reservation should not be aware of achievements). Three possible technical paths to explore: background tasks in FastAPI, decorator functions for routes that may trigger an achievement, custom FastAPI middleware.

Stretch Goals:

• Ability for achievements to be applied retroactively (if this requires a UI and manual action to kick-off from an administrator after deploying a new achievement to production, that is OK)
• Admin page for seeing stats about # of people who have completed each kind of achievement
• Admin page to see who has completed an achievement

Propose a Project

Your team is free to propose a custom project by Wednesday, October 23rd at 11:59pm. To do so, write up the project in a format similar to the above project proposals with a brief description of use, important needs, and stretch goals. Email the project proposal with the subject “COMP423 Project Proposal: TITLE” substituting your title in, CC all members of your group and kris@cs.unc.edu, and include the text of the proposal. Additionally, indicate your top choice if the proposal is not approved. Generally, approval is driven by scope and likelihood of completing needs within a 6-week period to close out the semester.