1. Business Questions

The following Business Questions (BQs) define the information and knowledge that can be obtained from ParchApp's data through an analytics engine.

ID	Type	Business Question	Justification
BQ1	Type 1. App Telemetry	What is the average response time of the availability engine when calculating common time slots for groups of different sizes?	The availability engine is one of ParchApp's core technical components. Measuring its response time helps detect performance problems and determine whether larger groups significantly affect calculation time.
BQ2	Type 1. App Telemetry	What percentage of activity creation requests fail or time out when users submit a new activity?	The prototype includes a complete activity creation flow. Monitoring failed or delayed submissions allows the development team to identify reliability problems that could prevent users from successfully creating plans.
BQ3	Type 2. Direct User Experience Improvement	What percentage of the time slots suggested by the recommendation engine are accepted by the organizer without being changed?	Understanding which recommendations users accept allows ParchApp to improve future suggestions and present alternatives that are better aligned with the actual behavior of groups.
BQ4	Type 2. Direct User Experience Improvement	How often are activity invitations accepted when one or more participants are marked as busy during the proposed time slot?	The prototype distinguishes between available and busy users. This information helps determine whether a busy calendar block should always be treated as a strict restriction or whether some users still accept activities during those periods.
BQ5	Type 2. Direct User Experience Improvement	How does the average time required for all participants to respond to an activity invitation vary by group size?	Groups of different sizes may require different amounts of time to reach a decision. This information can help ParchApp adapt how pending responses and expected coordination times are presented to organizers.
BQ6	Type 2. Direct User Experience Improvement	At what time after an invitation is sent are pending participants most likely to respond to a reminder?	This information can improve reminder timing so that users receive notifications when they are most likely to respond, reducing unnecessary notifications while helping groups reach decisions faster.
BQ7	Type 3. Feature Analysis	At which step do most users abandon the activity creation process: group selection, category selection, date and time selection, location, activity details, or review?	The prototype contains several inputs during activity creation. Identifying where users abandon the process can reveal unnecessary complexity and indicate which parts of the creation flow should be simplified or redesigned.
BQ8	Type 3. Feature Analysis	Which core coordination functionalities are used least frequently during the process of organizing an activity?	Comparing the use of features such as Groups, Compare Availability, Schedule, Invitations, and Alerts helps determine which functionalities provide value and which may need to be redesigned, made more visible, or removed.
BQ9	Type 3. feature Analysis	How often is the Compare Availability feature used before creating an activity, and how does its use affect the percentage of activities that reach Confirmed status?	Compare Availability is one of the central features represented in the prototype. This question evaluates whether users actually use it and whether activities supported by availability comparison are more likely to reach confirmation.
BQ10	Type 3. Feature Analysis	Which activity categories, study, sports, social, or other, are selected most and least frequently, and what percentage of activities in each category reach Confirmed status?	The activity-creation prototype includes a category selector. Analyzing its usage can help determine whether the current categories are useful, whether some should be prioritized, and whether new categories should be introduced.
BQ11	Type 4. Benefits from Data	Which time periods and campus areas concentrate the highest number of confirmed student activities?	Aggregated and anonymized activity patterns could provide useful information to universities, student organizations, and nearby businesses when deciding when and where to provide activities, services, or promotions.
BQ12	Type 4. Benefits from Data	Which combinations of activity category, group size, and time period concentrate the highest number of confirmed activities?	Aggregated demand patterns could help restaurants, activity providers, student organizations, and other partners understand what types of plans student groups organize, when they organize them, and the typical size of those groups.
BQ13	Type 5. Multiple Purposes	Which recommended time slots achieve the highest confirmation rate, and how can these patterns be used to improve future time recommendations for similar groups?	This question combines direct user experience improvement and feature analysis. Better historical knowledge can improve future recommendations while also measuring the effectiveness of the recommendation engine.
BQ14	Type 5. Multiple Purposes	Which reminder strategy leads groups to confirm activities faster while requiring the fewest notifications, and how does this vary by group size?	This question combines direct user experience improvement and feature analysis. It helps ParchApp identify reminder strategies that reduce the time needed to confirm an activity while avoiding unnecessary notifications. The result can improve the user experience by making reminders less intrusive and can also help the development team evaluate and refine the notification feature according to group size.

