Support/MetricsDashboardPRD: Difference between revisions

Support/MetricsDashboardPRD (view source)

Revision as of 11:49, 7 April 2009

138 bytes added , 7 April 2009

→‎Needs decision or investigation

Djst

1,623

edits

@@ Line 22: / Line 22: @@
 * Do we have any similar dashboard projects done in the past?
 ** Any code we can reuse?
-** Any previous work on scope/implementation we can apply here?
+** Any previous work on scope/implementation or good practices we can apply here?
 * Static or dynamic data?
-** In a nutshell, are we just going for a list of SQL queries that are cron-jobbed daily/weekly/monthly and continue to do special/ad-hoc queries manually?
+** Do we store the data we periodically gather in a way that enables us to select date ranges for the data we're collecting?
-** OR, do we store the data we periodically gather in a way that enables us to select date ranges for the data.
+** Or are we just going for a list of SQL queries that are cron-jobbed daily/weekly/monthly and just stored statically?
-* Are we aiming for TikiWiki integration, or are we something separate?
+* Are we aiming for TikiWiki integration, or are we making the dashboard separate?
-** What about productization of SUMO?
+** What about productization of SUMO? Having this integrated would make it easy for other installations of SUMO (e.g. Fennec, Thunderbird) to use the same features.
-** Other SUMO installations might not have Omniture -- do we need an interface between site metrics and TikiWiki metrics so Omniture can easily be replaced with e.g. Urchin, Google Analytics, or whatever other sites might be using?
+** Other SUMO installations might not have Omniture -- we would need an interface between website metrics and TikiWiki metrics so Omniture can easily be replaced with e.g. Urchin, Google Analytics, or whatever other sites might be using