Bike Ridr!

This is the developer documentation for a bike ride logging application that refers to an specifically designed API for user authentication and ride storage. The developer used the Atom text-editing platform, along with git and other software to write and test the code. The developer wrote the client facing code using HTML, SCSS (CSS) and JavaScript (the API was written using Ruby on Rails).

Github Repository Links

The Github repositories for this project are located here:

• Application Client
• Application API

Deployed Sites

• Bike Ridr Client
• Bike Ridr API

What is Bike Ridr

Bike Ridr is an application that can be used by cyclists to log date, location, distance and time data from their bike rides; then review, edit or delete previous ride data. The user creates a unique, password-protected account; then the user enters new ride data on a form that is provided and/or views all of their existing rides, if any exist.

Wireframes

Initial wireframes images:

1. Signed out/initial page.
2. Signed in page.

3. New Ride input page.
4. Ride history page.

User Stories

Bike Ridr user stories:

1. As a first-time user, I want to create a user account.
2. As a user, I want to record (create) a new ride record.
3. As a power user, I want to know my pace after providing my time and distance.
4. As a returning user, I want to search for, update or delete previous ride data.

Entity Relationship Diagram

Technologies Used

The following technologies were used to create this project:

1. HTML.
2. SCSS.
3. JavaScript.
4. JQuery.
5. Node.js.
6. Ruby on Rails.
7. Pry.
8. PostgreSQL.
9. Atom.
10. Git.
11. Github.
12. Heroku.
13. Grunt.
14. Curl.
15. AJAX.
16. Bootstrap.

Development Process and Problem-Solving

This project started by developing an initial project scope, which was modified as necessary during development:

1. Developed application idea, and determined diagrammed ERDs for successful creation.
2. Scaffolded database tables for API.
3. Developed wireframes for desired user interface.
4. Made considerations for how various in-app screens would be displayed.
5. Placed heavy emphasis on meeting minimum viable product first. Initially applied minimal SCSS to ensure that the user experience met requirements, and additional styling was added near completion as time permitted.
6. Placed heavy emphasis on performing new tasks in new branches and making regular commits. Branch names explain what changes were made on that branch, and often include just one commit.

Improvements/Unsolved Problems

The following improvements could be made:

1. Improvements to interface for more user-friendly experience.
2. Create user profiles to enhance/personalize each user's experience, and to enable interaction between user accounts (eg. view another user's rides).
3. Ride history table data sorted by date.
4. Output average speed of rider during activity.
5. Modals for user inputs.
6. Logo and animations for buttons.
7. Help documentation.
8. Provide additional pseudocode for understanding what is being done.
9. Refactor code for improved readability.
10. Inputs for additional ride data (eg. cycling cadence).
11. Input ride data in tabular format.
12. Resolve formatting issues on various screen setups.