User:Shashi/Foursquare/Gowalla Lite

= Checklist =


 * Google Reverse Geocoding API
 * SimpleGeo API
 * Foursquare Vocabulary API

= Deliverables =


 * A SimpleGeo location vocabulary plugin, similar to GeoNames plugin (WARNING: has a free limit of 10K requests / day)
 * A Spot or rather check-in microapp for spots+highlights+checkins+gallery
 * A Trip microapp for trips (depends on Spot)
 * A badge microapp for badges (depends on Spot)
 * A Gowalla + Foursquare compatible API, with added methods for administration
 * Check-in using StatusNet Mobile

= Design =

Spots

 * A spot has its own timeline of check ins / pictures and tips.
 * A user (OStatus) could watch a spot, which lets him receive all the check-ins into that place.
 * Each federated node has its own page for a given spot, but contains check-ins from all other nodes it is listening to.
 * A spot has gallery of pictures
 * Users can make logos for a spot, just like they make group logos
 * The first person to check into a spot becomes admin of the spot page and can add more admins
 * Anyone can bookmark a spot
 * Anyone can tag a spot with a "highlight" from a predefined set of highlights. eg. Scenic at Night, Nerd Hangout, etc.
 * The most picked highlights will be shown on the spot page
 * The admins can hide (specified number of) badges in the spot.
 * The other admins will also be unaware of the badge till they unlock it.
 * When a check-in to a spot with a badge is received, a badge is sent as a Salmon slap in reply
 * Each spot has a leader board with people with maximum check-ins

Implementation details

 * Spots are essentially groups of users where users get added automatically as they check-in
 * DB Model:
 * Spot - spot details
 * Check_in - Check-ins
 * Spot_admin - admins of the spot
 * Highlight_mood - predefined highlights
 * Highlight - highlight table, profile X highlighted spot Y as being of mood M
 * Spot_bookmark - bookmark a spot, add to a list of spots the user maintains for any arbitrary reason
 * OStatus:
 * A spot activity object identified by coordinates and a name
 * A Check-in verb where target is the spot object, actor is the goer.
 * A highlight verb where target is the spot object, payload is the name of the highlight, actor is the user adding highlighting

Badges

 * Anyone can create a badge
 * Admins of a spot can search the badges on their site and hide it at the spot for others to discover
 * Each badge has its own page for showing activity around it.
 * eg. Shashi unlocked the Pre-historic Cave Man badge in Madagascar 2 hours ago. etc.
 * The page shows a list of places hiding the badge in the past

Niceness

 * For judicious use of badges so that some badges are rare and hence more rewarding to find, hence adding to the healthy game dynamics:
 * creators should be able to (optionally) limit the number of badges that can be deployed
 * or to (optionally) confirm before a spot admin wants to hide badges.

Implementation details

 * DB Model:
 * Badge_detail - badge detail
 * Badge - badges found (badge.id, profile.id, checkin.id) as key
 * Badge_placement - Badge placement (spot, badge, count)
 * Badge_admin - admins of the spot
 * Come to think of it, even badges can be thought of as a group of people, some admins, where members are added automatically as they check in.
 * OStatus:
 * A badge activity object identified by name, icon etc.
 * An award activity verb with target as the user being awarded

Trips

 * Anyone can create a trip
 * A trip will have not more than 20 unordered spots by default
 * Anyone can bookmark a trip
 * Anyone can take up a trip, if they check-in to all the places in it, they finish the trip
 * If someone takes up a trip and has already been to all the places before, ask them if they want to do it again.
 * Each trip also has a page with pictures, people and spots

Implementation details

 * Ajax search and add interface for adding / removing places
 * Groups of people with admins again?
 * DB Model:
 * Trip - trip detail
 * Trip_complete - Trip taken
 * Trip_opt_in - users opting-in on a trip
 * Trip_spots - spots in each trip
 * Trip_admin - admins of the trip
 * Trip_bookmark - bookmark a trip, add to a list of trips the user maintains for any arbitrary reason
 * OStatus:
 * A trip activity object which contains a URI to a feed of spot activity objects
 * Completion of trips will not be sent over OStatus since they are to be decided by looking at the check ins a profile has made
 * an opt-in verb for a trip object with the actor as the user taking up the trip

Open questions

 * What will the object type uris be for the activity objects and verbs?
 * Should trips be immutable once created?
 * Can grouping of people be abstracted out?
 * Should spots / trips and badges be done as separate plugins with dependencies?
 * Which apis to support? Gowalla or Foursquare or both?

Also

 * Will need custom API methods to expose creation of badges
 * On badges/trips page, you could look at the referral url (if present) to look up a profile using it's homepage field (even OStatus profiles) and tell if the profile has achieved the badge/trip. This helps badges be authentic in OStatus
 * StatusNet Mobile integration -- requires another wiki page :P