PlayDate - A Social-Media Platform for Parents

1. Overview

1.1. purpose, goals & motivation behind the project

During the summer of '22, my software development class was divided randomly into teams of six and asked to create a web application within the timespan of 4 months. The entire project was divided into 6 milestones and for each milestone the professor/CTO would declare the title of 'Best Milestone'; subsequently, the team with the final best project would win the "Best Project Award".

Our team decided to create a social media application that was catered towards parents who wanted a more secure and inclusive way of arranging playdates for their children. Because our team consisted mainly of members who were parents themselves, we had a general idea of the issues our competitors(i.e. facebook) did not address. The existing social media paradigm consisted of loosely-moderated groups or unauthentic verified accounts- and specifically these were the things that we wanted to address so that we can narrow our scope to parents as opposed to the general public.

1.2. Features

We ultimately decided to create a standard community-based social media platform where users could share, post, and arrange meetings- all under a secure veil that was focused on protecting the data and integrity of our users, and in the end these were some of the main features we decided our application should have:

Multiple Layers of Verification: staff-based and moderator-based verification
Consolidating public events from different sources and creating a way for our website to interact with existing event-based platforms such as EventBrite or MeetUp.
The ability to create public and private groups for the local community.
Basic User Interaction features such as media-sharing or status updates.
Multiple ways of scanning for inappropriate content such as: reports or media-scanning.
Emergency Protocols that allowed parents to contact authorities if something troubling arises during a meetup.

1.3. Setup Instructions

(OPTIONAL) - Create a venv/conda environment with python version >= 3.10 for this project
Clone the following repo

https://github.com/x-candy6/PlayDate_Revision

Within the same folder as 'manage.py'(within ./PlayDate/Application/PlayDate), run

python -m pip install -r requirements.txt

Create a MySQL database called PlayDate
Create a user with privileges to that database with the same credentials in settings.py
Run the following commands

python manage.py makemigrations
python manage.py migrate
python manage.py runserver

1.4. TODO Demo

2. Planning

Relevant Milestones - Milestone 01

2.1. Tech Stack

Python 3.10
- Standard Python Libraries
- 3rd-Party Django Libraries: django-ipware,
- Django Web Framework
- HTML/CSS/Bootstrap
MySQL 8.0
Google Cloud
- Ubuntu 22.04

2.2. Technology Decisions Rationale

Since we were starting with a new team, we immediately needed to know the demographics of our skills and skillsets. Through a quick survey we were able to deduce that our team had a widely distributed skillset with a lot of front-end design experience(HTML/CSS), but not so much for backend systems. Furthermore, our proficiencies with different programming language had significant variance which meant that for whatever language we chose to program our application, there would always be 2-3 members who would have to learn the ropes. In the end, we ultimately decided to create this application in python because of the abundance of easy and modular learning resources available. With javascript, there was also a lot of variability between the frameworks members were familiar with that ranged from React to Vue, however, all of the team leaders were familiar with python and at minimum had a rudamentary knowledge of the django framework. In addition, we believed that the official django tutorial was a great resource that provided the vast majority of concepts we needed to learn in order to implement our application.

Figure 1: The short demographics survey essentially showed that regardless of which language we choose, a minimum of 40% of team members would have to quickly learn a new language or framework.

2.3. Timeline

The completion and progress of this project was divided into five milestones.

2.3.1. Milestone 1

For this introductory milestone, we were expected to have made significant progress in planning and design. This milestone focused on the following:

The general idea of what we were creating
Main Use Cases
Main Data Items and Entities
Functional Requirements
Non-Functional Requirements
Competitive Analysis
A High-Level Overview of the Architecture and Technologies to be Used

2.3.2. Milestone 2

In the second milestone, we were expected to make significant progress in prototyping our product. In addition, there was an expectation that we would have the following formal documents ready:

Data Definitions
Prioritized Functional Requirements
UI Mockups & Storyboards
High-Level-Database Architecture and Organization
High-Level-APIs and Main Algorithms
High-Level Application Network and Deployment Diagrams
Key Risks for our Project
Methodology for Team/Project Management

2.3.3. Milestone 3

This milestone marked the halfway point of our project and by this point we had established the prototypes and were focusing heavily with development. We were also asked to perform additional iterational revisions to the documentation we had submitted previously, this included:

Revisions for Data Definitions, Functional Requirements, Architecture/Organizations, and any additional diagrams that needed updating.

