STUFF RIDE

_________________

For

CST 499 – Computer Science Capstone

at

California State University, Monterey Bay, Fall 2020

_________________

Faculty Advisor: Dr. Eric Tao

_________________

by

Christopher Caldwell

Sunday, October 11, 2020

 2

EXECUTIVE SUMMARY OF PROPOSAL

Stuff Ride

by

Christopher Caldwell

Bachelor of Science in Computer Science

California State University Monterey Bay, 2020

The goals for this Capstone project are to create an internet connected system where users

who need to transport large items short distances can connect with other relatively nearby people

capable of transporting those items. Conversely, this system provides a means for people capable

of transporting large items short distances to connect with users requesting such work.

The concrete objectives required to facilitate such a system include:

• A server backend which can respond to and serve user web requests. (PHP, Laravel)

• A live database architected to store system/user information. (MySQL)

• A front-end, mobile friendly browser interface. (HTML, CSS, JavaScript, VueJS)

• Through the front-end interface, users must be able to:

o Create their accounts

o Log in/out.

o Curate their profiles

o Request Transportation

o Respond to and initiate Transportation Events

o Complete Transportation Events

The service targets a wide demographic of peoples 18 years of age and older, within the

mainland USA, low to middle-income, any ethnicity or gender, having basic to advanced
 3

technology skills such as any person able to use a smartphone and Facebook. Conversely, users

that elect to be transporters would need to meet the aforementioned requirements, as well as

possess the means and ability to render transport, such as driver’s license, vehicle, and physical

ability to manipulate heavy objects.

It is anticipated that the project will benefit the wide demographic it targets. Because the

project envisions enabling an online resale market, it is assumed that this will lead users to spend

less to acquire the goods they need/desire such as sofas, refrigerators, tables, desks, etc. This will

in-turn reduce waste since the service helps sell used items which might otherwise be destined

for the landfill.

 4

Table of Contents

PART I: Background and Approach ............................................................................................... 7

Introduction ......................................................................................................................... 7

Issue: Lack of Options for large Item Transport. ................................................................ 7

Solution: Stuff Ride ............................................................................................................ 7

Project Goals and Objectives: ............................................................................................. 8

GOALS ............................................................................................................................... 8

OBJECTIVES ..................................................................................................................... 8

Long Term Goals: ............................................................................................................... 9

Long term objectives: ......................................................................................................... 9

Stakeholders and Community: ............................................................................................ 9

Evidence of Need .............................................................................................................. 11

Feasibility Discussion ....................................................................................................... 12

Part II ............................................................................................................................................ 13

Design Requirements ........................................................................................................ 13

Functional Decomposition of the Project ......................................................................... 13

Selection of Design Criterion............................................................................................ 16

Final Deliverables ............................................................................................................. 16

Approach/Methodology .................................................................................................... 20
 5

Ethical Considerations ...................................................................................................... 21

Legal Considerations: ....................................................................................................... 22

Part III ........................................................................................................................................... 23

Timeline/Budget ............................................................................................................... 23

Usability Testing/Evaluation ............................................................................................ 23

Final Implementation ........................................................................................................ 25

Discussion ......................................................................................................................... 32

Conclusion ........................................................................................................................ 33

References ..................................................................................................................................... 36

Figures........................................................................................................................................... 38

Early Database Schema Design (Figure A) ...................................................................... 38

Early Create Account UI Sketch (Figure B) ..................................................................... 39

Early View-Accept Transport Request UI Sketch (Figure C) .......................................... 39

Early View User Profile UI Sketch (Figure D) ................................................................. 40

Early Create/View Transport Request UI Sketch (Figure E)............................................ 41

Early Transporter Schedule Editor UI Sketch (Figure F) ................................................. 42

Early Edit User + Transporter Profile UI Sketch (Figure G) ............................................ 43

Early Transporter Search UI Sketch (Figure H) ............................................................... 44

Early Transportation Event Page (User) UI Sketch (Figure I) ......................................... 45

Early Transportation Event Page (Transporter) UI Sketch (Figure J) .............................. 46

 6

Appendix: ...................................................................................................................................... 46

Testing Documents ........................................................................................................... 46

User-Client Questionnaire (Exhibit A) ............................................................................. 47

User-Transporter Questionnaire (Exhibit B) .................................................................... 48

User-Client Questionnaire (Brian) (Exhibit C) ................................................................. 49

User-Transporter Questionnaire (Sue) (Exhibit D)........................................................... 50

 7

PART I: Background and Approach

Introduction

Issue: Lack of Options for large Item Transport.

The internet has been a boon for commerce. From Amazon.com, to eBay, to Etsy, the

internet has enabled buyers to connect with sellers, transfer funds, and ultimately receive their

goods through various parcel services such as UPS, or FedEx. However, there are cases where

this system is not a feasible way to do eCommerce between parties. One such example is the case

where a buyer sees a great deal on a used refrigerator on Facebook Marketplace residing in a

neighboring city and would like to buy it. Unfortunately, neither the buyer nor the seller is

equipped to transport the refrigerator. Using a freight service would be an expensive hassle.

Renting a U-Haul for the day is not convenient—and is perhaps infeasible. Few people are

fortunate enough to have friends that both have trucks or trailers and are willing to use them for

such moves on short notice. How can this sale proceed?

Solution: Stuff Ride

We can imagine a social networking system that connects parties wanting large item

transportation with those that are prepared to handle moves such as the one mentioned in the

previous paragraph. Through this system, a user can find other users in a radius offering

transportation services that meet their needs. Conversely, users with the means to transport often

large items locally can earn money by listing their availability on the service. The service we call

StuffRide, will provide a web/mobile interface for users to create profiles to list services,

equipment, fees, and acceptable payment methods. After StuffRide is minimally functional,

features will be added to help users convey trustworthiness to other users. Such features will

include a system for rating users, and an address verification service. The StuffRide service is
 8

