File Browser options minor UI improvements
Open, NormalPublic

Description

I had a few ideas on some re-organization for the file browser options Here is the proposed changes (just the section highlighted in green)

Right now, every section is separated with panels. Is this needed? I am curious to see what other people's file browser looks like. Does it really get that long for some people? Panels create a lot of stuff ( lines, corner sorting thing, triangle), so I thought removing them would make it a little cleaner. People can always scroll if they happen to have a ton of stuff. Scrolling is easier than clicking in my opinion.

The system and system bookmarks list can't be edited (to my knowledge). Combined them to show their relationship better. Moved section operations to the bottom and made them a little more descriptive.

The goal is just to simplify this a little. Nothing too major.

Thoughts?

Details

Type
Design

Related Objects

I don't agree that the panels are much an issue. In fact, it may often be useful to hide, say, the System drives list. If everything was all in one panel, you woudn't be able to do that. Some Import/Export formats also display a rather long list of settings in the bottom 'operator' panel. You might want to hide other panels to give this panel space.

There are things we could do to make panels nicer and clearer throughout Blender, but IMO that's a separate issue.

However, I think there are things we could do to make the file browser clearer. For example. the huge buttons to add bookmarks is not needed, and the fact that system bookmarks are separate from Blender-bookmarks is also confusing.

Also, the fact that the Open command is in the upper right is not that great. There's a reason logos are often in the bottom right: it mirrors how we read (from top left to bottom right) It also matches the workflow to have it in the bottom. You first navigate to the file, then you press Open.

Here's a quick sketch of simpler buttons for adding bookmarks, plus the Open button in bottom right:

@William Reynish (billrey) Some good points.

Some of the exports have pretty long export options. I didn't realize they got that long.

I do like the Open and cancel buttons on the bottom with the file name. I wonder why they ended up on the top? Apple, Windows, and Linux OS all seem to have those actions on the bottom. System and system bookmarks aren't manageable (add, delete), so maybe that is why they are separate from Blender bookmarks? I like moving the file path operations ( back, forward, up, refresh) closer to the filepath field. It shows their relationship better. Moving all of the filters and create directory closer to the files also seems to strengthen the relationship as to what you are filtering (pretty much moving everything from the header).

@William Reynish (billrey) Could you provide a more fleshed out mockup with your ideas? My task just outlines one section, so maybe it would be good to close out this task and create a new one dealing with the entire file browser. I think just doing a little re-arrangement is all this area needs.

Maybe it's helpful to update the lists layout to the new lists layout of Blender (i.e. used in UV map list), to include the max height delimiter and the filter options, putting the buttons aside the list.

Or, as suggested by @William Reynish (billrey), also to merge System and System Bookmarks painels:

@Paulo José Oliveira Amaro (pauloup):

Yes I think it makes sense to use the re-use the same list UI here. It's also a good idea to combine System and System bookmarks. Conceptually they are the same thing - system paths.

Just a quick interjection from my side: @Paulo José Oliveira Amaro (pauloup)'s suggestion to update the lists to the new list style could possibly already be happening in the course of my work on T37881 - File Browser renaming of bookmarks. I'm still mostly reading through the code and assessing the situation, but so far my understanding is that the lists in the file browser are all coded in pure C and all fancy, new lists that allow renaming and such utilize the bpy.types.UIList python template. Thus a rewrite of the file browser sidebar layout in python might be a necessary and/or favorable decision for the sake of a good and DRY implementation.

I will further follow this conversation before going into any actual changes, and in any case I will need the python rewrite plan approved by a module owner, not sure about all the implications.

Aside that I have a question on the "System Bookmarks" - What data does this feed on if it's not user editable inside Blender?
I somehow assumed it would maybe import data from the OS-native filebrowser, but at least on my Ubuntu installation I don't see any resemblance between what "System Bookmarks" my (Nautilus) file browser shows, and what's showing inside the Blender File Browser.

@Simon Repp (simonrepp): Yes, the System Bookmarks is meant to reflect the bookmarks in the system-native file browser. It works on the Mac and afaik also on Windows, so that any folder added to the sidebar in Finder (or Explorer) also appears in Blender's System Bookmarks list.

Don't know about Nautilus and all the flavors of Linux and their respective file browsers. Perhaps some of these are not supported? In Linux you have loads of file browsers, and supporting all of them is likely more of a hassle.

The issue with the System Bookmarks is that it adds an extra category that's not needed. You end up having too many panels of bookmarks inside Blender. I think it's better to have System (drives and system bookmarks), Bookmarks (Blender bookmarks) and Recent.