2.3.4. Milestone 4

At this stage, we were expected to have a functional product ready and additionally we were to conduct test and checks on different aspects of quality assurance including:

Usability Tests
Code Reviews
Security Checks
Non-Functional Requirement Checks

2.3.5. Milestone 5

At this point of the project, we were expected to have a completed product that would be showcased and judged thouroughly by our class and the professor. We used our time in this milestone to implement any last-minute stylings and features. After all was completed, we would go on to prepare ourselves for our showcase presentation.

3. Backend Development

3.1. Diagrams and the Dynamics of Component Interaction

Figure 2: Because of time-constraints, the deployment architecture was confined to 3 simple loosely-coupled cohesive parts in order to cohere with our GCloud budget and team-size.

3.2. Implemented Functionality

Registration, Profiles, and User Authentication
Support
Groups
Event Management

3.3. data models, database schema, and any APIs

3.4. Database Overview

Figure 3: Initially, the schema had multiple points of data redundancy that duplicated 'event' entities to public-events and group-events. The iterations worked to reduce data redundancy and place more significance on the 'User,' 'Event,' and 'Group' entities.

Figure 4: The main entities in this application revolved around the Users, Groups, and Events. Other entities were made to inherit properties from these and create usable relations.

3.4.1. Models

Algorithms Used
- Routing/View Matching(Pattern Matching via Regexp or pattern matching algorithms)
- Template Rendering(via text substitution via string interpolocation or regexp)
- Control Flow(via conditionals and loops)
- DB queries: orm(uses different optimization techniques such as query planning, rewriting, and execution optimization)
- Data Retrievel - Indexing hashing or treebased(b-trees) were used to retrieve data
- Filtering and Sorting - Indexing, hash-lookup, binrary search, quicksort/mergesort
- PW Hashing, Token-Based Auth, Access Contro(Role Based)
- Custom Data Validation via Conditionals and Loops
- Inverted Indexing or Term Frequency-Inverse Document Frequency for indexing and ranking based on relevance to search
- Filtering - binary/hash lookups
Thread Pooling
Database Connection Pooling
in-memory/database caching

3.5. Deployment

3.5.1. Basic Networking

Figure 5: The application as a whole did not need any custom-made individualized web protocols. Instead it took advantage of existing protocols that were known to be the secure standard at the time.

3.5.2. Server Management

4. Frontend Development

4.1. Design Choices and Why

HTML/CSS/BOOTSTRAP/Django Forms/Template Engine

4.2. usability principles or design patterns

4.2.1. Usability Principles

Usability Principles that were Focused Upon
- Efficiency
- Learnability
- Memorability
- Error Prevention and Handling
- Flexibility(groups and user profiles)
- Simplicity
Usability Principles that needed more focus
- Visibility
- Feedback
- Accessibility
- Consistency

4.2.2. MVT/MVC

4.3. User Experience Development

4.3.1. UI Mockups and Storyboarding

Use Case 1: Registration
Use Case 2: Group Creation
Use Case 3: Joining a Group
Use Case 4: Creating Group Events
Use Case 5: Creating Public Events
Use Case 6: Emergency Assistance
Use Case 7: Event Surveys
Use Case 8: Technical Support
Use Case 9: Reviewing an Event
Use Case 10: Friends List
Use Case 11: Reporting Users/Inappropriate Content
Use Case 12: Viewing RSVP'd Events
Use Case 13: Saving Favorite Events
Use Case 14: Group Posts

4.3.2. Mockups -> Wireframes

Use Case 1: Registration
Use Case 2: Group Creation
Use Case 3: Joining a Group
Use Case 4: Creating Group Events
Use Case 5: Creating Events
Use Case 6: Technical Support
Use Case 7: Viewing RSVP'd Events
Use Case 8: Technical Support
Use Case 9: Reviewing an Event
Use Case 10: Friends List
Use Case 11: Reporting Users/Inappropriate Content
Use Case 12: Viewing RSVP'd Events

4.3.3. Screenshots of the Final Product

Homepage
Public Events
Registration
Login
Policy Pages
Support
Support Chat Bot
Events
Groups
Data Validation Pages
Profile
Joining an Event
Creating an Event
Joining a Group
Creating a Group
Creating a Group Event
Creating a Group Post
Managing Groups
Managing Events

5. Testing and QA

5.1. Usability Tests

