Browsers plugin graph report percentage instead of visits

[jnandreae]

The current view of the plugins used are meaningless. You can see in the graph how many people support this plugin but you have to look to another widget to see the count of people traced.

If i see it right in ticket #852 there are no detection for IE.

Proposal:

• put percentage of visitors handling the plugin instead of number of visitors. This percentage would be based on all visits, excluding IE visits.
• Add a note below the datatable explaining that Plugins detection doesn't work in IE and therefore the report is extrapolated based on non IE browsers.

[vipsoft]

Requires changes to Visualization and ViewDataTable classes to support this chart type and data stream (Similar to #397.)

[matt]

Renaming and increasing priority.

It would be easy to change the current graph and display percentage of users that have the plugin enabled. This would fix the main issue of this report.

[SteveG]

(In [2469]) refs #1125 now shows table instead of bar chart, displaying percentage of visits (excluding ie visits)

[SteveG]

would anyone please add the mentioned note to the view script/translation and close this ticket. I have problems with finding a suitable phrase for that in english (only got some in german...)

[matt]

Message proposal: {{{ Note: Plugins detection doesn't work in Internet Explorer. This report is based only on non IE browsers. }}}

patch looks good!

[matt]

(In [2474]) Refs #1125

• fixing integration tests
• fixing bug when no visit (called function on non object)

Refs #818: all_tests.php is now green on my box

[matt]

(In [2493]) Fixes #1125

• column translation was empty
• displaying message in footer + adding general feature to display footer messages
• fixing sorting was not working on the % Visits column because filter was queued and the Sort filter was executed before the new column was added. Instead, just applied the filter directly in API.

[matt]

after changes

[matt]

Bug, see screenshot: cookie detection works on IE therefore should not remove IE users (or % visits is higher than 100%)

[SteveG]

I guess the best solution to get representive values for all is to calculate the cookie value including IE users and the rest without those. Or shall we include ie to all values?

[matt]

sounds good - I think we can leave the messaging as it is.

[SteveG]

(In [2519]) fixes #1125 include ie users for cookie value calculation, now works for multiple periods like last10

[SteveG]

Wasn't as easy as I thought. The last change for the API-function didn't work for multiple periods like last10. So I had to change a bit more than only the cookie value calculation. Maybe anyone sees an easier way of doing this...

[matt]

code is too complicated I agree. Maybe this would be easy by writing a DataTable Filter? The Filter will access a standard datatable and therefore can contain the simple code contained currently in your API function.

The datatable array will simply apply the filter to all datatable inside it. It would in this case update all stats, except cookies.

Do you see what I mean?

[matt]

(In [2595]) Refs #1125

• Example of a simple filter to apply to the datatable in the API method. Filters will automatically work on all dataTable are are easy to write /maintain

• Fixing tests

[SteveG]

java detection seems to work in IE, too. see #1496

[matt]

we can do this a bit later as code works as is. Let's focus on the secret project ;-)

[vipsoft]

(In [3031]) refs #1125 - partially revert r2595 ... the "%" (unit) is inconsistent with revenue (no unit); refs #1562

[vipsoft]

What's the remaining "todo" on this ticket?

[SteveG]

Code works as it is, but code complexity is still a bit too hight. see  http://dev.piwik.org/trac/browser/trunk/plugins/UserSettings/API.php#L93

Maybe that could be solved a better way by using an tablefilter. Problem is that some plugins are treated a special way, as their detection does work in IE aswell.

[matt]

I'll take a look at the code and see if we can write a shorter version (maybe reusable). See also #1816

[matt]

it seems sometimes the % visit might be wrong:  http://wishuload.de/images/19232-42-2011-01-12142443.png

[matt]

See #2133 for code improvement now affecting another code

Closing this ticket as request was implemented, SteveG your next patch will be closed a lot faster I promise :)