@William Reynish (billrey) I think those are mostly good changes but I would be hesitant to merge the System Bookmarks and Bookmarks. Bookmarks serve as a way to add a custom shortcuts to often used areas and as such need to be editable by the user (from within Blender). You can't do this with the System Bookmarks but you can with regular Bookmarks. And so if you were to merge them then it would be a confusing mix of editable and non-editable.

That being said, I agree that it seems unnecessary to have both. I would be more inclined to simply remove System Bookmarks, and then add a little startup script that detects the OS level bookmarks and creates them in Blender the first time Blender is started (if the user does not have existing preferences).

@Jonathan Williamson (carter2422): I don't think we should merge Bookmarks with System Bookmarks. I think we should merge System with System bookmarks. :) That way we have a clear separation between System stuff and Blender user stuff.

Here are some updated mockups for improved File Browser design.

The issues:

Suggested outline:

  • Merge System with System Bookmarks
  • Place Name field, Cancel and Open buttons at the bottom
  • Move Up, Back, Forward, Reload closer to the file list
  • Make New Directory an icon
  • Add and Clear buttons for the bookmarks are simpler, less distracting, and take up less space
  • Opening the File Browser spawns a new window, rather than using the confusing 'Back to Previous' button at the top
  • Filter icons are hidden when the Filter feature is disabled.
  • Open/Save/Import/Export button is highlighted (this is what happens when you press return. It draws more attention to the main task)

With Graphics:

William Reynish (billrey) renamed this task from file browser options minor UI improvements to File Browser options minor UI improvements.Jan 1 2014, 7:32 PM

@William Reynish (billrey) nice mockups. This looks nice! I agree with your points in yellow with the first attachment. This is the direction I would go as well.

There are a few options that I don't see in the mockup (incremental savings -- +/- by the file name). I don't see the "show hidden" option, but that seems like it should be a filter grouped with the other ones.

I think opening this in a new window is a good idea. With the current implementation, having the Info bar on top doesn't really help at all since they aren't relevant. The whole "back to previous" doesn't seem to add any value (maybe it did at some time).

@Scott Petrovic (scottpetrovic):

Yes, I think the Filter options (+ Show Hidden) could appear in a second row when Filter is enabled, like so:

The +/- buttons should only appear when saving files I think. Doesn't really make sense when opening I don't think?

When saving, it could look like this:

Nice work @William Reynish (billrey). I think each of your points, in particular opening in a new window and the reading direction are spot on. I suspect "Opening in a new window" will present some extra problems to resolve (such as auto closing the window) but I can't imagine they'd be too much.

If you're willing, would you care to take your mockups and apply them to Export as well? Exporting will have some additional options applicable to the chosen file format. A good test case would be Collada. Currently these options show in the bottom left panel, but this breaks reading direction.

I actually quite like the fact that Blender opens the file browser full screen and not in a smaller window. When you've got directories with many files or .blend files with many datablocks it's quicker to browse and find the right files. With a smaller window you also get less space for operator properties and more scrolling there.

I know the standard is to have these smaller modal dialogs, but I feel that for 'serious work' what Blender does is better than these. With a big file browser and the file name at the bottom the design doesn't work so well, but I would rather solve that another way than adding more scrolling.

I will add that while I think opening in a new window is a better idea, I have never had a problem with it opening fullscreen in the current window. The Info bar does add some confusion, but I think it's secondary to the other issues (such as overall organization and layout).

I agree that the modal window is a slightly better option since you don't have to worry about the info bar. It is one of the few instances when info bar isn't relevant to what you are doing (user preferences being the other). It isn't a major issue though. The non-overlapping aspect is a little cleaner with leaving it in its space. The file name on the bottom isn't that critical either. It is on the top on Mac OS, so it isn't that odd to have it there. I think as long as the filters and operations are in close proximity to the respective fields, that is most important.

I agree to @Brecht Van Lommel (brecht). Full screen for open file window is a need when working with sequence strips, when you have to control the selection of a long image sequences. Not only Blender uses it but also another applications, like Adobe Lightroom. As was said, for serious work, it's very needed.

@Brecht Van Lommel (brecht): Yes, it's true that we perhaps loose a bit of space this way. But you could still maximise the dialog if you want, so not sure it's really an issue?

Most Open/Save dialogs waste a lot of space at the bottom for options which makes the area. In Blender we place those objects in the list on the side which saves lots of space for files and folder, so we already have more space compared to most apps.

