1. Project Retrospective Team FancyPants

2. What is CyteSee? Idea

3. CyteSee is…  An extensible product family designed for the Android mobile platform to aid in walking tours, allowing the user to navigate to coordinates and display information about each stop.

4. Basic idea:  User selects a tour from dropdown menu and selects “Go!”  User selects location from Tour List  CyteSee guides user to location via Map and GPS  Upon physical arrival to location, CyteSee will display relevant information about the location on a GeoPage  User is then able to select another location to travel to and repeat the process

5. What does it do? Commonalities and Variabilities

6. Commonalities  GPS  Point to Point Navigation  Client/Server communication  Action Zones

7. Variablities  Platforms  Currently only Android  Different Tours  GeoPage Features  Picture  Information headers and content  Relevant link  Email Address  Phone Number

8. How is it all put together? Architecture

9. System Overview  Application UI  Generator  Client / Server communications  Google Maps interface

10. Phone User Interface Generators Client Side Server Side Google Maps

11. Client / Server  Centralized server hosting a database MongoDB Save, store, and retrieve Java objects as JSON strings  Android mobile devices as http clients for database communication HTTP request from server GSON library to translate JSON strings back into objects

12. Google Maps interface  Extra API supplied by Google to interface with Google Maps servers  Uses phone’s built in GPS to determine user’s location  Displays map, current location, and destination

13. Application UI  User interface for CyteSee application  Written for Android using Java and XML layouts  Designed for simplicity and ease of use  Intuitive design, no confusing extras

14. How do we make a CyteSee product? Product Generation

18. Video Demonstration What does it look like?

19. How well did we do? Project Measures

20. Attendance

21. Participation Rubric 1Very Poor  Does not respond to Email(s)  Does not attend meeting(s)  Fails to turn in artifact(s) 2Poor  May attend meetings but does not participate or turn in artifacts or vice versa  When artifacts are turned in they are often late without forewarning 3Fair  Attends meetings  Does not turn in artifact on time, but provides ample warning and communicates the problem. 4Good  Attends meetings  Turns in artifacts/finishes assignments  Communicates openly 5Great  Attends meetings  Turns in artifacts/finishes assignments  Communicates openly  Goes above and beyond

22. Participation

23. Met Deadlines

24. How did we do? In Retrospect

25. What would we do differently?  Start coding earlier  Communicate better  Begin use of IRC earlier  More structured research  Time management  Structured deadlines  Set more granular goals  More relevant documentation

26. What would we do the same?  IRC  Bi-weekly meetings  Dropbox  Android  Project scope  Keeping down feature creep