restructuring of media filters

Discussion corner for Developers of Serendipity.
User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

restructuring of media filters

Post by Timbalu » Wed Oct 21, 2015 3:08 pm

I would like to make the media library filters a little more use- and understandable for the users.

Having a look to the full filter screen, we have 17 items, right?
The array $media.sort_order delivers 15 items, which are of two differing sorts:

Code: Select all

Array
(
    [i.date] => Array
        (
            [desc] => Upload-Datum
            [type] => date
        )

    [i.name] => Array
        (
            [desc] => Dateiname
        )

    [i.authorid] => Array
        (
            [desc] => Autor
            [type] => authors
        )

    [i.extension] => Array
        (
            [desc] => Dateiendung
        )

    [i.size] => Array
        (
            [desc] => Dateigröße
            [type] => intrange
        )

    [i.dimensions_width] => Array
        (
            [desc] => Bildbreite
            [type] => intrange
        )

    [i.dimensions_height] => Array
        (
            [desc] => Bildhöhe
            [type] => intrange
        )

    [bp.DPI] => Array
        (
            [desc] => DPI
            [type] => int
        )

    [bp.RUN_LENGTH] => Array
        (
            [desc] => Laufzeit
            [type] => intrange
        )

    [bp.DATE] => Array
        (
            [desc] => Verknüpftes Datum
            [type] => date
        )

    [bp.COPYRIGHT] => Array
        (
            [desc] => Copyright
        )

    [bp.TITLE] => Array
        (
            [desc] => Titel
        )

    [bp.COMMENT1] => Array
        (
            [desc] => Kurzer Kommentar
        )

    [bp.COMMENT2] => Array
        (
            [desc] => Langer Kommentar
        )

    [bp.ALT] => Array
        (
            [desc] => Bildinhalt (Zusammenfassung für das ALT-Attribut)
        )

)
These are 7 i.items and 8 bp.items. The i.items are image properties (i), the bp.items are mediaproperties base_properties (bp).

The labels are set via <label for="serendipity_filter_{$filter@key}">{$filter.desc}</label>.
As you can see by yourself, there are some, which do not show up as a name + (bp.desc) in parenthesis.
This is, while the code only sets those as fieldset span information headers, if of type "date" or "intrange". This makes the full filter item types not really good to understand and seperated from each other. Its OK if you think its all-in-one. But as far as I think it works, the bp.items are only available if being exemplarily set by user per item. And what happens if you start mixing them...?

Keep this in mind and let us find some other related questions:

If you look to the filter collapsible box en detail, you'll see "Dateiname" is shown twice. The first is the i.name (see array), the second is hardcoded (not array deflated) to the media_pane.tpl as

Code: Select all

                <div id="media_filter_file" class="form_field left">
                    <label for="serendipity_only_filename">{$CONST.SORT_ORDER_NAME}</label>
                    <input id="serendipity_only_filename" name="serendipity[only_filename]" type="text" value="{$media.only_filename|escape}">
                </div>
at the bottom of the array loop deflation. They have different input names too and both seem to work searching a filename.

This is followed by another hardcoded filter, which is media keywords:

Code: Select all

                <div id="media_filter_keywords" class="form_field center">
                    <label for="keyword_input">{$CONST.MEDIA_KEYWORDS}</label>
                    <input id="keyword_input" name="serendipity[keywords]" type="text" value="{$media.keywords_selected|escape}">
                </div>
