Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JimH]

This would be very exciting for me, especially if it ran on ARM.  

I've been fiddling around with building small MC-powered touch-enabled devices (like a boombox with a touchscreen, or a raspberry pi media player with a tiny touchscreen for control) and I keep running up against a wall because there's no nice touch interface for MC for Linux/ARM (other than webgizmo, which has some drawbacks).  

I wonder how far you could get with OneRemote.  

I hope we can work on WebGizmo a little sometime soon, so I'd be grateful to hear what limitations you have found.

Thanks.

[mwillems]

I wonder how far you could get with OneRemote.  

I hope we can work on WebGizmo a little sometime soon, so I'd be grateful to hear what limitations you have found.

Thanks.

The main limitation with using OneRemote in this application is that (as far as I know?) it only runs on Android.  The raspberry pi and many other little ARM boards can't run android (in some cases not at all, in some cases not in a usable way), they just run plain vanilla linux (like the Id).  Some dev boards can run android, but if I were using a device that could run android, there are already two very nicely developed touchscreen JRiver apps already available  (jremote and gizmo)

So on devices that can run android, there are lots of options.  And on windows there's theater view which works great on my Surface Tablet.  However, on vanilla Linux there's nothing but webgizmo, which has definite limitations on a touchscreen.  If you were looking for specifics, here are the biggest issues I hit using webgizmo as a touch interface daily on a raspberry pi for about six months:

1)  Unlike android gizmo, in webgizmo there is no load-on-demand infinite scrolling.  Album views are broken up into pages with 40 or 50 albums per page.  To switch pages you need to touch-press a fairly small hyperlinked number button at the bottom of the page.  Additionally, only four or five numbers are available for press at any one time (the rest are ellipsized, like 1, 2, 3 ... 45).  Android Gizmo and theater view both handle this through infinite scrolling, which would be nice for webgizmo.  Barring infinite scrolling (which would be ideal), larger, easy to press page buttons would be better, although if that's the solution, it would also be nice to have an alphabet (like in standard view).  As it is there's no good way to browse a large collection with webgizmo on a touch screen. To offer a concrete example, my music collection "album view" gets split across 50+ pages, and because the page numbers are ellipsized, getting to the "middle" of the collection is pretty hard.  It requires two dozen clicks and page loads to get to the "M's"!  

2) Unlike android, common desktop web browsers are not perfectly touch optimized. Many browsers (at least the the ones that run well on a raspberry) handle a touch screen by effectively treating it like a mouse.  This means "touch and grab" android style scrolling does not work, you have to use the browser scroll bars.  That makes scrolling even within the view pages challenging, as one has to grab the tiny browser scroll bar and drag it.  By contrast, Android Gizmo provides a nice large "grab bar" for assisted scrolling once you start scrolling.  An always-visible "grab bar" (like the one that appears on Android Gizmo, but always on) would be very nice to have in webgizmo.  

3) Unlike an android phone, the touchscreens I'm dealing with have no dedicated "back" button (many non-android tablets like the MS surfaces also lack such a button).  Webgizmo has no touch-friendly way to emulate this "back" function within the interface.  One can, of course, use the browser's "back" button, but in an appliance-type setting you don't want the browser chrome to be visible/accessible to a user (they could break things), you want the "app" to run fullscreen and be self-contained.  The lack of such a function within the interface makes navigation tough in full-screen.  Once you've gone down a level, your only option is to go all the way back to the top, which (combined with the above mentioned paged-view navigation) means that a single mispress can force you to start over on a chain of 10 or 15 clicks.  Gizmo for android relies on the fact that all android phones have a back button, but, a better example is theater view.  I use theater view on a windows tablet with no keyboard or back button and it works great because theater view always includes a way to move back up one level (through the rollers). I definitely don't think webgizmo needs rollers, but it would be nice if webgizmo had an onscreen way to either do what the browser "back" button does or just move up one level in the view hierarchy. Even just doing it the way Kodi does by making the first item in any view be "up one level" would do the trick.

4) This is a cosmetic issue, but it bothers me, so I thought I'd mention it.  The album cover thumbnails retrieved and displayed in android gizmo look nice and sharp, with no visible artifacts.  Often, the exact same album art in webgizmo appears to include artifacts or aliasing.  I'm not sure why that would be the case, but it's pretty easy to see if you look at the same album art in android gizmo and then in webgizmo on a browser on the same device. Art with large red or pink color fields seems to show it most prominently.

I've been tinkering with OneRemote and it seems to be coming along nicely, but it appears to be using the webgizmo backend? In any case, the same limitations with webgizmo appear to be present in OneRemote so far: paged scrolling, small numbers to change pages, no onscreen way to go up one level or back, aliasing in the album art etc. (although things are made somewhat easier in the android context by the presence of a hardware back button and native touch scrolling, etc.).  

Gizmo and JRemote are both fantastic and hard to beat as dedicated media interfaces in the android setting though, they're very polished.  In the desktop space theater view is also excellent.  Any improvements to webgizmo to make it closer to those interfaces and/or more "touch friendly" would be greatly appreciated, although if/when theater view lands on linux it will solve most of these problems.  In any case, I hope this helps, and I appreciate the chance to offer input  

