Homework 2 - Project Proposal


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Homework 2 - Project Proposal

  1. 1. Homework 2 - Project Proposal Huning DAI, Nathan MURITH and Xuyang SHI {hd2210, nam2140, xs2137}@columbia.edu E6998 Mobile Computing with iPhone and Android 10th December, 2009
  2. 2. Contents 1 Team Members 3 2 Selected Platform 3 3 Project 3 3.1 Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2 PartyLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1 The Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Why Is It Interesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 In More Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Tentative Development Timeline 9 References 10
  3. 3. 1 TEAM MEMBERS 3 1 Team Members Our team consists of three Columbia Graduate students: 1. Huning DAI - hd2210 - hd2210@columbia.edu 2. Nathan MURITH - nam2140 - nam2140@columbia.edu 3. Xuyang SHI - xs2137 - xs2137@columbia.edu 2 Selected Platform The group’s desired platform is the iPhone. However this desire is not currently final. Not all team members own a Mac and therefore not all team members have access to the iPhone SDK. At the moment we are trying to find a solution to our problem. Worst case scenario, we will “have to” revert the Android platform. There are no real technical reasons behind our wish to work with the iPhone rather than the Android. It is more a preference from the point of view of usage and ownership of devices such as the iPhone or the iPod Touch. 3 Project 3.1 Prior Work PartyLine is an already existing desktop and mobile application that was developed by Joshi Keerti, Nathan Murith, Joshua Weinberg and Green Zhang in the context of Columbia University’s User Interface Design class (COMS4170). While both desktop and mobile ap- plications were built for PartyLine, the above mentioned class’ emphasis was on the desktop application. The mobile application “developed” for PartyLine was a simple, tiny and un- aesthetic html page readable from any mobile device’s internet browser. Since the mobile portion of PartyLine was developed solely for demonstration purposes for COMS4170, we hereby propose to built a full and actual mobile device application for PartyLine from scratch as nothing from the demo dummy version is reusable for this project.
  4. 4. 3 PROJECT 4 Figure 1: PartyLine Desktop Application 3.2 PartyLine The PartyLine application is a collaborative notification system, based on the twitter[4] API, which allows people at remote locations to issue ongoing status reports that can include pictures inline. The application remains stateless by distributing state among var- ious online systems for information access and storage. This is made possible by the use of multiple APIs and presumes internet access that is more or less constant. A short list of those systems that can be integrated into our application would include Twitter ([4]), GlowFoto ([1]) and TinyURL ([3]). PartyLine allows remote stakeholders (already in attendance) to invite their friends to attend a “good” party, show, or other event already in progress, by issuing invitations or by sending status updates directly to their twitter friends or indirectly to their twitter friends list. PartyLine updates are distinguishable from regular tweets because they contain a spe- cially formatted tag used by our application to unify reports occurring at the same location
  5. 5. 3 PROJECT 5 with other possible friends in attendance. Moreover, these updates and invites can also be accompanied by a relevant image. Such updates can be sent from any mobile computing device that supports web-page access, such as mobile phones which are network equipped. Vice versa, those twitter friends who remain at home have the ability to peruse all the remote reports (including multimedia attachments) and may filter out unwanted invites, friends, or locations to better decide which party to attend. 3.2.1 The Application The application consists of two parts. One accessible from a mobile device which is used to send party updates, and the other to consult what parties are ongoing, when and where. The main part of the application is the review portion of it which was developed on Flex (desktop application that will not be touched in this project). We briefly discuss both the update and the review functionalities of PartyLine below. The update portion of PartyLine is the mobile device application we propose to build. It will offer the following functionalities and features: • Authentication of the twitter user • Send party updates as direct Twitter message or public timeline Twitter message, both with or without a picture • Update user’s Twitter location with that of the party • Number of currently remaining tweets • Help on how to use the PartyLine update website When a user submits a party update, the information in the form is sent to a proxy that does the following: • Authentication of the twitter user (this is obviously done before the update is sent) • Gathers party geolocation coordinates from mobile device’s GPS • Uploads the picture (taken with the device camera) to GlowFoto ([1]) • Updates user’s twitter location ([4]) with that of the party • Encodes party information (GlowFoto pic, Geolocation coordinates, description, title, etc) in a TinyURL ([3]) • Updates Twitter with direct or public tweet containing TinyURL tag.
  6. 6. 3 PROJECT 6 The main PartyLine application is accessible from any web and flash enabled device and can be used to review what parties are going on, when, where and who is attending. In addition to basic features, PartyLine consists essentially if two main elements: the timeline view and the map view. Figure 2: PartyLine Timeline View
  7. 7. 3 PROJECT 7 Figure 3: PartyLine Map View PartyLine provides the following features: • Authentication of the twitter user (login/logout) • Display of user’s extended information • Display of number of currently remaining tweets • Sorting of PartyLine tweets by twitter friend or by event • Display of all tweets, PartyLine or regular tweets • Display of all PartyLine tweets related to selection in “list” (regular) mode • Display of all PartyLine tweets related to selection in “timeline” (time) mode • Display of all PartyLine tweets related to selection in “map” (location) mode • The possibility to remove one item at a time from either view, or clear either view completely from all events
  8. 8. 3 PROJECT 8 • Help on how to use the PartyLine 3.3 Why Is It Interesting In the initial version of PartyLine, the main stakeholders were college students who are usually pressed for time, fond of attending various parties and events and who usually are pretty computer and internet savvy. We strongly believe that if tools to help a student target events based on their location, time and people already attending were easily acces- sible they would be used. It seems intuitive that the potential market is out there and the PartyLine would be, without a doubt, be used by students who already own mobile devices such as the iPhone, iPod Touch or the Android, who already have accounts on websites such as twitter, Facebook, mySpace or Linked’in, and who already rely on such tools and services to organizes their daily lives. In addition to the initial idea mentioned above, one can think of many situations in which such an application can be used with only very little modification in the original concept. Here are a few: • Emergency Services: the same collaborative and notification application could be used for accidents of any kind. Imagine someone witnessing an accident, he/she can easily and quickly take a picture of what appended and uploaded to the application with precise location and description in order to make available to authorities. • The concept can very well be adapted to an application for women who like to shop where they could broadcast images, location and descriptions of the latest pair of shoes they bought. • One could also see the application changed for hunters/fishers, where the currently hunting/fishing person notifies his buddies of where it’s all happening. • And the list goes on... 3.4 In More Detail One of the many interesting aspects of this project is that, considering the mobile devices that are available today, we can actually build a proper application and not simply a webpage. In this instance the application in pair with the mobile device in question is all the more interesting for the following reasons: Connectivity Probably the most important feature of these devices (iPhone, iPod Touch or Android) is that the are built and sold to be constantly connected to the internet, where the user may be. Be it via WiFi or 3G, the user is constantly connected which greatly facilitates the uses of applications such as PartyLine.
  9. 9. 4 TENTATIVE DEVELOPMENT TIMELINE 9 GPS The current location of the event being broadcasted by PartyLine being essential to the application, these devices offer GPS functionality which provides direct geoloca- tions used by the desktop application. Camera The built in high-quality camera will by definition be used with PartyLine. Contact List The access to the contact list could and would be used in association with the twitter contacts to keep track of who the user can broadcast an event to. Google Maps It is easily envisageable to have a mobile PartyLine feature similar to the desktop one that would take advantage of the built Google Maps application that could list the user’s friends’ broadcasted events on a map. Accelerometer Currently the accelerometer functionality of the devices isn’t put to use. We could easily think of using it to detect and modify the device’s orientation to display the mobile PartyLine application in various formats. Obviously other ideas may arise during development. In addition, the project can clearly be subject to changes during the development phase. 4 Tentative Development Timeline Below is a tentative timeline our group will try to follow when developing PartyLine: Week 0: 2/2-8 Preliminary platform development exercises, group formation, informa- tion gather, project idea discussions Week 1: 2/9-15 Preliminary mock up of the project. LoFi prototype of user interface. Modeling of the system, according to the MVC design pattern. Week 2: 2/16-22 LoFi prototype user testing. Redesign of user interface according to results from test user. Preliminary implementation of the project backend. Week 3: 2/23-3/1 Implementation of user interface and backend of PartyLine. Week 4: 3/2-8 In-group testing. Debugging and implementation according to testing. 3/9 Midterm review: Presentation and Demo Week 5: 3/9-15 Testing, implementation and reimplementaton/correction Week 6: 3/16-22 Testing, implementation and reimplementaton/correction Week 7: 3/23-29 Testing, implementation and reimplementaton/correction Week 8+ TBD (Testing, implementation and reimplementaton/correction)
  10. 10. REFERENCES 10 References [1] Glowfoto upload api, 2008. http://www.glowfoto.com/api_upload.php. [2] Google Maps API for Flash, 2008. http://code.google.com/apis/maps/ documentation/flash/. [3] Tinyurl, 2008. http://tinyurl.com/. [4] twitter, 2008. http://apiwiki.twitter.com/. [5] Yahoo! maps web services - geocoding api, 2008. http://developer.yahoo.com/ maps/rest/V1/geocode.html. [6] iPhone Dev Center, 2009. http://developer.apple.com/iphone/index.action. [7] Mobile Computing with iPhone and Android, 2009. http://www.cs.columbia.edu/ ~nieh/teaching/e6998/. [8] Bill Dudney, Chris Adamson, and MArcel Molina. iPhone SDK Development, 2009.