Cet article a pour but de spécifier les évolutions sur le moteur de recherche.

La branche 1.4 a vu naître un moteur de recherche complètement nouveau aux possibilités largement supérieures à celles de la branche 1.3. Un formulaire plus complet permet d'effectuer une recherche en fonction d'une date de début et d'une date de fin, dans un ensemble de catégories, selon un auteurs, etc.

Les nombreuses nouveautés fonctionnelles sur le moteur de recherche de la branche 1.4 ont également mis en évidence certaines limitations. Le mode de passage de la chaîne de recherche par URL a fait l'objet d'une recherche et de quelques tests simple par le développeur. Cependant, passer des chaînes de caractères complexes via l'URL, n'est pas la bonne méthode.

Les entrées de l'outil de suivi de bogues aident à comprendre pourquoi :

• bug 101 : montre que certains caractères utilisés pour séparer les champs de recherche ne sont pas utilisables partout. C'est le cas du caractère ”;”. Le développeur (pierrick) aurait dû lire les RFC. Maintenant qu'il l'a fait, il se rend compte qu'il y a trop de limitations à cette méthode. Ce bug a pu être résolu en utilisant un caractère plus simple, le ”-” et en le doublant.

• bug 104 ”# caracter in search engine” : montre qu'à partir d'un certain moment, le passage par URL arrive à ses limites. Pierrick a d'ailleurs indiqué que ce bug ne trouvera pas sa solution avec le moteur de recherche actuel. Il faudra attendre la branche 1.5

Ergonomiquement parlant, le formulaire s'est complexifié pour ceux qui aimaient la simplicité des branches précédentes. Il est au contraire limité pour ceux qui savent que le moteur de recherche a plus de possibilité que l'interface ne le permet. Un débat assez long a eu lieu l'été dernier entre Pierrick et Gweltas pour optimiser le formulaire, il fallait faire à la fois simple, puissant, et proche de ce que les autres applications proposaient.

En branche 1.4, il n'existe pas de moteur de recherche dans les commentaires utilisateurs.

Lorsque l'on navigue sur des pages issues d'une recherche, sans lire l'URL, il est impossible de savoir quels sont les critères de recherche.

En terme d'ergonomie, il est difficile de répondre à la fois à ceux qui demandent de la simplicité et à ceux qui demandent un maximum de souplesse. Même si le formulaire actuel doit satisfaire 80% des utilisateurs, il en reste 20%. La proposition est la suivante : multiplier par 3 les formulaires de recherche.

1. formulaire simple : comme en branche 1.3, un seul champ texte permet de lancer une recherche sur les informations les plus courantes des images (auteur, nom de fichier, titre, descripion, mots-clef)
2. formulaire standard : il s'agit du formulaire par défaut de la branche 1.4.
3. formulaire avancé : un formulaire plus complet permettant d'exploiter au mieux les possibilités offertes par le moteur. Un frontend à la hauteur du backend. Ce formulaire sera destiné aux utilisateurs avancés puisqu'il proposera davantage de champs à remplir.

En haut de la page de recherche, l'utilisateur pourra passer d'un formulaire à un autre par simple lien. A priori le formulaire standard sera celui proposé par défaut.

Soumettre une date n'est pas simple, il serait bon de proposer une aide au formulaire. Voir blog sur onpk.net

En branche 1.4, les règles de recherche existaient sous forme de chaîne de caractères. Cette chaîne de caractères utilisait plusieurs caractères séparateurs comme le tilde ”~”, le tube “|”, la virgule ”,”, le point-virgule ”;” ou encore les deux-points ”:”. Exemple :

file:554,555~OR--cat:4,5,6~sub_inc--date_available-after:2004-5-2~inc|AND

Malgré l'aspect lisibilité appréciable, cette méthode de stockage montre rapidement ses limites et ses incompatibilités avec les navigateurs. Il est par ailleurs difficile de respecter les RFC et d'utiliser des séparateurs…