[Manfred]

For me the question is - what's the objective behind it?

• addresses it the playing of movies, pictures or videos like JRemote, which is for me has an easy to use user interface with a high usability 
• or does it address the management functionality of JRiver like ripping disc, media network configuration, madVR config  etc., which is sometimes not so easy to handle?

I like to have more from the Options and the DSP Studio functionality on my JRemote or a new "Pretty Interface" which combines both - if JRemote is not longer strategic? (there were less new functionality over a long period of time)
Is that your goal?

[JimH]

MC22 will have two new interfaces that were developed from this Pretty Face idea.

Panel is an HTML5 browser application.

OneRemote is a native Android app.

Both will continue to evolve.

[JimH]

We're working on something that is a derivative of the Pretty Face idea.

Here are the goals:

Build a HTML5 web app that can talk to MC.  It can access MC's library in much the same way that Gizmo and JRemote do.

Provide an extremely simple interface that anyone can understand.  Minimal buttons, minimal choices.

The initial implementation will probably give a user a choice of 6 or 8 buttons.  Each one will start a different playlist.  The playlists will probably be whatever has been set for the Car Radio buttons  These can be static or dynamic (smartlists, Playdoctor).

Once we have it right with playlists, we'll move on to other media categories.

Because it's HTML, it will run in any browser on any device.  It will adjust itself to the screen size.

If you've used Panel, the interface will be familiar. 

You will connect by entering a URL, something like:  192.168.0.44:52126

If we get it right, it should be dead simple for an inexperienced user to start audio playing on the MC server or on the client device.

[Castius]

Glad to hear this is still moving forward.
One of my main problems with using theater view. Is trying to get to web media. If I had a nice way to get to my local media in chrome I might be able to better simplify getting to both.

[dtc]

Jim - What you describe seems to require an administrator behind the scenes to set things up. This works, for example, if an experienced user wants to set up playlists for members of the family. However, what you describe does not seem to fit for a standalone novice user nor does it seem to allow for direct access to tracks or albums for the entire library through user selections. Just wondering what the current thinking is. Will general browsing options be added or will this be limited to administratively set up playlists and radio buttons?

[AndyU]

I think you need to offer something more than just a pretty face - a helpful listener would be a step change in functionality. Voice input is becoming increasingly widespread from Amazon, Google and Apple. Let's face it, most folk start off with the thought "Play Kind of Blue", you never start off thinking "Genres Jazz Artists Miles Davis Kind of Blue".  Even a really good text based search could be useful - most people now have decent keyboard skills, at least with two thumbs.

[Manfred]

I am skeptical.

I understand the purpose to have a common simple app for android, ioS etc. to cut down development effort.

But the expectation of people buying specially expensive Apple products is to have an app like JRemote optimized to the apple ecosystem and the device. With a browser interface you have the lowest possible standard across the different UI technologies like swift etc.

Also the browser took a noticeable amount of screen space of your iPad etc.

I would prefer to have Standard View for managing MC as for today and to optimize and enhance!!! JRemote and the Android App. Supporting Windows touchscreen would from my point depend how many potential MC users want to have it. 

[mattkhan]

I think it would be great if jriver had a UX strategy and said something like "this is where we're going, we plan to deliver over the course of the next 2 release cycles (MC23 & MC24)" and that strategy provided for an admin interface along with the minimal set of content consumer interfaces required to service the supported platforms. IMV that would be a selling point.

Adding some other simple HTML5 interface (particularly one accessed via an ip:port combo that will seem pretty obscure to the non technical user) on top of the plethora of existing interfaces is not a selling point and seems more like a waste of scarce resources. Putting the effort into fixing jremote flaws and/or consolidating gizmo and jremote into one fully featured app interface seems like a better use of dev effort to me. I'm not sure why there is yet another app (OneRemote), perhaps that doesn't control MC at all. Confusing.

[JimH]

I think it would be great if jriver had a UX strategy and said something like "this is where we're going, we plan to deliver over the course of the next 2 release cycles (MC23 & MC24)" and that strategy provided for an admin interface along with the minimal set of content consumer interfaces required to service the supported platforms. IMV that would be a selling point.

Adding some other simple HTML5 interface (particularly one accessed via an ip:port combo that will seem pretty obscure to the non technical user) on top of the plethora of existing interfaces is not a selling point and seems more like a waste of scarce resources. Putting the effort into fixing jremote flaws and/or consolidating gizmo and jremote into one fully featured app interface seems like a better use of dev effort to me. I'm not sure why there is yet another app (OneRemote), perhaps that doesn't control MC at all. Confusing.

The obscure HTML5 interface isn't meant for the target user.  It can be saved as a desktop icon or as the home button in a browser.  Someone else would set that up.

I assume you've taken a look at Panel.  The best implementation is in the Lighting section which you may not use, but I use daily.  It's an extremely simple way to accomplish a task.  In this case, the task is starting music like you would turn on a radio.  Two clicks.  Once we get a little feedback, we'll expand the scope.

[mattkhan]

What you suggest is a downgrade on jremote to me.

