Technology Overview

The current site prototype is developed in Perl and the backend database is Mysql (33 tables). Perl programming is very heavy (more than 11,000 lines of codes), partly because Mysql doesn't support stored procedures and Perl have to handle all functions. For real development, we therefore recommend using larger database system like Oracle or Sybase and believe Perl programming will be relatively light then and site performance will be also greatly improved.

The whole site is template-driven and that allows interface designer and programmer to work independently but well combine their efforts. Cascade-style sheet is widely used across the whole site and assure the site-looking consistency. Javascript also applies on some pages and enable some user interaction on client side. We will consider using XML in near future and we also think wireless access to our site is not desirable in the near future.

Perl Implementation

We have written more than 11,000 lines of code to implement current prototype. Although code reusability has be one of key code design considerations, the coding is still very heavy for couple of reasons:

1. We have found out that not being able to implement functions (either stored procedures or triggers) within database require data exchange back and forth between perl scripts and database, and it is part of reasons of heavy coding and in the future will have great impact on site performance.

2. Event date management is complicated. In our system we have considered three type of events: one day event, weekly/monthly event (like every Friday night), and date-range event (like May 3 to May 5). Transferring different interpretation of dates has caused a lot of extra work. For example, given a specific date, say May 10, we need to find all one-day event on May 10, all weekly/month events on second Friday, and all date-range events whose starting is no later than May 10 and ending date is no earlier than May 10.

Main perl modules in our prototype includes:

Homepage module: setting cookies, identify a visitor and serve personalized homepage Consumer login and register MySFnight: event calendar and favorite venues, DJs and reviews. Event search module Venue search module Player network module Player sign in module Player update venue info module Player update event info module Player/consumer update image module E-mail to friends module Recommendation module: to calculate venue ranking and reviewers' scores.

Besides the above modules, there is a common package that stored all functions shared by all modules and configuration variables. The site has been implemented so that when the site need to be moved, the only file that need to changed is this common package file. Our code maintains high portability.

Database

We have created 33 tables in our mysql database so far and as more functions are implemented, more tables need to created. The reason we picked mysql as our backend database is that it is easy to implement and is supported at our lab. However, we have found out mysql won't be a good DBMS for real project implementation because it doesn't support stored procedures and triggers:

1. A stored procedure is a set of SQL commands that can be compiled and stored in the server. Once this has been done, clients don't need to keep reissuing the entire query but can refer to the stored procedure. This provides better performance because the query has to be parsed only once, and less information needs to be sent between the server and the client.

2. A trigger is a stored procedure that is invoked when a particular event occurs. For example, you can install a stored procedure that is triggered each time a record is deleted from a transaction table and that automatically deletes the corresponding records in other tables.

Without trigger support, we need to implement it on our perl codes. It also leaves the holes for trash data in database.

View our database specs

CSS

CSS is widely used across the whole site and we are able to easily maintain the consistency of site-looking. For example, all dropdown menu use a class called "dropdown" whose definition is like:

.dropdown { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 8pt; font-style: normal; text-decoration: none; color: #333333; line-height: normal }

By applying this class into every dropdown menu, we are able to keep our dropdown menu text look in the same way anywhere on the site.

Although we keep style sheet within HTML page instead of a separate .css file referenced from inside the html file, only two of our html pages that actually contain style sheet definition: the html template to provide top and left navigation bar for all consumers page, and the one for all player network page. Changing any CSS definition will only involve the change of these two files.

Javascript

Javascript is not heavily used in our site yet, it should play an important role in validating data input in real development

Template Driven

By adopting template driven method, we allow the high independence between interface designer and programmer. This independence allow the interface designer to be able to continue changing the html pages after the pages have been implemented, without adding extra work for the programmer.

Template-driven method also increase code readability. By seperating HTML codes and Perl codes, perl codes look much cleaner and it makes it easier for anyone who is going to take over the existing work and continue the work.

XML

We have explored the possibility of using XML in our site. Our conclusion is:

Although XML enable the separation of document structure and presentation, as well as facilitate the information exchange, we are aware of our target users' Internet experience and browser support, we decided not to support XML documents in our front-end presentation. However, depending on how important data syndication means to our project, we may consider using XML documents to exchange data with our partners in the near future.

View full report on XML

Mobile Technology

With the quick expanding of mobile users, we started to consider how we can possibly take advantage of it. However, our further study has shown that mobile technology is not applicable in the first phase of SFnight implementation for the following reasons:

Our content requires high-speed Internet connection Few situations in which our users will need to wireless access our website High development cost

View full report on mobile technology

Event Recommendation

Because event types are matching with users' preferences, we are able to give events recommendations based on users' selected preferences. Events don't have to have exactly same types as users' preferences. Instead, we recommend events that match closest to users' preferences:

Amn * Bjk = Cmk, where n=j

Amn: the matrix for events and their event types. m: number of events n: number of all event types.

Bjk: the matrix for clients and their preferences. j: number of all users preferences. k: number of clients.

Cmk: the matrix reflect how closely every client are related to each event. Each column is for one client. To get closest matching events, pick the largest numbers in that column and find corresponding events.

This is basic event recommendation model. Our improved event recommendation model will be:

Amn * Dnn * Bjk = Cmk

Where D is the correlation matrix to reflect how each event type can be related to each other. For example, people who like latin music may tend to like techo music, therefore we can assign them a 10% correlation parameter. Two possible ways to generate this correlation matrix: one is our editor manually assign them. Another way, which we think will be a better way, is to learn the correlation pattern from our collection events and venues.

Venue Recommendation

Our original venue recommendation design is that we will have separate editor picks venues and peer recommended venues. This system has some shortcomings:

Users will receive two recommendation for venues, which is confusing. Our editors are considered the only experts in our system, but in fact editors can make mistakes while some users with rich nightlife experience can be experts. We have no control on venue ratings created by spoofers.

We therefore decided to develop our venue review and rating system, based on the research method proposed by Wilensky & Riggs, in An Algorithm for Automated Rating of Reviewers. This method provides a collaborative filtering algorithm and enable us to combine rating of reviewers with item ratings. The basic concept is:

While (not converged)
      computer venue rating as weighted average
      computer review score based on how close to average reviewer rates venues.

By incorporating the quality of the reviewer into the system, we can distinguish between good guys and bad guys and our system have better chance to provide ratings closer to ground truth. By using some parameter in the algorithm, we will also be able to treat some users besides our editors as experts. Our editors' ratings will be combined with users' ratings since editors' are only considered one of the experts in the system. As a result, SFnight users' will receive only one combined and more accurate recommendation.

View full report for venue recommendation [PDF]