@tsteur opened this Issue on June 23rd 2012 Member

Piwik mobile, similarly to main app, could display a selection of several reports that make sense together, instead of listing one only. This would avoid the user to click too many times to get a broad picture of what is happening. for example it is useful to see browser + OS + resolutions + plugins at the same time, since clicking 5 times would be very time consuming to see low value data.

This would improve the clearness enormously. We could add a button so users are able to switch between "overview reports" and "detailed list of reports".

Also: The main app should have the same menu organization in Visitors / Actions / Referers / Goals / Ecommerce

@mattab commented on August 3rd 2012 Member

Piwik works with Controller and Actions. Some actions become Widgets. There is also the Menu which loads specific Actions.

The goal of this ticket is to create the lower level of abstraction: define the loaded page and "Group of widgets" that are currently hardcoded in a controller request and a specific .tpl file.

For example:

  • Refererers> Search Engine & Keywords displays 2 tables. In this code
  • Visitors > Settings loads 7 reports, some in pie chart/table/bar graph.

The "CompositeReport" is this view of N widgets and the initial parameters such as to specify the view type (graph, table, etc), or the number of columns (1 for full width, 2 columns to show 2 or more tables)

It would be nice to abstract it away: each Plugin defines a new hook, a function which returns the list of composite report. The Controller actions such as UserSettings.index and the template such as /trunk/plugins/UserSettings/templates/index.tpl would be deleted and refactored. The controller action and the template code could be reusing a singe core template providing 1 VS 2 columns etc. based on the PHP array returned by the hook.

The call to the action could be done via __call() added in Piwik_controller class. This would catch calls to non defined functions, and would return the "Composite report" output if the function name matches one of the known composite reports for this plugin.

A new API such as API.getCompositeReports would return the list of all composite reports.

Dashboard compatibility
The composite report is a perfect fit for the dashboard layout that we currently have. Currently we can define layout 33/33/33 50/50 and change number and width of columns.

The dashboards are basically composite reports already implemented.
The difference is that they are dynamic and can be edited.

Therefore the function API.getCompositeReports would also return the Dashboards of the logged in user.

The format of dashboards as current, and of composite reports, should be quite similar and maybe could be made consistent in the code.

New API to return the Menu

There would need to be a new API: API.getMenu
this would return the Menu array, so that Piwik Mobile could reuse same hirarchy if needed. This would also allow to test regression in the menu.

Final use

It will be very nice to be able to visualize Piwik Mobile on tablets, which could look like the real Piwik app (for more consitent experience). Also we could innovate better and allow to create nice Piwik Mobile layouts that we could keep in SVN and improve overtime.

Finally, sharing the Custom Dashboards to Piwik Mobile will be VERY useful. Creating the ideal dashboard takes time and it's nice for users to enjoy the same one on each device.

@mattab commented on August 9th 2012 Member

As a feature request for later, it would be nice to also Define composite reports and Widgetsvia the URL, eg. JSON so that one could easily build a Custom Report in Piwik (choose columns, layout, widget).

This would be in particular very strong for plugins such as Magento, Prestashop, etc. which could automatically add a Piwik dashboard loading only Ecommerce widgets, by default. The Ecommerce dashboard layout and widgets pick would be defined in the URL to the Iframe.

@mattab commented on April 11th 2013 Member

This is a must have for Piwik 2.0!

This Issue was closed on August 15th 2013
Powered by GitHub Issue Mirror