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?

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...

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 ;)

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.

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!!

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

+1

Also +1 for sliding out sidebar in full screen.

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 ... ?

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

In e62a17d: refs #3530 making page overlay more compatible

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

Maybe you could also update troubleshooting to document setApiUrl.

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.

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

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

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

In ee4ba4c: 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.

One more item crossed off :)

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

And another one

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