akin to Uber for item moving, and the hands-off listing paradigm of Craigslist. We will explore

important differences when compared to similar services explored in the environmental scan

section.

Project Goals and Objectives:

GOALS

• Create a web/mobile interface by which a person needing to locally transport an item to

their own physical address can search for a person(s) able and willing to provide such

transport.

• Create a web/mobile interface by which a person(s) may list themselves on the service as

being available and qualified to transport a large item(s) in their local area.

• After the two parties have agreed to work together, display information about the

progress and details of the item transport and provide information to help facilitate the

successful delivery of the item to be transported.

OBJECTIVES

• Provide a web/mobile interface for users to register for a StuffRide account.

• Provide a web/mobile area for users to curate their user profile, including links to other

social media, personal image, contact information. If the user is a transporter allow their

profile to specify transportation capabilities, custom policies, accepted payment forms,

etc.

• In the case of user-transporters, provide a scheduling web/mobile interface where user-

transporters can choose which days and times they are available to accept transportation

work.
 9

• Provide a web/mobile interface for user-clients to search for user-transporters in their

areas to transport specific item(s) from a specified address to their physical address.

• Provide a notification system that informs user-transporters that a user-client requests

them for a task and time, containing information about the item(s) to move, that the user-

transporter can accept or reject, and in-turn notify the user-clients of the status of their

outstanding request.

Long Term Goals:

• Migrate the system to a RESTful backend pattern decoupled from the browser.

• Implement 100% test coverage of server-side and browser-side methods.

Long term objectives:

• Users can confirm their emails with an automated email confirmation system.

• User benefit from a real-time message pushing with the notification system.

• Users can rate/review user-clients and user-transporters after transportation events.

• Users can verify their physical mailing addresses and pay the address verification fee to

StuffRide.

• Users benefit from the HERE GPS location service during transportation events to see

where their items are and calculate ETAs.

• User-transporters can search for item transportation requests in their area, and push offers

to the user-client via popup notifications.

Stakeholders and Community:

Broadly, we can identify five distinct categories of stakeholders that might be impacted

by the StuffRide project. These groups are, the project developer, User-Clients, User-

Transporters, and Retail Outlets. The fifth group is not a group of people per se, but generally
 10

includes the impact that StuffRide could have on the environment, which we will discuss first.

As mentioned in the introduction, StuffRide enables people to find transport when buying or

selling their large items. It is a relatively straightforward argument to make that since old items

are finding new owners, then new items are not needing to be purchased to fill that same role.

Consequently, the need for raw materials to make such new items is also diminished. And the old

item that has found a new owner receives an extended lifespan beyond the landfill.

The prior paragraph leads us to the next group of stakeholders, which are large item

retailers such as a Sears, Home Depot, Jerome’s Furniture store, or any other retail outlet that

might benefit from old items not being re-used, but instead new items being purchased at such

retail stores. A scenario of decreased demand can be imagined which lowers the sales of new

items at such stores.

The third and fourth stakeholder groups include User-Clients, and User-Transporters. The

User-Transporters are defined as a person user that wishes to arrange an agreement with a User-

Transporter for the purpose of transporting an item from some location, to their listed physical

address. In a functioning arrangement as facilitated by the StuffRide service, the User-Client

benefits by obtaining transportation for the item(s) they desire transported, while paying a fee to

the User-Transporter for their service. The User-Transporter benefits by obtaining 100% of the

fee for their work on behalf of the User-Client. In a degenerate case of the arrangement, a good-

faith User-Client encounters a User-Transporter that steals or damages the item to be transported.

It is also possible that the User-Transporter damages the property of the User-Client.

Alternatively, the User-Transporter might be denied payment for services faithfully rendered for

the User-Client. It is hoped that StuffRide’s systems of address verification with an associated
 11

fee, and a user-rating system, will highlight to other users that act in good faith, and users that

should be avoided.

The final stakeholder in the StuffRide project is the sole developer, Christopher Caldwell.

At present, the project is under development by a single individual with the intention of growing

the service in the developer’s spare time post the Capstone project deadline in mid-October of

2020. The developer expects to offer a service within StuffRide to flag user’s profiles as having a

verified address. Such a process enables the developer to charge a fee to fund the service, yet

also creates a modest barrier for serious users to demonstrate to other user’s their commitment to

using the service in good faith. The developer also has a strong interest in the success of the

project as it pertains to achieving a satisfactory evaluation for his Fall of 2020 Capstone course at

California State University Monterey Bay.

Evidence of Need

The Stuff Ride platform has the capability of drastically reducing waste. Items that may

have been destined for the landfill have a chance at a second life. Stuff Ride enables a largely

untapped aspect of eCommerce to become feasible, namely large items such as refrigerators,

couches, beds, exercise equipment and anything that is heavy and difficult for people without

proper muscle and vehicle accommodations to transport. Stuff Ride further enables the so-called

gig economy by providing a platform for anyone with the equipment and muscle to list their

services on the platform. For small businesses that are unable or unwilling to contract with larger

last-mile transportation outfits, Stuff Ride provides an alternative for transporting purchased

goods to the homes of customers. Finally, other services like Stuff Ride all take of percentage of

the transportation costs. However, Stuff Ride through its system of verification fees and crowd-
 12

funded prestige badges seeks to alter that model allowing both users who request and provide

transportation to enjoy the savings of this alternative.

Feasibility Discussion

Before beginning the construction of the Stuff Ride platform, an environmental scan was

performed surveying what similar services/platforms existed to help their users transport large

items from a location to their home. Similar services included Dolly (Dolly, 2020), GoShare

(GoShare, 2020), and TaskRabbit (TaskRabbit, 2020). It was determined that the greatest

difference between these services and Stuff Ride is the prominent role these services take as a

third party to the transporter and users requesting transport of items. The role of the

aforementioned services can be seen as having both added value and added restrictions. For

example, Dolly, GoShare, and TaskRabbit contract with their workers and vet them through a

