[Résolu] Moteur de recherche et résultat dans la même page

Tu peux mettre un lien pour jeter un cou d'oeil ?

Merci

Non pas vraiment. Mon explication n'était pas assez claire ? Je pourrais essayer d'être plus détaillé, mais si vous insistez pour un exemple concret qui fonctionne, je pourrais toujours créer une page spéciale pour en faire la démonstration.

Tes pages Web sont confidentiels

Aussi surprenant que ca puisse l'être, en ce moment, oui.

Perso, vaut mieux faire la solution 1.

C'est mon avis qui me semble le plus accessible.

L'idéal, c'est de prevoir les deux cas de figure avec ou sans javascript. Tu peut utiliser le truc du "noscript switching" tel que je le decrit dans ce topic :
> http://forum.alsacreations.com/topic.php?fid=5&tid=618
Modifié le 01 Dec 2004 - 00:27

Finalement, le mieux ne serait-il pas de faire les 2 ?

Ton code a-t-il réellement besoin d'être caché ? On peut offrir cette fonctionnalité supplémentaires à ceux qui ont activés JavaScript, fonctionnalité qui est tout de même "confortable".

Et pour ceux qui n'ont pas activés JavaScript, eh bien ce que tu avais à cacher, ne le cache pas ! Et la fonctionnalité ne sera pas disponible donc l'utilisation moins confortable, mais ils n'en seront pas pénalisés...

Selon ton script, tu donc appliquer le "masquage" de ton formulaire en JavaScript, et ceux qui n'ont pas le JavaScript activés verront le formulaire (car non masqué).

<script type="text/javascript">
<!--
document.write('<style type="text/css">');
document.write('<!--');
document.write('.classe { display: none; } ');
document.write('--'+'>');
document.write('</style>');
-->
</script>

.classe serait la casse à appliquer à ton formulaire.

Tout compte fait, je crois que tu devrais faire comme je le dit vu que pour un simple moteur de recherche, ce n'est pas très gênant...

Et faire une page pour dire que la fonctionnalité existe est quelque peu... "ridicule" ("Activez le JS si vous voulez faire réapparaître le formulaire de recherche").

Si jamais, dis-en-nous plus

Je ne suis pas certain d'avoir compris, mais tu dois disposer d'un serveur d'application pour faire ta recherche, donc un bon If des bois autour de ton formulaire doit faire l'affaire. comme çà il n'est même plus dans le code.

Par contre si ta volonté est de le faire "ré-apparaitre" quand l'utilisateur souhaite faire une nouvelle recherche sans pour autant effacer les résultats de la recherche en cours, je me demande si le fait de mettre le formualire dans un bloc avec un switch sur display en css ne peut faire l'affaire.

En fait, comme je l'expliquais, je veux que le formulaire soit toujours disponible, sans pour autant devoir recharger la page ou changer de page. Voici de quelle façon tout ceci se passe présentement, toujours dans la même page :

1. Le formulaire de recherche est visible.
2. L'utilisateur entre ses critères et soumet le formulaire à la page en cours.
3. Dès le chargement de la page, étant donné que je sais qu'une recherche vient d'être lancée, je fais disparaître le formulaire via Javascript.
4. L'utilisateur voit les résultats.
5. L'utilisateur veut consulter/changer les critères de recherche, il clique sur Montrer et via Javascript, je fais réapparaître le formulaire. S'il veut le cacher à nouveau, il clique sur Cacher, tout simplement.

En bref, Javascript ou non, le formulaire est toujours disponible pour l'utilisateur, c'est seulement la fonction pour le faire disparaître/apparaître qui ne l'est pas si son Javascript est désactivé.

Je crois que je vais laisser tel quel, sauf peut-être en ajoutant une balise noscript pour informer l'utilisateur qu'en activant son Javascript, il pourra faire Apparaître/Disparaître le formulaire pour un meilleur confort. Un petit message discret, rien d'harcelant. Donc j'oublis le onclick sur un lien, je vais le mettre sur un autre élément. J'avous que le rediriger sur une page pour l'informer qu'il doit activer son Javascript est un peu biggol, même si j'ignore ce que ca veut dire!

