search

matomo-org / matomo

Empowering People Ethically with the leading open source alternative to Google Analytics that gives you full control over your data. Matomo lets you easily collect data from websites & apps and visualise this data and extract insights. Privacy is built-in. Liberating Web Analytics. Star us on Github? +1. And we love Pull Requests!
https://matomo.org/
GNU General Public License v3.0
19.66k stars 2.62k forks source link

Page Overlay - List of possible future improvements #3530

Closed timo-bes closed 5 years ago

timo-bes commented 11 years ago

Ideas

Known limitation

Other uses for the Overlay mechanism

Documentation

See user guide, and troubleshooting FAQ: http://piwik.org/docs/page-overlay/

mattab commented 11 years ago

What a Great List of Wonderful Features & nice priorities.

The only one I would "move up priorities" because it is easy I think is: Display "Page Overlay: /XX" in a box next to the calendar instead of above iframe. We can reuse css from the "Widgets & Dashboard" which loads in the same use case... What do you think?

Some feedback and questions:

How do we pick the initial date and range? User default? Or #overlay- day, #overlay-month, #overlay-year?

+1 nice trick

Highlight the Top X (5?) bubbles with a different background color Good idea, but not sure about implementation as it will make readability less easy. Probably we better offer a way to "Filter Out" all links with a Slider to select the % clicks to show/hide. Let's discuss further later.

Find a way to view the following pages as a list. Maybe adding this capability to Transitions will do.

In Transitions we could have a "View all" link that would then display the list of all following pages? But how would you display long list of 30+ elements? we need pagination.. but that's not possible in Transitions is it?

Sparklines next to the link bubbles to show the evolution of this link

So the query would have to run 30 times or so? ;-) Or would you restrict the SQL to only look at this specific PageA -> PageB visits?

timo-bes commented 11 years ago

The only one I would "move up priorities" because it is easy I think is: Display "Page Overlay: /XX" in a box next to the calendar instead of above iframe. We can reuse css from the "Widgets & Dashboard" which loads in the same use case... What do you think?

I agree that we should save some space but I don't really like the idea with the box because URLs can be quite long. I didn't put it as top priority because the idea still developing in my head... :)

Find a way to view the following pages as a list. Maybe adding this capability to Transitions will do.

In Transitions we could have a "View all" link that would then display the list of all following pages? But how would you display long list of 30+ elements? we need pagination.. but that's not possible in Transitions is it?

I would put a limit on the "view all" as well - maybe 200 or so. I'd like to show it with a minimalistic scrollbar like in the segmentation UI mockups. The list could be displayed in a box next to the "Others" in the regular Transitions UI. It would only show the URLs and number of transitions in a very compact way.

Sparklines next to the link bubbles to show the evolution of this link

So the query would have to run 30 times or so? ;-) Or would you restrict the SQL to only look at this specific PageA -> PageB visits?

We'd need a custom query that loads the evolution of PageA -> PageB. We could add another method to RankingQuery that groups by different dates. It would be a little complicated to write but hopefully easy to use...

mattab commented 11 years ago

I agree that we should save some space but I don't really like the idea with the box because URLs can be quite long. I didn't put it as top priority because the idea still developing in my head... :)

I think there's lot of space in the box as there is only the Calendar + About Piwik on the same line.

I would put a limit on the "view all" as well - maybe 200 or so. I'd like to show it with a minimalistic scrollbar like in the segmentation UI mockups. The list could be displayed in a box next to the "Others" in the regular Transitions UI. It would only show the URLs and number of transitions in a very compact way.

Ok I like the idea, if you reuse the same UI pattern as the segment listing on mockup, +1 for consistency

But also, it would also very useful to have a link of some sort, that would open the Report table in full screen, in the same overlay (back button would return to the Transitions report).

This way users could use the other features: flatten, export, graphs, limit, etc. Especially, exporting "following pages" or "previous pages" via the API would be super useful (for users who can't use the Overlay section in "API" menu).

Sparklines next to the link bubbles to show the evolution of this link

So the query would have to run 30 times or so? ;-) Or would you restrict the SQL to only look at this specific PageA -> PageB visits?

