A3. Convergent Design
Product Pitch
TrailMix is a social media app for nature-enjoyers and hikers of all experience levels. The app allows users to document their hikes, creating trails which they can contribute posts/images to “on the go” or afterwards. These documented hikes will be visualized on a map on their profile (on which they can also pin their favorite trails and see statistics such as how many miles hiked) and can be posted publicly for others to like and comment. The app also allows users to coordinate hikes together through the creation of events where one may propose a hike on a certain date, with certain destinations along the way and invite users. Other users may view the event details (including attendees, destinations, estimated distance/elevation), start a discussion, and register. Users can also join a group that may be specific to their interests, level of experience, or location (Ex: “MIT Outing Club,” “Summit Hikers of Singapore”). Within this group, they can create new events and start new discussions as well. Users can look for these groups and events by filtering for certain tags, sorting by different criteria (“Dog Friendly Hike,” “Social Hike,” “Summit Hike,” “Intermediate Level Hike”), and searching by name.
Functional Design
Concepts
User
Name: User
Purpose: Stores a user’s credentials and all their information (posts, trails, events, groups)
Principle: A user can register for an account and sign in. When signed in they can be authenticated for certain actions (creating posts, joining groups, viewing things etc.)
State:
- username: string
- password: string Action:
- register(username: string, password: string)
- authenticate(user: User): boolean
Community Resource
Name: Community Resource (Event | Group)
Purpose: Manages the community resources which a user may join, Event or Group.
Principle: A user may create or delete their own community resources. Other users may join their community resources. Users can also search and filter through different community resources based on their tags.
State:
- resource: set Group | Event
- members: Group | Event → User
- users_resource: User → Group | Event
- users_owned_resource: User → Group | Event
Action:
- create_resource(resource: Group | Event, owner: User | Group)
- delete_resource(resource: Group | Event)
- join_resource (resource, Group | Event, user User)
- get_joined_resources(user: User): set Group | Event – gets set of all groups or events a user belongs to
- get_owned_resources(user: User): set Group | Event – gets set of all groups a events a user manages
- filter_resources(tags: set Tag): set Group | Event – gets set of all groups or events that match at least one tag in tags
- search_resources(query: string): set Group | Event – get set of all groups or events whose title matches the query
Post
Name: Post
Purpose: Manages the primary content of the platform
Principle: A user can create a post (share an event, contribution to their trail, or generic text post [questions, advice, etc.]) or delete a post. Posts can be made to a general feed of a feed specific to an event or group. A user should be able to load their posts.
State:
- posts: set Post
- post_authors: User → set Post
Action:
- get_posts(target: User | Group | Event): set Post
- create_post(target: Group | Event, author: User)
- delete_post(author: User)
Trail
Name: Trail
Purpose: Organizes hikes into a collection of points that together create a trail
Principle: A user can start a trail (whether as a proposal for an event or posting on their own profile) and continuously add points to it. As points are added, the total elevation and distance traveled for that trail are automatically calculated.
State:
- trails: Trails
- user_trails: User → Trails
Action:
- create_trail(author: User, start_point: Location)
- add_destination(author: User, trail: Trail, location: Location)
Map
Name: Map
Purpose: Spatial organization and visualization of geolocated information
Principle: A user may add a point (representing location of a group, destinations for a trail, locations of their posts, etc.) to a map.
State:
- map: set Map
- user_map: User → Map
Action:
- add_marker(location: Location, map: Map, user: User)
- delete_marker(marker: Marker, map: Map, user: User)
Tag
Name: Tag
Purpose: Manages metadata for content, helpful for classification
Principle: Tags can be added or removed from content (events, groups, posts). Ex: users can tag an entry to their trail with “Bird,” “Nature,” etc. Users can tag events to classify them in terms of difficulty, type of hike, etc. (“Dog Friendly Hike,” “Social Hike,” “Summit Hike,” “Intermediate Level Hike”).
State:
- tags: Post | Event | Group → set Tag
Action:
- add_tag(tag: Tag, content: Post | Event | Group)
- delete_tag(tag: Tag, content: Post | Event | Group, user: User)
Comment
Name: Comment
Purpose: Allows one to respond to content (posts or other comments) on the platform
Principle: A user can load comments for a post as well as write a comment in response to the post or any other comments on it
State:
- comments: Post | Comment → one Comment
- authors: Comment → one User
Actions:
- get_comment(content: Post): Comments
- post_comment(user: User, content: String, target: Post | Comment)
Like
Name: Like
Purpose: Allows one to express one’s approval or liking of a piece of content
Principle: A user can see the number of likes for as well as who liked a piece of content and also add or remove their like
State:
- likes: Post → set User
- user_likes: User → set Post
Actions:
- get_likes_count(content: Post): number
- get_likes_users(content: Post): set User
- add_like(content: Post, user: User)
- remove_like(content: Post, user: User)
Concept Note
The Community Resource concept is a refactoring of the Event and Group concept into one. This is because I noticed how both operated similarly in that when created, other users can join an event or group, and only once they join can they view and post in the forum specific to the group or event. The groups and events could also be filtered in similar ways. The difference between the two is that Groups may have Events and Trails documented within them and are similar to the User concept in that regard.
Synchronizations
We can synchronize add_destination/create_trail (Trail) or create_resource (Event or Group) with add_marker (Map) and add_tag (Tag) such that:
- whenever a user starts a new trail or contributes to a trail, it automatically populates as a marker on the map and adds a tag to it
- Whenever a new group or event is created, the home-base location for the group or the proposed trail for the event populates the map and the tags are attached to the resource such that users can filter for them
Same logic can be applied for deleting actions.
We can synchronize User with Post, Comment and Community Resource such that a user may only comment or create and view posts when they are joined or registered. Therefore we can use the user to authenticate beforehand.
We can also synchronize create_community_resource (Community Resource) and create_trail and add_destination (Trail) with create_post (Post) such that creation of trails, events, and groups will automatically create a post that can notify one’s network.
Dependency Diagram
Wireframes
Design Tradeoffs
Separate vs. All Together
- I had to figure out what was the best way to present new groups and events to the user in order to improve discoverability and engagement as well as management of these resources. I was deciding whether to create separate pages for the exploration of events and groups or combine them together in the feed.
- I decided to go with the first as having the separation looked cleaner and more cohesive and felt less overwhelming for each page. It also provided more real estate to include both the map and grid view for both. The tradeoff, however, is that there is less variety int content populating the feed and the user can't discover these resources "organically" as they would have to navigate to those pages specifically to find them.
Access to Discussions
- I was deciding between whether those that are not registered for an event or part of a group should be able to view discussions occuring within them. The first option would be that anybody would have access and the second would be that only those who joined may.
- I decided to go with the option that only those that joined may in the case that spammers or those with ill intentions will abuse the forums. It may be the case that the manager of the event or group may want to keep the resource private or limit general access in the first place so only those invited could engage in discussions. I should consider adding more flexible privacy options as a functionality. The tradeoff is that those who are curious about an event or group may not be able to learn more about them unless they join first. This may discourage them.
Live tracking
- I was deciding what was the best way for the user to provide live, on-the-go updates by leveraging the map functionality. I was deciding whether to include live-tracking which the user could turn on or off vs. having them upload the images as they hiked or alltogether at the end.
- I chose to go for the latter for safety reasons as one may use live-tracking for malicious purposes and it would feel too invasive. Live-tracking would have been useful, however, for group hikes if members were trying to locate each other or got lost. It would also be useful in that it could record the trail more accurately instead of predicting based off of fewer location points as the latter option would entail. However, this limitation of the latter option could possibly encourage the users to post more in order to document a more accurate record of the trail in terms of location points, time points, etc.