Skip to content

Final Milestone Review

Jump to bottom
EgemenKaplan edited this page Dec 29, 2023 · 4 revisions

Prepared by:

Furkan Özçelik

Hasan Baki Küçükçakıroğlu

Bahadır Gezer

Meriç Keskin

Sude Konyalıoğlu

Begüm Yivli

Bahri Alabey

Ömer Faruk Çelik

Enes Yıldız

Egemen Kaplan

Video: Web Info Aggregator - Demo

Executive Summary

BunchUp is a web aggregation application which aims to collaboratively save and organize nodes from the Internet. The application solves the problem of bookmarking that it is scattered and dies away after a while. In our team we focused to ease this process of saving nodes of the Internet and tried to make it fun.

We have implemented annotations to our project by the ability to add extra comments to spot descriptions. This way users can interact better and emphasize the things they want to better.

Our product’s design is made beforehand the implementation, this made the implementation easier and let us see the lacks of our project clearer. The designs were also helped building a easy-to-read organization.

Our project is deployed on an EC2 machine.

Final release notes

Our annotation server uses a different url for its endpoints.

  • In the web application, the host url for annotation requests were hard-coded in the code. Thats why, when we closed our EC2 machine and restarted it before writing the report, annotation endpoints were not working. In order for them to work, you need to find 4 or 5 occurrences of this host url and change the IP part of these urls to the url you will see in the .env file. (Don’t forget the :80/wia suffix)
  • Due to the same underlying reasons, the previous IP address, 18.192.100.93:80, utilized for API calls within the mobile application, needs to be updated to 3.79.231.219:80 across five distinct instances within the mobile code.

Management

One of the most important lessons we have learned was in Milestone 2, we now avoid making changes to our project at the last minute. We renamed Interest Area and Post to Bunch and Spot, which is more original and purposeful, but sometimes we confused the name in our own documentation, so we could have made this change earlier. We changed the mock-up designs in the middle of the semester, there was a risk that we couldn't deliver the functions on time, but we did, so we have a platform that is more aesthetic and provides a better user experience. Apart from that, we have always valued customer feedback and implemented them in the next milestones.

Status of Deliverables

Deliverable Status Notes
Final Project Team Report Delivered / Complete  
Individual Contributions Delivered / Complete  
All design documents Delivered / Complete  
Software release in GitHub Delivered / Complete  
Video Delivered / Complete

 

Requirements Coverage

