Print

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

[Isaacc7]

I'm using the trial version and I really like the functionality. It seems to be the only Mac player around that can use dsd files and uses dlna. Plus, jremote is amazing and the whole package is very reasonably priced. I'm having some odd playback issues that I have reported in the bug thread. Since they really do seem to be bugs and are rather specific I'm sure they'll be figured out and quashed.

So yeah, lots to like but...

Clearly it is a windows app ported over to Mac. More worrying are the usability issues. I can forgive a functional app that I don't like the look of but it does not use any of the Mac conventions for menu items, preferences, shortcuts (alt enter?), and I assume other functions built into the OS like full screen, etc.

Will there be a version whose usability is tailored to Mac users? Cmd based short cuts, Mac menus (including preferences using cmd ,) etc. I understand that might take a new version and that's OK with me but I would like some confirmation that development will go beyond simply running on the Mac and get to the point that it is an actual Mac app.

Thanks!

[JimH]

Development on the Mac version is ongoing.  If you have something specific that would help, please say so, but don't expect sweeping changes.

[Isaacc7]

Having a program conform to standard UI/UX is very important if you want to appeal to people using that platform. Off the top of my head I would suggest:

1) Changing the options menu to preferences and including it under the main media center drop down menu. This is the standard place to find these sorts of settings on all Mac apps. Having to search for preferences is a rotten way to start off using the program. In addition, the preferences panel navigation is on the top of the panel and the window below changes as you select the category. Preferences are accessible by the cmd , combination. Speaking of keyboard shortcuts...

2) Use standard Mac keyboard shortcuts and construction. The most important aspect of this is to use the cmd button instead of control. In addition, it would probably be a good idea to duplicate the iTunes commands, at least the common ones as that is what Mac users are probably most familiar with. Cmd-o adds to library, space button stops and starts playback, etc. 

3) Use system fonts and visuals, especially for menu items.

While it may be tempting to consider these "finer points," having a consistent UI is a critical part of how well uses get along with the program and cuts back on the amount of frustration when learning and using it. Right now JRiver Media Center is a very capable, powerful program but it is also very difficult to navigate and use if you're used to software on a Mac. I hope you'll be able to implement some of Apple's human interface guidelines into JRiver as you continue to improve it.

[JimH]

Thanks.  Are you using 19.0.131?
http://yabb.jriver.com/interact/index.php?topic=89012.0

[glynor]

1) Changing the options menu to preferences and including it under the main media center drop down menu. This is the standard place to find these sorts of settings on all Mac apps. Having to search for preferences is a rotten way to start off using the program. In addition, the preferences panel navigation is on the top of the panel and the window below changes as you select the category. Preferences are accessible by the cmd , combination. Speaking of keyboard shortcuts...

3) Use system fonts and visuals, especially for menu items.

