Add more default user locations to Places model/panel
AbandonedPublic

Authored by ngraham on Feb 2 2018, 5:38 AM.

Details

Reviewers
None
Group Reviewers
Frameworks
Dolphin
Summary

FEATURE: 389618

By default, the only user-related item on the Places panel is the user's home folder itself.

This is a little sparse, and lacks typical locations like Desktop, Documents, etc. Most users will not take the time to populate the Places panel with more entries, so it's important to provide a more complete set of defaults. An especially useful one is Downloads, which will be heavily used in the Open panel given how frequently people download things from the internet that wind up there.

I opted not to include ~/movies because my sense is that most average users no longer have local video collections that they keep in their home folders, instead getting all of their videos from the web. ~/music is still there because enough people do still have local music collections.

Test Plan

Tested in KDE Neon.

  • New items do not appear for existing installations; users' pre-existing Places panel entries are untouched
  • New items do appear for a completely fresh install
  • All items function as expected and point to real locations

Here's how it looks now:

Diff Detail

Repository
R241 KIO
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
ngraham created this revision.Feb 2 2018, 5:38 AM
Restricted Application added a project: Frameworks. · View Herald TranscriptFeb 2 2018, 5:38 AM
ngraham requested review of this revision.Feb 2 2018, 5:38 AM
ngraham edited the test plan for this revision. (Show Details)Feb 2 2018, 5:38 AM
ngraham edited the summary of this revision. (Show Details)
rkflx added a subscriber: rkflx.EditedFeb 2 2018, 2:38 PM

