1 / 30

Tomslist

Tomslist. Boston University Craigslist. Ben Duong, Frank Wong, Marc Adam, Henry Huang. Outline. Motivation Project Idea Features Listings, search & Contact Networks Garage sales Design Architecture Database Design Web Controllers User Interface User Experience. Motivation.

aurek
Download Presentation

Tomslist

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline • Motivation • Project Idea • Features • Listings, search & Contact • Networks • Garage sales • Design • Architecture • Database Design • Web Controllers • User Interface • 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: • This shows more information about the item • 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: • Title • Description • Date of garage sale • Time Start/End of garage sale • 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} Controller Logic {ASPX.CS code behind} View User Interface {ASPX, JS} Get Data Updates Save Data 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

  14. Design: Database Relationships • Users | Networks (Many-To-Many) • 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) • Each listing has a UserId field which is a foreign key referencing the primary key of Users • User | Garage Sale (One-To-Many) • 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) • 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) • 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) • 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.

  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 • The user types in changes to the textboxes and hits the submit button. • The controller for UpdateProfile receives the button trigger, collects the information from the textboxes. • The controller calls the UserDataService to get the user's current information as an object. • The controller changes the object to match the new information • The controller calls the UserDataService again to update the user's information in the database

  21. Design: User Interface (View) Our User Interface Pages:

  22. Design: User Interface Access Flow Login Navigation Bar Register Profile Messages Post New Listing Garage Sale Networks Front Page Search Legend Edit Listing Edit Garage Sale Post New Garage Sale See Listing Preview Accessible to everyone Accessible only by logged in users

  23. User Experience

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

  25. User Experience All controls are tagged with: • Classes: for styling multiple objects in the same way, used in: • Search/Featured Items divisions • Notifications Divisions • Forms inputs and buttons • IDs: for styling unique elements • master.layout page • Navbar • 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. • When the user registers for the site, we send an email with a verification link. They cannot log in until they have been verified. • 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 • Implementation of roles: • Guest • User • Admin • User Creation • User Verification • Login/Logout • E-mail verify • User Account Maintenance • Change E-mail • Change Password • Page Access Restrictions

  28. User Roles Our website has three increasing levels of access: • Guest / Unverified User (Level 1): • Can see featured listings and can search for listings • Logged-In Verified User (Level 2): • Can see garage sales • Can post new listings and garage sales • Can edit their existing listings and garage sales • Can edit user profile • Can message other users • Can request access to networks • Administrator (Level 3): • 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!

More Related