Requirement ID Name Status Notes
1 Functional Requirements    
1.1 - User Requirements    
1.1.1 - Registration and Login Completed  
1.1.1.1 - Guests shall be able to register... Completed  
1.1.1.2 - Users shall be able to login... Completed  
1.1.2 - Account    
1.1.2.1 - Guests shall verify their account... Completed  
1.1.2.2 - Delete account Completed  
1.1.2.3 - Update account    
1.1.2.3.1 - Change passwords and other account information Completed  
1.1.2.3.2 - Users shall not be able to change their username, email address, and birthday. Completed  
1.1.2.5 - Users shall have control over privacy settings of IAs. Completed  
1.1.3 - User-to-User Interactions    
1.1.3.1 - View other users' profiles... Completed  
1.1.3.2 - Follow other users on the platform. Completed  
1.1.3.3 - Vote on other users based on their profile, behavior, and activity... Completed  
1.1.4 - User-to-Platform Interactions    
1.1.4.1 - Posts    
1.1.4.1.1 - Creating a post in an IA by providing a title, a main link... Completed  
1.1.4.1.2 - Editing fields of their own post. Completed  
1.1.4.1.3 - Commenting on a post. Completed  
1.1.4.1.4 - Down/Upvoting a post. Completed  
1.1.4.1.5 - Reporting inappropriate posts to IA moderators. Completed  
1.1.4.1.6 - Annotating any post in order to give more detailed information about certain parts of these posts. Completed  
1.1.4.1.7 - Suggesting additional tags to posts created by other users. Completed  
1.1.4.2 - Interest Areas    
1.1.4.2.1 - Creating an interest area by providing a title, tags... Completed  
1.1.4.2.2 - Editing fields of interest areas... Completed  
1.1.4.2.3 - Following other IAs. Completed  
1.1.4.2.4 - Joining private IAs. Completed  
1.1.4.2.5 - Creating posts in interest areas... Completed  
1.1.4.2.6 - Suggesting additional tags to IAs created by other users. Completed  
1.1.4.2.7 - Reporting inappropriate IAs to System Administrators. Completed  
1.1.4.2.8 - Managing roles of other users in their own interest areas. Not completed  
1.2 System Requirements    
1.2.1 - Content    
1.2.1.1 - Post    
1.2.1.1.1 - Shall have an IA. Completed  
1.2.1.1.2 - Shall have a title. Completed  
1.2.1.1.3 - Shall have a main body... Completed  
1.2.1.1.4 - Shall contain required relevant metadata... Completed  
1.2.1.1.5 - Shall contain optional relevant metadata... Completed  
1.2.1.1.6 - Shall have comments, upvotes, and downvotes. Completed  
1.2.1.1.7 - Shall specify its purpose by labels. Completed  
1.2.1.2 - Interest Areas (IA)    
1.2.1.2.1 - Shall consist of posts created by their users or posts created within their nested IAs. Completed  
1.2.1.2.2 - Shall be able to consist of a collection of other IAs. Completed  
1.2.1.2.3 - Shall obtain at least one semantic label(tag) during their creation. Completed  
1.2.1.2.4 - Shall have a "Recommended IAs" section... Not completed  
1.2.1.2.5 - Offers various access levels...(public, private, personal) Completed  
1.2.1.3 - Home Page    
1.2.1.3.1 - Displaying recent posts from followed interest areas and users. Completed  
1.2.1.3.2 - Suggesting new posts and interest areas... Not completed  
1.2.1.4 - Annotations    
1.2.1.4.1 - Annotations shall have the W3C Web Annotation Data Model. Completed  
1.2.1.4.2 - Annotations shall appear in form of... Completed  
1.2.1.4.3 - Annotations shall appear in form of a highlight made on the annotated text without displaying any extra content. Completed  
1.2.1.4.4 - Annotations shall only be placed on Post main bodies. Completed  
1.2.2 - Search and Filtering    
1.2.2.1 - The system shall allow users to search for posts, users, and IAs. Completed  
1.2.2.2 - The system shall enable post filtering by interest areas, date, location, and other metadata. Not completed  
1.2.2.3 - The system shall enable the user to sort search results by relevance, date, and popularity. 2/3 Completed sort by relevance is missing
1.2.2.4 - The system shall allow public and private IAs to be searchable. Completed  
1.2.3 - Labeling    
1.2.3.1 - Tags    
1.2.3.1.1 - The system shall utilize Wikidata API for semantic labelig. Completed  
1.2.3.1.2 - Each tag shall each tag shall be able to display more semantically related tags… Not completed  
1.2.3.1.3 - The system shall facilitate post and IA searching by tags Completed However it is not semantic search
1.2.3.1.5 - Tags shall allow users to find interest areas and posts. Completed  
1.2.3.2 - Reputation system    
1.2.3.2.1 - The system shall allow users to vote on other users… Completed  
1.2.3.2.2 - Votes shall represent either positive or negative quality… Completed  
1.2.3.2.3 - The system shall assign badges to users... Completed  
1.2.4 - Reporting and Moderation    
1.2.4.1 - Moderation Dashboard    
1.2.4.1.1 - Removing inappropriate posts from the IA. Not completed  
1.2.4.1.2 - To warn users that create such inappropriate posts... %50 Completed backend completed
1.2.4.1.3 - Banning users from the IA. Not completed  
1.2.4.1.4 - Reporting issues to System Administrators... %50 Completed backend completed
1.2.4.2 - Administration Dashboard    
1.2.4.2.1 - Removing inappropriate posts or IAs from the platform. %50 Completed backend completed
1.2.4.2.2 - Warning users that create such inappropriate posts... %50 Completed backend completed
1.2.4.2.3 - Banning users from the platform. %50 Completed backend completed
1.2.5 - Account Management    
1.2.5.1 - All account information should be deleted when a user's account is deleted. Completed  
1.2.5.2 - All private IAs created by deleted account should be deleted. Completed. We don’t delete private and public interest areas since customer wanted so. We only delete personal interest areas.
1.2.5.3 - Public posts, comments, … of deleted account shall remain visible on the platform. Completed  
1.2.5.4 - The system shall not allow creating more than one account with the same email address. Completed  
1.2.5.5 - The system shall check the birthday of a user during the access to age-restricted content Completed  
2 Non-Functional Requirements    
2.1 - Platforms    
2.1.1 - Application shall be available for Web and Android platforms. Completed It is also available for IOS.
2.1.2 - The web version of the application shall be compatible with common browsers. Completed  
2.1.3 - The Android version of the application shall be compatible with Android 5.0 and higher. Completed  
2.2 - Security    
2.2.1 - User authorization information shall be encrypted. Completed 256 bit encryption
2.2.2 - The application shall implement strong password requirements... Not completed  
2.3 - Privacy and Ethical Considerations    
2.3.1 - The platform shall protect personal information and contact information... Completed  
2.3.2 - The application shall have a concrete "Community Guidelines"... Not completed We have privacy policy but not community guidelines
2.4 - Restricted Content    
2.4.1 - Adult content should have age restrictions. Completed No automatic adult content tagging(it is kinda big tech level) but user can tag content as adult content.
2.4.2 - Application shall not contain criminal content and gore. Completed No automatic mechanism(it is kinda big tech level) but content can be deleted by administrators.

