HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2015T2 Period Finals"

From IS480
Jump to navigation Jump to search
 
(32 intermediate revisions by 4 users not shown)
Line 14: Line 14:
 
<!-------------------START of Content Navigation Bar------------------------>
 
<!-------------------START of Content Navigation Bar------------------------>
 
{|style=width:"100%" cellspacing:"0" cellpadding:"0" valign:"top" |
 
{|style=width:"100%" cellspacing:"0" cellpadding:"0" valign:"top" |
| style="padding:0.25em;  font-size:100%; text-align:center; background-color:#696969; " width="10%" | <font color="#ffffff" size=4><b>Mid Term Wiki</b></font>
+
| style="padding:0.25em;  font-size:100%; text-align:center; background-color:#696969; " width="10%" | <font color="#ffffff" size=4><b>Finals Wiki</b></font>
 
|}
 
|}
 
<!-------------------End of Content Navigation Bar------------------------>
 
<!-------------------End of Content Navigation Bar------------------------>
 
==Powerpoint Slides==
 
==Powerpoint Slides==
Please find our mid terms presentation slides [[Media:Period_Finals_Presentation.pdf|here]].
+
Please find our Finals presentation slides [[Media:Finals_Powerpoint_PDf.pdf|here]].
  
 
==Project Progress Summary==
 
==Project Progress Summary==
 
<b>Current Iteration:</b> 10 (13/04/15 - 24/04/15)
 
<b>Current Iteration:</b> 10 (13/04/15 - 24/04/15)
*Overall Project Progress: approx 90%
+
*Overall Project Progress: approx 95%
 
*Currently performed 2 User Tests
 
*Currently performed 2 User Tests
*In the midst of attaining approval from app store
+
*<b>Uploaded to the App Store!</b>
  
 
===Project Highlights:===
 
===Project Highlights:===
 
====User Test 2====
 
====User Test 2====
<h3><span style="color:#ff5750">Objectives</span></h3>
+
<h5><span style="color:#ff5750">Objectives</span></h5>
 
*To compare the time users take carrying out the tasks, to the time of our experts
 
*To compare the time users take carrying out the tasks, to the time of our experts
 
*To identify tasks that take a significantly longer duration for users as compared to experts
 
*To identify tasks that take a significantly longer duration for users as compared to experts
Line 36: Line 36:
 
*To further improve our application based on the test results<br/>
 
*To further improve our application based on the test results<br/>
  
<h3><span style="color:#ff5750">Key Findings</span></h3>
+
Refer to [[IS480 Team wiki: 2015T2 Period. Documentation - User Test 2| User Test 2]] in our wiki for more info.
<b>Onboarding</b><br>
 
<center>[[Image:Ut2onboarding.JPG|600px]]</center>
 
For the Onboarding process, we can see that many testers had issues with the scroller for the cycle length choice. They found that the scroller was hard to use and not sensitive.  
 
<br><br>
 
  
<b>Home</b><br>
+
====Successful Upload to App Store====
<center>[[Image:Ut2home.JPG|600px]]</center>
+
<b>MenstruTrack is now in the App Store!</b>
For the Home page, we can see that many testers found the home page rather messy and overloaded with information.
+
Check it out
<br><br>
+
[[Image:Available-on-appstore.png|150px|link=https://itunes.apple.com/sg/app/menstrutrack-best-free-period/id921371387?mt=8&ign-mpt=uo%3D2]]
  
<b>Calendar</b><br>
+
====User Test 3====
<center>[[Image:Ut2cal.jpg|600px]]</center>
+
<h5><span style="color:#ff5750">Description</span></h5>
For the Calendar page, many users pressed the "Add Period" button and expected a period to be added. However, our application is designed such that users must select a date first.
+
Number of Users: 58 users<br/>
<br><br>
+
Gender: Female<br/>
 +
Date: 11 to 16 Apr 2015 <br/>
 +
Duration: Over a period of 1 week, users will use MenstruTrack as a period tracker <br/>
 +
Test Platform: iOS device with TestFlight application<br/>
 +
Questionnaire Platform: Google Form<br/><br/>
  
<b>Me</b><br>
+
<h5><span style="color:#ff5750">Objectives</span></h5>
<center>[[Image:Ut2me.JPG|600px]]</center>
+
*To gather feedback from users using our application as their period tracker
Overall, there are no issues with this page.
+
*To analyze user behavior and identify pages that users visit more
<br><br>
+
*To gather issues that users may face<br/>
  
<h3><span style="color:#ff5750">Changes from UT2</span></h3>
+
Refer to [[IS480 Team wiki: 2015T2 Period. Documentation - User Test 3| User Test 3]] in our wiki for more info.
<b>1. To automatically select a date for the user</b><br>
+
<br/>
Most testers click on the "Add Period" button first, expecting an event to happen to allow them to add a period. However, our application is designed such that users have to select a date first, before clicking on the button. Due to that, our team have automatically selected today's date for users to add a period. Thus, this will prevent users from tapping on the button first, without selecting a date.
 
<center>[[Image:Calbeforeandafter.JPG|600px]]</center>
 
<br><br>
 
 
 
<b>2. Allow the adding of period in "Period Log" page</b><br>
 
Most testers head to the "Period Log" expecting to add a period there. However, our previous design did not allow users to add a period on that page. We have decided to include the adding of period functionality for the "Period Log" page.
 
<center>[[Image:Logbeforeandafter.JPG|600px]]</center>
 
<br><br>
 
 
 
<b>3. Reduce words on news feed to avoid clustering</b><br>
 
Many testers find the news feed very clustered and some could not find the feed because of that. To solve the issue, we have decided to limit the header to just one-liner concise sentences. With that, the news feed will not appear so clustered anymore. <br><br>
 
 
 
<b>4. Reduce lag on application</b><br>
 
Many testers find the loading of the application rather slow because of the news feed. With this, our team developers have reviewed our codes to make it more efficient and thus, reducing the lag for the application. <br><br>
 
 
 
<b>5. Include a spinner for loading of news feed</b><br>
 
While waiting for the news feed to load, testers wanted a spinner to at least show that it is in process of loading. With that, our team will be implementing a spinner for the loading of our news feed on the Home page.
 
<center>[[Image:Homebeforeandafter.JPG|600px]]</center>
 
<br><br>
 
  
 
===Difficulties Faced===
 
===Difficulties Faced===
 
*Uploading our app the the Apple app store required our app to comply to many various rules. As a result, we failed on 3 attempts.
 
*Uploading our app the the Apple app store required our app to comply to many various rules. As a result, we failed on 3 attempts.
 
*Duration of vetting by Apple takes approximately 1.5 weeks each time we uploaded our app to the app store.
 
*Duration of vetting by Apple takes approximately 1.5 weeks each time we uploaded our app to the app store.
*<zach calendar>
+
*Apple does not release its existing iCal app for open development purposes. Therefore we had to implement the calendar module from scratch.
 +
*User interaction controls (e.g. extendable period bars) are not standard UI controls in the Apple library. Therefore we had to build various UI controls from scratch that interact directly with the calendar.
  
 
==Project Management==
 
==Project Management==
Line 160: Line 142:
 
|| 23 Feb 2015 - 6 Mar 2015
 
|| 23 Feb 2015 - 6 Mar 2015
 
|| 23 Feb 2015 - 13 Mar 2015
 
|| 23 Feb 2015 - 13 Mar 2015
|| -
+
|| Delay due to Calendar Module
 
|-
 
|-
  
Line 166: Line 148:
 
|| 9 Mar 2015 - 20 Mar 2015
 
|| 9 Mar 2015 - 20 Mar 2015
 
|| 13 Mar 2015 - 10 Apr 2015
 
|| 13 Mar 2015 - 10 Apr 2015
|| Delay due to Calendar Module
+
|| Delay due to code clean up to ensure 0 crashes in order for successful upload to app store
 
|-
 
|-
  
Line 172: Line 154:
 
|| Apr 2015 - Apr 2015
 
|| Apr 2015 - Apr 2015
 
|| Apr 2015 - Apr 2015
 
|| Apr 2015 - Apr 2015
||
+
|| -
 
|-
 
|-
 
|}
 
|}
Line 178: Line 160:
  
 
===Schedule Metrics===
 
