IS480 Team wiki: 2012T2 Viaxeiros Mid Terms

Welcome to Viaxeiros FYP Wiki Page

Mid Term Slides

Project Progress Summary

Progress Currently, Viaxeiros in in their Iteration 9 on 26 February 2013, and in the midst of meeting the upcoming milestone, which is the Midterms presentation, at 26 February 2013. Currently, since the Acceptance Presentation which is at 5 November 2013, The following main features have been completed: Native pages for travelogue and places Download of travelogue for offline usage Camera functions in the application Online and offline map display Improvement of performance and memory issues Based on the current status of the project, our team has decided to focus only on one of the additional functions proposed in the Acceptance Presentation, which is the Augmented Reality.

Project Highlights Iterations Descriptions / Highlights 2 Major Delay in Offline map Prior to the actual start of the coding phase, it has been decided that the offline map feature is going to take much more time than that of other functions as many of us are unknown to any available map technology, let alone one catered to offline usage. Thus, we have planned to start this function early, hoping to overcome the steeper learning curve earlier in the project. Our worries turn out to be correct, where our research in Iteration 1 shows that offline map is much more complex than what we assumed to be. Judging from this, we have made an appropriate change in our schedule, thus assigning a longer time for the creating of the offline map. 4 Increasing Scope to be done During Iteration 4, in one of the client's meeting, we have come to a conclusion with our sponsor that there should be a change in the requirements of the application. In view of the need to provide a more holistic feel of the application and to cater more wholesomely for the offline purposes, the clients and us decided to include the viewing of travelogues, places as well as the listing of travelogues to be native pages. This has in turn result in a major change in the schedule as some of the functions such as the search will be pushed to the later part of the schedule. In addition, our group has also discussed among ourselves and feel that one of the additional functions might have to be dropped as there is a high chance that this change in requirement will increase the time needed to complete this requirement. 7 Change in focus for additional functionality After the discussion with our clients, we feel that focusing on the Augmented Reality might suit the business model of the company better than that of the smart itinerary. This is because the smart itinerary creates a more "gamey" feel, which might contradict in the overall experience of the application. In addition, the smart itinerary might prove to be more troublesome for users as users can only accept the entire travelogue and are unable to edit much of it. Augmented Reality, in the other hand, provides users with an alternate view of the same data, which allows users to explore their surrounding in a more interesting manner. Thus, with these considerations in mind, our team has decided to focus our research on the implementation of augmented reality in the upcoming iterations.

Project Management

Project Status Modules Status Confidence Level (0 - 1) Members in charge Creating mobile web view 100% developed and deployed 1 Sing Lim Login function 100% developed and deployed 1 Melissa Native travelogue and places 100% developed and deployed 1 Sing Lim and Zi Jun Camera function 100% developed and deployed 0.9 Sing Lim Online and Offline Map 100% developed and deployed 0.9 Yu Kai Adding of places 100% developed and deployed 1 Sing Lim and Melissa Search function 100% developed and deployed 1 Sing Lim Like / Share to be developed 0.8 to be allocated Augmented Reality to be developed 0.8 to be allocated

Project Schedule (Plan Vs Actual) Planned Actual Key Changes Include functions for creation of travelogue Focus on Augmented Reality instead of Smart Itinerary For more information on the schedule of our application, please click here.

Project Metrics Schedule Metric The following shows the summary of our schedule metric thus far: Please refer to our Schedule metric calculation here. Highlights In general, there is a delay in Iteration 3. This is due to having examinations during that period of time. Thus, despite the relatively less functions during that period of time, there is a slight delay in completing the schedule. Due to this, we have decided to increase the time period for the next iteration and also to allocate more tasks to be done then. Links: Current schedule metric Schedule Breakdown Bug Metric Total Bug Count: Please refer to our bug metric calculation here. Highlights There is a spike in bug metrics during iteration 5 due to the coding sessions in iteration 4 as well as after our first user testing. In order to reduce the bug points, we have stopped coding out functions and focus instead on solving the current bugs that we have. Similarly for iteration 7, in order to solve the bugs found, more time has been allocated in iteration 8 to solve the bugs. Links Current bug metric Work Stress Metric Please refer to our work stress calculation here. Highlights In iteration 4, 2 of our team members have many tasks on hand as compared to other team members. Using this metric as a reference as well as the actual schedule breakdown, we have decided to allocated less tasks for the members in the next iteration and more tasks for the other members. Links [Work Stress metric]