API

API Documentation

Explore our API through the comprehensive documentation available on Postman. You'll find details on endpoints, request and response formats, and example API calls.

Example API Calls

  1. Creates a New Interest Area

    • Endpoint: {{host}}/v1/interest-area
    • Method: POST
    • Required Fields for Request Body:
      • accessLevel: 0 | 1 | 2 (public | private | personal)
      • title: String
      • description: String
      • nestedInterestAreas: Array
      • wikiTags: Array
    • Example Request

  2. Creates a New Post

    • Endpoint: {{host}}/v1/post
    • Method: POST
    • Required Fields for Request Body:
      • interestAreaId: Long
      • sourceLink: String
      • title: String
      • wikiTags: String
      • label: 0 | 1 | 2 | 3 | 4 (documentation | learning | news | research | discussion)
      • content: String
      • isAgeRestricted: Boolean
      • GeoLocation: Object(latitude: Float, longitude: Float, address: String)
    • Example Request

  3. Gets Interest Area's Posts

    • Endpoint: {{host}}/v1/interest-area/:interestAreaId/posts
    • Method: GET
    • Required Parameters:
      • interestAreaId: Long
    • Example Request

    All three requests require a valid JWT token for security. Include the token in the "Authorization" header as a "Bearer" token. Set the {{host}} field to "3.79.231.219/api," the current EC2 instance host URL. If you have Postman installed, run all three example requests by right-clicking the Postman folder examples and selecting "Run Folder."

User Interface / User Experience

Mobile

  • Member

    • Opening Page

    • Authentication Pages

    • Home Page

    • Profile Page

    • New Spot

    • Create Bunch

    • Settings

    • Spot

      • Details

      • Edit

    • Bunch

      • Details

      • Edit

  • Visitor

Web

Opening Page

image

Authentication Modals

image image image

Home Page

image

Profile Page

image image image image
  • Other Users
image
  • Other Users Following Modal