5.1.1. 2.1 Overview

Purpose

As an application for parents of children and pets, “ pays much attention to user’s and their families’ security. One of our superior features is “User Verification”, which will be tested in this section. “User Verification” will be tested since we want to make sure this superior feature is working well to compete with our competitors. There are 5 major functions related to this superior feature to be tested: upload identification image, sign up for events, join groups, create events, and create groups.
1. Problem Statement and Objective
  1. Upload Identification Image: we will test if a user can easily upload the identification photo for verification. A verified user can obtain more privileges, like sign up events and create groups, and it’s important for them to upload the identification photo successfully.
  2. Sign Up For Event: After the verification, we will test if a verified user can successfully sign up for events on “. This “sign up” function is a core privilege on our website and it’s important for users to successfully implement it.
  3. Join Groups: After the verification, we will test if a verified user can successfully join a group on “PlayDate”. This “join group” function is a core privilege on our website and it’s important for users to successfully implement it.
  4. Create Event: After the verification, we will test if a verified user can successfully create an event on “PlayDate”. This “create event” function is a core
    
    privilege on our website and it’s important for users to successfully implement it.
  5. Create Groups: After the verification, we will test if a verified user can successfully create a group on “PlayDate”. This “create group” function is a core privilege on our website and it’s important for users to successfully implement it.
2. User Profile
  
  Usability testers are from a diverse demographic pool who have been informed with the basic purpose of our application. They are newly registered and their accounts will be 'pending for verification' once created.
3. Method(Test Design)
  
  Usability test with metrics for effectiveness, efficients, and satisfication.
4. Task List
  - Upload Identification Photo
  - Registration
  - Join Groups
  - Create Events
  - Create Groups
5. Testing Environment
  
  Test host server website with a clean instance of Firefox/Chrome on Windows/Mac/Debian.
6. Test Monitor Role
  
  Front-End Team Member
7. Evaluation Measures
  
  Effectiveness & Efficiency form and Satisfaction Questionnaire

5.1.2. 2.2 Usability Test Results for Effectiveness and Efficiency

# of pages	Test Case	% Completion	Errors	Comments	% Time to Complete	# of Steps	Allotted Time Given
1 or 3	Upload ID Photo	100%	No errors.	The acceptable photo formats are: apng, avif, gif,

jpeg, jpg, png, webp. If an unverified user tries to create an event or a group, the user will be redirected to the verification step | 0 | 3 | 30 Seconds |

2

Event Registration.

95%

No usability errors however formatting of the event page changed after registration was finalized. Not consistent.

The acceptable photo formats are: apng, avif, gif,

jpeg, jpg, png, webp. If an unverified user tries to create an event or a group, the user will be redirected to the verification step | 5 | 2 | 30 Seconds |

2

Join Group

95%

When unverified users join a group "404 error" occurs.

False Negative. No errors for verified users joining a group.

When unverified users join a group, it should show a page rather than 404. | 5 | 2 | 30 Seconds |

2

Create Event

98%

But Individual event page need more

2

Create Group

98%

Styling Errors: no group picture, Group Creation button is misplaced out of border

Only verified users can create a group, unverified

users shall be redirected to the verification step when trying to create a group.Both groups and individual group pages need more styling | 5 | 2 | 1 Minute |

Task #1	Description
Task	Upload ID Photo at http://34.83.255.32:8000/profile/
Machine State	Host Server Running
Successful Completion Criteria	ID Photo uploaded and "Awaiting Approval" message shown
Benchmark	Completed in 30 seconds

Task #2	Description
Task	Event Registration at http://34.83.255.32:8000/events/members-events/
Machine State	Host Server Running
Successful Completion Criteria	Sign up for an event and can view this event’s

individual page. |

Benchmark

Completed in 30 seconds.

Task #3	Description
Task	Join Group http://34.83.255.32:8000/groups/
Machine State	Host Server Running
Successful Completion Criteria	Join a group and view the group page
Benchmark	Completed in 30 seconds.

Task #4	Description
Task	Create a Public Event at http://34.83.255.32:8000/events/my-events/
Machine State	Host Server Running
Successful Completion Criteria	Create an event and view the event page
Benchmark	Completed in 1 minute

Task #5	Description
Task	Create a group at http://34.83.255.32:8000/groups/myGroup/
Machine State	Host Server Running
Successful Completion Criteria	Create a group, view the group page, and confirm that the group-creator is the admin
Benchmark	Completed in 1 minute