-1 from my side because:

  • Dolphin: By default, the sidebar now has an ugly scrollbar. (The screenshot is "staged" in that regard.)
  • Gwenview: This clutters the Places list on the Start Page with a bunch of stuff not relevant for users (e.g. Music). I'm still busy fixing the fallout from the last patch similarly adding unwanted/broken entries, so please help out if you must add this globally. Note this is not only about Gwenview, but a lot of other apps using KFilePlaces are not interested in some of the entries either.
  • In general: Now there's duplication with Search For. For example, what's the difference between "Documents" and "Documents"? (Not everybody is aware of the headers, and rightfully shouldn't!) Same for "Pictures" vs. "Images". Maybe I could live with that if this only appeared if Baloo was turned off.
  • Plugged in an external thumbdrive? Good luck finding it below the fold! (This should be solved first by moving things around a bit.)

I'd rather use KFilePlaces more as a bookmark thingy, i.e. something where users add custom entries they want to see either in all or in specific apps. Those are highly specialized folders in my experience, depending on user's workflows and not something we could predict. Better leave some space so users can customize themselves.

Sorry Nate, I know you meant well. Nevertheless, let's hear first what others have to say, maybe I'm wrong or we could tone down the list a bit…

ngraham added a comment.EditedFeb 2 2018, 2:50 PM

The scrollbar issue is real, though I don't think scrollbars are as awful as you do. :-) Something to think about. I could see removing Music and Pictures, maybe. But Desktop, Documents, and Downloads are heavily used by ordinary regular users and I think it makes sense to provide links to them in the Places panel by default.

This raises a greater question of whether or not it makes sense to have KFilePlaces in Gwenview. Gwenview is an image viewer, and necessarily, the majority of KFilePlaces items are not going to be relevant to pictures. Same for other apps using it. Even without my patch, this issue will occur for users who add their own items to the Places panel.

I feel like the label duplication with the Search For section is a minor issue, and mostly a red herring. The header is right there, so at least in English, the implied imperative sentence is quite obvious: "Search for Documents", "Search for Music," etc. The functions are totally different, and equally important (and if anything, the functionality gained by this patch is more important).

Better leave some space so users can customize themselves.

The thing is, most users won't. That's why good defaults are so important. I think we could pare down the initial list a bit, but we need to offer better defaults than we currently do rather than leaving it up to users to create a DIY solution.

rkflx added a comment.Feb 2 2018, 3:13 PM

The scrollbar issue is real, though I don't think scrollbars are as awful as you do. :-) Something to think about.

Not awful per se, but a huge problem if they hide important stuff below the fold.

This raises a greater question of whether or not it makes sense to have KFilePlaces in Gwenview. Gwenview is an image viewer, and necessarily, the majority of KFilePlaces items are not going to be relevant to pictures.

It's very useful if users can add directories and then have them show up in every app. I'm thinking of things like Projects/2018/BigEvent/Files. Note those aren't filetype or app specific.

I feel like the label duplication with the Search For section is a minor issue, and mostly a red herring. The header is right there, so at least in English, the implied imperative sentence is quite obvious: "Search for Documents", "Search for Music," etc.

We'd need an eyetracking study to resolve that. I suspect your solution would get worse results, because the headers are only looked at second when randomly searching for something (at least in my experience when I evaluated eyetracking videos). Not having duplication would be better.

if anything, the functionality gained by this patch is more important

That's true. I doubt the search is used that often. While for Recently Saved the list of results might be manageable, for Search For the list of results can be too large to be useful.


Suggestion which would resolve most of my issues:

  • Remove "Pictures" and "Music" again.
  • Remove Search for (could be added back once we have collapsible headers).
  • Move up Devices, right below Remote.
spoorun added a subscriber: spoorun.Feb 2 2018, 3:59 PM

I'm afraid that removing pictures would be a bad idea.
The majority of users would find Pictures in particular essential - and lots of software and services automatically store images in the Pictures folder (for example when plugging in an SD card or camera, when downloading from a webservice).
So lay users (the ones who would be least likely to create their own items in the places menu) would miss it most.

-1 from my side because:

  • Dolphin: By default, the sidebar now has an ugly scrollbar. (The screenshot is "staged" in that regard.)
  • Gwenview: This clutters the Places list on the Start Page with a bunch of stuff not relevant for users (e.g. Music). I'm still busy fixing the fallout from the last patch similarly adding unwanted/broken entries, so please help out if you must add this globally. Note this is not only about Gwenview, but a lot of other apps using KFilePlaces are not interested in some of the entries either.
  • In general: Now there's duplication with Search For. For example, what's the difference between "Documents" and "Documents"? (Not everybody is aware of the headers, and rightfully shouldn't!) Same for "Pictures" vs. "Images". Maybe I could live with that if this only appeared if Baloo was turned off.
  • Plugged in an external thumbdrive? Good luck finding it below the fold! (This should be solved first by moving things around a bit.)

    I'd rather use KFilePlaces more as a bookmark thingy, i.e. something where users add custom entries they want to see either in all or in specific apps. Those are highly specialized folders in my experience, depending on user's workflows and not something we could predict. Better leave some space so users can customize themselves.

    Sorry Nate, I know you meant well. Nevertheless, let's hear first what others have to say, maybe I'm wrong or we could tone down the list a bit…

I disagree about the search entries - they are incredibly useful, again for lay users, or just those with not much time, searching for an image, document, or pdf - not knowing which folder they are in - are incredibly common tasks that warrant prime location for all to discover.

markg added a subscriber: markg.Feb 2 2018, 4:04 PM

Ha, funny. I would say +1 :)
Your idea is good and the default user places could imho be more then what is there by default right now.

I personally would only add:

  • Desktop
  • Downloads

Pictures, music and documents are in my case rarely used items. I usually have those stored somewhere else which would make them being there by default (for me) just a waste of screen space. But i can see others that do use that so it might be valuable to them.

You have a +1 and a -1 now. That's going to be interesting ;)

Suggestion which would resolve most of my issues:

  • Remove "Pictures" and "Music" again.

Music, maybe. Pictures no, for the reasons that @spoorun gave. Also, the Pictures item is useful for Gwenview, no? :) Again, we're talking about good defaults for average users, not for people like us (who can and do customize to our heart's content).

  • Remove Search for (could be added back once we have collapsible headers).

We already do have collapsible headers! Well... hide-able headers. I think that we shouldn't hide anything by default until the the UI for showing hidden sections is improved, otherwise our users won't be able to find them and will erroneously complain that we're removing features. My vote is for the macOS Finder approach, where the header is clickable and shows/hides its content, but the header itself sticks around. It's quite slick:

Everybody seemed to like this the last time I brought it up: Let me file a task to track implementing that: https://bugs.kde.org/show_bug.cgi?id=389803

I think this section could definitely be hidden by default once we improve the show/hide UI. My sense is that it's infrequently used, and you can easily get it via the Find toolbar item. Might not be worth the pixels it's occupying by default.

  • Move up Devices, right below Remote.

+1, sounds good.

I suspect that hiding the Search For category by default and moving up the Devices category would resolve the complaints.

rkflx added a comment.EditedFeb 2 2018, 5:52 PM

I could see removing Music and Pictures, maybe.

  • Remove "Pictures" and "Music" again.

Music, maybe. Pictures no

You propose a compromise, I agree and suddenly the situation is different again? Let's not rush this, please.

Also, the Pictures item is useful for Gwenview, no? :)

