Support/MetricsDashboardPRD/implementation

Design/Functionality

• Use jQuery for tabs & etc: simple, efficient, portable

Generate report

Options/steps:

• Specify input
  • Source of input
    • data from other reports (e.g. for trend of KB CSAT = this week - last week)
    • consider SQL query versus a query builder or some kind of query helper
      • query helper would show database structure and comments on tables and columns to help with building the SQL
      • could optionally include Omniture API
  • Preview option. E.g sample result returned
    • this counts towards bulding output. E.g click "Preview" and the output options will be customized to show a sample for previewed data
  • How input is to be stored, how often it is to be run
  • Possibility of aggregating input for multiple sources -- how would this work?
• Specify output
  • Comparison with past results (custom period, how many periods back to compare with) + absolute value
  • Single "row": columns + type per column
    • Types appear to be: string, integer, percentage, floating point
    • Additional operations to perform on the data
  • List of "rows": same settings as above + limit # of rows
    • Combine or compute results of different rows (e.g. for ratio of votes "article easy to understand" calculated from: number of yes/no votes)
  • Consider using ideas form my qmo_bugzilla module at [[1]]
    • Mapping feature is easy to use (+), but has learning curve (-) and is not as flexible as some reports might require (-)
  • Format specific to output option (need to decide which software to use - openflashchart? timeline/timeplot?)
    • Pie chart / bar chart
    • Histogram
    • Sparklines
• How far back in time to keep reports (requires separate cleanup script)

Implementation

Architecture

• Layer to pull data from metrics DB to match the requirements at [[2]].
  • Extra layer to cache data with an optional preference for caching level
• Layer for cron file(s) of various scripts to pull necessary data
• The above two layers organized into folders per source of report?
  • TikiWiki specific
  • Omniture specific
• Benefit of the above approach is to abstract getting data implementation from retrieving data implementation (eliminate dependency on the source of the data)

PHP structure

• separate TikiWiki and Omniture folders

Storage structure

• XML vs SQL DB?
• Probably best to use separate DB for metrics. Same DB as site would affect performance.
• DB table structure:
  • source table - may be unnecessary
    • contains information about how to connect to different sources. e.g. db connection for getting TikiWiki and Omniture info
  • query table
    • purpose: stores the different queries to be run. proposed structure:

 id | query | source (foreign key: id from source table) | last run | last changed

• • result table
    • purpose: stores different results