Discussion :

[ryan]

Yop!

Sous ce titre en forme de boutade se cache un vrai problème: Je travaille sur un site où il y a un champ texte dans lequel l'internaute peut entrer les premières lettres de la ville de France qu'il recherche. La recherche commence à la troisième lettre.

J'utilise AJAX pour interroger une base de données qui contient les 36000 et quelques communes de France. Par exemple, en entrant "mar", l'internaute verra une liste qui commence par Marac et finit par Marzy. S'il ajoute un "s", la liste se rétrécit, de Mars (07320) à Marssac-sur-Tarn. S'il ajoute encore un "e", la liste se rétécit encore, de Marseillan à Marseillette.

Où ça se complique, c'est quand je rentre "sai" pour chercher, disons, Saint-Etienne. Le script plante lamentablement avec un message de time-out, on peut le comprendre: il y a 4292 communes françaises qui commencent par "sai', en raison des nombreux Saint-machin et Sainte-trucmuche (4232 selon ma base de données).

C'est donc un réel problème d'ergonomie qui se pose à moi. Vous feriez comment pour garder cette façon de rechercher une ville sans tomber dans le piège des 4292 saints et saintes?

[Spartacusply]

Limiter le nombre de résultat à une dizaine, tout en lui indiquant (avec 3 petits points ou un truc comme ça...) qu'il y a d'autres résultats que ceux actuellement affichés. Afficher 4000 communes d'un coup à l'utilisateur n'a aucun sens.

[ryan]

Yop!

Limiter les résultats, certes, mais si la commune recherchée par l'utilisateur n'est pas dans les x premiers, il ne la verra pas et la recherche perd tout son sens.

Ou alors, il faut introduire un système de pagination, mais paginer 4000 lignes, ce n'est pas ergonomique (mais si ça évite de planter le script, c'est déjà ça...)

Je vais voir sur le forum AJAX si quelqu'un a déjà eu ce problème.

[BakSh0]

Je rejoins l'avis de limiter la recherche, d'une part pour la rapidité d’exécution de la recherche et de rendre l'ordre d'affichage par pertinence, d'autre part visuellement l'utilisateur n'est pas submerger par des résultats inintéressant.

Et plus l'utilisateur tapera de lettre plus il s'approchera de la réelle pertinence du mot recherché, il trouvera donc forcément sa réponse.

[ryan]

Yop!

Vous avez raison, limiter la recherche est la seule solution. J'ai introduit une limite dans le query, pour n'afficher que 100 lignes, ce qui est acceptable en temps de réponse, et qui est suffisamment long que pour décourager l'internaute de tout lire et l'encourager à introduire plus de lettres pour affiner sa recherche.

Merci de m'avoir indiqué la bonne direction.

Edit: l'orthographe, nom di dju!

[Pierre Maurette]

Bonjour,
Je déterre le sujet, je viens de travailler dessus, ce n'est d'ailleurs pas encore abouti.
Je me base sur un choix dans une liste de slugs, tous les lieux commencent par 'saint-' ou 'sainte-' (plus trois îles en 'st-').
L'ergonomie souhaitée: rien ne se passe avant que le troisième caractère ne soit entré. Quand l'entrée commence par 'sai', 'sain', 'saint', ainsi que le cas particulier 'st', les propositions 'saint-' et 'sainte-' apparaissent en tête de liste et en couleur. Quand l'entrée commence par 'saint-' ou 'sainte-', on laisse à nouveau passer deux caractères.
Essais visibles ici et ici.
A faire:
- La casse et les accents, pas compliqué à réaliser sur le canevas actuel, il faut juste décider. Ne pas oublier qu'il ne s'agit que de choisir dans une liste, l'utilisateur devrait comprendre sans douleur les contraintes de cette liste.
- On occulte pour l'instant quelques éventuelles communes en deux lettres (pas encore fait de recherche) et en deux lettres précédées de 'saint-' ou 'sainte-' ('saint-lo'). Se traitera sans via une liste en dur.
- Traiter les entrées 'st ', voire 'st-...', ces dernières pouvant apparaître en cas de frappe rapide. Test du singe impératif.

Pour ce qui concerne le flux des données: la réactivité peut dépendre du serveur, ainsi que du navigateur. Sur 1&1 (et mon serveur domestique) le réveil de la base de données est assez coûteux. IE semble avoir un peu de mal avec les gros tableaux en mémoire. Je m'orienterais plutôt vers la solution du lien 2, améliorée. L'idée est que le chargement de la liste se passera certainement après celui de la page, sur un temps mort. Pour l'instant c'est un tableau plat (json - ajax), demandé à la base de données. C'est idiot, ça doit au moins être préparé coté serveur. La liste des slugs avec un caractère de séparation occupe ~460ko. Ça se compresse très fort (logique). Je voudrais donc essayer de faire un transfert la chaîne avec séparateurs compressée suivi d'un split() à l'arrivée. J'ai eu des soucis avec IE en particulier en mettant la chaîne dans le JS de la page, sous la forme liste = 'pierre|zorglub|maurette'.split('|'); et puis je répète, c'est plutôt plus ergonomique de charger la page puis ensuite la liste.

Bonne journée