eMatchBay

1. eMatchBay Hendi Chandi Aleksandr Lyamtsev Arifin Tahir Ie Ling Tjam Itasari Wiryanto

2. Operational Concepts • User Community • People from all lifestyles and demographics • People with desires to meet new friends anywhere and anytime safely. • Good for people who are always on the moves.

3. Operational Concepts(continued) • Environment • Works in any mobile devices running on Windows platform, eg: IPAQ • Information gathered from clients and transferred to server through web services using the Internet. • Server filters and processes data according to user’s requests. • Assume: • More cell phones’ users switch to PDAs in future. • Transmissions of high bandwidth data become more affordable.

4. Operational Concepts(continued) • Major Benefits • Meet new friends safely - rating system • Link people with same interests and lifestyle • Provides feedback to users from peers for self-reflection • Provides an avenue for users to express their opinion about their friends freely. • Help shy-natured users to meet new people.

5. Operational Concepts(continued) • eMatchBay does not support: • Verbal communications • Concurrent written communications (eg: MSN) • Displaying matches on map • Landscape detections

6. User Prompt with a welcome page Click on SIGNUP button Fill in his information, ranging from hobbies to recreation. Everything else is optional - set by default as all null, except biodata. Once data entry is completed, prompt a disclosure page. Prompt a page disclosing all risks involved, and eMatchBay will not be responsible for any harm done to user. After user accepts agreement, user will be able to use eMatchBay to user’s heart content. Server User will supply, either from a mobile device or a remote computer, their personal data (name, age, username, password, gender, sexual orientation, e-mail, marital status). Some constraints will be imposed on these inputs (for example, password must be 8 characters long). These information must be stored successfully in our database for future retrieval. Database generates an ID number for this user. If information storage fails, user must be prompted to re-input data. System RequirementNew Sign Up

7. User Starts program. Login window will be prompted to login. One scenario out of three is possible thereafter: Profile found and password matches. Profile found but password incorrect. Profile not found. User will be fed a home page with all relevant links or actions. Server receives login information looks for user profile in database (using username) and clarifies password. If username and password matches, grant permission for this current user. If not, send error message. System RequirementReturning User Login

8. User User presses edit profile button To edit anything, user will just need to change user’s information, either using textbox, dropdown menu, radio button, etc. User will have option to disclose or hide certain information. After user completed all changes, user will need to click “SUBMIT CHANGES”. From this time on, any retrieval of user’s information will be the updated information Server User must be able to update profile at any time client side calls web service that retrieves user profile, so server retrieves those attributes and returns them. Client side calls the web service that updates user’s profile, passing as parameters all fields in profile and their display status. System RequirementEdit Profile

9. User User can choose from drop down menu of several options ranging from hobbies, bio-data to recreation. All entries will initially be by default set to null.                               User will most certainly be prompted to enter biodata range of person user expects to meet. Everything else is optional. After user make all necessary changes, user has to click “SUBMIT CHANGES” to update all changes on server. From now, if user looks for a match, it will be based on criteria set up by user unless user changes it again. Server Client side calls web service that retrieves user’s search criteria, server retrieves those attributes and returns them If user has never set a search criteria before, null strings are returned. Otherwise current search criteria are returned to be displayed. If user decides to change search criteria, client calls web service that updates search criteria. Search criteria includes age, hobby, occupation, etc, and limit to the number of matches. System RequirementUser sets search criteria

10. User User will be checked whether user has set the search criteria. If not, user will go to part (c), else user proceeds. This will send a request to user’s GPS-like* system to locate his universal location. User’s location will be stored at user’s program Program sends his location to server to find best 10 matches within user’s radius. Matches will be placed inside contact links. User can click next or previous to browse through pictures. If user is interested to contact person, user can use any communication means specified by other user. From here on, user will be on user’ own risk. Server User must have submitted a search criteria. User must specify his/her location to server using webservice. Server then queries database to find all users within a certain radius of current user which doesn’t ban current user, doesn’t opt to only give access to his/her profile to people in his/her friend list. After server retrieves profiles of these other users, it calculates best matches with user’s search criteria. If another user is ON, current user will be able to add user to friend list, or send static messages.. System RequirementUser Searches For Matches * Since GPS is not available, we will be uploading map-coordinates to find user’s location.

11. User User will be checked whether user has set search criteria. This will send a request to user’s GPS-like* system to locate his universal location. User’s location will be stored at user’s program. Program will send his location to server to find best 10 matches within user’s radius. Matches will be placed inside contact links. User can click next or previous to browse through pictures. If user is interested to contact person, user can use any communication means specified by other user Server User must have found other user through the matching User must know either the username or e-mail address of other user. Other user must have his/her status set to “on”, and must not be in the friend list of the current user. Other user is found through match finding function, and when prompted, accepts the request to add him/her to friend list. Other user receives a request, and has the chance to either accept or reject the request sent by the current user. System RequirementUser Adds Another User

