Roku Developer Program

[joetesta]

There's a misspelling on this page that tripped me up when I copied and pasted (note the extra "T" after the "N"): "EPGLaunchIntitiate"
https://developer.roku.com/docs/developer-program/performance-guide/measuring-channel-performance.md

[RokuTomC]

"joetesta" wrote:
There's a misspelling on this page that tripped me up when I copied and pasted (note the extra "T" after the "N"): "EPGLaunchIntitiate"
https://developer.roku.com/docs/developer-program/performance-guide/measuring-channel-performance.md

Thanks Joe, good catch. This is now resolved!

[marcelo_cabral]

"RokuTomC" wrote:

"Komag" wrote:
Looks like "game" is back, right near the bottom, just above "Screensaver attributes"

I would like solid definitive correct sizes for things as well:

icon
540x405?
290x218?
336x210?

When I set mine to 290x218, it looks PIXEL PERFECT on my Roku 4 and on my 4k Roku TV where the UI is 1080p.
Maybe the 540x405 is for the larger channel picture that you see when surfing the channel store?

Komag and Marcelo, I've confirmed the dimensions listed for the manifest attributes in the documentation is accurate. However, please be aware that these assets are only used when your channel is side-loaded. When your channel is published and installed from the Channel Store, the channel icon that renders is the one that you upload during the channel creation/submission flow.

540x405 is the dimension for the asset uploaded during channel submission. This is the pixel perfect spec, and scaling is handled by the firmware.
If this is incongruous with your experience, can you shine a little more light on the specific use cases where things are going array?

I just think that there is no point to have those old dimensions standards as they looked distorted because the aspect ratio is different from the current firmware UI. Just make a single standard as 502x405 and avoid this confusion. My final 5 cents on this. 🙂

[joetesta]

The last example entry on this page is incorrect:
https://developer.roku.com/en-gb/docs/d ... -search.md

For the sign up flow use case, call 
dispatchEvent("Sign_Up|pageNumber=<int>|pageType=<type>")
 or 
dispatchEvent("Sign_Up|pageNumber=<int>|pageType=<type>``") when a page is submitted or field is entered.``

It should be more like the first example that has different field values in the 2nd entry:

dispatch an event for the sign-up flow, assign
{RED: {eventName: "Sign_Up|pageNumber=<int>|pageType=<type>"}
or
{RED: {eventName: "Sign_Up_Form"|field=<string>"}

[joetesta]

There is insufficient guidance wrt pageNumber or pageType values:
 https://developer.roku.com/en-gb/docs/developer-program/discovery/search/prioritizing-authenticated-...

Should pages use consistent values for pageNumber (ie should a specific view be assigned a pageNum that's then used consistently for all users, no matter which path they follow to the page; or should the pageNum be incremented arbitrarily as the user steps through the process (such as maintaining a global pageCounter that's incremented on each page in the flow)?

What values may be used for pageType and where does it matter?  Can we create our own arbitrary types?

[joetesta]

Types listed do not match example:

pages: landing, sign in, registration, device activation, subscription selection, payment, and cancellation.

Examples:
"Sign_Up|pageNumber=1|pageType=Landing Page" "Sign_Up|pageNumber=2|pageType=Sign In"

Note: "Landing Page" vs "landing"

Can we use any arbitrary values we want for these?  Please clarify in the documentation.
https://developer.roku.com/en-gb/docs/developer-program/discovery/search/prioritizing-authenticated-...

[RokuJonathanD]

"joetesta" wrote:
There is insufficient guidance wrt pageNumber or pageType values:
 https://developer.roku.com/en-gb/docs/developer-program/discovery/search/prioritizing-authenticated-...

Should pages use consistent values for pageNumber (ie should a specific view be assigned a pageNum that's then used consistently for all users, no matter which path they follow to the page; or should the pageNum be incremented arbitrarily as the user steps through the process (such as maintaining a global pageCounter that's incremented on each page in the flow)?

What values may be used for pageType and where does it matter?  Can we create our own arbitrary types?

JD: The idea is to use the provided syntax so the Roku and you can easily identify the page where sign-up abandonments may be occuring...so for page numbering, it should just be based on a single path so that the page can be easily identifed. You don't need to number pages differently based on different user paths. 

[joetesta]

Thanks JD.  Given your reply I am assuming that the answer is "yes" to whether these values can be anything we want to put there.

Can we create our own arbitrary types?

[joetesta]

A challenge I'm facing is that our registration and sign-in flows are non-linear.  The "polling" screen could be screen number 3, 4 or 5 depending on the path and options the user chose.  I wish there were more guidance or an example of how this could work in a more complex / non-linear process.

Is it required that RED calls send incremental page numbers, or could we assign a distinct page number to each of our views and then a user might follow a path with non-sequential pageNumbers?

[RokuJonathanD]

"joetesta" wrote:
A challenge I'm facing is that our registration and sign-in flows are non-linear.  The "polling" screen could be screen number 3, 4 or 5 depending on the path and options the user chose.  I wish there were more guidance or an example of how this could work in a more complex / non-linear process.

Is it required that RED calls send incremental page numbers, or could we assign a distinct page number to each of our views and then a user might follow a path with non-sequential pageNumbers?

JD: They can be non-sequential, but the pages numbers should be increasing as a user progresses on a path. So one flow could have pages 1, 2, 4, 7 for example, and another might be 1, 3, 4, 5, 7, and so on.