Mashing Up Google Maps, Pt. 2

We initially had an issue within Moocher between our Google Maps “View Event” applet and the Facebook Comment system because the applet needed to be placed within an iFrame in order for its JavaScript to work correctly, and FBJS was not robust enough for what we needed. A page could display Facebook Comments or an iFrame, but not both.

The workaround we have implemented bypassed our “Display Event” applet by providing the user with a direct http hyperlink to Google Maps that is automatically generated for each individual event with the related search parameters. The syntax for our http query is: http://maps.google.com/maps?q=(Event Location)+(Network Name)

The Google Maps http query is flexible and allows a geographic coordinate to be included and specific markers to be placed on the map. This will allow us to refine our query results in the next phase. We used the same concept to make our “Add to Google Calendar” link. Moocher pulls information from the Facebook and Moocher event pages and generates a link that instructs Google Calendar to create an event reminder with event info, time, location, mooch type, etc.

The syntax for this is: http://www.google.com/calendar/event?action=TEMPLATE&text=(Event Name)&dates=(Date and Time in Google Format)&details=Mooch:(Type of Mooch)&location=(Name of location)&sprop=website:(Link to website of origin)

For more information about Google http parameters, please visit:

Google Map Parameters

Event Publisher Guide

Mashing Up Google Maps

To better support our users in finding free food, we are attempting to integrate Google Maps into the event view, which will let users find directions to events easily. Each Facebook network has its own map with a unique geographic point and zoom level. When a user is creating an event or importing an event to Moocher for a network, they will be prompted with the option to pinpoint the building/location of the event with a Google Map box that is automatically zoomed to their campus. Moocher stores the latitude and longitude of the mouse-click for reference.

When users are viewing an event with location data, the page will display a Google Map centered at the location of the event with a link to receive further directions from Google Maps. To enable the use of Google Maps within Facebook , we nested the scripts that Google Maps uses inside of an iFrame. Using PHP’s get() and set() methods, we are able to pass variables between our database, Google Maps applet, and the Moocher Application. The API is located at http://code.google.com/apis/maps/ and contains useful tutorials and code examples.

Organization

Our team meetings are extremely organized for efficiency. When we all arrive, we all go around and discuss what each person has done so far as well as what needs to be done, and I (Amritha) take detailed notes for that particular meeting. All the notes from every meeting go into our digital dropbox folder labeled "Meeting Notes," so group members can access the minutes from any meeting we've had in the past. For every meeting we make sure to book a meeting room so we can take advantage of whiteboards so we can map out remaining tasks and clarify requirements.

Wireframing with Omnigraffle

We created the wireframes for phase 2 with OmniGraffle, a diagramming application available exclusively on macs. The advantage of using OmniGraffle over other wire framing applications such as Visio and Illustrator is that it has a greater variety of stencils that contain premade drag and drop-able image elements. This makes the wireframing process much easier because you do not have to actually design most of the elements. There are also a lot of custom made stencils available online in addition to the presets that came with the program. For our wireframes, we used a set of Facebook stencils from Graffletopia as well as several other stencils containing various common UI elements.

Document Collaboration: Putting it all together

Once we had the right process established, compiling phase reports was a breeze. Our first step would be to use a good old fashioned whiteboard during our meetings to divvy up tasks and illustrate our concepts. Amritha would then document the tasklist and upload it to Dropbox. From there, each member checked his/her assigned tasks and would create a separate word document in the phase folder. When two or more of us needed to work on a small task simultaneously, we used Google docs to create the document and would then upload it to the dropbox folder.

As each task was completed and uploaded, I proofread, formatted and complied all the mini tasks into a single consistent document. So when the deadline came around, all that was left was a few final bits of formatting, a couple of proof readings and the report was ready to be turned in.

Document Collaboration: Dropbox vs. Google Docs

Dropbox is simply the greatest thing that's happened to team collaboration. Ever. Dropbox lets you keep a single folder synchronized with a web server, allows you to have 2 GB of content, has a web interface for accessing data from a browser and even a client that makes managing dropbox folders a breeze. But it doesn't stop there - Dropbox also lets you share folders with friends and set permissions, keeps the files synchronized across all devices and has a public folder that can be shared with people who dont use dropbox via a simple HTTP link.

However, there were a few situations where we needed 'live' document collaboration and thats when Google Docs came into the picture. With a Google account you simply create a new document and invite friends to collaborate on the document. The application supports live editing of the file by multiple users (I've seen upto 40 on one document) and uses micro-version control to ensure that users never overwrite each others content.

Moocher File Structure

Most of the Moocher team is familiar with the Model View Controller framework from past work with Ruby on Rails. We have decided to modify this framework for Moocher. The main change we are making is the combination of the controller and the view. We will also have a model for each view/controller which will contain all functions needed to interact with our database or outside interfaces/API's. However, we will also have "models" for external interfaces, API's, or even large pieces of functionality such as mapping, pagination, emailing, etc. Apart from the Model View Controller framework we're also splitting up the CSS and Javascript per view/controller so that each page has a definite location for all of it's functions, styling, and scripts. We're hoping this move will minimize the amount of people editing a single file at a time. A visualization of the Moocher file structure can be seen below: