What Nooxt ?

Après le choc des images, le poids des mots : voici le top 10 des nouveautés de Nooxt v3.

• #10. Enregistrement du mot de passe (plus besoin de le taper à chaque fois)
• #09. Encore plus rapide !
• #08. Création de contacts ajoutée.
• #07. Ajoutez une photo à votre profil.
• #06. Vous pouvez mettre une image en plus ou à la place du titre de l’événement.
• #05. Un événement peut avoir lieu à plusieurs dates.
• #04. Vous pouvez mettre le prénom et/ou le nom de l’invité dans votre mail.
• #03. Vous pouvez distribuer un lien publique pour votre événement.
• #02. Créez des équipes ou des voitures dans laquelle vos invités se placent.
• #01. Certains de vos invités peuvent co-organiser.

Nooxt v3 est avant tout une réécriture totale ce qui nécessite une vigilance particulière : c’est pourquoi une version beta est déjà en cours d’utilisation, parallèlement à la version courante. Cela permet d’étendre la période de test pour avoir un produit final qui ne présente pas trop de surprises (on va appeler les bugs comme ça désormais, c’est plus sympathique).

Merci aux courageux beta-testeurs et n’hésitez pas à me contacter si vous voulez en être. (Vous devez avoir un compte Nooxt.)

L’internet grouille de rumeurs sur ce que contiendra la prochaine version de Nooxt. Des centaines de blogs et de sites majeurs d’information (celui d’un grand quotidien du soir, notamment) ont sur leurs bureaux, entre le pot à stylos et l’agrafeuse, des dossiers longs comme les cheveux de Mia Frye regroupant toutes les données recueillies sur celle-ci.

Ils attendent patiemment le moment où ils pourront confirmer la moindre des allégations collectées et ainsi dispenser au monde quelques lumières sur le futur de l’organisation numérique d’événements. Je préfère avoir la primeur de l’exclusivité même si ça me coûte de les contraindre à jeter leur dossier cartonné orange à la poubelle.

Voici donc une image compilant quelques extraits de Nooxt v3, en exclusivité mondiale.

Une fois que la page est générée (rapidement, c’est là où je vous avais laissés dans l’épisode précédent), il faut que les informations soient transmises à votre internaute. Et pour cela, il n’y a pas de miracle : plusieurs millions d’octets de données mettront plus de temps que quelques milliers.

Cette fois-ci encore, partons du principe que vous n’avez pas la main sur le matériel (taille de la bande-passante,…) et focalisons-nous sur le logiciel. Et il y a fort à faire !

Taille et format des images

Réduisez la taille de vos images au minimum, c’est-à-dire ajustée à la taille affichée. Non seulement cela réduit le poids de l’image mais cela évite au navigateur de la redimensionner, ce que certains d’entre eux (Internet Explorer…) font mal.

D’autre part, choisissez le format approprié pour votre image. Et là, il n’y a pas de règle : le JPEG, le GIF et le PNG donnent des résultats variables suivant les images ; du coup, on ne peut pas passer à côté du test. Lorsqu’il y a peu de couleurs dans l’image, le PNG l’emporte souvent.

Minimiser le code Javascript et CSS

Les codes Javascript et CSS (s’ils existent) contiennent vraisemblablement des tabulations, des commentaires, des retours à la ligne,…. Autant de caractères qui sont parfaitement inutiles pour le navigateur (ils le sont seulement pour vous, pour vous relire). Dès lors, pourquoi ne pas les supprimer ?

Evidemment, ne faites pas le travail manuellement, des outils existent :

• pour le CSS, en PHP, CSSMin ;
• pour le JavaScript : JSMin

Sur les fichiers CSS de Nooxt, par exemple, on gagne ainsi 20%.

Minimiser le HTML

Si l’on réduit la taille des fichiers JavaScript et CSS, pourquoi ne pas faire de même sur le code HTML ? Pour les sites dynamiques (où chaque page est générée sur mesure par le serveur lorsque l’internaute la lui demande), l’inconvénient de cette opération est double :

• elle fait travailler plus intensément le serveur,
• elle augmente la durée de génération de la page, ce qui déplace donc le problème.

Sur Nooxt, je fais quand même cette minimisation lorsque l’on se connecte au site depuis un mobile, là où le temps de transmission est beaucoup plus déterminant que le temps de génération de la page. Pour cela, cette simple ligne supprime tous les caractères d’espaces successifs (tabulation, espaces, retour à la ligne) par un seul espace :

$sortie = preg_replace('~[\s]+~',' ',$entree);

Compression GZip

Lorsque vous envoyez des documents par mail, vous pensez sans doute à réduire sa taille en faisant une archive .zip. Pourquoi ne pas faire de même avec votre site internet ?

Certains navigateurs autorisent la réception de code compressé en GZIP (aussi bien la page HTML, que les codes JS et CSS). Pour vérifier si le navigateur qui visite votre site accepte ce format, il suffit de vérifier ses en-têtes. En PHP, cela consiste en vérifier que la chaine $_SERVER['HTTP_ACCEPT_ENCODING'] contient le terme “gzip”.

Pour faire la compression en particulier, l’opération est relativement simple pour les fichiers CSS et JS. Il suffit de compresser les fichiers et d’appeler les fichiers compressés (si le navigateur peut les lire, encore une fois !), par exemple :

<script type="text/javascript" src="fichier.js.gz"></script>
<link rel="stylesheet" href="fichier.css.gz" type="text/css" />

Avec cette compression, le fichier CSS de Nooxt a été réduit de 76% supplémentaires !

Chipotons

La performance est un défi toujours renouvelé (les sportifs en savent quelque chose), et il est toujours possible de faire mieux. Voici donc un paragraphe pour chipoter.

Plutôt que d’appeler les fichiers avec des noms à rallonge, Nooxt utilise des répertoires de 2 ou 3 lettres, pour l’essentiel. Ainsi “version3/images/icones/fichier.png” sera plutôt appelé “v3/i/ic/fichier.png”. De la même manière, les noms des classes et id du code HTML sont des noms courts, dans la mesure du possible.

Dans les images (GIF, PNG ou JPEG), des informations inutiles sont automatiquement ajoutées par le logiciel qui compose l’image (Photoshop, par exemple). Il est possible de leur faire perdre une taille avec des outils tels que Pngcrush ou Optipng pour le PNG, JHead pour le JPEG, ou le fameux SmushIt qui fait ça en ligne !

Dans le prochain épisode…

Bien. Vous avez maintenant un site internet généré vitesse grand V et d’une taille réduite au maximum.  Mais ça n’est pas fini : il faut que le navigateur récupère tout ça et l’affiche. Et, là aussi, il y a du boulot.

L’ambition en terme de fonctionnalités de Google Wave — un nouveau service web de conversations en direct (au croisement du chat, de l’e-mail, du forum et du wiki) — a éclipsé une petite révolution sur un élément bien connu de nos interfaces depuis le début de l’informatique : la scrollbar (ou “ascenseur”, en français).

Figure 1 — D’abord, l’idée d’avoir une flêche en haut et en bas, ainsi qu’un repère sur le positionnement actuel, pose les bases.

Figure 2 — Ensuite, l’innovation a été de rendre le repère proportionnel au contenu entier (plus la barre grise est grande, plus l’utilisateur voit une large portion du contenu entier).

L’ascenseur selon Google Wave

Si vous êtes comme moi, cela fait très longtemps que vous n’avez pas cliqué sur l’ascenseur ou ses flèches… Avec les ascenseurs de Google Wave, on prend acte du fait que la plupart des souris sont équipées de molette et qu’il n’est plus nécessaire de consacrer ces larges espaces à ce type de navigation.

Figure 3a — L’ascenseur ne prend plus de place : ni en largeur (il est à cheval sur le bloc), ni en hauteur (il ne va pas jusqu’au bas du bloc, un petit taquet indique jusqu’où il descend).

Figure 3b — Ici, on est tout en bas (l’ascenseur est au taquet, pour ainsi dire).

