HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2012T2 Viaxeiros Application Development"

From IS480
Jump to navigation Jump to search
Line 243: Line 243:
 
<b>6. Offline Map Display </b>
 
<b>6. Offline Map Display </b>
 
<br/><br/>
 
<br/><br/>
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 for the map for both the travelogue and place 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.
 
<br/>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.
 
<br/>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.
 
<br/><br/>
 
<br/><br/>

Revision as of 14:53, 25 February 2013

Viaxerios Logov1.png

Welcome to Viaxeiros FYP Wiki Page

Navigation 3.png
User Requirements Analysis

Survey 1

You can find the questions to our survey here
A summary review of the survey could be found here
Summary findings (Charts) could be found here


Feedback (Google Deployment)

Watch out for this space


Usability Tests


Usability Test 1 (3rd - 6th January '13)

GOALS

1. Make sure all the new features are workable and ready for Deployment 1

2. Obtain feedback to improve the usability 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
3
TRAVELOGUE
  • View My Travelogue Listing
  • View Individual Travelogue
  • View Individual Place in My Travelogue
  • Download My Travelogue
  • View Travelogue Offline (without map)
  • View Places in Travelogue Offline (without map)
4
MEMORIES
  • Capture Photos via Camera
  • Select a Photo via Gallery


TESTING METHODOLOGY

Our participants for UT1 are mainly our close friends. Each of us would get a friend to conduct User Testing with.

Firstly, our team will brief them what our App is for. As our App has not been deployed yet, we will pass them our phone and 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 unsure how to proceed.

After they are done with the tasks, we will then give them a feedback form for them to fill up.


UT1 DOCUMENTS REPOSITORY

DOCUMENT NAME
DOCUMENT LINKS
Scenario-Based Tasks
Click Here
UT 1 Feedback Form
Click Here



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

Alt text
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

Alt text


UT2 DOCUMENTS REPOSITORY

DOCUMENT NAME
DOCUMENT LINKS
Scenario-Based Tasks
Click Here
UT 2 Feedback Form
Online Feedback Form


Storyboard

You can find our Storyboard here: Version 1


Technical Complexity

1. ActionBarSherlock

An Action Bar is a bar at the top of the screen which is used across the application to identify the application brand and to support navigation. As Action Bar is not available for pre-honeycomb Android devices, we decided to make use of the ActionBarSherlock library, an open-sourced library designed to facilitate the implementation of Action Bar natively across all versions of Android devices using a single API. This library also provides additional features such as Fragments which is currently not present in the standard ActionBar mode.

2. Fragments

To integrate with the Sherlock Action Bar used as a header bar, fragments are used to allow multiple interfaces within a single activity. 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.

3. Image Loading

To speed up the display of pages and improve user experience, we have made use of “lazy loading” to enable the display of native pages (template) first while images are downloaded and displayed on the pages as and when they are ready. We have been able to do so with the use of the “Asynchronous” feature available in Android development.

4. URL Tracking

The android application that we are building for Qiito is a mixture of Qiito’s current mobile web and pure native pages. Some of the native pages include travelogue listing, travelogues and places. To enable switching between mobile web and native pages, there is a need to monitor the changes in URL. Should a following URL point to a webpage that requires native display, example travelogue listing, travelogues or places, there will be a need to call the native codes for display. Else, the mobile web should be called instead.

5. Different phone models with different OS versions

Since the Android software is offered on many different phone models, our team needs to cater for different image sizes to these phones. This is because phones tend to vary in size, features and user experience. Thus, this further complicates the native design process as additional time is required in resizing images and there is difficulty in ensuring consistency of the application for the rest of the other models. Additional testing is required as different sizes of phone models are tested to ensure that the images are displayed correctly.
Furthermore, older Android OS, which may not be able to support the newer OS, will not have the luxury to enjoy certain functionalities. Thus, extra time is needed to search for the best implementations without reducing usability of the application.

6. Offline Map Display

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.

7. QBeam – Augmented Reality View (Pending)

Even as locals, users may be surprised to discover unknown places of interest around their town. This is where QBeam comes in to help with the discovery, by displaying places of interests surrounding the user’s current location. This will be viewed through the lens of the phone camera, complete with the direction and distance away from the user. The team will be looking into exploring the Vuforia and Wikitude SDKs for Android in later iterations to deploy the Augmented Reality View function.



Resources

Below are the tools are resources our team is currently employing during this project:

[Eclipse IDE For Mobile Developers] Our trusty IDE that provides our coding environment!
[Subclipse] Subclipse is an Eclipse Team Provider plug-in providing support for Subversion within the Eclipse IDE.
[Android SDK Package] Providing the API libraries and developer tools necessary to build, test, and debug apps for our application.
[ActionBarSherlock] This library supports the use of ActionBar across all versions of Android using a single API.
[Fragments] Library that provides multiple interfaces within an Activity.
[OSMDroid] Map library we are exploring and deploying for our offline map viewing functionality.