@tsteur opened this Issue on November 19th 2017 Owner

because of action entry { "type": 95, "formName": "rechnerform", "formId": "6", "converted": "0", "submitted": 0, "serverTimePretty": "18.11.2017 20:27:14", "fields": [], "timestamp": 1511036834 },

it looks like

image

where you can only see 95 for a form interaction.

I reckon we will need to think about some way to standardide the output of actions maybe, so apps like Piwik Mobile can be written to process this API output. For example we already have always icon, next would be like a title, and a subtitle or so maybe? For a page view that would be the Page Title and the URL as subtitle.

The same logic should be then also used in the Piwik app to show the visitor log but that may actually not work because we want to have some links clickable, for example the form name which we would not be able to make clickable on the mobile app (at least it won't be trivial at all). Any thoughts?

Hiding unneeded output vs new API

Just thinking about the mobile app and that it would add quite a bit of data to send even more properties, and at the same time have lots of properties that are not needed. So maybe there would be an option to hide all action specific properties like pageIdAction or formId or formName to make the app much faster. Or maybe that would be a totally different API that only returns those standard fields? => If it is a new API then backwards compatibility will be a huge problem because not all users will have a new version of Piwik installed. But this I would need to somehow workaround anyway as I will either way need two different kind of views, one for old API format, and one for new API format (which shouldn't be too bad)

@mattab commented on November 24th 2017 Owner

It sounds good (and is needed for the future it seems) to standardise the output in some way. icon, title and subtitle are the main attributes, agreed. There would probably be a datetime and couple others too. For the rest of attributes (ids, times, dates, maybe even whether something is clickable) we could maybe put them in a metadata or so.

Ideally we keep things simple and not introduce a new API. And we need to keep BC ideally. So not sure if it's easily do-able. Introducing new API name may work if we don't have a choice.

Powered by GitHub Issue Mirror