Remove slight overlap of focus window on album covers

Feedback Feature Suggestions
21

This is a known UI issue (a number of alpha testers having “provided feedback” about it :grin:). The margin hosting the Focus banner also obscures icons on the Albums as well as artwork, meaning it is not just an aesthetic issue.

The margin and Focus banner are intended to ensure that users can readily see that a Focus search is operative.

The devs have, in the past, said discussions are continuing about the overlapping margin and any proposed change. I’m taking the liberty of renaming the thread and shifting it to Feature Request for discussion by users. I’ll also flag @Brian2 in case he has any comments or news.

My view is that if the margin stays its transparency should be greatly increased so that icons are clearly visible.

22

I would prefer, if it is a ‘known UI issue’ for this to remain as a Bug and not redefined as a Feature Request.
In my normal life, as a Product Manager in the software industry, it is sometimes easier to get items dealt with, as Bugs, rather than new features!

1 Like
23

I already requested this over a year ago:

Basically, once the user has narrowed down their search using the focus feature, the actual focus selection banner doesn’t need to remain in place and clutter up the screen. There should however be some visual reminder that the user is browsing only a selection of their albums using focus.

24

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.

25

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.

26

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
27

[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”.

28

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 ?

29

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
30

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.

Screen Shot 2016-06-24 at 11.08.04 AM.png2272×1760 1.94 MB

6 Likes
31

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

Thanks,
Simon.

32

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
33

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

34

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?

35

Told you !!!

2 Likes
36

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.

37

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!

38

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

Cheers,
Jeff

39

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

40

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