image

Settings Page

image

Search Page

image

Spot Page

image
  • Owner looking at Suggested Tags (same in bunch page as well)
image
  • Other Users
image
  • Other User Suggesting Tags (same in bunch page as well)
image

Spot Create/Edit

image image image

Bunch Page

image
  • Owner looking at follow requests
image
  • Other User
image
  • Other User trying to look at a private bunch without enough access level
image

Create Bunch

image

Edit Bunch

image

Annotations

Frontend

In the frontend side, everyone can annotate spots and see other users' annotations. When annotations are visible users might mess up with annotations, so we require users to hide other annotations first by clicking a button. Then user should highlight the section of text which she wants to highlight, then from the input field on the right hand side of screen she can complete this annotation by providing body. Then user can choose to display other annotations again.

On the right hand side of the screen there is a dropdown to filter annotations by users, we included this because otherwise there might be too many annotations in a popular post. Below that dropdown, there is a search bar, from this bar user can filter by input, this search is done by string matching(considering lowercase-uppercase) search input to target or body of annotation.

We also considered case of conflicting annotations, for example assume there is an annotation on 0-5 range and 0-15 range of a text, we simply merge that range while highlighting and if user hovers over that area, on the right hand side(on sidebar) we display annotations that belong to that merged annotation region.

The annotations are not editable/removable. Users can't annotate images.

Mobile

On the mobile side, everything is more or less the same as the web part.

Annotation Web Server

The server architecture is designed as a standalone system, complete with its own application layer and database, in compliance with the W3C recommendations for web annotations.

Compliance Status

Server Architecture

Our Web Annotation Server is made to operate autonomously, with a dedicated application and database. This design choice aligns with the W3C's guidelines for a robust and self-sufficient annotation ecosystem.

JSON-LD Implementation

Our server exclusively processes requests and responses formatted in JSON-LD (JSON Linked Data). Any request without the proper headers are not processed.

Annotation Containers, Annotations and Requests

The server's implementation of annotation containers, annotations and requests is in line with W3C’s model. The URLs, request bodies, and headers are in line with the standards.

Response Fields

Responses from our sever are structured in the JSON-LD format. All necessary fields are present as required by W3C. Our response format ensures that our annotations provide the necessary information in a structured and understandable manner.

Target Implementation

For the 'target' component of our annotations, we have chosen to only implement the TextualBody type targets. This decision was made to focus our annotations on text-based resources, allowing for ease of development. This restriction did not restrict the potential of the application, since the use of other resources other than text is minimal, and practically does not require the addition of annotations.

Please check the /annotation folder in our Postman API documentation for further investigation and example API calls and responses.

Scenario

Main User: Bahri

Sub User: Begüm

Bahri is planning to go to Italy for his master's education.

  • He enters "Italy" in the search bar and discovers Begüm’s “Traveling Europe Bunch.”
  • He follows the bunch.

A post titled "Toss a coin to your fountain!" spotted by Enes catches Bahri's attention. He comments under it, inquiring about directions to the Trevi Fountain.

  • Bahri suggests some new tags to Begüm for the “Travelling Europe” bunch, adding an “Italy TAG.”

He then creates a new PRIVATE Bunch titled “Masters in Europe,” which includes sub-bunches:

  • Learning Italian
  • Travelling in Europe

Within the "Masters in Europe" bunch, Bahri finds and shares a valuable link:

Bahri annotates "CS" as an abbreviation for "Computer Science."

Begüm checks her “Traveling Europe Bunch” and sees the tag suggestion made by Bahri, which she accepts.

  • She searches for "master" in the search bar and finds Bahri’s “Masters in Europe Bunch.”
  • She sends a follow request, which Bahri accepts.

Begüm then reviews the spots in the “Masters in Europe” bunch:

  • She comments under the spot and
  • Annotates “scholarship” as: "A grant or payment made to support a student's education, awarded on the basis of academic or other achievement."

