Design forward: Sharing behavior

[jancborchardt]

Sharing improvements

As talked about with @DeepDiver1975 @butonic @MTRichards @karlitschek etc.

Precursors:

• Review new Share API, see Share API 2 #3969
• Improve the sharing dialog, see »Design forward: Sharing dialog« Design forward: Sharing dialog #3224
• Decide on how quota is calculated, see Shared Files filesize subtracted from quota + fix/patch #2796

Indicate owner and participants

Currently, you need to click on the dropdown to know who is the original owner of a file shared with you.

• Instead, this should be directly in the file list row, where the »Shared« icon is right now.
• In the future we can do that with user images or other autogenerated visual identifiers.

Get rid of the »Shared« folder – DONE!

Currently, there is an empty read-only »Shared« folder where files/folders shared with you will appear. This is very confusing.

• Instead, shares should by default directly go into the root folder.

Ability to move and rename shares freely - DONE

• As people arrange their files differently, one should be able to freely move and rename the root of the share. That is, folder and file name.

Notify recipients and prompt to accept/decline shares

Currently, shared files are immediately added to your account, which can fill up your storage. Then they get synced via the desktop client which in turn fills up your computer space.
We should have a mechanism to notify people of incoming shares so they can accept or decline them.
That should also be configurable for admins for cases where people need to be in shares.

[butonic]

@DeepDiver1975 technical notes:

• mount each share as a separate mount point. too expensive?
• moving over mount point boundaries (eg. moving a file from a shared folder to a non shared folder) causes copy by default. reason being that files contained in a shared folder also belong to that mount point.

[stephanarts]

@jancborchardt if shared files are only added to it's owner's quota, that solves the problem of filling up your storage aswell, doesn't it?

If I have 2 users with different quota's (10 and 1GB) and the user with a 10GB quota shares a 5GB file with the one having only a one GB quota will effectively block the second user from using ownCloud. This effectively prohibits a 'power-user' to collaborate with lesser mortals.

[mbremer]

In the current implementation all shared folders from different users are put in the same Shared folder. As a result, duplicate folder names will be mapped with a running number, e.g. pictures(2), while the original name is pictures.
I find this very confusing, because names should be the same as the original. One way to solve this is to have a shared folder for every user who shared stuff with you, e.g. Shared userA, Shared UserB. This would already solve the issue of identifying who's shared folder it is and you don't need a new column or identifier in your layout.

[jancborchardt]

@stephanarts the storage fill up problem still exists – for your computer, because currently a share is accepted and then synced automatically. For the storage and sharing stuff, see #2796 – I updated the original post above, thank you for the hint.

@mbremer we thought about that too but having folders named by the people who shared them with you actually makes little sense. The file or folder name itself is the most important, and who participates is a different matter. We shouldn’t enforce folder names like that.

[mbremer]

I am not sure if my point was understood. I only want the starting point of the share to have the user name, not the actual folders being shared. Attached is a similar concept from my laptop where in Finder (on the Mac) you have a list of shared folders from different users. Once you click on such a share you'll see the folder names just like the original.

[jancborchardt]

@mbremer I understood it. And thank you for the clarification but we aim to do it like I described above. Regarding desktop integration, shared folders should ideally be marked with a share icon badge similar to the sync status badges as talked about in owncloud/client#102

[schiessle]

Just a note regarding notifications about shares and the ability to accept/decline shares: We have to make sure that this also works for people who use the sync client only. It has to be possible to accept/decline shares both on the web interface and on the desktop client.

Although it is just a semi-official interface, but what about people who use their ownCloud only over a webdav mount, e.g. gnome online account? They will never be able to receive shares, right?

One more note regarding the time frame: Is it realistic to get this all into OC6? I would be already happy if OC6 comes with the new Share API and is at least as stable as OC5. Therefore I would vote for a stable and solid share API for OC6 and new share features for OC7.

[jancborchardt]

The notifications will come in via email then.

And I highly doubt this will be ready for ownCloud 6.

[DeepDiver1975]

@MTRichards does this approach match the product roadmap?

OC6 comes with the new Share API and is at least as stable as OC5

fullack

[DeepDiver1975]

@MTGap

Is the ShareAPI feature complete to fulfill the described behavior?
Please drop technical question/considerations - THX

[butonic]

@jancborchardt I'd like to add another subtopic:

Allow guest to change app

Currently guests (people visiting public shared files with a token based link) only see the filelist and possibly the slideshow when clicking on an image. What you really want is to send people a link to a shared folder containing last nights party pictures that shows the big 200x200px previews as in the pictures app. Or the crazy songs from the party playlist that should be shown in @kabum s new music app. Or videos of the party shown in the video app. While this is related to how we want those apps to integrate with owncloud we should allow a guest to change the 'app' he uses to access a set of shared files.

[jancborchardt]

This should not need a user action, but rather a share which was shared
through Pictures should automatically use the layout and big thumbnails of
pictures. Same for Videos.
On Sep 3, 2013 2:49 PM, "Jörn Friedrich Dreyer" [email protected]
wrote:

@jancborchardt https://github.com/jancborchardt I'd like to add another
subtopic:
Allow guest to change app

Currently guests (people visiting public shared files with a token based
link) only see the filelist and possibly the slideshow when clicking on an
image. What you really want is to send people a link to a shared folder
containing last nights party pictures that shows the big 200x200px previews
as in the pictures app. Or the crazy songs from the party playlist that
should be shown in @kabum https://github.com/kabum s new music app. Or
videos of the party shown in the video app. While this is related to how we
want those apps to integrate with owncloud we should allow a guest to
change the 'app' he uses to access a set of shared files.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4437#issuecomment-23709746
.

[MTRichards]

Agreed. It would be great to see anonymous users getting a trouble free view into the files shared with them.

Of course, it should also be something the admin can turn off for anonymous users.

[butonic]

It's not taht easy to decide what app to show to the user by default. Showing the app that was used to share something might be a start. When I share an Album from the pictures app with you, you would initially see the thumbnails, which is great. Now you want to download the album as a zip. Pictures does not have a button for that. You would have to go to the files app, which is currently not possible. Hence I think we need to allow guests to navigate to other apps.

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[MorrisJobke]

Now you want to download the album as a zip. Pictures does not have a button for that.

The download button should always be visible in the header (upper right) no matter which app is shown, because it's the essential feature of sharing to download the content.

[jancborchardt]

Yes. The download button should always be visible as @kabum said.

And pictures shared through Pictures should always be displayed appropriately. The admin switch to turn that off is the Pictures app itself. If it’s shared through the Pictures app it’s a) clearly pictures and b) the intent to have them display like that. If a bland file list is wanted, it could be shared through Files.

[butonic]

Can we agree on two groups of apps:

viewers and editors