Alternatively, we could make the Open/Save/IO dialog be completely full screen. The Info header, and Editor Type drop down is confusing here. It makes the process unclear as there's no real separation between the Info bar and the rest of the UI. Aperture also uses a full screen browser. The way it works is that it animates in and out in a way that makes it clear that it's on a separate layer.

I still think a separate window would be clearer, because you can clearly see that it's a temporary dialog (the rest of the UI is seen below). At the moment that's not well communicated.

I don't think expecting users to maximize it is a good solution, many will not think of doing it because it's unusual. I also think we should do the better thing by default, to me there just doesn't seem to be enough space in such a small dialog, in your mockup the system folders are collapsed and many importers would only show a few buttons.

I agree the info header does not need to be there and certainly not editable, it should be properly modal.

We could open a file dialog that is almost the size of the window, with some 20 pixels padding on the sides to show the rest of the UI greyed out below it, so we have both a big dialog and show that it is above the rest of the UI. That can be in a separate window or something inside the same Blender window, as long as the rest is greyed out it should be clear.

@Brecht Van Lommel (brecht): Agreed, makes sense, would be a great solution.

@Jonathan Williamson (carter2422):

I didn't propose a difference to the way we display IO options, but we could make them more compact by using tabs, like so:

Created a proposal for improving the current bookmarks panel, allowing you to give each one a name (in the case of multiple folders with the same name) and move them up and down the list: http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI//FileBrowserBookmarks

@William Reynish (billrey) - I am personally not in favor of having tabs by the options. Exporting options are usually done as a separate step in most applications. You pick your file to save as one step, click save/export, file browser disappears, then a modal window shows up up with additional options for exporting format.

@Greg Zaal (gregzaal) - We also need the delete functionality by bookmarks. Is that what the red x is when editing. I am worried this proposal might make managing bookmarks too complex. Is managing bookmarks at this level something that most people need? If it is the minority, I would rather lean towards leaving it simple (unless maybe if there were more advanced context click options which don't exist now).

I modified @William Reynish (billrey) mokup a little with a slightly varied bookmark management. The "X" by the Recent panel will be confusing for Windows users. That communicates "delete this panel" - since X's to the right of a header means close in Windows. Instead of clearing, could we make it consistent with the other bookmark removal and have an "X" by each option?

Deleting isn't a primary action with opening files, so I think making them more subtle would make the UI feel less cluttered. The icons could turn white when they are hovered over.

@Scott Petrovic (scottpetrovic) Agreed. The red 'X' was for deletion, but that whole proposal is really just a big bandage. I'd much rather it be more hidden for advanced folk, such as ctrl+click or double click to rename, and a simple drag+drop to reorder.

@William Reynish (billrey) - good proposal, especially moving the selected file name and Cancel and OPEN to the bottom. And X-es as in the mockup from @Scott Petrovic (scottpetrovic).

@Brecht Van Lommel (brecht) - I know what you mean, browsing through large directories of files is good with a fullscreen dialog. I would still rather have Open file and Save file in a separate window, like user preferences currently. I don't see why resizing a window is unusual, we don't need to assume that computer users don't understand resizing. For serious work it's just one click to maximise it. I resize open file dialogs in Windows regularly, the only problem is if it always reverts to the old small size, so we simply need to always store the last size and position of the window.

Any chance to have a preview area in the file browser?

@Alessio Cappini (lsscpp) - that is a good idea, but that might not fit in with what this thread is about. That feature already kind of exists. If you are opening a file and go into grid view, it will show you a preview as the thumbnail. Is that good enough?

@Brecht Van Lommel (brecht) - Are we close enough with this direction that we can start doing changes? I think the direction we are heading is pretty good. I could try to start doing these code changes. Not sure exactly how to do it, but I can worry about that when I get in the code.

For the full screen vs. modal debate. It sounds like we need a lot of space. If someone clicks the "Open" button, that is what they want to do - so I think it is would be fine for it to take up the whole space to do what needs to be done. Maybe just update the info bar to take away some of the confusion.

Yep thumbnails are better than nothing, but often i feel the lack of a good (big) view of textures (Not to speak about the time needed to see all the thumbnails in a crowded folder.). So I have to reach the folder via system and search the images with an external app (a trivial viewer). Having a view that is fullsize and scrollable would be a gift. A thought this because Blender already has its own viewer

I am going to go MIA on this for a little while. I was starting to spend some time getting this all re-arranged in C (was struggling with externalizing everything Python). There is another open source project I that has my heart right now and need to switch gears to for a little bit (Krita).