D12333: Put the open/save dialog's toolbar above all other widgets, like Dolphin does

[Andres Betts]

abetts added a comment.


  +1
  
  In D12333#250266 <https://phabricator.kde.org/D12333#250266>, @rkflx wrote:
  
  > In D12333#250194 <https://phabricator.kde.org/D12333#250194>, @abetts wrote:
  >
  > > I gave a +1 to the original idea because I feel that there isn't really much closeness that you can achieve with the open dialog. It is simple, straightforward.
  >
  >
  > I find the pre-patch design also very streamlined.
  >
  > > If we wanted to do a strict fitt's law follow, then each back and forth icon would be next to each of the folders and not in a toolbar.
  >
  > Let's not throw the baby out with the bath water. Having the navigation buttons right above the breadcrumb bar is still better the having them crammed in the top left corner.
  >
  > > But we also have to see that there is stronger merit in organizing and looking for symmetry. Symmetry will sometimes help a user more than Fitt's guidelines.
  >
  > This statement may be true in general, but does not fit in our case, as I don't see much symmetry here, TBH. Panel and item view occupy most of the height, and thus are the most important elements. They are split asymmetrical in the horizontal direction, and rightly so. Adding a centered toolbar goes against this and breaks up the split, adding even more asymmetry.
  >
  > Furthermore, users are able to hide the places panel. With the current design the spatial relation between buttons and item view stays constant, while with a centered approach it will jump around.
  >
  > > get user feedback.
  >
  > The file dialog is an important piece of the entire UI. We cannot endlessly change things back and forth, we have to get it right by logical thinking the first time (in this case it would even be the third time!). In KDE3 it was centered, based on feedback from a usability expert it was changed to the current design. In terms of //user// feedback, I'm not aware of any huge issue users have with it right now.
  >
  > Do you want to change things around again until there //actually// is negative feedback? I'd agree with basing design decisions on user feedback if we had better telemetry or did some eye tracking studies, but our current method of hearing user's opinions over on Reddit and Bugzilla is not very effective in painting a broad picture, IMO.
  >
  >  ---
  >
  > Anyway, I'll come back to this Diff once the Sort button is in and we decided on a final default dialog size. This should make the decision easier, because after all the main motivation was to create space for more buttons.
  
  
  I think you are swimming against a non existent wave with your argument. I believe also that we are turning this discussion into a right/wrong argument. I don't think that there is a right/wrong approach in this case. If we want to hold on to ideas developed or talked about in KDE 3, then we are already setting ourselves back a few years. Design evolves. I can understand the desire to adhere to "laws" or guidelines, they provide consistency, ideas that we follow and easy answers. However, the VDG has not really come out in support of this or that "law". We believe that flexibility allows us to grow and evolve. Guidelines can be good reference points though.
  
  The proposed alignment has a few advantages, mentioned above. It is also a model that Windows and MacOS currently use and have used. I feel that if others can pull it off, we can too. This is not about "let's do it the Windows or Mac way" but rather it shows an example that while we seem to have a problem with it, other, more major and widespread systems, don't have a problem with it at all. Plus, it really seems overkill, design wise, to have 2 sets of controls that allow you to go back and forth between directories, and they are together in one horizontal plane. The first one, would be to the right of the breadcrumb navigation and the second would be the breadcrumb itself. Two sets of controls that do the same next to each other.
  
  Something that can help is to set the steps a user will take to get to the action of opening a file:
  
  1. User clicks open
  2. User looks for file
  3. User navigates to desired folder
    1. Breadcrumb grows as folders are clicked
  4. User double-clicks through folders
  5. User goes back to previews folder (Because he can't find the file to open)
  6. User clicks breadcrumb, user clicks arrows, user hits backspace
  7. User finds file
  8. User double clicks file to open
    1. User could also select by clicking once, then click [Open]
    2. User could also click to select and hit [ENTER]
  
  Alternatively
  
  1. User clicks sidebar to find file
  2. User double clicks file
  
  In these two interaction cases, I am not seeing the need to have 2 sets of navigation buttons together.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D12333

To: ngraham, #frameworks, #dolphin, #vdg
Cc: abetts, jtamate, broulik, anemeth, rkflx, michaelh, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20180420/bd892752/attachment.htm>