Project Risks The following shows the top 3 list of risks that our team is currently facing. For more information of the other risks, please visit here: S/N Risk Description Consequences Impact Likelihood Risk Rate Mitigation Strategy / Contingency Plan Status 1 Technical Risk 1.1 Team is unfamiliar with the technology used There might be a delay in project schedule longer time needed to create functions High High A Team members are to start researching and trying the technology in advance before the iteration Share research documents and knowledge among members Risk Strategy in place - Implemented 2 Sponsor Risk 2.1 Additional requirements requested during implementation of codes Might not be able to finish requirements on time substandard work produced High Moderate A Team members should discuss and decide if they can commit to the additional workload on time. If not, firmly reject the additional requirements Risk Strategy in place - Implemented 3 Project Management Risk 3.1 Over-estimate the days needed to build function Delay in the project schedule Moderate High A Project manager to take note of the schedule and plan the future schedules more carefully Provide a longer time period for the next iteration to complete the functions. Risk Strategy in place - Implemented

Application Development

Intermediate Deliverables Stage Specification Modules Project Management Minutes Team Minutes Sponsor Minutes Supervisor Minutes Metrics Schedule Metric Bug Metric Work Stress Metric Requirements Change Request Log Change Request Log Survey Results First Survey Result Statistic Analysis UI Prototypes UI Mockup Analysis Use Case Use Case Overall Design Diagram System Architecture Database Diagram Testing User Testing User Testing 1 User Testing 2

Technical Complexity Security HTTP Request Response Header - User token, application ID and parameters required to retrieve specific APIs were previously appended to a URL. To prevent user information from being compromised, we have shifted important parameters such as token and app ID to a HTTP connection header instead. Perfomance Gzip - To reduce long period of dependency for a stable connnection, it is critical to ensure that the file size of the required API is kept to a minimum. Comparing the data size between a Gzip file and a text String, Gzip file is calculated to be approximately 10 times smaller. This means that much less time is needed to retrieve the required data. This is critical for us as many users might always constantly be on the move and stable connection might be hard to get. At the same time, the data we require from QIITO is known to be relatively huge (A travelogue can contain 100s of places, with many pictures associated to each of the place). Lazy Loading - The idea of lazing loading is to reduce the required time needed to load and display a page. This is especially crucial when our application is required to retrieve and display a large number of images. What we have done is to make the downloading of images asynchronous and to create a queuing system (5 threads at a time) to download these images. Once an image is downloaded, it will be cached in the phone's memory and will be displayed on the page. SherlockActionBar/ Fragments SherlockActionBar library allows us to create "ICS looking" apps, enabling similar looks for versions all the way back to Android version 1.6, which the standard Android SDK does not offer. The features of the library include Actionbar, tabs, overflow, split action bar, viewpager etc. Now, we are able to create multiple interfaces within a single activity across all Android OS versions. This allows a better manipulation of functions when users navigate through the application. For example, the navigation between a web view and a native view with differing interface will only require two different fragments, instead of creating a new activity. In addition, due to the flexibility of fragments, each of them can be recycled and used in other activities within the application, reducing the need for repeated codes. The complexity lies on the fact that there is limited resources available pertaining to SherlockActionBar library. Being new to Android development, the learning curve for this library is considerably steep. Offline Map Whilst overseas, users may have difficulty obtaining data connectivity to have access to the full functionalities of Google Maps. With the implementation of OSMDroid (Open Street Maps for Android), the application will download a specific map area pertaining to the user’s itinerary. The maptiles (of .png file format) will then be zipped up so that it can be used to render the map, thus allowing users to view the touring area on the offline map with zooming features. This specificity is done through a customized algorithm to determine the right boundaries and zoom levels for the map for both the travelogue and place offline map. Being an open-sourced package increases the difficulty of implementation, due to lack of proper documentation to explore customized functions. There are also certain restriction of its usage due to it being free, thus algorithms for download are required to be stricter.

Deployment Deployment Version - v2.1 Development Environment - Deployed in Android Google Play Store Database - Used the phone's internal database, SQLite, Qiito Database (via API) Coding Language - Java and XML To download the application, you can visit this link to get the latest application in the Google Play Store.

