KPIs are Key Performance Indicators. They are necessary to measure the global performance of the project.
|#1||To know how many ZIM files are downloaded over time||
|#2||To know how often new revisions of large/popular collections are offered(over time)||
||???||Only for common collections: e.g., Wikipedia 1.0, Wikipedia for Schools|
|#3||Track the number of languages with offline options available||
|#4||Track the number of high-quality collections offered over time||
|#5||To know the reach of the offline work||
|#6||To know where the offline work is penetrating by location||
|#7||To know where the offline work is being viewed by location||
For all charts the period may be select for the whole stats page. So this is not a topic for each chart.
- If we want a centralized solution to get informations about ZIM file downloads without having a central repository... each provider should provide their stats. I propose in a first time to do that for kiwix ZIM files to see if this is OK.
- This seems to me to be the most important KPI
- I can do that with only one chart representing download count with bars over time. A total count will be also displayed. I would add two comboboxes to allow filtering. One to choose a language (per default "all"). A second offering a list of ZIM files in the pre-selected language (per default "all").
- Seems to me to be irrelevant now:
- Kiwix ZIM files are not "refreshed" periodicaly
- For WP ZIM files... they are build dynamically... does not make sense.Kelson 16:59, 27 July 2011 (CEST)
- Does the number of ZIM files in a language over time would be OK?. A chart with bar with a filtering combox with languages (per default "all") Kelson 17:01, 27 July 2011 (CEST)
- Could be interesting if generated from different library.xml Kelson 17:02, 27 July 2011 (CEST)
- Seems to me not feasible... Collection are to 90% not reviewed... and we do not have categories for ZIM files Kelson 17:04, 27 July 2011 (CEST)
- We do not have a system to monitor the viewership... this is also critical in term of privacy protection. Not sure we need that... download counts should be a good indicator. Only online readers could also be tracked. This make many flaws. Kelson 17:08, 27 July 2011 (CEST)
- Similar answer as for #1... but with a map. Kelson 17:09, 27 July 2011 (CEST)
- Similar answer as for #5... but with may use the kiwix sw update check system (need to be implemented) to know where kiwix is run.... Kelson 17:19, 27 July 2011 (CEST)
|#1||To know how many Kiwix readers are downloaded over time||
||Currently offered on Sourceforge|
|#2||To know which operating systems are downloading Kiwix||
||Share can be seen on Sourceforge, but not over time|
|#3||To know how often new versions of Kiwix is offered (over time)||
|#4||To know where the offline work is penetrating by location||
||Downloads and map can be viewed on Sourceforge||Downloads not viewable over time|
|#5||To know where the offline work is being viewed on Kiwix by location||
||The software update system should always "ping" a specific url. We should analyse that logs.|
|#6||To know why Kiwix was downloaded||