+1 on these two (and I've brought it up before).

The biggest issue is the fonts on the drop-down menus up top, of course.  Mostly the visuals of MC itself are okay (maybe not perfect, but it never will be perfect, and isn't completely "native" on Windows either).  But, those menus aren't good.

And I agree about using the standard menu choices under the Application Menu:
http://yabb.jriver.com/interact/index.php?topic=88243.msg604913#msg604913

For this though...

2) Use standard Mac keyboard shortcuts and construction. The most important aspect of this is to use the cmd button instead of control. In addition, it would probably be a good idea to duplicate the iTunes commands, at least the common ones as that is what Mac users are probably most familiar with. Cmd-o adds to library, space button stops and starts playback, etc. 

I disagree.  I mean, yes, the Command button should replace the control button (and it does, unless there's something I missed).  However, I disagree with many of your other points (mainly regarding emulating iTunes).

While this might ease the transition for some users coming from iTunes, it also might lead people astray (you should NOT be creating new Libraries in MC, typically, for example, and certainly not with a keyboard shortcut).  It is far more important to keep this unified with the Windows and Linux versions of MC, so that it is consistent across platforms (again, substituting the Command key for the Control key as appropriate).

It doesn't have to match klunky iTunes is my point, I guess.  They have 19 versions of history behind the scheme here -- it is not designed by accident.

Generally, there are some keyboard commands that are "required" on OSX (Command-Q for example).  Beyond that, though, they're free to implement their own, and I think it makes the most sense to keep it unified.

[Isaacc7]

I'm not sure I see the sense in keeping the commands consistent across platforms as opposed to within the platform. It is far more important IMO to keep to the established way of doing things on that platform. Are there many people that run it on multiple platforms? Ah, it looks as though the command button does work, all of the drop downs show ctrl as the action button. Cmd p means print everywhere else on the Mac platform and cmd s means save. I'd like to see some consistency with expectations from other programs. I understand that there have been 19 versions of the software but 17 of those were windows only, right? I understand that development goes in stages. Would like to see regular shortcuts be respected.

[Isaacc7]

Thanks.  Are you using 19.0.131?
http://yabb.jriver.com/interact/index.php?topic=89012.0

I am not! I'm using 19.0.124. Will download the newer version. Incidentally, it would be nice to have an "About JRiver media Center" and check for updates option under the main application drop down:)

Good to see constant iteration:)

[glynor]

On the upside, at least they didn't spend a bunch of time re-coding those menus in Lucida Grande, right? 

[Bluemoon]

+1 for the OSX native implementation.

OSX has very strict guidelines re how to write GUIs. It's well documented so it's not that difficult to implement. Having said that I also understand the importance of software stability and performance. As far as I can tell 19.131 is stable and performs reasonably well. So, given that Apple is working on the next OSX (10.10) update, maybe this is an opportunity to migrate to the native OSX GUI.

I have both Win and OSX licenses and use both. I still prefer to keep GUIs native.

My 2c

[6233638]

It's well documented so it's not that difficult to implement.

If you're writing a program from scratch that only runs on OS X, perhaps.
And Apple has a habit of completely changing the look every few years, which must be a pain - to say the least.
 
I'm sure that everyone would agree that a more native look & feel would be an improvement - but these things take time.
I've been doing some skinning work for the application on-and-off in my spare time, and that has gone from an iTunes-like clone where I originally modified someone else's skin to update the look from iTunes 9 to 10, to one where I redrew most of it from scratch to match iTunes 11, to working on a retina-capable skin (which means redrawing everything at 4x size) that looked like iOS 7, and now there's a brand new look for OS X 10.10. (similar to iOS but different)
 
Of course I'm just doing this for myself and in my spare time, but that's all been in the space of <18 months, and I've yet to come close to finishing one of these projects and producing a skin I'd be happy to post on the forums here for other people to download.
Most of the time I end up using a modified version of the default Noire skin that I've "flattened" by replacing a lot of the gradients and removing the glossy finish.
 
I do wonder if it would be possible to have a Media Center skin that renders transparency like the new OS X does. There are some transparency effects in there right now for tooltip pop-ups, but it doesn't have the same look, and I think they "cheat" in the way that they're rendered.

[Isaacc7]

Yeah, as the original poster I'm definitely in the I wish it was more like other Mac applications camp. I'm not sure it's fair to say that it would be easy to do though, especially if he's not using Apple development tools. I'm also not sure how easy it is to shift design sensibilities. There does seem to be a big difference in the expectations between Mac users and Windows users. I'm sure it can be a bit of a jarring transition to make:). It wouldn't surprise me if the big aesthetic changes might be a while...
 
I do think that making it look and function like a native Mac app makes good business sense long term. Apple users are (in)famous for being willing to spend money on software. The trade off is that they do expect the program to look a certain way. The functionality of JRiver and JRemote slay iTunes/remote in a lot of ways. If JRiver could be polished up I really do believe that it is only a few reviews from MacWorld or iMore away from getting big in the Apple world.

[mysticisgod]

+1... I would love to see MC look more like most Mac environment apps and I really think you guys would hit it out of the park if you did so. As previously stated above, I can also see how the Windows design look will turn off a lot of Mac users. I have at least one friend who just didn't like the layout/look and found it hard to figure out where setting items are located so he never went beyond the trial period.

[Fred1]

Mac Loo&Feel shoul at least be implemented as an option.
So everyone would have a choice.

[glynor]

I can also see how the Windows design look will turn off a lot of Mac users. I have at least one friend who just didn't like the layout/look and found it hard to figure out where setting items are located so he never went beyond the trial period.

I think it would be more helpful, generally, to explain specific ways we think it should be improved (like the menus and keyboard shortcuts Isaacc7 discussed above).

Generalized "it should have less of a Windows look" is probably not very helpful.  Bearing in mind that MC is a skinnable application (so the overall look and feel of the main Standard View UI is determined by the skin), specific descriptions like "X is bad because bleh and should look like Y" is the way to get improvements.

