Thibault Leruitte

Redesign of the Leonard crossroad

When you drive on the E411, from Namur to Brussels Ring, you go though the Leonard crossroad. The marking on the ground is basically the following.

Every time I take that road, I see a lot of freaking cars following this path.

However, the following path would be much more efficient. It would allow 2 lanes that do not cross each other from one end to another.

In order to achieve that efficiency, I propose to redesign the marking by following the scheme below. The road from the Ring to Namur already has a similar design by the way.

Thanks to @zulag for the review.

Critique de l’interface de Knowledge Plaza

Dans le cadre de mon mémoire, je suis amené à travailler avec Knowledge Plaza (KP).

KP est une plateforme de partage de connaissance. Bien que je trouve le concept excellent, en pratique, je trouve l’expérience utilisateur de KP désastreuse.

Pour remettre les choses dans son contexte, je suis un utilisateur récent de KP. J’utilise l’instance de KP déployée au sein d’Euranova. Je n’ai donc pas l’utilité de toutes les fonctions de KP. Le propos qui va suivre est mon opinion personnelle, et n’est en rien lié à l’opinion d’Euranova.

La principale critique que je vais argumenter est la suivante: KP est trop compliqué, et propose trop de fonctions. KP est notamment trop compliqué parce qu’il y a trop de notions. Un nouvel utilisateur de KP doit appréhender les termes de tile, mosaic, plaza, shelf, tag, facet, workspace, droit, bookmark, search, rating, wiki, etc.

L’interface est surchargé.

Par exemple, sur l’onglet du plaza, il n’y a pas moins de 7 barres de menu. Sept. Les menus 2, 3 et 4 se rapportent directement à la recherche, ça ne devrait être qu’un seul menu. Le bouton clear se retrouve même dans deux menus consécutifs. Il n’y a pas de raison de répéter cette même fonction à la suite.

La présentation d’un tile est surchargé. Les informations suivantes sont affichées:

1. le titre
2. le type (website, document, …)
3. le bouton pour ajouter des tags
4. les tags
5. la description
6. la date de publication
7. la personne qui l’a publié
8. la barre de menu qui apparait au survol de la souris
9. le nombre de commentaires
10. le nombre de bookmark
11. le rating

Pour rendre ça plus clair, on peut se passer de plusieurs informations sans soucis. Le nombre de commentaires et de bookmark, et le rating ne servent tous les trois qu’à mesurer la popularité d’un tile, on peut donc en faire un seul élément (j’y reviendrai).

L’élément qui est mis le plus en valeur de part sa couleur est le type de la tile. Cet élément est aussi celui qui au final est le moins intéressant. Si un tile retient mon attention, qu’est ce que ça m’apporte de savoir s’il s’agit d’un site web ou un PDF? Mon navigateur est de toute façon capable de le lire.

A côté de la liste des tags, un bouton « + » permet d’ajouter un nouveau tag. Quand un article n’est pas taggué, un lien permet d’ajouter un nouveau tag. Quand on passe la souris sur la tile, un menu permet d’ajouter un nouveau tag. Il y a trois façons de remplir la même fonction sur une surface de 600 sur 100 px, c’est de la répétition inutile qui n’a comme résultat qu’augmenter le bruit. Si il y a plusieurs moyens de faire, il y a au moins un moyen de trop.

Ratio données / metadonnées / bruit.

Dans les illustrations suivantes, j’ai tenté d’identifier les données en vert, les méta-données en orange et le bruit en rouge. La première illustration est le plaza, et la seconde est un tile.

Dans le cas du plaza, les données intéressantes sont le titre et le résumé des tiles. Ce sont à partir de ces données qu’un utilisateur portera son attention sur un tile ou non. Eventuellement, les metadonnées peuvent influencer cette décision dans une moindre mesure. On remarque que les tiles forment des blocs compacts, et qu’il est difficile de faire la distinction entre deux blocs consécutifs.

Dans le cas d’un tile, le titre, l’aperçu, la description et le résumé sont des données qui forment le contenu de la tile. Ces données occupent pourtant une place minime par rapport au reste de la page.

On remarque donc que le bruit est omniprésent et qu’il y a très peu de données sur une page. Dans l’idéal, il faudrait obtenir l’opposé: vert > orange > rouge.

Un formulaire trop long.

Le bookmarklet qui sert à ajouter une nouvelle tile propose un formulaire trop long. Ajouter une tile lors du surf devrait être une action rapide, un bon exemple est la prise de note de Things. Le bookmarklet de KP propose deux pages relativement courtes. Un premier point pour réduire le formulaire est d’en faire une seule page. (On pourra d’ailleurs faire de même dans toute la structure de KP, et fusionner l’édition des tags d’un tile avec l’édition du tile lui-même.)

La fonction d’ajout en tant que brouillon est répétée plusieurs fois. On peut soit cliquer sur le lien ajouter en tant que brouillon, ou placer le tile dans son workspace privé. En plus, si on décide d’ajouter directement le tile, il sera de toute façon ajouté en tant que brouillon, puisqu’il sera considéré comme invalide tant qu’il n’aura pas été validé manuellement après l’ajout.

Bien que dans le cas d’article scientifique, je peux concevoir la différence entre description et abstract, dans la plupart des cas au moins un de ces deux champs est inutile. On peut donc les fusionner, et on pourra mettre un abstract dans une description quand on en aura besoin.

Avec les droits qui me sont accordés, le champ privacy reste continuellement désactivé. Il ne serait donc pas nécessaire de l’afficher.

L’éditeur est bien fait.

Voici une note positive. J’aime la syntaxe de l’éditeur de texte, qui est simple et puissante. Des « = » pour les titres et des « * » pour les listes recouvrent la plupart des besoins. Il est juste dommage que l’éditeur du wiki propose une barre d’outils qui permet d’utiliser cette syntaxe, tandis que l’éditeur des commentaires ne la propose pas. Pour être cohérents, les deux éditeurs doivent être identiques.

Le rating, à quoi ça sert?

Puisqu’il m’est impossible de trouver les tiles que j’ai notés, je n’ai aucun intérêt de les noter. Les notations servent donc finalement uniquement à indiquer la popularité d’un tile. Mais attendez, pourquoi est-ce qu’un algorithme ne ferait-il pas le travail à ma place? Le nombre de commentaires, bookmarks, vues de l’article, et la date de publication feraient déjà des bonnes entrées pour cet algorithme. A la limite, un bouton « j’aime » à la Facebook pourrait remplacer les étoiles qui permettent de noter sur une échelle de 1 à 5. Une échelle, ça convient très bien lorsqu’il faut noter des choses subjectives, comme l’appréciation d’un film, ou une photo d’une personne sur un site de rencontre. Ca ne convient par contre pas dans ce contexte, ou on aimerait une notation objective de la qualité d’un article, d’autant plus si cette notation doit être décidée en consensus. (Cette échelle de 1 à 5 me fait d’ailleurs furieusement penser à l’échelle de Perceval.)

Il est même possible de noter une personne. Quelle entreprise se permettrait de noter négativement sur un tel site un de ses employés ou un de ses clients? C’est une fonction inutile, puisque les bonnes manières nous interdisent de l’utiliser.

Un wiki, c’est un tile.

Un tile, c’est une pièce d’information partagée. Pourquoi est-ce qu’un wiki n’est pas un tile, puisqu’au final il s’agit aussi d’une information partagée (qui en plus peut être éditée)? Pourquoi est-ce qu’il ne serait pas possible de commenter un wiki, comme un tile?

