Projects rework to automatic "Related resources"

[jancborchardt]

It is proven by now that people don’t do the manual picking and connecting of projects. Nextcloud should be intelligent enough to show related folders, Deck cards, events, conversations, etc. automatically.

The idea is to show folders, Deck cards, calendar events, conversations, etc. which are shared with the same group or circle. This should give useful links to other resources in 90% of the cases without manual interaction.

Proposal

• The manual "Projects" entry is expanded into a "Related resources" (wording not set, but nicely alliterated) section below the share list.
  • Alternatively, and if we actually introduce a "Details" tab at some point, we could also think about moving this "Related resources" section over there. This might be needed cause the sharing list can grow quite long.
• There is an explanatory subline "Anything shared with the same group of people will show up here."
• Below is a list of the related resources. They have sublines with relevant info like last message for Talk conversation, column and board for Deck cards, or dates for Calendar events.
• If any of the entries is clicked:
  • First step: Just like for Dashboard, you get redirected to that relevant item, opening it in a new tab.
  • Ideal future (also just like ideally for Dashboard): A simple modal opens with further detail on that element only, making for much smoother UX than a redirect and full loading of an entire page.

Questions / beyond minimum viable product

• How would it show up in other apps:
  • In Talk it would have to show up in the "Details" tab
  • In Calendar in either "Details" or a new tab
• Can people dismiss entries which are not fitting? (Probably not in the first version)
• How can someone see all the resources of a "Project", if that even exists?
  • Initially, any of the sidebar entries will do, as all of them should show the same.
  • Additionally, we could show the entries in Contacts/Circles in the relevant section. (Not really possible for groups)

cc @nimisha-vijay @AndyScherzinger @skjnldsv as discussed. :)

[skjnldsv]

Relevant: https://github.com/nextcloud/server/issues/21359 What shall we do?

Alternatively, and if we actually introduce a "Details" tab at some point, we could also think about moving this "Related resources" section over there. This might be needed cause the sharing list can grow quite long.

Could we do that straight away? Add a new tab for this?

[tobiasKaminsky]

Once anyone starts with this, please make sure to check back with me to coordinate proper API for clients.

[marcelklehr]

I like the proposal. It would be great if apps could add and link custom items, too.

[jancborchardt]

Could we do that straight away? Add a new tab for this?

I’d definitely not add yet another tab to the already existing 5 before we consolidate some of them, as specced in https://github.com/nextcloud/server/issues/658 So for now I’d advise to put this in Sharing, below the sharee list, as in the mockup.

[jancborchardt]

Relevant: #21359 What shall we do?

Sorry @skjnldsv, now also answering to that part: We specifically decided we want to keep this as simple as possible since the manual connecting work is just tedium. So we’d go with the approach specified in this issue rather than #21359

[PVince81]

@jancborchardt I assume that this only applies to the currently selected folder, not any parent folder shares. The latter would be much more expensive to implement as it would need to do the same "find" operation for every parent.

If only on the selected folder, I do wonder how often people will open the share / sidebar of an already shared folder, unless they already are interested in related resources and know to find them there. Otherwise, the discoverability is likely very low. Thoughts ?

[PVince81]

• [ ] define/clarify "same group of people". I assume "not strictly" the same group of people. so if the folder is shared with Alice and Bob, any resource shared with Alice individually and Bob individually will also appear there. Not only resources shared with both Alice and Bob only

[PVince81]

... or don't call it "group" in the wording because it might be mistaken with "Nextcloud group" while we mean "a set of individual persons"

[PVince81]

• [ ] should this also include other folders and not only calendars, chats ?

if not, would the folders only appear when jumping to the related calendar, chats ?

imagine the following scenario:

• folder "Project A" shared with Alice and Bob
• folder "Project B" shared with Alice and Bob
• talk room "Discussion Project A" with Alice, Bob as participants
• talk room "Discussion Project B" with Alice, Bob as participants

If I open the sidebar for Project A, I'd see in "Related resources":

• "Discussion Project A"
• "Discussion Project B"
• if we allow folders as well, we'd see "Project B" as well

if I open the sidebar of "Discussion project A", , I'd see in "Related resources"