5.1.3. User Satisfication Survey

5.1.4. Survey Results

Average Agreement Levels

Statement Number	Average User Response
1	4
2	4
3	5
4	4
5	4
6	4
7	3
8	4
9	3
10	4
11	4
12	3
13	4
14	4
15	4
16	4

5.2. QA Testing

5.2.1. HW and SW setup:

Testing hardware 1 - MAcBook Pro 2019 Software 1 - MacOs Monterey Version 12.4 Testing hardware 2 - MacBook Air 2017 Software 2 - macOS Monterey Version 12.3.1 App link: http://34.83.255.32:8000/

TEST 1: Usability

2.1 Users shall receive online help from support for any assistance on the application.
Test Plan 1 Outline:

This test will be performed on the home page where the chat bot is located on the bottom right. The test environment for 2.1 QA test is performed on Chrome and Safari. The action should take a minute or two to complete, this includes the typing and submission process. The risks that the test may run into is if the user submits repeated text or if the automated message lags to reply or simply does not work.

5.2.2. TEST 2: Security

4.2 - Information should be securely transmitted to the database server without any changes in information.

Test objectives:

This test is to make sure that user input is correctly sent properly to the database and we also want to make sure that password input is type in securely. This test should take about one minute to perform input and about another minute to check the database. A risk of this test is if the test fails we might have to fix data in the backend if incorrect tables are affected

5.2.3. TEST 3: Compatibility

5.1 - Application should be supported on Mac via browsers of versions, Chrome >= 60, Safari >= 12

Test objectives:=

The test requires that a standard input is inserted in the navigation search bar for the same results. The search result should work on compatible computers with chrome,firefox, and Safari. The test should take about a minute to verify that results are present for what is being looked for. The risks are that the user users an unsupported browser that fails to render a search.

5.2.4. TEST 4: Data Storage

7.2 - The application’s back-end servers should only be accessible to authenticated backend admins.

Test objectives:

The test is to make sure that user input cannot affect the backend database. If a user were to input text that would be similar to backend code, then the backend should remain unaffected. This test should take about a minute to perform the input and then another minute to check the backend. The risks are that the backend might be affected by user input during this test.

5.2.5. TEST 5: Data Storage

7.1. The application’s back-end servers should never display a customer’s password.

5.2.6. Test objectives:

The test requires a new user to register an account using different sizes and characters. The password is encrypted by Django using the sha₂₅₆ algorithm. The action should take a minute or two to complete, this includes the typing and submission process. The risks that the test may run into are if the user submits more than what we tried of 170 characters and therefore might not be able to work. Another risk would be if the test fails we might be able to see other user passwords.

2023-06-27_09-10-48_Screenshot 2023-06-27 090614.png

5.3. Code Review

1. Coding Style
● Indentation: We are using Python and it uses indentation to indicate control structures, so
correct indentation is required. By doing this, the need for bracketing with curly braces is
eliminated.
● Header comments: Having an introductory header comment is very important. Django
organizes into ‘applications’. Our project has the home app, the events app, and the
groups app, each of which have a set of standardized files which share names. Having a
comment at the top is the perfect place to mention which file you are looking at. It is also
good practice to provide a sense of the purpose of that file and what the big ideas are that
have an effect on the organization of the file itself.
● Camel case: We use camel case styling for definition and variable names.
● Code management:
○ Our project is divided into multiple applications like: playdate, home, events,
groups for structured management.
○ Each application has templates and views.
○ All the frontend code is stored in the templates folder of each application
○ All the backend logic is written in views.py for each application.
○ All the database classes are defined in models.py of respective applications
which can be imported into other applications when needed.
○ All the forms are defined in forms.py
○ Navigation tabs, footers, and other reusable html snippets that are common to
multiple pages are stored globally in the playdate application’s templates folder
and are included in other applications, without the need to re-write the headers
and footers.
○ All the css, javascript, and media files are stored in static folders for access from
all html files.

5.3.1. Peer Review