Now,
  • Are these two extraParems a rest of some old or some 2.0-dev smartifying coding state?
  • Was that perhaps meant as an approach for the simplified filter simple filter option? (Simple filter btw currently delivers i.date and i.name and the 2 hardcoded items)
  • Is there maybe a (plugin?) filter state where these two hardcoded items are the only items showing up?
  • Why is or was "media keywords" not placed in the sort_order (bp?) array?
  • The hardcoded "Dateiname" is based to only_filename, which is set and added to the $parems array by

    Code: Select all

    function serendipity_generateImageSelectorParems($format = 'url') {
        ....
        $standaloneFilterParams = array('only_path', 'only_filename');
    and latterly added to the $media full array. What are both array items for? (Originally meant and currently used?) (*)
  • In full filter view, you can't really distinguish between i.items and bp.items, per extending option or per design?! (I think it would be nice to have at least one of this!)
  • Having cleared this, how can we seperate i.* from bp.*, or make the media items better readable.
Thanks for any helping contribution.

PS. Btw the Personal Preferences simple filter option talks about having influence to entries too. This is not true, IMHO, except that it enables the checks for delete. We should change that in this case.

(*) It is easy to just disable the hardcoded "only_filename" in media_pane.tpl, but I am not that sure what all these related backend core code does. So its better to clear the upper questions first in detail to make it right.

To make this section even more featuresk, I would like to have a simple reset button for the filters. (By javascript for the best. But I still need some more ideas on how to do this in this case. [Solved])
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
yellowled
Regular
Posts: 6990
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: restructuring of media filters

Post by yellowled » Fri Oct 23, 2015 6:55 pm

I'm sure it's not what you would prefer or intend to do here, and I'm even more sure Garvin's going to have to say something about power users in this context, but I believe the majority of our users does not need or use … I'm going to guess at least 80% or the filters available.

I, for one, have never used media DB filters for date, size or DPI. In what context does that even make sense? „Show me all media that I uploaded between September 2013 and October 2014“? Who does that and what for?

I don't think we should remove those filters, and if you really want to invest time in developing this, you're of course welcome to do so, but I don't think it's worth the effort. Just my 2 cents, of course.

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: restructuring of media filters

Post by Timbalu » Fri Oct 23, 2015 8:25 pm

I moved that to the forum, while Garvin wanted to answer here.

Well, the thing is, that I invested much time to make the ML experience a little worthier for 2.1 and found so many code to touch, that investigating a little more does not care.

We always had this full featured filter and I am sure it was made to be able to filter as much as possible, for whom ever. I never used that before very often myself. This is Serendipity: it has overall hidden, open, or historical features, that the majority would not need to run a simple blog.

And now, after the directory structure of uploads can be used for better latterly structuring, it may be even more an "overhead".

But since we already have it, it would be nice to get it nicly working and understandable. One example - apart from filter structures - is its cookie section, which is "unfinished" and has bugs.

When the answers (one day) bring up the opinion to remove half of them, I am happy too. :)
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
garvinhicking
Core Developer
Posts: 30014
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: restructuring of media filters

Post by garvinhicking » Mon Oct 26, 2015 1:02 pm

Hi!

The code is so far away in my mind, I can't really answer without diving deeper into this. But I must admit I don't really understand the problem(s) yet, both verbally and conceptually.

We have i.* and bp.* differences because those adress two tables, but I don't understand why this is a problem.

Maybe we can adress one issue at the time, and then some others might resolve themselve. What would be a SINGLE issue that I could address first, and which might clear things up?

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: restructuring of media filters

Post by Timbalu » Tue Oct 27, 2015 10:37 am

garvinhicking wrote:What would be a SINGLE issue that I could address first, and which might clear things up?
Ok, lets see... We have the doubled filename field issue.

To decide which one to prefer and to keep, and which one to remove (or disable or workaround), I need to know in detail the historic reasons of their existence and appearance. (This decision might influence a later decision about restructuring the all filters, though.)

Why do we have 2 of the same, array filter i.name AND an extra defined only_filename var?

https://github.com/s9y/Serendipity/sear ... y_filename (Note: Does not show all occurences in shown files)

They are the issue for the doubled filename filter input.

The only difference I could find, is that 'only_filename' is queried for the realname table field too and has this str_replace thing, for a partitial search I assume. Maybe this gives you a hint to remember.

I would like to remove (or concentrate on) one of them.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
garvinhicking
Core Developer
Posts: 30014
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: restructuring of media filters

Post by garvinhicking » Tue Oct 27, 2015 11:03 am

Hi!

The "i.name" input field was never meant to contain a filterable input string, it was meant as an array key to use for SORTING only. The "only_filename" input field was the only one meant to search for actual images. I guess at some point this got confused.

So I'd suggest that we should drop the "i.name" input field and keep the "only_filename" one!

Best regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: restructuring of media filters

Post by Timbalu » Tue Oct 27, 2015 11:17 am

Seems plausible. I have a 1.6.1 here, where this is already the same. It only differs by appearance.
Thanks. This was my intention too. I'll come up with other related questions after solving this.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
garvinhicking
Core Developer
Posts: 30014
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: restructuring of media filters

Post by garvinhicking » Tue Oct 27, 2015 11:45 am

Timbalu wrote:Seems plausible. I have a 1.6.1 here, where this is already the same. It only differs by appearance.
Thanks. This was my intention too. I'll come up with other related questions after solving this.
Yeah, I dug through the sources; this mistake must have been issued quite early, possibly even by me and I didn't really notice. So it's good to clean up that mess, thanks!
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: restructuring of media filters