Au niveau du code PHP, les règles de recherche existent sous forme d'un tableau multidimensionnel.

Array
(
    [mode] => AND
    [fields] => Array
        (
            [file] => Array
                (
                    [mode] => AND
                    [words] => Array
                        (
                            [0] => 554
                            [1] => 555
                        )
                )
            [cat] => Array
                (
                    [mode] => sub_inc
                    [words] => Array
                        (
                            [0] => 4
                            [1] => 5
                            [2] => 6
                        )
                )
            [date_available-after] => Array
                (
                    [mode] => inc
                    [words] => Array
                        (
                            [0] => 2004-5-2
                        )
                )
        )
)

L'exemple ci-dessus est volontairement simple, les recherches peuvent être bien plus complexes que cela.

Ce tableau est créé par la page search.php lorsqu'on traite les données d'un des formulaires de recherche (par POST) ou qu'on demande une recherche triviale (par GET).

search.php?author=pierrick&date_available-after:2004-5-2~inc

Les alias de type “allwords” (équivalent à file ou name ou comment ou keywords ou author) de la branche 1.4 n'existeront pas dans les règles de recherche, mais uniquement au niveau logique pour simplifier le code si nécessaire.

Les règles de recherches doivent être sauvegardé, même si leur utilisation peut ne pas dépasser la minute.

La table “search” s'acquitera de la tâche :

CREATE TABLE phpwebgallery_search (
  id int UNSIGNED NOT NULL AUTO_INCREMENT,
  last_seen date DEFAULT NULL,
  rules text,
  PRIMARY KEY  (id)
);

La colonne id est l'identifiant numérique auto-incrémenté, facile à manipuler. La colonne rules contient le tableau de règles, sous sa forme sérialisée. La colonne last_seen informe sur quand la recherche a été utilisée (pour prévoir un mécanisme de purge).

search.php se charge de l'insertion, une page de maintenance dans l'administration proposera de purger la table.

Plutôt que de passer une longue chaîne complexe (mais lisible) dans l'URL, on ne passe que l'identifiant numérique de la recherche. Ainsi, la recherche évoluée proposera “simplement”

category.php?cat=search&search=874954

Ce mode passage rendra plus simple la réécriture d'URL pour avoir de jolies URL du type http://site/galerie/category.php/search/7845 (fonctionnalité en cours de réflexion).

Alors qu'en branche 1.4, on peut encore se raccrocher à l'URL pour savoir quelles sont les règles de recherche, la recherche évoluée n'a plus rien à proposer. Il faut donc prévoir l'affichage des règles.

Les règles de recherches s'affichent dans une “boîte” (ou alors dans une popup, point à discuter) au survol d'un icône du type . Cet icône sera placé à côté du titre de la catégorie : “Recherche” en l'occurence.

Le stockage en base des règles de recherche ouvre de nouvelles possibilités. Par exemple, la réutilisation des recherches. Concrètement, un utilisateur peut accéder à sa liste de précédentes recherches et les relancer (avec des résultats différents si la galerie a changé évidemment).

Une nouvelle page de gestion des recherches utilisateur doit être accessible depuis la page de recherche. Cette page propose une liste de recherches passées appartenant à l'utilisateur connecté (champ search.user_id) avec la date de la création de la recherche et la description des règles de recherches. L'utilisateur peut alors :

• relancer la recherche
• modifier la recherche, ce qui l'emmène vers le formulaire de recherche pré-rempli
• supprimer la recherche

Pour aller plus loin, on pourrait donner la possibilité à chaque utilisateur de rendre publiques ses recherches (champ search.public à true/false). Ainsi depuis l'écran de gestion des catégories, il serait possible de voir ses recherches en particulier et les recherches publiques.

• initialement prévue pour la branche 1.5
• reportée à la branche 1.6 par manque de temps
• [2006.01.20] nouveau backend développé. Voir r1008 dans Subversion.
• [2006.01.27] affichage des règles de recherche, développé. Voir r1015 dans Subversion.