Implement sorting filters

[oparoz]

The default is to sort alphabetically, but it should be possible for the user to sort his collection by date and to reverse that order

Requirements

• [x] Sorting interface
• [x] Sorting code. Pull the data from the cache, send it to the client and process it.
• [x] Fix https://github.com/interfasys/galleryplus/issues/56

  Open questions

• Should we have a dropdown with 4 possibilities? 2 buttons? Where?
• Which date to use? Currently only the uploading date is available, but if meta data support is introduced then it would be possible to sort by date-the-picture-was-taken
• Should we we have more filters? Sort by brightness, colour, size, etc.

Designers: @jancborchardt Interested parties: @deMattin @Riechao @noooz @seuf @FredrikLindseth @Aesculapius @simonclausen

[deMattin]

For sorting I only see the filename, filedate and date picture is taken. This could be a simple pulldown named "sorting" with this 6 options (every option and reverse).

The activated sorting should remain active as long as gallery is active and has to be reset to default if you restart gallery. I don't think, a user customizing of this "default" is neccessary.

With more meta data support it could be possible to filter the output. I don't see the sorting in this context as a useful task.

But there are many questions remaining if you implement filters. You have to get a list of existing (selected) meta-data in the current folder to set a filter only on existing values. How could such a "list" look like?

[jancborchardt]

At first we don’t really need an interface for it. Sorting should be by date taken by default. Alphabetic sorting makes 0 sense for photos.

After that, we can still judge if we really need other options.

[deMattin]

Alphabetic sorting does make sense!

Cameras save their picture names chronological in alphabetical order and if you have a collection of (renamed) photos it is normally also sorted alphabetically. You can not really rely on the meta data "date taken" on cameras. They often have wrong dates because of previously empty batteries and not have setting correct date after such a "reset".

And if you rename, you have influence on sorting (thematic prefix). Editing and correcting meta data is very often not done by many users.

So I definitly vote for alphabetical order as default as it is now!

[Koire]

@deMattin There are 2 problems I've found with this: 1.) The default of the gallery is to sort A-Z (smallest to largest -- reverse chronological order), and I have 4 or 5 years worth of photos from various smartphones, viewing my more recent photos is a hassle. 2.) Not every device uses the same naming convention. Some of my pictures are just the timestamp, some have img_date_time, some pic_datetime, some datetime, some yyyy-mm-dd-time -- it's bad because they become scattered and only sorted by the naming convention.

[oparoz]

And that's the reason I think we need some sort of panel with options so that people can configure the view the way they want to.

[jancborchardt]

And, well, sorting by date taken – newest first – should be the default.

@oparoz yeah, we could have that as a setting. However for every setting we really need to question if we actually need it.

[deMattin]

Sorting on filename (and reverse) are ready to use, fast and the reverse order function is easy to implement (#90). Sorting on metadata (date taken or others) depend on looking in the file and certainly will be slower because you have to read ALL pictures first to sort them afterwards.

I think, to have the option, to sort the gallery folder as you need, is a fine feature and I support it.

But while generating the view and on first call (so it will be "default") I think it will be much slower with nothing appearing on the screen, if there will be a sort order with meta data as default.

Or do you want to wait until e.g. 500 picture previews are generated (picturesize and orientation matters for previews size and needed displayspace), metadata read of all files and after that all pictures are sorted and sent to browser?

If you have meta data as default, there also has to be a permanent "cache" and cache management for this data to be established because if not, you have to wait for this procedure to be finished every time you open a folder.

Again: Metadata sorting is a fine feature but only as a switching option if all pictures or previews are already generated AND displayed. Gallery+ isn't very fast yet and it shouldn't slow down only because of a default view which will slow down all on design.

@Riechao: because of your "Point 1.)" I made #90 because this is also my problem and surely others will have it too. Everybody, who is having a maintained picture folders won't need "date taken" at all because:

1. the picture names mostly content date/time or a serialized number
2. date taken corresponds to filename order if you have the same source
3. But they often need "reverse order" to show newest pictures first

Date taken is only needed, if you have different sources for your pictures in same folder and leave filenames as they are. I don't think, that's the usual case to reasonable slow gallery+ down.

Namesorting A-Z and Z-A could be the first step and metadata the second. And if there is a solution, that doesn't slow down with metadata, we can discuss again, what should be default ... ;)

But I don't know how to get a progress in here: Sorting by name and reverse are easy to implement but oparoz waits for a panel design. I thing, if noone of the core designer team will have a look here, optional sorting will never come ... ;)

[oparoz]

A good point was made. Sorting by date taken can only work if we store the metadata in the database and would require some sort of data collection at upload time to be really usable.

[deMattin]

I hope, there was not only one good point .. ;)

But I really think, sorting should be made step by step:

