Feedback on current beta screen shots

[px]

Attached are current screen shots of the 0.0.28b live application using a test domain.

Setup page URL: https://www.cloudflare.com/cloudflare-apps?z=example.com#piwik_analytics

Closed:

Expanded:

[px]

Live version of the cloudflare.md Piwik Analytics CloudFlare app information page

Unfortunately not able to figure out the path for broken images in the screen shots. Will ask CloudFlare about it.

[mattab]

Looks nice!

some feedback:

• the description could be more descriptive/introduction to Piwik in general, eg.

This Piwik Analytics Cloudflare Application will help you add the Piwik tracking code on your website pages. To use this app, you need to have Piwik installed already, or use a Piwik Hosting package.

• Piwik installation URL is marked as REQUIRED but help text says it can be empty. I think it should be REQUIRED also...
• Do you really need WIP notation? I guess it should "just work" ;)

nice progress!

[px]

• Tweaked descriptions on the app, and setup page.
• there is no actual way to force a required field on the app platform.
• I'd like things to just work also; that said, without the zone name given to me as a variable, or knowingly allowed to parse other aspects of the page, I would need to write another library, or something to parse known known TLD and second level domains.

[mattab]

Nice. For the site I was thinking maybe cloudflare gave this information to the scripts, but maybe not, in which case it's fine to ask for it (but don't add the /piwik path, maybe instead ask users to write full URL to Piwik

In the description there's a small repeat "Configure [your configured domains]"

[px]

There is no way to validate input fields. :( The field's description asks for a root/full URL to Piwik; to me if the field is empty/null, defaulting the value to a relative URL '/piwik' seemed most flexible and appropriate. This can allow a user to have different trackers hosted on the names being proxied through CloudFlare. In addition, there is no (easy) way to distinguish a sub-domain, and then find it's appropriate Website ID number outside of the Piwik installation. So all analytics will be tracked under the same Id, but at least using different trackers.

Also perhaps Website Id and or Site Aliases are exposed via Piwik API? If so, it would be cool for an eventual roadmap for tighter CloudFlare integration. It would be nicest if the user only had to point to their tracker URL, authenticate, choose websites under the zone name to track, and then the rest of the setup is essentially taken care of automagically.

[mattab]

fyi the site IDs are available if you know the site URL, via SitesManager.getSitesIdFromSiteUrl (url)
http://piwik.org/docs/analytics-api/reference/#SitesManager Then once you know the ID you can get the Alias urls as well via: SitesManager.getSiteUrlsFromId the data would be cached and refreshed once a day or so..

I'm just not sure about the default value /piwik, would the app work if in the URL I set to "piwik.example.org" ? or "http://piwik.example.org/" ?

Also I would suggest to try and remove "WIP" in the UI and readme, before the first public release, as it's best to finalize these items so users don't have to and it is smooth from the start (plus it works right? ;-))

:+1:

[px]

I am looking into requesting the idSite via the API, but it seems that it would need to have anonymous enabled, or a clean way for a user to not expose their private token.

The app works essentially the same as the javascript tracking widget code, I am just populating a variable and using it as the root. Appending "u+'/piwik.js' " or "u+'/piwik.php'" as needed.

[mattab]

• "Prepend the site domain to the page title when tracking" Could you change this to being a checkbox or "yes/no" select? the JS code could be written in the description, to still let users know what it means.

I think checkbox would make it easier for users and clearer to understand.

Otherwise it looks good! :+1:

[px]

Sorry, forgot to comment back a few days ago.

CloudFlare has no checkbox elements as far as I know. So changed it to be controlled by the equivalent of a checkbox. A drop down with two options, Enable/Disable. :)

I figured that with a functional "advanced options" feature, which I am working on, that users could do their magic in there should they know how.

Had also pushed 0.0.37b, and am awaiting a code review on their end. Will then update with more screenshots which should have the Piwik logo,

Piwik interface demo,

Also this app's latest screenshots visibly working. I will update this one below.

[mattab]

I have some suggestions for UI/UX:

• Could you write "Disable (default)" (append (default) to select option) for when it's the default? This way users can always revert back to default in case they misclick.Can you
• remove dot after Enable DNT in title for consistency
• helps add your tracking information -> your javascript tracking code
• to web pages -> to your web pages server via Cloudflare (or similar wording)
• "Setup" / "Update"-> why 2 buttons? maybe you could simplify to use only one "Save settings" button ?
• "otherwise it will default to use 1" -> "If not specified, it will default to use '1'"
• remove (WIP)
• maybe rename "enable/disable" to "Enabled/Disabled" ?
• Can you rename Debugger to "Logging" and rename the desc text to "If you experience issues with the Javascript tracking code, you may enable logging and use your browser console to view learn more."

[px]

The Setup/Update buttons are immutable parts of the CloudFlare UX.

Sorry, the above screenshot is "old." Will update it in a moment.

Already: removed the WIP, capitalized Enabled/Disabled options.

Added "(default)" string for the default selection boxes.

Will be fixing the bad html in field descriptions with the next revision after I hear back from Cloudflare on suggestions.