process of background checks. In the event of a dispute, a user of the service can reach out to the

service itself for remedy. This heavy involvement by the services also comes with a markup cost

to the services provided by the workers. Another downside to the centralized labor model

provided by these services is that they are only available in a discrete number of cities across the

USA—primarily in large metropolitan areas.

It then makes sense for the Stuff Ride service to provide an alternative labor model, and

alternative payment model which are in both instances decentralized. Instead of the Stuff Ride

service vetting individuals with background checks and credentials, the service can offload that

aspect to a user review and rating system, as well as a profile curation page to help users and

transporters communicate trustworthiness and reliability. In terms of payment, the Stuff Ride

service again takes a step back to allow transporters to retain 100% of their fee allowing

transporters to take home more of their pay and remain competitively priced for their services.
 13

Finally, since the service is less involved with the initiation of transporters, it is easier for

persons in rural areas to list and find transportation services.

After surveying possible technologies for creating the Stuff Ride platform, the developer

chose to utilize Laravel PHP (Otwell, n.d.) for a browser-based solution. The developer chose to

use a web-based solution to increase the adoption of the platform, so it is available on Macs,

PCs, Android phones, and iPhones via their browsers. An alternative would have been to create a

RESTful based back-end API and create native apps for each platform to call those API

endpoints. While this would provide users with a superior experience, it would not have been

feasible in the allotted time for the project. The developer also chose Laravel PHP over any other

PHP MVC framework due to the lower costs of hosting PHP servers, and due to Laravel’s

vibrant developer community and large number of modules easily integrable into Laravel

projects.

In considering the development of Stuff Ride, the question of how to best implement

functional interfaces to the user arose. The developer found three prominent options for modern

front-end experiences. Those being, Evan Yu’s VueJS framework (Yu, n.d.), Facebook’s

ReactJS framework (Facebook Inc., n.d.), and Google’s AngularJS framework (Google, n.d.).

The developer chose to utilize VueJS again, due to the large and enthusiastic developer

community behind VueJS. And, although ReactJS has a larger user base than VueJS the

developer chose VueJS because of the intuitive syntax of the JavaScript framework.

Part II

Design Requirements

Functional Decomposition of the Project

 14

We know that the Stuff Ride platform will have users. As such we will need a database to

store user information. We will also need a user interface for users to interact with. Users will

need the ability to:

• Register

• Log-in

• Log-out

• Curate their profile (edit name, address, email, phone, weblinks, bio, image)

• Create Transportation Requests (specify item name, images, weight, dimensions,

pick-up address, special handling info/requests, fragility, value)

• Search for Transporters (find transporters in a user’s service range with schedule

availabilities)

Since some users will be transporters, we will need functionality for users to become

transporters. Once a user is a transporter, they will need the ability to:

• Edit their Availability Schedule

• Edit their Transporter Specific abilities (max weight, max dimensions, max

driving radius, accepted forms of payments, guarantees)

In order to know whether two users are within range of each other geographically, we

will need a way to convert a user’s home address to GPS coordinates of latitude and longitude.

When a user finds a transporter they would like to employ there will need to be functionality for

transporters to respond to the request. The user will also need to utilize such a messaging system

to see if their request was accepted or denied. And in order for users to manage outstanding
 15

transportation requests, there should be a dashboard to host the transportation requests.

Transportation requests can have various states, such as:

• Pending

• Accepted

• In-Progress

• Cancelled

• Completed

Once a transporter has accepted a transportation request at a particular time, that time in

their schedule should no longer show as available to other users. And once a transporter has

accepted a transportation request, that request should appear on the transporter’s dashboard as a

pending transportation event. When the time of the transport event arrives, both the user and the

transporter should be able to access a synchronized transport event page. The page should have:

• A link to the requesting user’s profile

• A link to the description of the item to be transported

• A way for the transporter to progress the state of the transport event. The states of

the transport event will be:

o Unstarted

o En route to pick-up

o Arrived at pick-up

o En route to drop-off

o Arrived at drop-off

o Complete
 16

o Cancelled

To help further facilitate the transportation event phase, the event interface should show

the addresses of the next destination IE, pick-up address, and drop-off address. There should be

buttons to signal delays, and request contact from the other party either phone call or text.

Selection of Design Criterion

Based on the functional decomposition of the project, Stuff Ride must be usably

performant and reliable. Users should experience greater than 99% uptime of the service,

therefore the underlying technology should be of enterprise reliability and serviceability. The

cost of implementing the platform should not exceed $100 per month, as that would exceed the

project budget. Code size is not a limitation. The Stuff Ride platform should be maximally user-

friendly since the process of transporting large and possibly expensive items is stressful enough

already without adding technological challenges to the user’s frustrations. Lastly, the Stuff Ride

platform should be secure in such a way that unauthorized users are not able to access

information they should not, and it should be non-trivial to compromise another user’s

authentication information.

Final Deliverables

The final deliverable of the Stuff Ride project will be a mobile friendly web application

hosted on a public web server. The web application back-end will use Laravel PHP 7.8. The back

end Laravel server will be responsible for returning pages to the user as HTML, as well as

responding to RESTful API requests. User interfaces will use of the VueJS and Vuetify

responsive JavaScript libraries to give users a graphically pleasing native-app-like and intuitive

interface. The Axios library will be used in the user’s browser to make asynchronous calls to API

endpoints. The web application will utilize a MySQL database for storing relational information
 17

such as user info, user profile data, profile URLs, transporter profile specific information, image

URLs, transportation requests, and transportation event data. To facilitate the conversion of

United States postal addresses to GPS latitude and longitude values, the HERE API service will

be called by the Laravel backend.

The following user interfaces will appear in the final deliverable.

• A Landing Page

o The Landing Page will be the first page a visitor sees. It will provide

information about the Stuff Ride service, as well as links to log in, or sign

up.

• A Sign-up Page