1. filename and reverse sorting switchable
2. metadata sorting to be switchable in a already generated preview (no cache or db storage needed and we will see, how fast or slow this will be)
3. metadata sorting (picture taken) with permanent saved or cached meta data and its update management.
4. enhance metadata sorting from picture taken to whatever you can think of (metatags could even be customizable by user?)

I think, point 3. will be a really hard job because you have to be aware of meta data changing and there will be all problems, also the sync client has to deal with. So I thing, it won't be a good idea to realize all in one step.

[jancborchardt]

Well – then we should probably store that in the database. Proper apps like Dropbox can do it, and sort it by date – we should be able to as well. :)

[deMattin]

How many developers does dropbox have? :wink:

[jancborchardt]

I’m pretty sure comparing the number of developers doesn’t matter here. :) The point is that sorting is one of the main things in a pictures app, and something we should do right.

[deMattin]

It definitely does matter, how many developers there are! Without oparoz the gallery+ won't exist and I see not much coding help here (sadly my skills are too low).

What you want to have is a big coding job and I think it won't be possible to realize this in more or less one step. But noone other than oparoz will decide, how he acts further ...

[jancborchardt]

That’s why I would like to discuss it with @oparoz instead of talking about maybes. :)

[deMattin]

He is involved, surely listens and will tell us, what he thinks or will do next ... ;) I don't think, this is a senseless blabla here. If we discuss this, it's possible to decide, what will be best approach to get all satisfied. I see it as a sort of brainstorming. Sadly as a non developer there's nothing more we or I can do (in addition to testing) to help the project ...

[oparoz]

From my pov, #90 is easy, as long as someone takes care of the UI. Same if we implement a simple sort by upload date, but for the rest, I think we're a long way off since the app doesn't currently store any data in the database.

So hopefully, the first steps can make 50+% of people happy and the rest will have to wait.

[oparoz]

if some of you need to have a default sorting order for some albums, you should test the album-info branch/PR Information about the config file is in #93 .

[oparoz]

Can't be implemented until https://github.com/interfasys/galleryplus/issues/56 is fixed.

[oparoz]

Interesting parties can try the sorting-buttons branch. I'm not going to spend any more time on the buttons, so designers will need to get involved to get this merged into master, but I will try to fix all reported sorting issues.

Note: Asset pipelining doesn't seem to be able to compile the scripts properly on my test setup. Let me know if this is also an issue for you.

[deMattin]

Sorting seems to work and I like the solution and the buttons. But there is a problem with the svg-files. They arise a second and then disappear: There seem two be 2 versions loaded - a correct one and a wrong one, witch overrides the right one:

GET https://[domain]/apps/galleryplus/img/namedes.svg 404 (Not Found)

namedes.svg Dimensions 0 × 0 File size 230B MIME type text/html URL https://[domain]/apps/galleryplus/img/namedes.svg

It seems to be the path. The path is without "owncloud" but is webroot instead! It is https://[domain]/apps/galleryplus/img/namedes.svg instead of https://[domain]/owncloud/apps/galleryplus/img/namedes.svg

Edit: And the inagename thing is fine, also - good work! :+1:

[oparoz]

I can't reproduce your icon issue. The paths are relative, so it's strange that it's adding them to the root folder, unless asset pipelining is enabled.

[deMattin]

No assets activated. There have to be 2 places, where this icons are loaded in code. They first arise and then disappear, as the breadcrump is displayed. I also see in debugger the both loaded svg files. The one with right path and the one with the wrong after that.

[oparoz]

Which browser? I've tried with Firefox, Chrome and BlackBerry 10 and they could all show the icons. Do you see all 4 icons in your img folder?

[deMattin]

I've tried with my default "chrome" and with normally not used and cache cleared IE11, firefox and Nexus 4 (only for testing) . All with 2 different owncloud accounts. Again: The Icons are firstly shown but are overwritten by the "wrong path" ones! So the first load does work but when broadcrum arises there is something, that goes wrong. Maybe in the part, where the previews are generated and the actual sorting order is set. I don't fully understand this part of code.

My first thought was a wrong mimetype of the "overwriting" error, because in the list of the loaded ressources, there is the correct one and the one with the "wrong path" and a false mimetype.

Icons are in img folder and not corrupt. But if this wouldn't be so, the short diplay of the icons won't work.

Edit: Also deactivated my theming and restarted apache - no success ... :/

[oparoz]

I've committed a change, but Github is misbehaving atm, so you'll have to wait to see if it helps.

[oparoz]

Github is under attack https://github.com/blog/1981-large-scale-ddos-attack-on-github-com

[deMattin]

Ok, I'll wait and meanwhile watch "Django unchained" ... :smile:

[oparoz]

Or replace line 452 in gallery.js with this: button.find('img').attr('src', '/apps/' + Gallery.appName + '/img/' + icon + '.svg'); ;)

[deMattin]

Sadly doesn't change anything ... :disappointed:

