TomslistBoston University Craigslist

Ben Duong, Frank Wong, Marc Adam, Henry Huang

Outline

1. Motivation

2. Project Idea

3. Featuresa. Listings, search & Contact

b. Networks

c. Garage sales

4. Designa. Architecture

b. Database Design

c. Web Controllers

d. User Interface

5. User Experience

Motivation

• Buy items from trustworthy environment

• Buy items without shipping costs

• Sell items that other people might use

• See item before buying

• Existing websites are not user friendly

Project Idea

Build a Craigslist with user verification:

• Open to the public but with "communities" of users (ie colleges)

• BU Students are more willing to trust other BU Students

• BU Students have what other BU Students need - cycle of students moving in/out is a good ecosystem for this type of system

Features: Listings & Search

Users can post items and specify:

• Title

• Description

• Price

• Location

• Tags

• ImageItem tags are used when performing

search

Features: Listings, Search & Contact

All users can search for items:

• Results will show based on item tags

• Items can be previewed:o This shows more information about the itemo This allows users to contact each other directly

Messages will be sent to site mailbox:

• Users can contact for listings

• Can chat with each other from the site in a chat messaging page

Features: Networks

Tomslist has networks set up by the admin:

• Users can decide to join networks

• Users can join networks if they have an email address associated with that network

Features: Garage Sales

Users can setup garage sales:

• Allows users to highlight all their items, without setting up tons of listings

• Allows users to setup an event by specifying:o Titleo Descriptiono Date of garage saleo Time Start/End of garage saleo Garage sale location

Design

Design: Architecture

Our website follows an overall Model-View-Controller (MVC) architecture. Our data models are decoupled from the user interface views. The models and views are interfaced by the way of our controllers that handle all of the logic when the user navigates the user interface.

Model (Data)

EntitiesData Services

{Essentially all of our App_Code folder}

View

User Interface

{ASPX, JS}

Controller

Logic

{ASPX.CS codebehind}

Get Data

Save Data

Updates

User actions

Design: Database (Model)

First our database model and relationships.

• Each logical entity for application has a table to store information

• We implement one-to-many relationships through the use of foreign keys.

• We implement many-to-many relationships through the use of junction tables.

Design: Database Diagram

Design: Database

Core Tables:

Users

Networks

Notifications

GarageSale

Listing

Tags

Images

Relationships Type

Users Networks Many-to-Many

Users Listing One-to-Many

Users Garage Sales One-to-Many

Users Notifications Two-to-Many

Listing Tags Many-to-Many

Images Listing One-to-One

Images Users One-to-One

Images Garage Sales One-to-One

Junction Tables

UserNetworks

ListingTags

Design: Database Relationships

• Users | Networks (Many-To-Many)o Implemented with a junction table (UserNetworks)

that has pairs of primary keys from the Users and Networks table in each row.

• Users | Listing (One-To-Many)o Each listing has a UserId field which is a foreign key

referencing the primary key of Users

• User | Garage Sale (One-To-Many)o Like with listings, each garage sale has a UserId

field which is a foreign key referencing the primary key of Users

Design: Relationships Continued

• User | Notifications (Two-To-Many)o Each notification has one field SenderId and another

ReceiverId. Both are foreign keys that reference the primary key of the Users table.

• Listing | Tags (Many-To-Many)o This is implemented with another junction table (ListingTags).

Each row in the junction table is a pair of primary keys from the Listing and Tags table.

• Images | Listing/Garage/User (One-To-One)o Each Listing, GarageSale and User has a field, ImageId, which

can be used to find the associated image. We decided not to make a foreign key for images since we wanted to use 1 table for all three entities

Design: Data Services

Problem: How can we allow frontend user interface development without the need to worry about database tables and column names?

Solution: Decouple the frontend client from the the backend SQL data server.

Our Implementation: We developed an Object-Relational Mapping (ORM) for our core entities. This allows the user interface to work with objects without having to worry about underlying implementation

