HeaderSIS.jpg

IS480 Team wiki: 2010T2 Quantum

From IS480
Jump to navigation Jump to search

Logo.JPG

Team Overview

Product Manager: Chua Sherman Glenn

  • Keep track of project’s progress and help resolve conflicts.
  • Keep track of project’s scope.
  • Allocate resources dynamically within the project.

Developers: Tang Bin, Qiao Yang

  • Determine suitable technologies and systems to use for development.
  • Determine suitable methodologies to adopt for project.
  • Plan project development and infrastructure.
  • Develop the application.

Tester: Carol Then

  • Develop test and use cases.
  • Develop UAT (User Acceptance Tests) and SIT (System Integration Tests).
  • Ensure that project’s usability and functionalities meet sponsor’s standards.

Project

The aim of this project is to build an Android application for wackotopia.com. Wackotopia.com is a website that hosts funny pictures from different parts of the world. It aims to attract as many visitors as possible and also become the go-to site for the funniest, wackiest, and weirdest images on the internet so that when people can see some funny images and jokes, read the comment, and have a good laugh when they are bored.

Project Overview

The application starts from the simple idea of sharing funny picture immediately after snapping with your phone. With the application, users will be able to logon to wackotopia.com, snap & edit picture, upload & view pictures as well as adding comments. In addition, inspired by the success of foursquare and the popularity of Location-Based-Service, we also included LBS in the application. Geocodes will be uploaded together with the picture and uploaded pictures will be pinned to google map, so users can know what are the funny things happening around them or track the traces of other users. Searching functions will also be provided for the map view.

At the same time, being a native Android application, users can enjoy several benefits while using the application:

  • Immersive, full-screen experience, which is not available on the phone's browser.
  • It is the fastest picture experience on a smartphone, even faster than the phone's browser.
  • Able to use the camera to take a picture very quickly (Android Camera API).
  • Able to edit a picture very easily.
  • Able to use native Android APIs to easily share pictures with friends via email, MMS, and Facebook.

There are several drawbacks of building a native Android application instead of a mobile-optimized web application:

  • We have to build the application from scratch, since we are unable to use existing HTML code.
  • Application will not be cross-platform, which means for now, it is available only on Android devices.
  • Much more complicated to build an application in Android than in HTML5.

Motivation

Our group is particularly interested in building mobile applications, since they are commonly referred to as the next paradigm in computing. Many people believe and predict that Smartphone sales will surpass PC sales by 2011. As such, learning the emerging technologies will prove extremely useful for us.

Stakeholders