[oparoz]

Maybe it's a problem with the default sorting order. What did you set it at for that album?

[deMattin]

As I also tested in an account without any options set, this can't be the reason.

[oparoz]

Found the problem

[oparoz]

Should be fixed now

[deMattin]

Is fixed! Good work! Tested on FF, Chrome and IE11.

[oparoz]

Thanks for testing :)

[oparoz]

I've asked IRC and Twitter for help...

For reference, this is what we have now. Too "graphical"

Those are the standard Font Awesome icons, but there isn't one for date sorting

[deMattin]

I found following issue: If you switched sorting and then change folder, the button remains in switched state but sorting order is reset to default.

I think, best behaviour for the buttons and (manual) switching will be: If you switch sorting, this sorting will be set on every folder you walk through during the gallery+ session - also ignoring all different settings in config file! Manual settings in actual session should always overwrite presets, because you have a reason to do so.

[oparoz]

Thanks for the report. I think you're right. something was left behind...

I don't think we can override the config settings or it will be a pain to reset it for people who were just looking for something in one folder. One more reason to have a sorting panel, with lots of options. That way people can configure it the way they want.

[deMattin]

Ok, I see - you would have to save "clicked" event to decide, if the sorting has been manually set. Would be more complicated as I thought first ...

And thanks for the fix - resetting sort order now works as expected.

[deMattin]

I'm very interested in merging this into master. So I created some ownCloud style icons for calendar sorting with fitting name icons:

I would suggest to remove the 3D effect shadow and give the active icon simple a darker (and thicker) border. The not active button should have the same border (1px) as other icons in ownCloud.

Please have a look at my fork of gallery+: https://github.com/deMattin/galleryplus I have messed a bit with my branches and so merged all in master there.

Maybe the active border should be made thicker (2-3px). I'll test this later. Because everything in ownCloud is positioned with spacings and paddings and not alignment, it's really fun to change something ... ;)

One next step could be, to replace the "Teilen" text button with the share icon of ownCloud.

[deMattin]

Looks now like this:

[oparoz]

There are several issues with the icons: alignment, font, size and the button is bigger as well, so in short, it's not clean. I do think that this calendar works better though because it doesn't have the huge hinge at the top. As for the border, I think the 3D effect still looks best.

[deMattin]

Icon size: No problem - can reduce size from actual 21px to 16px (though I liked it bigger and see no issue) Font: it is a sans serif font like in "Teilen" and commplete ownCloud. What's wrong with that font? Button size: as big as the other buttons (Teilen, Info) with 32px, What's wrong? 3D button style: I didn't like the previous 3D effect because the border is too small to really see this effect. So it's not really clear, which button is active or "pressed". And second ownCloud has a flat style and 3D doesn't fit there.

Does it make sense to continue this fork or is it just waste of time?

[oparoz]

Size: The problems is that the padding needs to be the same or these buttons look more important, etc. Font: The other items are in bold. A serif font would be better, to express that this works on text, etc. Button size: It's wider Styling: Having a flat design doesn't mean that you can't have shadows. Google's new material design raises buttons which are currently active per example. The main problem is that shadows slow things down, so I'm trying to avoid them. Inverting the colour of the button doesn't work as it's too in-your-face.

You can work on your fork, trying to find a solution and maybe we'll eventually find one, but I've spent a few hours on this already and concluded that professionals should get involved if we wanted to have something which can be merged. My main problem is with the calendar icon. Once we find something which works, then it can probably be merged with the 3D effect or a lightness effect.

[oparoz]

I just want to add that I thought about using colours as well, but then it doesn't work for people who pimp theme their oC.

[deMattin]

Next try:

[deMattin]

I reworked the button borders and now it looks nice and is clean aligned (nothing jumping around) and all sizes, spacings and paddings are equal to other buttons. And it doesn't depend on fontsize any more! This way it looks very smooth and gentle but anyway you see the active selection. What do you think?

Edit:

Also the 3D inset flag is easy to set now without loosing alignment. But as I mentioned before, I don't like it much, but it is ok... And the not active sorting option should not get any styled border, I think.

[deMattin]

Now with share button:

All in master branch ... https://github.com/deMattin/galleryplus

[oparoz]

Thanks. I don't know why the share button was never put in place, so I've just pushed a change to master to set it like the other ones.

Regarding the borders, I'm not sold on the thick border. I don't think it's used anywhere else either. But that's not that important. It can be decided at the last minute.

You're going through the same route I took when testing icons and it's still not working. Spacing between elements is wrong and we can't see it's a calendar. It looks like a building when it's squeezed like that. I had the same problem with the icon I used. It gave me an idea though and I'll try something these coming days, but I'm not sure it's going to work. These icons look too busy compared to the simplicity of the other ones.

[bill340]

Using the latest master, I still don't see any of the new buttons. Any suggestions?