• Text Editor,
• PDF Viewer,
• Slideshow (currently part of pictures) provides the deprecated image viewer app
• Video viewer (haven't had a look at the code)
• webodf editor

Viewers and Editors provide a meaningful way to interact with a single file. It does not matter If you open a picture from the Files or from the Pictures app. It will always open in the slideshow, allowing you to go to the next or previous image in the album or in the folder.

file based apps providing a specialized focus on a set of files (and folders)

• Files (default dir is /)
• Pictures (default dir is /Pictures) - currently also contains the slideshow / image view functionality used in files,
• Videos (default dir is /Videos) - haven't seen the code but I think it should work similar to Pictures / Music, exposing meta information in a Music like interface and providing the actual video viewer
• Documents (default dir is /Documents).

Real file based apps change the visible content to focus on a specific task. The Music app works on extracted meta data from audio files and hides all other files. The Pictures app shows thumbnails and hides all files but images. Each of these apps allows users to upload or if possible to create a new file in the default dir. If the app allows navigation to other folders (Files, Pictures) it will upload to the current folder. Music works on Metadata and always uploads to Music. Videos TBD?

context for a user who wants to share sth.

As @jancborchardt already correctly explained to most of us we want a share button in every viewer & editor, so a user can share what he is currently seeing. We also want a share button in every file based app to allow sharing groups of files / folders.

context for users accessing sth shared with them

I hope we can all agree that users should be able to use any editor & viewer we have to access a file. They should also be able to use any file based app we have to change focus. My GF will kill me if she has to download a full album when she only wants two images in an album of 1k files (we have friends uploading too many bad and redundant holiday pictures, although there is always right click -> download ... ). When I share a project folder (Summer Holiday 2013) that contains images, documents, music and videos I want to be able to switch apps.

Starting in the app from which a set of files was shared does not change that.

[PVince81]

Linking this ticket about resharing chain and "global list of who can see a file" here: #5345

[butonic]

Not to self. Explore a custom public.php template that contains / loads the necessary html and JS code to run Pictures and Music / Media.

[butonic]

sharing with stable links in combination with a contact

When sharing to contacts it would be nice to have stable links. For that the token should not contain any randomness but could be based on the fileid in combination with the contact id. The contact has to authenticate anyway, so there is no problem in the token being reproducable.

[jancborchardt]

@butonic good point. That would also be useful for when sharing via email. It allows us to generate a unique link per contact, so it can be individually revoked.

[butonic]

@jancborchardt Not only that, but when you unshare the file, say by accident and then reshare the file to the same contact it should generate the same link / token. So you don't have to resend the link to your contact.

[jerrac]

If the only indication that a folder is shared with you is an icon, what happens if you can't see that icon? Say, if you're blind? I like the idea of prefacing the folder name with the sharing user's display name.

Is being able to remove yourself from a share on the roadmap? After you've accepted it. So, you need temp access to another users folder, they give it to you, you accept the share, then they forget to remove you after you're done with it. So, you remove yourself.

[schiessle]

If the only indication that a folder is shared with you is an icon, what happens if you can't see that icon? Say, if you're blind?

I'm not an accessibility expert but shouldn't your braille terminal or screen read "tell" you the alt text of the image or something similar in this case?

Is being able to remove yourself from a share on the roadmap?

Yes, we are planing to add this feature to the new share dialog.

[jerrac]

@schiesbn

I'm not an accessibility expert but shouldn't your braille terminal or screen read "tell" you the alt text of the image or something similar in this case?

If you are using one. What if you are just color blind, or something like that? The answer to that would be a well designed icon. Or maybe a (shared from john smith) next to the folder on wide views.

Yes, we are planing to add this feature to the new share dialog.

Nice. :)

[schiessle]

What if you are just color blind, or something like that? The answer to that would be a well designed icon.

Are the current icons not well designed? If you have experience in this area I'm sure our designers would appreciate your input.

[jerrac]

The icon itself has good contrast, and I think it would work well for most
users.

The symbol on the current Shared folder icon does not imply sharing to me.
To be honest, I'm not sure what it implies.

If it were the same icon as what is on the Share button you click to open
the share dialog, I could learn what it means.

But, I'm very leery of relying on everyone understanding what a symbol
means. Thus, for screen sizes that allow it, I'd add some kind of text to
differentiate it as well.

--David Reagan

On Thu, Jan 16, 2014 at 9:55 AM, Björn Schießle [email protected]:

What if you are just color blind, or something like that? The answer to
that would be a well designed icon.

Are the current icons not well designed? If you have experience in this
area I'm sure our designers would appreciate your input.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4437#issuecomment-32493540
.

[jerrac]

I just found #3340 which, if implemented, makes shared files very clear.

[jancborchardt]

In ownCloud 6, shared files have a permanently visible »Shared« indicator to the right. Including an icon for »group«.

[ase69s]

"Instead, shares should by default directly go into the root folder."
+1 to this idea

[nloui]

+1 from us as well

[jancborchardt]

Note that the »shares should by default directly go into the root folder« is being worked on for ownCloud 7 (I think by @schiesbn).

[MorrisJobke]

@jancborchardt Really? Nice :)

[PVince81]

Should we add tick marks in the original post ? A few has been implemented already.

• Shared folder removal: remove the "Shared" folder #8026
• Ability to move and rename shares freely: also remove the "Shared" folder #8026

@jancborchardt "Indicate owner and participants" is done as well ? Or is there more work to come ?

[jancborchardt]

@PVince81 updated the original post. You can also edit original posts btw.

[PVince81]

I know, I just didn't want to hijack it 😄

[DeepDiver1975]

@jancborchardt anything missing in here?

please either close or move to 8.1-next - THX

[jancborchardt]

Yep, all the original items are done. Other issues are tracked separately.