INTRODUCTION: The purpose of UF Social is to provide platform to connect UF Gators based on their interests. This provides a medium for Gators to connect and communicate with each other. The finished product is intuitive to the users with a minimum learning curve. Mobile App should use the system resources efficiently.
The functionalities for the application are: *Match users based on their common interests. *Match users based on their location. *Send and receive notifications on mobile application. *Update the profile match list in real-time.
The UF Social software system consists of a mobile application. The software will provide users with the profiles of fellow Gators in real-time with whom they have common interests and with whom they have crossed paths. The profiles that are shown in the application are filtered dynamically based on users proximity to each other.
SOFTWARE CONTEXT: RethinkDB will be hosted as a centralized server database and all the users will have access to the app using an internet connection. There is also a server-side script running to facilitate operations on the data in the database.
APPLICATION DETAILS: When users open the UF Social application for the first time, they are met with the LANDING PAGE. This page contains the application name “UF Social”, a button for logging in to existing account, and a button for creating new account. Upon clicking the “Register” button, the user will be brought to the REGISTRATION PAGE page where they must enter their desired username, password, and their UF email. Only a UF email address can be used for registration. After entering this information, and clicking the “Submit” button, the user will be taken to the CONFIRMATION PAGE that awaits the user to enter a confirmation code. This confirmation code will be sent to the provided UF email after the user registers an account. After the user enters this confirmation code inside of the app, the account information is permanently created in our back-end database. From here, the user is taken to the USER SUGGESTION PAGE.
The next time the user opens the application, and chooses to login to an existing account instead of registering a new account, they are taken to the LOGIN PAGE. On this page, they may type in their username and password. After our back-end authorizes this information, the user is logged into their account, and is sent to the USER SUGGESTION PAGE. However, if the user has forgotten their password, they can select this option on the LOGIN PAGE, and get sent to the FORGOT PASSWORD PAGE. From here, the user will confirm their email address, and have the system send a randomly generated code to the supplied email address. Upon a successful entry of this code on the same page, the user is directed to reset their password to a new value, then is logged in and transferred to the USER SUGGESTION PAGE.
On the USER SUGGESTION PAGE, all saved and filtered matches are displayed in a single column. From here, the user can switch the tab to view their own profile and filtering information on the MY PROFILE PAGE. On this page, the user can specify their interests, specify their educational status, and how they would like to filter potential matches. Any changes to this page are immediately sent to the back-end server. From the USER SUGGESTION PAGE, the user may also switch the tab to view their saved matches on the PREFERRED USERS PAGE. This page only displays profiles that the user has both matched with, and approved. From either this page, or the USER SUGGESTION PAGE, the user may press on any profile preview to view that matched person’s full profile. From the PREFERRED USERS PAGE, the user can click on a friend and switch to the CHAT PAGE to send messages users on this page. If the user declines this potential match, the information for that user is erased from the app’s memory, and the profile is added to the user’s list of blocked profiles.
While the app is running in the background, it is periodically sending its GPS location to the server. At the same time, all other users are sending their own GPS locations to the server. After every update to any GPS location on the server database, the server checks if that location is within a certain range of any of the other locations it has logged. If this is the case, the server sends a header message to both users that were within the proximity. This header contains just enough information for each user to determine if their filtering requirements were met. Every time a unique meeting occurs, each user increments the amount of times they have met the other user in a local data store. If then, the amount of times that user has “met” the other user exceeds a certain value, that user requests the full profile of the person they just crossed paths with. The server fulfills this request, and the client stores this information in the USER SUGGESTION PAGE. This means that they have matched with the other user. Of important note is that this matching is independent of the other party; one person could match with another based on the frequency of their meetings, while the other person has not yet had enough meetings to form a match. However, as these two users meet more, eventually the match will display on the other user’s app.
Matches have several criteria; most important are the shared interests. The application will accept only certain interests; preset by the developers, so as to create a common list for all users. (C++ would not match with C plus plus, if we allowed users to submit their own interests). When the server determines that a meeting has occurred, it forms a list of only the interests that are shared between both parties, and sends the size of this list to both parties so they can determine whether the other party has enough matched interests to form a match.