Use and Maintenance

Project Artifacts

  • Manuals

  • Software Requirements Specification

  • Software Design Documents

  • User Scenarios

  • Mockups (Mobile / Web)

  • Research

    The integration of the W3C Web Annotation Data Model into our platform has brought substantial contributions. The incorporation of annotations has enriched our posts, adding valuable context to the content and enhancing user understanding. Users have contributed by introducing unique descriptions and keyword groups, further enriching the content with different perspectives. This collaboration has led to a dynamic and comprehensive platform experience, reflecting the collective knowledge and insights of our user community.

    Through group research, we determined that using Java Spring on the backend, React with TypeScript on the frontend, and Flutter for mobile development was the most suitable choice for our project. These technologies were selected for their adaptability and effectiveness, as well as our team members' background knowledge.

    We conducted API research to add geolocation to our spots and decided on the Google Maps API. Its ease of use and detailed location information have added another sophisticated feature to our platform. Users can select the relevant location when creating a spot, providing more detailed information to the platform.

    Additionally, we researched and used wiki tags in our platform. Wiki tags help organize content, making it easier for users to find what they're looking for, enhancing the accessibility of relevant content when searched with a keyword.

  • Project Plan

  • Unit Test Reports (Not completed)

Software

Dockerization and Deployment

Build and Deployment Instructions

Pre-requisites

  • Docker
  • Docker-Compose
  • Git

Pre-build

  1. Clone the Repository

    git clone <https://github.com/bounswe/bounswe2023group8.git>

  2. Database Environment Configuration (Required) Navigate to the root directory:

    cd bounswe2023group8/app

    Create a .env.annotation-db file and populate it with the values provided in the annotation-db file, which is located in the 'secrets' folder of the deliverables uploaded to Moodle.

  3. Database Environment Configuration (Required) Navigate to the root directory:

    cd bounswe2023group8/app

    Create a .env.enigma-db file and populate it with the values provided in the enigma-db file, which is located in the 'secrets' folder of the deliverables uploaded to Moodle.

  4. Backend Environment Configuration (Required) Navigate to enigma directory:

    cd bounswe2023group8/app/backend/enigma

    Create a .env file and populate it with the values provided in the enigma-server file, which is located in the 'secrets' folder of the deliverables uploaded to Moodle.

  5. Backend Environment Configuration (Required) Navigate to the annotation directory:

    cd bounswe2023group8/app/backend/annotation

    Create a .env file and populate it with the values provided in the annotation-server file, which is located in the 'secrets' folder of the deliverables uploaded to Moodle.

  6. Frontend Environment Configuration (Required) Navigate to the web directory and modify the .env.development file:

    cd bounswe2023group8/app/web

    Replace IP of the REACT_APP_BACKEND_API_URLwith the IP of the host machine. (localhost if in local environment)

Build steps

  1. Navigate to App Directory

    cd bounswe2023group8/app

  2. Start Services with Docker-Compose

    docker-compose up

If you encounter any issues in determining the correct values, please contact @bakikucukcakiroglu to obtain a valid .env file.

After running the above steps, your application should be up and running. You can send requests to 80 port of the host machine. Make sure to check any logs for potential issues during startup.

Mobile Application Manual

System Requirements:

  • Operating System: Windows (7 SP1 or later), macOS (10.12.0 or later), Linux (64-bit) or Android Device
  • Disk Space: 2.8 GB for Windows, 4.5 GB for macOS, and 2.8 GB for Linux
  • Tools: Android Studio for APK on the emulator, Xcode for iOS version on the simulator

Running APK on your Android Device:

  • Allow Chrome to install unknown apps by going to Settings > Apps > Menu > Special access > Install unknown apps.
  • Install a file manager (such as Cx File Explorer or File Manager) so that you can find the APK file after you download it to your phone.
  • Download the APK file from here and open it to install it. Alternatively, transfer the APK Installer from your computer using USB.