Clients: Users of wackotopia who also use a Smartphone. Those who use their Smartphones to surf the web and view pictures will find this a welcome application, since it is a native application and it can incorporate more native functionalities (such as swiping sideways for the

Sponsor:

Technical Scope

Login/logout/register:

  • Using sponsor’s existing server-side web services to create a new user, as well as check if a user exists (login).
  • Building 2 client-side web services on the phone to consume to server-side web services in order to create a new user (register), as well as login/logout.

View pictures:

  • Building a server-based web service to serve the pictures from the sponsor’s database, as well as a client-side web service on the phone to consume it.

Take picture

  • Calling the phone’s camera API.

Edit pictures:

  • Adding of 3 or less tags to each picture.
  • Algorithm to resize picture.
  • Algorithm to add a title and a short sentence to a picture to make it a ‘demotivational’ style picture, all from a phone.
  • Algorithm to save new picture without any metadata loss.

Upload pictures:

  • Building our own client-side web service to send the picture, as well as the server-based web service to receive it.
    • The web service should also send the 3 or less tags with each picture.

Search pictures (by location and keyword):

  • Calling the phone’s geo-location API.
  • Building a client-side web service to send search terms to the server.
  • Building a server-side boolean-model search functionality to index and search pictures’ location, tags and comments.
  • Building a server-side web service to serve the thumbnails of the returned pictures with their geo-data (x-y coordinates).
  • Building a client-side feature which shows all the returned pictures’ thumbnails on a Google map.

Technical Complexity

The technical complexity of our project lies not in its depth, but in its breadth. In fact, the 'deepest' technology we go into is the Android API, which is where the bulk of development is happening. The most challenging part part about Android, and smartphone programming in general, is that although the phone is also a computer (has CPU, RAM, processor, etc), the paradigm is fundamentally different:

  • The user approaches a phone application differently (using touch, as opposed to a mouse). You have to assume speed (as opposed to long waiting times) and interactivity (as opposed to just starting at the screen).
  • The phone has functions a PC does not have (GPS location tracking, mobility, touch interfaces such as pinch to zoom). Therefore, to maximise the use experience, you have to incorporate all these fundamental phone abilities.
  • The phone has different limitations from a PC.
    • Limited RAM (512Mb at most). You have to assume that the user or the OS will force close your application from time to time, which means your application data will have to be saved constantly. You also cannot do things which require huge memory, which means you always have to make your code as efficient as possible. E.g. the less variables you declare the better.
    • Limited processing power. You do not want your phone performing many big computations, or many algorithms.
    • Limited connectivity. You do not want to choke the phone's bandwidth by needlessly downloading content that he may not be interested in.

As mentioned before, we are working with at least 3 different technologies:

  • Android API
  • C#.Net Web Services
  • Google Map API

The real challenge for us is in picking up the very different APIs quickly, and being able to implement them. This usually means running the HelloWorld tutorial for the technology, and reading tutorial guides as fast as possible in order to understand the APIs, capabilities, and limitations.

X-Factor

We will build a feature where the user can add text to a picture and save it as a new picture. This is quite different from other picture applications where users cannot easily add word content to pictures from a phone, merely view them. By allowing users to add text to a picture, the ‘funny-ness’ of the picture can potentially be increased. This is similar to current ‘demotivational’ pictures, where each picture comes with a title and tagline.

E.g.
This isn't that funny:

Without.png

But add a little text, and it gets a whole lot funnier:

With.png

Also, we will build a tagging system into the application, where the user can search for funny pictures either by location, tags, or comments. This is similar to the ‘Now Trending’ functionality in Twitter. This helps categorise pictures quickly, by letting the user tag his own submitted picture.

Lastly, we will also build a search functionality into the application, where users can either search for specific types of funny pictures, or funny pictures near his current location. For instance, if the user uses the ‘Nearby Pictures’ feature, he can immediately see all the nearby funny pictures to his location. If he uses the ‘Search Pictures’ feature, he can search for ‘car fat’ and he can immediately start viewing all the pictures which are tagged with ‘car’ or ‘fat’, or have comments with ‘car’ or ‘fat’ in them.

The results of both types of searches will be visually displayed in a Google map as pins and thumbnails. This helps the user get specific types of funny pictures fast and visually by being able to choose from thumbnails quickly. In future, users will be able to see a cool map visualisation that shows where how people from various places around the world submit funny pictures.

Use Cases

Use Cases.png

Architecture Overview

Client-side application will mainly consist of:

  • Login/logout web service
  • Register web service
  • View picture web service
  • Upload picture web service
  • View & give comments web services
  • Search web service
  • Create new picture algorithm
  • Resize picture algorithm
  • Save new picture algorithm
  • Google map
  • Location API
  • Camera API
  • Sharing API

Server-side infrastructure will mainly consist of:

  • View picture web service
  • Upload picture web service
  • View & give comments/likes web services
  • Search web service
  • Modifying existing databases

Architecture Diagram

Architecture.png

Storyboard

[Here].

Project Management

Our team is allocating 2 weeks to gear up for this project as preparation. Furthermore, the sponsor has also kindly agreed to provide any references and resources that we may need in terms of books, computers, or testing devices.

Schedule

Status.png

Risks

We recognise that our project will contain certain unavoidable risks. Rather than try to remove them totally, we instead endeavour to either efficiently reduce their likelihood of occuring, or to mitigate their impact by having backup plans in place.

  1. Lack of technical expertise.
    • Problems:
      • Most of us do not have prior experience working with Android, or the Android SDK.
      • There are new APIs to learn, new paradigms to work with, and new environments and constraints to work within.
      • Code becomes inefficient, resulting in unresponsive application or interfaces (requiring too much memory or CPU cycles).
      • Risk1.png
    • Mitigating factors:
      • Android is mainly a high-level programming environment which utilises the Java syntax, and since the developers will probably not be exposed to low-level system/functionality code, programming should not be a huge issue.
      • We have allocated 1 week for an Android crash course to get started with the tools and environment. Also, since Android is open-sourced, in the very unlikely scenario where we really need to look into the operating system code to see how it really works, we can.
      • We have multiple client meetings scheduled after each iterative development cycle. This is so that the client can test the new functionalites and give immediate feedback. Should improvements be required, there is a 2-week buffer (weeks 12 & 13) to improve code quality to improve performance. There is also a general buffer week (week 14) in case more enhancements are required.
  1. Unable to get Android devices for test & debugging.
    • Problem:
      • We need live devices to properly perform our test cases. Testing in a emulator is not sufficient, since an emulator uses a mouse to click, whereas on a live device, the main input is touch.
      • Android comes on a variety of hardware; getting more than 1 live device may prove to be a problem.
      • Risk2.png
    • Mitigation strategy:
      • So far, we have 2 different live devices (with differing technical specifications) to perform debugging and testing on.
      • We will continually source for ways to get live devices for development purposes, whether through the sponsor or through other means.
  1. Exceeding development cycle.
    • Problem:
      • Due to any unforseen circumstances, we may exceed the time allocated to each development cycle.
      • This can be due to the previous risk (lack of technical expertise), or factors such as laptops crashing, unable to meet sponsor to sign off, etc.
      • Risk3.png
    • Mitigation strategy:
      • If we exceed the time allocated to each development cycle, we will push the entire schedule backwards as required.
      • We have 2-3 weeks buffer period, so this will help mitigate the risk.
  1. Requirement changes.
    • Problem:
      • The sponsor may want to change features or functionalities halfway through the project.
      • We ourselves may want to change (add, remove) certain functionalities to improve the overall product.
      • Risk4.png
    • Mitigation strategy:
      • We have multiple client meetings scheduled after each iterative development cycle. This is so that even if the client has a requirement change, we can know about it as early as possible, so as not to disrupt our development cycle.
      • We are adopting an iterative development approach. This helps us test and re-test each new functionality with existing ones, so if there are any changes required, we can know about it early. If we go with the waterfall approach, we may only know about required changes in the later (testing) phase, which may be too late.
      • We also have a 2-3 week buffer period, to handle any unforseen change requirements.

Bug Metric

This metric is for tracking bugs in our code. The aim of this is to reduce the number and impact of bugs, and to improve the overall code quality.

In order to track bugs, we have come up with a metric that measures the impact of a bug by looking at its severity (how much does this bug affect the product?) and its likelihood (how likely is this bug to occur?). By taking both factors into consideration, we can quickly prioritise bugs and fix the major ones first.

We measure n, where n is given by number of lines of code divided by number of bugs.

If n < 5%, we are doing good.

If 5% < n <15%, we need to perform a code review.

If 15% < n, we need to redesign our model.

We also classify bugs into the various types, depending on where it happens:

  • User experience/experience
    • Long waiting times
    • Application hanging
    • Difficult to navigate the application
    • Too many steps required to perform desired action
    • Username not displaying properly
  • Logic
    • Not displaying the correct picture
    • Login/logout not working properly as intended
  • Back-end
    • Web-servies not working as intended
    • Web-services/database performing too slowly
    • Map visualization not displaying properly

Metric.png

Meeting Minutes

Here.

Midterm Progress Wiki

Here.

Final Presentation Wiki

Here.

Poster

Poster(green).jpg