Discussion: File/Folder picker

[ZenBird-zz]

Discussion: File/Folder picker

I am currently working on a File/Folder picker Reunion SDK for UWP. Is there a Picker UI available that I can use? or is there one in the works?

Related Links

https://github.com/microsoft/ProjectReunion/pull/99

[mdtauk]

There used to be a Picker UI in the Windows 8 days, which was a full screen experience.

With the move to Windows 10, the classic Win32 CommonCtrl dialog is used.

For a Reunion API - using Win 7 and 8 should use that Win32 dialog, but for Win10 onwards - a new XAML version should be created - not sure if that would belong to Reunion or WinUI - but as one of the most often seen UIs in Windows - it should really be in Xaml, and demonstrate that WinUI is more than ready to "replace" Win32 components, like it has with the UAC Dialog

[StephenLPeters]

Have you taken a look at this?

[ZenBird-zz]

Have you taken a look at this?

This is exactly what I am trying to replace with the new Picker. This API is not very functional. The attached PR talks about the missing features.

[StephenLPeters]

Cool, so your question is if additional design work has been done in this area since that was created?

[ZenBird-zz]

Not really. The current PickerUI does not allow for picking of multiple folders or files and folders together. The options here are:

1. Relax the restrictions in the PickerUI that will allow for picking multiple folders, files and folders.
2. Build a new Picker UI that allows for a richer experience (at par with Win32 dialog).

My vote is for #2 since it will bring the Picker experience to what developers are familiar with.

[mdtauk]

I also enthusiastically vote for 2 also. Build a new UI that can be extended by the app, and used for both UWP and WinUI Desktop apps - and also will look at home on Windows 10X/Xbox/Surface Hub etc.

[Felix-Dev]

I strongly favor point 2 as well.

[shaheedmalik]

It really needs to be rebuilt. With the move from Windows 8 to Window 10, most of the pluses from the Win8.1 picker were removed and it seems like it just regressed.

It needs to be built to be scalable for multiple form factors and not just "Desktop or nothing" or "Tablet mode or nothing"

[mdtauk]

I am currently exploring ideas for this, and starting with the current Windows Open/Save File Dialog layout - it seems a bit unrefined - so I am looking at other file presentations for inspiration.

[mdtauk]

Some refinement, currently simplifying the elements before adding more

[ZenBird-zz]

This is pretty interesting. Is the idea to provide an API to populate the UI?

[mdtauk]

This side textbox idea is not working lol, moving on

[Felix-Dev]

Also adding @duke7553 here as he is the creator of Files UWP and thus might have some expertise on this topic.

[mdtauk]

Also adding @duke7553 here as he is the creator of Files UWP and thus might have some expertise on this topic.

The real problems will start when you start adding in support for custom save options.

The control density will take up a lot of space without moving them into a flyout - but not sure the likes of Adobe would like that

[mdtauk]

So breaking the control apart

The Save Options areas will render xaml controls for options the developer chooses to include. With the existing Win32 API https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ifiledialogcustomize this is a series of IFileDialogCustomize methods

Whilst I am reluctant to enable "anything goes" custom xaml to be presented here, the new API should allow controls to be specified, and values to be read back - during the file open and save workflow.