Jim agrees:

If you have something specific that would help, please say so, but don't expect sweeping changes.

[mysticisgod]

I think it would be more helpful, generally, to explain specific ways we think it should be improved (like the menus and keyboard shortcuts Isaacc7 discussed above).

My issues (Windows feel) that I was referring to were all the same ones which were brought up by Isaacc7 which I think would be a great idea to take a look at. The menus I believe would be the biggest improvement if it followed the look and layout of most native Mac apps.

Myself, I've never owned a PC computer, I've always had Macs (over 20 years) and it took me quite a bit of time to figure out the menu layout and I'm guessing this is how PC programs treat all menus but Macs are quite different.

[6233638]

I agree that it would be nice if the menus were natively themed.
However, you have a problem with a program like JRiver which is on multiple platforms.
 
Do you rearrange the menus so that they are more "mac native" for people that are only using the Mac version?
Or do you keep them as they are so that users can move between platforms with ease, as everything is the same no matter which system you are on.

[Isaacc7]

Programs should always be made to work well on the system they are on. It is much more likely that people will use the program along others on their computer than it is to use the same program on multiple platforms. Even really important programs like photoshop and Word customize their UI to the platform they are on. Those are much more likely to be used across platforms than a media player. Sorry, I don't understand the position that familiarity across platforms is more important. I understand from a programming perspective that it is less labor intensive but I hope that once the main functionality of the program is nailed down there will be changes made to the Mac version to make it a better fit on the platform.

[mwheelerk]

Programs should always be made to work well on the system they are on. It is much more likely that people will use the program along others on their computer than it is to use the same program on multiple platforms. Even really important programs like photoshop and Word customize their UI to the platform they are on. Those are much more likely to be used across platforms than a media player. Sorry, I don't understand the position that familiarity across platforms is more important. I understand from a programming perspective that it is less labor intensive but I hope that once the main functionality of the program is nailed down there will be changes made to the Mac version to make it a better fit on the platform.

I would agree that a design should be optimized for the OS of its intended use. I love this tool and am slowly but surely learning to navigate around the menus and features. I am not a design person so to be able to describe what is different to the look and feel is difficult but I know it when I see it.

I can say that in terms of basic metadata I prefer doing it in iTunes. The layout is just easier to read and use. However I certainly appreciate the range and flexibility of metadata in JRiver which is much better than iTunes.   So in my case it is both a basic functionality and a design sense that would optimize it for Mac users.

If it was truly optimized for Mac and had the feature set available to Windows users I am willing to buy the product again. I am not asking for these things as a free upgrade.

[groovyd]

not having written an OSX application I can only assume that by calling their standard interface API calls you get what looks like a Mac app automatically.  It must take extra code to make it look differently the way JRiver does for things like menus.  Skins are clever but probably more a windows media player sort of feature then a mac feature.  Don't know of many Mac programs that have skins nor do I expect many Mac users appreciate them.  I am happy to have been able to invert the default skin for JRiver to light text on dark background but had I a choice I would invert the whole of OSX to match.  I would be just as happy though to not have the option but have an out of the box interface that just follows the Mac standard, menus, colors, keys, everything.

Am guessing they could probably strip a ton of fat out of the program by getting rid of skins and just calling the standard APIs.

[glynor]

Am guessing they could probably strip a ton of fat out of the program by getting rid of skins and just calling the standard APIs.

It is nowhere near as simple.  I don't work for JRiver, and I'm going on memory and extrapolation from what Matt has explained previously, but... It is something like this:

