-ulist is uLink's college classifieds application.
Database:
MySql: Categories
NoSQL: Posting
-MongoHQ or ObjectRocket
Post MongoDB Collections will be organized by school, and will be created if they do not exist on demand. Example post collection format: ulist_post_[school_id] i.e. ulist_post_1
Server Code: Node.js, Express Framework
// http://docs.objectrocket.com/nodejs // http://support.mongohq.com/languages/nodejs.html
Email Node Module: TBD
Capcha Module: TBD
Partner SDKs: Paypal
// node plugin: TBD
Web - Ember.JS? Mobile - iOS
ULink Users
-need to be able to view all school's posts
-have to be authenticated and a user of the school to post to the school
-when a user submits a post, they need to do some sort of new age security
-all the user's posts will show up in their account, in which they can edit them
-(From Ben Clark 03.24.13)- we need a rating/feedback system in which ulink users can rate other uLink users who post (Need to think out more later)
Employers
-need to be able to post jobs to the school
-this "employer" type posts can have more information
-last as long as 30 days?
-payment model for the jobs? TODO: reference other classifieds like Uloop, craiglist
-this post will be a one time post in which an email will get sent to them where they can always go back to the ulink site and edit their post
Listing
-need to be created by the user and they will have:
-pictures (3)
-any information from the user
-meta data (i.e. bolding)
-will last 7 days
Headlined Listing
-will be just like a regular post, but will show up in the headlined section (see Living Social "Escapes" for design)
-can be for 1 or 3 days
-once a post is initially created, it goes into active right away
-need to be able to be "Flagged? or some other more intuitive langauage" by any public user of the application
-If posting has no picture, we should have a default image (but it should not be very strong) so that the posts' information
is clearly visible
Strong Listing
-will be with the regular listings, but visually will have the following features:
- taller height size (compared to regular posts)
- Bolded Title
- Image in post row (if available)
Payments
-for all "add-ons", the user must pay via a technology (Paypal)
Pricing System
-We should have a pricing table that has costs for headlining and strong listing per school.
-Algorithms should determine weekly prices:
-based on number of headlines and strongs vs. number of postings we get per (week at first)
-prices should also have the ability overriden so that we can force a price and keep it that way (a flag on the table)
Map View - Google Maps
-Will have all the categories available, and when clicked, all the posts with
locations will show up (for the clicked category)
-A marker will have basic information like a thumbnail pic (if available), and
the title
Searching
-should be by category, and search against tag
Categories TBD - see craigslist
qt - query type can have values of "s", "c", or "u" "s" is for searching "c" is for category loading "u" is for user listing retrieval if you do qt=s, then you have to pass the following params: sid, t sid = school id t = is the search text for qt=c (category searching) you need, mc, c, and sid mc="main category text" c="sub category text" sid=school id finally qt=u, you just need uid=user id
Ex. //<server_domain>/api/listings/?qt=s&sid=3&t=tickets
we just need to denote a "batch size" and it needs to stay constant we grab listings how we normally would right let's say 1000 results are returned based on the batch # and a place holder id (the primary key for the document), we can determine what data we need