We'd need a custom query that loads the evolution of PageA -> Pa geB. We could add another method to RankingQuery that groups by different dates. It would be a little complicated to write but hopefully easy to use...

+1 for RankingQuery complicated code change ;)

timo-bes commented 11 years ago

When we add new filters and options, I don't want to place them in the website; I'd rather have them in the sidebar. With the current mechanism, we cannot send notifications to the iframe without changing its location. In modern browsers, there's postMessage which allows us to do that. This way, we can make much more use of the sidebar.

When the sidebar becomes more important, it's not a good idea to hide it the way it was planned. Instead, it's better to just slide it out via JS without changing the location. For that reason, some priorities in the list above will change.

The current mechanism should work in all browsers (I still have to test that but I'm pretty sure), using postMessage won't. My plan is to make new features like filters and different modes only available in new browsers and show a warning in old ones. The basic mechanism will still work but not the fancy stuff. GA doesn't support old browsers like IE7 at all (probably because of postMessagesupport) so it should be fine if we do it this way.

mattab commented 11 years ago

The basic mechanism will still work but not the fancy stuff. GA doesn't support old browsers like IE7 at all (probably because of postMessagesupport) so it should be fine if we do it this way.

That's perfectly acceptable, at Piwik we do not need to support IE7-8, especially for non critical features. Nice updates!!

mattab commented 11 years ago
  • Should we redirect to piwik to show the sidebar right away?

+1

Also +1 for sliding out sidebar in full screen.

anonymous-matomo-user commented 11 years ago

As Requested here: http://forum.piwik.org/read.php?2,99709

We have Piwik integrated into our CMS - and not all URLs pointing to our sites are automatically added to piwik. So when I open the Page Overlay for a Domain which is not added to Piwik it will only tell me:

Quote
You are attempting to open Page Overlay for the URL WWW.DOMAIN.COM None of the domains from the Piwik settings matches the link.

So the Question is if it would be possible that Piwik checks if the Piwik Code is present on the called Domain - and if yes - show the Page Overlays - and not persist on the Domain entered in the Admin ... ?

timo-bes commented 11 years ago

In 4a18420b31fb4d2127ab25c9d96f710bb0a2405c: refs #3530 page overlay

timo-bes commented 11 years ago

In 4a18420b31fb4d2127ab25c9d96f710bb0a2405c: refs #3530 page overlay

timo-bes commented 11 years ago

In e62a17da11ba0e437eaa3d250fbb453b724a5ff8: refs #3530 making page overlay more compatible

mattab commented 11 years ago

Did you need "setApiUrl" to make it work or did you add it "in case" ?

Maybe you could also update troubleshooting to document setApiUrl.

timo-bes commented 11 years ago

I did need it in one case where tracking is done via a URL where mod_proxy only forwards piwik.php and piwik.js. To get the scripts and the data for Overlay, we had to use a different URL.

I just updated the documentation.

timo-bes commented 11 years ago

In f71ae715aa87d565efba9a30e2b9a802ec364930: refs #3530 fixing overlay status bar in ie7 and ie8

timo-bes commented 11 years ago

In ea674051301237593062fc43e7d528666bf42ed5: refs #3530 proper line breaking of location in overlay sidebar in internet explorer

timo-bes commented 11 years ago

In 55727244bb9c1375bc9f19c720836f3400f0e155: refs #3530 removing a loading notification from page overlay because it crashes sometimes in ie8

timo-bes commented 11 years ago

In ee4ba4c0bc8f1fb5353fabd9e72aad6928b44fdf: refs #3530 leave some space between the link and the orange box in page overlay.

this way, dropdown menus without timeouts (like the ones on piwik.org) work in page overlay.

one still has to be a little careful to move the mouse slow enough, but that's the best we can do.

timo-bes commented 11 years ago

One more item crossed off :)

timo-bes commented 11 years ago

In c13cdd9b9b42b0a24ffd97b9fd9c2ac0dee7b410: refs #3530 overlay help icon linked to piwik.org documentation

timo-bes commented 11 years ago

And another one

mattab commented 11 years ago

Would be nice to forward &segment parameter to overlay report, I forgot to do it. Referenced in: #3934

Edit: covered in Page Overlay support for "Segments" so one can view Overlay for a segment of visits #9256