===Schedule Metrics===
[[Image:Schedule_Metrics_Iter9.png |500px]]
+
[[Image:Schedule_Metrics_Iter10.png |600px]]
  
 
Iteration 8:
 
Iteration 8:
Line 185: Line 167:
 
<br/>
 
<br/>
  
*Iteration 9:
+
Iteration 9:
*Delays caused by issues that require rectification
+
*Delays due to rectification of issues in order to achieved 0 crashes for upload to app store
 
*Code clean-up to continue in iteration 10
 
*Code clean-up to continue in iteration 10
 +
<br/>
 +
 +
===Task Metrics===
 +
[[Image:Task_Metric_Iter10.png | 600px]]
 +
 +
Lessons learnt from iteration 5 taught us not to under estimate coding tasks. This helped us better measure the time required by breaking down large programming tasks into smaller ones which are more manageable and predictable. Hence helping us reduce the fluctuations in the task metric measurements.
 +
<br/>
 +
 +
[[Image:Planned_vs_Actual_man_hours.png| 600px]]
 +
 +
The Planned vs Actual Man hours depict the accuracy in allocation of time for individual tasks. Ever since iteration 5, programming tasks were better measured with lower variance. The only fluctuation that exists is in iteration 9. This is due to the fact that extra time and effort was used to rectify issues in order for our final push of the app to the app store. This took longer than planned, therefore a slight delay variation.
  
 
===Bug Metrics===
 
===Bug Metrics===
[[Image:Num_Bugs_Iter9.png| 550px]] [[Image: Bug_Score_Iter9.png | 550px]]
+
[[Image:Bug_Score_Iter10.png| 550px]] [[Image: Bug_Score_Iter10.png | 550px]]
  
 
*No testing carried out in iteration 7 as there were no programming tasks
 
*No testing carried out in iteration 7 as there were no programming tasks
Line 196: Line 189:
  
 
===Project Risks===
 
===Project Risks===
[[Image:Top_Risks.png|600px]]
+
[[Image:Top_Risks_new.png|600px]]
  
 
==Technical Complexity==
 
==Technical Complexity==
Line 241: Line 234:
  
 
===Team Reflection:===
 