Figure 3c — On peut aussi descendre page par page en cliquant sur les flêches. Dans ce cas, l’ascenseur ne descend pas (sinon, pour aller de page en page, on courrait après !) : seul son ombre descend. L’ascenseur rejoindra sa bonne position (celle de la figure 3c) lorsque que la souris quittera la zone.

Nous verrons si cela se généralise… Notons, pour conclure, que des téléphones portables (tels que l’iPhone) n’affichent l’ascenseur que lorsque l’utilisateur bouge dans la page — était-ce une source d’inspiration ?

L’Homme a une tendance naturelle à l’anthropomorphisme : il cherche partout dans ce qu’il voit ses congénères humains. Plus concrètement, lorsque la façade d’un immeuble a deux fenêtres, l’on voit des yeux. Et notre regard est naturellement tourné vers ce “visage”.

Il en est peut-être de même pour les mérous, qui se disent : « tiens, ce rocher ressemble à un mérou. » Sauf que c’est relativement difficile à prouver puisqu’il n’existe pas de système de eye-tracking (captage du regard) pour mérou. Cela existe pour les hommes.

Sur les sites web en particulier, un visage attirera naturellement votre regard, comme le montre cette image sur laquelle ont été placés les résultats du captage. (Plus c’est rouge, plus il y a de regards.)

Ce qu’il est intéressant de noter est que lorsque le visage regarde une zone, l’internaute va naturellement y jeter un oeil (l’article). Regardez plutôt, justement :

Une sorte de “Derrière-toi !” que l’on aurait tort de ne pas utiliser car redoutablement efficace…

Le test exclusif offert avec votre article

°_° : Si vous voyez un visage et non des degrés, vous n’êtes pas un mérou.

Un internaute a eu la gentillesse d’appeler une page de votre site web. Votre serveur va-t’il la produire aussi rapidement que possible ? Voici quelques outils pour tirer ceci au clair…

Mesurer

Trouver le problème, c’est trouver la solution ; sortons donc notre micro-chronomètre pour mesurer le temps que le script mets à s’exécuter.
Voici une petite fonction PHP (cadeau !) qui fonctionne comme un chronomètre.

function michronometre(){
global $_MICHRO;
list($usec, $sec) = explode(" ", microtime());
if(isset($_MICHRO)){
return ((float)$usec + (float)$sec)-$_MICHRO;
}else{
$_MICHRO=((float)$usec + (float)$sec); return 0;
}
}

Appelez une première fois la fonction (michronometre();), le compteur démarre. Regardez le compteur à n’importe quel moment pour voir le temps affiché (echo michronometre();).
Vous pouvez le regarder à différents endroits de la page pour voir quelle portion de code est à inspecter pour optimiser.
Le temps obtenu sera d’autant meilleur que votre serveur est bon. Mais de manière générale, on fait avec ce qu’on a…
En ce qui concerne Nooxt, la page la plus complexe est produite en un peu plus d’une demi-seconde.

Syntaxes PHP

Pour gagner quelques microsecondes, jetez un oeil à la syntaxe de votre code PHP : les “switch” sont plus performants que les “if…elseif…else”, les guillemets simples que les guillemets doubles (même si c’est moins vrai, voire même faux sur les dernières versions de PHP),…
Le site The PHP Benchmark répertorie des tests de rapidité pour différentes syntaxes.
Cela dit, n’espérez pas tirer grand chose de ce côté là.

Base de données

Le plus chronophage (un joli néologisme typiquement SSII-ien) restent les appels à la base de données : tentez de regrouper vos requêtes en une seule (avec les jointures et les SELECT imbriqués) et, évidemment, banissez les requêtes au sein de boucles.

Cache des pages et des données

Pour savoir comment mettre en cache une page, il suffit de distinguer deux grands types de pages :

• les pages entièrement dynamiques qui devront être différentes à chaque chargement puisqu’elles vont chercher des nouvelles données ;
• les pages qui sont modifiées une fois pour toute côté serveur.

Pour les premières, une page HTML sera affichée beaucoup plus rapidement : vous pouvez soit la produire manuellement (en copiant-collant le code généré HTML par le PHP dans un fichier HTML), soit activer le cache de votre moteur de template (si vous en avez un).
Pour les secondes, le recours au PHP sera obligatoire. Mais, au sein d’une même page, vous pouvez distinguer ce qui nécessite réellement un recalcul à chaque chargement de la page… et les autres.
Sur Nooxt, pour calculer des probabilités de présence, des statistiques sont réalisées sur tous les événements puis appliquées à l’événement en cours. Pour éviter ces deux calculs à chaque page, le premier est calculé une fois pour toute et est stocké en session (dans la variable $_SESSION).

Attendez, je n’ai pas fini de

Lorsque vous faites des “echo” ou “print_r”, les informations ne sont pas envoyées aussitôt : ce n’est qu’à la fin du script que tout est envoyé d’un bloc. Mais pourquoi attendre que toute votre page ne soit calculée avant de commencer à l’envoyer à votre internaute ? Vous pouvez demander au serveur de faire parvenir au client ce qui a déjà été affiché en utilisant la fonction flush() [edit: et ob_flush(), merci Thomas].
L’usage le plus courant est d’utiliser cette fonction juste après le “</head>” dans le code HTML, pour que le navigateur puisse commencer à charger les fichiers externes pendant que le reste de la page est généré.

Dans le prochain épisode…

Votre page a été générée aussi rapidement que possible mais parviendra-t’elle à la vitesse de l’éclair au navigateur ? Melany avouera-t’elle son adultère à Jason ?

Nous ouvrirons bientôt plus de sites web que d’applications sur nos ordinateurs — et c’est d’ailleurs déjà le cas pour la plupart d’entre nous… –. C’est précisément le pari que fait Google en annonçant un nouveau système d’exploitation (concurrent de Windows) dont l’objectif est d’accéder au web en quelques secondes (« We’re designing the OS to be fast and lightweight, to start up and get you onto the web in a few seconds », Official Google Blog). Pas de faire tourner des fenêtres en 3D ou de déchiffrer le génome de Patrick Juvet : ouvrir une page web.

Cette tendance positionne les sites web en concurrence directe avec les applications installées sur les ordinateurs et, à cet égard, l’utilisateur attend d’eux exactement la même chose : la quasi-instantanéité. Il n’est plus acceptable d’attendre quelques secondes pour accéder à l’information. Pour preuve, la moitié des utilisateurs place la lenteur de chargement comme la principal raison pour laquelle ils quittent un site (source).

Particulièrement vrai sur mobile

D’autre part, grâce à BlackBerry et à l’iPhone, l’internet mobile n’est plus un terrain de jeu technologique mais une vraie perspective de développement. Des centaines de millions de téléphones seront bientôt des navigateurs internet.

Les débits proposés imposent fatalement un recul par rapport aux connexions sur un ordinateur : les informations sont moins rapidement transmises sur un téléphone que via l’ADSL. On ne saurait se satisfaire de cette limitation technique : l’utilisateur ne réduit pas ses exigences à la baisse en passant sur son mobile.

Voilà donc qui introduit l’importance de développer un site web rapide. Cette série de 4 billets livrera quelques clefs pour cela sur trois aspects :

• du côté serveur,
• la communication serveur-client,
• du côté client.

Précisons qu’il ne sera abordé que des actions qui peuvent être menées par un webmaster sur son site web ; le découpage supra indique l’origine du problème, pas l’origine de la solution !

(Je m’engage donc à faire encore 3 billets sur ce blog !)

Google met à la disposition des webmasters un outil (Website Optimizer) qui permet de comparer la “réussite” d’un design sur un autre. Le succès est mesuré par le “taux de conversion”, c’est-à-dire le pourcentage de personnes qui vont atterrir sur la page cible (dans le e-commerce, ce sera typiquement le panier).

Les internautes voient aléatoirement l’un des deux designs et le taux de conversion est calculé dans l’un et l’autre cas. L’outil est tout simple ; ce qui nous intéresse en revanche ici, ce sont les résultats.

L’équipe qui s’occupe du projet fait l’amitié à la planète de livrer quelques exemples de résultats sur leur blog, duquel j’ai extrait quelques exemples. (Les images sont petites, mais ça permet d’avoir une vue d’ensemble. Vous trouverez aux liens indiqués les images en taille réelle et parfois d’autres essais.)

LA.com

Lequel des deux formulaires gagne ? L’un des deux a fait peur aux internautes, partis fissa sur une autre page, avec donc 20 % d’inscription en moins.

Le gagnant est le premier. Regardez d’un coup d’oeil comme il a l’air plus simple ; la première colonne est la première regardée (si ce n’est la seule). Sur la première page, on a l’impression que le formulaire ne fait que 3 champs. Sur le second, on a les 4 cases à cocher et ensuite les 3 champs, soit deux fois plus de questions à se poser… (Article sur le blog)

Pacific Hills

Le calcul des taux de conversion comparés est ici un petit peu particulier : les deux écrans contenaient chacun un numéro de téléphone différent. L’objectif était de mesurer celui qui aboutissait au plus d’appels. Lequel des deux gagne ?

C’est la seconde qui gagne. Je ne vais pas m’attarder dessus : la zone centrale est clairement mise en avant parce que c’est la seule sur fond blanc, et l’image du téléphone de la même couleur que le numéro (rouge !) est d’une efficacité redoutable. (Article sur le blog)

37 signals

Cet exemple-ci n’est pas tiré du même blog ; je l’ai pris directement de l’excellent Signal vs Noise. Le meilleur des 3 générera 30% de plus d’inscription que le pire…

Le gagnant est le second. Ce qu’il faut retenir c’est qu’il ne faut pas perdre de temps : le titre lui-même doit être un argument (contrairement au premier). Aussi, les citations qui disent que le produit est génial (sans blague ?) ne servent à rien, il vaut mieux insister sur le fait que c’est rapide (“Moins de 60 secondes !”). (Article sur le blog)

Safe Software

L’une des deux pages va provoquer plus de téléchargement… Laquelle ?

C’est la seconde. Oui, l’inénarrable photo d’un blanc sans âge beau-mais-pas-trop qui sourit à la vie parce que télécharger des logiciels ça lui donne envie de croiser les bras et de montrer ses dents au ciel, n’a servi à rien. Et la flêche verte non plus. (Article sur le blog)

Si vous avez d’autres exemples, n’hésitez pas à les poster en commentaire !

Pensez à ça quand Nooxt vous fera patienter quelques secondes pour envoyer des mails d’invitation aux 4 coins du monde !

(via Mike Lightman et Swiss Miss)

Le 10/01 à 22:22:22, Nooxt était officiellement lancé. Officiellement et… symboliquement, puisqu’il a fallu en réalité attendre 10h le lendemain, le temps que chacun se réveille de la soirée inaugurale.

Un petit peu plus d’un mois après, il est temps de jeter un oeil aux chiffres de fréquentation, et surtout aux performances du serveur (c’était le point qui m’effrayait). Je ne vais pas jouer avec vos nerfs et commencer par la conclusion : tout s’est bien passé.

Plus de 2 fois + de visites

Le lancement a provoqué une hausse de fréquentation prévisible et espérée, qui s’est stabilisée en février, signe que ça n’était pas qu’un simple coup.
Comme je l’avais annoncé il y a quelques semaines, j’ai suivi attentivement les performances du site (je répertorie le temps de chargement de chaque page). Quelques corrections ont été faites au fil de l’eau et il faut maintenant autour de 0,5 s. au serveur pour générer une page, en moyenne.
Il y a encore un petit peu de marge de manœuvre mais ça me semble une bonne base ; tant mon serveur que les visiteurs sont contents, je continue l’aventure !