Post by Timbalu » Wed Oct 28, 2015 5:38 pm

Another small minor question:
What is meant by bp.RUN_LENGTH, which you can search for as something being a "from" - "to" intrange (not a date) and is not something being set in the media properties by the user?
I have no real clue what this is about. "Laufzeit" of what? I assume it is meant as something for video runtime or so, to search a video which has a run length "00:50:00.00" to "00:60:00.00" for example. Is this true? And, who really would know this? :)
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
garvinhicking
Core Developer
Posts: 30014
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: restructuring of media filters

Post by garvinhicking » Thu Oct 29, 2015 3:51 pm

RUN_LENGTH is the runtime in minutes for video and audio files.
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: restructuring of media filters

Post by Timbalu » Thu Oct 29, 2015 7:53 pm

Would you mind giving me a working example, please?! :)
I still seem to not understand this search.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
garvinhicking
Core Developer
Posts: 30014
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: restructuring of media filters

Post by garvinhicking » Fri Oct 30, 2015 10:38 am

Hi!

If you upload two videos, one with 2 Minutes and one with 7 Minutes, and you want to find videos in your library with a runtime below 7 minutes, you enter "1" in the one field and "7" in the other.

I now only see that this "Sortieren nach (bp.RUN_LENGTH)" is something that shouldn't be like this. It should ready something like "Sortieren nach: Laufzeit" and "sortieren nach: Bildbreite". Showing our database column keys to the user is really nasty...
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: restructuring of media filters

Post by Timbalu » Fri Oct 30, 2015 5:18 pm

Yes that was my first impression when I saw this full filter Box. And being extremly unclear and in need for clarification or restructuring. We then did something about it, which fixed the grid and the lines.

Btw S9y 1.6.1 was
DPI
Copyright
Title
Short Comment
Long Comment


While S9y 1.7 series added
Laufzeit
Verknüpftes Datum
Bildinhalt (Zusammenfassung für das ALT-Attribut)
I'll changed and committed the missing/wrong key names.

Back to the Laufzeit: I now discovered how to use it. It has to be set by mediaproperties before. I still have issues targeting that file, but now I know it definitely is a base_mediaPROPERTY. (I don't have videos to test this, so i tried with audio.) This btw is a good example of what I meant before. All these bp fields are of only use, if you have already added baseproperties to some ML items, via the item property form. This should be known or clarified to the user by design or so.

I have an idea on how to restructure/design this with a little CSS. I'll show that later.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: restructuring of media filters

Post by Timbalu » Sat Oct 31, 2015 2:37 pm

Run_length seems to store an audio file with example runtime 00:03:57.00 as 237 by serendipity_mediaTypeCast(), I assume. Now a filter search "Laufzeit" "from 1 to 240" will really get that file. That is a something a normal user can't know or assume, can he? Is that DB-stored value 237 now a result of a wrong conversion, or is it meant to be like this? Its not what you said it should do, since this would mean to search from 1 to 4, wouldn't it?!

Edit: Well the 237 num is totally ok, since it is 3 min x 60 sec + 57 sec and we need to have a valuable stored format, which is seconds. I now think the filter search is missing a reconversion to be usable, which is 3rd param "invert" set to true. But what I still don't get is, that in case a search 1 to 5 (minutes) is a valid approach, the search sh/would be advised to only use minutes then...?
For example like this:

Code: Select all

 if (substr($f, 0, 3) === 'bp.') {
     $realf = substr($f, 3);
+     if ($realf == 'RUN_LENGTH') { 
+         $fval['from'] = $fval['from'] * 60;
+         $fval['to']   = $fval['to'] * 60;
+     }
     $cond['parts']['filter'] .= " AND (bp2.property = '$realf' AND bp2.value >= " . (int)$fval['from'] . " AND bp2.value <= " . (int)$fval['to'] . ")\n";

Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
garvinhicking
Core Developer
Posts: 30014
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: restructuring of media filters

Post by garvinhicking » Mon Nov 02, 2015 12:29 pm

Hi!

Well, the search is for metadata, and the metadata needs to be stored. I believe we can trust users to know that they need to enter information to search for it ;)

That the value is stored in seconds strikes me as odd... but if it's been like this, we should better use that value in the future, but add a tooltip or something like that in the input area, to instruct people that they need to enter the runlength in seconds.

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

Post Reply