Peer review by other team
Team 01 Code Review of Team 03
Part 1
home/views.py:
- Excellent header providing a short but detailed description of the particular file
- Good organization of imports- Plenty of informative inline comments
- Consider separating parts of the code with white space rather than simply comments to
make it less crowded and easier on the eyes to read
- Good use of standard naming conventions
home/HTML/:
- Good headers
- Consider having minimal inline style. Inline style avoids content and design from being
separated. Use CSS files instead. For ex: everything related to font, color, align, etc
should be in CSS file not inline, makes the code very crowded
- Consider separating divs with white space to make it less crowded and easier on the
eyes to read
- Good use of standard naming conventions
- Very few informative comments
- Consider adding <footer> to a separate view
- Consider putting functions to a separate file
Part 2
events/views.py:
- Excellent header providing a short but detailed description of the particular file
- Good organization of imports
- Utilizes white space well, seems less packed, and is simpler to read.
- Plenty of informative inline comments
- Good use of standard naming conventions
Peer review by other team member
Part 1:
Home/html
● Would want footer as a separate file for better organization.
● Easy to understand and follow
Home/views
● Header, helpful to know which page we are in to edit
● Imports organized and easy to find
● Informative comments
● You would want to reduce the number of if statements. Make it more modular
by adding functions. Want to make it easier to debug and modify.
Part2:
events/views
Organization:
● Header, helpful to know which page you are in for editing.
● Imports organized
● Inline comments informative
● Probably same as previous feedback, to reduce number of if statements if
possible and make it modular
● Email logic as a separate function for contact support is an idea if possible

6. Conclusion

6.0.1. Thoughts, Introspections, and the Future of this Project

The main challenge of this project revolved around our time constraints. We were tasked to create this platform in 4 months however we weren't exactly given 4 months of time dedicated for development and coding.

The first month revolved around planning and training. However training was still an integral part of every milestone. It's one thing to teach someone how to write a simple 'hello world' program, but that will honestly just teach them how to write to stdout instead of teaching them the reasons on why one would want to print to stdout. That being said, web/programming epistemology was a core part that was lacking from the education of fellow members. Throughout the entire project, pair programming and active discussion was a fundamental aspect that allowed members to not only apply knowledge(such as routing, relative styling units, basic security principles) but also learn 'why' we would apply that particular datum/practice toward a specific situation.

I believe it was because we dedicated so much time towards team-member-interoperability, that we were able to win 4/5 milestones and subsequently the best project award. While the fundamental components of this application were based off of simple web-development tasks, the amount of work required for documentation, testing, styling, and implementation was definitely too much for a single person to do alone. From the beginning, this project placed importance in teamwork and being able to plan and orchestrate a flexible gameplan that utilized the efforts of all team members. We didn't win the first milestone because we had lacked that, but we learned that was one of the most important facets that had resulted in our initial failure.

With that being said, I think the final product of this project is very modular and scalable in design. The django philosophy emphasizes reusability and because of that I will still be able to use this entire project as a template for any non-static site that requires authentication, groups, support, and events.

From an abject and concrete perspective, my impressions of the endproduct weren't very optimistic- but that perspective is myopic, and the value of this project wasn't the application itself, however the knowledge and skills gained from it. The main point of this application was to transition from being 'lone-programmers' to engineers that are capable of working together to create a scalable and successful endproduct, and I believe we were all successful in making that transition. I think we did a great job creating a usable application all while learning how to efficiently work in a team. That's one of my main takeaways from this project. Personally with the vast amount of resources on the internet, I think anyone could make a similar application, but the true challenge was to be able to work successfully in a team so we could in-fact create bigger successful products in the future regardless of which team we are placed in. Practicing team management skills and philosophies such as being AGILE and placing importance in team-integration through Kanban/SCRUM were integral parts of development that have long-lasting value outside of this project.

Key Improvements to make

There are a lot of features that need to be immediately added in order to improve the reusability of this site as a whole. Things like email routing, notifications, event-logging, and data validation, all need to be implemented in order for this project to be used as a seamless template.

6.0.2. Writeup Kanban

V 1.0.3

TODO	DOING	DONE
		Blog Post Outline
		Import static files
		Setup templates
		Showcase Server setup
		Writeup
	Convert certain images to charts

p1 - Add Resources page with Milestones, Project, and SQL export files
p1 - switch from aws demo to docker-based in-browser demo
p1 - Demo Video

p2 -Manage repo visibility scope
p2 -Convert Long Images to a Gallery format for better ux

p3 -Create a way for automated verification for test users
p3 -Prioritize Significant Points and Remove the Others
p3 -Test-Server Monitoring, Optimization, and Automation

Revise	Revise	Revise