IS480 Team wiki: 2013T2 The CodeFather Final Quality of Product
Back to Main Wiki | Progress Summary | Project Management | Development Overview | Quality of Product | Reflections |
Contents
Final Deliverables
We have completed 10 iterations till Finals.
The table below provides the links to our works and documentation:
Stage | Specification | Modules |
---|---|---|
Project Management | Meeting Minutes | Iteration 1 to 6 - Team, Supervisor & Mentor Meetings |
Project Metrics | Schedule, Bug, Wellness, Decision Making Metric | |
Requirement Gathering | Market Research | Product Comparison |
Market Survey | Gathering feedback from users to understand users' needs | |
User Requirement Validation Tests | User Testing to understand the user experience of our application and the expectations of the user | |
Design | Architectural Design | Architecture Overview and design of systems and application |
Prototypes | Low and Medium Fidelity Prototype for mobile and web application | |
Testing | User Testing | User Testing |
Presentation Materials | Presentation Slides | Slides for Acceptance and Midterms |
Deployment
Our web application for Schedulous is deployed on a live server.
You can try it out our Web application here!
Our Android mobile application is also available to be downloaded from Google Play here
user testing
We have conducted two user and vendor requirement validation test for our mobile and web application.
We have also conducted three user testings of which one is a load testing for our mobile and web application.
Click to view in detail for the user testing or scroll down to see the summary of findings for our user tests.
User & Vendor Requirement Validation Tests
x | 1 | Requirement Validation Test - Mobile Application | x | 2 | Requirement Validation Test - Vendor Web Application | x | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
x | 29 Feb 2014 | x | 17 - 21 March 2014 | x | |||||||||||||
x | x | x | |||||||||||||||
User Testings After Midterm
x | 1 | Android Users Mobile Application Test | x | 2 | Android and Web Application User Testing | x | 2 | Load Testing | x | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
x | 24 - 26 March 2014 | x | 1 - 11 April | x | 9 - 11 April | ||||||||||||
x | x | x | |||||||||||||||
User Testing | Main Findings | Changes Made | User Comments |
---|---|---|---|
First Mobile User Testing |
|
|
|
Vendor Web Testing |
|
|
|
Android Mobile User Testing |
|
|
|
Android Mobile and Web User Testing |
|
|
|
Load Testing |
|
|
No comments |
User Interface Changes (Web for users)
Below shows the before and after of our web application for users.
User Interface Changes (Mobile)
Calendar Main Page
Schedulous synchronise all calendars within the user's phone, and populated within our mobile application itself. Initially all our events were all populated with a single colour scheme -- Black and there was no display of information for the events shown. Users complained that there was a lack of information being displayed on the calendar page.
We have then revised our design and categorise different colours for different calendars. In addition, we have also customised the calendar page to include the display of events as well as displaying the particular event when a user clicks on the date. In our current application, the calendar is categorise in terms of month by default. So all the events for the particular month would be displayed.
Create Event Page
Previously, in our mobile application, our Create New Event Page was a form, where users were navigated to another page for selection of dates as well as selection of friends. Once they were done filling the appropriate details, the form would be fully populated. This is similar to a website form.
However the concept of the form has in turn lead users into feeling that they were directed to the same page and there were too many clicks that users have make while creating an event. We have then revised our design as well as our flow to improve the usability as well as reduce the number of clicks for the user to make.
In our current application, we have changed the flow of create an event into a straightforward flow instead of a form that navigates to other pages and populates details.
Our current flow would be in the following sequence:
- Enter Event Title & Location
- Select Dates and Times
- Select Friends
Select Dates & Times Page
Previously our way of selecting dates and time required the user to pick dates and times on separate pages. In addition, when selecting of a timeslot, it will in turn populate a time dialog for the user to choose the appropriate time. Users was in turn confused about the selecting of timeslots as it was just a single field instead of the usual selecting of start time and end time of the event.
In our current application, we have combined both the selecting of dates and times in a single page allowing the user to select multiple dates as well as times to indicate when they would like this event to be held on.
For instance, Huishia would like to organise a FYP meeting sometime within this week. She would like it to be either on 24 February, 26 February or 28 February 2014 from 3pm to 6.45pm. In this case, she can be able to select the following timeslot for the meeting and allow her group members to allocate their availability. This in turns reduces the number of clicks as well as allow the user to understand our application's concept better.
Select Friends Page
In our previous design for the Select Friends Page, we only displayed the user's Facebook friends and there was no way for users to be able to view the friends that they have already selected. This in turn cause us to incorporate and change a few elements to increase usability of the users.
In our current application, you would have noticed that there are 3 tabs on the Select Friends Page, this would in turn allow the users to view the friends that they have selected as well as selecting all the members in a particular group when clicking on the group button. This in turn would allow the user to reduce the need to select the same friends over again when all they have to do is to tick a group.
Chat Main Page
In our previous version of our application, our Chat Main Page displays the members in the existing group . Users commented that they would prefer to see the conversation as well as updated information in this page. This would in turn allow the Chat Main Page to seem more like a chat page. We have then considered their feedback and make the necessary changes.
In our current application, we display the latest messages from a user to allow users to see at a glance what are the user's latest messages.
Individual/Group Chat Page
In our previous Individual/Group Chat Page, there was a lag time when displaying of messages due to the fact that when the user access the page, it would grab data from the server and populates on the page. This in turn cause the users to wait and wonder what was wrong with the application.
We have then incorporated locally caching of messages to allow messages to be populated without any delay. In addition, we have also included a tab that would display the events organised for the group. Users can then be able to update their availability as well as confirm their event within the chat group itself.
Notifications
Previously our application was unable to display notifications hence users did not know who has communicated with them in the group as well as the interactions that they have with their friends. We have then implemented Google Cloud Messaging to allow notifications to be shown to the users for the following tasks:
- New Chat messages
- New Chat Group created
- New Event/Outing created
- Confirm Event/Outing