microsoft / PowerToys

Windows system utilities to maximize productivity
MIT License
107.28k stars 6.32k forks source link

[Preview Pane] Folder preview #16124

Open KillyMXI opened 2 years ago

KillyMXI commented 2 years ago

Description of the new feature / enhancement

When folder is selected - show basic information about it's contents:

The size of folder contents and total (recursive) number of files/folders might be slow to compute, so it's up for debate. Having it for a selected folder makes more sense than filling the Size column in the main view of Explorer. Having a rule to drop computation after certain file counter (Just show "More than ..." after that point) might be a nice compromise as well.

Having a file listing in form of a secondary explorer view might be nice visually but confusing. Not sure about the best way to both communicate the preview nature and ensure consistent looks.

Scenario when this would be used?

Case 1:

I want to delete some folders. I'm trying to ensure they are safe to delete. For this I have to either enter them one after another or hover the mouse over them and wait for a popup to appear.

Opening every folder breaks the context and creates additional cognitive load (remember relative position and what I'm looking for at each moment). Popups are unreliable (don't always appear) and provide very little information.

Case 2:

Speed up the navigation by providing some information about folder contents before committing to go there. This is similar to certain multicolumn file managers.

Supporting information

No response

Jay-o-Way commented 2 years ago

Nice. could be coupled with #356

Aaron-Junker commented 2 years ago

I have doubts that this works. But I can't say for sure

callumc34 commented 2 years ago

Thought the same thing myself, have started working on development over at: https://github.com/callumc34/PowerToys

Aaron-Junker commented 2 years ago

Thought the same thing myself, have started working on development over at: https://github.com/callumc34/PowerToys

Hi @callumc34 Please make you fammiliar with our contribution guidelines. In these we state that you first have an approval of a core team member before you start working. If not we can't guarantee that we will merge your PR.

Cc:@jaimecbernardo

callumc34 commented 2 years ago

Thought the same thing myself, have started working on development over at: https://github.com/callumc34/PowerToys

Hi @callumc34 Please make you fammiliar with our contribution guidelines. In these we state that you first have an approval of a core team member before you start working. If not we can't guarantee that we will merge your PR.

Cc:@jaimecbernardo

How do I get approval?

jaimecbernardo commented 2 years ago

Let's discuss it here. Perhaps a mock would help, and also how it could be accomplished. Regarding accomplishing it, I'm not even sure one can register a handler for previewing folders in Windows šŸ¤”

callumc34 commented 2 years ago

Let's discuss it here. Perhaps a mock would help, and also how it could be accomplished. Regarding accomplishing it, I'm not even sure one can register a handler for previewing folders in Windows šŸ¤”

I have already figured out how to setup the folder handler and have it working. Windows uses the "Folder" "extension" in the registry to handle directories.

Here's a working example image

The GUI aspect is something I would like input on. I was thinking about having a little info bar with total size and the total number of files/folders. For the display of whats inside im not entirely sure what it should look like, was thinking just a list with the icon and the file/folder name.

You can check out the implementation in the latest three commits here: https://github.com/callumc34/PowerToys I've implemented it exactly like all of the other previewers.

jaimecbernardo commented 2 years ago

That sounds like it'd be useful, although it might be a bit slow for some huge folders.

@crutkas , what do you think about this Folder Preview. Is this something we should include?

jaimecbernardo commented 2 years ago

UX needs a bit of work, yes. We need to make sure it properly gets cancelled. For example, if you press down down down on C: folders are huge and it'd be bad having 5 processes at the same time inspecting folders and files.

crutkas commented 2 years ago

I'd like to chat about

  1. UX would look like.
  2. What types of stuff can be done with just the list.
  3. What happens while this is loading (example Win folder is massive)
KillyMXI commented 2 years ago

As a user, for folders with a lot of items I would like to see a partial information asap. If it can keep loading the information in the background and updating it without much flashing - that would be great.

I'd expect it to process items in chunks to provide first information early and cancel processing as soon as I select another item.

callumc34 commented 2 years ago

UX needs a bit of work, yes. We need to make sure it properly gets cancelled. For example, if you press down down down on C: folders are huge and it'd be bad having 5 processes at the same time inspecting folders and files.

I'd like to chat about

  1. UX would look like.
  2. What types of stuff can be done with just the list.
  3. What happens while this is loading (example Win folder is massive)
  1. A better prototype I worked up for the preview, I think an info bar at the top or bottom in an accent color should be a useful addition too. I assume the files should be sorted by name similar to how File Explorer does it, with folders always at the top then files following, though this could also be a user preference. image

  2. I think adding too much functionality is relatively pointless, for example allowing the user to continuously open folders in the preview seems pointless, makes more sense to just open a second file explorer at that point. Potentially could allow for the users to open the file from the preview, though again its only one folder deep you could just click on the folder and then open it. I think the preview works best for just seeing whats in the folder and as @KillyMXI said just seeing whether the folder is empty and general metadata about the folder.

  3. I agree they should get cancelled, however I think that the actual time it takes for the program to retrieve the list of files using Directory.GetFileSystemEntries is actually pretty quick even for larger folders. A simple loading animation should suffice.

There definitely has to be a cap for the number of files shown, i think about 15 displayed at once works well. There could also be a page system so the user can go through all of them by selecting the next page, or simply just stating that there are x more folders/files.

KillyMXI commented 2 years ago

I think the preview should contain the least possible amount of interactivity.

Once you start to recreate a file explorer features such as item selection and opening - you set yourself on a path of complete feature set duplication. If that can be considered a desirable feature then the preview most likely should use a file explorer component (like in QtTabBar). But for me the priority would be to be as lightweight and fast as possible and also least distracting (it's just a preview).

Pagination seems unnatural for the file explorer and adds a lot of interactive UI elements. I would prefer a kind of ellipsis with a message like "... X more items" that can be clicked to load more items. Or "auto pagination" that loads more items if I scroll to the end of the list.

If the load limitations can be dynamic based on the storage medium performance - that would be great. Like, if the whole folder can be processed under half a second on SSD - that's great, no need to break it artificially. If a moderate size folder takes time on a network drive or legacy medium - that's when chunking makes sense.

callumc34 commented 2 years ago

I think the preview should contain the least possible amount of interactivity.

Once you start to recreate a file explorer features such as item selection and opening - you set yourself on a path of complete feature set duplication. If that can be considered a desirable feature then the preview most likely should use a file explorer component (like in QtTabBar). But for me the priority would be to be as lightweight and fast as possible and also least distracting (it's just a preview).

Pagination seems unnatural for the file explorer and adds a lot of interactive UI elements. I would prefer a kind of ellipsis with a message like "... X more items" that can be clicked to load more items. Or "auto pagination" that loads more items if I scroll to the end of the list.

I agree completely, I think as lightweight as possible makes the most sense.

If the load limitations can be dynamic based on the storage medium performance - that would be great. Like, if the whole folder can be processed under half a second on SSD - that's great, no need to break it artificially. If a moderate size folder takes time on a network drive or legacy medium - that's when chunking makes sense.

The load limitations are being drastically overstated. The issue is not with processing the folder, Directory.GetFileSystemEntries is incredibly quick even for large folders, it is virtually the same as running ls -l, the issue is that presenting them all in one windows forms becomes incredibly slow when resizing - though I am not overly familiar with Windows Forms and resizing so perhaps my method & layout is not efficient.

KillyMXI commented 2 years ago

Ah. I keep falling into the same mental trap. Yeah, layout for a very long list can be a bottleneck.

I would still avoid pagination. We should keep in mind it's just a preview, and prevent scenarios with complex interactions.

The hard limit (possibly adjustable) is fine - the user can just open the folder to see more.

The soft limit is probably fine (now I'm starting to question it - maybe it's still too much interaction) - show more items only when needed (on click or scroll). The user will not face performance degradation unless tried hard enough.


If the user invests the effort into interaction with the list, looks for something, finds it and then can't do anything with it - that might be frustrating. Instead, I would rather prevent the user from being invested into the preview too much and nudge into going inside the folder as soon as possible for any complex interactions.

Aaron-Junker commented 2 years ago

I want to add that if you create interaction, you quickly come to a limit in what prevhost is allowed to do. For example creating new folders or files is not allowed

callumc34 commented 2 years ago

This is my current implementation of the folder preview. It shows 15 files and then cuts off showing how many more it is missing. image

It loads pretty much instantly, I dont think theres much reason to add any interactions as it's just a preview.

KillyMXI commented 2 years ago

šŸ“ 4 more...

This might be a bit misleading. I guess it's files or folders and there might be no folders behind the ellipsis. I would try to use an empty icon there.

I guess 15 items in the preview might be a bit low on a large screen? This might be something for experimentation or configuration.

KillyMXI commented 2 years ago

Another idea: Don't show the number in the ellipsis item. Instead, show the total number in the header of the footer. I think the total number might be more useful to see, albeit it might be more tricky to figure out the UI.

(A header or a footer might be useful later to show some additional information.)

Triasmus commented 1 year ago

I don't know if this is still getting worked on, but I would love basic interactivity (really just opening files) and being able to dive into subfolders. The folder preview part of the mockup in this related issue https://github.com/microsoft/PowerToys/issues/16593 looks good to me (besides that it's not doing dark mode...)

My main use-case for the subfolder preview feature in qttabbar has to do with some automated testing processes creating a bunch of time-stamped results folders in each of which there is an html file and an empty file named PASS or FAIL. If the test failed, I want to open the HTML. I have other use-cases where I need to view two layers deep. It's a pain to have to go in and out of a bunch of folders, and a non-interactive folder preview, especially without being able to view subfolders, wouldn't be able to replace the qttabbar feature I've come to rely on.

Given that we're finally about to get integrated file explorer tabs in Win11, I would be able to remove qttabbar if I could find a folder preview option that fulfilled my needs (I'm technically not supposed to even have qttabbar on my work pc... Don't tell my IT :D).

KillyMXI commented 1 year ago

Interesting take.

For this particular scenario I'd probably generate a top-level html summary with links to particular files. If the testing system is out of my reach, then making a script for that is not too difficult. Hard to believe nobody realized you'd need to review and access test results from a single place.

Sometimes I still want to navigate adjacent folders for whatever reasons myself.

My first thought was - there is the navigation pane on the left, can I use it? And I came to conclusion that it turns into a mess once I enable navigation to the current folder. Can't get used to it. There might be a potential for improved navigation pane that would solve the same problem. But realistically, that's out of scope of PowerToys and it is unlikely to be recognized by Windows Explorer team (I haven't tried to raise the issue though). I brought up multicolumn file managers in the OP post. More useful navigation pane would become somewhat closer to the left column of 3-column file manager.

Then I made a pair of buttons for qttabbar to navigate between next/previous folder within the same parent folder and it was enough for me. I didn't use some navigation features of qttabbar itself as I find them intrusive/distracting. That's also why I'd prefer to see the folder preview as minimalistic as possible at least in the first iteration. I don't want to argue that some features might be useful in the preview pane, but I'm worried the flood of locally motivated but overall dangerous feature creep requests will ensue either way. I think careful consideration is needed to define the scope of the preview.