Design: ORM

The ORM consists of a list of objects that represent data that we have stored in our database. For example a "Listing" represents one row of our Listings Table.

The data services are what map the objects to entries in our database by the way of SQL commands. They are what allow us to do database transactions.

Object Data Service Database Table

User UserDataService Users

Listing ListingDataService Listing

Network NetworkDataService Networks

Garage GarageDataService GarageSale

Image ImageDataService Images

Notification NotificationDataService Notifications

Tag TagDataService Tags

Design: ORM

Our reasons for developing an ORM:

• By creating objects, it allows our controllers and views to only have to worry about an object that represents data in the database.

• This allows us to organize data into logical forms and groups represented by object.

• It allows us to centralize all database calls and SQL queries which allows for easier code maintenance.

• This allows for a more intuitive interface between the developer and the data.

• An example is calling the GetUser() method from the UserDataService and getting a User Object with information filled in from the database.

Design: Web Controllers (Controller)

Our web controllers handle all of the business logic required for the website.

• Includes the Code Behind (aspx.cs) files

• Their purpose is to supply the Views with information and to modify the data model according to user actions.

• Examples include: button clicks, list selections, etc.

• Handles site navigation and redirects

Design: Web Controller Workflow

Example case: The user wants to changes their profile information

1. The user types in changes to the textboxes and hits the submit button.

2. The controller for UpdateProfile receives the button trigger, collects the information from the textboxes.

3. The controller calls the UserDataService to get the user's current information as an object.

4. The controller changes the object to match the new information

5. The controller calls the UserDataService again to update the user's information in the database

Design: User Interface (View)

Public

Front Page• Highlights featured Items

Search• Displays queried listings

User Login

User Registration

Private

User Profile

Creation Pages (Listings/Garage Sales)

Edit Pages (Listings/Garage Sales)

Messages• See notifications and chats with

other users

Networks• Ability to join a network

Our User Interface Pages:Administrator

Admin Page• Able to delete users• Able to delete

networks• Able to delete tags

Design: User Interface Access Flow

NavigationBar

Search

Profile MessagesPost New

ListingGarage Sale Networks

RegisterLogin

Edit Garage Sale

See ListingPreview

Post New Garage Sale

Edit Listing

Front Page

Legend

Accessible to everyone

Accessible only by logged in users

User Experience

User Experience

Unified website layout - each page has the same header.

All create and edit functions logically listed under the respective postings they are for.

Page contents centered and spaced evenly to effectively utilize screen space.

Useful error messages and error handling

User Experience

All controls are tagged with:

• Classes: for styling multiple objects in the same way, used in:o Search/Featured Items divisionso Notifications Divisionso Forms inputs and buttons

• IDs: for styling unique elementso master.layout pageo Navbaro Search bar

All UI/UX files (js, css, imgs, fonts) are stored in a public folder in our project directory

User Verification

We have two areas that require a user to verify themselves.

1. When the user registers for the site, we send an email with a verification link. They cannot log in until they have been verified.

2. When the user requests access to a network, we require the user to provide an email address that matches the domain name associated with the network. We then send an email to this address with a verification link. The user is not added to the network until this link is clicked.

Membership

• Membership implemented using ASP.net o Implementation of roles:

Guest User Admin

o User Creationo User Verification

Login/Logout E-mail verify

o User Account Maintenance Change E-mail Change Password

o Page Access Restrictions

User Roles

Our website has three increasing levels of access:

1. Guest / Unverified User (Level 1):o Can see featured listings and can search for listings

2. Logged-In Verified User (Level 2):o Can see garage saleso Can post new listings and garage saleso Can edit their existing listings and garage saleso Can edit user profileo Can message other userso Can request access to networks

3. Administrator (Level 3):o Can delete users, networks and tags

Implementation Technologies

Back end:

• C# & MSSQLFront end:

• HTML5, CSS3

• Javascript (mainly for postbacks)

* No third party libraries were used in this design

Thank You!