Dismiss button for "folder content best viewed in collectives app" header in file list

[nidico]

Browsing a folder which belongs to a collective in the files app shows a message "The content of this folder is best viewed in the Collectives app." on top of the file list.

Allow to dismiss the info header in the file list. It should be a persistent change for the user.

Background

For our use case most content (e.g. the files displayed in that folder) is currently not displayed from within the collectives app.

I assume this message is intended for users that only (automatically) store the collective "wiki style" markdown pages in the folder hierarchy below Collectives/collective_name.

However the automatically created folder Collectives/collective_name can be used for normal "file sharing" within the collective as well - and in that case, above message doesn't make much sense - as here, the content of this folder is not best viewed in the Collectives app, because it doesn't display relevant parts of the folder.

[mgc8]

Indeed, there should be a way to show "files" contents in the menu/links from the left. Right now, the only way to get to these files from within the Collectives UI is by manually linking them inside a Wiki/Markdown page.

[mejo-]

Dear @nidico, thanks for your feedback.

However the automatically created folder Collectives/collective_name can be used for normal "file sharing" within the collective as well.

While this is true, the recommended frontend for Collectives is the Collectives app. We know that novice users get lost by accidently navigating to the Files app when they spot the "Collectives" folder there. That's why we introduced the header for Collectives folders in the Files app.

We're working on proper attachments support in Collectives - though it will only support attachments that got uploaded to the .attachments.<fileId> folder of the corresponding markdown document. That's what is done when uploading files using the "Insert attachment" functionality from the editing toolbar.

See the screenshots and screencasts in #603 to get and idea of our current work.

I'm curious, would this solve the issue for you?

[mgc8]

We're working on proper attachments support in Collectives - though it will only support attachments that got uploaded to the .attachments.<fileId> folder of the corresponding markdown document. That's what is done when uploading files using the "Insert attachment" functionality from the editing toolbar.

See the screenshots and screencasts in #603 to get and idea of our current work.

I'm curious, would this solve the issue for you?

While not the direct reporter you're addressing, I can respond as a fellow user who supports the original issue. For me, this would not be a complete solution.

When working with other people on projects (the very reason for something like Collectives to exist), we often need to share not just "live" text documents but various existing ones as well -- most often images, but also PDFs, videos or whatever other formats exist. For example, on a project I'm collaborating on, we have a folder with 1000 images that need to be shared, updated and discussed. "Attaching" something like that to documents would be terribly inefficient, brittle (updates would have to be manual) and would also mess up people's workflows which rely on sync-ing large folders directly with Nextcloud via the desktop clients.

The thing is, Nextcloud already supports this functionality, and we can use it just fine within the Files app. If the structure behind-the-scenes is already files and folders, why not expose it? All we need is a lightweight modality to include these shared files and folders within Collectives -- either by displaying them directly in the left-column, or by creating a form of "embed folder" widget that can be added to any text page, similar to how we can have embedded images right now. For example, an inspiration could be the "display children" macro from Confluence.

[max-nextcloud]

I think one thing we can do for sure is change the wording. The best in there is making a judgement rather than explaining the situation. For a folder that belongs to 'Our Garden' how about:

This folder belongs to 'Our Garden'. [Open in Collectives]

And for the toplevel folder:

This folder contains the data of your collectives. [Open Collectives]

[nidico]

While I think that the improvements in #603 are nice, I agree with @mgc8 that attachments aren't sufficient and regular file sharing with a default collective folder is an important use case for many collectives which isn't covered with attachments to collective pages.

In my opinion, @max-nextcloud 's wording change is a good and simple solution for this issue.

There could be other improvements in this regard ("improve the usefulness of the default collective file folder"), but outside of the scope of this issue:

• Link to the respective collectives files folder from the collective (simple and useful, would fit well with the link "in the other direction", which we're discussing here)
• Embedding the file view within the collective (harder)
• Move the collective "wiki pages" in a separate subfolder (e.g. pages), so they don't clutter the files view (maybe controversial, but in my opinion useful)

[mgc8]

Agreed with the word change and the other suggestions from @nidico . Is there scope for creating a separate issue (or issues) to cover that, if this one will be closed with just the wording update?

[mejo-]

My feeling is that there's two perspectives on this problem:

1. Users who know about the file structure and want to use it - mostly users who know how to find their way around
2. Users who get lost in the user interface easily and need to be guided.

The header was implemented to make sure that the second group of users find their way from the files view to the Collectives app. That's also why it uses a strong wording. The wording came out of a discussion with our design team, so I'll not change it for now. Let's put @nextcloud/designers into the loop for additional feedback.

Link to the respective collectives files folder from the collective (simple and useful, would fit well with the link "in the other direction", which we're discussing here)

This is already the case. In the three-dot-menu next to the page title you should see a "Show in Files" option.

Embedding the file view within the collective (harder)

Nothing like this is planned for now.

Move the collective "wiki pages" in a separate subfolder (e.g. pages), so they don't clutter the files view (maybe controversial, but in my opinion useful)

Sorry, but this will not happen for now. Collectives is mainly about text documents which certainly can have attachments and related files, but the user interface should always put the pages in front.

[mgc8]

1. Users who know about the file structure and want to use it - mostly users who know how to find their way around
2. Users who get lost in the user interface easily and need to be guided.

The header was implemented to make sure that the second group of users find their way from the files view to the Collectives app. That's also why it uses a strong wording. The wording came out of a discussion with our design team, so I'll not change it for now. Let's put @nextcloud/designers into the loop for additional feedback.

If that is the case, then there should be an option for the users in the first group to turn it off. The implementation is of course up to your design criteria -- an option in User/Settings, a button that says "Don't show this again" on that very page, etc., and perhaps you could consider what happens once the second group becomes "educated" and that message is superfluous, yet still in their face... In every Collectives folder.

Embedding the file view within the collective (harder) Nothing like this is planned for now.

Is there something we can do to increase the visibility/priority of this feature? I find it quite a serious omission from an otherwise well designed tool, which prevents using it with a wider group of people (and actually makes things such as sharing non-page files more confusing for exactly the groups of "lost" users you're trying to help). If you check other similar collaboration tools, you'll find this feature present in one way or another on every one of them.

[nimishavijay]

It was always intended that Collectives would be the place for organised knowledge management, not Files. Which is why all the messaging points to move away from Files and towards Collectives :) And with attachment management, the main concern over here (regarding non-markdown files) will be addressed as well.

Embedding the file view within the collective (harder)

We try to make sure that the designs are usable for most people, who aren't power users. A niche feature such as having a file view in the collective (especially when attachments are shown in the collective as well) would make it confusing for many people. Since there is a quick way to navigate to Files by clicking on the 3dot menu, I would say this is something that may not be prioritised in the near future.

there should be an option for the users in the first group to turn it off

I would agree over here! Although we are trying to navigate people towards Collectives, if someone prefers to use Files there would be a sort of "banner blindness" after seeing this infobox every time. There can be a dismiss button on the right in the infobox and this would stop the infobox from showing next time for that folder. What do you think? :)

[mgc8]

I would agree over here! Although we are trying to navigate people towards Collectives, if someone prefers to use Files there would be a sort of "banner blindness" after seeing this infobox every time. There can be a dismiss button on the right in the infobox and this would stop the infobox from showing next time for that folder. What do you think? :)

Thank you for the added background and information. I can't speak for others, but personally I'd find that a good solution. Of course, if we also get better attachment management in the future for images/PDFs/etc., then all the better!

[mejo-]

We're open to pull requests that allow to dismiss the info header in the file list. It should be a persistent change for the user.