Context Navigation

describes purpose, requirements, and possible implementation of a popularity system for phtagr

Purpose

what is popularity in the context of a file gallery, and how could it be used?

allows the file, and in turn the poster to gain social status (wow, he has the coolest images)
allows the admin to predict server load (oh no, that file is getting more popular and is pretty big)
allows attention to be drawn to a community determined set of files
allows the user to make some predetermination of quality (everyone else is looking at it)

Provide a system that is useful in a wide variety of traffic levels (3 visitors a month to 1,000s of visitors an hour)
decouple the concept of popularity from quality (a separate feature should track quality)
the software determines popularity by observing the natural flow of traffic, not through dedicated user actions (does not use a rating, or other solicited feedback)
Popularity should atrophy (decrease) across time, if people are no longer interacting with the file regularly

the admin can determine how much a given action affects popularity
be able to view a files popularity history
search based on popularity on a given day / time
admin or users with permission should be able to "fake" popularity
- fake popularity can be on a timer (acts as popularity 75 for the next 2 days, then behaves at its actual value)
- fake popularity can just be added to the actual total (admin give image 50 bonus popularity, because they want to)

every file is given a new current popularity attribute "popularity"
- if popularity is to be tracked across time, they are also given a popularity history list, popularity history should never be recorded in file metadata
a system wide popularity is tracked, as a total of popularity awarded "popularity traffic"
a set of actions are given hooks to be able to trigger the awarding of popularity "popularity events"
a default config file is generated, and then altered, that way if the software defaults change a current gallery's behavior does not.

values for all popularity events can be set
atrophy severity can be set
- linear (flat amount)
- scaled (remove 10% popularity rounded down, minimum 1, not to pass zero)
- aggressive (remove (((current value)-10)/(scaling value))+10)%, not to be more than 50% rounded down, minimum 1, not to pass zero, the smaller the scaling value the more aggressive the atrophy, recommended default would be somewhere around 1/2 the maximum expected daily popularity gain whatever that ends up being)
atrophy trigger type can be set
- atrophy by time (triggers the atrophy at a given interval)
- atrophy by traffic (triggers atrophy after the popularity traffic has progressed a certain amount)
- atrophy by both (atrophy will only occur once a given time has lapsed, as well as an amount of popularity traffic has occurred)
  - because of this option, a popularity event should be triggered at a set interval, that raises the the popularity traffic by a configurable amount (default should be small but not zero, or a low traffic site will see no atrophy with this setting by default)

users view the site triggering popularity events
1. files popularity is increased by the popularity event's value
2. popularity traffic is increased by the popularity event's value
cron triggered maintenance is triggered
1. current popularity of each file is logged (if popularity tracking is on)
2. trigger any time caused popularity event, adding value to popularity traffic
3. time passed and/or popularity traffic is checked to see if atrophy is triggered
  - if atrophy is triggered
    1. set popularity events to record elsewhere while database is updated
    2. apply atrophy to every file with greater than 0 popularity
    3. reset popularity traffic to 0
    4. update popularity based on events that occurred during the update
  - if atrophy is not triggered
    1. don't do anything

what sorts of things should be able to trigger the awarding of popularity?