Finally the app is done. Here’s a formal description, as it went in one of the papers we wrote:
The application permits its users to share check-ins in certain locations with other users of the system (such as family members and school friends), similar to the popular application Foursquare. The check-in feature was selected for our case study based on the analysis previous qualitative data with members of our target group.
Basic features and preferences
Users can place other users of the system in one of two lists (“family” or “friends”), otherwise they are placed in the list “others”. Users can select with which lists they share their check-ins, and from which lists they view shared check-ins.
Users can create locations either through placing a marker on an integrated Google Map, or simply by detecting the current GPS position. The application will create a 50m*50m location surrounding the resulting GPS coordinates, to which the users can assign a name.
When a user wants to check-in, a list of nearby, already created locations is displayed (with the option of adding a new location). The user can select their location, and confirm their check-in, to be shared with the users in the lists our user is sharing with, according to their preferences. Users who receive this check-in will get a pop-up with the sharer’s name and location information, assuming that they opted (in their own preferences) to view check-ins from the list to which the sharer belongs.
Social commitments
The application allows for additional, norm-based behavior customization. Drawing from the social commitments framework by Singh, and our analysis of user data, we have created the following commitment model:
A commitment (S, T, t, n, e, d) consists of S the source (creator of the commitment), T the target that has to comply with it, t the triggering condition that activates the commitment, n the normative effect (an obligation or a prohibition of sharing or viewing a check-in, from someone or a group of people), e the expiry condition that deactivates the commitment, and d the deadline by which an obligation commitment should be fulfilled.
For example, Mark (source) can create the following commitment: (1) I want Paula (target) to share her check-ins with me (normative effect), if she enters the park (triggering condition). Another example is Mark creating the commitment: (2) I want Paula to “not view” check-ins from the group “friends” (normative effect) after 9 pm (triggering condition). In the current app version, the deadline ASAP is used for obligation commitments. Expiry condition in (1) is not required, while in (2) it is implied as a certain hour (9 am).
Upon creation, commitments are sent from source to target, whereby the target can either accept or delete the commitment, or “decide later”. The commitment enters its “active” state when it’s been accepted by the target, and the trigger condition has been met. The commitment leaves its “active” state when the expiry condition has been met, but can re-enter that state if the triggering condition was met again, provided that it was not deleted.
Conflicts between preferences and an active commitment are decided in favor of the commitment. For example, if Mark is in Paula’s family list, and Paula opted in her preferences to “not share check-ins with family”, accepting commitment (1) above means Paula’s check-in will be shared with Mark if she enters the park. Conflicts between two active commitments would be solved in favor of the commitment most recently accepted.
A 3-minute tutorial video of the application (with subtitles) can be seen here.
Alex's portfolio 