This ticket is a follow up of #534 - the first version of Row evolution is part of Piwik 1.8.
There are items which I believe will make the feature easier to discover, easier to use, harder to misuse! here they are:
Usability
Multi Row Evolution UX
Multi Row Evolution is an awesome feature but currently hard to discover, so here are UX suggestions:
In the multi row evolution report:
If you have any suggestion or find any bug with Row Evolution please report here!
See also:
See also
To fully implement #3013, API.getRowEvolution needs to support a new parameter : $idGoal.
This is required for Goal reports with dimension such as :
Without this parameter it is not possible to plot, for example, the evolution of 0 days (to conversion) for eCommerce orders (&idGoal=ecommerceOrder).
It has been suggested in comment:5:ticket:3013 that static graphs should display the top 5 row evolutions.
The logic needed to get the top 5 row evolutions should maybe be located in the API.getRowEvolution method.
The $label parameter could become a non required parameter.
When no labels are not provided, the top 5 label evolutions would be returned.
It could even support keywords such as 'top5' and 'last5'.
The logic needed to get the top 5 row evolutions should maybe be located in the API.getRowEvolution method.
The $label parameter could become a non required parameter.
When no labels are not provided, the top 5 label evolutions would be returned.
It could even support keywords such as 'top5' and 'last5'.
Sounds good, in the code I propose to simply use the value of filter_limit - if it's specified use it, otherwise default to 5. So it is consistent with existing API.
top5 and last5 is an interesting idea, but I think a bit too early unless we make good use of such features in the UI :)
Replying to matt:
Sounds good, in the code I propose to simply use the value of filter_limit - if it's specified use it, otherwise default to 5. So it is consistent with existing API.
filter_limit gives you the top labels per period. If you look at Referers.getRetererType period=year date=last5 filter_limit=2 you can see that the top 2 labels are not the same every year.
Which top x labels should be taken? The ones from the last period? Or something more sophisticated involving averages over periods?
Keep the top labels for the most recent period (ie. current period) being compared. As part of #57 we will highlight which ones are decreasing and increasing, but for plotting values we simply use the current period.
If you look at Referers.getRetererType period=year date=last5 filter_limit=2 you can see that the top 2 labels are not the same every year.
That's correct, but for refererType example, the graph will always display all lines since there will be max 4 (direct,website,search,campaign)
refs #3158
See #3361 Row Evolutions not returning data for Actions.get[Entry|Exit]PageTitles
(In [6925])
refs #3158
refs #3013
Thanks for making the suggested changes! Nice commit.
Indeed it's a good point.
When there is no labels in the "last date" report, or when there are less than 5 labels, I propose that we "top up" the labels list by requesting the report for the current year of data, and use this to fill in the 5 labels ?
(ie. the code calling $this->loadRowEvolutionDataFromAPI ) could be refactored to be called twice with Last date and Current year
this would ensure that, when there's a bug in the site for 2 days for example, the graph show that the top 5 values this year have all decreased a lot. If we don't use yearly data, the graphswill show "no data" when in fact there's an emergency situation ;-)
what do you think ?
(In [7086])
refs #3158
return label values instead of metadata url with new API parameter $labelUseAbsoluteUrl == false (defaults to true)
refs #3013
(In [7116]) Refs #3158
Row evolution works when the label or sub label contains "script" - this used to be a smarty hack to make the JS widgets work, but we only support iframe now, so we can safely remove our overwrite
(In [7179]) refs #534: bringing the new popover behavior to row evolution
(In [7182]) refs #3158: remember selected metric in multi row evolution as part of the url - using the back and forward buttons after picking different metrics is possible now
Replying to matt:
Thanks for making the suggested changes! Nice commit.
- I forgot to manage an edge case when $label=false and there are no data, what should the API return ? see @review
Indeed it's a good point.
When there is no labels in the "last date" report, or when there are less than 5 labels, I propose that we "top up" the labels list by requesting the report for the current year of data, and use this to fill in the 5 labels ?
(ie. the code calling $this->loadRowEvolutionDataFromAPI ) could be refactored to be called twice with Last date and Current year
this would ensure that, when there's a bug in the site for 2 days for example, the graph show that the top 5 values this year have all decreased a lot. If we don't use yearly data, the graphswill show "no data" when in fact there's an emergency situation ;-)
what do you think ?
See 3790
Missing data: go to demo link. Reproduce: click on a domain name in the table, then click any Row evolution icon for a download -> the graph and sparklines display but there is no stats written on the right of sparklines.
This is a feature, not a bug. Matt, you didn't like that row evolution showed +100% if the period was longer than the time data was tracked for the current report. So we decided to ignore all values until the first non-zero value. In the report you link to, the rows have only zero values except for the current month. Since there is only one data point we consider, we don't show the change.
I hope I managed to express the point clearly... The question is whether we want to keep this "feature" or not. Your call, Matt.
Note to myself: To remove this, get rid of $firstNonZeroFound and if ($first == 0) in API_API::enhanceRowEvolutionMetaData().
In 221b74d38a006b0cede71423bbc1d98d82066539: refs #3158 row evolution
metric selector graph: Would it be possible to add the "Metrics picker" in the graph in row evolution report?
Why would we want to do that? Row evolution has its own implementation of the metrics picker. In the regular view, you can click the metrics below the graph and in Multi-RowEvolution, there's the selectbox at the bottom (and in this case, the regular picker wouldn't work because we have to reload the data after changing the metric).
Can we remove this request?
Small detail: When report is Flattened, and label is long and truncated (eg. custom var name - value), hovering on the row to see the tooltip also displays a white spot where the Row evolution icon normally is, hidding some text
I can't reproduce this. Has it maybe been fixed by now? Matt, please double check.
Loading data... could be instead "Loading Evolution data for {here icon and label name}" this could be done by copying the HTML of Label row, including the icons/logos?
The problem is that we only have the label in the URL parameter. Since RE launched by changing the hash part of the URL, we don't have the data table row DOM el. What we have is the label - we could show that but it looks weird for subtables. E.g. when row evolution is openend on an outlink, it might look like "www.example.com > /".
We don't have the icon at all so there's no way to show it expept add it to the URL too which introduces XSS possibilities. We could only show it when RE has been launched from a table and pass the row dom el around but this would add complexity to the already complex code.
So I'm not sure what to do about this request. It would be nice, yes. But I don't see a decent way to implement it.
Removing 'add the "Metrics picker" in the graph in row evolution report' from description
Nice that you looked into these.
I removed them and updated and cleaned up the ticket description.
Thanks, Matt.
Why did you remove this from the description?
Rows across pages can't be compared. Reproduce: mark a row for Multi-RE, klick "next >" and open RE on another row. The selection will be lost because the marked rows are stored in the data table instance which is destroyed. Possible solution: store state in the data table manager. Clear the state when switching between reports.
I'm not sure if it's a good idea to allow multi pages selection. It could be easier to use the Bottom-right limit selector to show more rows, and easily select them at once.
Closing this issue as Row evolution works well - for specific requests, we should create new separate issues :+1: