Mettre en avant les nouvelles features

Il est souvent très difficile de repérer les nouvelles fonctionnalités qui débarquent sur le site. Une façon de faire qui est de rajouter devant chaque nouvelle feature une marque pour montrer que c'est nouveau. ça permet non seulement de donner envie de tester, mais aussi d'être plus indulgent si ça bug (car contrairement aux autre features éprouvées, elle est nouvelle).

ça pourrait donner quelque choses comme ça.

Je trouve que ça perturbe la navigation, ce gros truc rouge. A mon avis, une bonne explication dans l'article dédié à la release suffit.

Ou un peu moins voyant, type "Aider les auteurs^{new !}"

Jusqu'à quand resteraient ces mentions ? La release suivante ?

Pourquoi pas ?

Ca fait pas un peu "web des années 2000" ?

Mon coup de pinceau n'est pas génial (surtout avec paint), ça marche mieux quand je modifie le html directement.

C'est le genre de chose qu'on voit habituellement sur des sites (google pour ne citer qu'eux) et je trouve que ça met en lumière une nouvelle fonctionnalité majeure. C'est complémentaire à l'article pour les nouvelles version.

Je dirais que la mention devra rester uniquement le temps de sa release. Par exemple, la 1.6 arrive avec l'API, ça pourrait être sympa d'avoir un truc du genre à coté de "API" qui se trouvera dans le footer.

Ca va déjà mieux. Par contre, "Nouveau" est un peu long. A côté de "API", ça fera probablement trop. Personnellement, je ne dis pas non à une petite icône.

Ça pourrait être pas mal mais il ne faut pas que cette marque empêche la nouvelle fonctionnalité de fonctionner correctement ! Et il faut penser à l'enlever à la version d'après…

C'est chouette et ça pose la très bonne question de la visibilité des nouvelles features.

Par contre, pour un truc comme ça j'aurais tendance à dire : "si c'est pas automatique, ça va casser les c*uilles".

Effectivement va falloir le mettre à la main, passe encore, et surtout ne pas oublier de le virer… Ça c'est moins évident. Autant le premier j'y crois : tu développes un nouveau truc dans un template, tu mets la class "new-feature" qui en CSS fait un ::after(content:"New") par exemple. Autant le second ça me paraît complexe d'y penser, donc faudrait un moyen ou un autre de tout ràz.

La solution infâme pour faire ça serait d'annoter les nouvelles features (la classe CSS dont je parlais) par le numéro de version dans lequel elles ont été introduites. Pour une version donnée, dans la CSS on aurait uniquement new-version16::after etc. si on est en 1.6. Le <a href="lalalal" class="new-version15"> sera toujours là, mais pas décoré.

C'est le truc le plus crade auquel j'ai pu pensé. Mais y'a certainement pire :\

Dans tous les cas, les nouvelles features seront recensées dans l'article de la release, non ?

Dans tous les cas, les nouvelles features seront recensées dans l'article de la release, non ?

Euh, oui… C'est déjà le cas, y'a pas de raison que ça change.

Après je suis d'accord avec firm1 que tout le monde ne lit pas les articles de release, et que mettre en avant le fait que la plateforme évolue, qu'il existe de nouvelles fonctionnalités que des gens ont développées et qu'elles peuvent être utilisées. Que potentiellement c'est sujet à amélioration parce que c'est tout neuf, etc. me semble être une bonne idée.

Et ergonomiquement, le meilleur moyen pour indiquer une information relative à une fonctionnalité, ça reste sur la fonctionnalité elle-même, pas dans un changelog à l'autre bout du site.

Après oui, ça pose des problèmes techniques assez pénibles à résoudre. Mais je comprends pas franchement ton argument.

Ce que je veux dire, c'est que la liste des "New" à supprimer sera disponible dans l'article de release et donc que ça ne sera pas si prise de tête que ça (même si ça le sera).

@Javier:

J'avoue que techniquement je n'ai pas mieux que la solution crade de Javier.

Je me demande même si ça n'est pas possible de référencer dans notre fichier settings une variable new_features qui peux contenir l'ensemble des identifiants html des liens qu'on voudrait mettre en lumière. Ainsi, le travail de mise en lumière se fait au déploiement.

'fin ça me semble moins crade, mais un peu crade quand même.

Bref, je ne sais pas comment les gens le font habituellement, mais ça doit pas être simple

@Vayel : l'article pour moi à sa place parce qu'il donne des détails, etc. Mais tout le monde ne va pas tout lire. Alors qu'en tombant sur un lien estampiller "New", il va se dire "ah, je ne comprends pas comment l'utiliser, je vais aller lire le morceau de l'article qui en parle". Et de plus, s'il tombe sur un bug, il va pas se dire "Pff, ZdS est un site buggué", mais il aura tendance à se dire "Bon, la nouvelle feature est buggué, c'est normal, mais le reste du site est plutot cool".

Est ce que la solution de Javier ne peut pas suffire ? Il "suffira" ainsi aux dev front de passer de temps en temps sur les templates pour virer les features qui ne sont pas décorrés. J'imagine qu'un bon IDE doit pouvoir récupérer rapidement la liste de tous les éléments décorés avec une classe en particulier.

On ne se comprend pas. J'approuve l'idée qu'il faut et un article de release et des marques distinctives pour les nouvelles features. Mes messages réagissaient à cela :

Comme elles sont listées dans l'article de release, il sera assez simple de leur faire la chasse.

Théoriquement elle pourrait suffire. Mais comme le dit Javier ci-dessus, il faudrait le faire à chaque fois, c'est pas la mort non plus, mais ça doit exister une solution plus propre quand même.

@Vayel : Ah ok. C'est pas si gravissime si on ne les vire pas non plus je suis d'accord avec toi là dessus.

Bah à la réflexion Kje, je suis même pas certain que y'ait besoin de faire le ménage.

C'est pas complètement délirant de conserver cette marque dans le code.

Et au lieu d'une classe CSS on peut même imaginer un data-added-version peut-être un peu plus sémantique ? Je suis pas franchement spécialiste mais ça me semble moins affreux.

1. ça gêne pas (ça alourdit de pas grand chose et ça apporte une vraie info)

2. ça permet, le jour où on le décide de marquer des éléments un peu à la façon du @Since dans certaines doc. Si jamais ça a un intérêt… Ce qui reste à démontrer.

L'avantage de cette solution c'est vraiment qu'elle se maintient toute seule.

J'aime bien la solution a coup de data-added-version on a un truc vraiment sémantique et dédié à ça. Et du coup c'est déjà plus simple a maintenir qu'une classe css.

En tout cas techniquement je suis pour.

Bon je viens alors que le sujet est bien avancé.
Perso, je ne suis pas convaincu de l'utilité de la chose.
Si un nouvel arrivant arrive, il s'en fiche que la fonctionnalité soit nouvelle ou non ?
Si l'utilisateur est habitué :
Soit il s'en fout.
Soit il veut la tester et la c'est utile, mais c'est souvent dit lors de l'annonce d'une version. La personne sait donc ce qu'elle souhaite tester.
Soit elle l'attendait et du coup elle le voit plus facilement. À mon avis c'est le seul cas utile. Mais je pense qu'elle a autant de chance de la voir dans la liste où on met les nouvelles fonctionnalités en avant que sur la page qu'elle visite.
Du coup pour moi, le "nouveau" n'est pas super utile mais mettre une page avec toutes les nouvelles fonctionnalités un peu plus pratique.
Sinon +1 pour le data-added-version si la solution se met en place un jour.

Si un nouvel arrivant arrive, il s'en fiche que la fonctionnalité soit nouvelle ou non ?

Ce n'est pas mon cas par exemple. Si j'arrive sur un site et que je tombe sur un truc buggué après 2 minutes de navigation, j'aurais une mauvaise image de la plateforme d'entrée. Si j'arrive sur le même site et que je tombe sur un bug alors que je suis passé sur une feature estampillée "new!" j'ai tendance à me dire "ok, ça va, c'est parce que c'est neuf"