-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Row Evolution: usability improvements, UX #3158
Comments
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'. |
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 JulienM:
+1 |
Replying to matt:
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.
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 #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
|
(In [7116]) Refs #3158 |
(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:
See 3790 |
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(). |
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? |
Popover state in hash part is implemented. |
I can't reproduce this. Has it maybe been fixed by now? Matt, please double check. |
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 > /". 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?
|
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 👍 |
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:
The text was updated successfully, but these errors were encountered: