Page Overlay - List of possible future improvements

[timo-bes]

Ideas

• Track & see number of clicks for each exact <a href=''></a> link element that was clicked, when multiple there are multiple links pointing to same URL. Covered in track & see the exact link that was clicked, when multiple links points to same URL #5182
• Include a link to Overlay in the Transitions popover (maybe as an icon in the title bar)
• Add a link below the pages report to launch Overlay for top page view
• Show % of all page views in the sidebar
• Add option to show absolute numbers in the bubbles (shorten them as 1.3K, 3.4M getPrettySizeFromBytes())
• When Transitions is opened from Overlay:
  • clicking the title in the center box should load the URL in the same window back into the Overlay session
• Highlight the Top bubbles with a different background color
• Sparklines next to the link bubbles to show the evolution of this link
• Full screen mode (hide sidebar): only slide it out via JS

Known limitation

• links that are hidden by a parent with overflow:hidden are not detected. This happens for example in sliders. Possible solution: go up X levels up in the DOM and check whether containers have overflow:hidden. Use offset() of the parent and the link to determine whether it's visible. Problem: Uses CPU cycles, has to be done every 2 seconds. Maybe only recheck when the offset() of the link has changed.
• When using the back button to go back to the initial page, the forward history breaks.
• When a popover is open and the link is copy/pasted or the page is reloaded, the popover is not high enough.

Other uses for the Overlay mechanism

• Color Overlays (with darker background than GA)
• Heatmap
• Visualizing visitors' screen resolutions
• Show Live log for this page including where visitors came from and where they went to

Documentation

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

[mattab]

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]

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]

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]

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]

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]

• Should we redirect to piwik to show the sidebar right away?

+1

Also +1 for sliding out sidebar in full screen.

[anonymous-matomo-user]

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]

In 4a18420: refs #3530 page overlay

• when the referrer is matched to determine whether the session should be started, don't match the domain. this caused trouble for some users and doesn't provide real advantages.
• new method tracker.setApiUrl() that can be used if the tracker url and the api url (which is used in overlay) differ

[timo-bes]

In 4a18420: refs #3530 page overlay

• when the referrer is matched to determine whether the session should be started, don't match the domain. this caused trouble for some users and doesn't provide real advantages.
• new method tracker.setApiUrl() that can be used if the tracker url and the api url (which is used in overlay) differ

[timo-bes]

In e62a17d: refs #3530 making page overlay more compatible

[mattab]

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]

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]

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

[timo-bes]

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

[timo-bes]

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