Load-In Road

• 

  Login Page

• 

  Tracking the carrier's location

Inspiration

We decided to tackle two pain points, one for the carriers, and one for the shippers.

Pain Point for Carrier

Problem

Carriers often look for the highest paying loads, regardless of the destination. However, brokers either don’t include the rates in their posting, or provide rates that too low for carriers to make a profit.

Ideal Goal

Increase the prices on load listings by encouraging brokers to increase posted rates, without discouraging them from posting their loads.

Pain Point for Shipper

Problem

Despite the presence of many location dependent features that would help carriers find good loads, carriers often do not enable their location services within the load board app due to privacy concerns. This means brokers do not know the location of their loads as they are being hauled and must rely on updates from the carriers.

Ideal Goal

Increase the number of users that enable their location services.

Why These Two Pain Points

We realized that both had a similar problem: the lack of information from the other party. In fact, carriers often want the shippers to display their rates so that it is easier for them to choose a job that pays better. On the other hand, shippers often want to have access to the carrier's location so that they can have instant updates on the location of the carrier, and whether the job is completed or not.

What it does

For our project, we implemented a web application that would be similar as the basic 123LoadBoard platform. However, on this webpage, carriers must agree to share their location to select jobs, and shippers must include the price of a job for it to be posted. This way, users who do not wish to disclose this information could simply use the regular website, whereas ours would ensure that a minimum amount of information is provided.

How we built it

Our project is a web application built using HTML, CSS, JS and some librairies/frameworks. The front-end was made entirely of raw HTML and CSS code, whereas the back-end used JavaScript, but also nodeJS and expressJS. We used MongoDB for the database, and used mongoose to help implement the interaction from user to database. To test our code throughout the whole competition, we used nodemon to run the web application to see our changes in real-time.

Challenges we ran into

One challenge we struggled with was to connect the front-end with the back-end, particularly with the login and signup pages. We had difficulty verifying and authenticating the user whenever they logged in, and we had a bug where a new account would always be of type carrier (users could not create shipper accounts).

What we learned

This was our first web application project using JavaScript. We learned a lot about how to use JavaScript for the front-end to interact with the back-end through a service layer, to a database layer to provide the required information to the user. We learned a lot about the structure of a JavaScript web application.

Implementation

Our solution is a web application that allows clients to create a shipper or carrier account, and to display their rates for each job or enable their location, respectively. This way, both parties will provide more information, but will also have access to more information.

Front-End

The web application's UI is built using HTML and CSS files, as well as some JavaScript to interact with the user.

The front-end first redirects the user towards the login page, where they have the option to signup (create a new account).

Then, shippers are redirected to their jobs page, where they can post new jobs, edit previous jobs or delete unselected jobs. In order to edit a job, it must not be chosen by a carrier. Furthermore, shippers dispose of the option to track the location of the carrier for ongoing jobs (jobs that have been accepted), which redirects them to a new page where they can see the location of the carrier (updated every 0.5 second).

Carriers are redirected to a browsing page, where they can view available jobs and select one to do. They can also go to their ongoing jobs to see which one they have already accepted (for instance, check when they should deliver tha load).

Back-End

The user communicates with the web application thanks to JavaScript and NodeJS. Express is used to interact with the user and handle the user requests. These requests are then passed to the service layer, which communicates to the Mongo Database using mongoose.

Schemas

There are two main schemas to represent the data: User and Job tables/collections.

User Schema

Attribute	Required	Unique
Username	Yes	Yes
Email	Yes	Yes
Password	Yes	No
Client Type	Yes	Yes

• Username: Used for display
• Email: Used for login credentials
• Client Type: Shipper or Carrier

Job Schema

Attribute	Required	Unique
Shipper	Yes	No
Carrier	No	No
Posted Day	Yes	No
Expected Delivery Date	No	No
Pick-Up Point	Yes	No
Drop-Off Point	Yes	No
Rate	Yes	No
Cargo Weight	Yes	No

• Shipper: Set to the job poster by default
• Carrier: Set to null to display an available job
• Posted Day: Initialized as timestamp
• Cargo Weight: Required, as carriers have a maximum capacity

Note that the posted date is not a value that the shipper can enter, as the value will be generated automatically my express and mongoose when creating the job posting (using Date.now() and {timestamps: true}).

Location Tracking

When selecting an ongoing job, a shipper has the option to track the live location of the carrier. By clicking on the tracking button, the shipper gets redirected to a new page that diplays an interactive map. The location of the carrier is then querried and updated every 0.5 second (half-second).

What's next for Load-In Road

We were thinking about the option of migrating the complete 123LoadBoard platform to this web application. The difference would be that users would have a "premium" option, which would be what our project is, and the regular option, which does not require to show the rate/enable your location. We believe that this way, our project would seem even more appealing.

As future work, we thought that it would be a good idea to add the option to be able to edit jobs. We also wanted to rework the database and use a more accurate location tracking program.

For future ideas, we wanted to make an option where whenever a carrier would accept a job, the money would directly be withdrawn from the shipper's account. However, the money would be "on hold", and transfered to the carrier only once the job is complete. If the job would be cancelled, then the money would be returned to the shipper.

Built With

• css3
• express.js
• html5
• javascript
• mongodb
• mongoose
• node.js