Pictures: not apparent how to add pictures

[jancborchardt]

As pictures is essentially just a frontend to all the pictures in the Files app, it’s not apparent how to get started or add pictures.

To fix this, the top bar in the Pictures app should have an upload button just like Files. This then just uploads it to the folder inside Files.

[butonic]

@jancborchardt Where should the upload button be placed? next to the breadcrumbs I assume?

[jancborchardt]

@butonic yeah, just like in the Files app would be a good start.

Or a different thought, for a more contextual design: Have the first block in the list (where the first image would appear) be a big add field. Should probably have 2 buttons, for »Upload« and for »Create folder«.
I prefer this also because we kind of want to get rid of the top bar as a static thing, just having the breadcrumbs overlay. (Maybe I need to explain this more.)

What do you think?

[butonic]

@jancborchardt @stefannagtegaal @laryllian There is a reason for "well known" user dirs: http://freedesktop.org/wiki/Software/xdg-user-dirs / http://cgit.freedesktop.org/xdg/xdg-user-dirs/tree/user-dirs.defaults. As a consequence I'd like to start the pictures app in a localized {PICTURES} folder. The user can still navigate to / by clicking the home breadcrumb. This way images will land in the {PICTURES} folder and not in /. Similar to music which should automatically determine the folder by looking at the meta information and use {MUSIC}/{artist}/{album}/{trackno}. - {title}.{ext} or a configurable template ... or any folder when uploading it in the files app. Opinions?

[jancborchardt]

Regarding that I guess you know more. Having it in localized folders instead of just English »Pictures« and »Music« is good, because the app names are localized as well.

[stefannagtegaal]

While I don't think it's appropriate to discuss this here, I do think that this needs fixing. However, Pictures and Music is just nothing else as another (limited) view of the Files page with a different presentation (eg. image-files are presented as such, and music-files are being capable of playing. Besides that, it's nothing new..

The fact that the above is totally misunderstood by users, is that the menu items "Images" and "Music" appear in the top navigation which gives people the idea of switching between different directories, while they are basically only switching views (only display images and only display music-files).

If you want to go this way and have a different navigation-item for Images and Music, how would you do that for the rest of all file formats like pdf/doc/docx/ppt/wav/mp4/ogg, etc, etc.. Do you want them all to appear in the top navigation, categorised by type? It doesn't make sense to me..

Code wise, we are doing nothing else as selecting all the filetypes which are of a special mime-type, and presenting it differently. So, some sort of menu which gives users the ability to switch between different views, would be better imo.

[icewind1991]

I think trying to guess the correct folder for Pictures (or music) is to much of a problem, a user might not want his folder names localized the same way he wants his interface to be localized, he might want all of his pictures stored on a separate mount or just use a different name altogether.

I think it's best to just let the user create his own "Pictures" folder if we want it.

The question of where to put new uploads from the pictures app is no issue anyway since the galleries copy the underlying directory structure. So when a user choose to uploads a file inside a gallery we can simply put it in that folder.

[stefannagtegaal]

First of all: I'm not against adding an upload-form here, I totally agree.
I only think the reason behind it should be that it's easier/faster for a user to add files to the Files-table. Nothing more.

[jancborchardt]

Ok, this has always been a pain for users so let’s please move forward with a very simple »upload button« solution. Like I originally proposed:

Have the first block in the list (where the first image would appear) be a big »Add« square. Should probably have 2 buttons, for »Upload« and for »Create folder«.

@butonic did you mention at some point in time that you already added an upload button to the pictures app for a customer? Let me know. :)

[butonic]

yes I have. I'm currently busy with oracle fixes and backporting. But in about two weeks or maybe when I'm annoyed of oracle, I'll backport that. Instead of »Create folder« I'd use »Create album« to be in line with the used terminology in the pictures app.

[jancborchardt]

@butonic aye! Good call on the wording also.

[jancborchardt]

cc @libasys & @oparoz on this issue. This has been the prime complaint and problem in usability tests with the Pictures app. (No, not more settings. ;)

[oparoz]

Yep, an upload button shouldn't be a problem, but for drag and drop we would need the whole upload mechanism to be moved to public functions or create our own, which would probably be a nightmare since it seems you were forced to write your own

[jancborchardt]

@oparoz for now an upload button is fine. We can do drag&drop later. :)

[oparoz]

I've had a look and it's the same problem if using an upload button. All the JS we need is in the Files app, so we can't access it.

[libasys]

no that is not the problem you get the upload functionality with:

script('files', 'jquery.fileupload');

and as example form html

<form style="display:none;" class="float" id="file_upload_form" action="<?php print_unescaped(\OCP\Util::linkToRoute('gallery.images.uploadImages')); ?>" method="post" enctype="multipart/form-data" target="file_upload_target">
    <input type="hidden" name="id" value="">
    <input type="hidden" name="requesttoken" value="<?php p($_['requesttoken']) ?>">
    <input type="hidden" name="MAX_FILE_SIZE" value="<?php p($_['uploadMaxFilesize']) ?>" id="max_upload">
    <input type="hidden" class="max_human_file_size" value="(max <?php p($_['uploadMaxHumanFilesize']); ?>)">
    <input id="pinphoto_fileupload" type="file" accept="image/*" name="imagefile" />
</form>

and a js function like:

$('input#pinphoto_fileupload').fileupload({
        dataType : 'json',
        url : OC.generateUrl('routetoyourupload'),
        done : function(e, data) {
}
});

and php part as example:

       /**
     * @NoAdminRequired
     */
    public function uploadPhoto(){

        $file = $this->request->getUploadedFile('imagefile');
     ......
       }

and that's all, but i see more a problem if you work with caching the images in a js array, with every new uploaded file you have to generate it new!

[oparoz]

@libasys - Yes, we could do it that way, but we would probably missing lots of use cases covered by https://github.com/owncloud/core/blob/stable8/apps/files/js/file-upload.js

If it's not an exact match, users will reject it.

[libasys]

my 5 cents: I think you have to add to much js to get this feature running and slows the gallery app down!

[oparoz]

How will it slow it down (if drag and drop is not implemented)?

[libasys]

you have to add js libs on loading the gallery app

[oparoz]

Ah, but that's a problem all apps are going to have anyway, since there is no library sharing allowed and since RequireJS is not used.

I agree that it can be a problem to add a large lib to try and solve a problem which only affects a few users, but apparently this is at the top of the list of the most wanted features, so unless the lib is 500k, I think it will be acceptable.

[libasys]

this 3 js files needed:

OCP\Util::addscript('files', 'file-upload');
OCP\Util::addscript('files', 'jquery.iframe-transport');
OCP\Util::addscript('files', 'jquery.fileupload');

you can have a look at the files/ajax/upload.php file if you can use it, what the returning values are!

[oparoz]

My main problem is that file-upload is not on bower. It will be a maintenance nightmare to keep track of changes. That's why it needs to move to the public space or be turned in to a bower lib so that apps can use it.
Could this be a way forward @butonic?

[DeepDiver1975]

Please reopen in gallery(plus) repo is still valid - THX