o A page where a new user can enter their name, address, password, and

email to register for a Stuff Ride account.

• A Log-in Page

o A page for users to enter their email and password in order to be

authenticated and logged onto the Stuff Ride platform.

• The Header Bar

o The header bar will appear on all pages if a user has been authenticated

and logged in.

o The header will contain a Stuff Ride logo which links to the Dashboard.

o The header will contain a message drawer containing messages for the

user, and a notification bubble signifying new messages and the count.
 18

o The header will contain a drop-down menu with the logged-in user’s name

on it. The drop-down menu will provide navigation to the various pages,

such as editing profiles, editing schedules, and logging out.

• A Profile Editing Page

o A page for users to edit their displayed name, phone number, email,

gender, image, bio, and custom links.

o From this page, a standard user can choose to become a transporter.

• A Transporter Schedule Editing Page

o A page which displays a transporter’s schedule for the next seven days.

The transporter can click a time of day to enable or disable that time-

chunk to signify their availability for that chunk of time.

• A Transporter Specific Profile Editing Page

o A page for transporters to specify the maximum weight they can carry,

maximum dimensions, any guarantees they offer, special equipment they

have, and how far they are willing to drive from their home address to

perform transportation services.

• A Transport Request Creation Page

o A page for users to create new transport requests. A transport request can

specify an item’s name, images of the item, item weight, dimension, and

value. Additional handling info such as fragile, transport is pending a sale,

need help moving into house, and a section for narrative instructions such

as gate codes, hazards, and other information pertinent to the

transportation of the object that the transporter should be aware of.

 19

• A Central Dashboard

o The Dashboard is a page that serves as the hub of a user’s activity on the

Stuff Ride platform. The Dashboard will contain tiles of any outstanding

or past transportation requests, either requested by that user or accepted by

a transporter.

• A Transporter Search Page

o The Transporter Search Page will display any transporter users that are

within range to the requesting user.

o If a transporter appears on the search, the row will display the

transporter’s viewable profile, star rating, times and dates of availabilities

as well as a button to send the transport request to the transporter targeting

a specific time that the transporter is available as designated by that

transporter in their schedule.

• A Message Drawer

o The Message Drawer will be a collapsible sidebar that opens up when the

user clicks the notifications bubble on the header bar.

o The Messages will include information such as, requests for transport,

accepted or declined requests, and updates in the transportation request

such as en-route, arrived, cancelled, or completed.

• A View User Profile Popup

o The View User Profile Popup is a reusable overlay which displays

information about a user. Users that are transporters will have their
 20

transporter information appended to the standard user profile information

displayed in the popup.

• A View Transportation Request Popup

o The View Transportation Request Popup is a reusable overlay which

displays information about an item that has been requested for transport,

such as item name, images, weight, dimensions, value, pickup address,

and handling info.

o The View Transportation Request Popup will also have an icon linking to

the View User Profile View popup of the requesting user.

• A Transport Event Page

o The Transportation Event Page exists to coordinate the transportation

event. The page is synchronized between the requesting user, and the

transporter performing the pickup and delivery.

o The Event Page will include the address of the next step in the delivery

either pick-up or drop-off, a button for the transporter to progress the

delivery step, a button to signify a transporter delay, and another button to

flag to the other user that they request either communication by text or a

phone call.

Approach/Methodology

The StuffRide project began development in late March of 2019. After the initial idea for

the service was formulated, there was a brief period of requirements gathering. Informal user

stories were brain-stormed to create sketch-pad mock-ups of the various user interfaces. From

these initial mock-ups was derived the data requirements from which the initial database schema
 21

was designed. The developer chose to use a PHP MVC framework called Laravel for the

backend server, along with MySQL for the database. The Laravel backend was chosen due to the

ease of implementing complex routing, active record system, built-in security, and view

templating with PHP, among other features of the framework. Learning to use the framework

required significant of self-study on the part of the developer. During early development of the

service, the developer also chose to integrate the VueJS JavaScript framework to accelerate

front-end development—which required more learning as well since the developer was not

already familiar with it. During the development process, a paradigm shift to test-driven

development for unit, feature, and integration tests was also implemented. The developer also

switched to using Docker to streamline local development and remote server deployment of the

software. Further development of the project proceeds using an agile development strategy. After

development of a minimally functional service is complete, further features will be added to the

project.

Ethical Considerations

Most ethical concerns surrounding the StuffRide service pertain to the possibility of

disputes between users of the service. In order to facilitate delivering items from one location, to

the physical address of another user both the user-client and transporters put themselves in a

position of vulnerability. There exists the possibility that a user-transporter could steal or damage

the item they were tasked to transport. And there exists a possibility that the user-client might

refuse to pay the user-transporter for services rendered. However, a user-transporter is better

positioned to take advantage of the user-client since:

1. The user-transporter can compel payment by withholding the item until payment is

received.
 22

2. The user-transporter would have the physical address of the user-client whereas the

inverse is not true for the user-client.

However, the issue of either client or transporter taking advantage of the other should not be a

persistent issue. While any incident will discourage disaffected users, such users will be able to

log their complaints against other users in the form of reviews and ratings after the transportation

event has concluded. This way, future users should be able to avoid making agreements with

users with low ratings. Also, users who opt to pay the fee to have their addresses verified will

only be rate-able by other users that have had their address verified. This policy should prevent

the creation of multiple online accounts to lodge bogus reviews of users and adds trust to users

that have verified their address. The user buy-in of having a verified account also encourages

users to protect their rating by conducting themselves respectably.

Apart from the concerns mentioned above and the efforts to mitigate these concerns, it is

not clear that any demographic would be disadvantaged by the StuffRide service.

Legal Considerations:

The StuffRide service attempts to avoid most legal risks by making the service free to

use. The service does not warrant the viability or trustworthiness of any other user on the service.

However, the StuffRide service will attempt to one day promote a system of trust through

address confirmation, and ratings to help users do business with trust-worthy entities.

In order to comply with the Children’s Online Privacy Protection Act of 1998 (Federal

Trade Commission, 2018), the StuffRide service requires that all users be 18 years of age or

older to create and operate an account (United States Department of Transportation, 2011). This

age coincides with the latest that any person in any state may obtain a full driver’s license.
 23

Part III

Timeline/Budget

The original project proposal contained a section for a timeline and budget. In short, the

project comes in under budget, and over time. The developer of Stuff Ride initially submitted the

project proposal during the Fall of 2019. However, due to unforeseen circumstances the

developer was unable to complete the project during that semester at CSUMB. Again in the

Summer of 2020, unforeseen personal circumstances prevented the developer from the timely

completion of the Stuff Ride project. Yet due to the developer continuously working on the

project outside of an academic setting, the Stuff Ride project was essentially in a state of

completion by the start of the Fall 2020 Capstone course at CSUMB. At the start of the Fall 2020

Capstone course, only the Transportation Event component milestone remained for completion.

By the time user testing of Stuff Ride was required by the course schedule, Stuff Ride was

completed on-time.

The original project budget for Stuff Ride is $100 a month. That value reflects the

necessity of renting a web server from a third party. At present, the costs of renting a web server

and a MySQL server from Digital Ocean totals $60 per month. The developer also subscribes to

a video tutorial service tailored to Laravel/VueJS which costs $15 a month. The total expenditure

then comes to $75 a month for Stuff Ride related costs, leaving a $25 monthly margin under

budget.

Usability Testing/Evaluation

During development, a suite of automated tests ensured that individual components of the

system function in isolation, and with integration. There are three tiers of automated tests. These

tiers are, unit tests, feature tests, and browser tests also known as integration or end-to-end tests.
 24

Unit tests verify the smallest units of code. An example of a unit test would be testing a function

on the Schedule class which returns the next date a transporter is available for transportation

work. Feature tests are slightly more complex in that they test how multiple methods work

together. Feature tests for Stuff Ride often involve calling HTTP APIs endpoints with correct

and incorrect parameters to ensure that the proper results and response codes are received back

from the backend server. An example of a Stuff Ride Feature test would be testing an HTTP API

endpoint responsible for submitting transportation requests to a transporter. Finally, integration

tests, also known as browser tests, or end-to-end tests, involves code which automatically opens

browser windows, navigates to pages on the Stuff Ride site, enters data into fields, and clicks

buttons. Integration tests ensure that all pieces of the codebase are working together to produce

the intended presentation in the browser window.

Although the project did not begin using the Test-Driven Development paradigm, it has

since been utilized in the development of StuffRide since late 2019 with a high degree of code

coverage. Some automated tests were written retroactively, such as browser tests to ensure that

users can perform operations like registering, logging in, modifying their profile, and creating

transportation requests.

For the focus group testing portion of the project, the developer solicited the help of four

individuals with three of them inside the target demographic, and one outside of the target

demographic. The individual outside the target demographic was minimally computer literate,

however the feedback from the individual was still quite useful. For example, there were fields

where it was not immediately clear to the tester what information should be entered. In these

places, the tester helped the developer identify where and how the expectations of using Stuff

Ride could be made clearer.

 25

Testing took place over Zoom for all focus group users. The developer asked users to

share their screens and feel free to discuss their thoughts and observations as they acted out a

transportation scenario presented to them by the developer. For instance, each set of two users

were designated as a pair consisting of requester and transporter. The developer told the pairs

that the requester would like to find transportation for a refrigerator being sold by a neighbor

using the neighbor and requester’s real addresses. The transporter was given the scenario that

they are a transporter looking for work, and to also register with their real address. Then, the

pairs were given the opportunity to fulfil their respective objectives. At times during the focus

group testing, the developer would ask the users to share their screens to better understand the

feedback users were giving.

The developer originally drafted a pair of questionnaires for requester and transporter,

respectively. The developer submitted the questionnaires to the first pair of testers, and it was

returned. However, the feedback in the questionnaires was of dubious value to the developer.

(Appendix A, Appendix B). Most useful were the notes taken by the developer during the focus

group testing. The developer did not attempt to receive feedback via questionnaires from the

second pair of testers. It is the belief of the developer that the design of the questionnaires

themselves did not adequately solicit the kind of responses that would prove useful to the

developer.

In hindsight, the automated testing implemented during the development of Stuff Ride

proved to be the most valuable type of testing to date. The automated tests highlighted areas of

the project which were truly broken, allowing them to be identified and fixed. User testing

resulted in the discovery of a handful of non-critical issues that will be fixed at a later date.

Final Implementation
 26

Stuff Ride is a mobile friendly responsive real-time web application that runs in a

browser. At its core, the purpose of Stuff Ride is to connect two users, and a third-party non-user

that is in possession of an item requiring transportation. The two user types are transporter, and

requester. The requester creates a transportation request describing in the request the information

that transporter will need to successfully deliver the requester’s item from the third-party to the

requester.

In order to facilitate these functions, it is first necessary for both users to register accounts

with Stuff Ride. To achieve this, the developer used Laravel PHP acting as a backend server, and

MySQL acting as a data storage repository for user information. Laravel PHP comes with a basic

template web application that includes functionality such as user signup, and authentication

when given a data storage source such as MySQL. The implementation of user sign-up, and log-

in simply required configuring an environment variable file with the MySQL credentials. Since

Stuff Ride needs to know the GPS coordinates of users in order to calculate their relative

proximity to each other, a server-side event was added to fire whenever a new user is created. In

response to this event, the HERE GPS API service is called to convert the user’s given postal

address to GPS latitude and longitude coordinates.

Since Stuff Ride is primarily browser based and therefore stateless by default, there is not

a great degree of interconnectedness between user interfaces, so we may consider them in

isolation. The user interfaces needed to accomplish the networking between requester,

transporter, and third-party are as follows:

• Edit Profile Page (Figure G)

• Edit Transporter Profile Page (Figure G)

• Edit Transporter Schedule Page (Figure F)

 27

• Create Transport Request Page (Figure E)

• Transporter Search Page (Figure H)

• Dashboard / Home Screen

• Transport Event Page (Figure I, Figure J)

In addition to the discrete pages listed above, there are a few components that appear on these

pages that are as complex and useful as the above pages, they are:

• The Header

• Notifications Tab

• View Transport Request Popup (Figure C)

• View User Profile Popup (Figure D)

From the above pages and the intended functionality required for each one an early database

design was created (Figure A), as well as a rough idea of how the UIs should be created.

The Edit Profile Page consists of a number of editable fields such as name, phone, email,

gender, greeting, user image, custom links, and a become transporter button. When submitting

the page, the values in the editable fields are sent via HTTP Post requests to the Laravel backend

server and updated accordingly in the MySQL database if the data is valid. If the become

transporter button is selected, a VueJS pop-up appears asking the user to confirm their intention

to become a transporter. If the user confirms their intention to become a transporter, that

information is also sent to the server when the page is submitted. If a user becomes a transporter

then new records are created for them in the Transporter Profile and Transporter Schedule

Tables. Any weblinks on the Edit Profile form are also entered into a separate table for storing

URL links. And an image specified as the user’s profile image is sent to the backend server for

compression and storage.

 28

The Edit Transporter Profile Page is another form page, however the implementation

makes heavy use of VueJS and Vuetify components to provide sliders and selectable badges to

modify values such as, guarantee lists, equipment lists, accepted payments list, max dimensions,

weight, and delivery radius. Again, submitting the page to the server via a HTTP Post request

stores the form’s values.

The Edit Transporter Schedule page provides columns of VueJS buttons synched to the

record of the corresponding transporter’s schedule data in the database. Every column represents

a day of the week, and each day has 48 buttons representing 30 minutes of time. Selecting a time

window in the schedule mutates a local copy of the transporter’s schedule. If the transporter

clicks the save button, a HTTP Post request is sent to the server with the local copy of the

schedule and is updated in the MySQL server.

The Request Transportation page provides the requesting user with a number of fields to

specify information about the item they would like delivered, as well as information about the

location and contact information of the person residing with the item to be delivered. Information

about the item includes, the item’s name, images of the item, dimensions of height, length, and

width, weight, value, and flags such as fragile and sale pends transport. Another section of the

form provides fields to enter the third-party’s physical address, contact name, contact phone, and

flags for whether or not the item needs transportation ASAP, or if the address given is residential

as opposed to commercial. Finally, a third section of the Transportation Request form provides

an area to specify handling details such as reporting hazards, confirmation numbers, gate codes,

special requests, etc. There also exists flags for specifying whether or not the item needs to be

moved into a building as opposed to being dropped off at the door or whether the item needs to

be kept upright.
 29

The Transporter Search Page can be visited by a requesting User if the user has created a

Transportation Request. Using the Transportation Request, the backend server cross references

nearby transporters to see if they have an availability in their schedule, and if the item falls

within the range of limitations specified in the Transporter Profile, IE. Is the item within the

transporter’s delivery radius? Is the item less than or equal to the max dimensions supported by

the transporter? Is the weight less than or equal to the max weight supported by the transporter?

If these constraints are satisfied by the user’s Transportation Request, then the transporter will

appear as a search result on the page. The requester can then select from a dropdown component

the times that the transporter is available. The times listed in the dropdown reflect the times the

transporter specified that they were available on the Edit Transporter Schedule page. Then, the

requester may click to submit their Transportation Request to the transporter for either

acceptance or rejection.

The Dashboard is the hub of activity for a Stuff Ride user. In the area below The Header,

transport request tiles appear. The request tiles can be clicked to search for a transporter. If the

request is accepted, then clicking the request tile will bring the user to the Transport Event page.

Each tile also contains a trash can icon, which can be clicked to delete the Transportation

Request. Clicking the trash can icon sends a HTTP Post request to a delete API endpoint with the

Transportation Request’s id number. Also, if a transporter has accepted a Transportation

Request, another user’s Transportation Request will appear on their Dashboard. If a

Transportation request tile has the state of pending, then the Transportation Request has been

sent to a transporter, and the transporter’s popup profile can be viewed by clicking the image of

the transporter that appears on the transportation request tile.

 30

The Transportation Event page serves as a way of coordinating the delivery of the

requester’s item from the third-party’s address to the requester’s address between the requester

and the transporter. The Transportation Event page contains different buttons depending upon

whether the page is visited by the transporter, or by the requesting user. The transporter can see

the delivery step, IE. Unstarted, En Route1, Arrived1, En Route2, Arrived2, and Completed. The

transporter can also progress the delivery step by clicking the progress delivery step button.

Progressing the delivery step changes the delivery status bar, as well as the address of the current

objective. IE, if the delivery step is En Route1, then the information in the objective window is

that of the third-party. If the delivery step is En Route2, then the information in the objective

window is that of the requester. The same corresponds to Arrived1 and Arrived2. And if the

delivery state is Unstarted or Completed, no information appears in the objective window. Other

buttons for the transporter include request contact, and delayed. Clicking the request contact

button sets a flag on the event causing a popup notification to appear for the other user. Clicking

the delayed button causes the delayed flag to be set for the event, causing red “delayed” text to

appear on the delivery status bar. The requesting user’s view of the Transportation Event page is

exactly the same as the transporter’s except that it does not include the delayed and progress

delivery state buttons. The delivery state information is kept synched by repeatedly calling a

HTTP API endpoint that returns the current delivery state to both users. Clicking any button on

the page mutates the local copy of the Transportation Event data and sends it to the server again

via an HTTP API post request. It is recognized by the developer that calling the Stuff Ride

server’s view Transport Event API endpoint repeatedly to simulate a real-time event is not

scalable, and the developer intends to integrate WebSockets to properly support this feature at a

later date.
 31

The Header is a bar that appears atop every page on Stuff Ride. When a user is not

logged in, then the header contains the Stuff Ride logo link, which points to the login page, as

well as buttons to log in, or register. When a user is logged in, then the Header contains the Stuff

Ride logo link which redirects to the Dashboard. When logged in, the Header also contains a

drop-down menu adorned with the user’s name, and a dialog bubble icon as part of the

Notifications component. The drop-down menu provides navigation links for the user to move to

other pages such as the Edit Profile page, and the Edit Transporter Schedule page, as well as log

out. Clicking the dialog bubble icon opens the Notifications tab.

The Notifications tab is a VueJS drawer which opens when the user clicks on the dialog

bubble icon present on the Header when the user is logged in. The Notifications drawer contains

message tiles such as requests for transport, transport request responses, and other miscellaneous

messages, some pertaining to but not limited to the progression of the Transportation Event.

The View Transport Request Popup is a reusable VueJS component that at first, behaves

as a clickable thumbnail image of the item and name given at the time the Transport Request was

created. When the thumbnail is clicked, a window overlays the web page containing information

about the Transportation Request. Such information includes a large clickable image carousel

containing up to 4 images of the item to be transported, The item’s name, city, and zip, a View

User Popup component, the dimensions, and weight of the item, and all other info listed in the

corresponding Transportation Request. The View Transport Request Popup appears on transport

request notifications, transport response notifications, and on the Transport Event page.

The View User Profile Request Popup is a reusable VueJS component that at first,

behaves as a clickable thumbnail image of the corresponding user. When the thumbnail is

clicked, a window overlays the webpage containing information about the user such as the
 32

information specified in the Edit User Profile and Edit Transporter Profile pages. The View User

Profile Popup appears on transport request notifications, transport response notifications, and on

the Transport Event page.

Discussion

The greatest hurdle the developer faced during the design and implementation phases of

the project was a learning curve faced by the developer. Although it was recommended by the

project administrators to not embark upon a project that required the learning of new

technologies, the developer nevertheless chose to do just that. Prior to beginning the design of

Stuff Ride, the developer was minimally experienced with the Model-View-Controller pattern

(MVC) and minimally experienced with PHP, HTML, CSS, and JavaScript. In order to create the

sort of high-quality experience envisioned by the developer, it was necessary to drastically

increase the developer’s knowledge in PHP, HTML, as well as learn entirely new technologies

such as Laravel’s opinionated form of web app development, VueJS, the Vuetify library,

RESTful APIs, and Docker.

Midway through the implementation of the project, it became increasingly clear that Test

Driven Development (TDD) was a necessity. The developer’s hope was that a minimally

functional project could be achieved without TDD. But as the size and complexity of the project

grew, the developer was spending as much time manually testing and trouble-shooting bugs and

errors as adding to the code base. Again, TDD with PHP and integration testing would be a

costly learning curve in terms of the time spent to integrate that into the project.

The integration of Docker midway through the project posed yet another important but

costly integration in terms of time. Initially, development on the project was done with the

default server offered by Laravel through Artisan, a command-line tool. This proved
 33

unsatisfactory as the Laravel server was running on Windows 10, and the production server on

Digital Ocean runs Linux. By using Docker to provision identical Linux operating systems

within which the project can run, it can be assured that if code works on the development server,

that it will also work on the production server since we are no longer navigating the differences

between two operating systems. The other benefit of using Docker is its integration with

Kubernetes for scaling the project up and down as usage increases. Scalability becomes vital as

many users attempt to access the same server. When a server’s processing power and throughput

become a bottleneck, Kubernetes provides for duplicate web servers to be provisioned, brought

online, and for traffic to the site to be evenly balanced between the server instances.

Due to unit testing, feature testing, and integration testing becoming a focus of the

project, the roll out to users was quite smooth. However, during the first round of focus group

testing, a critical bug was found in the form of search results not appearing when the requester

attempted to find the transporter using the project’s search feature. The bug was tracked down

and fixed within a couple hours, and the focus group testing was able to proceed to completion

that same day.

Conclusion

The project seeks to solve the issue of people needing to find persons to transport their

large items. Consequently, we also need to find a way to bring persons able to transport large

items to one place where they can be found by persons looking to have large items brought to

them. We attempt to solve this problem by creating a web application where users can give and

receive transportation for large items. Importantly, the solution must be internet connected, either

as a browser application, or a mobile native application. The developer chose to proceed

developing a browser-based application since it would satisfy the application’s requirements,

 34

offer an easier learning curve, and be expandable via the RESTful API to later mobile native

iterations of the application. The developer chose a waterfall-agile development methodology.

After a period of requirements gathering, mockups of the various user interfaces for the project

were sketched, and from those interfaces an early database schema was formulated (Figures A-J)

Page by page, and component by component, the developer grew the project, making small

changes as they became apparently needed. Again, the site needed a way for users to register and

log in, a way to curate their profiles, create transportation requests, find transporters, negotiate

transportation, and engage in the transportation event culminating in the successful delivery of an

item, and the remuneration of the transporter.

From working on this project the developer reinforced the importance of having a strong

development foundation. A significant portion of time could have been saved if the developer

had the underlying knowledge and foresight to implement TDD and Docker development and

production environments from the beginning, instead of midway through the project. The

developer gained significant web development knowledge with the underlying technologies of

the project, and a new appreciation for web development in general, as well as an appreciation

for a discipline known as DevOps. DevOps refers to a combination of development and

operations. When a web app is created that is only the beginning. There remains the issue of

ensuring server uptime, scalability, accessibility, migrating to new database schemas when the

data requirements change, and adding to the site while avoiding server downtime. All these

underlying factors affect the user experience and the perceived quality of the web application.

Looking to the future, the developer hopes to see Stuff Ride launch publicly and gain as