• "Project A"
• "Project B"
• if we allow same type resources, we'd see "Discussion project B" as well

I guess that answers the question: we need to include same type for it to make sense

[PVince81]

• [ ] assuming that only future calendar events are shown, or should old events be shown as well ?

[PVince81]

• [ ] idea: also show possibly related resources by partial name match ?

in some cases you might have multiple folders for the same project but in different subdirectories, for example customer names appearing in "sales" and also "engineering". when opening the sidebar of folder "sales/$customerName" you might also want to get a link to "engineering/$customerName" considering that it's the same or almost same name and they are likely linked

in some setups those two subdirs might not be shared to the same set of people, especially in organizations that have the parent folder shared with everyone (also see parent folder topic) so according to the current share-based idea they would not appear linked

however note that partial text match is likely very slow performance-wise

[jancborchardt]

@jancborchardt I assume that this only applies to the currently selected folder, not any parent folder shares. The latter would be much more expensive to implement as it would need to do the same "find" operation for every parent.

Yes, definitely in the first version anyway. We can always see if we improve it somehow later on.

If only on the selected folder, I do wonder how often people will open the share / sidebar of an already shared folder, unless they already are interested in related resources and know to find them there. Otherwise, the discoverability is likely very low. Thoughts?

Yeah, it’s a bonus thing on top anyway, a bit of "intelligence". So nothing which needs to be super present, the sharing tab is fitting.

define/clarify "same group of people". I assume "not strictly" the same group of people. so if the folder is shared with Alice and Bob, any resource shared with Alice individually and Bob individually will also appear there. Not only resources shared with both Alice and Bob only

Yes – so of course resources shared with both will be prioritized, but if there are none of those, resources shared with Alice individually or Bob individually would come in.

should this also include other folders and not only calendars, chats ?

Yes, good point. :) That’s not communicated in the mockup but you are right.

assuming that only future calendar events are shown, or should old events be shown as well ?

Only future events, yep.

idea: also show possibly related resources by partial name match ?

Nice idea! We can try how well that works and that can be one aspect to fill in the "Related resources" list.

Important is also that the list should probably not be endless but have e.g. max 7 entries.

[PVince81]

• [ ] add config switch to disable the feature

[PVince81]

=> regarding partial match, there would be too many false positives. Ex: a folder "July" might show all July's from other years

let's leave it out for now

[ArtificialOwl]

=> regarding partial match, there would be too many false positives. Ex: a folder "July" might show all July's from other years

let's leave it out for now

Not if you can know the number of times the resource have been accessed in the last n weeks

[jancborchardt]

So @stefan-niedermann asked what about an API to get this data in other apps, like Deck, or Deck mobile even. Is there something documented already @ArtificialOwl @PVince81?

[AndyScherzinger]

Afaik @Pytal will support adding this to the other webUI parts where projects has been visible. As for an external API this hasn't been discussed or raised yet - so I guess currently not accessible to mobile apps, bit @ArtificialOwl might know best.

[tobiasKaminsky]

If we want to have this also for mobile, then please count me in, so that we can create a proper API, similar how we are doing currently with dashboard api. (this then needs to be planned for mobile clients)

My question is now, if we first shall wait for user feedback if this is liked/used at all, and then implement it on clients or if we wanna start with it nevertheless.

[AndyScherzinger]

I think we can wait since the predecessor "projects" is also not available on mobile. What do you think @jancborchardt @karlitschek

[stefan-niedermann]

the predecessor "projects" is also not available on mobile.

This is not the full truth - the Deck Android app implemented projects as good as possible with a not documented API. Given there are multiple issues in the issue tracker to extend the support of projects (as well as on the Deck server apps repo btw), I think it is save to assume that people are interested in this kind of features, also on mobile. Of course I can only talk for a few 3rd party apps and not the official ones 😉

[AndyScherzinger]

Valid point @stefan-niedermann - currently can't tell if still could be pulled of for initial v25 launch

[Shen]

It is proven by now that people don’t do the manual picking and connecting of projects.

The main reason that people don't do much with projects is the bad implementation.

