Remove slight overlap of focus window on album covers

Don’t we have a visual reminder of the fact that Focus is invoked already? It’s the “Focused on x of y” message in the top line.

Personally, I prefer also seeing the focus criteria that are currently in place in that second line that overlaps the top row of albums, and I’m happy to live with the overlap as the cost of seeing the criteria. This display of criteria could also be a switchable option.

Yes, but my whole point (and that mentioned by others) is that this visual reminder is far too obtrusive and overlaps the album covers in an unhelpful way. I don’t think many others would share your view of having the banner remain in place this way - though as you say, perhaps some kind of switchable option would be possible.

IIRC It was the fear that a user may forget they are in a focus view that lead to the somewhat ugly and obstructive overlap.

I think there are several other ways to remind/alert a user that a focus is active.

1 Like

[quote=“extracampine, post:7, topic:11787, full:true”]

Yes, but my whole point (and that mentioned by others) is that this visual reminder is far too obtrusive and overlaps the album covers in an unhelpful way. [/quote]

And my point was that the “Focused on x of y” message may not in fact be part of the banner, but the UI element that lists the number of albums, i.e. the “All x” message that gets changed to “Focused on x of y”.

True words and I apologise for having effectively hijacked your thread. In the interests of putting the overlap in its historical context however, I’m going to go further and merge it with the original thread started by @extracampine over a year ago.

The problem with treating the overlap as a Bug is that it has been reported as a Bug, both by users and by alpha testers within Roon’s internal bug database, without resolution. As @brian mentioned in the original thread (now above) it is a tricky problem to resolve. Other things have understandably taken priority. Perhaps now @brian, @mike, @danny its time has come ? Would at least greater transparency of the overlap be possible ?

So, having read the rest of the Thread, I now understand the issues and complexity of screen layout involved.

Also it is ok, to have multiple reports against a bug, it should reflect the priority for any refactoring that is required, just like voting on future requirements. It is also ok, to have Bugs sitting in the backlogs, just along as these are groomed, re-prioritized and re-estimated every so often, following a sprint retrospective (excuse the Agile/Scrum language, I don’t know what Development methodology Roon follows).

I was reacting to the fact it doesn’t look right, with the top of the Album covers under the top navigation bar and tons of space at the bottom of the screen.

In fact, my route to this screen, was a search on a Conductor, which gave me Search Results by Artist, then in the ‘Main Albums’, I clicked ‘All Albums’ which brought up the Focus screen.

Suggestion: The ‘Focused on’ is taking up two lines, with whitespacing around it.

If you made the ‘Focused on’ & the results ‘12 of 4706>’ one line, and reduced the whitespace about and below it, you would get back most of the overlap, and then reduce the whitespace, a little, above the dots at the bottom

Then the integrity of the main components is not changed i.e. the top nav bar, the bottom play bar or the sizing of the album covers, so no major rework!

The marginal reduction in whitespace around the album artworks would be offset against the lack of overlap at the top, which just looks wrong.

Don’t mean to solutionize the problem, but just a suggestion…

1 Like

So there are better focus designs down the pipeline that will provide a more comprehensive solution to this (and other browser shortcomings). In the meantime, I’ve added some margin to the browser when focused so that for a single row of focus cart items the albums/artists/composers aren’t obscured.

6 Likes

That will work - how/when do we see this?

Thanks,
Simon.

Subject to testing, next version release. Releases don’t have fixed dates, the testing cycle for a build (outside the flurry of builds preparing a major release) usually takes between 7-14 days and a candidate build for release started testing today.

1 Like

Oh no now you’ve opened a can of worms there will be no peace now :sunglasses:

ok, looking forward to the next release.
Do you have a Product Roadmap for future releases, based on what’s being worked on & what’s been requested?

Told you !!!

2 Likes

No. We leave it up to the devs discretion because burdening them with reporting and scheduling requests would delay the New Toys. There is a prediction thread as to what is likely to be in 1.3 based on public statements.

Wow, so the Developer’s get to build whatever they wish, and leave the stuff they don’t want to do, undone. I through that with Agile/SCRUM development methologies, Sprints/Interactions the accountability on Developer’s on deliveries was removed, but then not even understanding what they are working on and when it is going to be done, is a step further.
Would make for interesting Product planning meetings with Stakeholders!

That’s a pretty big leap in logic and, IMHO, unwarranted.

Cheers,
Jeff

See this for one of a number of discussions on this forum about this issue.

What would be your problem if the Developers were the Stakeholders?

True - maybe my previous comment was based a ‘traditional’ B2B software company approach, and software development methodologies used, based on Company Goals & Objectives, Customer Requirements and maintaining a User journey/experience. Where a Product Roadmap has to be given and shared with clients, and bugs fixed within contracted SLAs, etc.
And maybe it was just a rough week, in software development and the ‘end of Sprint’ demo/reviews not going well with stakeholders! So, apologies.

All fixed now, in the latest release (1.2 Build 147)

Many thanks,
Simon.

2 Likes

The issue is fixed, but there’s still a lot of scope to improve the layout /aesthetics of the focus results screen.