IS480 Final wiki: 2016T1 WEGOT
ABOUT US | PROJECT OVERVIEW | PROJECT MANAGEMENT | DOCUMENTATION |
MAIN WIKI | MIDTERM WIKI | FINAL WIKI |
Contents
Documentations
WEGET Progress Summary
Project Highlights:
Project Challenges
Challenge Faced | Impact | Mitigation Plan | Outcome |
---|---|---|---|
Lack of resources to market mobile application |
Without proper marketing, our application would be on the play store with no real users. This makes our entire project pointless as the core of our project's revolves around user to user interactions |
Develop and upload marketing plan given the resources we have at the moment |
|
Proof-of-concept testing for our mobile application with real users |
We have done user testing with simulated users for short periods of time. However, our real users would be using this application in a much more frequently. Hence, our group feel its important to obtain users feedback from a prolonged user testing. |
Executing marketing plan in targeted areas that are within our reach. After execution, obtain some of these newly found users to assist us in doing a live testing lasting at least one week. |
|
Team is not supported by sponsor, sponsor was dropped after being uncontactable for more than 2 months |
Initially, our sponsor had assured us that he would be obtaining live users for our application. However, halfway through he decided that he wanted to use this as a prototype. We tried reasoning with him but he has been uncontactable since. Without his support our group now has to perform additional tasks of marketing and obtain users with whatever means possible to make our application a success. |
Adopting our own business and marketing plan, change focus from profiting to understanding whether current business model works and how to improve based on live feedback. |
|
Project Achievements
Project Management
Project Scope (Plan Vs Actual):
Project Schedule (Plan Vs Actual):
Project Metrics:
Technical Complexity:
Complexity | What is the complexity | How it was resolved |
---|---|---|
|
We made use of the popular FCM(Firebase Cloud Messaging) to broadcast notifications to our users in the event. With Firebase notifications, a notification is required in order for FCM to locate and send notifications to the specific user. However, this notification token is generated device-based, as opposed to user account-based. Therefore, if different users signed in on the same device, they essentially be sharing a single notification token. As such, all the messages sent from FCM (Firebase Cloud Messaging) console will be accessible to all user accounts logged in on a single device. This pattern of messaging behavior is not desired for our application. |
In order to combat this unintended behaviour, we have decided to generate an FCM token based on user registration with his/her device. Based on every user login, this token is uploaded to our application database. And this FCM token is cleared from database by web-service after user logout. In this design, although the FCM token is device based, it can be used by a single user login session only. The notification message behaves in the correct manner. |
|
Our application involves the transmission of users’ sensitive information such as their password, contact number and payment details over multiple HTTP GET and POST between our client devices and our web service. As such, we had to implement a secure means for the data to be transferred between client and server. In addition, with the expected volume of simultaneous users, we need a lightweight and quick means to secure these sensitive information when performing the webservice calls.
|
Client-Side: |
|
To help enable communication between our two different types of users, we chose to implement an in-app chat function. The challenge for our team is to develop a chat function with proper infrastructure to enable fast and live chats between users. Traditionally, before embarking on building a chat module, developers needed to build an infrastructure to support communication which can be very tedious and complex. Thus, the worry for the team is to enable an effective and robust communication channel for users and to also integrate communication into our other mobile application features. |
Sendbird’s Chat API helped us by removing the need to create a complex infrastructure to enable communication for our application. Thus, we would only need to focus on implementing and enabling communication channels by using their chat API. After signing up a new user, we will initialize Sendbird and also sign register them on Sendbird using a unique id that is tied to that user upon registration. After registration, we can then create and open communication channels with other users when they communicate with each other. Create new channel between 2 users: Open existing channel between users: We can then load these channels and display messages between users which can be displayed in real-time as well
|
Quality of product
Intermediate Deliverables:
Type | Specification | Documentations |
---|---|---|
Project Management | Risk, Metrics and Minutes | |
Analysis, Design and Diagrams | Market Research,Prototype, Persona, Scenarios, Storyboard, Use Case and Architecture Diagram | Market Research and Surveys Prototype |
Testing | User Test Plan | User Testing 1, Test Plan
User Testing 2, Test Plan |
Quality
Deployment:
WEGET android application can be found on the Play Store or can be downloaded via https://play.google.com/store/apps/details?id=com.weget.fuyan.fyp
Testing:
Payment Module:
Notification Module:
Request Module:
User Interface: