🚲 Tanguy Ortolo a écrit 12224 commentaires

KDE : il y a une boîte de configuration avec tous les moteurs de recherche (et la liste est déjà bien longue par défaut).

Et pour en ajouter ? Notamment pour en ajouter de peu connus, par exemple le moteur de recherche du wiki de mon travail ?

Epiphany : tu ajoutes un signet avec un URL et la liste apparaît dans la barre d'adresse quand tu entres quelque chose, et il y a une clef dconf avec une URL par défaut.

Pas utilisable par un non-geek donc.

Au passage, ce n'est que la moitié d'OpenSearch ça.

L'autre moitié, c'est un format formel structuré, non HTML, de présentation des résultats d'une recherche. Ce serait très utile pour deux cas :

1. les barres latérales de recherche, façon SeaMonkey ;
2. les petits écrans.

Sauf que la maladie habituelle du Web a sévit : les gens ne savent plus utiliser que le HTML, et ont complètement oublié que des formats structurés pouvaient être utiles.

Comment font les autres ?

Facebook : Quasiment toutes les fonctionnalités requièrent JavaScript : l'ajout de contenu avec un éditeur de qualité, le chat, la mise à jour du contenu en temps réel, les actions qui ne rechargent pas la page (Ajax quoi…).

Et lire seulement un article rédigé par quelqu'un ? Aucune raison de nécessiter JS, or pour avoir essayé, sans JS ils n'affichent pas tout, ou l'affichent mal il me semble.

Google : La complétion est obligatoirement en JavaScript. La complétion HTML5 est un peu légère. Pour le reste, JavaScript n'apporte pas grand chose.

JavaScript pas du tout indispensable donc, en théorie. Or depuis certains endroits — genre depuis mon travail, mais pas depuis chez moi, allez comprendre — Google n'affichent rien, mais alors rien du tout, pas même de page d'accueil, si JS n'est pas activé.

Wikipedia : L'éditeur d'articles est une horreur sans JavaScript. Et l'édition d'articles, c'est un peu le principe de base de wikipedia.

Alors déjà, il y a des gens qui n'ont pas du tout besoin des fonctionnalités JS de l'éditeur, genre moi. Et ensuite, celui qui lit un article sans vouloir l'éditer n'a vraiment pas besoin de JS. Mais ça tombe bien, Wikipédia c'est plutôt bien codé : sans JS, c'est utilisable.

Eh bien OpenSearch, ça sert à ça, ou plus précisément, à deux cas :

1. Je suis sur un site, et il se trouve qu'il fournit un moteur de recherche, interne ou externe, peu importe : Firefox me propose de l'ajouter facilement à sa liste.
2. Je suis sur un annuaire de moteurs de recherche, et pour chaque moteur listé, il y a un lien : en cliquant dessus, ça l'ajoute à la liste de Firefox.

Pas forcément sans une goutte de JS, mais simplement qui fonctionne sans JS. Un très bel exemple est RoundCube, un webmail qui est tout à fait utilisable sans JavaScript, et qui avec JavaScript ajoute des fonctionnalités pas indispensables. Et pour les mauvais exemples, des tas de sites Web qui poussent le vice jusqu'à charger leurs styles par JavaScript, et donc ne ressemblent à rien quand on a désactivé l'interpréteur.

Heu… C'est un principe d'ergonomie de base d'adapter l'interface à l'utilisateur et pas l'inverse.

Parfois on doit faire l'inverse. Quand l'utilisateur prend spontanément de mauvaises habitudes, l'interface doit décourager celles-ci, pas les encourager en les rendant plus faciles encore.

Peut-être que certaines choses ne sont pas possibles à faire autrement qu'avec une page web dynamique. Je pense à Google Maps par exemple.

C'est pour ça que j'ai écrit « sauf cas particuliers », en pensant justement à ce qui ne peut pas être fait sans JavaScript.

Quand, dans un site, tu mets un <link rel="search" href="http://search.example.com/?q=%s"/>, ces navigateurs proposent d'ajouter le moteur de recherche à sa liste ?

Ah, ça valait le coup de préciser. À ma connaissance : non.

C'est surtout un raisonnement normalisateur : presque tout le monde fait comme ça donc on n'a pas à permettre de faire autrement. Heureusement qu'on n'applique pas ce raisonnement partout, sinon dans deux ans on n'aura plus de barre d'URL — ce qui fera la joie des faussaires.

Non non non. En 2013 le nombre de sites codés avec deux pieds gauches, qui sont inutilisables sans JavaScript, a augmenté en effet, mais attention à ne pas déplacer le problème : sauf cas particuliers, le problème ne vient pas du blocage de JS mais de l'incompétence du concepteur du site.

Sauf que ce n'est reconnu nulle part. OpenSearch, on aime ou pas mais c'est le seul standard, et il fonctionne bien comme ça. Il permet de stocker : nom du moteur de recherche, description, icône… Après, pourquoi pas publier un outil pour fabriquer des descriptions OpenSearch à partir de chaînes comme ça ?

Non, mais la barre de recherche ne sert pas qu'à demander à Google, hein. Perso, j'utilise aussi : DuckDuckGo, Wikipédia en français, Wikipedia en anglais, Wiktionnaire en français, le wiki de la boîte où je travaille et OpenStreetMap.

perso, j'aime bien voir l'url avant de cliquer

Elle s'affiche dans une zone éphémère en bas de la page.

C'est bien, mais pas top ça :

• aucune découverte OpenSearch, il faut se les palucher ;
• pas possible de relancer facilement une recherche sur un autre moteur.

Ah, génial, je viens d'essayer et ça fonctionne à merveille ! Bon, eh bien je sais quel est le prochain paquet Debian que je ferai. Enfin, quand j'aurai rattrapé mon retard dans pas mal de choses tout de même…

C'est à régler dans le profil de l'administrateur.

Pour les articles, il faut tout de même un peu de structure externe, avant d'en faire des pages Web, puisqu'il faut pouvoir y identifier : le titre, la description et les mots-clefs — pour les mettre dans l'en-tête HTML —, le chapô — pour l'afficher sur les pages composites — et le corps.

Donc du HTML, pourquoi pas, et c'est d'ailleurs ce qui est utilisé là où c'est pertinent, à savoir pour le chapô et le corps, mais dans une structure en JSON ou autre — système de fichier par exemple : un répertoire pour l'article et un fichier par composant ! —, c'est indispensable.

Je pense pour ma part que l'utilisation de XML n'est pas très appropriée pour les données d'un blog. En effet, qu'a-t-on ? Des articles, des mots-clefs, des catégories et des commentaires. Le plus efficace à mon avis :

• un fichier par article, avec par exemple une structure à la RFC-822 dans le plus pur style de Debian pour stocker titre, chapo et corps ;
• pour les catégories et mots-clefs : un répertoire à chaque fois, avec les articles liés dedans, et dans chaque article un champ indiquant ses catégories et mots-clefs ;
• pour les commentaires : un fichier par article, éventuellement le même que celui de l'article lui-même, avec les commentaires ajoutés à la fin.

Mais les auteurs de PluXml ont fait un choix un peu différent. Ça ne me dérange pas outre mesure, surtout compte tenu du fait qu'ils sont presque les seuls à avoir résisté à la basededonnite aiguë qui sévit dans le mont du ouaibe.

Pour les exemples, il faut utiliser les noms de domaines dédiés à cet usage : example.com, example.net, example.org, example.edu, et le nom de domaine de niveau supérieur example.

Et si je ne tape qu'un mot ? Et si je veux relancer ma recherche dans un autre moteur de recherche ? Tout, ça change.

Pareil pour moi, je n'ai trouvé aucun autre navigateur Web que Firefox avec un outil pour lancer des recherches qui :

1. prenne en charge la découverte OpenSearch ;
2. à la suite d'une recherche, conserver les termes de la recherche sans les remplacer par l'URL de la page de recherche ;
3. permettre de passer rapidement d'un moteur de recherche à un autre.

Ah, et à propos de traduction, on truc qui serait génial, ce serait d'utiliser la langue appropriée pour chaque visiteur.

L'interface d'admin est-elle également traduite, au moins en anglais ? C'est la seule chose que j'attends avant de pouvoir enpaqueter ça pour Debian…