Roku Developer Program

[retrotom]

I'm having issues using roSearchScreen because it is too "text"-driven. The issue is that there are duplicate text values in the suggestion screen -- and no way to accurately determine the actual selected suggestion result. Channels like Netflix work around this by including the year or something in the suggestion text. I will admit that it makes little to no sense to display the same value in the list two or more times. But in cases where this can't be helped, it's necessary to get the selected item or index -- not the supplied text. Would it be possible to extend roSearchScreen/roSearchScreenEvent to include the following:

• roSearchScreenEvent - GetIndex should return the selected index in the suggestions list


• roSearchScreenEvent - GetData should return the selected item/value in the suggestions list


• roSearchScreen - Accept an array of roAssociativeArrays for suggestions; that way extended information can be tied to the suggestion items


• roSearchScreen - (In conjunction with the above request) Expose a method/property for GetSuggestionItems or something; right now, you would have to keep an array of objects and an array of strings in order to be able to look something up.

Thanks,
RT

[TheEndless]

While I agree that the additional functionality would be nice, I think you may be trying to use the search screen different than is intended. I think the search screen and suggestions are just intending to allow the user to enter text faster, not actually find a search item. Typically, you'd have a search results screen after they click a value, so if you have multiple items with the same name, they can then choose which they want. In your scenario, how would the end user know which of the two suggestions with the same name is the correct one without seeing associated cover art or description?

[retrotom]

Yeah, I would agree with you. But showing cover art, etc. only makes sense if you have all the associated data. My channel, etc. is driven by a user's media collection. Imagine this scenario: You've ripped two CDs or something from a local band using Windows Media Player. Because it's a local band and there's no CDDB (or whatever) data available, the Album is "Unknown Album". The Artist is "Unknown Artist". The tracks are called "Track 01", etc. Maybe you've been too lazy to update/maintain the album info -- assuming you even know it. How could you possibly tell them apart anyways without a) displaying the fullpath of the file and/or b) playing the file? I say AND because there's a high probability you won't have the ability to display the full path intelligently...especially depending on your OS and where it's saved. With all the effort expended to do so, you might as well play the first file and move on to the next one. Does that scenario make sense? There are other scenarios similar to this one that can occur.

[TheEndless]

I understand the scenario, but I don't understand how the user would be able to tell them apart from the search screen any moreso than from a search results screen in that case. I mean, how does knowing that they selected the first "Track 01" instead of the second "Track 01" on the search screen help you, when there's nothing that distinguishes them anyway? I would think a search results screen with multiple "Track 01"s on it, showing different durations or file sizes in the description would be more helpful to the end user. On that same note, depending on how many "Track 01"s they have in their collection, displaying multiple "Track 01"s in the suggestions means they'd have to enter more of the name to find what they're looking for, which kind of defeats the purpose of the suggestions in the first place. See what I'm saying?

I think it's better to consider the search screen as strictly a place to enter text, with suggestions to help with faster entering of that text, and rely on some other method (poster or grid screen) to actually present results to the user.

[retrotom]

Yeah, that makes sense. I think we are/were thinking the same thing, but my idea around the navigation is slightly weird/suboptimal now that I think of it. I was thinking that they user would be able to play/inspect the video from the search screen. When you really think about it, you're doing the same thing twice if you show the suggestions...and then show them again on another screen. But it's probably more intuitive to do it that way; not to mention it would conform to the way netflix works. It would still be nice to have those things I asked for. I think what you do after the "search" is almost inconsequential; I'd still want to search (and get results) just once without creating two sets of arrays. I'd also like to know the exact item I selected. For instance, another reason this is important is because of the lack/inconsistent support of unicode. The suggestions list supports some unicode characters when parsed from XML; but GetMessage() returns ASCII -- thereby eliminating the ability to figure out what the user selected or event re-query with their selection. For instance, test with something like "360°". The suggestions list will display that exact term; GetMessage returns "360?". It would be frustrating to display all matching values, and be on the wrong index.

[TheEndless]

If possible, I'd recommend doing a lightweight search just for title hints on the actual search screen. Depending on how intensive your search actually is, doing a full search on every character entered could be a lot of extra work for your server, and result in a slow refresh on the search screen.

[retrotom]

Yeah, that's something I'm looking at now. Even with a naive (non-FTS indexed) approach, it's OK to do a per-character search. Obviously, (because of the lack of indexing) it may get slower with more characters. Dealing with thousands of audio, video, and image files -- I can still achieve sub second search times on my laptop. I think it's more intuitive to have an "autocomplete" feel to the search. Having to type and scroll all the way down and then all the way to the suggestion box feels klunky to me. If speed/performance does become an issue, I can always implement FTS with my database engine. What helps is knowing that the Roku will only display a few results. Because of that, I don't actually have to return or find every matching result; I can just quickly return the top N. Because of this, the search is actually really fast in practice.