12. User The user will choose the person the user wants to rate by selecting the username or identifier  The user will then answer question about user’s match  The user will then click submit to prompt the server to update the match’s rating   From now on, every time the user’s match rating is requested, the new updated rating will appear. Server The other user must be contained in the current user’s friend list. The scoring is open, so the other user will not be able to reject any score. The current user will be asked to provide a score that will be entered into the database. There will also be an option to enter a textual “testimonial” of the other user which will not count toward the scoring. This new score should be displayed along with the other user’s profile the next time some other user asks requests it. System RequirementUser Rates Other Users

13. User To communicate with your new match, the user will double click at the match username or identifier             A new window will open.             The user can just communicate just like any instant messaging system (more like SMS, not MSN). Server User can send a static message to any other users in his/her friend list, and non-friend users who are ON. After user types in the messages and submits it through a web service, the server receives it and first queries if the target user if ON or OFF. If target user is ON then it sends message directly to client app. If target user is OFF the message is stored in the user’s inbox table in the database. The next time user is online and checks his/her inbox, this message should be displayed. System RequirementUser Sends Static Message

14. User The user will choose the person’s username or identifier The user will be prompted to make sure the user has met the correct selection. The user will have to click “YES” to be processed, or the ban is dropped. After clicking “YES”, that match’s username will be entered at user’s ban’s list. Server Either the other user was in the current user’s friend list, or he/she was included in a match, or he/she sent a message to the current user. Client side calls a web service that takes the ID of the person to be banned. The other user’s ID is entered into a list of banned users by this user in the database System RequirementUser Bans Another User

15. Software Architecture • Software specifications: • Operating System: Windows Mobile Computing • Software: • Microsoft .Net, using C# and SQL • Microsoft SQL Server • GPS software (ex: MapPoint) to identify users’ location. • Database specifications: • Database will contain multiple tables with schema defined using 3d normal form. • Database should represent following properties: • - Personal information of a user • - Public information of a user • - Location descriptors • - Contact list and ratings stored by a user.

16. Systemarchitecture • Fast and reliable client-server communication using on--fly/session interactions with web services • Web services are called by application via a well defined API • API layer, sessions, and data buffers interface our web services with database and clients • modular nature of our architecture will provide a convenient way of producing updates for our application and issuing new features for future releases. • API specification support administrative tools and updates • System behavior: • Client application uses brief connection to internet from mobile device to perform a specified task. • Once connection is established, mobile application will access appropriate web service, using client id as a session ID. • server will perform task specified by a webservice, and return information back to client using an XML stream.

17. Execution oriented view and data flow • Profiles • Rating • Matches Server Target • Profile1 • Profiles • Location Matching Comparator • ID • Profile • Rating • Request • Location • Match • Profile + rating Requester Rating Calculator • Rating • Feedback • Database Maintenance • Critical updates, releases Location Identifier Administrator • GPS services • Map Point • GPS data • SQL requests • GPS data Information Gateway -> Retrieval/Storage DBMS • Profiles • Rating • Location • DB modifiers • GPS requests API, sessions, data buffer

18. Sample UI User defined matching specs Main page interface User profile

19. Lifecycle PlanWhy is the system being developed? • Create a program that satisfy the customers’ need of close connectivity • Create sense of community • Networking

20. Lifecycle PlanMilestones • Wk 1 – 2 (April 7th - May 3rd): Research & design ( writing LCO and LCA) • Wk 3 (May 3rd – May 8th): Research on rating questions, Database constructions • Wk 4 – 5 (May 9th – May 22nd): Build server & client app (concurrently)/ Database Integrating • Wk 6 (May 23rd – 26th): Product Integration (include: testing & debug), Usage Doc. (README, etc) • Wk 7 (May 26th – June 2nd): Testing & Debug, Prepare for final release

21. Lifecycle PlanWho will do it? • Database constructions: • Design & build database • Team members: Hendi, Arifin, Ie Ling, Aleksandr • Research on rating questions: • Search online for cosmopolitan style questions for rating users. • Set rating criteria for users • Team member: Itasari • Client (user) App • Build UI for user interaction with program • Connect to server through server’s web services to carry out the functions in the program. • Team members: Aleksandr, Arifin • Server App • Build web services that connect with client app and perform operations on databases & user data according to request from client app. • Four parts: • Matching Comparator -> Team member: Hendi • Rating Calculator -> Team member: Ita • Location Identifier -> Team member: Hendi, Ie Ming, Ita • Information Gateway: Retrieval and Storage -> Team member: Ie Ming

22. Feasibility Rationale • Resources & Facilities • All required resources are available & fulfilled: • 2 PDAs • Database • Software: C# & SQL Server • Program Risks • Seems small/manageable: • 4 members experienced in databases and dealt with web services before • Architectures (both client/server) are clearly laid out. Seems reasonable for completion in four weeks time. • .Net provides easy implementation of UI.

23. Feasibility Rationale(continued) • Other Risks: • Unforeseen circumstances – may not be able to finish program in 4 weeks. • Not enough time to optimize the program – efficiency problem • Cost of mobile devices still high, but expected to go down in future • Users may not like the program