As far as I can see Panel is a single page that just collects links to an assortment of legacy plain html UIs (webgizmo, webremote, webplay) and the lighting thing (which I haven't seen so can't comment on it). You then have the 2 different apps that have different features and bugs and the main GUI. Ultimately my point is that it would be a (very) good thing to have a strategy for clearing away any legacy interfaces & building the minimal set of UIs (which may mean extending some existing ones or building something new). I would be surprised if that weren't a selling point given the number of posts on the subject of UX.

[Grenache]

So, nearly two years after the announcement of "Pretty Face", this is what we get? Something resembling a very basic and not very pretty remote, if I understand it correctly judging from the comparaison to "Panel" and its "familiar interface". On one hand it's meant to be "an extremely simple interface" with "minimal choices" (if we wanted simple we probably wouldn't be using MC in the first place), on the other hand it needs programming of smartlists that have to be set to the Car Radio buttons and then needs connection to a server via an obscure URL (which all aren't very simple for new users). I understand your goal when you compare it to "like you would turn on a radio. Two clicks.", but you don't mention that the user first needs to build the radio himself.

Please, someone correct me, if I'm wrong, but I don't think this is what most users have been asking for.

[JimH]

So, nearly two years after the announcement of "Pretty Face", this is what we get?

It wasn't quite an "announcement".  Here's the first paragraph of my opening post:

We've been talking about adding another user interface to try to make MC easier to play for people who aren't familiar with it.  I don't know exactly where this leads, but I wanted to propose the idea and let you see if you can improve it.

If you have a better idea, then please post it.

[JimH]

What you suggest is a downgrade on jremote to me.

It's not JRemote or a replacement for JRemote.

[jachin99]

Something else to think about is just how important is the interface for things like panel/ webgizmo, etc with things like IFTTT integration.  With the added convenience of speaking commands to your media center, tablets, Ipads, etc. start to take on a new role.  For me at least, I can use a traditional remote or maybe in the future a spoken command to do things like change channels, or play a song but I can't use those kinds of things for tasks that require me to sort through volumes of information, and make a choice.  Google home does something similar when I ask for a recipe, or ask it a question in general.  For instance I ask it, "How do I cook shrimp", and it responds with a short summary, and then sends a web search of the question I just asked to a tablet where I look up different ways to cook shrimp.  In this scenario, each device is kind of optimized for its particular purpose.

For JRiver lets say I just want to play some music.  I can tell my google home/ amazon echo to just play music but after a while my playlists get old and I want to discover new music or hear something I haven't listened to in a while. Then a tablet or something else that displays volumes of information all at once becomes more useful because it lets me sort through my music or even change music applications. 

[JimH]

For JRiver lets say I just want to play some music.  I can tell my google home/ amazon echo to just play music but after a while my playlists get old and I want to discover new music or hear something I haven't listened to in a while.

Play Doctor is good for re-discovery of old music you have.

[JimH]

Split Consolidate all the remotes

[Listener]

I wonder how far you could get with OneRemote. 

I hope we can work on WebGizmo a little sometime soon, so I'd be grateful to hear what limitations you have found.

As I described in the "consolidate ..." thread, WebGizmo truncates tag values when it displays a list of categories.  The thumbnails are not useful to me so I can't browse using WebGizmo. or Gizmo or Panel.  An example



 

[xtraktz]

For me JRemote interface and style the best!!!

[JimH]

Here's the new interface:

Radio KISS

Before you use it, this isn't trying to be a more powerful Gizmo or JRemote.  It may be best suited to your child or your parent, someone who has zero tolerance for complexity.  It's a quick way to start music, without having to understand a program.

[JimH]

Here's the original direction I outlined in the first post of this thread.  I think Radio KISS is close.  It's not a comprehensive solution (audio, video, etc.) but there's nothing to prevent us from building that, too.

I like the direction this is taking.

We've been talking about adding another user interface to try to make MC easier to play for people who aren't familiar with it.  I don't know exactly where this leads, but I wanted to propose the idea and let you see if you can improve it.

For talking purposes, imagine that it has the functionality of Theater View, Gizmo, and JRemote.  It runs on anything that MC does: Mac, Windows, Linux, and Android.

It might be a separate, but inexpensive product, but it uses MC's library.

It is colorful, more graphical rather than text, and touch friendly.

It can work on a TV, a computer, a tablet, or a phone.

[Grenache]

Here's the original direction I outlined in the first post of this thread.  I think Radio KISS is close.

Really? To me it looks more like an extremely simple remote than what was outlined nearly two years ago. Maybe I read too much into this:

imagine that it has the functionality of Theater View, Gizmo, and JRemote

[JimH]

I changed my mind.  Sorry.  We're not trying to do everything with this remote.  Friendly first.

There are several other remotes that are comprehensive.  This one is easier, in my opinion.

[JimH]

I started a topic called Web Apps and it explains a little more about the direction we're taking.

[JimH]

Just re-reading my original post in this thread.  It's now been two years, but I think that Panel is pretty close to meeting the original goal.

[JimH]

Please use this thread for Panel:

https://yabb.jriver.com/interact/index.php/topic,105883.150.html