===Team Reflection:===
As Swift is a very new language, the team had a tough time trying to find the proper resources to learn from and to find out the 'right' practices. In order to fully understand the code and framework, the team took an entire winter break to learn more about Swift. Two of the more reliable sources that the team was studying from is provided by [https://wiki.smu.edu.sg/is480/Knowledge_base#Swift Stanford University and Apple's Developer Guide].
+
Building an iOS application with Swift was definitely a challenging task for the team, one in which we may have under estimated. Through this experience, we have seen in ourselves the ability to persevere, the aptitude for learning and the boldness to go against the conventional. Despite the initial setbacks and negative feedback, we remained determined to complete the application and to upload it onto the App Store. We chose to focus on what is good and work closely with those who supported us to have come this far. During this process, we had to constantly learn new skills beyond what the school has taught us such as the Swift language, usage of the xCode IDE, Apple's rules for uploading our application and the lady's menstrual cycles. We have come to realise that even something unconventional such as 5 guys building a female related application can be done because app development boils down to simply understanding processes, logic and algorithm which is something that can be achieved regardless of gender. In conclusion, we believe that tenacity, with a little luck, got our app accepted. A sleepless night of rectifying all issues for our final push has definitely paid off.
 +
 
 +
 
 +
* In order to fully understand the code and framework, the team took an entire winter break to learn more about Swift. Two of the more reliable sources that the team was studying from is provided by [https://wiki.smu.edu.sg/is480/Knowledge_base#Swift Stanford University and Apple's Developer Guide].
  
 
===Gabriel Reflection:===
 
===Gabriel Reflection:===
Line 249: Line 245:
  
 
===Teng Yu Reflection:===
 
===Teng Yu Reflection:===
*It is extremely important to plan, even though nothing goes according to plans.
+
<u>We started something bigger than all of us. we have to finish it.</u>
*As a team, when problems kick in, we need to ensure that the mitigation plans kick in and someone will be there to cover for the other member. There is no such thing as “this is not my job”.
+
<br>
*Code as though the users know how to code.
+
Initially when the team was formed, both internal and external expectations were very high as everyone see us as a strong and well-balanced team. Maybe it is because of this, we went ahead and challenged ourselves. As we venture further into the project, we realised that the mountain top seems further away instead of getting nearer. The climb was treacherous and mid-way, during our Mid Terms Presentation, we took a tumble and reality struck; that maybe we could never accomplish what we promised. It was demoralising but like a slap to our faces, we realised the severity of the situation. Instead of turning around and giving up, we pulled each other along and climbed together. Whenever someone faces a difficulty, we reallocated our personal time to help him to along; it was never about me, it is always about us. Throughout this journey, without the support of various stakeholders such as our supervisor, sponsors and professors, we could still be at the mid-way of the mountain. As we celebrate the success of reaching the top, one key reflection that I learn is "Nothing is impossible, it is just whether you want to do it". With the right mentality and perseverance, I am glad that my team has delivered our promises to our sponsors, supervisors and professors.
  
 
===Terence Reflection:===
 
===Terence Reflection:===
*In a project with a huge scope such as IS480, it is equally important to pay attention to the larger picture such as project management on top of the smaller tasks
+
*In a project with a huge scope such as IS480, it is equally important to pay attention to the larger picture such as project management on top of the smaller tasks. For example, the goal of our project, what we plan to achieve, what is the value that we are providing to the users as well as the client, and not to forgot the plan that will make all these work out. In the previous modules that i have taken such as Software Engineering, the project was already properly scoped for us and we do not need to think about things like goals and accomplishments. However for IS480, it is different.
*Designing an iOS app possess a different challenge compared to a web application. In particular, designing for different screen sizes and managing the huge amount of interactions between the user and the application
+
*In this project, I have to learn about mobile application development with a  new language ‘Swift’ from scratch. Previously I had only experience with web development. As such, building a mobile application in a new language really put a test to my abilities for this project.
 +
*Designing an iOS app possess a different challenge compared to a web application. In particular, designing for different screen sizes and managing the huge amount of interactions between the user and the application. This is a huge different compared to web development that i am more familiar with.
 +
*Gained ‘Learning to Learn’ skills. In the field that we are in, there are always frequent updates and emerging technologies. We need to constantly upgrade ourselves and learn new skills. Thus, learning to learn skills is crucial to be able to adapt to changes.
 +
*It is also important to look at the entire process/journey of IS480. I have overcame many obstacles and grew from the first day i took up this project till now. It serves as a very good learning point for future projects that i am going to take up.
  
 
===Zachery Reflection:===
 
===Zachery Reflection:===
* Coding in both Swift and Objective C and bridging both languages together
+
* Unless you have many years and experience specializing in the particular development language and framework used for the project. It is impossible to plan the time required for programming task since the amount of code and the implementation steps are unclear.
* Understand and learn more about the Cocoa Touch Framework
+
* In order to make my estimations more accurate for the PM, I'll have to identify the implementation steps first (which means running through in my mind the HOW of building a function and module with the use of WHAT classes.) This is difficult early on, as we are unfamiliar with the technology, and should have done the research first before estimating tasks. However in this case, research does takes up time as well, and therefore we will always have to accept a task with a level of uncertainty resulting in an inaccurate estimate on time required.
 +
* Many of the functions, and UI seemed implementable in concept, and we assumed that many of the operations and libraries will be available for us to use. However, we soon realize that while in web development, interactive applications with complex jQuery is an exception, in iOS development, the emphasis was on interactivity and interactive applications were the norm.
 +
* We had to learn drawing of graphics, making objects translate, appear, change colors, control the state of various view elements... etc
 +
* We spend more time learning than implementing in the initial stages, therefore we would have been seen as "not delivering" in the early stages despite being in the process of rapid internalization of the development concepts and implementation methodology unique to mobile development and objective C. Unfortunately, our main KPI is on the amount of work produced, and sometimes that may not be an accurate indicator of the amount of work and preparation necessary to make it happen.
  
 
===Zhizhong Reflection:===
 
===Zhizhong Reflection:===
*Always be ready for changes and bugs because no application is perfect. There will always be room for improvements
+
We challenged ourselves by taking up a project with many uncertainties. For example, we had to learn a new language that little people can help us with and a topic we have no idea about. I have to admit that we failed several expectations and could have done better in many instances. However, what I have learnt from this project, is the importance of attitude. Obstacles and failures are just part and puzzle of life, but what keeps the team going, is the right attitude. It is the attitude to be positive, to be willing to learn and to put in your best that defines your experience. In terms of skills, I have surely learnt more about handling a full-fledged project. Everything we have learnt, from IDP, SE, PMSB, AA, are all put into use. In addition, I have also learnt to use new softwares like POP, iTunes Connect, xCode and Testflight. I have learnt to work with a team with different dynamics.<br>
*Though documenting is tedious, it is essential to ensure that the team stays on track and that functionalities are aligned with the client’s requirements
+
 
*Be critical and constructive. That is the only way to improve
+
In all, FYP was a challenge. It showed me the difficulty of creating something that looked so simple to me previously. Most importantly, it showed me that it is not about how hard you fall, but how fast you get back up.
 +
 
 +
==Sponsor's Comments==
 +
===Team===
 +
*Men who care ;)
 +
*Care to take time and understand things you didn't previously, such as the context of this app, the specifics in a women's cycle, building an iOS app, the business aspect etc. Care enough to make sure the team delivers and produce an app useful to us sponsor.
 +
*Care not just to make an impression but to deliver quality and professionalism in liaising with us.
 +
*And most importantly, care enough to initiate and take charge of the project as though the app is yours.
 +
 
 +
===Benefits of the Application===
 +
*MenstruTrack will help us in 2 main aspect. To keep connected and engaged with our current retail / online customers, and also to engage new / potential customers.
 +
*These will help to increase our bottom line as well as building up our brand in the feminine care space. Future plans will be to include analytics and more targeted recommendations for customers.
 +
*MenstruTrack can also be extended as an avenue for other consumer brands to reach out to ladies.
 +
 
 +
===The Application===
 +
*Due to Apple's strict curation process, the launch was slightly delayed, but overall, we are very satisfied with the outcome.
 +
 
 +
*The team was flexibility in tweaking requirements according to UT feedback, and also took much initiative to think through the functionalities and nitty gritty of how the app should function.
 +
 
 +
*From many feedback given, ladies like the look and feel of the app - that is the first battle won.

Latest revision as of 16:52, 21 April 2015

Phome.png Home Poverview.png Project Overview Pmanagement.png Project Management Pdoc.png Documentation Pteam.png The Team
Finals Wiki

Powerpoint Slides

Please find our Finals presentation slides here.

Project Progress Summary

Current Iteration: 10 (13/04/15 - 24/04/15)

  • Overall Project Progress: approx 95%
  • Currently performed 2 User Tests
  • Uploaded to the App Store!

Project Highlights:

User Test 2

Objectives
  • To compare the time users take carrying out the tasks, to the time of our experts
  • To identify tasks that take a significantly longer duration for users as compared to experts
  • To detect issues that users face in using our application
  • To learn more about the good and bad aspects of our application
  • To gather feedback regarding the usability of our application
  • To further improve our application based on the test results

Refer to User Test 2 in our wiki for more info.

Successful Upload to App Store

MenstruTrack is now in the App Store! Check it out Available-on-appstore.png

User Test 3

Description

Number of Users: 58 users
Gender: Female
Date: 11 to 16 Apr 2015
Duration: Over a period of 1 week, users will use MenstruTrack as a period tracker
Test Platform: iOS device with TestFlight application
Questionnaire Platform: Google Form

Objectives
  • To gather feedback from users using our application as their period tracker
  • To analyze user behavior and identify pages that users visit more
  • To gather issues that users may face

Refer to User Test 3 in our wiki for more info.

Difficulties Faced

  • Uploading our app the the Apple app store required our app to comply to many various rules. As a result, we failed on 3 attempts.
  • Duration of vetting by Apple takes approximately 1.5 weeks each time we uploaded our app to the app store.
  • Apple does not release its existing iCal app for open development purposes. Therefore we had to implement the calendar module from scratch.
  • User interaction controls (e.g. extendable period bars) are not standard UI controls in the Apple library. Therefore we had to build various UI controls from scratch that interact directly with the calendar.

Project Management

Project Scope

Final Scope.png

  • Due to the shortage of time, we were not able to implement the "good to have" portion of the scope
  • We have however, put in place some simple and basic google analytics for tracking purposes and as evidence of usage by users

Milestone schedule

MidTerms
Milestone Schedule v4.png
Finals
Milestone Schedule v6.png

Timelines

Planned
Planned Timeline.png

Actual
Actual Timeline.png

Project Schedule (Plan Vs Actual):

Iterations Planned Actual Comments
1 2 Sep 2014 - 3 Oct 2014 3 Sep 2014 - 9 Oct 2014 -
2 6 Oct 2014 - 5 Nov 2014 6 Oct 2014 - 5 Nov 2014 -
3 10 Nov 2014 - 5 Dec 2014 10 Nov 2014 - 5 Dec 2014 -
4 8 Dec 2014 - 9 Jan 2015 8 Dec 2014 - 11 Jan 2015 -
5 12 Jan 2015 - 23-Jan 2015 12 Jan 2015 - 13 Feb 2015 Delay due to complexity in building calendar module
6 26 Jan 2015 - 6 Feb 2015 26 Jan 2015 - 6 Feb 2015 Reduced scope for Profile development to focus on completing calendar
7 09 Feb 2015 - 20 Feb 2015 15 Jan 2015 - 22 Feb 2015 Used buffer time to catch up on functionality builds
8 23 Feb 2015 - 6 Mar 2015 23 Feb 2015 - 13 Mar 2015 Delay due to Calendar Module
9 9 Mar 2015 - 20 Mar 2015 13 Mar 2015 - 10 Apr 2015 Delay due to code clean up to ensure 0 crashes in order for successful upload to app store
10 Apr 2015 - Apr 2015 Apr 2015 - Apr 2015 -


Schedule Metrics

Schedule Metrics Iter10.png

Iteration 8:

  • Delay caused in finishing build of calendar in order to upload to app store
  • Delay due to rectifying changes from comments during Mid Terms, integration issues


Iteration 9:

  • Delays due to rectification of issues in order to achieved 0 crashes for upload to app store
  • Code clean-up to continue in iteration 10


Task Metrics

Task Metric Iter10.png

Lessons learnt from iteration 5 taught us not to under estimate coding tasks. This helped us better measure the time required by breaking down large programming tasks into smaller ones which are more manageable and predictable. Hence helping us reduce the fluctuations in the task metric measurements.

Planned vs Actual man hours.png

The Planned vs Actual Man hours depict the accuracy in allocation of time for individual tasks. Ever since iteration 5, programming tasks were better measured with lower variance. The only fluctuation that exists is in iteration 9. This is due to the fact that extra time and effort was used to rectify issues in order for our final push of the app to the app store. This took longer than planned, therefore a slight delay variation.

Bug Metrics

Bug Score Iter10.png Bug Score Iter10.png

  • No testing carried out in iteration 7 as there were no programming tasks
  • More critical bugs were found after integration resulting in app crashes

Project Risks

Top Risks new.png

Technical Complexity

Swift
Swift.png
Swift is a new language for building iOS applications. We chose to build in Swift to keep up with new trends. However, learning and developing in Swift pose a challenge due to the limited resources available.



Keyboard Algorithm
During the development process, we realised that at some of the views, the keyboard will cover some of the text entries. This will be especially true for iPhone 4S because of the different aspect ratio (iPhone 4S uses 3:2 while iPhone 5 onwards use 16:9). In order to mitigate this problem, instead of just removing the development entirely for iPhone 4S, we developed an algorithm to allow the top of the keyboard to reach the bottom of the text field.

The process in developing the algorithm:

  • Find the height of the screen.
  • As the keyboard is defaulted, there is no way to change the animation of the keyboard, as such, the only way is to shift the background.
  • As such, the amount to shift depends on a key ratio.
  • To calculate the key ratio, we have to conduct the following mathematical study of the different screen sizes

KeyBoardAlgo.png
To calculate the amount to be deferred, the universal formula that we derived is Screen Height/The y-coordinate of the active text field. After translating the algorithm to codes:
Keyboard algo.png


Period Forecast Algorithm

  • To forecast when is the next period, using the most recent period data will be most appropriate.
  • We used a simple weighted moving average formula to forecast the next period
  • The formula uses the 3 most recent period data, the most recent one has a weight of 0.7, second most recent one has a weight of 0.2 and the 3rd most recent one has a weight of 0.1
  • Our algorithm also removes all the outliers within the data. In this case, the outliers are cycle lengths which are <25 and >40

Forecast algo.png

Cycle Stage Algorithm

  • To know which cycle stage the user is currently in, we need a algorithm to be able to calculate. The algorithm is explained using the table below, accompanied by 2 scenarios

Cycle stage algo.JPG

Auto Layout feature

  • Designing for different screen sizes poses a great challenge to all mobile developers. In iOS, we are required to use the 'Auto Layout' feature which uses 'Constraints' to position the various elements to fit different screen sizes.
  • Unlike a web platform, we are unable to specify the height for a particular element to be for example 50% of the screen. Therefore, we need to create our own grid system, which is customized for different views of the application
  • To create a proper grid in a view, we have to use constraints to set it in the way we want it to be. After which we can then put in our elements.
  • The picture below shows a rough guide on how to define the grid, putting in the elements after that, as well as the constraints that we need to create in order to create the view.

Autolayout.png

Reflection

Team Reflection:

Building an iOS application with Swift was definitely a challenging task for the team, one in which we may have under estimated. Through this experience, we have seen in ourselves the ability to persevere, the aptitude for learning and the boldness to go against the conventional. Despite the initial setbacks and negative feedback, we remained determined to complete the application and to upload it onto the App Store. We chose to focus on what is good and work closely with those who supported us to have come this far. During this process, we had to constantly learn new skills beyond what the school has taught us such as the Swift language, usage of the xCode IDE, Apple's rules for uploading our application and the lady's menstrual cycles. We have come to realise that even something unconventional such as 5 guys building a female related application can be done because app development boils down to simply understanding processes, logic and algorithm which is something that can be achieved regardless of gender. In conclusion, we believe that tenacity, with a little luck, got our app accepted. A sleepless night of rectifying all issues for our final push has definitely paid off.


  • In order to fully understand the code and framework, the team took an entire winter break to learn more about Swift. Two of the more reliable sources that the team was studying from is provided by Stanford University and Apple's Developer Guide.

Gabriel Reflection:

  • Learned the importance of understanding technical tasks and planning according to its complexity
  • Have a better gauge of how long to plan for various activities for a more accurate schedule
  • Had a first hand experience of the effectiveness of managing stakeholder and changes through formal means

Teng Yu Reflection:

We started something bigger than all of us. we have to finish it.
Initially when the team was formed, both internal and external expectations were very high as everyone see us as a strong and well-balanced team. Maybe it is because of this, we went ahead and challenged ourselves. As we venture further into the project, we realised that the mountain top seems further away instead of getting nearer. The climb was treacherous and mid-way, during our Mid Terms Presentation, we took a tumble and reality struck; that maybe we could never accomplish what we promised. It was demoralising but like a slap to our faces, we realised the severity of the situation. Instead of turning around and giving up, we pulled each other along and climbed together. Whenever someone faces a difficulty, we reallocated our personal time to help him to along; it was never about me, it is always about us. Throughout this journey, without the support of various stakeholders such as our supervisor, sponsors and professors, we could still be at the mid-way of the mountain. As we celebrate the success of reaching the top, one key reflection that I learn is "Nothing is impossible, it is just whether you want to do it". With the right mentality and perseverance, I am glad that my team has delivered our promises to our sponsors, supervisors and professors.

Terence Reflection:

  • In a project with a huge scope such as IS480, it is equally important to pay attention to the larger picture such as project management on top of the smaller tasks. For example, the goal of our project, what we plan to achieve, what is the value that we are providing to the users as well as the client, and not to forgot the plan that will make all these work out. In the previous modules that i have taken such as Software Engineering, the project was already properly scoped for us and we do not need to think about things like goals and accomplishments. However for IS480, it is different.
  • In this project, I have to learn about mobile application development with a new language ‘Swift’ from scratch. Previously I had only experience with web development. As such, building a mobile application in a new language really put a test to my abilities for this project.
  • Designing an iOS app possess a different challenge compared to a web application. In particular, designing for different screen sizes and managing the huge amount of interactions between the user and the application. This is a huge different compared to web development that i am more familiar with.
  • Gained ‘Learning to Learn’ skills. In the field that we are in, there are always frequent updates and emerging technologies. We need to constantly upgrade ourselves and learn new skills. Thus, learning to learn skills is crucial to be able to adapt to changes.
  • It is also important to look at the entire process/journey of IS480. I have overcame many obstacles and grew from the first day i took up this project till now. It serves as a very good learning point for future projects that i am going to take up.

Zachery Reflection:

  • Unless you have many years and experience specializing in the particular development language and framework used for the project. It is impossible to plan the time required for programming task since the amount of code and the implementation steps are unclear.
  • In order to make my estimations more accurate for the PM, I'll have to identify the implementation steps first (which means running through in my mind the HOW of building a function and module with the use of WHAT classes.) This is difficult early on, as we are unfamiliar with the technology, and should have done the research first before estimating tasks. However in this case, research does takes up time as well, and therefore we will always have to accept a task with a level of uncertainty resulting in an inaccurate estimate on time required.
  • Many of the functions, and UI seemed implementable in concept, and we assumed that many of the operations and libraries will be available for us to use. However, we soon realize that while in web development, interactive applications with complex jQuery is an exception, in iOS development, the emphasis was on interactivity and interactive applications were the norm.
  • We had to learn drawing of graphics, making objects translate, appear, change colors, control the state of various view elements... etc
  • We spend more time learning than implementing in the initial stages, therefore we would have been seen as "not delivering" in the early stages despite being in the process of rapid internalization of the development concepts and implementation methodology unique to mobile development and objective C. Unfortunately, our main KPI is on the amount of work produced, and sometimes that may not be an accurate indicator of the amount of work and preparation necessary to make it happen.

Zhizhong Reflection:

We challenged ourselves by taking up a project with many uncertainties. For example, we had to learn a new language that little people can help us with and a topic we have no idea about. I have to admit that we failed several expectations and could have done better in many instances. However, what I have learnt from this project, is the importance of attitude. Obstacles and failures are just part and puzzle of life, but what keeps the team going, is the right attitude. It is the attitude to be positive, to be willing to learn and to put in your best that defines your experience. In terms of skills, I have surely learnt more about handling a full-fledged project. Everything we have learnt, from IDP, SE, PMSB, AA, are all put into use. In addition, I have also learnt to use new softwares like POP, iTunes Connect, xCode and Testflight. I have learnt to work with a team with different dynamics.

In all, FYP was a challenge. It showed me the difficulty of creating something that looked so simple to me previously. Most importantly, it showed me that it is not about how hard you fall, but how fast you get back up.

Sponsor's Comments

Team

  • Men who care ;)
  • Care to take time and understand things you didn't previously, such as the context of this app, the specifics in a women's cycle, building an iOS app, the business aspect etc. Care enough to make sure the team delivers and produce an app useful to us sponsor.
  • Care not just to make an impression but to deliver quality and professionalism in liaising with us.
  • And most importantly, care enough to initiate and take charge of the project as though the app is yours.

Benefits of the Application

  • MenstruTrack will help us in 2 main aspect. To keep connected and engaged with our current retail / online customers, and also to engage new / potential customers.
  • These will help to increase our bottom line as well as building up our brand in the feminine care space. Future plans will be to include analytics and more targeted recommendations for customers.
  • MenstruTrack can also be extended as an avenue for other consumer brands to reach out to ladies.

The Application

  • Due to Apple's strict curation process, the launch was slightly delayed, but overall, we are very satisfied with the outcome.
  • The team was flexibility in tweaking requirements according to UT feedback, and also took much initiative to think through the functionalities and nitty gritty of how the app should function.
  • From many feedback given, ladies like the look and feel of the app - that is the first battle won.