Skip to content

Final Project Report

Jump to bottom
Tim Honeywell edited this page May 6, 2013 · 47 revisions

Home // Project Documents // Developers // Technical Strategy // Guides // Meeting Notes // Feature Log

MyM

"Map your moments."

Developers

Inception: Objectives and Overview

A joint document is here. The original is here. The updated version is in full below for convenience.

Problem Statement:

An iOS application needs to be created for the iPhone utilizing a minimum of five Amazon AWS cloud services. The application development should span the majority of the Spring semester and the final product should approach start-up quality.

Objective of System / Description of End Product:

Our app idea is for a social travel blogging app. Users will be able to create “moments” by sharing photos, videos, and blog posts from their iOS device. However, unlike a traditional blog where entries are chronological, our application would display this information on a map where the post was made or the photo was taken. Users can be friends with each other, allowing them to see each other’s posts on their own map.

Our app would use S3 to store photos, EC2 to manage images and conversions, SES to send email notifications to users, IAM to provide user credentials, and finally, an RDS database to store user information.

Importance and Need of Product:

A frequent question that is asked when people are shown a picture is “Where is this?!” MyM answers that question, by design. When you take a picture with MyM, the app notes your location and drops your photo on native map application. Taking a road trip? Snap some pictures along the way... at the end, you’ll see a string of pictures along your route. Easily share your moments and manage your own digital travelogue.

Similar Systems:

There are several systems similar to the application we are developing. Instagram is similar regarding the submission of photos to the cloud. The use of locations and databases causes our application to be similar to Foursquare as well. Video moment support creates similarities between our application and other sites that allow sharing of small video clips, such as Vine.

Innovation:

One key innovation in our design is that user content will be uploaded and presented based on location, as opposed to chronologically. Posts from weeks or months ago will be nearly as easy to find as content uploaded the same day and all content will be easily available to find based on location.

Computer Science Concepts and Technologies to Learn:

To complete this project our group will have to learn and use various new tools and languages. Some in our group have been exposed to iOS programming in Objective-C, but others will have to learn this language and delve into the iOS SDK to be able to implement various aspects of the project. Furthermore, our group will have to learn how to implement many AWS services such as S3, EC2, SES, and IAM. The project will also require a database, so we have chosen to learn how to use RDS to meet our project’s needs. Since we will be using Github for this project, we will need to all learn how to use git for source version control amongst our group members. Finally, our group will be using an application called TestFlight that will allow us to share over the air our in-progress application for testing by people outside of our group.

Diagrammatic Representation:

Alt text

Other Possible Applications:

There are several additional applications for this project, including selling houses, travel guides/agents, and tracking band/celebrity tours. House agents could use the application to advertise houses for sale in the area. Travel guides or agents could use the application to promote various vacations and what different spots have to offer. Both house and travel agents could use the application to communicate with potential customers. Bands and celebrities could use the application to post content from tours or vacations so that users can track their day to day activities.

Elaboration: Requirements Modeling and Analysis

A joint document is here. The original is here. The updated version is in full below for convenience.

Legal Issues:

Security

The application will provide accounts for each user. Users will not be able to access data that others have posted without friending that account first. Accounts will be password protected and use the bcrypt encryption protocol. User data will be protected against malicious software and from risks of either compromise or deletion. The application will be protected against outside threats towards the server (mainly bad/invalid user input) in order to continue running and provide persistent service to users.