The Mac version of MC runs essentially (at the core) the exact same code as the Windows version.  MC itself (the Windows version too) is built on a cross-platform framework that JRiver built in-house, which is why the Mac version exists at all.  Unlike other cross-platform applications you've used, it isn't built on an "interpreting language" (Java or whatever).  Nor are there two separately-developed applications which have to be maintained separately.  There is the "core" (the vast majority of MC's code) and then the "OS-specific layer" which isolates what is absolutely required to work with a particular platform (so, the CoreAudio stuff on OSX, and the Direct3D stuff on Windows).  It is all "native" (it is all written in C++ and Objective C).  But, unlike other "written for cocoa" applications, it wasn't all hand-written to use the OSX APIs.  It uses, essentially, the "JRiver APIs" (which are then translated into native API calls where needed).

That's why the menus are hard, for example.  They have to re-build a OS-specific extension to their framework so that the menus are themed right on OSX versus Windows (versus Linux).  As it is now, it is using the same exact code Windows uses to build them (which is easiest, because it requires no duplication of effort to make sure changes are replicated across platform versions).  So, said another way:  It doesn't use the Windows APIs OR the OSX APIs to draw those menus.  It uses the JRiver API to draw them "raw" onto the screen.  So, they need to build an OSX-specific version of that piece which draws native menus (or does a better job faking it).

I don't think this is that "hard" of a task, but it is probably a "big" task.  There's always so much to do...

Hopefully this explains.  But, it boils down to this: The way the Mac version of MC is built is unlike any other cross platform application you've probably ever used.  It is actually a technological wonder, to a degree.  So, they're not "going out of their way" to not use the Cocoa APIs.  They aren't using ANY native APIs (on Windows or OSX) wherever possible, which is what allows a tiny shop to port a massive and complex application like MC across to different platforms, and keep them always pretty much in sync.

[JimH]

+1 to everything glynor said, and I do work for JRiver.

[Isaacc7]

I was afraid of that. If you don't use the developer tools and the native APIs it is much much harder to achieve a native feel. I hope the lower hanging fruit can be gotten to at least.

[Hendrik]

John has been poking the menus with a stick for a bit, maybe we can do some basic changes here to get them feel a bit more "Mac" at the very least.
The overall design of the application is entirely independent of the OS though, and controlled by the skin you're using. Maybe we can come up with an alternative skin that looks and feel more Mac-like, but no promises on that front.

[glynor]

I do think native menus would go a LONG, LONG way.

Target 10.10, though, if you have to fake it (assuming you can't make it detect OS version an fake appropriately).  If possible, I'd use the native AppKit menus (mapped to your internal framework, of course).  There are a lot of small, but significant, OSX "touches" that are hard to get right, but which if missing, completely break the illusion.  Here are a few examples that Mac-nerds love to trot out:

On a Mac, you can click the menu title, hold the mouse button and release on the item.  When opening a submenu within the menus, you don't have to point to the sub-menu title, and then over to the sub-menu itself.  You can drag at a 45deg angle over to your "target" and it will open automatically.

Little fiddly-ness like that is part-of the attention to detail that Apple wins converts with, and... Frankly... The menus are a big part of that "Mac-ishness" feel.  They were the original differentiator, to a degree.

[groovyd]

yeah, hacking a duct tape adapter to make the same core code more or less work across many platforms is only as good as the duct tape holding it together.  sounds like that adapter interface between the core functionality and the various os gui calls need revisited.  atleast in the mac branch it would make sense to deprecate the 'skins' concept and just implement the minimal calls necessary to get basic window and menus looking and acting natively.

[6233638]

I do think native menus would go a LONG, LONG way.

Yes, even if they keep the current layout, native menu behaviors would definitely make the program feel a lot more native.

...atleast in the mac branch it would make sense to deprecate the 'skins' concept...

I don't see this happening.

[Isaacc7]

John has been poking the menus with a stick for a bit, maybe we can do some basic changes here to get them feel a bit more "Mac" at the very least.
The overall design of the application is entirely independent of the OS though, and controlled by the skin you're using. Maybe we can come up with an alternative skin that looks and feel more Mac-like, but no promises on that front.

I think the menu items I mentioned, especially the preferences would be a higher priority than the fonts and the look for me but I will be happy with whatever can be done:)

[Fred1]

One thing, however, that could be done easily:

In the MacOs version dialogs lack the ability to close with the ESC key (without saving changes) or the RETURN/ENTER key (whitch does the default action, normally saving the changes).

In the Windows version this works correctly, in the Mac version it doesn't.

[Afrosheen]

One thing, however, that could be done easily:

In the MacOs version dialogs lack the ability to close with the ESC key (without saving changes) or the RETURN/ENTER key (whitch does the default action, normally saving the changes).

In the Windows version this works correctly, in the Mac version it doesn't.

Yes!  Anything that would make using Media Center more keyboard friendly would be fantastic.  Which is I think the most common request when it comes to making this more Mac-like.  If I could make one personal request is to integrate Media Center with Mac's menubar so that the commands don't look out of place.  

I think the skin of the app is good for now and if there's push for a change, then maybe provide a simple tutorial on how to effectively change it via CSS.  

I still think this app is a huge plus for Mac users.  I just think it's the first impression that might turn people off from the amazing features it has brought to media management on the Mac.

[glynor]

One thing, however, that could be done easily:

In the MacOs version dialogs lack the ability to close with the ESC key (without saving changes) or the RETURN/ENTER key (whitch does the default action, normally saving the changes).

In the Windows version this works correctly, in the Mac version it doesn't.

+1 on this from me as well.

Adam reports they just fixed the Caps Lock issue, so that's good.  And, Matt spilled the beans that they're working hard on getting ripping and burning going.  I can certainly wait until that's done (it is way more important), but this stuff should all stay on the list.

[adamt]

One thing, however, that could be done easily:

In the MacOs version dialogs lack the ability to close with the ESC key (without saving changes) or the RETURN/ENTER key (whitch does the default action, normally saving the changes).

In the Windows version this works correctly, in the Mac version it doesn't.

This has been fixed and will be in the next build.  Thanks for the report!

[glynor]

Thanks Adam!!!

[paul.raulerson]

It is nowhere near as simple.  I don't work for JRiver, and I'm going on memory and extrapolation from what Matt has explained previously, but... It is something like this:

The Mac version of MC runs essentially (at the core) the exact same code as the Windows version.  MC itself (the Windows version too) is built on a cross-platform framework that JRiver built in-house, which is why the Mac version exists at all.  Unlike other cross-platform applications you've used, it isn't built on an "interpreting language" (Java or whatever).  Nor are there two separately-developed applications which have to be maintained separately.  There is the "core" (the vast majority of MC's code) and then the "OS-specific layer" which isolates what is absolutely required to work with a particular platform (so, the CoreAudio stuff on OSX, and the Direct3D stuff on Windows).  It is all "native" (it is all written in C++ and Objective C).  But, unlike other "written for cocoa" applications, it wasn't all hand-written to use the OSX APIs.  It uses, essentially, the "JRiver APIs" (which are then translated into native API calls where needed).

That's why the menus are hard, for example.  They have to re-build a OS-specific extension to their framework so that the menus are themed right on OSX versus Windows (versus Linux).  As it is now, it is using the same exact code Windows uses to build them (which is easiest, because it requires no duplication of effort to make sure changes are replicated across platform versions).  So, said another way:  It doesn't use the Windows APIs OR the OSX APIs to draw those menus.  It uses the JRiver API to draw them "raw" onto the screen.  So, they need to build an OSX-specific version of that piece which draws native menus (or does a better job faking it).

I don't think this is that "hard" of a task, but it is probably a "big" task.  There's always so much to do...

Hopefully this explains.  But, it boils down to this: The way the Mac version of MC is built is unlike any other cross platform application you've probably ever used.  It is actually a technological wonder, to a degree.  So, they're not "going out of their way" to not use the Cocoa APIs.  They aren't using ANY native APIs (on Windows or OSX) wherever possible, which is what allows a tiny shop to port a massive and complex application like MC across to different platforms, and keep them always pretty much in sync.

Everything there makes sense of course.

I am getting to the point where I think it would be nice to totally disable the entire interface, like the media server. It would be delightful to have the Windows video options, but without all the other interface hooraw. If I want to play a movie, I want to see the movie, not MC.

Would be especially nice on the Mac, but that may never happen, or may be a very long way off. I do understand CD ripping is about to happen on the Mac version. That's exciting!

-Paul

[saitoh]

Having done programming and understanding the approach your using, I can sympathize with the constraints.

My one request other than menus is to move the window control buttons (minimize/max/close) to the left side like every other OSX app (or at least the option to move them over there). Don't want to go to the three dots? Thats fine, but it's really counter intuitive to go to the right on a mac regardless of what the icons look like. As someone who uses both Windows and Macs daily, I've never had an issue switching back and forth as it's consistent within that system. In some ways, I'd trade the odd menus for that left side control orientation.

Just my two cents. If this was covered elsewhere, my apologies. Thank you.

[6233638]

My one request other than menus is to move the window control buttons (minimize/max/close) to the left side like every other OSX app (or at least the option to move them over there). Don't want to go to the three dots? Thats fine, but it's really counter intuitive to go to the right on a mac regardless of what the icons look like.

They should be on the left if you are using the default Noire skin.

[saitoh]

They should be on the left if you are using the default Noire skin.

problem solved! I didn't notice that, my bad. Thanks.