many users as possible. The challenges mentioned in the previous paragraph are significant as

the project consists of only one developer at present. The developer hopes to find collaborators to
 35

take on some of the roles available, such as further development of the project’s codebase, and

an expert in the field of DevOps, marketing, and graphics design. Before the project will launch

publicly at www.stuffride.com, the project requires:

• A user reviews and ratings system.

• A physical address verification option with an associated fee.

• A fee processing functionality.

• A user donation program with custom flairs.

• Realtime WebSockets support.

• Email verification.

• Password recovery.

• A way for transporters to calculate their fees.

• A system for users to control their data and privacy.

• A way for users to delete or inactivate their account.

 36

References

Dolly. (n.d.). On-demand moving and delivery help. Retrieved July 30, 2020, from

https://dolly.com/help/

Federal Trade Commission. (2018, October 04). Children's Online Privacy Protection Rule

("COPPA"). Retrieved from https://www.ftc.gov/enforcement/rules/rulemaking-

regulatory-reform-proceedings/childrens-online-privacy-protection-rule

GoShare. (n.d.). Delivery, Truck Rental, Moving Companies, Movers, Shipping. Retrieved

July 30, 2020, from https://www.goshare.co/

TaskRabbit, Inc. (n.d.). TaskRabbit connects you to safe and reliable help in your neighborhood.

Retrieved Jul 30, 2020, from https://www.taskrabbit.com/

United States Department of Transportation. (July, 2011). Federal Motor Carrier Safety

Administration, DOT. Retrieved, August 20, 2020

https://www.govinfo.gov/content/pkg/CFR-2011-title49-vol5/pdf/CFR-2011-title49-vol5-

sec391-11.pdf

Yu, E. (n.d.). Vue.js. Retrieved September 19, 2020, from https://vuejs.org/

Facebook Inc. (n.d.). React – A JavaScript library for building user interfaces. Retrieved

September 20, 2020, from https://reactjs.org/

Google. (n.d.). Superheroic JavaScript MVW Framework. Retrieved September 19, 2020, from

https://angularjs.org/
 37

Otwell, T. (n.d.). The PHP Framework for Web Artisans. Retrieved September 19, 2020, from

https://laravel.com/
 38

Figures

Early Database Schema Design (Figure A)

 39

Early Create Account UI Sketch (Figure B)

Early View-Accept Transport Request UI Sketch (Figure C)

 40

Early View User Profile UI Sketch (Figure D)

 41

Early Create/View Transport Request UI Sketch (Figure E)

 42

Early Transporter Schedule Editor UI Sketch (Figure F)

 43

Early Edit User + Transporter Profile UI Sketch (Figure G)

 44

Early Transporter Search UI Sketch (Figure H)

 45

Early Transportation Event Page (User) UI Sketch (Figure I)

 46

Early Transportation Event Page (Transporter) UI Sketch (Figure J)

Appendix:

Testing Documents
 47

User-Client Questionnaire (Exhibit A)

On a scale of 1 – 10, with 1 being a little, and 10 being a lot and N/A being not applicable…

… how would you rate:

1. The difficulty of finding a transporter to deliver your item(s)?

2. Your satisfaction with the way the website informed you about the whereabouts of your

transporter and your item(s)?

3. The difficulty of using the site overall?

4. Your satisfaction with how StuffRide lets you control your personal information?

5. The value of the service, considering that it is free to use.

6. How good looking the site is?

7. How speedily the site responds and loads?

8. The likelihood of recommending StuffRide to someone that needs local item transport or

wants to transport items to make some money?

Any details you can give about your experience using StuffRide is very helpful! This is a student

project and any feedback is highly valued for improvement of the project and educational

purposes.______________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________
 48

User-Transporter Questionnaire (Exhibit B)

On a scale of 1 – 10, with 1 being a little, and 10 being a lot and N/A being not applicable…

… how would you rate:

1. The difficulty of using the app to coordinate delivery with your client?

2. Your satisfaction with the way the website informed you about the kind of item you

would be transporting?

3. The options available the app gave you when a problem arose?

4. The difficulty of using the site overall?

5. Your satisfaction with how StuffRide lets you control your personal information?

6. The value of the service, considering that it is free to use.

7. How good looking the site is?

8. How speedily the site responds and loads?

9. The likelihood of recommending StuffRide to someone that needs local item transport or

wants to transport items to make some money?

Any details you can give about your experience using StuffRide is very helpful! This is a student

project and any feedback is highly valued for improvement of the project and educational

purposes.______________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________
 49

User-Client Questionnaire (Brian) (Exhibit C)

On a scale of 1 – 10, with 1 being a little, and 10 being a lot and N/A being not applicable…

… how would you rate:

1. The difficulty of finding a transporter to deliver your item(s)? 1

2. Your satisfaction with the way the website informed you about the whereabouts of your

transporter and your item(s)? 10

3. The difficulty of using the site overall? 3

4. The likelihood of recommending StuffRide to someone that needs local item transport or

wants to transport items to make some money? 10

Any details you can give about your experience or problems using StuffRide is very helpful!

This is a student project and any feedback is highly valued for improvement of the project and

educational purposes.__________ I needed something to help me visualize the shipping

process so I could fill out the form easier. Also, I didn't always know what to click on next.

But after I made a shipping request, it was like a game. I liked the messages telling me

where my item was along the way. When it finally got to my house, I was notified right

away. Very satisfied. Thank you.

 50

User-Transporter Questionnaire (Sue) (Exhibit D)

On a scale of 1 – 10, with 1 being a little, and 10 being a lot and N/A being not applicable…

… how would you rate:

1. The difficulty of using the app to coordinate delivery with your client? 1

2. Your satisfaction with the way the website informed you about the kind of item you

would be transporting? 10

3. The difficulty of using the site overall? 2

4. The likelihood of recommending StuffRide to someone that needs local item transport or

wants to transport items to make some money? 10