Skip to content

Project Retrospective

berat-sayin edited this page Apr 16, 2026 · 4 revisions

Use of Standards

This document outlines the specific standards adopted for the project, the rationale for their selection, and the plan for their integration into the system.

1. Schema.org (JSON-LD)

Why we chose it?

Schema.org provides a universally recognized vocabulary for structured data on the web. By using it, we ensure that our core entities—such as User Profiles, News Announcements, and Help Requests—are machine-readable and interoperable with search engines and other third-party services.

How we plan to integrate it?

  • User Profiles: Map the user_profiles and physical_info tables to the Person and MedicalCondition schemas.
  • News: Implement the NewsArticle schema for all announcements.
  • Help Requests: Use the ServiceRequest or AskAction vocabulary to define the nature and status of help requests.
  • Implementation: The backend API will include @context and @type fields in JSON responses where applicable. The web frontend (Next.js) will inject JSON-LD scripts into the <head> of entity-specific pages.

2. GeoJSON (RFC 7946)

Why we chose it?

The project relies heavily on geographic coordinates for help requests and location-based profiles. GeoJSON is the industry standard for encoding geographic data structures in JSON, supported by almost all mapping libraries (e.g., Leaflet, Google Maps) and spatial databases (PostGIS).

How we plan to integrate it?

  • API Responses: Any endpoint returning location data (e.g., /api/help-requests, /api/profiles/location) will format coordinates following the GeoJSON Point structure:
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [longitude, latitude]
      },
      "properties": { ... }
    }
  • Database: Ensure PostGIS queries (if used) or standard SQL queries return data that is easily transformable into this standard.

3. W3C WCAG 2.1 (Level AA)

Why we chose it?

As a platform designed for emergency help and community support, accessibility is not optional. Adhering to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA ensures that users with visual, auditory, motor, or cognitive disabilities can effectively use the service.

How we plan to integrate it?

  • Frontend Development: Use semantic HTML elements, provide sufficient color contrast, and ensure all interactive elements are keyboard-accessible.
  • ARIA: Implement appropriate WAI-ARIA roles and labels for complex UI components in the Next.js and Android applications.
  • Validation: Integrate accessibility auditing tools (like axe-core) into the CI/CD pipeline and conduct manual screen-reader testing.

4. RFC 7519 (JSON Web Token - JWT)

Why we chose it?

JWT is the industry standard for secure, stateless authentication. It allows the backend to verify the user's identity without storing session state on the server, which is essential for scalability and cross-platform (Web/Mobile) compatibility.

How we plan to integrate it?

  • Authentication Flow: Upon successful login, the backend issues a signed JWT.
  • Security: The token is sent in the Authorization: Bearer <token> header for subsequent requests. On the web, it will be stored in an HttpOnly cookie or secure storage; on Android, in EncryptedSharedPreferences.
🎓 Team Members

📄 Templates

📅 Weekly Meetings

🧪 Lab Reports

🎬 Scenarios and Mock-ups

🧩 Use Case Diagrams

🏗️ Class Diagram

🔁 Sequence Diagrams

🛠️ Implementation Plan

📦 Deliverables

MVP Deliverables
Final Milestone Deliverables

📚 Project

✅ Acceptance Tests

🚀 Releases

Clone this wiki locally