IS480 Team wiki: 2012T1 Team Sageby Final Wiki
Thanks for visiting Team Sageby's Wiki Page!
Our iOS Application, Sageby Surveys, allows users to do surveys, earn credits and exchange for vouchers, all in one single iPhone!
||||PRODUCT OVERVIEW|||||PROJECT MANAGEMENT|||||USER TEST|||||LEARNING OUTCOMES|
- 1 Project Progress Summary
- 2 Project Management
- 3 Quality of product
- 3.1 Quality
- 3.2 Deployment:
- 3.3 Testing
- 3.4 Analysis
- 3.4.1 What are the main To-Do changes
- 3.4.2 What we did badly
- 3.4.3 What we did well
- 3.4.4 Unit Testing
- 3.4.5 Test Cases
- 3.5 Project Deliverables:
- 4 Reflection
Project Progress Summary
Since our Midterm presentation in 1st October, we have realigned developmental focal point strictly on the usability of our application. Professor Archan gave an extremely useful tip: "It is all these little things that makes up the last 5% of your application". We felt that Prof Archan was hinting that the application was well on its way to accomplishment, but was still lacking in terms of refining the user experience.
Following our initial developmental methodolgy, Build | Measure | Learn, we manage to smooth out kinks and re-engineer the way how Sageby Surveys displays information.
|1||Handling Excessive Low Severity Bugs|
Soon after mid-terms, we realized that as Sageby Surveys is continually being built, the amount of bugs were increasing and this became a serious issue when the application did not manage to work smoothly just right before User Test 4. Development of customized views became buggy and development of the application was impacted. Hence, we implemented a hybrid debugging system which includes fixing a specific debugging period (current model) and pushing low severity yet heuristically important bugs to be fixed within the next iteration, which reduces risk of task overload within the next iteration. This bug-fixing model is extremely efficient with our lean development as bug-fixing effort varies between iterations.
Through this initiative, we managed to clear out all identified bugs and deliver an highly refined application for User Acceptance Test (Final UT).
Upon successful construction of the application, we realized that delivering a complete set of functionalities was far below the scale as compared to delivering an app that was interesting, visually appealing, and bug free application. Hence, this lead to a conclusion that users are experiencing a phenomenon called "Perceived Intuitiveness & Efficiency" of the application. We looked into several ways to improve usability and came up with 2 solutions, one to improve loading speed and another to improve learnability.
|1||Sageby Lead Developer Left|
Construction of the Application Programming Interface (API) on Sageby's servers was stopped and could not provide the mobile application with dynamic data from Sageby's datebase.
Marcus had to drop his initial task, Performance Profiling and Core Data, and take on the role of building APIs.
|2||Lazy Loading & Pull-Down-to-Refresh|
Before our Final User Test, we identified the common scenario that users were unsatisfied with, Rewards and Survey's list loading. This was due to the rendering time of iOS with images for the table cells. Hence, instead of removing images, we decided to implement a different way of loading the table cells. Lazy Loading helps to load cells with text first, and then replaces the images once its finish rendering. Also, instead of refreshing the list every time the view is loaded, we implemented Pull-Down-To-Refresh to allow users to refresh the table only when they want to. This improved table loading timings up to 100 times faster and greatly improved the application ability to display much more surveys and rewards efficiently.
After our User Test 4, our application was nearly boasting all functionalities that we had planned for. However, this increased the complexity of the application and led to lower satisfaction level of users. Although a relatively high percentage of users (>63%) were satisfied with each different module of the application, we wanted to raise the population of satisfied users to 90%.
Hence we introduced a walkthrough page that will be shown during the initial startup of the application. Users are excited and motivated to use the application when the walkthrough appeared, aiding them in understanding the application, especially for new users. Users had a much higher satisfaction level, increase from 60% to 90%, which was partly contributed by the walkthrough, and overall improve user's receptiveness towards our application.
|1||5 Extensive User Tests|
Before midterm, We held numerous user tests and there were more complains than positive remarks. These lead us to think, why did a full fledge application not score well with the users. We then realized that it is due to the finer details that are lacking, causing displeasure in using the application. After User Test 4, we felt that we really have to implement "Lazy Loading" (efficiency in loading pages) and walkthrough pages (improve learnability). These are non-functional modules that we had originally considered but were abandoned due to lack of foresight for long load-time of lists. In bid to perfect the application, we used 2 more of our buffer days (1 week) and built our walkthrough pages, along with Lazy Loading and Pull-Down-to-Refresh for rewards and survey's list.
Our Final User Test was a User Acceptance Test for our Sponsors, Sageby Pte Ltd. They put the application through their own testings for both APIs and Sageby Surveys itself. Our sponsors are extremely satisfied with the application being full fledge and is ready to be launched officially. Also, they are further convinced when a huge percentage of our 40 users for Final UT felt that Sageby Surveys is highly enjoyable to use and had many amazing functions to go along with it.
Overall, thanks to the laborious and tiring 5 User Tests, we managed to exercise team's belief, "Build-Measure-Learn", to a great extent, bringing constant improvements to the application from continued user feedbacks and learning sessions. The final product is our sweat and soul, Sageby Survyeys.
Project Timeline With Scope
- All Functionalities (including additional functionalities) that we have planned for are completed and deployed.
- Application is now deployed on Appstore version 1.3
- Successfully conducted our Final UT5, a User Acceptance Test for our Sponsors
- Sponsors accepted the application and handed-over after reviewing the application and receiving many positive feedbacks from the users
|Task/function/features, etc||Status||Confidence Level||Comment|
|Login Module||Fully deployed and tested 100%. However, it is not updated to latest Facebook SDK due to lack of backward compatibility with iOS 5||1||Luojia|
|Survey Module||Fully deployed and tested 100%, with categorization via alphabetical order||1||Luojia|
|Rewards Module (Store)||Fully deployed and tested 100%||1||Luojia|
|Rewards Module (Wallet)||Fully deployed and tested 100%, with categorization via used & unused sections||1||Luojia|
|Settings Tab||Fully deployed and tested 100%||1||JunHao & Mervyn|
|Social Sharing Module||Fully deployed and tested 100%||1||TeeJun|
|Feedback Channel||Fully deployed and tested 100%. Used Apptentive Package for feedbacks and easy rating portal.||1||Junhao|
|Performance Profiling & Memory Leak Tests||Function to be Kept in View. To be continued if necessary.||1||Marcus|
|Application Programming Interface||Partially developed, deployed and tested 50%. Survey, Users and Rewards Module completed||1||Marcus|
|Database Transition from Development to Live||Fully deployed and tested 100%||1||Marcus|
|Unit Tests||Partially developed, deployed and tested 50%. Login, Surveys, Rewards, User Module & Settings tab covered||0.5||JunHao|
|Facebook Sharing UIView||Partially developed, deployed and tested 50%.||1||Mervyn|
|Mobile Template for Lime Survey||Fully deployed and tested 100%||1||Mervyn & Junhao|
|Social Integration||Fully deployed and tested 100%. Twitter integration and Facebook Login||0.9||Luojia & Teejun|
|Application for All Modules||Fully deployed and tested 100%.||1.0||Marcus & Luojia|
|Transition from iOS5 to iOS6 with versioning identification||Fully deployed and tested 100%. Devices with iOS5 will not invoke iOS6 specific methods.||1.0||Luojia|
|User Notifications||Fully deployed and tested 100%. Comes with a Slider(left) single finger motion||1.0||Mervyn|
|Geo-fencing Notification||Fully deployed and tested 100%. Vendors are currently set to a radius of 25 metres||1.0||Junhao|
|Creation of a Map based View for merchants||Fully deployed and tested 100%.||1.0||Junhao|
|Implement Lazy Loading for rewards & survey's list||Fully deployed and tested 100%.||1.0||Mervyn|
|Walkthrough Pages (4 different pages in total)||Fully deployed and tested 100%.||1.0||Mervyn|
|Pull-Down-to-Refresh||Fully deployed and tested 100%.||1.0||Junhao|
Project Schedule (Plan VS Actual)
Despite having several additions in our project scope, we managed to narrow down the non-functional requirements of the applications and added an extra week in Iteration 4 to accomodate our User Tests.
|1||Complete Paper Prototype for client's acceptance||30/5/12||5/6/12||30/5/12||5/6/12|
|Develop sample iOS App||6/6/12||13/6/12||6/6/12||13/6/12|
|Complete Prototype with Survey Module||14/6/12||27/6/12||14/6/12||27/6/12|
|2||Build Facebook Single Sign On Auth||27/6/12||3/7/12||27/6/12||3/7/12|
|Build Sageby Manual login||3/7/12||11/7/12||3/7/12||11/7/12|
|Allow user to logout||3/7/12||11/7/12||3/7/12||11/7/12|
|Build User details popup||11/7/12||17/7/12||11/7/12||17/7/12|
|Build different in-house survey layouts. Allow survey question to have dynamic survey layout||17/7/12||25/7/12||17/7/12||25/7/12|
|Able to pull dummy data from Sageby's server||17/7/12||25/7/12||17/7/12||25/7/12|
|Build survey's question routing function||17/7/12||25/7/12||17/7/12||25/7/12|
|Deploy and upload to Apple's Appstore||31/7/12||31/7/12||31/7/12||3/8/12||Code-signing error and outdated library links led to 3 days delay in deployment|
|3||Build browsable table for Store vouchers||1/8/12||8/8/12||1/8/12||8/8/12|
|Allow users to redeem vouchers||1/8/12||8/8/12||1/8/12||8/8/12|
|Build browsable table for Wallet vouchers||8/8/12||15/8/12||8/8/12||15/8/12|
|Build QR generator||8/8/12||15/8/12||8/8/12||15/8/12|
|Deployment on Appstore||21/8/12||21/8/12||8/9/12||8/9/12||Pushed to Iteration 3 due to the lack of APIs|
|4||User is able to share completed surveys via Facebook share and Twitter||22/8/12||29/8/12||22/8/12||29/8/12|
|Users will be able to provide feedbacks to Sageby Surveys||22/8/12||29/8/12||22/8/12||29/8/12|
|User is able to share referral link for benefits||22/8/12||28/8/12||22/8/12||28/8/12|
|Build iFrame to support Lime survey||29/8/12||4/9/12||29/8/12||4/9/12||Added an Extra week to support external survey engine|
|Build iFrame to support Lime survey (Added)||29/8/12||4/9/12||29/8/12||4/9/12||Needed to support external survey engine for live testing(UT3)|
|Built User & Survey Module's APIs (Added)||5/9/12||11/9/12||5/9/12||11/9/12||Added an Extra week to build APIs to receive dynamic data and prepare for live testing (UT3)|
|Transitioned from iOS5 to iOS6 (Added)||12/9/12||18/9/12||12/9/12||18/9/12||Added an Extra week to transition from iOS5 to iOS6 in order to update deprecated APIs and to support application on iPhone 5|
|Transitioned from Development Database to Live Database (Added)||12/9/12||18/9/12||12/9/12||18/9/12||User will be able to register with Sageby and do real surveys.|
|Deploy to Appstore||25/9/12||25/9/12||30/9/12||30/9/12||Delayed by 5 days due to rejection from Appstore for several unsupported APIs|
|5||Populates different price button according to number of prices available for redemption||1/10/12||6/10/12||1/10/12||11/10/12||There was unexpected difficulty in implementing customized logic for buttons. A logic bug was found on 6th of October and functionality was delayed by 5 days|
|Implement User Notifications that includes Slider(left) to activate||26/9/12||19/10/12||26/9/12||19/10/12|
|Implement & Integrate APIs for dynamic data||26/9/12||23/10/12||26/9/12||23/10/12|
|Implement Geo-fencing Notifications||3/10/12||11/10/12||3/10/12||11/10/12|
|6||Create a Map-based view for Redemption tab||24/10/12||28/10/12||24/10/12||28/10/12|
|Implement & Integrate API for Geo-fencing Module||24/10/12||2/11/12||24/10/12||2/11/12|
|Implement Lazy Loading Pull-Down-to-Refresh for all tabs||3/11/12||6/11/12||3/11/12||9/11/12||Lazy-Loading and Pull-Down-to-Refresh was tougher then expected due to the reconstruction of how table cells had to be populated. Extended by 3 days.|
|Develop & Implement Walkthrough Pages||8/11/12||15/11/12||10/11/12||15/11/12||Walkthrough pages was implemented by 2 as there was bug fixing on-going and bug-fixing took longer then expected.|
For more details on the project management schedule, please check out our Project Management Wiki page at Sageby Schedule Metric!
We have chosen Schedule Metric and Bug Metric as it best suits a development for iOS due to expected rapid changes in schedule and unforeseen bugginess of a mobile app.
The schedule metric has been highly useful for us by providing us with an better grasp of our current situation and to track the amount of time we took with difficult tasks. Project Manager was also able to efficient allocate extra time and also to meet up with changing demands and opportunities.
Overall, the team felt that tasks were well planned and user tests were held at effective timings with sufficient bug-fixing durations. Complexity of modules are also well understood, which led to an improving trend in project management metric.
We needed the Bug Metric to answer 3 important questions during development:
- Where did it originate from
- Impact of the bug
- How many are there
With the aid of the Bug Metric, we managed to identify key issues, which includes Facebook Login and sharing and persistent UI Bugs. Coding in Storyboard with Objective-C bypasses the conventional coding of transitions of Views in iOS. This is a huge improvement in convenience for new developers such as us, but when bugs arises, we need to identify the location of it and to rectify the issue by diving into the source codes and make manual changes.
After our Mid-terms, we realized that the severity of bugs could be low but might take long hours of bug-fixing due to its complexity. Given the different amount of bug-fixing effort required per iteration, 1 week is definitely sufficient for fixing all major bugs but might not be able to fix all low severity bugs. Hence we have adopted a hybrid bug-fixing system that schedules the fixing of remaining bugs in the next iteration. This ensures that most bugs can be fixed before the next iteration's User Testing.
Overall, we managed to clear all identified bugs and our sponsors are pleased with the quality of the application
Technical Complexity takes into consideration of Team Sageby's main development pain points. Although there are other complexities such as Facebook login SDK issues and iOS 6 with backwards compatibility, these issues can be temporarily kept in view due to the immaturity of the SDK and platforms.
|Task||Description||% of Self-Written Codes|
|Construction of Application Programming Interface||This API construction is extremely important to the success of the application. However, we have several considerations during the building of APIs.
|Building Different Survey Layouts||Surveys are split into 2 categories, In-house survey & Limesurvey(external). These survey templates are extremely important in ensuring that users enjoys doing surveys on a small mobile screen.
There are 5 current types of survey layouts that our team has researched to be the most used survey layouts which includes Checkbox, Radio box, Rating, Free text & Arrangeable boxes.
However there are several considerations to building it. There are no existing templates provided by iOS. Hence we need to customize "Survey Views" that follows the same logic as a multiple choice question, single choice question & arrangeable tables.
LimeSurvey is widely used by Sageby Pte Ltd as it provides powerful analytical tools and a wider array of survey templates. However, LimeSurvey is an external engine and it will be better to develop their in-house survey for the long run.
Also, LimeSurvey has its own share of technical complexities. The web templates that are built by LimeSurvey are meant for Web usage and we did not want to pay external vendors for their standard looking mobile templates. Hence we decided to build our own customized templates through the usage of HTML6's features to resize to mobile resolution/screen size. This was extremely tough as LimeSurvey's templating structure involve several pstl files and CSS files that had to be trial and tested on how the files work together.
|Compatibility with both iOS5 & iOS6||Compatibility with both iOS 5&6 versions had to be stretched across 2 different categories, versioning issues and screen sizing issues.
Screen Size iPhone 4S and older versions uses a 3.5-inch screen and iPhone 5 uses a 4-inch screen. This causes older applications that are not properly configured to have its layout rendered wrongly. We had to resize all images, clear out and replace all old methods for positioning the layout of the buttons, images and text-boxes. This was extremely tough for us as there were many customized views and layouts and we had to source for new methods to customize layouts for the 4-inch screens.
iOS5 & iOS 6' In iOS 6, there were several deprecated APIs that we could not use and we had to adopt the newer APIs. Also, we had to provide backward's compatibility for iOS 5 for the Geo-fencing module as Apple decided to change their maps to an iOS in-house map system. This results in different MapKit APIs for different mapping providers. We started coding and building the application to suit 2 different versions and this took up more time and effort in perfecting the application.
|Reusable Profile Views||In the initial design of the storyboard, profile view was individually created as part of the storyboard. The profile view fetches the user’s Facebook photo, name and also Sageby’s credits. However after a redesign of the application, there was a need to place profile view in 3 other pages. Instead of creating another 3 profile view to be placed it into the storyboard, we decided to create an object for the profile view where the object can be called. Our efforts paid off and it worked well. Once the user clicks on the profile view button, the object will be called and displayed on the view.||80|
Quality of product
|Application Efficiency Improvements||iOS's standard generation of table and cells does not include any customizations. In our application, the table cells are highly customized, showing data from numerous API calls and even rendering images. However, this greatly slows down the application to the extend of diminishing user satisfaction due to the increased delay time.
A solution that we have sourced online was to improve on how the table cells are generated and rendered. Instead of removing images, we decided to implement a different way of loading the table cells. Lazy Loading helps to load cells with text first, and then replaces the images once its finish rendering. This improved timings up to 100 times faster and greatly increased the application to display much more surveys and rewards efficiently.
|Dynamic Data||Sageby Surveys is built with the intention to be a full fledge product, and hence it is necessary to build the API to support dynamic data. These APIs provides the application with data from Sageby Pte Ltd's database which includes real surveys and rewards used on the web portal.
|Intuitive Layout with Easy to Understand Process Flow||
Sageby Surveys is an iOS application that is supported on both iOS5 and iOS6, and on both iPhone 4 and iPhone 5. Sageby Surveys is currently deployed on AppStore.
This is the link for AppStore download:Surveys AppStore Download
And these are several images that are previews for the application.
Application Programming Interface is current deployed on:
- Sageby's Live Server with Live database, www.sageby.com, as Version 1.2 for AppStore's Sageby Surveys
- Sageby's Development Server with demo database, dev.sageby.com, as Version 1.3 for development device
Final User Test (UT5)
The main objectives of this this final UT are to test for all functionalities.
This include new functionalities:
- User Notification
- Geo Mapping
To prove that our application is:
C. Visual- Appealing
From our previous User Test 4, we will test the additional implementations:
A. Walkthrough Page
B. Lazy Loading
D. Heuristic Changes
UT 5 Schedule
Altogether, there are 32 responses. To have a better gauge of user learnability curve with the application, the user test has an equal proportion of new and past users.
To understand user lifestyle usage, 55% were iPhone user while 39% were Android user. The remaining 6% were blackberry and other OS users.
-Simulated different stages of the process flow
1). Awareness Booth
2). Waiting/ Queue Booth
3). Redemption Booth
- Gave a set of goals for user to complete
User Behaviour Observation
- Facial Expression, body language
User Feedback Survey
In- House Survey Template
Issues faced by Users:
1). User accidentally exit while doing a survey
2). Users is able to submit blank answer for compulsory question
3). User want to know their cumulative amount after completion of a survey
88% would like to be notified by Geo-fencing Notifications
Issues faced by Users:
1). User feel that something can be shown instead of a blank page when there are no notification.
82% find the map intuitive to you while the remaining 18% gave a neutral stand.
Issues faced by Users:
1).User is unable to identify the distance from current location to target venue
79% find the walkthrough feature helpful while the remaining 21% gave a neutral stand.
1).63% of the user gave a 80% satisfaction level for User Test 4.
2). 94% of the user gave a 80% satisfaction level for Final User Test. There's a increment of 27% in satisfaction level.
What are the main To-Do changes
- Exit Pop-up for Internal Survey
- Warning message for empty response
- Display total credits when survey is done
- Revamp the Purchase Success Page
- Display a 'No Notification' message when it is empty
-Display distance of user current location from target venue
- Inclusive of Walkthrough Tab at Setting Page
What we did badly
Overall, the Final UT execution was executed with no major issues. There was no shortage of equipment or application failure.
What we did well
Proper instructions were given from the Testers to the Testees. All equipment’s are working fine. There were minimal waiting times. We met our daily target for users.
Overall, the Final UT execution was executed with no major issues. There was no shortage of equipment or application failure. Some of the feedbacks have been extremely useful for the team final development and client.
In addition, proper strategies were in place to make sure users can go through a simulated environment, to gather feedbacks about the whole work flow.
Unit testing is a standard technique in computer programming whereby we break the software into small, independent pieces of code (a.k.a. the unit), isolate it from the rest of the code and test it. The main goal of unit testing is to try and find as many bugs as possible, as soon as possible.
Unit tests are split into two categories, Logic and Application Unit Tests.
Logic Unit Testing
Logic unit testing concerns the testing of the classes logic directly. You only test the logic of the methods, you don't interact with user interface elements or simulate them. For example, testing that a coordinate convertor utility is returning correct values is logic unit testing.
Percentage of Testing
- Verification of Credentials for manual login
- Test for verification of specific survey styles such as checkbox, radio buttons, etc.
- Test for mock data verification
Overall Percentage of logic tests : 50%
Application Unit Testing
Application testing in iOS is much more specific to applications with user interface. In application testing, you will check that clicking a certain button triggers the correct behavior, that a view loads correctly, and so on.
Percentage of Testing
- Landing page verification
- Survey, Rewards and Settings tab verification
- Survey details view and start button verification
- "About" button in settings tab verification
- "Share" button in settings tab verification
- "Logout" button in settings tab verification
Overall Percentage of Logic Tests : 70%
Test Case is a set of conditions or variables under which a we will determine whether an application or software system is working correctly or not. We have up to 50 steps for our Test Case version 3
Percentage of Testing
Covered Areas: All functional module
Overall Percentage of Test Case: 100%
|Project Management||Meeting Minutes||Team meetings: Minutes 1-11|
|Supervisor: Minutes 1-9|
|Project Schedule Planning||Project Schedule: Project Schedule|
|Metric||Bug Metric: Bug Metric|
|Schedule Metric: Schedule Metric|
|Requirements||Final Presentation||Final Presentation Slides|
|Analysis||Use case||Use Case Diagram & Documentation|
|Functionality List||Functionality List|
|Design||Architecture System Diagram||System Architecture|
|Low Level Architecture System Diagram||Low Level System Architecture|
|Application Programming System Design||Application Programming Interface|
|Domain Diagram||Domain Diagram|
|Mockup Designs||Mockup Designs|
|User Test Documents||UT 1|
Six days a week, five hours a day, every awakening day in our life for the past six months.
To create Sageby Surveys was an uphill task for us. With a five man team and no prior experience with Objective C or iPhone programming; we were tracking on unknown ground. However we marched on with positivity wanting to take away something from FYP instead of just doing another mainstream project.
It’s all began when we first sat down on a proper meeting to decide on what we want to achieve and selecting from the long list of sponsors. Are we able to manage the project? Do we want to push our limits together? There are some of the recurring factors that came to our mind while deciding on the project that we want to undertake. Ultimately, we decided to work with Sageby Pte Ltd because we find the business project meaningful, stimulating and fun! Our summer was all about technical familiarisation, managing client’s scopes while juggling our internship at the same time! Beside the steep learning curve from a new programming language, it was not easy to even display a simple “Hello World” on a mobile phone.
Our team took the project seriously and work on two user tests even before the Acceptance. We called it Prototype Testing because we really want to be sure that we are building a product that users really want. This is part of Lean Development which our team adopted. After our acceptance, our team re- allocated resources to capitalise on each individual’s strengths. We became more efficient and are constantly able to meet our work schedule. We have a tight working relation with the Sponsor’s technical team.
Every project has its own set of limitations, challenges and trade-offs. From overcoming coding difficulties to meeting our iteration goals, we have to constantly manage our supervisor and client’s expectations without short-changing our deliverables. When the client’s technical in-charge left the company, we faced the issue of implementing an app without firm back-end support. Marcus, our team Database Manager, took over the wheel and work on the API and database structure. In a blink of an eye, we were managing scopes out outside our initial deliverables. Mid Term Presentation gave the team a better reflection of our team’s capabilities and shortcomings. We managed to deploy our App to Appstore three times, earned a respectable amount of monetary incentives for our client via our App platform and achieved a modest number of application downloads. Our motivation to excel grows as Final Presentation draws nearer.
Friendships are forged when we overcame our challenges together. Every project success is always a team effort.
Just to share a quote, “Life isn’t about learning how to weather the storm. It’s about learning how to dance in the rain.”
Peh Jun Hao
Managing expectations, deliverables and scheduling, these are the concerns that keeps popping in my head over these past few months. Assuming the role of a Project Manager has far exceeded my imagination. From planning out the team milestones and deliverable to coding some of the functionalities, I have to actively manage and keep track about team's development ensuring that they themselves learn from the development of Objective-C, learn about carry out User Tests and improving. There are just so many things to learn, and so much that the team can learn only by being together as a team.
From managing and implementing the database for the application to constructing the Application Programming Interface (API), this project has really stretched the limit of my abilities. Having the need to work closely with the client’s server, it’s a common sight to see me working at our client’s office on a normal working day. People call me brother-bear, but my sponsors call me the helpful-bear and it really makes my day knowing that my work benefits everyone!
Being the only girl in this male-dominant team, having the post of a lead developer is definitely not a walk in the park. The most awkward scenario is when Junhao introduces me as the lead developer and people give weird stares): Besides delivering and ensuring good quality codes, I have to aid the team members when it comes to coding issues and I am really glad that my team respects my every decision, even when its not reasonable. I am just glad that I managed to fit in well with my team and made it till the end together! (:
Looking back, continually improving the design and heuristic played a major role in our user experience. Through the numerous rounds of feedbacks, improving the design is an on-going process due to technology changes and the evolving needs of our users. To date, I am glad that this project gave me the platform to create relevant and attractive designs which meet the modest goal of our application- Simple, intuitive and easy-to- use, and of course, constantly getting ever-changing design naggings from the team.
Foo Tee Jun
What, 5 user tests?! That was my first thought after the team concluded with a lean development of continuous measure and learning. The biggest challenge that I faced as the quality assurance manager is actively seek for efficient ways to improve our application at all time. Not limited to design layouts and user experience, the focus is on pushing the app usefulness beyond its expected level. What keep me going? It’s the smiles and contentment shown from our users’ face.
- Team has the necessary technically competency. This is their first iOs application and they have produced an exceptional application for Sageby which we will be using launching very soon next month.
- Their working styles compliment each other and is well demonstrated by how they have sub teams working in parallel to complete tasks for each of their 5 user testings.
- Their designing skills compliments Sageby’s designs. Feedback from real users also mentioned that the design is efficiently designed around the core features of Sageby that.
- The team manage improve and bring forth our slogan, “Pay Using Waiting Time” to realization. A huge amount of users are also exposed to Sageby via the mobile platform and this is shown by the large increase in signups using the mobile APIs
- The team is also excellent at handling obstacles such as server down,s webhost down, dev server down and changes in requirements such as the addition of APIs as their job-scopes.
- Lastly, the team managed to push the application to the AppStore with 4 versions, showing the application’s quality built and pushing the application to more users.