1. Tomslist Boston University Craigslist Ben Duong, Frank Wong, Marc Adam, Henry Huang

2. Outline 1.Motivation 2.Project Idea 3.Features a. Listings, search & Contact b. Networks c. Garage sales 4.Design a. Architecture b. Database Design c. Web Controllers d. User Interface 5.User Experience

3. 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

4. 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

5. Features: Listings & Search Users can post items and specify: Title Description Price Location Tags Image Item tags are used when performing search

6. 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 item o 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

7. 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

8. 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 Title o Description o Date of garage sale o Time Start/End of garage sale o Garage sale location

9. Design

10. 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) Entities Data Services {Essentially all of our App_Code folder} View User Interface {ASPX, JS} Controller Logic {ASPX.CS code behind} Get Data Save Data Updates User actions

11. 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.

12. Design: Database Diagram

13. Design: Database Core Tables: Users Networks Notifications GarageSale Listing Tags Images RelationshipsType UsersNetworksMany-to-Many UsersListingOne-to-Many UsersGarage SalesOne-to-Many UsersNotificationsTwo-to-Many ListingTagsMany-to-Many ImagesListingOne-to-One ImagesUsersOne-to-One ImagesGarage SalesOne-to-One Junction Tables UserNetworks ListingTags

14. 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

15. 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

16. 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

17. 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. ObjectData ServiceDatabase Table UserUserDataServiceUsers ListingListingDataServiceListing NetworkNetworkDataServiceNetworks GarageGarageDataServiceGarageSale ImageImageDataServiceImages NotificationNotificationDataServiceNotifications TagTagDataServiceTags

18. 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.

19. 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

20. 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

21. 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

22. Design: User Interface Access Flow Navigation Bar Search ProfileMessages Post New Listing Garage SaleNetworks RegisterLogin Edit Garage Sale See Listing Preview Post New Garage Sale Edit Listing Front Page Legend Accessible to everyone Accessible only by logged in users

23. User Experience

24. 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

25. User Experience All controls are tagged with: Classes: for styling multiple objects in the same way, used in: o Search/Featured Items divisions o Notifications Divisions o Forms inputs and buttons IDs: for styling unique elements o master.layout page o Navbar o Search bar All UI/UX files (js, css, imgs, fonts) are stored in a public folder in our project directory

26. 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.

27. Membership Membership implemented using ASP.net o Implementation of roles:  Guest  User  Admin o User Creation o User Verification  Login/Logout  E-mail verify o User Account Maintenance  Change E-mail  Change Password o Page Access Restrictions

28. 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 sales o Can post new listings and garage sales o Can edit their existing listings and garage sales o Can edit user profile o Can message other users o Can request access to networks 3.Administrator (Level 3): o Can delete users, networks and tags

29. Implementation Technologies Back end: C# & MSSQL Front end: HTML5, CSS3 Javascript (mainly for postbacks) * No third party libraries were used in this design

30. Thank You!