Allow multiple share links

[schiessle]

Before starting on the implementation of multiple share links I would like to get some feedback from @nextcloud/designers how this should look like.

I already thought about it a little bit and this is my suggestion:

1. Initial share view:

If you click on "create new public link" you get a text input field which is pre-filled with "share link 1", the next one "share link 2", and so on, so that the user can give the link a name.

If the link was created it will look like this, the user sees the new share link, with the '...' menu and again a option to create another public link:

To the '...' menu I would add the two new additional option "rename" and "unshare".

Opionions? cc @jancborchardt

Steps to complete it

• agree on design
• front-end implementation
• back-end implementation
• OCS API implementation
• Tests

[nextcloud-bot]

GitMate.io thinks possibly related issues are #10218 (allow to add a personal note to a share), #10194 (multiple attachments), #10132 (Allow restoring of deleted user shares), #1639 (Unable to access public shared link), and #3243 (Share by single file with multiple links.).

[MariusBluem]

See discussion and mockups here: #5336

[jancborchardt]

FYI I'm on vacation – please never only @-mention me, always the whole @nextcloud/designers team. :)

As for the design:

• The current way for the first link should stay like it is, to not clutter the view with extra entries for the most common case.
• When you tap into the share input field, "Add new share link" should be suggested as entry like in @MariusBluem's mockup in the linked issue.

[schiessle]

When you tap into the share input field, "Add new share link" should be suggested as entry like in @MariusBluem's mockup in the linked issue.

And the link, after it was created, looks then the same way as the first one (with the checkbox and so on). Do they all have the same name? Or do you just add a number? How will people distinguish the different links?

Also on link removal. Unchecking the checkbox will then remove the complete entry as long as there is one more link and if it is the last one we keep the entry and just uncheck it so that the user can again create the first public link?

Not sure if I understand it completely but sounds quite clumsy and more complicated then what I suggested.

Btw, your mockup here looks quite similiar to what I suggested: #5336 (comment) You also have always a "new share link" action on the top and below the existing shares, including already created public links.

[MariusBluem]

You should definitely be able to give share links a name (maybe we should make this mandatory at all ...)

[tobiasKaminsky]

maybe we should make this mandatory at all

I am unsure how many sharing links are done on one file, but if you only have one, there is no need to have a name for it (of course you should be able to name it, if you want).

[schiessle]

You should definitely be able to give share links a name (maybe we should make this mandatory at all ...)

I agree, that's why my mockup gives you directly a input field, where you can just press enter or focus out to accept the default or give it a custom name without a lot of hassle.

[tobiasKaminsky]

Is this a feature that should also be available on clients?

[MorrisJobke]

Is this a feature that should also be available on clients?

Would make sense 👍

[blackcrack]

would be nice if to be able for make a "public" folder to share it
and give a frame from the NextCloud /Public-Files
where listing like this :
http://blackysgate.net/phpfilemirror/upload/
( phpfilemirror this code can be take as example (plugin textbrowser under addons) but i have no time at moment for playing around with php code..)

to have a public-sharing like as example :
https://webserver.org/nextcloud/User/public-files

therewith it is possible for provide directories and files in public for download,
add in a downloadpage or in a webpage to have a possible for publishing files and folders in easy way..

therewith it is also possible to put videos on this public-sharing folders
and if we have a webm(av1) ( [request] Webm Encoder app for Files-app )
can we put howto as movis online or other interesting things..
from Research and Technology.
As example, Total Commander, Videotutarial's .. addons in subfolders + howto videos.
or for give Wallpapers and photos directly online and copy in the public-folder, the subfolders can have name like date wallpapers-from-20181001 and so on ..
or if it's possible for put html/php files inside for create other content..
or something ..
just as suggestion/idea .. for playing this idea further ..

best regards
Blacky

[tobiasKaminsky]

Is this a feature that should also be available on clients?

Would make sense

Once there is a PR, I'll open up an issue on all clients (prior does not make sense, as we cannot implement/test it)
For UI/UX on clients I assume, that we can try to stick very close to webUI.

[jancborchardt]

@schiessle the main issue with the flow you suggest is that people are faced with an input field first. This is a barrier – you want to simply share a link, not think of a name. There’s a reason we designed it like we did. ;) Also because the most common case is only having 1 single share link, which in your design would take up 2 rows already – confusing people.

And the link, after it was created, looks then the same way as the first one (with the checkbox and so on). Do they all have the same name? Or do you just add a number? How will people distinguish the different links?

No, it could simply be "Share link 2" for example. Or even better, name it like the settings it uses "Read-only link", "Files drop link", etc. The default is "Share link" and is editable. You need a fallback for that too even when using an input field.

Also DO NOT use the wording "Public link" as the link is not publicized anywhere.

---

TL;DR: There is a design we discussed among the design team, I described it above and it’s in the linked issue #5336. Let’s please go with what we agreed on as a group, ok? 🙂

[schiessle]

@jancborchardt Honestly I don't see a final conclusion here #5336 There is one mockup by @MariusBluem and your drawing which are quite different. Also as pointed out here #11169 (comment) my proposal seems to be quite similar to your drawing. The only thing I might need to skip is the input field. Personally I consider it a nice workflow, if you are fine with the default lable you press just enter of focus out. If not you can set up the complete link, including a nice label like "for jan" in one run without having to go back to the '...' menu, etc.

But time is running. So I don't want to discuss this to dead. Do we agree that if we skip the part with the entry field my suggestion is in line with your drawing? If not please be more concrete.

[jancborchardt]

Yes, we need to skip the entry field. And yes, we should also not disrupt the current flow. And yes, when you only have a single shared link, there should not be 2 entries in the links related to link sharing.

There should be one default entry in the list for "Share link" exactly like now.

And additional links you should be able to create by:

• opening the 3-dot menu of the default share link entry and having a "Create another share link" entry there
• tapping in the input field and having a "Create another share link" entry there

(If you only think one is good, decide for one.)

Then that entry appears and the link is immediately copied into the clipboard. And the 3-dot menu is opened as well. (As per @skjnldsv pull request.)

Ok?

[schiessle]

@skjnldsv did you had a chance to look in the UI part of this?

You can commit directly here and also drag over the commits from your other pr if you want.

[skjnldsv]

@schiessle I'm on it until the feature freeze, this is the only task left for me :)
Status: this is a nightmare. The code is a complete mess and I'm banging my head.

I'm very disappointed that we did not wait for the new sidebar standard so we could at least know the code we're working on :'(

[schiessle]

thanks a lot @skjnldsv ! So it is at least not only me who felt lost in the code...

[skjnldsv]

@schiessle unfortunately no. We'll have to talk about this at the next hackweek :)