---

2. Implemented Business Questions

ID	Implemented by	Type	Business Question	Rationale
BQ1	Juan David Guzmán Casadiego	Type 1. App Telemetry	What is the average response time of the availability engine when calculating common time slots for groups of different sizes?	The availability engine is the core of ParchApp. Measuring its latency by group size shows whether large groups slow down the experience. It is Type 1 because it measures a technical resource, it uses internal telemetry and the answer is not shown to the user.
BQ3	Tatiana Perez Suancha	Type 2. Direct User Experience Improvement	What percentage of the time slots suggested by the recommendation engine are accepted by the organizer without being changed?	Knowing which suggestions organisers accept helps the app show better options. It is Type 2 because it is based on the user's own interactions and the answer returns to the user: the slot position that groups usually accept is marked as Recommended, feature F2.
BQ3	Gabriel Enrique Rodríguez Pinto	Type 2. Direct User Experience Improvement	What percentage of the time slots suggested by the recommendation engine are accepted by the organizer without being changed?	It measures how often users accept recommended slots unchanged, helping improve future suggestions based on their interactions.
BQ4	Gabriel Polania	Type 2. Direct User Experience Improvement	How often are activity invitations accepted when one or more participants are marked as busy during the proposed time slot?	ParchApp combines manually created availability with free/busy information imported from external calendars. Measuring whether users accept invitations that overlap with busy periods helps determine whether a busy block should always be treated as a strict restriction or as a soft conflict. It is Type 2 because the information comes from users' availability and invitation responses, and its result can directly improve the time-slot recommendations shown in Schedule.
BQ5	Jhon Vega	Type 2. Direct User Experience Improvement	How does the average time required for all participants to respond to an activity invitation vary by group size?	Groups of different sizes need different amounts of time to reach a decision. The Flutter app logs rsvp_submitted every time a member answers, and a nightly Cloud Function turns those events into the expected time until everyone replies for each group size. It is Type 2 because it comes from the users' own answers and the result goes back to them: the Active Groups roster card shows organisers how long groups like theirs usually take and warns them when replies are taking longer than usual.
BQ8	David Alfonso Pérez Rojas	Type 3. Feature Analysis	Which core coordination functionalities are used least frequently during the process of organizing an activity?	Comparing how often Groups, Compare Availability, Schedule, Invitations and Alerts are opened shows which features give value and which need a redesign. It is Type 3 because it measures features that are not used over time and the answer affects adding, removing or updating them. It is not shown to the user.
BQ13	Gabriel Enrique Rodríguez Pinto	Type 5. Multiple Purposes	Which recommended time slots achieve the highest confirmation rate, and how can these patterns be used to improve future time recommendations for similar groups?	It evaluates which recommended slots are most often confirmed and uses those results to improve future suggestions. It is Type 5 because it combines feature analysis with direct user experience improvement.

---

3. Analytics Pipeline

1. Data source. Every event goes through one class, AnalyticsTracker. The views never call Firebase directly, so event names and parameters stay the same across the app. Business data, such as groups and activities, is written to Firestore.

2. Ingestion. Events wait in a local queue and are sent in batches when the phone is online. This protects the data when a student loses signal, for example inside TransMilenio, and it saves battery.

3. Storage. Telemetry events live in Firebase Analytics and business data lives in Cloud Firestore. Both are exported every day to BigQuery, so analytical data is separated from the data the app uses to work.

4. Processing. One scheduled SQL query per Business Question aggregates the raw events. No heavy calculation runs on the phone.

5. Presentation. BQ1, BQ4, BQ8 are shown in r Studio dashboard for the team. BQ3 is written back to a Firestore document that the app reads, so the answer changes what the user sees. This is the Type 2 feedback loop.

Privacy. No event includes calendar titles, places or attendees. Only free and busy blocks, group sizes and timestamps are logged, and user IDs are anonymised before the export. This follows the privacy decisions made since MS3.

1. Data source. Google Calendar is the external data source for imported availability.

