Additions:
& There's still a lot more content to add, just bear with us. As for the usefulness of the stats: think of this as //analytics// specifically designed for wikis. By analyzing these indicators and comparing them with those made available from other wikis, we'll be able to provide admins with reports about their wiki's //health// and //performance//. We'll be even able to provide projections and recommendations on how to set up your wiki to achieve a specific goal. For an idea of how a report may look like, take a look at our analysis of [[http://dev.nitens.org/flickr/group_trackr.php?group=94761711@N00 Flickr groups]].. To see what kind of predictions can be made just by taking into account very simple indicators, take a look at the [[http://nitens.org/docs/wikidyn.pdf study]] we presented at ""WikiSym 2008"". The [[http://wikitracer.com/docs/Home#hn_External_links external links]] section can also give you an idea of the use of wiki analytics.
Deletions:
& There's still a lot more content to add, just bear with us. As for the usefulness of the stats: think of this as //analytics// specifically designed for wikis. By analyzing these indicators and comparing them with those made available from other wikis, we'll be able to provide admins with reports about their wiki. We'll be even able to provide projections and recommendations on how to set up your wiki to achieve a specific goal. For an idea of how a report may look like, take a look at our analysis of [[http://dev.nitens.org/flickr/group_trackr.php?group=94761711@N00 Flickr groups]].. To see what kind of predictions can be made just by taking into account very simple indicators, take a look at the [[http://nitens.org/docs/wikidyn.pdf study]] we presented at ""WikiSym 2008"". The [[http://wikitracer.com/docs/Home#hn_External_links external links]] section can also give you an idea of the use of wiki analytics.
Additions:
& Hi Alex, thanks for your feedback, I add comments inline -- DarTar
& There's still a lot more content to add, just bear with us. As for the usefulness of the stats: think of this as //analytics// specifically designed for wikis. By analyzing these indicators and comparing them with those made available from other wikis, we'll be able to provide admins with reports about their wiki. We'll be even able to provide projections and recommendations on how to set up your wiki to achieve a specific goal. For an idea of how a report may look like, take a look at our analysis of [[http://dev.nitens.org/flickr/group_trackr.php?group=94761711@N00 Flickr groups]].. To see what kind of predictions can be made just by taking into account very simple indicators, take a look at the [[http://nitens.org/docs/wikidyn.pdf study]] we presented at ""WikiSym 2008"". The [[http://wikitracer.com/docs/Home#hn_External_links external links]] section can also give you an idea of the use of wiki analytics.
& This would be possible in principle, however, this requires changing the default headers that are sent by the application. We think that this could be a barrier to adoption compared to a scenario in which (if the engine allows this), (1) a simple file is dropped in the plugin folder of your wiki, (2) the wiki is registered with the service, so the service knows exactly the URL from which it can pull the data.
& WikiTracer is not much about //wiki engines// (that's what [[http://www.wikimatrix.net Wikimatrix]] is for!) but about //wikis// and it will not report about //features of a wiki engine// but about //statistics of a wiki// that depend on the specific features supported by its engine. It will aggregate stats for wikis running on a variety of different engines. In order to draft the first version of a platform-independent protocol we need to find the largest possible subset of indicators shared by the majority of wiki engines. For instance, some wikis support //comments//, other only support //talk pages//: if we want to build comparative statistics we cannot compare apples and oranges and we need to know if a feature is supported and if stats for that feature can easily be computed on-the-fly.
& The unique identifier is needed not only for internal use but for services querying the WikiTracer API to obtain information about a specific wiki (when this is allowed by the privacy settings of that wiki). Suppose you are not happy with the output WikiTracer offers by default. Using the API and passing your unique id on top of the key you'll be able to query WikiTracer, retrieve the data you need and do with this data whatever you want.
Additions:
- private (individual) vs. public (aggregated) stats
- plugin configurability (privacy)
- license
- write up: how does this function?
- pull vs. push (corporate wikis behind a firewall may prefer a push option)
- I'd like to see a writeup explaining why the various stats are useful. The WikiTracer page is very brief.
- It's unclear to me how to get the first response from a site. Shouldn't the spec contain something like a link element in the HTML header pointing to the WT data? Example: %%<link rel="alternate" type="application/xml" title="WT Data" href="http://www.emacswiki.org/alex?action=wikitracer" />%%
- Why are we writing our engine capabilities on a wiki page here if the WT response will report these?
- Why does the wiki have to provide wid and engine_type as unique numerical identifiers? I would have thought that the engine_type is a plain text field (eg. "Oddmuse") and that unique keys are used by wikitracer internally. Otherwise wikitracer turns into a micro IANA.
Deletions:
- private (individual) vs. public (aggregated) stats
- plugin configurability (privacy)
- license
- write up: how does this function?
- pull vs. push (corporate wikis behind a firewall may prefer a push option)
- I'd like to see a writeup explaining why the various stats are useful. The WikiTracer page is very brief.
- It's unclear to me how to get the first response from a site. Shouldn't the spec contain something like a link element in the HTML header pointing to the WT data? Example: <link rel="alternate" type="application/xml" title="WT Data" href="http://www.emacswiki.org/alex?action=wikitracer" />
- Why are we writing our engine capabilities on a wiki page here if the WT response will report these?
- Why does the wiki have to provide wid and engine_type as unique numerical identifiers? I would have thought that the engine_type is a plain text field (eg. "Oddmuse") and that unique keys are used by wikitracer internally. Otherwise wikitracer turns into a micro IANA.
Additions:
- Why does the wiki have to provide wid and engine_type as unique numerical identifiers? I would have thought that the engine_type is a plain text field (eg. "Oddmuse") and that unique keys are used by wikitracer internally. Otherwise wikitracer turns into a micro IANA.
Edited on
2008-09-16 10:57:02 by
AlexSchroeder [Mostly questions that need an answer somewhere on the site (or better pointers if the answers alread]
Additions:
- pull vs. push (corporate wikis behind a firewall may prefer a push option)
==Alex==
Some of these suggestions are in fact questions that should be answered somewhere on the site.
- I'd like to see a writeup explaining why the various stats are useful. The WikiTracer page is very brief.
- It's unclear to me how to get the first response from a site. Shouldn't the spec contain something like a link element in the HTML header pointing to the WT data? Example: <link rel="alternate" type="application/xml" title="WT Data" href="http://www.emacswiki.org/alex?action=wikitracer" />
- Why are we writing our engine capabilities on a wiki page here if the WT response will report these?
Deletions:
- pull vs. push (corporate wikis behind a firewall may prefer a push option)
Additions:
- plugin configurability (privacy)
- write up: how does this function?
- pull vs. push (corporate wikis behind a firewall may prefer a push option)
Deletions:
- configurability (privacy)
- how does this function?
- pull vs. push (corporate wikis behind a firewall)
Additions:
- pull vs. push (corporate wikis behind a firewall)
Deletions:
- pull vs. push
Additions:
- pull vs. push