#TakeLessons Booking Monitor#

Setup

Computer

Minimum requirements

The machine will most likely run best on Ubuntu, with a decent graphics card to handle the CSS3 rendering that we may potentially do.

Display Requirements

Aiming to display on a computer that’s at least 720P

Accessibility

This will only be accessible internally (just like Maestro). It can be accessed by anyone in the office.

Data

Storage

We will be storing this data into the reporting table, where it will store the following information:

The information will be added when they are booked via Public and Maestro

First Iteration:

Pull from the Sale ETL

Second Iteration:

Create a new machine/storage-location to store these smaller records.

Input

If filtering our data, we can fetch the data in any way we want. There are the optional filters we can have:

Output

This is the data we’ll output to the display, in a JSON format that can be fetched asynchronously

id (int),
student: {
  name (string), 
},
teacher: {
  name (string),
  photo_url (string)
},
lesson: {
  category (string),
  service (string),
},
location: {
 product_loc_type (string),
 lesson_duration (string),
 lat (float),
 lng (float),
 city (string),
 state (string)
},
created_at (timestamp)

Display

Booking Cards

Design

The cards will be sorted in a FIFO format.

The most recent card will be the largest card, while other cards will shrink down as they are pushed down

Animation

The cards should have these requirements:

If there are cards queued up, divide up the time of the cards with this simple algorithm:

tMin = Min time of cards = 10 sec.
tMax = Max time of cards = 60 sec.
total = Total Cards = Actively displayed Card + Queued Cards

timePerCard = max(tMax / total - 5), tMin);

The “5” is the threshold to start doing this algorithm. For instance, we want to make sure we don’t burn through 5 cards immediately. We’ll start using this algorithm after having gained 5 total cards so it gives the illusion that we are still generating bookings.

Factors

There are 3 factors that have been identified when adding a new card:

Map

Design

The map will be an SVG image that will be measured precisely so that map markers can be coordinated on it. It must be scalable to be used on any browser, especially an HDTV.

Icons

Icons will be placed relative to the map.
Additional effects may be added to make icons look more apparent that it has just been placed.

Icons must be:

Imagery

Represent each map marker with these symbols (All from the font Elusive)

In-Home: http://www.fontello.com/#search=road
In-Studio: http://www.fontello.com/#search=home
Online: http://www.fontello.com/#search=desktop

Animation

Additionally, when a map icon is added, it can create a nice effect where the map tilts based on where the icon hits on the map.

48 States, plus the other 2.

Additional kudos points if we can add Hawaii and Alaska into the corner of the screen, and having icons drop into there. Otherwise, ignore the icons.

Running Graph

Design

The graph will show the number of sales per hour over the course of 24 hours

Filtering Controls

Allow the user to be able to apply filters to the map, with the provided inputs

Social Media

Design

Show a running page of social media from Facebook, Twitter, Instagram, and g+ on a separate “screen”

Milestones

Primary Objective

Secondary Objective

Tertiary Objective

Team Breakdown

The project can be broken down in the following manner:

API/Backend Development

This person will be expected to create an API that will output expected parameters for the front-end developer to use. They also must create an interface for the front-end developer to grab the formatted data from.

Additional: They must be able to hook this into places that generate booking, and store the data into the database.

Front-end: Card Development

This person will be responsible for stubbing out data until the API/Backend developer is able to send data with the expected parameters.

They will also manage the card algorithm system as well.

Front-end: Map and Coordination Development

The map developer will be responsible for the coordination of pin icons on a vector-based map. They will need to need to be able to create a library that will allow the front-end card developer to add and remove pins.