2. Ingestion. ParchApp connects to Google Calendar through the calendar integration layer. Calendar events are read and passed through a mapper that converts the external calendar format into ParchApp availability blocks.

3. Storage. The normalized availability blocks are stored in Cloud Firestore together with the user's manually created availability. Each block keeps only the information required by ParchApp, such as the start time, end time, availability status and source. This allows imported and manually created availability to be handled through the same backend.

4. Processing. The scheduling logic uses normalized blocks to calculate common availability and evaluate possible time slots without depending directly on Google Calendar.

5. Presentation. The resulting availability is shown in the Schedule view as busy or available periods.

BQ5 feedback loop (Flutter), by Jhon Vega

1. Data source. When a member answers Going on an Active Groups card, the use case logs rsvp_submitted with activity_id, group_size, response_ms and response. response_ms is the time since the latest activity of the group was created, which is the invitation.

2. Ingestion. Events go through the AnalyticsService facade, so the use case never calls Firebase directly. Firebase Analytics batches them and keeps them while the phone is offline.

3. Storage. Firebase Analytics exports the events every day to BigQuery. The user ID is a SHA-256 hash, the same format as the Android app.

4. Processing. bq5_response_time.sql keeps the first answer of each person per invitation. An invitation is complete when as many people answered as the group has members, and its time is the last answer. The query groups the results by group size. The Cloud Function refreshResponseTimeInsight runs it every night and chooses one estimate per size: the time until everyone replied when there are at least 3 complete invitations, otherwise the time of one answer when there are at least 5 answers. A second function, resetRsvpOnNewActivity, clears the RSVPs when a new activity is created, so every invitation starts with no answers.

5. Presentation. The function writes insights/bq5_response_time in Firestore. The Flutter app reads it and shows the estimate under the RSVP progress bar of the closest group size. If the document is missing or there is not enough data, the card shows nothing.

Rationale. The phone only logs one small event per answer. The heavy aggregation runs in BigQuery once a day, and the app reads a single small document, which saves battery and data. Writing the result back to Firestore closes the Type 2 loop: the answer to BQ5 changes what the organiser sees.

3. Architecture Design

Architectural Style — Client-Server

ParchApp follows a Client-Server architectural style because the application is composed of multiple mobile clients that need to access and modify shared information through centralized cloud services.

ParchApp provide the user interface and handle user interactions, while shared services such as Firebase Authentication, cloud Firestore, Firebase Analytics, and BigQuery provide the server-side capabilities required by the system. External services, such as Google Calendar and Google Maps, are also consumed through integration components.

This architectural style is appropriate for ParchApp because the application is multi-user and both mobile platforms need to work with the same users, groups, activities, invitations, availability information, and analytics data. Instead of each mobile client maintaining an independent version of the system state, the shared backend acts as the common source of information.

Architecture design

MVC architecture

The General MVC architecture, adapted to Android, is ideal for ParchApp because it separates the data, the interaction logic and the presentation. XML layouts are the View, Activities and bottom sheets are the Controller, and entities, domain services and repositories form the Model.

This structure lets the three members of the Android team work in parallel on different screens without breaking each other. It also gives each design pattern a clear place in the code, which improves scalability and maintainability.

• The user taps a control in a View, for example Compare Availability.
• The View only sends the event to the Controller. It has no business logic.
• The Controller updates or queries the Model through a repository or a domain service.
• The Model answers with a callback, and the Controller updates the View.

At system level the app follows a client-server style. The Android app is the client, and Firebase and Google Maps work as the server side.

MVVM architecture

The Flutter development team decided to organize ParchApp using the Model-View-ViewModel (MVVM) architectural pattern. Flutter has declarative and reactive approach to user interfaces that makes this pattern a natural fit. In Flutter, the interface is rebuilt when its state changes, and mechanisms such as ValueNotifier, ChangeNotifier, Streams, and similar state-listening tools allow the View to react to changes without containing the business logic that produced them. This matches the MVVM principle in which the View observes the state exposed by the ViewModel.

Using MVVM allows the Flutter team to keep the UI separated from presentation and business logic. The View is responsible for rendering widgets and capturing user actions, while the ViewModel manages the state required by the screen and coordinates the operations that must be performed. This separation is especially useful for ParchApp because the application depends on several data sources and external services.

