View the live App

Check out our GitHub

Table of contents

Overview of Manoa Rides

Manoa Rides is a carpooling application for the University of Hawaii community. Manoa Rides enables members of the University of Hawaii to pair drivers in search for riders, or riders in search of a driver, and create their own carpooling solutions.

Carpooling solves two problems, many people have difficult getting to and from campus and others who do drive would simply enjoy the convinence of carpooling benefits such as parking, HOV lanes, or maybe a snack from a gracious passenger.

Manoa Rides allows drivers and riders to easily find one another based off of proximity and when they would like to head to or from school. This is a completely free service and we encourage the users to negotiate with one another as to what a fair compensation for the drivers might be as they would be going out of their ways to pick up a passenger or two. Some drivers may be more than happy to do so for free, while others may ask for a few bucks for gas money, a small snack, or even a funny joke!

By limiting this service to members of the UH community every rider or driver is accountable and known—a UH email address is required to create an account. This exclusivity makes the expierence more trustable and safe for users.

Summarily, Manoa Rides aims to provide an organic and safe way to make the regimented process of getting to and from class easier for those within our community. We hope you find it useful!

User Guide

To sign up for a new account or login to an existing account click on the login button and enter your University of Hawaii login information.

After logging in, you will be directed to Create/Edit profile page. At the Profile Page you can specify things like your full name, whether you are posting as a rider to a driver, a picture of yourself, the capacity of your car, a picture of your car, a short bio, and the zip code in which you live. To edit this page in the future simply click on the profile tab.

To upload the times you want to go and come from the University of Hawaii, you can access the schedule page and set your weekly schedule so other Drivers/Riders can connect with you.

You can view your complete profile and schedule on the Home Page where your public profile is listed.

To search for Drivers or Riders click on the Drivers or Riders tab. You can search for Drivers and filter based on time they commute, their zip code, and the number of seats they have in their car.

You can search for Riders and filter based on their commute times and their zip codes.

Installation

First, install Meteor.

Second, download a copy of Manoa-Rides, or clone the repository using git.

Third, cd into the app/ directory and install libraries with:

$ meteor npm install

Fourth, run the system with:

$ meteor npm run start

If all goes well, the application will appear at http://localhost:3000. If you have an account on the UH test CAS server, you can login.

Developer guide

Branches

When creating a new branch for the project use issue-XX naming conventions. This way branches can be directly tied to the issue they correspond to.

$ git checkout -b issue-XX

Make sure that master always has working code.

To change branches:

$ git checkout [issue-XX or master]

Make sure to:

$ git pull

frequently from the master branch. This assures that you will have the most recent working code from other people.

Meteor Website

To use and make a meteor app website, first create an account on the Galaxy website After creating an account it will be costly to push any website onto galaxy so it’s best to work with an organization that has limited slots but will be able to push your website for free.

For more instructions, please at E54: Test deploy to Galaxy

Directory structure

The top-level directory structure contains:

app/        # holds the Meteor application sources
config/     # holds configuration files, such as settings.development.json
.gitignore  # don't commit IntelliJ project files, node_modules, and settings.production.json

This structure separates configuration files (such as the settings files) in the config/ directory from the actual Meteor application in the app/ directory.

The app/ directory has this top-level structure:

client/
  lib/           
  head.html      # the <head>
  main.js        # import all the client-side html and js files (important if creating or deleting any directories)

imports/
  api/           # Define collection processing code (client + server side)
    base/        # BaseCollection is an abstract superclass of all RadGrad data model entities.
    eventdata/   # Represents specific eventdata.
    profile/     # Profiles provide portfolio data for a user.
    user_accepted_listings/
  startup/       # Define code to run when system starts up (client-only, server-only)
    client/      # Contains the router and user account-configuration.js page to link other pages
    server/      # Initializes the database and publish the interest and profiles.
  ui/
    components/  # templates that appear inside a page template.
    layouts/     # Layouts contain common elements to all pages (i.e. menubar and footer)
    pages/       # Pages are navigated to by FlowRouter routes.
    stylesheets/ # CSS customizations, if any.

node_modules/    # managed by Meteor

private/
  database/      # holds the JSON file used to initialize the database on startup.

public/          
  images/        # holds static images for the website

server/
   main.js       # import all the server-side js files.

Import conventions

This system adheres to the Meteor 1.4 guideline of putting all application code in the imports/ directory, and using client/main.js and server/main.js to import the code appropriate for the client and server in an appropriate order.

This system accomplishes client and server-side importing in a different manner than most Meteor sample applications. In this system, every imports/ subdirectory containing any JavaScript or HTML files has a top-level index.js file that is responsible for importing all files in its associated directory.

Then, client/main.js and server/main.js are responsible for importing all the directories containing code they need. For example, here is the contents of client/main.js:

import '/imports/startup/client';
import '/imports/ui/components/form-controls';
import '/imports/ui/components/directory';
import '/imports/ui/components/user';
import '/imports/ui/components/landing';
import '/imports/ui/layouts/directory';
import '/imports/ui/layouts/landing';
import '/imports/ui/layouts/shared';
import '/imports/ui/layouts/user';
import '/imports/ui/pages/directory';
import '/imports/ui/pages/filter';
import '/imports/ui/pages/schedule';
import '/imports/ui/pages/landing';
import '/imports/ui/pages/user';
import '/imports/ui/stylesheets/style.css';
import '/imports/api/base';
import '/imports/api/profile';
import '/imports/api/interest';

Apart from the last line that imports style.css directly, the other lines all invoke the index.js file in the specified directory.

We use this approach to make it simpler to understand what code is loaded and in what order, and to simplify debugging when some code or templates do not appear to be loaded. In our approach, there are only two places to look for top-level imports: the main.js files in client/ and server/, and the index.js files in import subdirectories. In those subdirectories, they usually will contain any html, CSS and JavaScript files that the subdirectories will use.

Note that this two-level import structure ensures that all code and templates are loaded, but does not ensure that the symbols needed in each file are accessible. So, for example, a symbol bound to a collection still needs to be imported into any file that references it.

Naming conventions

This system adopts the following naming conventions:

Data model

The Manoa-Rdies data model is implemented by mainly using a Javascript class: ProfileCollection this class encapsulates a MongoDB collection with the same name and export a single variable Profiles that provides access to that collection.

CSS

The application uses the Semantic UI CSS framework. To learn more about the Semantic UI theme integration with Meteor, see Semantic-UI-Meteor.

The Semantic UI theme files are in app/client/lib/semantic-ui directory. Because they are in the client/ directory and not the imports/ directory, they do not need to be explicitly imported to be loaded. (Meteor automatically loads all files into the client that are in the client/ directory).

Note that the user pages contain a menu fixed to the top of the page, and thus the body element needs to have padding attached to it. However, the landing page does not have a menu, and thus no padding should be attached to the body element on that page. To accomplish this, the router uses “triggers” to add a remove the appropriate classes from the body element when a page is visited and then left by the user.

List of some of the Semantic UI used in this project: -Images -Accordion -Item -Grid -Container -Table

Routing

For display and navigation among its four pages, the application uses Flow Router.

Routing is defined in imports/startup/client/router.js.

Manoa Rides defines the following routes:

Authentication

For authentication, the application uses the University of Hawaii CAS test server, and follows the approach shown in meteor-example-uh-cas.

When the application is run, the CAS configuration information must be present in a configuration file such as config/settings.development.json.

Anyone with a UH account can login and use Manoa Rides to create a portfolio. The user will then create their own profile and image (and car image) to gain further access.

Authorization

The landing and directory pages are public; anyone can access those pages.

The profile and filter pages require authorization: you must be logged in (i.e. authenticated) through the UH test CAS server, and the authenticated username returned by CAS must match the username specified in the URL. So, for example, only the authenticated user johnson can access the pages http://localhost:3000/johnson/profile and http://localhost:3000/johnson/filter.

To prevent people from accessing pages they are not authorized to visit, template-based authorization is used following the recommendations in Implementing Auth Logic and Permissions.

The application implements template-based authorization using an If_Authorized template, defined in If_Authorized.html and If_Authorized.js.

Configuration

The config directory is intended to hold settings files. The repository contains one file: config/settings.development.json.

The .gitignore file prevents a file named settings.production.json from being committed to the repository. So, if you are deploying the application, you can put settings in a file named settings.production.json and it will not be committed.

BowFolios checks on startup to see if it has an empty database in initialize-database.js, and if so, loads the file specified in the configuration file, such as settings.development.json. For development purposes, a sample initialization for this database is in initial-collection-data.json.

Redeploy Meteor

Sometimes after editing fields in the profile field, or using new packages you may not be able to run the app on localhost in those cases this command sequence can help solve some errors:

meteor npm reset
meteor npm install
meteor npm run start

This should reset your local mongo and update your installed modules.

ESLint

BowFolios includes a .eslintrc file to define the coding style adhered to in this application. You can invoke ESLint from the command line as follows:

meteor npm run lint

ESLint should run without generating any errors.

It’s significantly easier to do development with ESLint integrated directly into your IDE (such as IntelliJ).

Development History

The development process for Manoa-Rides

Milestone 1: Mockup development

This milestone started on November 14, 2017 and ended on November 22, 2017.

For milestone 1 the goal was to get mockups off all the page we wanted, and get an idea of what the completed application would look like.

Mockups for the following four pages were implemented during M1:

Landing Mockup

Schedule Mockup

Profile Mockup

Filter Mockup

Milestone 1 was implemented as Manoa-Rides GitHub Milestone M1:

Milestone 1 consisted of 15 issues, and progress was managed via the Manoa-Rides GitHub Project M1:

Each issue was implemented in its own branch, and merged into master when completed:

Milestone 2: Implementing and Improving Functionality

This milestone started on November 23, 2017 and ended on December 13, 2017.

For Milestone 2 the goal was to take the page that we created in Milestone 1 and implement the fundamental functionality.

Five pages were implemented during M2:

Implemented Landing Page

Implemented Home Page

Implemented Schedule Page

Implemented Profile Page

Implemented Filter Page For Drivers

Implemented Filter Page For Riders

Milestone 2 was implemented as Manoa-Rides GitHub Milestone M2

Milestone 2 consisted of 23 issues, and progress was managed via the Manoa-Rides GitHub Project M2

Each issue was implemented in its own branch (unless it took less than 20 minutes to complete or was done directly through the mLab Mongo database), and merged into master when completed.

Community Feedback

After asking some of our friends, all outside of the computer science field to try out our app we came away with seven main points.

  1. All of them were not aware the UH had a carpooling system or application in place.
  2. Six out of the ten people asked used their own vehicle to drive to school. The other four used the bus.
  3. Most people both departed to school and returned home on a very regular weekly schedule.
  4. Motivations for potentially using the carpooling system were, in order, reducing transit time, reducing transit cost, and reducing pollution.
  5. When asked how they would carpool if they hadn’t known about app most said asking around.
  6. When asked if they would use our app for carpooling all of them said they would use our application only if it had a significant number of users. Their main concern was actually finding a viable rider or driver.
  7. Overall, the people who drove to school felt there was more incentive to be a rider than a driver. Most indicated that some sort of monetary compenstation was appealing. Though a couple drivers mentioned that they didn’t want to make profit, but rather offset a portion of gas and parking costs.