Linked ListDetails View

[oenarap]

Maximize usage of available screen(s) real estate by allowing multiple master-details be displayed at a time.

I am wishing for a feature that is kind of similar to Fabian Sauter's MasterDetailsView PR but taken a little further.

Describe the solution

Imagine having all your displayable master-details view(s) rolled-out across your screen(s) with no wasted space whatsoever. But then, can be collapsed to fit in the size of a mobile phone's display without losing usability -- the crux of UWP apps!

Describe alternatives you've considered

I've considered using MasterDetailsView, BladeView and combination of both, but would require a daunting amount of workaround to get near the result i wish to achieve.

Additional context & Screenshots

I have been toying around with the idea for a while now. You might want to take a look at a rudimentary implementation i currently am working on: https://github.com/oenarap/CDLNPeople/tree/master/CustomControls.Controls/LinkedViewControl

i took inspiration from behavior of People app that shipped with Windows 8.1/10. I'm not sure, but definitely not the latest version.

screenshots:

compact (the most recent pane the user interacted with remains displayed)

optimal

full

extended

...etc.
...etc.

Hello, 'oenarap! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[Kyaa-dost]

@oenarap looks like an interesting feature to have but not sure about the work it would require as you have emphasized the complexity 🤔

[skendrot]

This does seem like a good use for the BladeView. In your "optimal" screenshot, wouldn't you want to view the the details of Mr. Potter and his personal information since that's currently selected?

[oenarap]

@skendrot the second pane visible in "optimal" screenshot is some sort of quick view of a person's details most relevant to the user. the lower part serves as a navigation list.

anyway, the content is not supposed to be the issue.

as i've mentioned in the "alternatives", BladeView and MasterDetailsView are two closest to fit my scenario. it's just that i get lots of friction when i try to achieve a behavior like this:

kudos to the watermark!

[michael-hawker]

Thanks for this great suggestion @oenarap! I could almost definitely see this as an option on BladeView somehow. It really feel similar in layout/behavior to that (outside of this collapsing behavior).

I mean the Master/Details vibe does show in your example, but I think that could still be left to the developer and manipulated via separate blades? Maybe we also need an option for BladeView to remove the header/controls on top of the blades to provide this more fluent look?

I'll add this to our 7.0 milestone for now, is this something you want to take on yourself to implement & contribute or are you looking for assistance?

[oenarap]

Thanks @michael-hawker!

i'll be glad to go either way. if you let me take on it alone, fine. if you want me to collaborate, it's just the same coffee. so long as this idea gets "adopted and improved" by the community, it's a big win for me and perhaps, everybody.

[michael-hawker]

Thanks @oenarap, it would be great to see what you come up with!

Since we already have the TitleBarVisibility flag on BladeView, I see that this could be a combination of:

1. Modernizing the BladeView style (@mdtauk & @niels9001 - fancy a gander? 🦙❤)
2. Making it easier to have Blades adapt to their Content's sizing (I think they're pretty stiff currently).
3. Adding a new BladeMode property for this new type of Stacking behavior of the panels.

I think the Master/Details scenario part of it is probably secondary and either left up to the developer to manage, or maybe becomes some sort of separate navigation helper/tracker (I'm curious what @Sergio0694 does as he mentioned something like this once I think).

One thing I wanted to clarify from your screenshots was if if the NavigationView bar was excluded from your vision or somehow integrated to the control??

I'm also happy to point folks from the UWP Community Server onto this topic for more input from the community, or feel free to start a discussion there.

[mdtauk]

The only thing I would suggest, is to consider how this kind of control would work with the two pane view, and for dual screen scenarios.

This kind of UI may be cumbersome for the user

[Sergio0694]

@michael-hawker Yeah you're correct, I do have something like this in both OneLocker and Legere. I wrote my own shell that I'm reusing across both apps (with some modifications), which includes two main panels (à la master-slave), and two additional side panels. The navigation system bounces back and forth between the two main panels and keeps a navigation history across them, so that when you shrink the UI down, the correct panel stays on top and the user doesn't lose track of the workflow. This also works well on mobile (OneLocker runs on W10M too), as the system completely hides the two main panels and the user only sees them as one. My shell in particular also includes some various animations/transitions for the various sidebars, as those are not considered on the same level as the two main panels, but more like accessories (the hamburger menu on the left, and the sidebar on the right).

Here's a picture of the main visual states so that it's clearer to see what I'm talking about:

I have to say I'm a bit puzzled as to how something like this could work as a reusable control, as there are a lot of moving parts that need to come together, plus users might want to customize lots of different aspects to fit their needs. For instance, I couldn't just reuse my OneLocker shell, I forked my own shell and customized it again to perfecty fit my needs in Legere.

What I mean is, the shell of the app is particularly important both for the UX as well as to define the brand, as different publishers might want to keep a distinct look and feel for all their apps (eg. like I'm doing with the same shell for OneLocker and Legere, see screenshot):

That is to say, we might probably want to think about how much customization to add so that it's enough for the majority of users that would be satisfied with just using a shared control from the toolkit with some light restyling, but also so that we don't waste time adding in too many customization features trying to appease devs who would not be using the control anyway, opting instead for their own custom shell. Just sharing my two cents here of course! 😄

[oenarap]

@michael-hawker i agree the BladeView would offer the best springboard for this.

with that said, i think we can dismiss any concern about reusability. anyone?

@mdtauk if BladeView provides in-built functionality to split between two BladeViewItem to accommodate two-pane or multiple-screen scenario, then users should be able to focus their time and energy on the contents. and based on my understanding, that should always be the ultimate goal for an author. i would appreciate it if you can share something from your standpoint that guarantees this idea is doa.

@Sergio0694 thanks for the input.

@michael-hawker sorry if i got stuck with the "master-detail" thing. it has always been the way i imagine how "contents" will be presented. and as i said earlier in this thread, "contents" is not supposed to be the issue.