D’année en année, les webdeveloppeurs ont accordé de plus en plus d’importance à l’adresse URL de leurs pages (http://…). À l’origine, l’objectif était d’améliorer le référencement par les moteurs de recherche. L’idée est de mettre “bernard-montiel” dans le lien, plutôt que “ref=8238209″, pour que Google donne plus de points à la page.

Le lien fait partie de la page

La barre d’adresse surmonte les pages dans tous les navigateurs, dans une large zone blanche dans laquelle est écrit en gros et en noir le lien vers la page. C’est un emplacement capital qu’il serait dommage de laisser en pâture aux identifiants techniques abscons et, il faut l’avouer, un peu effrayant.

Lorsque l’on ouvre une application comme Word ou Firefox, il est impossible à l’utilisateur de savoir si elle a été écrite en C#, en Java ou en Cobol ; et cela tombe bien, il s’en fiche comme de la marque du premier scooter de Karen Cheryl. Il n’y a donc pas vraiment de raison d’afficher “.php”, “.html”, “.asp”,…

Que faire des liens ?

Mieux, la barre d’adresse peut être un véritable outil de navigation, et ce, à 3 degrés différents.

• N’essaye même pas de comprendre le lien. Par exemple : http://livre.fnac.com/a1605068/David-Carter-Guide-des-chenilles-d-Europe?PID=1&Mn=-1&Mu=-13&Ra=-1&To=0&Nu=2&Fr=0 pour la page sur le Guide des chenilles d’Europe.
  
• La barre peut servir de fil d’Ariane (on peut remonter à l’élément parent en supprimant le ou les enfants). Par exemple : apple.com/trailers/universal/duplicity/ affiche la bande-annonce de Duplicity, apple.com/trailers/universal/ affiche les bandes-annonces Universal, etc.
• La barre d’adresse peut servir d’accès direct à des pages. Par exemple, les pages de Wikipedia pour lesquels je ne passe plus par la page d’accueil (exemple : fr.wikipedia.org/wiki/Alexandre_Delperier) ou celle de LastFM qui utilise une convention simple (lastfm.fr/music/Sacha+Distel).

Enfin, une barre d’adresse bien propre me donne la sensation que le site que je visite ne s’approprie pas les informations que je lui communique et qu’elles seront toujours à moi. Comme si je travaillais sur un bureau bien rangé.

Et vous, faites-vous attention à la barre d’adresse ou cliquez-vous de lien en lien sans y faire attention ?

“On s’en fout, c’est juste du wording.”¹ Dans le développement web, c’est une phrase que j’entends souvent et que, je le confesse ici, j’ai dû moi-même prononcer. Outre la double obscénité que réprésente l’anglicisme et la vulgarité (qui n’est pas l’objet de ce billet), cette remarque marque le désintérêt dans le développement pour les mots employés.

Si elle a, évidemment, sa justification technique (les textes utilisés sur un site sont les éléments les plus facilement modifiables), elle représente bien le plan auquel l’écrit est relégué. Je ne parle pas de grammaire ou d’orthographe — saluons déjà la témérité de ceux qui sont partis pour faire un site en français, là où des fautes sont si facilement faites² —. Je parle en particulier du choix des mots.

Porter une attention particulière à la rédaction des intitulés permet d’étendre leurs fonctions : ils ne deviennent plus seulement informatifs mais aussi des vecteurs de communication.

Ajouter de la communication à l’information

À titre d’exemple, le site Last.fm et le plus confidentiel Google.com ont tous les deux condensé leurs identités dans un titre de bouton. L’exemple du premier est si marquant que je vous le retranscrit de mémoire alors qu’il n’est plus en ligne depuis quelques mois [edit. : Si, en fait. Merci Camous]  : pour changer la couleur de fond (noir et rouge), l’utilisateur avait le choix entre “Paint it Black” et “Simply Red”. Quelques secondes suffisaient pour comprendre qu’il s’agissait d’un site de musique, qui aime la musique et qui ne parle que de musique. Mieux qu’un slogan, une preuve par l’exemple.
De la même manière, le slogan de Google (un truc avec la recherche, je ne sais plus quoi) ne sera jamais aussi puissant que leur bouton “I’m feeling lucky” (ou “J’ai de la chance”) : 4 mots qui font oublier les bases de données de centaines de milliards de résultats, les AdWords, la confidentialité des données, l’empire tentaculaire… La société n’est plus que “cool”.

Les sociétés font des efforts considérables pour être cool et faire oublier les costumes sombres qui les composent. Mais qu’est-ce qui aurait le plus d’effet :

• une campagne pour Windows dans laquel des gens disent “Windows c’est cool” ou bien le bouton “Démarrer” renommé “C’est parti, je suis chaud” (écrit en plus petit, du coup) ?
• des bannières “iTunes aime les jeunes et leur musique” (avec des adolescents qui dansent, cela va sans dire) ou bien la “Bibliothèque” renommée “Ton gros son”.

Évidemment, toutes les applications (web ou non) ne cherchent pas à créer une telle proximité avec leur utilisateur ; le sérieux et le conformisme sont des valeurs que l’on peut vouloir communiquer. Le tout est de se poser la question — comme on le ferait avant de choisir une couleur ou une autre — avec, au final, l’espoir d’ajouter un supplément d’âme à ses boutons.

“Les titres de champs d’un formulaire sont le miroir de l’âme.” 

Dans Nooxt, j’ai un objectif particulier qui est de privilégier les phrases complètes ; concrètement, dire “Kevin et Brian viennent sans doute. Brandy ne vient pas.” plutôt que “Kevin, Brian : peut-être. Brandy : non”.³ Je sacrifie de la concision mais la phrase, l’accord et les majuscules rendent la communication moins mécanique.

C’est un choix discutable, que tout le monde n’aurait pas fait mais auquel je tiens : en cela, on me lit à travers ces textes. Voilà l’âme cachée derrière le site ! Dans ces mots, plus que n’importe où ailleurs.  

1. Le wording, c’est l’ensemble des termes utilisés sur un site pour les noms des rubriques, les titres de bouton, les intitulés de champs, etc.
2. Voilà, je peux faire des fautes sur mon blog comme ça.
3. Les prénoms sont inventés, Dieu merci.

Parler du réchauffement climatique et de la nouvelle ferveur écologique qu’elle suscite en totale contradiction avec les comportements individuels pourrait faire l’objet d’un long article en 3 parties et 18 paragraphes, avec plein de mots compliqués.

Ou bien, un tee-shirt qui dirait :

Pour moi, il y a du génie dans l’écriture d’une telle phrase (bravo Lawrence Pernica). L’alliance de la simplicité et de la concision font toujours mouche et j’espère avoir le plaisir de découvrir vos exemples et de les partager ici. (Même si je me rend bien compte que c’est mon second billet et que je ne parle donc qu’à moi-même…)

Oui, je précise qu’une phrase est une création — du coup, ce blog va vraiment parler de tout. Mon prochain billet parlera d’ailleurs précisément de texte (vendeur hein ?).

Voilà déjà plus d’un an que je travaille sur Nooxt et il faut se rendre à l’évidence : il va falloir que je me résolve à ouvrir les inscriptions. Et c’est effrayant à double titre.

Techniquement d’abord, c’est rendre accessible simultanément à des centaines de millions d’utilisateurs (potentiels) un site sur un serveur relativement basique (supportera-t’il deux fois, dix fois, cent fois plus de connexions ?). Je crois avoir pris un certain nombre de protections sur lesquelles je reviendrai dans un prochain billet.

Humainement d’autre part, parce que je vais exposer mon travail à la vindicte du réseau des réseaux (c’est-à-dire Internet, mais j’adore cette périphrase qui laisse entendre toute la démagogie du réseau des réseaux lui-même). Dès lors, je n’aurai plus l’excuse “Ce site est en cours de développement”. Il me restera bien une mention “version beta” ça et là ; mais cette dénomination a perdu beaucoup de son sens il y a quelques années.

Et maintenant quoi ? (”What next?”)

Dans quelques semaines, les inscriptions seront ouvertes (vraisemblablement en janvier 2009). Ce blog détaillera la genèse de fonctionnalités nouvelles, reviendra sur les étapes de l’épopée de Nooxt et distillera des astuces relatives au web-développement.

Mais le cadre délimité par le sous-titre du blog me laisse le champ libre pour évoquer ici… à peu près tout.