User Testing Usability Test 2 (14th February '13) GOALS 1. Make sure all the new features implemented are workable and do not affect the old features from UT1 2. Obtain feedbacks from our users to improve the usability, experience and performance of the App TEST SCOPE S/N MAIN FUNCTION FEATURES TESTED 1 LOGIN Facebook Login Qiito Email Login 2 DISCOVERY View Featured Travelogues View Featured Places View Featured Photos View Expanded Google Map in Individual Travelogue View Expanded Google Map in Individual Place 3 MY TRAVELOGUE Add all places to new Travelogue Add a place to existing Travelogue View My Travelogue Listing View Individual Travelogue (with expanded map) View Individual Place in My Travelogue (with expanded map) Download My Travelogue View Travelogue Offline (without map) View Places in Travelogue Offline (without map) 4 MY MEMORIES Capture Photos via Camera Upload Photos via Camera/Gallery to Qiito's Server 5 MY PROFILE View My Followers *those in RED are newly added features TESTING METHODOLOGY Our participants for UT2 consist of Existing and new Qiito App Users. For existing users, we asked our friends from UT1 to test on our App to see if our App has improved from UT1. We also target new users by inviting our fellow SMU friends from different schools to try out our App. We conducted our Usability Testing 2 in a SR. Firstly, our team will brief them what our App is for. If the participants have Android phones, we will ask them to download our app from GooglePlay. If they have no Android phones, we will pass them our phones to test on. Like UT1, we gave our participants a sheet of instructions consisting a set of scenario-based tasks. We would then sit beside them and observe how they interact with our application. We should not guide them unless they are confused or don't know how to proceed. Our team would also note down the areas which are confusing. After they have done with the tasks, we will then ask them to fill up an Online Feedback Form UT2 DOCUMENT REPOSITORY DOCUMENT NAME DOCUMENT LINKS Scenario-Based Tasks Click Here (.docx) UT 2 Feedback Form Online Feedback Form UT 2 Results Click Here (.pptx)

Reflections

Learning Outcomes Team Reflection Member Reflection I have learnt to better manage my time by prioritizing my work accordingly. As the Quality Assurance Manager and Assistant Designer, I realized that it is very difficult to develop a native android app without any frameworks as there is a need to cater to different screen sizes for the phones. Sometimes it might look okay on my phone but looks different in another phone. I hope that through this project, I am able to learn things to give a better user experiences for users. I set out to learn hard skills such as technical coding and soft skills such as project management skills, which I believe is still an ongoing process.   However, the learning outcomes since acceptance have been much more overwhelming than I’ve expected. Being the lead developer for offline maps has really tested my patience and perseverance due to the need to meet project requirements and deadlines. I’ve also gained more experience working in an agile development where we have to constantly gauge and prioritize the importance of certain functions, either due to client requirements or insights from user testing. As a designer, it was indeed challenging as it was my first being exposed to Android Coding. Editing the XML layout code was quite different as compared to editing on a CSS template. Furthermore, I have to take consideration to different layouts and densities. Therefore , I have earnt the virtue of being patient and to continue to play around with the layout values to ensure that the outlook of the application appears correctly in different models. Communication is also key amongst the team to ensure the quality of the application is there. Coding is about coding and writing efficient logics and displaying them correctly (UI). Other areas include performance and usability issues, especially when there are different android phone models and versions out there. I have also enjoyed the opportunity of learning from one another. Our group started off with no one knowing how to develop an android app. As it progresses, each of us has forged our strength in different areas. Working with An has also widened my knowledge on many other technical know how such as performance testing etc. As a lead business analyst, I have explored available travel apps and design a survey questionnaire prior the start of the project to decide on interesting features that users would want in a travel app. At the same time, touching up on design prototyping and diagrams to clarify with sponsor and supervisor Through this project, I was hoping to learn how to better manage a team using the agile framework, where workload is fairly allocated throughout the team as well as a good management of change requests throughout the application. Currently, through the logs as well as meetings that we have, I learnt how to manage changes from the client’s, supervisor’s as well as user’s feedback and to prioritize what changes should be implemented. I hope to continue to learn how to better allocate the correct amount of manpower for each functions, and how to communicate better with the other stakeholders involved in our application.