Cet article est une extension de "Ta page charge, ce n'est pas sale." chez hteumeuleu.fr. Il explique avec justesse pourquoi les barres de chargement (et consorts) sont une mauvaise chose sur le web ; avec une certaine ironie d'ailleurs, puisqu'elles alourdissent les pages.

C'est tout à fait exact, bien sûr. Mais je voulais étendre la portée de ce billet parce que le web n'est plus seulement une agrégation de sites vitrines interconnectés. On construit aujourd'hui de véritables applications, sur le web. Bon, ça ne date pas d'hier, mais le mot ActiveX me donne des boutons...

L'auteur de l'article original nous explique qu'une page de chargement est plus frustrante qu'autre chose pour l'utilisateur qui n'a alors la main sur rien et ne peut qu'attendre. Et nous le savons, personne n'aime attendre. Encore moins lorsque l'on est sur Internet où tout va si vite.

En revanche, dans les métiers de l'informatique et des web applications en général, on est souvent confronté à des fonctionnalités qui sont leeeentes. Parfois même, la boutade qui dit qu'on aurait le temps d'aller chercher un café en attendant... n'en est pas une. Ce problème trouve sa cause dans une pléiade de possibilités : fonctionnalité mal codée, non optimisée ; la demande farfelue d'un client ; des serveurs surchargés ; un poste client inadapté ; une sollicitation trop importante du réseau ; etc.

Mais là, c'est le drame. Le client qui vous paie, cher, n'admettra jamais que l'export PDF sa base de données de 2Go soit aussi lent. Il voit son navigateur mouliner dans la semoule, pendant 1 minutes, puis 2. Et puis, il se dit que ça a planté alors il recommence. Et il recommence à nouveau sur l'ordinateur de son collègue pour vérifier que ça ne vient pas du sien. Et là, gagné, c'est le serveur qui lâche.

C'est un cas extrême, d'accord. Vous allez me dire qu'on n'aura jamais à implémenter une fonctionnalité pareille dans une webapp. Mais quoiqu'il en soit, vous aurez toujours des actions lourdes à faire, qui prendront du temps. Un exemple plus réaliste : l'import OPML dans le projet Autoblog.

Alors comment éviter ces comportements, frustrer les utilisateurs et ramasser des anomalies qui n'en sont pas ?

La réponse est l'inverse de ce qu'y est écrit dans l'introduction : les barres de chargements ! Elles animent la page charge. Elles permettent à l'utilisateur de suivre l'avancement. Elles permettent surtout de constater l'application ne nous a pas lâché, et qu'elle continue à faire son job.

Ca ne s'applique pas qu'au web d'ailleurs. Qui attend 5 minutes en voyant : L'application Windows.exe ne répond pas. ? Qui tue une application en voyant une barre de chargement avancer ?

Eh oui. Une page qui charge, ce n'est pas sale. Mais une barre de chargement, c'est rassurant. Utilisez-les avec parcimonie et intelligence, sur des fonctionnalités qui sont susceptibles d'être lourdes, vos utilisateurs seront ravis.

PS : Si jamais la cyber-psychologie est une discipline, je crois que ce billet en est !

Cet article est une extension de "Ta page charge, ce n'est pas sale." chez hteumeuleu.fr. Il explique avec justesse pourquoi les barres de chargement (et consorts) sont une mauvaise chose sur le web ; avec une certaine ironie d'ailleurs, puisqu'elles alourdissent les pages.

C'est tout à fait exact, bien sûr. Mais je voulais étendre la portée de ce billet parce que le web n'est plus seulement une agrégation de sites vitrines interconnectés. On construit aujourd'hui de véritables applications, sur le web. Bon, ça ne date pas d'hier, mais le mot ActiveX me donne des boutons...

L'auteur de l'article original nous explique qu'une page de chargement est plus frustrante qu'autre chose pour l'utilisateur qui n'a alors la main sur rien et ne peut qu'attendre. Et nous le savons, personne n'aime attendre. Encore moins lorsque l'on est sur Internet où tout va si vite.

En revanche, dans les métiers de l'informatique et des web applications en général, on est souvent confronté à des fonctionnalités qui sont leeeentes. Parfois même, la boutade qui dit qu'on aurait le temps d'aller chercher un café en attendant... n'en est pas une. Ce problème trouve sa cause dans une pléiade de possibilités : fonctionnalité mal codée, non optimisée ; la demande farfelue d'un client ; des serveurs surchargés ; un poste client inadapté ; une sollicitation trop importante du réseau ; etc.

Mais là, c'est le drame. Le client qui vous paie, cher, n'admettra jamais que l'export PDF sa base de données de 2Go soit aussi lent. Il voit son navigateur mouliner dans la semoule, pendant 1 minutes, puis 2. Et puis, il se dit que ça a planté alors il recommence. Et il recommence à nouveau sur l'ordinateur de son collègue pour vérifier que ça ne vient pas du sien. Et là, gagné, c'est le serveur qui lâche.

C'est un cas extrême, d'accord. Vous allez me dire qu'on n'aura jamais à implémenter une fonctionnalité pareille dans une webapp. Mais quoiqu'il en soit, vous aurez toujours des actions lourdes à faire, qui prendront du temps. Un exemple plus réaliste : l'import OPML dans le projet Autoblog.

Alors comment éviter ces comportements, frustrer les utilisateurs et ramasser des anomalies qui n'en sont pas ?

La réponse est l'inverse de ce qu'y est écrit dans l'introduction : les barres de chargements ! Elles animent la page charge. Elles permettent à l'utilisateur de suivre l'avancement. Elles permettent surtout de constater l'application ne nous a pas lâché, et qu'elle continue à faire son job.

Ca ne s'applique pas qu'au web d'ailleurs. Qui attend 5 minutes en voyant : L'application Windows.exe ne répond pas. ? Qui tue une application en voyant une barre de chargement avancer ?

Eh oui. Une page qui charge, ce n'est pas sale. Mais une barre de chargement, c'est rassurant. Utilisez-les avec parcimonie et intelligence, sur des fonctionnalités qui sont susceptibles d'être lourdes, vos utilisateurs seront ravis.

PS : Si jamais la cyber-psychologie est une discipline, je crois que ce billet en est !

PrivacyBox est un service en ligne allemand qui permet d'autoriser ses utilisateurs à être contacté de manière complètement anonyme. Je l'utilisé d'ailleurs dans ma page de contact. Malheureusement, après 5 années des bons et loyaux services, PrivacyBox nous annonce qu'il va disparaître ; encore un, parmi les bons.

Parce que je pense qu'il est important de toujours laisser la possibilité de l'anonymat, je vais remplacer ce service par un simple formulaire, faute de mieux.

Voici ce qu'on peut lire sur le site de PrivacyBox - j'ignore depuis combien de temps et pour combien de temps :

PrivacyBox est désormais en fin de vie

Le service PrivacyBox a été lancé en 2008 par la German Privacy Foundation 
e.V. (GPF) et a réuni de nombreux utilisateurs depuis lors. Aujourd'hui 
l'outil est dépassé, à la fois techniquement et conceptuellement.

Pour le moment la GPF ne prévoit pas de développer une nouvelle version. 
Il n'y a pas encore de date fixée pour la fermeture du service PrivacyBox, 
mais nous vous informerons suffisamment à l'avance. Malheureusement, 
nous ne pouvons plus répondre aux demandes de support.

Nous voulons remercier tous les utilisateurs de PrivacyBox pour leur 
confiance, et nous excuser pour la gêne occasionnée.

(traduction rapide et approximative)

Voilà. Du coup, pour le moment, j'ai fait un formulaire de contact tout simple en PHP, comme on apprend à en faire dans les livres pour débutants. N'importe qui peut accéder au formulaire (en HTTPS auto-signé, désolé) et me contacter sans que je sache qui c'est. On est quand même loin de PrivacyBox, puisque l'utilisateur doit accéder à mon serveur web pour me contacter. Mais c'est mieux que rien.

Par contre ce genre de formulaires, ça attire tous les bots aux alentours rien qu'à l'odeur. Plutôt que de mettre en place un captcha inefficace et indéchiffrable, je tente une astuce que j'ai lue chez l'ami Tontof.

Le principe est simple, il suffit d'ajouter un champs texte appelé "message" dans votre formulaire, mais qui est caché en JavaScript :

document.getElementById('message').style.display = 'none';

Les bots, qui ne sont pas réputés pour faire dans la finesse, vont évidemment remplir ce champ alors que les humains ne le feront pas : le champ est invisible au rendu. Il ne reste plus qu'à valider le formulaire si le champ "message" est vide.

Je saurais rapidement si c'est efficace, ou non. En tous cas, c'est astucieux.

Si vous avez des idées pour améliorer l'aspect anonyme ce formulaire, ou si vous connaissez des services similaires à PrivacyBox, n'hésitez pas.

PrivacyBox est un service en ligne allemand qui permet d'autoriser ses utilisateurs à être contacté de manière complètement anonyme. Je l'utilisé d'ailleurs dans ma page de contact. Malheureusement, après 5 années des bons et loyaux services, PrivacyBox nous annonce qu'il va disparaître ; encore un, parmi les bons.

Parce que je pense qu'il est important de toujours laisser la possibilité de l'anonymat, je vais remplacer ce service par un simple formulaire, faute de mieux.

Voici ce qu'on peut lire sur le site de PrivacyBox - j'ignore depuis combien de temps et pour combien de temps :

PrivacyBox est désormais en fin de vie

Le service PrivacyBox a été lancé en 2008 par la German Privacy Foundation 
e.V. (GPF) et a réuni de nombreux utilisateurs depuis lors. Aujourd'hui 
l'outil est dépassé, à la fois techniquement et conceptuellement.

Pour le moment la GPF ne prévoit pas de développer une nouvelle version. 
Il n'y a pas encore de date fixée pour la fermeture du service PrivacyBox, 
mais nous vous informerons suffisamment à l'avance. Malheureusement, 
nous ne pouvons plus répondre aux demandes de support.

Nous voulons remercier tous les utilisateurs de PrivacyBox pour leur 
confiance, et nous excuser pour la gêne occasionnée.

(traduction rapide et approximative)

Voilà. Du coup, pour le moment, j'ai fait un formulaire de contact tout simple en PHP, comme on apprend à en faire dans les livres pour débutants. N'importe qui peut accéder au formulaire (en HTTPS auto-signé, désolé) et me contacter sans que je sache qui c'est. On est quand même loin de PrivacyBox, puisque l'utilisateur doit accéder à mon serveur web pour me contacter. Mais c'est mieux que rien.

Par contre ce genre de formulaires, ça attire tous les bots aux alentours rien qu'à l'odeur. Plutôt que de mettre en place un captcha inefficace et indéchiffrable, je tente une astuce que j'ai lue chez l'ami Tontof.

Le principe est simple, il suffit d'ajouter un champs texte appelé "message" dans votre formulaire, mais qui est caché en JavaScript :

document.getElementById('message').style.display = 'none';

Les bots, qui ne sont pas réputés pour faire dans la finesse, vont évidemment remplir ce champ alors que les humains ne le feront pas : le champ est invisible au rendu. Il ne reste plus qu'à valider le formulaire si le champ "message" est vide.

Je saurais rapidement si c'est efficace, ou non. En tous cas, c'est astucieux.

Si vous avez des idées pour améliorer l'aspect anonyme ce formulaire, ou si vous connaissez des services similaires à PrivacyBox, n'hésitez pas.

Le célèbre service Github, incontournable pour beaucoup de développeurs, fête aujourd'hui ses 5 ans d'existence. Le service fête aussi son succès et sa croissance impressionnante, surtout après la levée de $100.000.000 l'été dernier. Github compte aujourd'hui 3,5 millions d'utilisateurs, soit deux fois plus qu'en juillet dernier.

Mais aussi pratique et ergonomique que soit Github, il n'en reste pas moins qu'un service en ligne, avec un business model. Je reste convaincu que l'open source et l'auto-hébergement sont à privilégier et à promouvoir.

Je vais donc vous présenter mon dernier projet en date : Public GitLab !

GitLab est un super projet open source codé en Ruby on Rails dans lequel on retrouve les fonctionnalités et l'ergonomie de Github. Vous pouvez voir à quoi ça ressemble sur la démo officielle. Tout y est : la gestion des repositories Git, le bug tracker, les merge requests, le wiki, les fichiers en Markdown avec coloration syntaxique, etc.

Le seul problème, et les développeurs de GitLab font de la résistance là dessus, c'est qu'il n'y a pas de repo publics. Ils considèrent que c'est un outil destiné destiné aux entreprises (i.e. à un groupe de personnes restreint), et pour une raison qui m'échappe, refusent d'implémenter un mode public.

L'outil n'est donc pas adapté pour l'hébergement de projets open source, ni pour les particuliers (comme moi :)).

J'ai donc un peu tweaké GitLab pour que mes repositories soient publics, et que n'importe qui puisse s'inscrire pour rapporter un bug. J'ai mis mes bidouilles au propre, et voilà le fork Public-GitLab, pour tout le monde.

Vous pouvez visiter tout ça sur git.hoa.ro.

Bien sûr, rien de m'empêche de créer quand même des repo privés, qui ne sont accessibles qu'au membres habilités ; et je n'ai pas besoin de payer Github pour ça !