A web app that allows users to post when they need to crash for a night. Other users can see these posts so they will know who to contact if they want to be a good Samaritan.
- Ember
- JavaScript
- Handlebars
- Bootstrap
- Fork and clone this repository.
- Install with
npm install && bower install - Run the front-end server with
ember server
Whether it's for a pre-planned trip or for a reckless night, everybody goes through a moment when they need to crash somewhere. I always see posts on Facebook asking for help from friends for their vacations, and back in college I had a couple friends who would crash at my place for a night if they weren't good to drive. I'm a big fan of safety first, so why not create an app to focus on these short term (or long term) couch needs? Originally, I wanted to implement friendships because I feel safer going to a friend's house than not. This is still a goal, but one I could not meet within one week.
I had an idea of what I wanted the back-end to look like with friendships, but
after thinking seriously about the scope of this project, I simplified it to
something managable with Ember. I made several ERDs to plan out the
friendships, which I plan to use later, but for this project I settled on a
simple user has_one profile, profile has_many couchposts, and user
has_many couchposts through profile.
This was my first Ember App, so I had concerns about structure on the front-end. I used General Assembly's talk on Ember as a reference to create a paper prototype. While we see everything on a two-dimentional screen, Ember seemed like a three-dimensional framework, so I needed a visual explanation of everything Ember does. Images of the paper prototype are below.
After figuring out all my components, I began my project with a small list of to-dos on the projects tab on GitHub. I filed some issues directly into my project repo, but for the most part my issues went into General Assembly's capstone repo, and I'd reference those resolved issues on the app repo. I used my issues to structure each day, so I kept to a fairly straightforward schedule. I spent a longer time on the front-end than I usually do because I'm not familiar with Ember, but ultimately I'm pleased with how this project went.
I had an adventure learning Ember. I had to frequently reference my paper
prototype just to figure out how Ember wants components named, which direction
was "up" vs. "down" when sending data down, actions up, and keeping track of
what components did what. My biggest complications came with connecting models
to the API, as my requests were declaring certain attributes as nil, such as
profile_id even though I thought attributes such as foreign keys would
persist. I learned a lot more about the serializer's relationship and role
between the front-end and back-end, and ultimately defining everything clearly
in the back-end serializer helped me point my data in the right direction.
Some of my biggest difficulties came with the date. My back-end was
saving dates on my local timezone, but Ember was converting them to GMT. I
learned that I could solve this by creating a transformer that takes the data
from the back-end serializer and deserializes it into something that the
front-end can display. I utilized Moment.js' moment.utc to convert the
dateNeeded to my time-zone and reformatted it to something more appealing for
users.
I definitely want to implement some kind of friendship feature. I need to take some time and study friendships on both the back-end and the front-end. I got close to figuring this out on the back-end, but again, I decided to prioritize making a complete product over making something with friendships.
This shows the different layers of the front-end of my app. Each layer represents a route or a component. For example, the large white page is the main application route. It shows the path to each file and general basic layout of the page. Each "component" also shows the file path and has interchangeable "nested components" on them. The post-its represent the nested components. Folded up, they show what the user would see, but opened they show the path to the necessary files. I referred to this prototype every time I faced a wall or got confused about nesting.
Sign-Up View
User Interface for Sign-Up
Path to Ember files for Sign-Up
Closer Look at Nav-Bar
New Couchpost View
Edit Couchpost View
User Interface for New and Edit Couchpost
Path to Ember files for New and Edit Couchpost
Couchpost List View
User Interface for Couchpost List
Path to Ember Files for Individual Couchpost
- Create account
- Create profile
- Sign in
- Change password
- Sign out
- Send post
need a couch - See other users' posts
- Update their post
- Delete their post
- User can update their profile
- User can search for friend (have them search by id first)
- User can add friend
- User can accept friend request
- User(in need) can specify “emergency” or “future trip”
- User(with couch) can respond to alert
- User(in need) can request Lyft to user(with couch)’s house
- User(all) can see how many times a friend has responded to an alert
- The idea is you’re more likely to be accepted to a couch if you offer your couch a lot
- User(all) can direct-message a friend (with details of trip or something)
- User can receive “emergency” push notifications
- Good for drunk friends or friends who don’t feel safe at home
- If “future trip”, then user can specify dates the couch is needed
Couchpost Page
New and Edit Couchpost Forms
Pitch Deck Wireframe