Finally, MVVM improves modifiability, testability, and parallel development. Presentation logic can be tested independently from the widgets, backend implementations can be replaced behind repository abstractions, and different team members can work on views, ViewModels, domain logic, and integrations with fewer dependencies between their changes.

Design patterns

Repository pattern for data access

![Repository pattern] (https://github.com/CONSTR-APLICACIONES-MOVILES/Sprint-2-Java/blob/main/img/Repositorypattern.png)

The Repository pattern for data access, implemented in Java by Juan David Guzmán Casadiego, gives each entity one access point. Controllers never know if the data comes from the local cache or from Firestore, so if we change the backend, only the repositories change.

• DashboardActivity and GroupDetailActivity depend on the GroupRepository interface, never on Firestore.
• FirestoreGroupRepository implements the interface and reads the local cache first, then the server.
• Every result returns through a Callback, so the UI thread never waits for the network.
• ActivityRepository and AuthRepository follow the same structure.

Strategy pattern for slot ranking

The Strategy pattern for slot ranking, implemented in Java by Juan David Guzmán Casadiego, lets AvailabilityEngine rank common time slots with different criteria without changing its code. The engine depends on the SlotRanker interface, and each ranking is a separate class.

• CompareAvailabilitySheet chooses a ranking and passes it to the engine with setRanker().
• The engine intersects the free and busy blocks of all members.
• The engine delegates the order to ranker.rank() without knowing which ranking it is.
• A new ranking, for example one based on the BQ3 results, only needs a new class.

Each member implemented one ranking. OverlapRanking by Juan David orders slots by the number of available members. PreferenceRanking by Tatiana uses each member's preferred hours. SoonestRanking by David Alfonso breaks ties by the earliest start.

Observer pattern

The Observer pattern for real-time group updates, implemented in Java by Tatiana Pérez Suancha, keeps the screens synchronised with Firestore. When someone confirms a plan, every open screen updates at once, without asking the server again and again. The backend is decoupled from the UI, which improves modularity and keeps the experience responsive.

• GroupDetailActivity, DashboardActivity and CreateGroupActivity implement the GroupListener interface.
• Each screen subscribes with observeGroup() when it opens.
• When the group document changes in Firestore, GroupRepository receives the snapshot and calls notifyListeners().
• Each screen updates its own part: the RSVP bar, the groups card or the pending invitations. Screens unsubscribe in onStop() to avoid memory leaks.

The same idea is used by QuickStatusSheet.Listener, which sends the new availability status back to the Dashboard.

Singleton and Facade patterns for analytics

The Singleton and Facade patterns for analytics, implemented in Java by David Alfonso Pérez Rojas, are combined in AnalyticsTracker. As a Singleton, it guarantees one shared instance, so every event in the app uses the same format. As a Facade, it offers one simple method and hides the event queue, the connection check and Firebase.

• Every screen calls AnalyticsTracker.getInstance(), so the whole app shares one instance.
• Screens only know one method: track(name, params).
• The tracker adds the event to EventQueue and asks ConnectivityMonitor if the phone is online.
• When there is a connection, the queue is sent in one batch to FirebaseAnalytics, which saves battery.

Adapter Pattern — Google Calendar Integration

Adapter design pattern is implemented by Gabriel Polania and it is used to integrate Google Calendar with ParchApp's availability model.

Google Calendar exposes calendar information using its own data structures and fields. However, the scheduling functionality in ParchApp should not depend directly on the Google Calendar representation. Schedule only needs a normalized representation of a user's availability, such as the start time, end time, availability status, and source of each block.

For this reason, a GoogleCalendarAdapter is placed between the external calendar service and the ParchApp domain model. The adapter receives the calendar information returned by Google Calendar and transforms it into the internal AvailabilityBlock representation used by ParchApp.

Repository pattern in Flutter, BQ5 insights and camera

The Repository pattern in Flutter, implemented by Jhon Vega, keeps the domain and the ViewModels independent from Firestore and from the camera plugin. Each repository is an interface in the domain layer, and the implementations live in the data layer.

• ResponseTimeInsightsRepository has two implementations: FirestoreResponseTimeInsightsRepository reads insights/bq5_response_time, and MockResponseTimeInsightsRepository gives demo values and is used in tests.
• ProfilePhotoRepository is implemented by DeviceProfilePhotoRepository, which opens the front or rear camera with image_picker and copies the photo to the app folder with path_provider.
• The use cases EstimateResponseTime and ChangeProfilePhoto only depend on the interfaces, and the implementations are chosen in app/dependency_injection/.

Rationale. The insight comes from a nightly job and can be missing, and the camera depends on permissions and on the device. Hiding both behind interfaces lets the ViewModels be tested with fakes, lets the app run with demo data, and means that changing the data source only changes one class.

3.6 Integrated architecture

The integrated architecture gives a complete view of how all the design patterns fit inside the MVC framework. The MVC framework includes the data access layer, coordinates the real-time updates, uses the slot ranking and tracks events through the analytics module.

Controllers never call Firebase, Google Maps or the sensors directly. This keeps responsibilities separated, makes each subsystem easy to replace, and shows how the patterns collaborate in the main flows of the app.

Each member contributed to one part of the architecture:

Architectural pattern	Layer	Member	What they built
MVC adapted to Android	Presentation	Tatiana Pérez Suancha	Controllers of Group Details and Create Group connected to the domain and data layers
Layered architecture	Domain	David Alfonso Pérez Rojas	StatusService and the domain models used by the engine
Layered architecture	Data	Juan David Guzmán Casadiego	Repositories and the Firestore offline cache
MVVM with layered architecture	Domain and Data	Jhon Vega	Domain entities and use cases for BQ5 and the profile photo, Firestore and device repositories, and the Profile and Active Groups ViewModels

3.7 Sequence diagram for comparing availability and creating an activity

The sequence diagram for comparing availability and creating an activity shows the main flow of ParchApp. It shows how the Repository, Strategy and Singleton patterns work together, from the moment the organiser selects a group until the Activity Created screen appears.

The slot calculation runs on a background thread with ExecutorService, so the interface never freezes. The BQ1 and BQ3 events are logged at the exact moment the time is measured or the slot is chosen, which keeps the analytics data accurate.

3.8 Sequence diagram for sign in

The sequence diagram for sign in shows how MainActivity authenticates the user through AuthRepository and Firebase Authentication. The app never stores passwords.

Firebase keeps the token and restores the session on the next launch, so returning users skip the form and see the Continue as card designed in MS6.

3.9 Architectural tactics

Each tactic answers one of the quality scenarios defined in Sprint 1.

Tactic	Quality attribute	Sprint 1 scenario	Where in the code	Responsible
Background execution	Performance	9.1 and 9.12	ExecutorService for slot calculation and I/O	Juan David Guzmán Casadiego
Authenticate actors	Security	9.11	Firebase Authentication before any data access	Juan David Guzmán Casadiego
Maintain a local copy of data	Availability	9.2	Firestore offline persistence and the local event queue	Tatiana Pérez Suancha
Timeout and fallback	Availability, graceful degradation	9.9	Distance Matrix client with an 8 second timeout and a fallback message	Tatiana Pérez Suancha
Batching and adaptive sensor sampling	Energy efficiency	9.4	AnalyticsTracker and StatusService	David Alfonso Pérez Rojas
Restrict access to sensitive calendar data	Confidentiality, privacy by design	9.5	ScheduleRepositoryImpl.getFriendsBusyBlocks() only creates friendBusy blocks with start, end, and ownerId, without persisting title, subtitle, or location. ScheduleView._buildFriendBusyBlock() renders only the friend identity/busy state, while _buildPersonalBlock() can render full event details for the owner.	Gabriel Polania
Atomic transaction	Data consistency, correctness under concurrency	9.7	Activity scheduling saves the selected time slot and recommendation outcome in a single backend transaction, preventing partial or duplicated updates.	Gabriel Pinto
Graceful degradation	Availability	9.9	FirestoreResponseTimeInsightsRepository returns no estimate when the insight can't be read, and FirebaseAnalyticsService never lets a failed event break the screen	Jhon Vega

4. Implemented Features

Java team

Every member contributed to one functionality of each required item, as the table of each feature shows.

#	Required item	Feature	Responsible
F1	a. Uses a sensor	Automatic Commuting status	David Alfonso Pérez Rojas
F2	b. Answers a Type 2 BQ	Recommended slot, BQ3	Tatiana Pérez Suancha
F3	c. Context-aware	Context-aware plan card	Tatiana Pérez Suancha
F4	d. Smart feature	Best-slot recommender	Juan David Guzmán Casadiego
F5	e. Authentication	Sign in with Firebase Auth	Juan David Guzmán Casadiego
F6	f. External service, backend	Groups, activities and RSVPs in Firestore	Tatiana Pérez Suancha
F7	f. External service	Travel time from Google Maps	David Alfonso Pérez Rojas

F1. Automatic Commuting status

The accelerometer detects sustained movement and the GPS detects that the user left the campus area. When both agree, the app suggests changing the status to Commuting / In transit.

Member	Contribution
David Alfonso Pérez Rojas	StatusService with accelerometer sampling and the suggestion in Set Availability Status
Tatiana Pérez Suancha	Campus area check with the Fused Location Provider and the runtime location permission
Juan David Guzmán Casadiego	Live status card in the Dashboard that updates when the suggestion is accepted

F2. Recommended slot, BQ3

The Compare Availability sheet marks as Recommended the slot position that organisers accept without changes most often. The value comes from the BQ3 result in config/analytics.

Member	Contribution
Tatiana Pérez Suancha	slot_selected event and the BQ3 query that writes suggested_slot_acceptance
Juan David Guzmán Casadiego	Recommended badge in CompareAvailabilitySheet that reads the config document
David Alfonso Pérez Rojas	was_modified flag saved when the activity is confirmed in Activity Created

F3. Context-aware plan card

The plan card uses the current location, the current time and the connection state. It shows the travel time to the venue, warns "You won't make it on time" when the plan starts before the user can arrive, and shows an offline banner without connection.

Member	Contribution
Tatiana Pérez Suancha	Plan card in Group Details with the travel time and the late warning
Juan David Guzmán Casadiego	Same card in the Today's Plans section of the Dashboard
David Alfonso Pérez Rojas	ConnectivityMonitor that shows the offline banner

F4. Best-slot recommender

The availability engine intersects the free and busy blocks of all members for the chosen duration. Then it ranks the slots and shows the best ones first.

Member	Contribution
Juan David Guzmán Casadiego	AvailabilityEngine and OverlapRanking, by number of available members
Tatiana Pérez Suancha	PreferenceRanking, by each member's preferred hours
David Alfonso Pérez Rojas	SoonestRanking, which breaks ties by the earliest start

F5. Sign in with Firebase Auth

Users sign in with email and password or with Google Sign-In. The session is kept between launches.

Member	Contribution
Juan David Guzmán Casadiego	Sign In view connected to AuthRepository, email and password, and Google Sign-In
Tatiana Pérez Suancha	Continue as card that restores the session with getCurrentUser()
David Alfonso Pérez Rojas	Log out, which clears UserSession and returns to Sign In

F6. Groups, activities and RSVPs in Firestore

Groups, invitations and responses are read from and written to Cloud Firestore. This functionality is connected to the backend and is different from authentication.

Member	Contribution
Tatiana Pérez Suancha	Create Group writes the group and its invitations, and Group Details listens in real time
Juan David Guzmán Casadiego	Dashboard reads the groups and today's plans
David Alfonso Pérez Rojas	Activity Created reads and writes the activity and its reminder setting

F7. Travel time from Google Maps

The Distance Matrix API gives the travel time used by F3. If the API does not answer in 8 seconds, the card shows a fallback message and the user can still continue.

Member	Contribution
David Alfonso Pérez Rojas	DistanceMatrixClient with the timeout and fallback
Tatiana Pérez Suancha	Travel time shown in the Group Details plan card
Juan David Guzmán Casadiego	Travel time cached per activity in ActivityRepository

Flutter team

Each member is responsible for two of the required items, as the table shows.

#	Required item	Feature	Responsible
F1	a. Uses a sensor	Profile photo with the front or rear camera	Jhon Vega
F2	b. Answers a Type 2 BQ	Expected reply time on the Active Groups roster card, BQ5	Jhon Vega
F3	c. Context-aware	Context-aware activity time recommendations	Gabriel Pinto
F4	d. Smart feature	Best-slot recommender for Activity Details	Gabriel Pinto
F5	e. Authentication	Google Auth	Gabriel Polania
F6	f. External service	slots from Google calendar	Gabriel Polania

F1. Profile photo with the front or rear camera:

In Edit profile, the user chooses Take a selfie or Rear camera. The app opens the phone camera, saves the photo in the app folder and shows it in the profile avatar. If the user closes the camera, the current photo stays. If the camera permission is denied, the profile shows an error.

F2. Expected reply time on the Active Groups roster card, BQ5:

The roster card shows how long groups of a similar size usually take until everyone replies, and warns when replies are taking longer than usual. The value comes from insights/bq5_response_time in Firestore, written by the BQ5 nightly job, so this feature is also connected to the backend.

F3. Context-aware activity time recommendations:

The Activity Details flow generates recommended time slots using participant busy periods, preferred hours, requested duration, current server time, and the current day. The feature adapts its suggestions to the current activity and group context.

F4. Best-slot recommender:

The recommendation engine filters infeasible time slots and ranks the remaining alternatives using ContextAwareSlotRankingStrategy. It considers how well each slot matches participant preferences and presents the best options first.

---

5. Implemented Views

Each member implemented two views in Java with the Android SDK, AppCompat and Material Components. The UI keeps the visual identity defined in MS6: primary blue #003D9B, a clean sans-serif typeface and custom vector icons.

View	Responsible	Navigation pattern
Sign In	Juan David Guzmán Casadiego	Root entry point, forward-only navigation into the Dashboard
Home Dashboard	Juan David Guzmán Casadiego	Hub with persistent bottom navigation and modal bottom sheets
Group Details	Tatiana Pérez Suancha	Pushed onto the back stack from the Dashboard, reuses its bottom sheets
Create Group	Tatiana Pérez Suancha	Linear, wizard-style forward navigation with a Cancel path
Activity Created & Confirmed	David Alfonso Pérez Rojas	Terminal screen that exits to Schedule or back to Home with finishAffinity()
Set Availability Status	David Alfonso Pérez Rojas	Modal BottomSheetDialogFragment with no back stack entry
Schedule	Gabriel Polania	Bottom Navigation / Tab Navigation
Activity Details	Gabriel Enrique Rodríguez Pinto	Detail screen accessed from Schedule, with persistent bottom navigation and a modal bottom sheet for editing
Profile	Jhon Vega	Bottom navigation tab with modal bottom sheets
Active Groups	Jhon Vega	Pushed from Home and Profile, with filter chips and back action

5.1 Sign In

Implemented by: Juan David Guzmán Casadiego

The Sign In view is the entry point of ParchApp. It shows the brand emblem, a Continue as card for returning users, the Google option and the email and password form. In Sprint 2 it is connected to Firebase Auth, F5, and it shows inline errors and a loading state.

UI/UX concepts applied:

• Visual hierarchy between the quick Continue as path and the manual form.
• Primary and secondary call-to-action.
• Google sign-in placed above the form to reduce friction.
• Inline validation and error feedback.

5.2 Home Dashboard

Implemented by: Juan David Guzmán Casadiego

This is the central hub. The greeting, invite card, live status card, today's plans and active groups scroll under a fixed header, the FAB and the bottom navigation. Secondary tasks open as bottom sheets, so the user never loses context.

In Sprint 2 the plans and groups come from Firestore, F6, and the status card reflects F1.

UI/UX concepts applied:

• Information hierarchy across cards.
• Progressive disclosure through bottom sheets.
• Live status indicators.
• A FAB for the main creation action.
• Persistent bottom navigation.

5.3 Group Details

Implemented by: Tatiana Pérez Suancha

This view shows the shared context of a group:

• a banner with the synchronisation status,
• the next group plan with its RSVP progress bar,
• the live roster,
• quick coordination actions,
• a recent activity log.

It reuses the Dashboard bottom sheets. In Sprint 2 it listens to Firestore in real time, F6, and shows the context-aware plan card, F3.

UI/UX concepts applied:

• Social presence indicators.
• RSVP progress visualisation.
• Component reuse across screens.
• Role signalling with the LEADER badge.
• Chronological activity feed.

5.4 Create Group

Implemented by: Tatiana Pérez Suancha

This full-screen form includes:

• group name, date and time,
• three invitation methods: link, QR code and email chips,
• a list of pending invitations.

The link is copied with the Android clipboard API, and the QR block can be hidden to keep the form short. In Sprint 2 the group is saved in Firestore, F6.

UI/UX concepts applied:

• Structured form with required fields marked.
• Progressive disclosure of the QR code.
• Several invitation methods.
• Dynamic chips for invitees.
• Clear action hierarchy.

5.5 Activity Created & Confirmed

Implemented by: David Alfonso Pérez Rojas

This confirmation screen:

• summarises the activity that was created,
• lists the invited friends with their RSVP state,
• offers calendar sync with SwitchCompat and the reminder setting,
• ends with two exits: View in Schedule or Back to Home.

In Sprint 2 it saves the was_modified flag used by BQ3.

UI/UX concepts applied:

• Success feedback pattern.
• Recap card that closes the loop.
• Social proof with status pills per person.
• Fast sharing actions.
• Clear final actions.

5.6 Set Availability Status

Implemented by: David Alfonso Pérez Rojas

This modal bottom sheet has:

• five exclusive states: Available now, In Class, Deep Focus, Busy/Personal and Commuting,
• a duration chip group,
• an auto-sync toggle.

In Sprint 2 the Commuting state can be suggested automatically by the sensor feature, F1.

UI/UX concepts applied:

• Single-selection list with a clear selected state.
• Icon-coded categories.
• Chip-based duration selection.
• An automation toggle.
• Toast feedback on save.

5.7 Schedule

Implemented by: Gabriel Polania

The Schedule feature allows users to:

• Navigate through different days and weeks.
• Select the expected duration of a plan.
• Import events from Google Calendar.
• Visualize personal calendar events directly in the schedule.
• Compare their availability with selected friends.
• Identify common available time slots for creating plans.

UI/UX Concepts Applied

• Timeline-based visualization of daily availability.
• Date and week navigation.
• Chip-based meeting duration selection.
• Friend selection for availability comparison.
• Clear visual distinction between personal events, friends' busy periods, and common available slots.
• Manual Google Calendar import, giving users control over when their calendar is synchronized.
• Privacy-by-design, keeping full calendar information private while exposing only busy/free availability to other users.

5.8 Activity Details

Implemented by: Gabriel Pinto

The Activity Details view presents the complete information of a selected activity and provides access to its scheduling and editing actions.

The main screen shows:

• the number of participants,
• category, activity name and description,
• scheduled date and time,
• location,
• recommended time slots based on the group's availability and preferences,
• an action to modify the activity.

UI/UX Concepts Applied

• Information hierarchy through separated content cards.
• Persistent bottom navigation.
• Modal bottom sheet for contextual editing.
• Clear primary actions for finding times and modifying the session.
• Progressive disclosure: editing options appear only when requested.
• Loading, success and error feedback during backend operations.
• Recommended alternatives that preserve user choice instead of automatically selecting a time.

5.9 Profile

Implemented by: Jhon Vega

Shows the identity card with avatar and status, the academic card, statistics and links to Edit Availability and My Groups. Edit profile opens a bottom sheet with the fields and the two camera options, F1.

UI/UX concepts applied:

• Identity first: avatar, name and status at the top.
• Progressive disclosure with bottom sheets.
• Inline validation on Save.
• Snackbar feedback and a destructive Log Out button.

5.10 Active Groups

Implemented by: Jhon Vega

Lists the user's groups with filter chips by category. Roster cards show RSVP progress and the BQ5 expected reply time, F2.

UI/UX concepts applied:

• Filter chips with counters.
• RSVP progress with expected coordination time.
• Color-coded status per group.
• Loading, empty and error states with retry.

---

Ethics Video Reflection

https://youtu.be/yTLTN7v-tO8