Roku Developer Program

[stevelaw18]

We are in the R&D stage of developing an application on Roku. Our main goal is to keep a consistent look-and-feel with other platforms we've already developed on.

It seems like there are several options in creating a custom interface.

One is using the roScreen with the 2D API. This sounds a bit more labor intensive, and will require many components, view stacks, etc to be built from scratch.

It also seems we can use an roImageCanvas.

There's also the NDK, but we'd rather not go there, since our UI should not require being written in that low of a layer.

Are there any suggestions on which approach would be the best? Best practices? etc?

Our app consists of several buttons in the header section, one carousel, a menu strip, then another carousel. Here is some poor ascii art demonstrating our layout. When the top buttons are pressed the main screen is overlaid with a transparent black image, and a list is displayed where the user can make selection, which may load another list, or potentially play a video.

-----------------------------------------------------------------------------------------
|  [LOGO]                            [SEARCH BTN]                  [BTN]   [BTN]  [BTN]
|----------------------------------------------------------------------------------------
|
|    ------------------             --------------------------            -------------------   
|    |                |             |                        |           |                  |
|    |                |             |          Selected      |           |                  | 
|    ------------------             |           Item         |           --------------------
|                                   --------------------------
|
|      ----------------------------------------------------------------------------------
|     |         MENU BTN1        |        MENU BTN 2       |       MENU BTN 3      |
|     -----------------------------------------------------------------------------------
|
|     Another Carousel down here that populates in response to the menu item 
|     selections.
|
-------------------------------------------------------------------------------------------

[eockh]

I'm using roScreen and the compositor in my app. So far it seems to work ok even though its performance is slow (especially with text)...but yeah you have to do everything from scratch. It seems that Roku doesn't want to really support UI that's outside of their standard screens. I would be very happy as a developer if we could get access to buttons, scrollbars, tables, grids and such directly, but it seems like we have to roll our own. Also, NDK access is limited unless you are porting an existing game (I know because I asked). Good luck.

[MSGreg]

The standard roPosterScreen is not significantly different than the ASCII art you posted. The biggest hurdle is probably the Menu Buttons.

I suggest trying a simple roPosterScreen

You LOGO is "<company logo>" and your "SEARCH BTN" and "three "BTN" can be <Categories>. You will lose the Menu BTN, but perhaps they can be implemented as part of an roSpringboardScreen

Your list overlay is a simple (non-transparent) roListScreen, or you can reimplement using an roSpringboardScreen.

You can stack each of the screens (non-transparently) on top of each other as deep as you need, where the top screen gets the user interaction. It will be relatively straightforward if you don't need to exactly copy your UI. Just substitute with available components as needed.

[belltown]

One thing to consider about "custom" interfaces is whether you really need a custom interface versus a standard Roku UI. For frequent users of smart phones (I'm only guessing here because I don't have one), I would think the users would expect a similar interface across all apps that run on that platform; it makes jumping from app to app a lot easier and provides a much smoother, consistent user experience. If you're trying to mimic your smartphone interface on the Roku, then you need to realize that the same philosophy applies to the Roku: users expect a consistent look-and-feel across all their Roku channels for the same reasons that smartphone users do (and by 'users' I'm referring to myself).

Imagine having a dozen or so Roku channels (or smartphone apps) and having to get used to a dozen different custom interfaces because each on the interfaces' designers wanted to make their app look like an interface they supported on another platform. I suppose it would be okay if your users only used your app on their Roku, and they're buying a new Roku specifically to use your app via their TV, but if they're existing Roku users then they're most likely already used to the standard Roku interface.

I also believe that on the Roku, probably more so than on a web site or smartphone, what's really important is the content delivered rather than how slick the UI looks (except maybe for games). Users generally find something they want to watch or listen to, then sit back in front of the TV to enjoy it. The key here is to make it easy for them to find what they're looking for.

Just my two cents' worth.

[TheEndless]

"eockh" wrote:
So far it seems to work ok even though its performance is slow (especially with text)...

Not to stray too far off topic, but make sure you're declaring your fonts outside of your drawing loop. The creation of the font is really expensive, so if you're doing a GetFont() every time you need to draw text, that could significantly degrade your performance.

[stevelaw18]

users expect a consistent look-and-feel across all their Roku channels

You can also argue that users expect a consistent look-and-feel among the same product family. Imagine you use NetFlix on the Wii, and it looks different than the one on the Roku.

[belltown]

"stevelaw18" wrote:

users expect a consistent look-and-feel across all their Roku channels

You can also argue that users expect a consistent look-and-feel among the same product family. Imagine you use NetFlix on the Wii, and it looks different than the one on the Roku.

Yes, you could argue that too. I suppose it depends on who your users are and whether they spend a lot of time using your app on several different platforms, or whether they spend their time using a lot of different apps on the same platform. I don't have many platforms, so I'd fall into the latter category, but I'm by no means suggesting that I'm in the majority in that regard.

[stevelaw18]

Let's say we have no choice. We need to create a consistent UI. The platform must surrender to us or else.

What are our options and which one is recommended?

[TheEndless]

"stevelaw18" wrote:
Let's say we have no choice. We need to create a consistent UI. The platform must surrender to us or else.

What are our options and which one is recommended?

For performance, roScreen. For ease in development, roImageCanvas.

[RokuJoel]

If your channel absolutely must have the same look and feel as your existing smartphone apps, then using roScreen is what you need to do. roImageCanvas is not really fast enough to be used seriously for a UI, although there have been a few channels based on it, it is essentially clunky and sluggish.

It isn't that difficult to build your own components in roScreen. Not knowing what your existing smartphone apps look like, of course there is a limit to the kind of advice we can give you. The best advice I can give you is just to start working on it, and ask questions if you run into trouble. roScreen is good for creating slick user interfaces with the kind of smooth motion you might find in an iPhone or Android app, especially if you use the double-buffering mode.

Joel