Running App on Computer:

Installation Instructions:

Flutter SDK Installation:

  1. Download Flutter: Visit the Flutter website and download the latest stable release suitable for your operating system.
  2. Extract the Zip File: Extract the downloaded file to a location on your computer.
  3. Add Flutter to PATH (Windows):
    • From the Start search bar, type 'env' and select 'Edit the system environment variables.'
    • Click 'Environment Variables...'
    • Under 'System Variables', select 'Path' and click 'Edit...'
    • Click 'New' and add the path to the 'bin' folder in the Flutter directory.
  4. Run flutter doctor: Open a terminal or command prompt and run flutter doctor to verify the Flutter installation and to identify any missing dependencies.

Running on Emulator/Simulator:

Emulator Setup (Android Studio):

  1. Download Android Studio: Install Android Studio from the official website.
  2. Launch Android Studio and navigate to Tools > AVD Manager.
  3. Create a Virtual Device: Click on + Create Virtual Device, select a device definition, and follow the prompts to create an Android emulator.
  4. Run the Emulator: Start the emulator by clicking on the play button next to the created device in the AVD Manager.

iOS Simulator Setup:

  1. Install Xcode: Download and install Xcode from the Mac App Store.
  2. Open Xcode: Accept the license agreement and install any necessary components.
  3. Open the iOS Simulator: Launch Xcode, then go to Xcode > Open Developer Tool > Simulator.

Set Up the Development Environment

Choose an IDE: Select an Integrated Development Environment (IDE) such as Visual Studio Code (VS Code), Android Studio, Xcode, etc. Download and install the IDE of your choice.

Integrate with Flutter: If you're using VS Code, install the Flutter and Dart extensions to make your IDE Flutter-ready.

Clone the Project

Open a Terminal or Command Prompt.

Get the Clone URL: Get the clone URL for the project repository from a source like GitHub.

Navigate to a Desired Folder: Navigate to the directory where you want to store the project on your computer.

Clone the Project: Use the following command to clone the project:

git clone https://github.com/bounswe/bounswe2023group8.git

Step 4: Install Dependencies

Move to the Project Directory: Use the Terminal or Command Prompt to navigate to the project's root directory.

Install Dependencies: Run the following command to install the project's dependencies:

flutter pub get

Usage:

  • Once your simulator/emulator is ready: In the terminal, navigate to your Flutter project directory /mobile and execute flutter run to launch the app
  • Once the application is installed on the emulator/device, interact with it as you would with any other mobile application.
  • Use the emulator/simulator controls to simulate touch, gestures, and other interactions as needed for testing the application.

Remember, Flutter offers a rich set of documentation and resources that can further assist with troubleshooting.

During the development process, our team rigorously tested our application on a range of devices to ensure its compatibility and performance. At the same time we verified and validated the user and system manuals.

The devices used for testing include:

  • MacBook Air M1
  • 2 x MacBook Pro M1
  • HP Spectre
  • iPhone X
  • iPhone XS
  • iPhone 14
  • iPhone 15
  • Oppo Reno 2Z
  • Google Pixel 4a

Real Database Data (The data for at least 100 realistic posts)

Exported real database data is uploaded to drive. [Go to drive.](https://drive.google.com/drive/folders/1LsgyaHMSg42Pe6fd1U-l8Fj35JXGEoTj?usp=sharing)

Individual Report

Home | Milestone 1 Report | Milestone 2 Report | Requirements | Mockups | Use Case Diagrams | Class Diagrams | Sequence Diagrams

bounswe2023group8

🏠 Home

🗄️ Project
Milestones
👤 Individual Contribution Reports
Milestone 1
Milestone 2
Final Milestone
🖇️ Lab Reports
📑 Templates
👥 Team Members
CmpE 352
Old Project Files
📅 Meetings
🔬 Researches
👤 Individual Contribution Reports
Clone this wiki locally