The application will be constructed under the premise of a “dumb” client. Most processing will be handled on the server side, allowing for validation of data in the server environment (gaining access to the server is much more difficult for hackers to accomplish). User accounts and friendships will be handled exclusively on server-side. The server will be fitted with strong access controls and session management to reduce stealing of permissions and session hijacking, respectively. The User Interface will be designed in order to reduce the amount of invalid data that could be passed to the server, although all data will be re-validated server-side. Most security protocols and testing procedures implemented will be taken directly from OWASP: (https://www.owasp.org/index.php/OWASP_Mobile_Security_Project).

Backup and recovery

All files uploaded to the application will be hosted and backed up using AWS S3 storage. The system will keep additional copies of user content in order to prevent loss of data from an outside attack. Files will be recoverable and users will continue to have access to content once the storage system has restarted. Users will be able to quickly and easily terminate and erase their account, along with all attached content. All data will be deleted from storage, meaning accounts will not be recoverable once they are terminated.

Legal issues

The application will abide by several U.S. standards in regards to privacy of information. The Personal Data Privacy and Security Act of 2009 states that all private and confidential user information stored by a site should not be accessible to other users. Personal data and content on the application will be protected from unwarranted access.

The application will provide ways to block and filter illicit content, although a user’s main line of defense will be to unfriend users who upload content they do not agree with. Location tracking is an integral part of the application and users will be informed of location tracking through the terms of service of the application. In addition, they will be prompted to agree to tracking when opening the application for the first time.

The application will provide both a short about page that explains the uses of the app and how a user’s information will be stored and used.

Possible Applications of the System:

The primary intent of MyM is to serve as a location-based blog. Users will be given the opportunity to upload pictures, video, and text posts, attaching them to specific geographic locations. This content is then displayed in the form of pins on a map.

MyM lends itself to use as a digital travelogue. Users are able to upload and caption moments as they journey throughout the world. In addition, users can view moments of their friends, allowing trips to be shared with friends and family as they occur.

MyM would be an ideal tool for real-estate agents. The agent could photograph the houses currently on the market and write text posts containing their details. Text and photos for a particular house would naturally be grouped into a collection over its location on the map. Users could then follow the real-estate agent to have access to a dynamic catalog of houses.

Similarly, travel agents would be able to use MyM to advertise and promote travel destinations, adding photographs and videos to show off the locations and text to describe the vacations in more detail.

Bands and celebrities would benefit greatly from the functionality, allowing many users to view where they are and what they are up to. While on tour, all the photos and reflections that are often posted to a traditional blog could be posted to MyM. Users who friend the band or celebrity would be able to track their progress.

Use Case Diagram for System:

Alt text

Use Case Descriptions:

Post Moment - Existing Photo

  • Primary actor: User
  • Goal in context: To post an existing photo as a moment in the application.
  • Preconditions: System is fully configured and app is installed on iPhone; user has logged in and photo to upload has already been taken.
  • Trigger: The user wants to upload a photo. Scenario:
    • The user launches the application from the iPhone menu.
    • The user will be navigated to the default application screen (the map).
    • The user will select the ‘+’ icon at the bottom of the screen.
    • The icon will expand to display several additional icons: ‘Photo,’ ‘Note,’ and ‘Video.’
    • The user will select the ‘Photo’ icon.
    • The application will navigate to a camera interface, where the user can select to choose from existing photos/videos by selecting the bottom right button.
    • The user will select the existing photo to upload from his library.
    • The application will navigate back to a post screen, where the user can select to add a title and caption.
    • The application will then navigate to the map screen, where the new moment will be displayed in its location through use of the photo’s metadata.
  • Exceptions:
    • No existing photos.
    • User decides not to post photo at any point during process.
  • Priority: Very high
  • When available: First iteration
  • Frequency of use: High
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • How many photos can a user choose to upload at once?
    • Who can a user tag?

Post Moment - New Photo

  • Primary actor: User
  • Goal in context: To take a photo and post it as a moment in the application.
  • Preconditions: System is fully configured and app is installed on iPhone; user has logged in and photo to upload has not already been taken.
  • Trigger: The user wants to take and upload a photo.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user will be navigated to the default application screen (the map).
    • The user will select the ‘+’ icon at the bottom of the screen.
    • The icon will expand to display several additional icons: ‘Photo,’ ‘Note,’ and ‘Video.’
    • The user will select the ‘Photo’ icon.
    • The application will navigate to a camera interface, where the user can take a photo using the capture button at the bottom of the screen.
    • The application will prompt the user to ask if he/she would like to upload the photo just taken.
    • The user will select ‘Yes’ to continue, and ‘No’ in order to return to the camera interface and try again.
    • The application will navigate back to a post screen, where the user can select to add a title and caption.
    • The application will then navigate to the map screen, where the new moment will be displayed in its location through use of the photo’s metadata.
  • Exceptions:
    • User decides not to post photo at any point during process.
  • Priority: Very high
  • When available: First iteration
  • Frequency of use: High
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • How many photos can a user take before uploading?
    • Who can a user tag?

Post Moment - Existing Video

  • Primary actor: User
  • Goal in context: To post an existing video as a moment in the application.
  • Preconditions: System is fully configured and app is installed on iPhone; user has logged in and video to upload has already been taken.
  • Trigger: The user wants to upload a video.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user will be navigated to the default application screen (the map).
    • The user will select the ‘+’ icon at the bottom of the screen.
    • The icon will expand to display several additional icons: ‘Photo,’ ‘Note,’ and ‘Video.’
    • The user will select the ‘Video’ icon.
    • The application will navigate to a camera interface, where the user can select to choose from existing photos/videos by selecting the bottom right button.
    • The user will select the existing video to upload from his library.
    • The application will navigate back to a post screen, where the user can select to add a title and caption.
    • The application will then navigate to the map screen, where the new moment will be displayed in its location through use of the video’s metadata.
  • Exceptions:
    • No existing videos.
    • User decides not to post video at any point during process.
  • Priority: Very high
  • When available: First iteration
  • Frequency of use: High
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • How many videos can a user choose to upload at once?
    • Who can a user tag?

Post Moment - New Video

  • Primary actor: User
  • Goal in context: To record a video and post it as a moment in the application.
  • Preconditions: System is fully configured and app is installed on iPhone; user has logged in and video to upload has not already been taken.
  • Trigger: The user wants to take and upload a video.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user will be navigated to the default application screen (the map).
    • The user will select the ‘+’ icon at the bottom of the screen.
    • The icon will expand to display several additional icons: ‘Photo,’ ‘Note,’ and ‘Video.’
    • The user will select the ‘Video’ icon.
    • The application will navigate to a camera interface, where the user can take a video using the record button at the bottom of the screen.
    • The application will prompt the user to ask if he/she would like to upload the video just taken.
    • The user will select ‘Yes’ to continue, and ‘No’ in order to return to the camera interface and try again.
    • The application will navigate back to a post screen, where the user can select to add a title and caption.
    • The application will then navigate to the map screen, where the new moment will be displayed in its location through use of the video’s metadata.
  • Exceptions:
    • User decides not to post video at any point during process.
  • Priority: Very high
  • When available: First iteration
  • Frequency of use: High
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • How many videos can a user take before uploading?
    • Who can a user tag?

Post Moment - Note

  • Primary actor: User
  • Goal in context: To create a note and post it as a moment in the application.
  • Preconditions: System is fully configured and app is installed on iPhone; user has logged in to the application.
  • Trigger: The user wants to create and upload a note.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user will be navigated to the default application screen (the map).
    • The user will select the ‘+’ icon at the bottom of the screen.
    • The icon will expand to display several additional icons: ‘Photo,’ ‘Note,’ and ‘Video.’
    • The user will select the ‘Note’ icon.
    • The application will navigate to a post screen, where the user can create his note. The user can select to add a title and caption.
    • The application will then navigate to the map screen, where the new moment will be displayed in its location through use of location tracking.
  • Exceptions:
    • User decides not to post note at any point during process.
  • Priority: Very high
  • When available: First iteration
  • Frequency of use: High
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • How many notes can a user upload at a time?
    • Who can a user tag?

Alter Moment - Delete Moment

  • Primary Actor: User
  • Goal in context: To delete a post made by the user
  • Preconditions: System is fully configured and app is installed on iPhone; user has logged in to the application. User has a post on the map.
  • Trigger: The user wants to delete their post
  • Scenario:
    • The user clicks on a post that they have made, bringing up the detail view for that post.
    • User presses the ‘Delete Post’ button
    • The user presses the ‘Ok’ button to make changes
    • The user is returned to the map screen with the post deleted from view.
  • Exceptions:
    • The user presses the cancel button when prompted to confirm changes
  • Priority: Very High
  • When available: First Iteration
  • Frequency of use: High
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open Issues:
    • Make sure that the post is removed from the map properly when returning from the deletion
    • Make sure that the post is changed on both the map and in storage.

View Moment

  • Primary Actor: User
  • Goal in context: To bring up the detail view for a post
  • Preconditions: There is a post on a user’s map
  • Trigger: User wants to see more information about a moment on the map
  • Scenario:
    • The user is logged in and is currently on the map screen
    • The user clicks on a moment that is on the map
    • The application navigates to the detail view for that moment
  • Exceptions:
    • Error retrieving information from server
  • Priority: Very high
  • When available: First iteration
  • Frequency of use: Very high
  • Channel to actor: iPhone
  • Secondary actors: none
  • Channel to secondary actors: N/A
  • Open issues:
    • Will the detail view just expand as a big annotation to the map, or will it transfer the user to a new screen?
    • What animation will occur when transitioning from the map to the detail view?

Friend another user

  • Primary actor: User
  • Goal in context: To friend another user
  • Preconditions: The user is logged in with a valid account
  • Trigger: The user wants to add a friend
  • Scenario:
    • The user has navigated to the user’s page of the application
    • The user clicks to add the user as a friend
    • An email will be sent to the user to confirm the friendship.
    • If the user presses ‘Confirm’ in the email, a friendship will be created.
  • Exceptions:
    • The other user denies the request.
  • Priority: High
  • When available: Second Iteration
  • Frequency of Use: Medium
  • Channel to actor: iPhone
  • Secondary actors: Other user
  • Channel to secondary actors: iPhone
  • Open Issues:
    • Implement request blocking
    • Prevent spam requests

Unfriend another user

  • Primary actor: User
  • Goal in context: To stop interactions with another user
  • Preconditions: User has a friend
  • Trigger: User wants to remove a friend
  • Scenario:
    • User navigates to their friends view
    • The user chooses a friend and selects to delete them as a friend.
    • If the user clicks ‘Ok,’ the other user will be removed from their friends
  • Exceptions:
    • The user cancels when asked for confirmation
  • Priority: High
  • When available: Second Iteration
  • Channel to actor: iPhone
  • Secondary actors: other user
  • Channel to secondary actors: iPhone
  • Open Issues:
    • Add a blocking feature

Expand Collection

  • Primary actor: User
  • Goal in context: To expand a collection of grouped moments on the map
  • Preconditions: There is a collection of posts that can be expanded
  • Trigger: The user wants to see the individual posts that make up a collection
  • Scenario:
    • The user is on the map screen with a collection icon displayed on the map.
    • The user clicks the collection icon.
    • The collection expands into individual posts in a circle around where the original icon was.
  • Exceptions:
    • Posts may start to overlap if there is too much clutter in one area
  • Priority: Medium
  • When available: Second iteration
  • Frequency of use: Medium
  • Channel to actor: iPhone
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • How do we deal with collections that are close to each other?
    • Should collections auto expand/contract as the user zooms in/out

Create Account

  • Primary actor: Prospective User
  • Goal in context: To create a MyM account
  • Preconditions: System is fully configured and app is installed on iPhone.
  • Trigger: The prospective user wants to create an account.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user will be presented with a login screen.
    • The user selects the ‘Register’ button, launching a new view.
    • The user enters a new username, email address, password, and full name in the appropriate fields and selects a button labeled ‘Create.’
    • The user will be presented with a screen banner notifying them their account has been created.
    • An email will be sent to the user welcoming them to the application.
    • The user will be navigated back to the login screen to begin using the application.
  • Exceptions:
    • The user enters an existing username.
    • The user enters an existing email address.
    • The user enters a non-existent email address.
    • The user enters an incorrect verification code.
  • Priority: Very high
  • When available: First iteration
  • Frequency of use: Medium
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • Present option to log in?
    • Present retry screens as necessary?

Sign In

  • Primary actor: User
  • Goal in context: To sign in to a user’s account.
  • Preconditions: System is fully configured and app is installed on iPhone.
  • Trigger: The user wants to use the application.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user will be presented with a login screen.
    • The user enters their username and password in appropriate fields and selects a button labeled “Log In.”
    • The user will be navigated to the default application screen (the map).
  • Exceptions:
    • The user does not have an account.
    • The user does not enter their account credentials appropriately.
  • Priority: Very high
  • When available: First iteration
  • Frequency of use: Low
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • Present option to create account?
    • Present retry login screen?

View Profile/Settings

  • Primary actor: User
  • Goal in context: To view the profile for a user.
  • Preconditions: System is fully configured and app is installed on iPhone, user is logged into the application.
  • Trigger: The user wants to view his/her profile.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user swipes left to right on the application’s main screen, bringing up a sidebar display.
    • The user selects ‘Settings’ on the sidebar.
    • The system displays the user’s profile for viewing, with option to ‘Edit Profile.’
  • Exceptions:
    • The user decides not to view his/her profile.
  • Priority: High
  • When available: First iteration
  • Frequency of use: Medium
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • None

Edit Profile

  • Primary actor: User
  • Goal in context: To edit the profile for a user.
  • Preconditions: System is fully configured and app is installed on iPhone, user is logged into the application.
  • Trigger: The user wants to edit his/her profile.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user swipes left to right on the application’s main screen, bringing up a sidebar display.
    • The user selects ‘Settings’ on the sidebar.
    • The system displays the user’s profile for viewing, with option to ‘Edit Profile.’
    • User selects option to ‘Edit Profile.’
    • User edits desired changes to profile and selects ‘Save Changes’ to make changes or the ‘X’ icon to revert to ‘Profile’ screen.
    • If user selects ‘Save Changes,’ changes are made and system reverts to ‘Profile’ screen.
  • Exceptions:
    • The user decides not to edit his/her profile.
    • The user’s changes are not allowed.
  • Priority: High
  • When available: First iteration
  • Frequency of use: Medium
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • Should we require user to enter credentials again before editing?

Edit Settings

  • Primary actor: User
  • Goal in context: To edit the settings for a user.
  • Preconditions: System is fully configured and app is installed on iPhone, user is logged into the application.
  • Trigger: The user wants to edit his/her settings.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user swipes left to right on the application’s main screen, bringing up a sidebar display.
    • The user selects ‘Settings’ on the sidebar.
    • The system displays the user’s profile for viewing, with option to ‘Edit Settings.’
    • User selects option to ‘Edit Settings.’
    • User edits desired changes to account and selects ‘Save Changes’ to make changes or the ‘X’ icon to revert to ‘Profile’ screen.
    • If user selects ‘Save Changes,’ changes are made and system reverts to ‘Profile’ screen.
  • Exceptions:
    • The user decides not to edit his/her profile.
    • The user’s changes are not allowed.
  • Priority: High
  • When available: First iteration
  • Frequency of use: Medium
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • Should we require user to enter credentials again before editing?

View Friend Profile

  • Primary actor: User
  • Goal in context: To view the profile for a user’s friend.
  • Preconditions: System is fully configured and app is installed on iPhone, user is logged into the application.
  • Trigger: The user wants to view his/her friend’s profile.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user swipes left to right on the application’s main screen, bringing up a sidebar display.
    • The user selects ‘Friends’ on the sidebar.
    • The user selects the friend who’s profile he wants to view.
    • The system displays the user’s friend’s profile for viewing.
  • Exceptions:
    • The user decides not to view his/her friend’s profile.
  • Priority: High
  • When available: First iteration
  • Frequency of use: Medium
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues: = None

View About Page

  • Primary actor: User
  • Goal in context: To view the MyM About Page.
  • Preconditions: System is fully configured and app is installed on iPhone.
  • Trigger: The user wants to view the about page of the application.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user swipes the arrow at the bottom of the view upwards, bringing up another view.
    • The user can now read an view the about page of the application.
  • Exceptions:
    • The user decides not to view the About Page.
  • Priority: High
  • When available: First iteration
  • Frequency of use: Low
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • Should all settings be viewable on the screen?

Edit Settings - Sign Out

  • Primary actor: User
  • Goal in context: To sign out of a user’s account.
  • Preconditions: System is fully configured and app is installed on iPhone, user is logged into the application.
  • Trigger: The user wants to sign out of the application.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user swipes left to right on the application’s main screen, bringing up a sidebar display.
    • The user selects ‘Sign Out’ on the sidebar.
    • The application returns to the login screen.
  • Exceptions:
    • The user decides not to logout of the system.
  • Priority: Very high
  • When available: First iteration
  • Frequency of use: Medium
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • Should system prompt users to ask if sure?
    • What should be saved on logout?
    • Should editing the settings require the user to login again?

Edit Settings - Delete Account

  • Primary actor: User
  • Goal in context: To delete the user account.
  • Preconditions: System is fully configured and app is installed on iPhone, user is logged into the application.
  • Trigger: The subscription user wants to delete his account.
  • Scenario:
    • The user launches the application from the iPhone menu.
    • The user swipes left to right on the application’s main screen, bringing up a sidebar display.
    • The user selects ‘Settings’ on the sidebar.
    • The user selects ‘Edit Settings’ on the menu.
    • The user selects ‘Delete Account’ on the screen.
    • The system prompts the user to confirm they would like to delete their account.
    • The user selects ‘Delete Account’ to delete their account or ‘Cancel’ to return to the ‘Settings’ sidebar.
    • If the user selects ‘Delete Account,’ the user’s account is deleted, all connections to the user’s account are deleted from the MyM system, and the user is then returned to the login screen.
  • Exceptions:
    • The user decides not to delete their account.
    • The user does not authenticate their account.
  • Priority: High
  • When available: Second iteration
  • Frequency of use: Very Low
  • Channel to actor: Via iPhone display
  • Secondary actors: None
  • Channel to secondary actors: N/A
  • Open issues:
    • What exactly needs to be done on the back-end to accomplish this?
    • Is any additional verification needed for account deletion?

Mock Up Images:

In the login screen, the user will be able to login to an existing account, or register for a new account on the top left. At the bottom left, the user can access the About information.

This is the settings screen. Users can access and change information about their account such as their password in the Account tab. You can delete your account inside the General tab. The Sharing tab allows the user to set their options for sharing their maps and their moments. The Privacy tab allows a user to set who can view and follow their Maps and information about their account. The Notifications tab allows a user to set what notifications will be shown to them in their recent activity. Notifications could also be sent to a phone or an email. The Security tab allows a user to set up more authentication steps for logging into their account. The About tab displays information about the app, such as copyright information and the names of the app’s creators.

This is the main Map page that a user will see upon successful login. The - symbol will be a + on start up, but can be expanded to display the various methods of adding moments to your Map.

A user can click on a moment on their Map or their friends’ Maps to display the moment as seen above. The user can click the small blue arrow to bring up more detailed information about the moment such as comments and tags.

Swiping left to right brings up a menu of various options for the user to access. The user can view their profile information, view a listing of their trips, view their recent activities (notifications), view their friends list (includes who they are following), view their settings, and sign out from the session.

Swiping right to left brings up a list of all of the user’s friends and people they follow. Using the search bar they can search for a specific friend.

This is the menu that appears when a user chooses Friends List from the menu shown by swiping right to left on the main Map screen. A user can click the top left icon to return to the map and can use the dropdown menu in the top right to filter between friends, followers, and people you are following. The search bar can be used to find a specific person.

This is the built in camera interface that launches when a user chooses to create a new picture/video moment from the expanded icon menu on the main Map. The options button allows a user to set flash to be on/off/auto, to switch between the front and back camera, and to turn gridding on/off. The bottom left arrow icon returns the user to the main Map. clicking the camera icon takes a picture whereas clicking the red dot starts a video recording. The picture icon in the bottom left allows a user to choose an image/video from their pre-existing camera roll.

After a photo has been taken for a created moment, the user chooses to add a caption, tag any friends, and selects a trip to add the moment to. Sharing the moment finishes its creation and pressing back exits the creation of the moment.

This is the screen that a user is taken to when choosing to create a “note” moment. The user can type the note, add a caption, tags friends, and select a trip to add it to.

This is the screen that is shown when a user clicks the small blue arrow after clicking a moment on a map. The moment is displayed and the caption, friend tags, and comments are shown. A user or friend can create a new comment about the moment and the owner of the moment can edit its information.

This is the screen is when you select a user from the search list that is still not your friend. You won't be able to see the map unless the other person accepts your friend's frequent. If the user don't accept friend'’ request, only followers, you are going to be able to follow the user instead of friending him.

Elaboration: Design

Final report was edited for grammar and consistent clarity. No significant changes were made aside from updated interface images and diagrams. A joint document is here. The original is here. The updated version is in full below for convenience.

Shneiderman’s Eight Golden Rules of Interface Design are a set of standards that should be taken into account with all design projects in order to strive to make the best quality project. These standards are relevant in our project because as projects like ours become more streamlined, such as in a mobile device, the speed and quality of a solution become more and more important. Thinking about the eight rules helps us plan our project to deliver a high quality end result. The rules relate to: consistency, quick use through shortcuts, informative feedback, dialog closure, elegant error handling, reversal of actions, locus of control, and reduced short term memory load. As each of these rules are explained further below, it becomes more apparent how these qualities are not only necessary in a project like ours, but also how most of what they encompass should be expected.

1 - Strive for consistency

Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout.

By keeping our visual and interaction design consistent with other iOS applications, we ensure that the learning curve is going to be easier and that the user will enjoy using the application. As a result, the chance of the user not knowing what a specific button does is reduced. The idea is to build an application that is easy to learn and master.

By keeping a consistent visual and interaction design within the application, we ensure the user will always get the expected result out of an action.

For example, we have the “Log In” screen, which looks like any other Log In screen. This ensures that the user will be familiar with what is presented to him, reducing the learning time.

An example of consistency within the MyM application is the screen to post a new Moment. The screens to post new Moments will look similar, regardless of the content the user posts. The only difference is the top half of the screen, which is going to depend on what kind of Moment the user wants to post. This is beneficial because the user will be familiar with the screen layout.

2 - Enable frequent users to use shortcuts

As the frequency of use increases, so do the user’s desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user.

We want users to keep using our solution, which is why we are are offering every functionality two or three taps away. We will also implement swipe actions, that are fast and intuitive to be used as shortcuts to common tasks. As an example we have the little menu at the very bottom, that once it is clicked it will expand into three options: share picture, note or video. This is really practical and save us a lot of space in the screen and let the user focus on what is important. On the right we have an example of the swiping menu that will provide fast access to main features.

The application will utilize a swiping menu on the left that gives the user access to all main functionalities.

3 - Offer informative feedback

For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.

The application will be using a mix of colors, animations and pop-ups to give feedback to the user, leaving no ambiguity regarding the status of the action. The user will always have full control of their actions. At many points we will offer the user the ability to cancel the current process.

A third party library AJNotificationView will be used to display warnings and error messages effectively without being distracting.

4 - Design dialog to yield closure

Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.

Our application has three major action sequences available to the user: sharing a moment, adding a friend, and viewing a moment. All main action sequences end with the user viewing the main map screen or an appropriate AJNotification. Users will be directed through the action sequences if they so choose, but will know they have completed their chosen action when the map reappears with new content or they receive a notification.

5 - Offer simple error handling

As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error.

There will be a large amount of redundancy built into the application to assure that serious errors are not incurred. Moments, for instance, will not be able to be shared with anything less than the required amount of content.

Another issue is network connectivity. Although not necessarily under the user’s control, the app should not allow the user to enter or access content without a stable network connection. If it did, the user could encounter the frustrating case of a hanging or unresponsive app. If the user loses a network connection, the application will gracefully save its state, including any existing user input, and display a modal notifying the user of the dropped connection.

6 - Permit easy reversal of actions

This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.

Users will always be able to undo their actions. The application will allow the user to: edit account, remove moment, and remove account. This will let users fix/undo any undesired actions.

7 - Support internal locus of control

Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.

The default state of the application is the map view, displaying the user’s and their friends’ moments. The map view will not change unless the user takes an action: posting a moment, navigating the map, or opening up one of the menu options. If the user posts a moment, the map will zoom to the new moment. If the user navigates the map, it will respond appropriately. The application will at no time bother the user to attend to notifications, bug them to post something, or otherwise get in the way of the user’s experience. It will simply display appropriate options at each point in time, making them available yet unobtrusive.

8 - Reduce short-term memory load

The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.

A user only ever has to worry about one action at a time, and each action is walked through in a logical order, so the user only has to input one thing at a time.

A user is always doing only one of the following: Sharing a moment Viewing the map Viewing a moment Viewing Friends Editing the settings / profile

Class Diagrams

View Controller Class Design Diagrams

Alt text

Model Class Design Diagrams

System Sequence Diagrams

Sign In

Register New User

Map

Friends List

Add Friend

Profile & Settings

Create Moment

View Moment

Construction: Implementation

The source code for the MyM project, along with its documentation, can be found in this Github repository.

Construction: Testing

To ensure that the application was working properly, we conducted a series of tests.

Registering:

Ensure that the user has entered valid information. The first picture has an empty username. The second one we provided two passwords that are not equal. For both cases we got a warning telling us that the information was not right.

On the first picture we provided a password that is too short and on the second one we provided a username that is already exists. For both cases we got a warning telling us that the information was not right.

To ensure the registering process was also creating an account. We provided enough information to be able to create an account. As expected we were pushed back to the login view. A banner stating that the account was created successfully also showed.

Login

Once we got the registering to work, we were able to test the login. We first provided wrong information to ensure that wrong credentials would not let a user sign in. Providing the correct credentials, redirects the user to the main view, the map view.

Awesome Menu and Navigation Menu

To speed up the navigation within the application we provide the user two, one touch away, menus. The awesome menu and a navigation menu.

Moment Creation

During moment creation, there is a potential for two different types of errors that need to be checked. One is where the user exits the camera and provides no picture/video content. This type of error can also occur in a text moment creation where the user doesn’t input any text. The lack of content, if the user presses submit, will cause an error message to show.

The second type of error that may occur in any of the three types of views is for a moment to to not have a caption.

Once a moment has all of its required content to be created, the moment is added and a pin, once the information is uploaded and the user is taken back to the map, will be dropped down on the map.

Moment Detail

From the map view, a moment pin may be selected. If the user clicks on the the accessory button on the pin view, it will load a moment detailed viewer. Depending on the content type, it will load one of three views. A text view which will load the text in order to view the moment, a picture which will represent the picture moment, or a video banner image which if clicked on will start the stored video of the moment.

Once clicking on the play button, a movie player is loaded with the moment video which on screen controls to view the video.

Last, the user may view a list of information including, moment tags, date created, who the moment was created by, the type of moment, and a method to delete the moment (so long as the user owns it). Once clicking the delete button, the user must confirm to actually delete the moment.

Moments on the Map

After creating some moments, we had to make sure we could see all the moments on the map. Creating a new moment, generates a new pin on the map.

Friends and Gravatar

The first thing we tested was if we could see all the people we could request friendship, among with that, we tested it the Gravatar avatars were working properly. As you can see,user that have their email as their gravatar email get a profile picture. Otherwise you get a default picture. Clicking on one of the users send a friend request.

An email confirmation is going to be send to the user you want to be friends with. The user must accept your friendship.

Account Settings

We also tested if the Settings view was loading the proper information from the server

Transition: Maintenance

The source code for the MyM project, along with its documentation, can be found in this Github repository.

Transition: User Instructions

MyM Manual - DEVELOPER

There are two components to the MyM application: an iOS application, and a backend running on Amazon Web Services.

The iOS application was built using XCode 4. The .xcodeproj in the repository should be able to be used by anyone else using XCode 4.

The backend is a collection of AWS resources: an EC2 instance running a custom Rails application, an RDS instance for user account management, an S3 bucket to store user content, an SES sender for mail delivery, and IAM to manage access to these resources across the iOS and Rails applications. A guide to getting these resources up and running together can be found [here][The-MyM-Backend], and is duplicated below for convenience.

EC2

The MyM backend is a Rails server running on EC2, specifically, an EC2 micro instance running the Amazon Linux AMI. Rails accesses RDS and SES resources using IAM.

To prep a fresh AMI for use, use the following guide. Substitute appropriate current version numbers as necessary.

// update defaults
sudo yum update

// install basics
sudo yum install git
sudo yum install gcc
sudo yum install gcc-c++
sudo yum install make.x86_64
sudo yum install openssl097a.x86_64
sudo yum install openssl-static.x86_64
sudo yum install python-devel
sudo yum install sqlite-devel

// install rvm
bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)
echo [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bash_profile
source ~/.bash_profile
rvm install 1.9.3 && rvm use 1.9.3 (workaround if fails because of patch - run "rvm get head" and then "rvm install 1.9.3 --autolibs=3")
rvm rubygems latest

// install mym dependancies
gem install aws-sdk
gem install rails
gem install therubyracer
Rails

The Rails runtime environment is set in ~/.bash_profile.

Running the server in detached mode:

rails s -d

Kill a detached server:

cat tmp/pids/server.pid
kill -9 [pid]
rm tmp/pids/server.pid

SES

For SES functionality an SES verified sending address will need to be setup, ideally with "production access" sending limits (10k/day, 5/s). This address can then be used within Rails (app/mailers/user_mailer.rb) to send the welcome and friend request emails.

RDS

SQLite is fine for the testing and development environments in Rails, but for production, an RDS instance should be provisioned.

MyM is currently using a 5GB db.t1.micro running MySQL, but of course this is flexible.

Once the instance is available (it can take ~20mins to become accessible after provisioning), the config/database.yml can be edited to access RDS for production. Don't put the access credentials directly in the YAML though: set them in your ~/.bash_profile (or equivalent).

S3

No setup is required on for S3 aside from provisioning a bucket and changing the references to that bucket in the iOS code. For interest's sake, however here is the information on how S3 storage is organized.

Moment data is stored flat in an S3 bucket as follows:

set Identifier:

latitude_longitude_title_username_timestamp
(eg. 3.546318_-69.960938_Bike Ride_adamc_1366135254)

set Content-Type:

image/png
audio/mpeg
video/mp4
text/plain

set Caption:

lalala

This schema is used so that the mapview only has to query S3. When a user wants to view a moment in more detail, the additional data (namely, comments) will be accessed from RDS via the Rails server.

IAM

IAM is used throughout the application ecosystem to manage access to the various AWS resources.

A user profile should be set up to limit the server's access to RDS and SES, and a similar arrangement should be made with iOS's access to S3.

iOS accesses the core MyM functionality through HTTP requests, so it's access is inherently limited. By keeping core functionality within the AWS infrastructure, we can maximize security and reduce possible entrypoints for malicious attacks.

MyM Manual - USER

When you first open the application you will be brought to the Sign In View.

Sign In

At the bottom of the view is a button to create a new MyM account called Register. Clicking this button will send the user to the Register View (see below for intstructions). Next to the Register button is an up arrow surrounded in a white square. Swiping up from this arrow will display a scrollable About View, which explains MyM, provides the names of the developers, and gives a list of third-party libraries used. Once you have registered an account, you can input your username and password into the appropriate text boxes and click Log In to log in to your account.

Register

The register view has six fields that are all required to set up a MyM account. The first field is the username you will use to sign into your account and that will be displayed on the map callouts for your moments. The second field is the name that will be displayed on your friends’ friends lists. The third and fourth fields are the password that will be associated with your account. Your password must be at least eight characters in length to be valid. Finally, the last two fields are for a valid email address to send emails to for successful registration and friend request confirmation links.

Map

The map is the bread and butter of MyM. When the map loads for the first time it will zoom in on the user’s current location. Users can replicate this zoom again by pressing the zoom button at the top right of the screen. On the map, all of your moments and your friends’ moments are displayed as pins. Clicking on a pin displays a callout with the username and title of the moment as well as a detail disclosure button, which when clicked will send the user to a detailed view of that moment. At the bottom right of the screen is the create moment button. Clicking on the button brings up three additional buttons, each pertaining to a specific moment type: Picture, Video, and Text. Clicking on one of these buttons will launch the respective moment creation view. Clicking on the create moment button again will dismiss the three additional buttons. Users can make their navigation menu appear by clicking on the menu button at the top left of the screen or by swiping from the left side of the screen. This menu has three buttons: Friends, Account Settings, and Sign Out. Clicking on the Friends button will launch a new view that displays all the user’s friends. Clicking on the Account Settings button will display the user’s profile and allow the user to change their password and email as well as permanently delete their account. Clicking on the sign out button will end the current user session and return the user to the sign in view. Tapping anywhere on the map or clicking the menu button again will dismiss the menu.

Friends List

The friends list view displays all of the user’s accepted friends. The user can either use the section index control along the right side of the screen to find a friend alphabetically, or search for a friend’s name in the search bar. If a friend is clicked, the application will launch a new view displaying the friend’s account information and a button to delete that friend from the user’s friends list. A user can also replicate this deletion functionality by swiping over a friend’s name on the friends list and clicking the delete button. Pressing the + button at the top right of the view launches a new view to add friends to a user’s friends list.

Add Friend

This view displays a list of all users currently registered on MyM. A user can once again use the section index control at the right side of the screen or the search bar to find a specific user. If the current user clicks on another user’s name a friend request alert will be displayed on the screen. If the user clicks send, then a friend request email will be sent to the potential friend. A user can forgo searching for the user’s name and simply send a friend request email directly to a user’s email by clicking the add by email button at the top right of the screen, entering the email, and then pressing send.

Account Settings

The account settings view will display the user’s profile picture, username, password length, email, and friend count. By clicking on either the password or email field the user can change their email by confirming their current password and then inputting the new password or email. A user can click the field displaying their friend count to display their friends list. Finally, the user can delete their account permanently by clicking the delete account button at the bottom of the view and confirming the deletion. If a user deletes their account they will be forcibly moved to the sign in screen.

Create Moment

This view is called by the main map view. Depending on which of the three buttons the user clicks on (Picture, Video, Text) determines the behavior of this view in order to create the respective moment type. Each type allows the user to enter a caption for the moment and a space delimitated string of tags.

If the user clicks the text moment button, the moment initializes with a text field view which will allows the user to type a text note to describe their moment.

If the user clicks the picture moment button, the moment initializes the camera in order to take a picture. After taking a picture, the photo is selected and presented to the user on the moment creation view. After the photo is created, the user can either tap the photo to take a new one or click the submit button (after filling out at least a caption for the moment) to successfully create a new photo moment.

If the user clicks the video moment button, the moment initializes the camera in order to take a video. The video has a time limit size of 5 seconds. After taking a video, the video is selected and then loaded and prepared to a movie player. This allows the movie to be played if desired. Also after taking the video, a thumnail is created and presented to the user as done in the photo moment. Like the photo moment, clicking on this thumbnail will allow the user to retake a video or click the submit button (after filling out at least a caption for the moment) to successfully create a new video moment.

There is error checking to protect from incorrect moment entries. If the user tries to create a picture/video moment and then cancels the camera view, a no content view is created to give the user an opportunity to restart the camera without having to exit the view.

There is also protection against a user submitting a moment without content.

Display Moment

This view is called by the main map view. Once a user selects a moment pin, they can click on the accessory button which calls an instance of this view. Depending on which of the moment types the pin represents (Picture, Video, Text) determines the behavior of this view in order to view the respective moment type. Each moment type follows the same format, the content of the moment is viewed at the top followed by a list of its attributes; moment tags, date created, who the moment was created by, and its type followed by a delete button at the bottom of the view. A user may only delete a moment if they created it. They can not delete other user's moments.

This view is only meant to view the moments, not to edit the information but in some cases, depending on the moment type, the user can interact with the moment viewer. If the moment text is longer than the view, the user may scroll the text view to see the remaining text. If a video view is present, the user may tap the play button at the top, which is where the moment content normally is in order to play the video. There is no user interaction, other than moment deletion, for viewing pictures.

In order to delete the moment, a user must first be the owner of the moment. Once entering the moment viewer, the user can scroll to the bottom of the view to the delete button. Once clicking the button, the user must confirm there deletion. Moment deletion is permanent.

Experience and Conclusions

Each teammate submitted two essays individually to the Canvas Dropbox.

Clone this wiki locally