Sharing user consolidation

[juliusknorr]

• Share list design improvements
  • Highlight matched strings
  • Merge contacts with the same uuid and group them in the ui
  • Increase the max-width of the suggestion box
  • Add icons for easier recognition of the share type
• Share search improvements
  • Remove federated sharing address books which are the same as local ones
  • Filter out local users from address book remote searches
  • Filter out generic remote result for local users
  • Add uuid to results to allow proper grouping and avatar placeholder generation
  • Add type of property to the ContactsManager search result (e.g. HOME/WORK for EMAIL)

Before (with increased height for better visibility):

After:

cc @nextcloud/designers for early feedback 😉

[jancborchardt]

So in the screenshot, the "Contacts example 2" is a person you can share federated or via 2 emails with, right?

For real consolidation, we should completely collapse it into one entry/row. We only need to show the preferred share method, which in this case is federated sharing.

And the priority is: same Nextcloud > federated cloud ID > email.

[juliusknorr]

So in the screenshot, the "Contacts example 2" is a person you can share federated or via 2 emails with, right?

Yes, "Contacts example 2" is an entry in the address book that has 2 email addresses and a federated sharing id.

For real consolidation, we should completely collapse it into one entry/row. We only need to show the preferred share method, which in this case is federated sharing.

What about a contact, that has a personal cloud id and a personal and work email address. You would not be able to share it to the work related email then?

[skjnldsv]

Looks amazing! :)
Just a very small nitpick ;)

[skjnldsv]

Please use a half one to ensure the user know the list is not over :)

[skjnldsv]

For real consolidation, we should completely collapse it into one entry/row. We only need to show the preferred share method, which in this case is federated sharing.

Keep in mind that dropdown should be the simplest UX process. One click searching, one click selecting. If after selecting a contact you need to after click another stuff to specify email or federated, this is a bad behaviour I think 🤔
Not sure if that was what you were suggestion, but adding my comment just in case 😉. If I misunderstood, please ignore :)

[juliusknorr]

Keep in mind that dropdown should be the simplest UX process. One click searching, one click selecting. If after selecting a contact you need to after click another stuff to specify email or federated, this is a bad behaviour I think thinking
Not sure if that was what you were suggestion, but adding my comment just in case wink. If I misunderstood, please ignore :)

From my understanding it was about not showing any other sharing methods of a user at all. But I'm a bit worried about the missing options to share to some other contact point as already said above.

@jancborchardt Also how would we decide which contact information is the relevant one if the user has multiple on the same level. Lets say a contact doesn't have a local account but has two cloud ids in the address book. Which one should be shown then. We can't just use a random one there.

Obsolete

[jancborchardt]

@juliushaertl hm, as far as talking with @MorrisJobke & @rullzer I thought the main point of the consolidation was to actually consolidate people into one entry.

Lets say a contact doesn't have a local account but has two cloud ids in the address book. Which one should be shown then. We can't just use a random one there.

Why not share it to both in the background, and just see where they accept? We don’t really know which cloud they use anyway. Ideally then afterwards we know what they accepted with and that will be set as the standard method.

Yes, grouping the person and removing the duplicate avatars are good first steps – but the initial plan was to really make clear that it’s one and the same person, and that you as the person who shares really shouldn’t bother which way you share → it’s only important to share with the person.

[juliusknorr]

hm, as far as talking with @MorrisJobke & @rullzer I thought the main point of the consolidation was to actually consolidate people into one entry.

Ok, I just couldn't find any issue discussion about it, that was why I asked for more input. 👍

Why not share it to both in the background, and just see where they accept? We don’t really know which cloud they use anyway. Ideally then afterwards we know what they accepted with and that will be set as the standard method.

That is probably something we can consider for later, since that would require us to store the preffered share method somewhere and also have a way in the sharing backend to not show up multiple shares in the ui then. Seems a bit to much for 15 to me 😉

Yes, grouping the person and removing the duplicate avatars are good first steps – but the initial plan was to really make clear that it’s one and the same person, and that you as the person who shares really shouldn’t bother which way you share → it’s only important to share with the person.

How about picking a default share option for contacts while searching, but once we have a exact match of the search string (e.g the user has entered the complete name) we show the other share options as well. That way you still have the choice if you want to, but in the regular case the user can quickly share using the best available method.

Example:

User types "Jan"
Share dialog shows:

• Jan-Christoph Borchardt (will share with the first we have of local user/federation/email)

User types "Jan-Christoph Borchardt"
Share dialog shows:

• Jan-Christoph Borchardt (local user)
• Jan-Christoph Borchardt (federation)
• Jan-Christoph Borchardt (email)

Edit: To make it a bit easier we maybe could allow to use the tab-key to complete the display name of the currently selected entry.

• User types "Jan"
• Share dialog shows entry: Jan-Christoph Borchardt
• User hits tab
• Share input field is filled with Jan-Christoph Borchardt
• All share options show up as descriped above

[juliusknorr]

@nextcloud/designers Here is how the solution I've described above looks like:

Fuzzy search with consolidated results:

Hit tab to complete the currently selected contact name, all contact methods are shown:

[juliusknorr]

Ready to review.

CI failure is a timeout: https://drone.nextcloud.com/nextcloud/server/12057/192

[jancborchardt]

How about picking a default share option for contacts while searching, but once we have a exact match of the search string (e.g the user has entered the complete name) we show the other share options as well. That way you still have the choice if you want to, but in the regular case the user can quickly share using the best available method.

Wow, great solution @juliushaertl! 🎉 :) 👍

[skjnldsv]

Looking really great! Amazing work!! 🎉
Small changes though? :)

Fixed ;)

[juliusknorr]

@skjnldsv Comments addressed.

[rullzer]

Awesome stuff looking good!

[rullzer]

Only minor comment (but we can fix that later)

Is that the default dropdown is quite small on firefox for me

But as said lets get this in and fix minor stuff in a later PR so this doesn't get even more huge

[juliusknorr]

Is that the default dropdown is quite small on firefox for me

Do you have the gallery app installed? Iirc there was a style overwriting the server rules, I can have a look later.

[rullzer]

Yes I had this enabled on my tests.

[jancborchardt]

Do you have the gallery app installed? Iirc there was a style overwriting the server rules, I can have a look later.

O lala, another reason to get rid of the legacy code :O

[jospoortvliet]

Is there anything the gallery does now we have grid view? Ok, it is more focused on images etc but I'd separate the actual viewing view and have that in core/Files and have the gallery as an optional app users can install. Few will, I bet.

More on-topic, I'll test this a bit once it is in the daily builds ;-)

[MorrisJobke]

Is there anything the gallery does now we have grid view?

Yes - slideshow is still in the gallery.

[jospoortvliet]

Yeah, I thought so... Ok, for later then.

[jancborchardt]

I'd separate the actual viewing view and have that in core/Files and have the gallery as an optional app users can install. Few will, I bet.

Yup, the next step is to write a new universal viewer. Spec at #12382
Afterwards we should indeed stop shipping Gallery as it duplicates functionality of grid view, and is pretty outdated and unmaintained. Grid view is a better and well-integrated replacement.