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!