Collectif L'OUVRE-BOITE

Autolinks : une controverse sans objet

Une belle controverse a éclaté sur la capacité Autolink de la barre d'outils Google. Elle est bien résumée dans cet article de Kuro5hin getting to the real issue.

Autolink : repérer dans une page Web des adresses (USA), des codes de suivi postal, des numéros ISBN. Créer automatiquement [*] un lien dans cette page vers une carte (USA), le service de suivi d'un transporteur, une page Amazon.

[*] La page Web n'est modifiée, les liens créés (si c'est possible) que si l'utilisateur a cliqué dans un bouton de la barre Google.

Controverse : "Ah les *£ç&@#! qui osent modifier "ma" page !"
En fait : Crainte de voir croître encore la puissance de Google
Morale et bon sens : If a content-modifying function : 

• has a definition that is completely understood by the user
• is only invocable at the user's request and in isolation (i.e. not automatically)
• has an effect limited to the user who invoked it
• ... then it's entirely within the spirit of the Web, no matter what modification it performs.
  
• No exceptions.

Une entreprise comme Google a tout intérêt (outre la concurrence avec Microsoft ou Yahoo), à fournir des outils légers :

• non intrusifs
• faciles à installer
• rendant des services
• pouvant servir de supports de test pour des usages
• dirigeant vers des services Google (pouvant éventuellement porter de la publicité)
• ou vers des services de partenaires
• ou des services proposés par des annonceurs, ou par prospects qui pourraient devenir annonceurs, ou "meilleurs" annonceurs

Bref, rien là que du business bien exécuté. Rien n'empêche des concurrents (ou des entreprises non concurrentes, ou même des administrations, associations, particuliers) de faire pareil.

Cela rappelle un peu les débuts de la "guerre des browsers". Plusieurs voies étaient possibles, et ont été empruntées, dont :

• Le chargement en features des logiciels de navigation. Cela a eu les résultats que l'on sait sur la stabilité, la sécurité, la compatbilité (avec les sites Web, les standards.
• La personnalisation des logiciels (habillage, fonctionnalités) pour de grands clients.
• Le développement de plug-ins
• Le développement d'applets java, de scripts javascript
• Les développements serveur lourd + client léger

Les navigateurs d'aujourd'hui sont plus légers, plus conformes aux standards. La personnalisation du navigateur peut bénéficier :

• côté technique : de l'apport des Web Services et de protocoles client / serveur plus performants, du RSS, des tags
• côté usages : de la pratique de plus en plus répandue du partage, de l'efficacité du buzz (blogs, etc.).
  

Il s'agit d'une personnalisation légère. Les mini-applications (mini-services) prennent le plus souvent peu de place en mémoire, peuvent être rapidement développées puis modifiées / améliorées (et d'autant plus que leur code est accessible), ce qui augmente le taux d'utilisation par les utilisateurs, et les incite à tester puis adopter de nouveaux usages.

Guerre des boutons

Pour séduire l'utilisateur, chaque acteur peut vouloir proposer des extensions ou bookmarklets plus perfectionnés les uns que les autres (attention cependant à la simplicité s'usage ...). Et "remplaçant" le bouton du concurrent ... ou encombrant votre navigateur.

Ces boutons peuvent "rendre service" à l'utilisateur. Ils servent aussi des objectifs business.

La guerre des boutons consisterait, pour promouvoir ces accessoires, en offres de services (avantages promotionnels), cadeaux, publicité, rédactionnel (... sur blogs par exemple, avec démonstrations à l'appui). Très classique campagne commerciale.

Boutons : mercerie partagée :-)

La guerre des boutons a peut-être déjà éclaté, à notre insu. Mais quelle importance ? Nous pourrions nous mêmes fabriquer les boutons qui nous sont utiles, et diriger les liens (et en général déclencher un enrichissement de la page Web ou une action quelconque) vers des services que nous apprécions (ce qui introduit la possibilité d'utiliser le partage de signets / de services / d'appréciations / recommandations / recherche

A la carte ou au menu, quelques ingrédients d'un service de partage de boutons :

Ingrédient indispensable

Le service exporte et importe des flux RSS, dispose d'API (Web Services in / out).

Ingrédient 1 : un bouton-mère

Il contient les blocs pour accueillir les composants d'une mini-application javascript : champs à remplir, cases à cliquer, etc. (Cf. par ex. le bookmarklet de BlogMarks).

Un langage de script très simplifié (cf. Applescript ou Automator) permet, de lier données et traitements entre les composants de la mini-application. Ce langage est un générateur de javascript. Dans beaucoup de cas simples, une métaphore graphique (cliquer, cliquer et déplacer, sur des objets graphiques) peut complètement remplacer l'écriture de code (qui reste néanmoins accessible et éditable, avec feedback sur le GUI).

Un dérivé de l'ingrédient 1 : un atelier de boutons "sur mesure".

Appels lancés depuis un article précisant peu à peu (dialogues, commentaires) des besoins. Tag "je demande", tag "j'offre", autres tags, matching selon diverses possibilités techniques (recherche dans liste, filtrage collaboratif, etc) et commerciales (abonnements, petites annonces, enchères - en utilisant un système Web Service d'enchères; remarque Web Services valable pour le support technique de modules PA, etc.), etc. Réalisations gratuites ou payantes, conseil en boutons (pour par ex. entreprises voulant propager un bouton).

Ingrédient 2 : une bibliothèque de composants

Bibliothèque en ligne, partagée, avec commentaires et exemples (locaux et sur sites utilisateurs), taguée ...

Certains composants sont génériques, par ex. "détecter quelque chose dans la page Web", il y a donc des sous-bibliothèques de paramétrages, par ex "détecter un N° de plaque d'immatriculation Français ou Italiien"

Ingrédient 3 : une bibliothèque d'actions

Par ex : ajouter / remplacer quelque chose dans la page Web, par ex. un lien

Ingrédient 4 : (par ex.) une bibliothèque de destinations

Par ex., si on a besoin d'un service de réservation hôtelière, d'envoyer des fleurs (etc. ...) on ira chercher l'URL - et éventuellement la "colle" Web Services, sur un service du genre Influenceurs.

Si on a besoin d'une aide de type dictionnaire, encyclopédie, on choisira un panel de destinations (Wikipedia, Webster, etc.) qui seront appelées une à une ou ensemble. Les destinations peuvent être des pages Web, ou des appels à Web Services qui pourraient, par ex., "retourner" un résultat dans un bloc de la mini-application, dans une fenêtre pop-up ... ou dans la page Web appelante, ou encore dans un flux RSS qui alimenterait directement une autre application desktop, ou un répertoire personnel (agenda, etc.) distant.

Ingrédient 5 : des boutons tout prêts

Fabriqués par des individus ou des entreprises, la bibliothèque de ces boutons est recherchable, consultable, partageable, commentable, taguable (etc.).

Pour faciliter le choix d'un bouton "tout fait" : des indices de popularité (téléchargement, tracking - avec assentiment utilisateur - de l'usage d'un bouton portant telle id, ...), de notoriété (cf Technorati, nombre d'utilisateurs ayant dans leur "réserve de boutons" en ligne - un peu comme les parties "mes signets" de BlogMarks - le même bouton (les mêmes composants, etc.), et une éditorialisation (sur le site, + mail et alertes mail, RSS, etc.)

Ingrédient 6 : éditorialisation

On peut signaler que tel bouton, tel composant ou tel paramétrage "très pratiques" permettent en outre de bénéficier de tel avantage : Sponsoring, publicité, rédactionnel clairement indiqué comme tel , permettent de financer le service, et en conséquence de pouvoir signaler :

• Usages innovants
• Belles réalisations techniques
• "Evénements" dans les commentaires, les tags, etc.
• "Evénements" moteurs de recherche, etc.
• "Evénements" ... et commentaires sur les usages commerciaux.

L'animation du site pourrait aussi comprendre concours etc., récompenser les innovations ou réalisations remarquables, le respect de standards (XUL etc.).

Divers

Un des Web Services à proposer ("localement", par Web Services etc.) pourrait être un marché des partenariats, car un bouton combine plusieurs utilités, et il peut être intéressant pour l'utilisateur comme pour les sponsors, annonceurs, destinataires (etc.), de proposer des synergies.

Là aussi, diverses techniques et diverses modalités commerciales de matching peuvent être utilisées.

Pour mémoire :

• Stephane Lee a lancé sur del.icio.us un répertoire de gadgets blogs. Un tel répertoire pour des boutons ne fournirait pas tous les services attendus d'une bibliothèque de boutons (tris et recherches multicritères, tableaux de comparaison, forums de commentaires - avec tags - etc.
• Le SDK Flowaves de Laurent Bervas pourrait fournir (demander l'avis de techniciens) des routines de base pour réaliser certaines parties de la bibliothèque de boutons.

Nota 1 :

Il existe un très grand nombre de sites plus ou moins techniques avec des astuces, des commentaires, des listes de ressources. Aucun, à ma connaissance,

• n'utilise les tags pour la propagation, la recherche, le classement
• ne propose une construction quasiment sur mesure de mini-applications
• dont il assurerait ensuite une fonction de "place de marché" (et de buzz).

Nota 2 :

Un site de partage de boutons n'est pas obligé de réaliser / présenter tous les ingrédients. Il peut commencer modestement - et rendra déjà un service -.

Nota 3 :

L'Autolink cité au début de l'article modifie (sur clic de l'utilisateur) le contenu de la page. On pratique déjà couramment la suppression de pop-ups, d'images publicitaires, etc. au moyen de simples réglages du navigateur. Il y aurait beaucoup à explorer et innover sur les modifications de contenus (légales, innovantes, utiles, ludiques etc.).

On peut imaginer, par exemple, que des préférences utilisateurs soient stockées localement dans le code d'une mini-application (un mini-éditeur local permet en GUI de les consulter, modifier, éditer, supprimer). Ces préférences pourraient aussi résider sur un répertoire distant, être partagées, taguées, etc. Le rôle de ces préférences est de piloter des modifications de contenu.
 
Exemple ludique : remplacer certaines chaînes de caractères par d'autres (prédéfinies, en provenance d'un serveur, etc.). Exemples moins ludiques : co-navigation à plusieurs, paramétrage à distance de boutons.

L'Autolink se comporte comme une sorte de proxy. Il y aurait beaucoup à explorer, également, dans des usages innovants de proxys.