Web-Interface-Concept

Web Frontend

Objectives
1) A public area should inform potential customers. This area does not need to correspond with the backend system and could be completely separated.
2) A restricted area should only be accessible within a participating company's intranet after authentication. It consists of three areas:
a. A user area should allow drivers and passengers to register as new users, offer and request lifts and manage their own user accounts
b. A company admin area should allow company administrators to manage the company's configurations, read out usage data and balance user accounts
c. A system admin area should allow the system administrator to configure the entire system

Public Area
The public area deals as a common information website. Requirements:
" Web CMS with separation between content, visual design and navigation
" Supports all common languages and character sets
" Supports search engine optimization
" Supports web analytics (at least hits and referrers on page level)

Restricted Area
One possible implementation is the current eBay implementation where the registration web form is located at the call2ride server and shown within an iFrame in the intranet page as well as all confirmation or exception messages. It reads out the user's name and email address from the framing page. If possible the user authentication should be performed by the framing page. This area should only be accessible from the company's IP domain.

Functions on the different Access Levels
The restricted area should provide a three tier access system.
On the lowest access level, the user level, a drivers or passengers of one company should be able to register; offer or request lifts, manage most of their account data and see user level statistics.
One level higher, on the company level, a company admin should be able to manage all of their company's user data, balance the user's accounts and see company level statistics.
One level higher, on the system level, we need to be able to perform all lower level tasks and manage data and access rights of all attending users and companies.
Subsequently the main functions and main data fields of these levels are described and prioritized.

User Level Functions
The user area is accessible for authenticated users acting as drivers or passengers.
The user area should always be integrated in the company's intranet and stick to the corporate design to prevent confusion and gain trust. If possible it should allow single sign on and synchronization with the company's user data (e.g. via LDAP) in order to reduce maintenance effort and assure data consistency. The implementation will be company-specific.

Required functions/use cases on user level

Register, unregister
o Corporate email address (to be verified)
o Call phone number (to be verified)
o Name (to be verified)
o Alias

Offer a lift
o Date
o Departure time
o Route
o Direction
o Car (later)
o Recurrence (later, via calendar)

Request a lift
o Date
o Earliest departure time
(later: alternatively earliest arrival time)
o Latest departure time
(later: alternatively earliest arrival time)
o Point to point
" From (pick point)
" To (pick point)
o Route (alternatively to the points)
" Route
" Direction
o Recurrence (later, via calendar)

Reset password

Edit individual routes: Create, modify, delete

Change primary location

Edit phone numbers
(no editing of email address, company email is essential in order to assure user is still a employee of the company)
o Add, modify, delete (at least one number must be remaining)
o Phone numbers to be verified for every change
" Edit cars: Create, modify, delete (new table: 1:n related to user)
o Brand, Model … via drop-down list
o Age
o Fuel consumption [Miles/Gallon] and [l/100 km] … to be set by the system
o Carbon Footprint [Oz CO2/mile] and [g CO2/km] … to be set by the system

View own usage data in tabular view with filter and ordering capabilities; data shown:
o Date (time frame filter)
o Time of the day
o Route + direction (filter for both)
o Distance (attention: distance can vary for a route in case of modified routes ' distances need to be saved for each lift separately), show sum of distances selected
o Balanced/open (filter)
o All lifts offered/requested (filter), show sum of selection
o Number of passengers for successful lifts offered, show sum of selection (filter)
o Bill number for each successful lift

View company statistics, location statistics + individual contribution in a graphical representation (chart) with a time frame filter. For each of the data below, a cumulative run chart should be shown, indicating the company, the top performer and own contribution data.
o Number of offers, requests, given/taken lifts
o Distance given/taken
o Carbon Footprint reduced
o Costs saved , Money earned/spent
In addition for each of the data the user's rank and the gap to the top performer should be displayed in numbers.

View bills with time window filter. Each bill has its unique bill number, the balanced timeframe and a sum of all item counts and distances. Each bill contains a list of items in the balanced timeframe with:
o all lifts offered and all lifts given/taken
o date/time
o distance
In case a driver had multiple passengers on one ride, each passenger should equal to one row. Names of the ride partners should not be visible for data privacy reasons.

Page Overview
Tbd.

Company Level
The company admin should be able to perform all tasks a company's user can perform. In addition:

Manage locations (add, modify, delete, activate/deactivate)

Edit company data
o Name
o Email address suffix
o Corporate IP range
" Manage get points: Create, modify, delete, activate/deactivate, assign to location
" Manage location-specific routes
" Company level statistics

System Level
The company admin should be able to perform all tasks a company's user and the company's admin can perform. In addition:
" Overall statistics
" Tbd.

For the web roles and functions see https://sourceforge.net/p/opencarpool/wiki/Web-Functions-Roles/