Odd (to me) search behavior

I have a gallery with four levels of subalbums. I have tagged the lowest level albums using (at the moment) just a couple of tags. Two of the lowest-level albums have one tag, and one lowest-level album has another. My default search options are just "title", "tag", and not to return images, but to return albums.

When I begin my search from the highest (gallery, or "index") level, everything works great.

If I descend even one level (into one of the high-level albums of the gallery), the same search fails -- even though all the search targets are below that level in the album tree.

Is this expected behavior? If not, what am I missing? Is it not possible to search WITHIN an album (at whatever level in the hierarchy the album resides)?

Comments

  • acrylian Administrator, Developer
    Hard to say without knowing the theme. Some themes limit the search on the album page their child albums. So if you are below a level it will only search the childs. Just looked quickly and I think the basic and the Zenpage theme do this.
  • I'm using the Zenpage theme.

    I'm not sure what mean by "limit the search on the album page their child albums" If you mean that they limit the search TO the children of the album being viewed, then the searches I'm running should work.

    The hierarchy in question is:

    index >> Members Only >> Digital Music Library >> All Works >> The Stars and Stripes Forever

    All of these are albums (including the last)

    If I view the index page in my Zenphoto browser and do a tag search for 'Sousa', the result is the 'The Stars and Stripes Forever' album. This is correct.

    If I then descend to the album 'Members Only' so that the navigation path is

    index >> Members Only

    and do the same search, the result is "Sorry, no matches found. Try refining your search."

    This doesn't seem to make sense since I'm searching from a level that is still an ancestor of the album it should find, and just one level below an album where it successfully found that target.

    Any idea how I might try to diagnose this? It makes it appear as though the search capability is working on when invoked at the highest level of the album tree. The same thing happens when the search is done on the basis of Title rather than Tags. So it doesn't appear to be Tags-specific. Maybe a bug?
  • acrylian Administrator, Developer
    Sorry, typed too fast. No bug, just as coded in Zenpage, basic and eff+ for ages. I seriously don't remember why actually… See Zenpage theme's `album.php` and find:
    `printSearchForm(NULL, 'search', gettext('Search within album'), gettext('Search'), NULL, NULL, $album_list);`
    and change it to:
    `printSearchForm("", "search", "", gettext("Search gallery"));`
    http://www.zenphoto.org/documentation/functions/_template-functions.php.html#functionprintSearchForm
  • Thanks much. That "feature" is pretty goofy.

    For reasons I won't go into, I've been trying to get this done without changing any source. But this is a behavior that I think is just too nutty to be tolerated. I'm inclined to regard it as a bug even if that code was intended :-) -- if for no other reason than that it appears to be incompatible with more general statements about the search algorithms and behavior (such as "search within" for returned results). Whatever.

    I'll take a look and do some experimentation. Thanks again. Saved me a lot of time.
  • Hmm.. the Garland theme does the same thing. Going to have a looksie. In this theme, change sidebar.php:

    `
    if (getOption('Allow_search')) {
    switch ($_zp_gallery_page) {
    case 'album.php':
    case 'image.php':
    $list = array('albums' => array($_zp_current_album->name), 'pages' => '0', 'news' => '0');
    $text = gettext('Search within album');
    break;
    case 'gallery.php':
    $list = array('albums' => '1', 'pages' => '0', 'news' => '0');
    $text = gettext('Search albums');
    break;
    `
    To:
    `
    if (getOption('Allow_search')) {
    switch ($_zp_gallery_page) {
    case 'image.php':
    $list = array('albums' => array($_zp_current_album->name), 'pages' => '0', 'news' => '0');
    $text = gettext('Search within album');
    break;
    case 'gallery.php':
    case 'album.php':
    $list = array('albums' => '1', 'pages' => '0', 'news' => '0');
    $text = gettext('Search albums');
    break;
    `
    Guess it depends how you want it to behave based on what you are looking at.
  • Well, I think the most reasonable expectation is that you're searching FROM a given tree node "downwards" in it and its immediate and indirect descendants. In that case, if a search from a level n node N returns a hit h in nodes below level n (n+1, n+2, ...), then the same search from each node N' at level n+1 should return h if and only if h occurs at N' or any descendant of N'. (Sorry if that's confusing, but without some formal notation it's difficult to express clearly in this space.) It seems really difficult to justify anything else.

    The alternative is what I'm seeing: I do a search at level n+j and get a null result. I go up level n (the index in this case) and get a hit for nodes at level(s) n+k where k <= j. It's like, the closer I get, the less I can find. Not quite true since the search seems to be successful ONLY at the topmost node (i.e., a topmost album in the Gallery).

    Or so it seems to me :-). I guess it might be enlightening to see an English translation of that PHP code since I think it would turn out to be pretty odd and unintuitive. The result, however, certainly seems to be just wrong.

    I confess that I don't speak PHP and haven't looked at the code surrounding those snippets you provided, but just from almost total ignorance of the language it appears that the first snippet -- for search purposes -- is treating albums the same as images. This is really odd considering that albums are containers (and in fact containers of images), and images are not containers. So it is "natural" to search in albums (containers) but not in images (since there's nothing in an image to search -- in the relevant sense). Maybe this really is a bug and whoever coded it just put the album case in the wrong place???
  • acrylian Administrator, Developer
    Actually what the code does is search in the current album's childs.

    @MarkRH: Indeed Garland does it as well. IMHO that indeed should be changed to be always a global search by default.

    Zenphoto also has an option to search within the current search results but that is something different.

    Generally themes are suggestions to be used or modified if not fitting.
    So it is "natural" to search in albums (containers) but not in images (since there's nothing in an image to search -- in the relevant sense).

    Albums are folder and images are wihtin. You don't search "in" you search "for". For things like filenames, titles, tags etc. So there is plenty relevant to search for with images.
  • Okay, I acknowledge your search-in/search-for distinction. That makes the current behavior seem even more deviant.

    In fact, at the implementation level, searching-for involves searching-in. More generally, a search is always within some context, and the structure of that context (list, tree, DAG, hash table, data base, etc.) bounds and governs the nature of the search and the methodology used. One can choose to ignore that structure and always search "everything" (treating the structure as an unordered set, for example), in general this approach won't be what users expect or what the application should implement. I think you agree with this.

    There is a hierarchical relation (abstractly among Gallery/Album/Subalbum/Image, and concretely at the implementation level among Directory/Subdirectory/File), and this permeates the Zenphoto design and implementation. For example, in the admin Search page, you can constrain the search not to return album matches or image matches. But this is all somewhat pedantic. Zenphoto itself can be considered as a high-level data structure (built on more fundamental ones), and perhaps construed in that way some of its more esoteric properties were never formalized at the design stage.

    However, always doing a Gallery-wide global search (when searching from any album or subalbum, no matter where it is in the hierarchy) would surely be regarded as bizarre by most, if not all, users. Users want to be able to search clearly identifiable portions of the content, and to do so on the basis of how the content and its organization is represented in the interface. I'm pretty sure you agree with this as well. The current behavior appears to violate this. There's nothing wrong in supporting fully global search from any location, but I think that should not be the only option. I also think it should not be the default, but there's room for argument there.

    In fact, your last remark is exactly to the point. I am searching FOR images (or in some cases FOR albums, and more generally FOR "things") that have certain monadic properties. But if I search "from" two different places that should yield identical results, the results are not identical. And the measure of how unintuitive and unexpected this is that it required examining the code to see what was being done and whether there is some way of justifying that. There doesn't seem to be.

    (Aside: This could be regarded as an interface issue (though I'm not inclined to do so). The appearance of a search box and button ON a page says -- intuitively, to the user -- search for what I'm going to specify WITHIN what I'm seeing displayed on the current page. If you would want to make the search always global across the Gallery (which I REALLY don't like), then you should either remove the search box/button from the page (and move it to some "tools" area -- which has its own problems), or at the very least change the label from "search" to "gallery search" or something like that. Just some thoughts. I don't recommend it.)

    In any event, thanks very much for the effort you've put into this and for your explanations. A very interesting discussion, and informative to me. Whatever Zenphoto decides to do about it (or not), it points me in the direction of how to (from my perspective) "fix" it in accord with my own requirements.
  • Let's back up here.

    While the code may be INTENDED to search in the current album's children, it in fact is NOT doing this. The parent/child hierarchy of ALBUMS I have is

    Index -> Members Only -> Digital Music Library -> All Works

    Then within All Works, I have child albums of

    First Suite for Military Band (Tags: NONE)
    Second Suite for Military Band (Tags: NONE)
    The Stars and Stripes Forever (Tags: march, Sousa)

    The Stars and Stripes Forever has tags 'march' and 'Sousa'. Search options are 'Tags' and 'Title'.

    If from the Index page I use the 'Search gallery' button to search for 'march' or for 'Sousa' I get one hit, and it is The Stars and Stripes Forever. This is correct. It indicates that the hierarchy of albums at and below Index is being searched. Very likely, it seems, 'Search gallery' means "search the entire gallery without regard to its structure". This makes sense.

    If I then navigate to the Members Only page and search for 'march' or 'Sousa', I get "Sorry, no matches found. Try refining your search."

    If I navigate to the All Works album page, I get the same result -- even though its child Stars and Stripes Forever is tagged with both 'march', and 'Sousa'. This indicates that 'Search' is NOT searching in the current album's children.

    I get the same results in searching for Title.

    What am I missing here? The only searching that appears to be working is the "global" search of 'Search gallery'.

    I'm not attempting to be argumentative. But the behavior does not seem to be consistent with what you say it should. What am I missing?
  • acrylian Administrator, Developer
    Sorry, I think I was wrong above as the code seems to search only in the current album and not the childs at all (unless I misread the code again quickly).

    There is also a option to search within search results or the search cache might.

    Regardless, we internally already more or less agreed to modify the official themes to always search globally. This is probably the general expectation anyway.
  • Well, you have something of an interface problem remaining: concerning how you are naming your search buttons.

    Currently the button for the Index/Gallery level search says "Search gallery". Very clear.

    If you do a search and get hits, then on the hits page the search button ALSO says "Search gallery" -- independent of whether you have set the "Default search" to be New or Within. This is at least apparently inconsistent with the documentation which says that in the second case "the search will be from within the results of the previous search".

    Now I will grant you that given how you are now planning on making ALL searches global, then it turns out (as an artifact of this implementation decision) that the practical effect is the same: you ALWAYS do a global search. I see this as an unfortunate conflation of implementation with design, and bending the design to conform to an easy implementation that's been chosen. But I won't argue about that. Note however, that in order to get certain clearly desirable search effects, one has to be quite careful with tagging and the choice of tags, and the number of tags will necessarily increase compared to an environment where relative search is done. (I omit the details of why this is so, but I'm sure people familiar with tag-based search in complex data structures will see the point.)

    The "all searches are global approach" continues to give rise to some confusion because if you NAVIGATE into an album below the Index/Gallery level, the search button says simply "Search" and NOT "Search gallery". This seems a clear indication that at some point, designers intended there to be a non-global search going on at the subalbum level -- and a distinction between gallery search and local search. Certainly it appears this way. So I'd argue that it is not "the general expectation" to "always search globally". But this is your decision.

    In any event, I would strongly urge you to make all of your search buttons say "Search gallery" in order to avoid confusion among users since this is now the action the buttons will have.

    The alternative would be to make all of your buttons say simply "Search" and document that this always means "Search gallery", but from a UI perspective it's better for the button to more clearly indicate what its action is. However, in any event, I strongly recommend that you don't use two buttons which say different things but have the same action. Just based on my own UI design experience.

    Thanks again for taking the time with this and thinking about it.
  • acrylian Administrator, Developer
    The button should indeed then be named "search" and not "search gallery" because it also covers Zenpage pages and news if you have enabled them. "Gallery" however is the internal term for the whole Zenphoto site including optional pages and news.

    A search within will only happen if the option is enabled on the backend.

    Most official themes are old and probably will not stay with us forever anymore.
Sign In or Register to comment.