Roon, could you please get the basic usability stuff out of the way whilst you blaze new trails

Gave it a try and it works as you’ve stated :slight_smile: Again, thanks to both of you @anon90297517 and @ToneDeaf. The 2 caveats I see so far is that I need to recreate the bookmarks once I make any changes to my library, and when listening music that is suggested to also be in my library (already) this may actually be nothing more than yet another commercial streaming version copy/link (I know, I’m also streaming my own digital copies :slight_smile: ). Still not intuitive but works as a mitigation for now. Thanks!

1 Like

Meaningful user documentation is an essential component of a software product and should be costed along with all of the other development phases. It should anticipate and reflect user behaviour/workflows, not just describe the product feature by feature. The creation of such a component is as skilled a job as any other in the process, done by trained and experienced technical writers.

When I have paid $699 for a product, I do not expect any part of it to be produced by volunteers.

Maybe I misunderstand the caveat with regard to having to recreate bookmarks, but the way these are supposed to work is as if you are simply ‘running’ the focus ‘query’ - so at any given time it should give you the result for your current library.

See the Knowledge Base here for details. Are you experiencing something different?

I use Roon daily on Windows and iOS devices, so my workflows are well established, but the UI is a complete shambles. Features are implemented individually and crammed in wherever someone decides to put them, creating the most convoluted user processes. Use cases should be developed which reflect every anticipated user behaviour, and the UI (re)developed from those. A couple of examples:

  1. On my iOS device, I select and start playing an album. To see what is in the queue and the playing time left, I have to click the track title at the bottom of the screen to bring “Now Playing, Queue, Roon Radio and History into view”. That in itself makes no sense, but now I can’t see Tracks, Album Info, Credits and Versions any more, a place where it would be far more logical to find the queue. How do I get back to that view? By clicking the album artwork, an entirely different method to get back to where I was than the one I employed to get to where I am now. Obviously implemented by the “where can I cram this feature” method, not what is intuitive for the user.

  2. 90% of the time, I choose what to play by browsing artists or albums, yet those choices are way down the menu in a section called “Library”. The options in the section at the top called “Browse” offers anything but the option to do so. There, in the most prominent part of the UI real estate, I find my most ignored items. Is there a Roon user in the world who uses “Live Radio” more frequently than “Artists” or “Albums”?

Technical features are generally implemented well, the way users work with the product far less so, clearly due to a lack of contemporary design, development and user acceptance testing processes. You can only go so far with software built by enthusiastic engineers, at some point structure and all of the missing disciplines must be put in place or you are forever stuck with a “boy in a bedroom” product. Roon passed that point some time ago.

4 Likes

Bookmarks are dynamic , as you add more content the Bookmark will include them, think of the bookmark as defining a search on you library

Tags on the other hand are static , they are good for say a box set that has a fixed content

Love your post. A perfect illustration of how UI development should be done: starting from use cases as opposed to tacking-on.

As for the quote, just to illustrate that for a given action there can be multiple ways of going about: 90% of the time, I choose what to play by using search.

The developers should have enough imagination to consider multiple ways of doing things and then do the obvious: implement them all.

1 Like

But in fact, you DID pay $699 for that product (or whatever price you paid). Even after a trial period.
I would bet that very few people refrain from buying Roon because it doesn’t have a formal manual, but that many people don’t buy it because of its cost. So does it make sense to increase the cost of the product substantially to include a manual that most people don’t require (or probably don’t even use)? Does it make sense to put effort ($$$) into a manual rather than fix or refine features?

Wiki-like documentation seems more the norm these days for products from small companies like Roon. I DO wish the KB were more accessible and updated more frequently. But at the end of the day, it serves its purpose in the majority of cases.

I for one would prefer features and refinements over manuals written by technical writers.

@ToneDeaf I understand and they work as supposed, undoubtedly. Hence I was grateful for your and Dirk’s suggestion. What I was referring to is that the bookmarks are a result of the focus selection that Dirk suggested so if my library changes the resulting bookmarks that comprise my owned assets (versus TIDAL, QOBUZ, etc) vary. I.e. when I add something to my library I need to re-run Dirk’s and your suggestion that in combination give me what I was looking for in the first place (a dynamically adjusted view versus a point-in-time static bookmark definition). As mentioned it’s a workable mitigation for now because my library doesn’t change on a daily base but the library concept still appears to be broken to me … or phrasing more positively: there’s room for UX improvements :slight_smile:

@Mike_O_Neill Thanks, got it. Still surprised, though. I considered the bookmarks to be a representation of the view I received following Dirk’s focus proposal (like I bookmark a web site). Instead it is a reference (view) on the possibly varying library content. Only the prior focus criteria is static. Nice, and now that I understand probably “good enough” for me moving forward (thanks to all of you) - still surprising from a UX perspective as it was not intuitive getting there …

Where :astonished:, did I miss something?:stuck_out_tongue_winking_eye:

1 Like

Here’s another bug/ oversight that’s an easy fix but gets no love:

If you edit tags on any files that have previously been analysed Roon will merrily re-analyse that which has already been analysed rather than just read in the changed metadata. This despite being able to quickly verify that the underlying audio stream has not changed.

Low impact of you’ve changed an album or two, but not when you go add a roonalbumtag to a whole branch of your music.

How absurd.

Hey Kyle, just a heads up. I have an open topic with support concerning the Blank Screen issue that I’ve had. iPad12.9 Roon Remote Issue. I’ve added a reference to your post here in that topic. The issue sounds similar but may not be related.

It seems that for all iOS apps the user is just supposed to know without any instructions exactly how everything works since after all iOS is completely and entirely intuitive. This is true because God, aka Steve Jobs, in his most infinite and infallible wisdom deemed it so. In other words, the holy church of the three dots.

Thanks for that information @Jazzfan_NJ, I have enabled the Keep Screen Awake option. Does that keep the IPAD screen awake as long as the Roon app is running in the foreground? Or is that in the background as well? Guess I can find that out by trying it. I’ve had the “Blank Screen” issue 4 times in the past month. Each time I’ve had to delete and reinstall Roon Remote to get back to normal operations. Stopping and starting the app does not correct it. I’ve had the issue twice when the IPAD screen was awake so that does not appear to be the trigger in my case.

@Mike_LC As far as I can tell the keep screen awake function only works when the Roon Remote is running in the foreground.

The only issue with this otherwise nice feature is that should you forget that you have Roon Remote running in the foreground the battery will quickly run down since the screen doesn’t go to sleep.

Yes, it keeps the screen awake with Roon in the foreground and not when Roon in the backgound. Tried it both ways. Very handy features and thanks for sharing. I will be keeping that enabled and flip Roon to the background when not actively using the screen.

FYI @Kyle_Kerley @farmbacker, and anyone else that has encountered the issue. I received an update on the support ticket I have open for the “Blank Screen” issue. The support team indicated they have enough information now, from the open ticket, what was posted here and perhaps on other posts they have found, to open an investigation on the issue. I take that to mean someone will be actively working on it.

It’s a good thing you posted in this topic. Had been thinking I was the only one experiencing the problem.

Not quite the spirit of the thread.

2 Likes

Maybe but the facts are the facts…deleted

Thanks for the update, glad to know it’s on their radar.