Ca me semble bon, et vous ?
Modifié le 01 Dec 2004 - 14:50

Hum...

<COGITO title="Mec qui réfléchit à haute voix">

Merkel a écrit :

Par contre, je fais disparaître le formulaire via Javascript afin de laisser plus de place pour les résultats. Si l'utilisateur veut consulter ou changer ses critères de recherche, il n'a qu'à faire réapparaître le formulaire, donc pas besoin de recharger une page.

Sauf cas extrême de design totalement figé en hauteur comme en largeur (auquel cas il y a un problème à régler avant tout), il y a toujours dans une page Web une réserve inépuisable de place: la hauteur et le scroll vertical.

Ah... Mais mon utilisateur va devoir scroller pour réatteindre le formulaire, et c'est casse-pied, ça...
Mais :
- C'est moi qui n'aime pas scroller. Lui, en fait, je n'en sais rien.
- Le scrool n'est jamais que le comportement de base d'utilisation d'une page Web. Je dois pouvoir supposer que mon utilisateur maheureux en a au moins l'habitude.
- S'il y a ce javascript pour afficher le formulaire masqué, il faut de toute façon qu'il atteigne le lien qui l'active. Devine comment ?

Dans tous les cas, l'utilisateur devra chercher l'accès au formulaire et éventuellement scroller pour l'atteindre. Mais il me semble qu'il herchera plus aisément le formulaire qu'un lien qu'il faudra avoir repéré au passage. Et du point de vue accessibilité, un formulaire est plus explicite et direct qu'un lien pour y accéder: l'info qui est directement apparente est plus accessible que l'info qu'il faut chercher.