These controls should reflow logically with resizing, (the form control proposal would make sense here #82 )

---

Looking at each piece of the dialog, I think its mostly the top navigation/breadcrumb toolbar that needs some work. As well as the grid/detail/icon view area and it's toolbar for New Folder, View Button Flyout, and whatever other view specific controls are needed.

This is not part of File Explorer, so does not need to use the same layout or infrastructure, and can be rethought for Fluent Design and modern UI

[shaheedmalik]

@mdtauk, how do you think it should look for touch interfaces?

[mdtauk]

@mdtauk, how do you think it should look for touch interfaces?

These controls are using the standard WinUI control sizing, so they should all be touch ready. The sizing of the window/modal window would most likely be full screen if the device is in Tablet Mode.

Are there any touch affordances you feel are missing?

[shaheedmalik]

@mdtauk, how do you think it should look for touch interfaces?

These controls are using the standard WinUI control sizing, so they should all be touch ready. The sizing of the window/modal window would most likely be full screen if the device is in Tablet Mode.

Are there any touch affordances you feel are missing?

Right now, it's hard to select multiple objects. It's very unintuitive. One thing that the Win8.1 version did that I think was right was the ability to swipe on files to select them.

Another thing I think should be worked out is the ability to pull from other apps. This feature worked well, in Windows 8.1, but not well in the Windows 10.

Visually, this doesn't mess well.

[mdtauk]

Right now, it's hard to select multiple objects. It's very unintuitive. One thing that the Win8.1 version did that I think was right was the ability to swipe on files to select them.

Ah so the grid view region I imagine would use standard WinUI List or Repeater controls, and so could support the same multi-select gestures, but perhaps those are not enough to give you a good experience?

All of the UI would use WinUI and not use the Win32 controls.

[WamWooWam]

Look, I've gotta be honest with y'all here, as much as a new fancy and pretty file/folder picker sounds nice in concept, in practice I don't see this as a particularly good idea for a couple of reasons.

Windows Explorer is ancient, and while this can be a drawback at times, this also means it's extremely powerful. As it stands, within the current pickers I have access to all my available shell extensions, every view/sort/grouping available in Explorer as well as extensions like the preview pane and full properties/extended properties dialog. All my folders follow the same view preferences as they do in the file browser, and everything works as the user would expect. There's almost nothing I can do in explorer that I can't also do in the file pickers, and I see this as a massive strength.

A replacement to these dialogs can't be a downgrade, especially for power users, and almost every single time an application has attempted to recreate it's own file browser, it's been (in my opinion) vastly inferior to just the simple, native control. It's something new to learn, it's inconsistent, and generally much less functional than plain old Windows Explorer.

To add insult to injury, this would be the 4th kind of native file/folder picker within Windows itself. There's already the "classic" Windows XP-era open/save dialogs still in use by some applications to this day, the absolutely ancient and awful to use folder picker straight out of Windows 95, and the more modern Vista-style common control dialogs used now. Adding yet another picker for end users to learn seems counter productive.

To be clear, I'm not saying the current common control dialogs couldn't do with a spruce up, as already noted, the camera/photos app integration is butt ugly, and could be done way better, but as it stands I don't see adding a whole new dialog to be the solution to this problem.

[shaheedmalik]

To be clear, I'm not saying the current common control dialogs couldn't do with a spruce up, as already noted, the camera/photos app integration is butt ugly, and could be done way better, but as it stands I don't see adding a whole new dialog to be the solution to this problem.

So to be clear, you think fixing something isn't the solution to the problem. And we shouldn't fix something because there are apps being used by apps from Windows 95 or Vista? This mindset is what is dragging down Windows. Apple releases a whole new OS style and people applaud and want to develop apps for them (Apps that use the updated consistent design language.), and Windows is left because people don't want to improve things. That one thing will cause a domino effect in the rest of the ecosystem.

Here's the thing about WinUI3. Nobody is forcing that app from Vista from being upgraded. I tell you what, equal function, people will pick the pretty app over the ugly one.

[WamWooWam]

So to be clear, you think fixing something isn't the solution to the problem. And we shouldn't fix something because there are apps being used by apps from Windows 95 or Vista?

Not in the slightest, I'm saying adding new, additional pickers alongside the pre-existing ones simply creates fragmentation between existing apps that use the older pickers, and the newer apps that have adopted the newer ones. It's more to learn, and Windows has enough to learn as is.

Here's the thing about WinUI3. Nobody is forcing that app from Vista from being upgraded.

Thus creating the aforementioned fragmentation and cognitive overhead. On top of this, unless these new dialogs are system wide, it doesn't really solve the problem at all, as there'll always be apps using the existing ones that don't work very well for touch etc.

I tell you what, equal function, people will pick the pretty app over the ugly one.

Equal function, sure, but that implies equal function is something you achieve, and so far I haven't seen a single non-native picker match the capabilities of the existing one, and ditching the Windows Explorer base (and all the masses and masses of functionality and consistency that come along with it) in place of something that looks prettier isn't gonna go very far in achieving that.

[mdtauk]

Windows Explorer is ancient, and while this can be a drawback at times, this also means it's extremely powerful. As it stands, within the current pickers I have access to all my available shell extensions, every view/sort/grouping available in Explorer as well as extensions like the preview pane and full properties/extended properties dialog. All my folders follow the same view preferences as they do in the file browser, and everything works as the user would expect. There's almost nothing I can do in explorer that I can't also do in the file pickers, and I see this as a massive strength.

Future versions of Windows may not include File Explorer, and may not support third party extensions. This discussion is not about breaking support for existing apps which call upon these common file dialogs - but about making a new version which moves forward, and can be supported by WinUI Desktop, UWP, and possibly Reunion Apps - wrapped in a modern API.

A replacement to these dialogs can't be a downgrade, especially for power users, and almost every single time an application has attempted to recreate it's own file browser, it's been (in my opinion) vastly inferior to just the simple, native control. It's something new to learn, it's inconsistent, and generally much less functional than plain old Windows Explorer.

Not a replacement in that all apps automatically use it - but for new WinUI apps, and apps opting into the modern Reunion APIs - so if an app compiles with WinUI and Reunion - they are aware of what the dialogs offer.

To add insult to injury, this would be the 4th kind of native file/folder picker within Windows itself. There's already the "classic" Windows XP-era open/save dialogs still in use by some applications to this day, the absolutely ancient and awful to use folder picker straight out of Windows 95, and the more modern Vista-style common control dialogs used now. Adding yet another picker for end users to learn seems counter productive.

It was due to inadequacies of the XP/98/95 era dialogs, that new Vista ones were developed. And those replaced the Windows 3.1 era ones.

The Windows Shell is over time, being re-written with Xaml, and Windows 10X/Xbox will require better solutions. A new API could just wrap around existing dialogs, patching security issues, new platforms will require duplication of work by building their own dialogs and wrappers for them - this being a Reunion scope item, could be a way to unify.

To be clear, I'm not saying the current common control dialogs couldn't do with a spruce up, as already noted, the camera/photos app integration is butt ugly, and could be done way better, but as it stands I don't see adding a whole new dialog to be the solution to this problem.

The solution is developing a modern API for file access, and file system access, possibly at the Reunion level. The Dialog, is just building a modern composable UI that will be supportable for modern form factors.

[mdtauk]

The area which would display the local file system could perhaps display a Xaml apps' designated Picker Entry Point - or even a web app.

This rough example is showing a Google Drive webpage in that space.

[shaheedmalik]

The area which would display the local file system could perhaps display a Xaml apps' designated Picker Entry Point - or even a web app.

This rough example is showing a Google Drive webpage in that space.

This is fluid!

One thought. The button that says "Switch to local storage" can be accomplished by simply putting a down arrow on the Left hand side right after the source title, in this case, "Google Drive". This way, one can switch to other apps as well.

[mdtauk]

This is fluid!

One thought. The button that says "Switch to local storage" can be accomplished by simply putting a down arrow on the Left hand side right after the source title, in this case, "Google Drive". This way, one can switch to other apps as well.

I did say it was a rough example.

That functionality would probably be built into the navigation/breadcrumb bar, if its part of the spec/API. It just occurred to me that the dialog could accommodate UI from another source - how that would be implemented is for greater minds than mine lol.

[mdtauk]

Here is an exploration of the Toolbar

The top one is for local storage and devices - still not totally sure on the design, but it has Navigation, Breadcrumbs, and Search

Then there is a WebApp/PWA - which gives you basic web navigation and refresh - as well as More options buttons

Finally there is a Xaml App - which can maybe request buttons in it's toolbar - and then a Xaml page rendered below.

[sjb-sjb]

Why wouldn’t you just do a port of the UWP pickers?

[mdtauk]

Why wouldn’t you just do a port of the UWP pickers?

UWP apps on Windows 10 - display the Win32 pickers. On Xbox, 10X, and I think Hololens / Surface hub use a Windows 10 Mobile era File Explorer app as it's picker interface.

So a new shared API spec, needs to provide more from it's Picker interface - and if you do that, why not extend it to add new features and support for cloud storage as well as Xaml apps and File System access.

[sjb-sjb]

@mdtauk how do I call the Win32 pickers from a Desktop+WinUI app? The "Windows.Storage.Pickers" namespace is not on the list of Windows Runtime APIs available to desktop apps.

Seems like something that should be do-able. Personally I don't need anything beyond what UWP offers.

Or is this what is being dealt with by microsoft/ProjectReunion#99 ?

[mdtauk]

@mdtauk how do I call the Win32 pickers from a Desktop+WinUI app? The "Windows.Storage.Pickers" namespace is not on the list of Windows Runtime APIs available to desktop apps.

Seems like something that should be do-able. Personally I don't need anything beyond what UWP offers.

Or is this what is being dealt with by microsoft/ProjectReunion#99 ?

I would assume its Project Reunion, as it will have to provide the security around the file access - this topic would be for the visual design and UX

[sjb-sjb]

@mdtauk thanks for the comment. With Desktop+WinUI there are no security limitations, I believe. So, I am still trying to figure out: how can I call the Win32 pickers from Desktop+WinUI ? Should be do-able currently ... I'm just new to the Desktop+WinUI programming environment.