It is, but it could be added in Gwenview, just like Kdenlive could add Movies or JuK could add Music. We don't need Pictures in KDevelop, though! When fixing the fallout from D8332 I discovered what you are changing here will propagate to every app using KUrlNavigator, which is quite common. (Meanwhile I gave up on adding fixes like 50e6fa3ffc49 everywhere, because I realized this has to be solved at Baloo level.)

Next big caveat: Our file dialog is used in Okular, Kate and every well-integrated Qt app, where some of the additions make no sense at all. Do you want a Music folder in your EDA and CAD app?

I completely agree it is useful in Dolphin. However, then it should be added in Dolphin.

TL;DR:

  • Places and searches useful everywhere should go to KIO.
  • Specialized stuff (i.e. "Does it only return one specific filetype?") should be added in the app or at least be opt-in. Perhaps we need KExtraFilePlaces or some mimetype dependent automagic?

https://bugs.kde.org/show_bug.cgi?id=389803

That's what I meant. Collapsible headers (i.e. one click, discoverable how to do that only by looking at it) are great. Our current hide-able headers are more of a configuration thing, you wouldn't want to use them regularly.

Keeping Pictures but removing Music would seem to be a compromise, no? But since this has proved controversial, it's obviously not going in anytime soon, so no need to worry about that.

Since the places model is now in KIO, once a user adds a location in Dolphin, it automatically shows up in all apps now, right? Or am I wrong and there is a way to make things appear only in Dolphin and the file open/save dialogs, but not other apps' own uses of KFilePlaces? If so, that would seem to be an obvious intermediate solution and I'll focus on that.

rkflx added a comment.Feb 2 2018, 6:17 PM

Keeping Pictures but removing Music would seem to be a compromise, no? But since this has proved controversial, it's obviously not going in anytime soon, so no need to worry about that.

Well, Documents and Downloads would be useful (perhaps Desktop if we really want to promote that, personally I'd leave it out).

If you want to do it right, your patch (or multiple patches) could:

  • add common stuff to KIO (Documents, Downloads)
  • add special stuff to Dolphin (Search For, Pictures, Music etc.)
  • remove special stuff from KIO (e.g. Search For)
  • change the order

Since the places model is now in KIO, once a user adds a location in Dolphin, it automatically shows up in all apps now, right? Or am I wrong and there is a way to make things appear only in Dolphin and the file open/save dialogs, but not other apps' own uses of KFilePlaces? If so, that would seem to be an obvious intermediate solution and I'll focus on that.

Well, if the user checks Only show when using this application (Dolphin) while adding an item, it should (unless there's a bug) only appear in Dolphin, otherwise it will be available everywhere. Both are valid use cases.

rkflx added a comment.Feb 2 2018, 6:25 PM

file open/save dialogs

I'd assume the use case of those is quite broad, so those should be opt-in. However, I'm not sure whether an app can change it's file dialog's places model? That may be a deficiency, but then the deficiency should be solved instead of being worked around by a global addition.

Keeping Pictures but removing Music would seem to be a compromise, no? But since this has proved controversial, it's obviously not going in anytime soon, so no need to worry about that.

Well, Documents and Downloads would be useful (perhaps Desktop if we really want to promote that, personally I'd leave it out).

If you want to do it right, your patch (or multiple patches) could:

  • add common stuff to KIO (Documents, Downloads)
  • add special stuff to Dolphin (Search For, Pictures, Music etc.)
  • remove special stuff from KIO (e.g. Search For)
  • change the order

Since the places model is now in KIO, once a user adds a location in Dolphin, it automatically shows up in all apps now, right? Or am I wrong and there is a way to make things appear only in Dolphin and the file open/save dialogs, but not other apps' own uses of KFilePlaces? If so, that would seem to be an obvious intermediate solution and I'll focus on that.

Well, if the user checks Only show when using this application (Dolphin) while adding an item, it should (unless there's a bug) only appear in Dolphin, otherwise it will be available everywhere. Both are valid use cases.

I don't think almost any users use or know about that because the two most obvious methods of adding something to the Places panel--drag-and-drop and the file's "Add to places" context menu item--make it global by default. Also if we add Music and Pictures et al to just Dolphin by default, then they're not going to show up in the file open/save dialogs where they're useful, right?

rkflx added a comment.Feb 2 2018, 6:38 PM

I don't think almost any users use or know about that because the two most obvious methods of adding something to the Places panel--drag-and-drop and the file's "Add to places" context menu item--make it global by default.

Users adding custom entries has nothing to do with your patch. If a users adds a place and it appears everywhere, well that's his problem. Your patch adds it everywhere for every user, which is what I disagree with.

Also if we add Music and Pictures et al to just Dolphin by default, then they're not going to show up in the file open/save dialogs where they're useful, right?

See comment above. I doubt Kate's users want to see Pictures. I agree that some apps would want to opt-in, not sure how to do that. I think the best thing would be to make this mimetype dependent: If the file dialog detects you want to open/save Music files, it should add "Music" to the standard model. That would be an addition to the file dialog though, not where you are currently changing it. Do we have a resident file dialog expert around we could ask about that?

rkflx added a comment.Feb 2 2018, 6:46 PM

Also, I feel a bit sorry for you. If I had realized the problem when Search For was added I would've added the same comment. I'd be glad if we could fix that again and remove the mimetype dependent items from the standard places model (or make it more intelligent about what to show).

spoorun added a comment.EditedFeb 3 2018, 3:20 AM

I don't think almost any users use or know about that because the two most obvious methods of adding something to the Places panel--drag-and-drop and the file's "Add to places" context menu item--make it global by default.

Users adding custom entries has nothing to do with your patch. If a users adds a place and it appears everywhere, well that's his problem. Your patch adds it everywhere for every user, which is what I disagree with.

It's easy for power users to 'hide' places they don't want in the panel.
It's much easier than for the majority of users, lay users, who can neither add nor remove panel items, and want to see their pictures, their documents, and their downloads.
They also want to find their images and pdfs using search, the current interface makes that easy for them, for the majority workflow, who may not find things at easily otherwise.
Most PC users, including many Linux users, don't even know where they store pictures or documents, they just expect them to appear, and if the UI (in this case Dolphin and the file-picker) doesn't do that anymore they're lost.
For those who need more or less items in the panel, the minority, they're far more likely to be ones who can add or remove it themselves as required.

Also if we add Music and Pictures et al to just Dolphin by default, then they're not going to show up in the file open/save dialogs where they're useful, right?

See comment above. I doubt Kate's users want to see Pictures. I agree that some apps would want to opt-in, not sure how to do that. I think the best thing would be to make this mimetype dependent: If the file dialog detects you want to open/save Music files, it should add "Music" to the standard model. That would be an addition to the file dialog though, not where you are currently changing it. Do we have a resident file dialog expert around we could ask about that?

It should be fine for Pictures to show up in Kate's dialogue.
It's easy to overlook a very important usability issue: users prefer - our brains prefer - consistency in presentation. It makes it easier to find things.
If the panel changes each time we open it (depending upon context) it both feels less comfortable, less familiar, and makes it harder for our eyes to jump to what we want (whether through Kate, or uploading via browser, or trying to open a pdf).
So (unintuitively) removing Pictures in Kate can slow the workflow rather than improve it.

+1 very positive! There should be as many default places as possible, scrollbars are not awful; at least Desktop, Documents, Downloads, Pictures, Music fit perfectly fine. User can easily remove unneeded entries (it's easier to remove than to add I think)
And collapsible headers would be very cool.

rkflx added a comment.EditedFeb 3 2018, 1:29 PM

@spoorun You make it sound like the sidebar is the only way to access those folders. That's not true: The file dialog opens in "Home" by default, where you can directly click on Pictures and the other folders anyway.

Regarding not adapting the file dialog to mimetypes: That's not how it works in most apps if you look at the file picker part: It only shows those files which are supported by the app, e.g. in VLC no odt Documents are shown at all. If we'd follow your reasoning we should change VLC to show every filetype, so users have a hard time finding things and get an error if they made a mistake instead of preventing those in the first place.

Finally, a screenshot:

I don't see any header there, so the duplicated entries are plainly confusing. Also, the list is way too long now (maximum recommended number of items in lists is 4-5), even though it's a minimal install. On regular hardware with more devices attached it would be even longer! @alexeymin IMO we are already way beyond any reasonable limit for "as many items as possible".


BTW, I'm genuinely interested in improving this topic for our users.

It would be great if everyone could ask their friends and family if they are using Search For in the Open dialog, and how many results are displayed for them to sift through (as there is no secondary search filter in that case). Also I'd be interested if they expect Search For in the Save dialog. Also: Usage of Dolphin vs. usage of Open to open files.

Finally, a screenshot:

The KUrlNavigatorPlacesSelector menu is about to get a welcome change in D10329 that addresses this concern.

BTW, I'm genuinely interested in improving this topic for our users.

It would be great if everyone could ask their friends and family if they are using Search For in the Open dialog, and how many results are displayed for them to sift through (as there is no secondary search filter in that case). Also I'd be interested if they expect Search For in the Save dialog. Also: Usage of Dolphin vs. usage of Open to open files.

I conducted the requested survey over the weekend while at a huge Super Bowl party. Plenty of "regular" users! Some of them use macOS instead of KDE Plasma (I'm working on 'em!), but thankfully the file managers and Open dialogs have identical features, so I think it's still valid data:

Survey data

Person 1 - moderate computer skills, college professor (humanities)

  • Occasionally uses Search For from the Open dialog; never uses it in the file manager. Hundreds of results.
  • 50/50 split between using file manager and Open dialog to open files
  • Heavy user of Places panel bookmarks in both file manager and Open dialog; has more than 20 and knows how to create, manipulate, and remove them

Person 2 - low computer skills, writer

  • Never uses Search For from the Open dialog or file manager. Thousands of results
  • Exclusively uses apps' Open dialog to open files
  • Uses Desktop and Downloads Places panel bookmarks from Open dialog

Person 3 - moderate computer skills, artist

  • Never uses Search For from the Open dialog or file manager. Thousands of results
  • 75/25 split between using file manager and Open dialog to open files
  • Uses Desktop, Documents, Pictures, and Downloads Places panel bookmarks in both file manager and Open dialog

Person 4 - low computer skills, public relations

  • Never uses Search For from the Open dialog or file manager. Hundreds of results
  • Exclusively uses apps' Open dialog to open files
  • Uses Desktop, Downloads and Pictures Places panel bookmarks from Open dialog

Person 5 - moderate computer skills, construction worker

  • Never uses Search For from the Open dialog or file manager. Thousands of results
  • 75/25 split between using file manager and Open dialog to open files
  • Uses Places panel bookmarks (Desktop, Documents, Pictures, etc.)

Person 6 - good computer skills, artist

  • Occasionally uses Search For from the Open dialog and the file manager. Thousands of results.
  • 50/50 split between using file manager and Open dialog to open files
  • Heavy user of Places panel bookmarks; has more than 10 and knows how to create, manipulate, and remove them

Person 7 - very low computer skills, minister

  • Never uses Search For from the Open dialog or file manager. 2-3 dozen results.
  • Exclusively uses apps' Open dialog to open files
  • Never uses Places panel bookmarks; saves everything in Documents folder, and Open dialogs all open right there

Survey conclusions

  • Everybody uses the Desktop for short or long-term file management; access to the Desktop from the Places Panel is extremely important
  • For many, the Open dialog is the primary file access tool
  • Almost everybody uses Places panel bookmarks from the Open dialog
  • Many/most use Places panel bookmarks from the file manager--some very heavily
  • Almost nobody uses Search For from the file manager

It's worth mentioning what macOS does here that differs from our current approach:

  • The macOS Places panel equivalent ships by default with bookmarks to ~/Desktop, ~/Documents and ~/Downloads (but not Music, Pictures, or Movies)
  • The macOS screenshot tool deposits images on the desktop, not in the ~/Pictures folder
  • The macOS Search For section can search for music, pictures, and movies, but not documents
  • The macOS Search For section is only present in Open dialog (at the very bottom of their Places panel equivalent), but not present in the Save panel or Finder file manager. The macOS Search For section also has all entries no matter what app you invoke it from; e.g. from a text editor, you're still able to Search For music and pictures.

I therefore must stand by my position that more Places panel bookmarks are needed, and that they should appear in all apps. This is especially important for ~/Desktop. Less so for ~/Pictures, which I could be convinced out of. I think we could make Search For a hidden category in Dolphin (once the UI is better) and remove it entirely from the Save dialog.

rkflx added a comment.Feb 5 2018, 9:16 PM

Thanks so much Nate, that's impressive and I feel we can make real progress this way. You are probably not far off from the conclusions I came to above. Smells like a new task on a workboard is in order ;) I'll try to digest what you wrote later in more detail…

zzag added a subscriber: zzag.Feb 6 2018, 1:28 AM

I think we could make Search For a hidden category in Dolphin (once the UI is better) and remove it entirely from the Save dialog.

Do we really need Serach for? It looks like a dirty hack. Maybe, the find util(or whatever) should have checkboxes like Pictures, Music, etc?

In D10245#201731, @zzag wrote:

I think we could make Search For a hidden category in Dolphin (once the UI is better) and remove it entirely from the Save dialog.

Do we really need Serach for? It looks like a dirty hack. Maybe, the find util(or whatever) should have checkboxes like Pictures, Music, etc?

In fact, we already do, right there in Dolphin's Find panel:

I made a workboard Task to advance the discussion and figure out our next steps: T8349: Improve Places panel usability and presentation

ngraham abandoned this revision.Apr 3 2018, 4:21 PM

Abandoning in favor of D11768