D'autre part, ça me semble difficilement séparable du nombre de résultats affichés par défaut, et de l'option offerte à l'utilisateur d'afficher des pages successives de résultats ou tous les résultats (s'il y en a des kilomètres, il assume son choix )

Enfin, en matière de formulaire dans des résultats de recherche, AMHA:
- un formulaire dupliqué avant et après la liste de résultat est encore celui auquel on aura le plus facilement accès.
- le "bon" formulaire de nouvelle recherche intègre l'option "chercher dans ces résultats" / " "faire une nouvelle recherche". Pour développer l'ergonomie de la page, je chercherais plutôt à développer cette fonctionnalité qu'à jouer à cache-cache avec le formulaire pour des raisons de gain de place

Me voilà cassé !

Laurent, suite à la lecture de ton message, que j'ai lu plus d'une fois, je dois t'accorder que tu as raison. Mon histoire de cacher le formulaire n'est pas forcément des plus ergonomiques, car comme tu le dis, d'une façon ou d'une autre, l'utilisateur devra scroller pour se rendre soi au formulaire soi au lien pour le faire afficher.

Je vais donc retirer cette fonctionnalité, comme ca, l'utilisateur verra toujours le formulaire et ses critères de recherche pour avoir obtenu la liste des résultats. Cela va prendre un peu plus de place dans la page, mais avec l'utilisation des ancres, ca devrait bien aller. Je vais mettre un ancre sur le formulaire et sur les résultats, avec des liens pour se rendre à l'un ou à l'autre.

Merci à tous ceux qui ont donné leur opinion !
Bonne journée !
Modifié le 01 Dec 2004 - 17:42

Pffft... Une controverse a priori intéressante qui s'interrompt faute de combattant. Dommage

(Blague à part, je crois vraiment que tu fais le bon choix à l'heure actuelle, surtout en utilisant les ancres que j'oublais de mentionner.)

Cela dit, pour rebondir un peu : la place d'un formulaire de recherche dans une série de documents est-elle réellement dans le document ?

A partir des métadonnées du type <link rel="...">, n'est-elle pas plutôt du ressort du navigateur ? Et donc à générer par celui-ci dans son interface ?

(Dans Opera, c'est déjà réalisable au prix d'un petit bidouillage maison des fichiers de config et d'un script qui récupère l'url du site et lance une recherche google dans celui-ci sur le texte saisi dans un formulaire placé dans la barre personnelle de l'utilisateur, ou à partir d'un mot sélectionné dans un document. On doit pouvoir aisément faire au moins l'équivalent dans FireFox sous forme d'extension.)
Modifié le 01 Dec 2004 - 18:52

Laurent Denis a écrit :

Cela dit, pour rebondir un peu : la place d'un formulaire de recherche dans une série de documents est-elle réellement dans le document ?

J'ignore si j'ai bien saisis ton rebondissement, mais je vais y aller de cette réponse :

Je dirais que oui si la recherche doit s'effectuer non pas dans le document en cours, mais dans une base de données ou plusieurs pages du site. Après tout, une application est créée pour gérer différents documents. L'utilisateur doit avoir à sa disposition un moteur de recherche directement dans l'application, et non pas dépendre du système d'exploitation ou du navigateur web sur lequel elle roule afin de bénéficier de cette fonction qui vous le savez, est parfois primordiale.

Si le moteur de recherche est aussi intégré dans le système d'exploitation ou le navigateur web, c'est tant mieux. Mais je crois que l'application en elle-même doit être indépendante du système sur laquelle est roule.

Ceci dit, mon moteur de recherche sert uniquement à rechercher des factures dans une base de données, alors je doute qu'un tel outil pourrait être intégré à même le navigateur web.

Ah... Là, j'aimerais bien un coup de main d'Emmanuel Clément (le styliste d'OpenWeb) : c'est un sujet dont nous avions pas mal débattu il y a longtemps. A défaut:

Tes factures sont le cas type d'une collection de documents. Leur cohérence est purement interne, et lié à un identifiant unique. Isolément, aucune n'a de sens.

Je suppose qu'il existe une URI (pas URL) pour le tout, la chose qui produit les factures, qui est identifiable aux factures, l'entreprise (qui reste à identifier sémantiquement).

Autrement-dit (RDF):
[cette Facture] ->est payable à ->[cette entreprise]

Reste à définir quelque-chose derrière "facture", "est payable à" et "entreprise" (ou des termes plus pertinents) pour que des machines puissent manipuler le tout.

Mais à partir de cette URI, un outil sémantique pourrait adresser une recherche ciblée à un moteur, qu'il soit externe (Google) ou sous forme de service associé (Atmoz).

Mais si c'est le navigateur qui effectue la recherche sur ces documents, qu'advient-t-il de la sécurité / confidentialité des documents ? Mon moteur de recherche est accessible seulement aux personnes identifiées dans mon application web, et les requêtes s'effectuent selon leur profil : ils ont accès uniquement à une partie des factures, et non l'ensemble.

Je ne connais pas trop les technicalités de l'intégration d'un moteur de recherche dans le navigateur pour ce genre de documents protégées, mais il me semble instinctivement qu'il est plus sécuritaire que la recherche se fasse via l'application web et non par le navigateur web sur lequel notre serveur n'a aucun contrôle. Évidemment, supposons que je fournisse au navigateur les URI (qui bon, pourraient surement être des urls vers les détails de la facture ?), je peux quand même en bloquer la lecture au navigateur si l'utilisateur n'est pas identifié...

Peut-être n'ais-je tout simplement pas compris l'idée que tu voulais soulever. Il me semble quand même que tout ca rend la chose plus compliquée qu'il ne le faut. Pourquoi faire gérer la recherche par le navigateur ? Quels sont les intérêts ? Surtout si l'intégration d'un moteur de recherche directement dans l'application n'implique pas beaucoup de travail.
Modifié le 01 Dec 2004 - 20:15