On ne peut créer un wiki qu’en créant un mosaic. Pourtant, ces deux concepts sont bien différents. Un mosaic, c’est un ensemble de tiles qui ont un sujet ou un intérêt commun. Un wiki, c’est un document modifiable par tout le monde. J’imagine que les concepteurs de KP ont voulu utiliser un wiki afin de permettre au créateur d’un mosaic d’expliquer le contenu de ce mosaic. Cependant, le wiki est un outil bien plus puissant, qui peut être utilisé dans de nombreux autres cas.

Le dashboard et le plaza sont identiques.

Par défaut, le dashboard et le plaza indiquent la même chose. 90% des tiles présentées sur le dashboard se retrouvent sur le plaza, et inversement. Je n’ai d’ailleurs jamais compris par moi-même ce qui différencie ces deux onglets.

Eric Delacroix m’a expliqué que le dashboard affiche l’activité sur toutes les tiles, tandis que le plaza n’affiche que les tiles nouvellement ajoutées. Puisque le dashboard et le plaza contiennent déjà tous les deux des barres de menu qui ont pour fonction de sélectionner le contenu affiché, il ne me semble pas opportun d’ajouter des onglets qui ont la même fonction. On pourrait donc supprimer un de ces deux onglets.

Pas de tags privé.

Les tags privés ne devraient pas exister, et je vais le démontrer par l’absurde. S’ils existaient, il devrait y avoir une version privée de tous les champs de metadonnée, afin d’être consistant. Il faudrait donc aussi un titre privé, une description privée, etc. Or, avoir une version privée de toutes les metadonnées et une idée horrible qui compliquerait bien trop les choses. Donc il ne doit pas y avoir un seul champ privé.

C’est un bazar!

Ceci est plus un sentiment, et j’ai moins d’argument pour l’expliquer. Néanmoins, après plusieurs mois d’utilisation, le sentiment général que j’en retire, c’est que KP ça reste un bazar. Pour trouver un tile, je peux soit voir les derniers postés, soit faire une recherche textuelle. Même si je suis fan d’un recherche à la Spotlight, si je ne connais pas le titre ou le texte d’un tile, j’aurai du mal à le trouver.

Ce qui manque, c’est une hiérarchie des tiles, par workspace, par mosaic. Un fil d’Ariane pourrait grandement aider à cette sensation de hiérarchie. J’aimerais trouver facilement les tiles que j’ai modifiés et ceux que j’ai bookmarkés.

Etonnamment, la notion de projet est absente de KP. Un projet, c’est l’énoncé général sur lequel on travaille. Pour ma part, mon projet est représenté par un mosaic qui porte le nom de mon mémoire, et qui a été créé par mon promoteur. Ce mosaic est celui que je consulte et édite le plus souvent. J’aimerais donc un moyen rapide de pouvoir le localiser à partir de la page d’accueil de KP.

Le shelf ne devrait pas exister.

Le shelf est une bonne idée en soit, c’est un moyen élégant de déposer un tile dans une mosaic. Mais au final, quand je l’utilise, je ne peux m’empêcher de penser qu’il existe pour une seule raison: KP est incapable de fournir une liste structurée des mosaics, et donc c’est à moi à me débrouiller à retrouver la bonne mosaic dans le bazar.

Conclusion

Knowledge Plaza propose un concept intéressant, mais qui est malheureusement effacé par une interface surchargée et qui propose trop de fonctions inutiles et répétées. Je pense qu’un redesign de l’interface dans la philosophie KISS serait bénéfique à KP.

Java rotable integer

JList qui ne sélectionne pas le dernier élément si on clique en dessous de celui-ci

Dans une JList, si afficher tous les éléments prend moins de place que la hauteur de la liste et si on clique en dessous du dernier élément, ce dernier devient sélectionné. Un moyen de contourner le problème est de supprimer tous les MouseListener et MouseMotionListener enregistrés à la JList, et d’implémenter son propre MouseListener.

Voici une solution d’implémentation assez simple. Si un clic est fait en dessous du dernier élément, plus aucun élément ne sera sélectionné. Attention, seul le mode SINGLE_SELECTION fonctionnera avec cette solution.