Here and in many other issue-threads are good suggestions to make it useable. https://github.com/nextcloud/server/issues/15841

I think an intelligent suggestion-feature can help creating your own individual projects like a team in MS-Teams with circles, chats, files, deck,...

[extralooping]

The main reason that people don't do much with projects is the bad implementation.

I very much second that! We were hoping to get at some point a usable projects functionality for grouping decks, files, etc. (as discussed in various issues, see ie. #22897).

No automatic suggestion will be able to achieve this conscious grouping (but might help, as sugegsted above).

[Shen]

I very much second that! We were hoping to get at some point a usable projects functionality for grouping decks, files, etc. (as discussed in various issues, see ie. #22897).

It seems to be too late. The decision is incomprehensible and unfortunately goes in the wrong direction. Too bad, Nextcloud. Projects had so much potential. 🤷🏼‍♂️

[nicovd737]

Hey guys, There is no words to describe our surprise about that. How can you take decision like that ? We lost all benefits of deck ... Really disappointed

[earendil1]

@jancborchardt

The projects rework to automatic "Related resources" would work out if one had the possibility to both have automatic suggested resources and humanly selected resources.

The automatic implementation does not rule out that many issues need to be handled consciously by a user. What would be missing if you go in that direction is a conscious bridge between elements (files, conversations) sharing a common feature and Deck cards for ex. I do not think that this need should be overlooked.

Maybe the most efficient way to do that are tags, since created projects up to now cannot be managed well.

Improving the communication between tags (which already work for groups of files), other files and Deck cards as well as Conversations would go in the right direction for most user cases.

Example: imagine that from the Files app one could select a group of files – manually or with tags – to associate to a conversation or to a Deck card: and then give it a name. Inversely from the Deck card one could attach group of elements/projects based on tags or on project names.

cc @nimisha-vijay @AndyScherzinger @skjnldsv

+1

[sunjam]

Maybe the most efficient way to do that are tags, since created projects up to now cannot be managed well.

Please see these forum threads for additional context.

• Tags discussion support sytem wide tagging across all official nextcloud apps
• Lets Talk about Projects
• Wiki Ways to integrate led to a design call in regards to using linkable objects as reference in a nextcloud server.

Please do reference or continue these discussions however you see fit!

[hilburger]

Please don't get me wrong, I really appreciate the devs work :)

I think everybody understands that features change over time or are dropped. But I think that users and companies who work with NC in a serious day-in-day-out manner should be taken into account more prciously.

So such big features that shall be dropped should get an alternative and ways to migrate before the old are dropped. Otherwise people will switch to alternatives with reliable and steady development paths.

[SamuXzX]

Maybe the most efficient way to do that are tags, since created projects up to now cannot be managed well.

The link @sunjam posted seems to me the most relevant: Tags discussion support sytem wide tagging across all official nextcloud apps.

I've always rooted for system wide tags. But the tags have a bad implementation too: the feature is hidden and it lacks a proper managing page (the existing one isn't a dashboard for tags, I didn't have time to link the relevant threads). In addition, some apps don't actually work with tags: see Notes, which uses folders to organize notes, or Deck, which primarily uses boards and columns; but this could be the reason to actually intend tags as system wide categories instead of simply app-specific taxonomies without messing with the way they internally organize content, so if they are implemented in every app this should work well.

Projects were uncomfortable and "Related resources" could be useful in some way but they are not so flexible, so something should come up, be it tags or manual picking for related resources. And please: we need a dashboard for Project or groups of "Related resources", otherwise everything will be too much fragmented.

[ahcheing]

It is proven by now that people don’t do the manual picking and connecting of projects.

I'm really curious how this factual conclusion was reached. Because its simply not true. as other commenters have noted, at least some people, myself included, used the feature a lot. In my case its such a key part of my workflow I actually reverted back to older nextcloud version, since projects was the only way of directly linking disperate resources together in nextcloud.

The language of this statement implies there is some data from whence this false conclusion is being drawn, and I would like to know how you are gathering this data so that I can add to so that I can add my voice to prevent nextcloud from removing features in the future.

[PVince81]

if you're still using the old projects feature, you can reenable it with this config switch: https://github.com/nextcloud/server/pull/33569/files#diff-3bbe91e1f85eec5dbd0031642dfb0ad6749b550fc3b94af7aa68a98210b78738R2229

the removal/deprecation was based on the assumption that the feature was broken / not fully working

[ohthehugemanatee]

Add my voice to the chorus in favor of de-deprecating Projects. "Content shared with the same people" is not a reasonable replacement for "Content semantically linked by real-world context." This replacement is a net loss for users.

If it's true that "people don't do the manual picking", there's still no logical connection to "we should scrap the entire projects concept and add an unrelated new feature for 'things shared with the same people.'" Where was the discussion of "we should improve Ux to make content picking easier", or "we should improve Ux to make project picking easier," or even "we should add the unrelated new feature beside projects and see how people use them"? (I kid; the discussion was in other Issues which were summarily closed by this one)

At work, typically consistent groups of employees - OUs - work on several concurrent projects over the course of a year. "Also shared with the same people" is a regression for this use case - it will just show them all the files that their team works on, with no semantic subdivision at all.

Home installations have at most a handful of users. Everything is shared with everyone. Compared to semantic projects, "Also shared with the same people" is a regression for this use case, too.

What is the intended use case for "also shared with the same people?" What's the target audience, and how does it help them?

What is the path forward to restoring the manual semantic grouping capability to users? Is it building on Tags? Merging Projects capabilities still in the codebase with this "Also shared with the same people" feature? Starting Projects fresh with its' own UI? Or something else?

[SamuXzX]

Add my voice to the chorus in favor of de-deprecating Projects. "Content shared with the same people" is not a reasonable replacement for "Content semantically linked by real-world context." This replacement is a net loss for users.

If it's true that "people don't do the manual picking", there's still no logical connection to "we should scrap the entire projects concept and add an unrelated new feature for 'things shared with the same people.'" Where was the discussion of "we should improve Ux to make content picking easier", or "we should improve Ux to make project picking easier," or even "we should add the unrelated new feature beside projects and see how people use them"? (I kid; the discussion was in other Issues which were summarily closed by this one)

At work, typically consistent groups of employees - OUs - work on several concurrent projects over the course of a year. "Also shared with the same people" is a regression for this use case - it will just show them all the files that their team works on, with no semantic subdivision at all.

Home installations have at most a handful of users. Everything is shared with everyone. Compared to semantic projects, "Also shared with the same people" is a regression for this use case, too.

What is the intended use case for "also shared with the same people?" What's the target audience, and how does it help them?

What is the path forward to restoring the manual semantic grouping capability to users? Is it building on Tags? Merging Projects capabilities still in the codebase with this "Also shared with the same people" feature? Starting Projects fresh with its' own UI? Or something else?

Wonderful summary, I hope the we can agree the solution will be building on Tags, but for now the fact is that this decision totally needs a rethinking.

[ahcheing]

the removal/deprecation was based on the assumption that the feature was broken / not fully working

I see, that makes more sense then what I assumed, which was a user survay or analitics of some sort, but it makes from devs perspective that users would not use a buggy feature. and yeah it is pretty buggy, but it works often enough to be very useful, at least for me. especially with the android deck app.

if you're still using the old projects feature, you can reenable it with this config switch: https://github.com/nextcloud/server/pull/33569/files#diff-3bbe91e1f85eec5dbd0031642dfb0ad6749b550fc3b94af7aa68a98210b78738R2229

I just tested it and it seems to be working even a newer version of nextcloud. Awesome!

IDK what the best way is going forward for linking disparate files / cards / objects together, (tags? related resources? shrug). but I am extremely grateful the decision was made to allow users to re-enable the feature. If yall where google the feature would just have been gone with no options. I really appreciate how you keep rolling out new features and also doing a good job of giving users enough flexibility and stability to tweak the system.

[reos-rcrozier]

This is wierd, I was waiting for projects to get useful by adding some kind of standalone page where you could actually view what was in a project, the lack of which is the actual reason they aren't used, not the manual picking. Instead you're getting rid of a feature which actually had a lot of promise? I doubt very much some kind of auto selection of stuff that's shared will be useful at all.