Joomla! 4 et au-delà : une vision pour l’utilisateur final

Qu’en est-il du futur de Joomla! ? Nous parlerons plus particulièrement dans cet article de l’utilisateur final ce cette future version.

Joomla! 4 et au-delà : une vision pour l’utilisateur final Qu’en est-il du futur de Joomla! ? Nous parlerons ici plus particulièrement de l’utilisateur final de cette future version. Dans le premier post de cette série nos avons exploré le message marketing unique pour Joomla! 4 et au-delà. Armés de ce résultat, regardons comment nous pouvons l’utiliser comme une vision actionnable, en commençant avec les améliorations qui affectent nos utilisateurs finaux. Le thème commun derrière toutes les améliorations apportées à cette vision pourrait être résumé comme “Ne les faisons pas réfléchir”.

Cet article est une traduction de l’article Joomla! 4 and Beyond: A vision for the end user par Nicolas Dionysopoulos.
Installeur simplifié
Wordpress vante qu’il possède une “célèbre installation en 5 minutes”. Ce n’est pas célèbre, ce n’est pas 5 minutes et ce n’est pas une installation complète. Elle établit simplement la base de données. Mais cela a l’air simple. La première expérience que quelqu’un a avec WordPress est “wow, c’est si simple”.
D’un autre côté, la procédure d’installation de Joomla! ressemble à passer une frontière de l’URSS.
Trop de formulaires. Trop de choix. Cela a l’air extrêmement compliqué. Je sais ce n’est pas le cas, mais les impressions des nouveaux utilisateurs sont “wow, ça a l’air vraiment compliqué”. Et dans le logiciel , tout comme dans les rencontres, les premières impressions font toute la différence.
Donc simplifions cela. Ne montrons par défaut que les options absolument nécessaires. Cachons tout le reste derrière un bouton cliquable “Mode Expert”. Vous savez quoi ? Nous pouvons même faire une page d’installation unique.
De plus, générons les fichiers .htaccess et web.config automatiquement. Faire des tests dans un sous-dossier du répertoire installation est simple et transparent pour l’utilisateur, et nous pouvons activer la ré-écriture d’URLs sans demander l’avis des utilisateurs, sans qu’ils aient à toucher des choses effrayantes à travers l’outil effrayant qu’est le FTP.
(Une illusion de) L’intégration Site et Admin
Je considère la séparation du site (frontend) et de l’admin (backend) comme une fonctionnalité très positive de Joomla!. Mais cela mène à la frustration des utilisateurs. Pourquoi dois-je avoir à entrer manuellement une URL spéciale pour accéder à mon panneau d’administration ? Et pourquoi dois-je me connecter deux fois avec le même identifiant et les mêmes mots de passe ? Pourquoi lorsque je me déconnecte du site, je ne suis pas déconnecté de l’admin, et vice versa ? Pourquoi y-a-t-il “deux pages” pour éditer le même article ou le même module ? Nous prenons cela comme un acquis, mais c’est très confus pour les nouveaux utilisateurs et pour les utilisateurs finaux qui sont chargés de la mise à jour du site et de son contenu.
Donnons l’illusion de l’intégration avec une connexion unique pour les deux applications.
Lorsque vous vous connectez à une application, vous vous connectez automatiquement à l’autre, tant que vous avez les droits adéquats. Oui, cela a de potentiels impacts de sécurité en ajoutant des vulnérabilités XSS, nous pouvons donc ajouter une fonctionnalité pour désactiver cela. Les utilisateurs avancés pourraient donc le désactiver.
Mode intégrateur
Combien de fois vous est-il arrivé de vous demander quel foutu module était publié sur cette page, quelles sont les positions de modules de ce template et quel est le template que vous devez surcharger pour changer cette partie du site ? Si vous construisez des sites de taille moyenne et supérieure, vous voyez ce que je veux dire.
Et si nous ajoutions un Mode Intégrateur dans la Configuration Générale, juste sous le paramètre Débogage système, qui donnerait une vision aux rayons X du frontend du site.
Une telle option pourrait

Vous afficher l’ID du module à coté du bouton d’édition.
Activer l’utilisation du tp=1 pour afficher toutes les positions de module disponibles, comme sous Joomla! 1.5.
Afficher une icône d’information avec chaque vue de template. Le passage de la souris afficherait le chemin relatif de la racine du site, du rendu original du template ET le chemin relatif vers la surcharge de template nécessaire. En marquant celui actif (original ou surcharge) avec du texte en gras.

Joomla! 3 Le Livre Pour Tous

Écrit pour toutes les personnes qui débutent avec Joomla!, ou qui possèdent déjà quelques connaissances avec les versions précédentes, et qui souhaitent construire et entretenir un site web sans avoir à entrer dans le code.

version numérique
{j2store}42||cart{/j2store}

version papier
{j2store}18||cart{/j2store}

Commentaires
Nous devons être le seul CMS de la galaxie à ne pas avoir de système de commentaires.
Pour le dire en criant, il n’y a pas besoin d’une excellente solution de commentaires, simplement une assez bonne.
Avez-vous déjà utilisé WordPress ? Si vous avez commenté ici (sur le site de Nicolas) vous l’avez déjà fait. Vous voyez comment le système de commentaires par défaut fonctionne ? C’est simple à en mourir. L’intégration ne fait pas partie du core, c’est un plugin. Le système de commentaires par défaut du logiciel de blogging le plus célèbre de la planète nécessite internet pour apprendre comment entrer du HTML brut. Je ne plaisante pas.
Et je vous le dit, nous allons relever le niveau. Vous devez juste choisir entre WYSIWYG, texte brut, bbCode ou balise pour le texte de commentaires ; profondeur des réponses jusqu’au niveau 5 (cela devient illisible ensuite) ; support des avatars (Gravatar par défaut, avec des plugins complémentaires pour d’autres avatars) ; permettre à n’importe quelle extension d’utiliser ce commentaire d’article (comme nous le faisons avec le com_categories) ; permettre aux plugins de contenu de pouvoir fournir des intégrations comme un service anti-spam (peut être intégré avec Akismet par défaut) ; permettre l’utilisation de notre système de CAPTCHA pour les invités, pour tous les utilisateurs, ou pour personne. Le temps de développement nécessaire est inférieur à celui produit par une seule personne pendant 1 mois.
Champs personnalisables
Pas nécessairement une fonctionnalité 4.0. Je ne vais pas vous mentir en disant que cela peut remplacer un CCK dédié.
Cela peut donner d’excellentes possibilités de personnalisation aux intégrateurs de site web.
Permettons des réglages de champs personnalisés par catégorie avec une méthode de rendu dans nos vues de templates. Si vous organisez cela correctement, vous pouvez stocker ces champs dans une table distincte (pas de données encodées JSON dans la table #_content) afin de les rendre recherchables. Et vous pouvez enrichir le système avec des plugins pour que des fournisseurs tiers proposent d’autres types de champs personnalisés. Comme je le dis, ce n’est pas un CCK mais cela aidera de nombreux utilisateurs pour créer des sites plus rapidement sans devoir alourdir leurs sites avec de nombreuses extensions tierces avec tout ce que cela signifie pour leur habilité de mise à jour…
Mise en place du contenu
Nous sommes déjà si près, mais cela n’est pas parfait. La mauvaise publicité de la fonctionnalité de versioning vous permet d’avoir une version “live” de votre contenu et plusieurs versions (par défaut 10) “non-live”. Vous pouvez même épingler certaines versions afin de les sauvegarder pour toujours.
Que ce passerait-il si nous améliorions le nombre à 2 ou 3 ? Nous pourrions avoir du contenu “live”, “mise en page” et “autre”. Ensuite, si l’utilisateur possède les droits nécessaires, nous pourrions avoir un module qui lui permettrait, en frontend, de changer entre deux versions. Nous pourrions même avoir un plugin qui activerait le contenu mis en page lorsque le site est consulté par certains utilisateurs, même s’ils ne sont pas connectés – si je veux tester le contenu pour les invités pas exemple. Puisque c’est une application globale, les développeurs tiers pourraient proposer leurs propres fonctionnalités de mise en page.
Cela nécessite des modifications sur la manière dont nous procédons avec les Ids d’articles, ce qui signifie que le site mise en page serait plus lent, mais je considère que c’est un impact acceptable.
Sans compter que ce que les gens demandent quand ils disent “multisite” est en fait une manière simple de mettre en page leur contenu.
Un gestionnaire de médias qui permettrait vraiment de gérer les médias
L’actuel Gestionnaire de Médias devrait être appelé correctement “navigateur de fichiers”. Un bon gestionnaire de médias doit stocker les metadonnées des fichiers des médias et vous aider à les organiser et à les chercher. Idéalement, un gestionnaire de médias propose :

Un support pour les différents types de médias : images, vidéos, audios, documents divers.
Un stockage des métadonnées pour chaque élément : titre, description, légende, tags, taille de fichier, dimensions (image, vidéo), durée (vidéo, audio), format, type MIME.
Plusieurs sources de médias. Chaque source peut être sockée localement, sur S3, CloudFiles, (S)FTP, Dropbox, etc. Cela peut bien sûr être enrichi avec des plugins.
Faisons que le gestionnaire de médias permette de redimensionner les images dynamiquement (en cache bien sûr). Chaque retouche dynamique d’image devrait également demander en permanence la confirmation à l’administrateur, avec jamais plus d’un seul clic.

Un éditeur WYSIWYG apte à la création de contenu
Ceux qui savent comment utiliser Joomla! remplacent l’éditeur par défaut par JCE. Les nouveaux utilisateurs se demandent pourquoi utiliser un éditeur si mal réalisé. Ma bête noire est d’avoir deux boutons pour les liens (un dans l’éditeur et un sous la zone de contenu) deux boutons pour les images (un dans l’éditeur et un sous la zone de contenu) et ainsi de suite. C’est de la folie ! Quelques améliorations simples :

Surcharger le bouton Lien de TinyMCE. Au strict minimum, permettre aux utilisateurs de chercher dans les articles et catégories natifs de Joomla!. Permettre l’ajout de plugin, et vous avez la même expérience avec JCE et WordPress. Se débarrasser des plugins editor-xtd. Les développeurs devraient être capables de fournir leurs propres plugins pour proposer du contenu cliquable à partir du bouton de l’Editeur à la place d’un bouton editor personnalisé.
Si vous insistez vraiment sur les plugins editor-xtd, les boutons devraient être insérés dans la barre d’outil de l’éditeur, pas sous la zone de contenu.
Laissez l’éditeur s’étendre en hauteur lorsque le contenu devient important sans grandir plus que ce que ne permet la taille de la fenêtre. Utilisez WordPress pour écrire un long article et vous comprendrez ce que je veux dire.
Egalement, donnez à l’éditeur un mode full screen (plein écran).
Utilisez le Drag & Drop pour ajouter & charger les médias dans le gestionnaire de médias, et pour les insérer dans le document.
Copier un lien Youtube devrait instantanément convertir l’intégration sans avoir besoin d’utiliser un plugin tiers et utiliser un code étrange du style {youtube}abcdef123{/youtube}. Assurez-vous que cette fonctionnalité permet le support des plugins afin que les développeurs tiers puissent proposer des services dont nous n’avons peut être jamais entendu parler, mais dont certains utilisateurs ne peuvent se passer.

module-boutique-2
Simplifier les paramètres – Organisation du flux de travail
Au cours des 5 dernières années, nous avons ajouté des fonctionnalités à tous les composants natifs, en quantité équivalente.
Les pages de paramètres des composants natifs ont l’air plus compliquées que le cockpit d’un avion moderne.
Nous avons besoin d’un affichage “Mode débutant”. N’afficher par défaut que les paramètres les plus pertinents et cacher le reste derrière un bouton “Mode expert”. Cliquez-le pour accéder à tous. Si vous pouvez choisir quelles options afficher vous avez amélioré le flux de travail.
Mais le gestionnaire de flux de travail a besoin de plus que cela. Au minimum, je peux imaginer un système qui définit ce que peut faire chaque groupe d’utilisateurs dans le Backend, basé sur certaines conditions. Comme cela n’est vraiment pas ma spécialité, j’aimerais que les personnes expertes UX et workflow management donnent des retours.
Routage et menus
C’est en fait un élément pour le billet de demain, mais puisqu’il affecte l’utilisateur, j’ai décidé d’en parler un peu.
Le fait que les menus définissent le routage (les URLs) est frustrant.
Les gens doivent créer des menus cachés pour créer des URLs personnalisées. S’ils ne font pas attention à l’utilisation de l’alias vs l’élément réel, ils vont se retrouver avec du dupplicate content ou le composant va faire “d’étranges” redirections qu’il est impossible de debugger. A mon avis, les éléments de menu et le routage doivent être découplés, même si cela va déplaire à de nombreux utilisateurs.
Améliorer le multilingue
Sommes nous tous d’accord pour appeler cela “multilingual” et non “multilanguage” ? La dernière fois que j’ai vérifié notre langue par défaut était English (UK) pas Joomla! Creole.
Le défaut principal du multilingue dans Joomla! 3 est qu’il est compliqué et qu’il est presque impossible de paramétrer un site web existant.
Déplaçons le paramètre multilingue de l’installeur à l’intérieur même du CMS. Permettons aux utilisateurs d’activer le multilingue quand ils le souhaitent. En l’activant, des copies de leurs éléments de menu seraient créées mais la langue ne serait PAS publiée de suite.
Lorsque vous créez un élément de menu vous avez un paramètre permettant de régler de multiples langues permettant à l’utilisateur d’entrer le nom de l’élément de menu et l’alias pour toutes les langues disponibles. La création des éléments de menu et les relations de langues se font automatiquement pour toutes les langues additionnelles. Lorsqu’un élément est créé dans un menu qui a la page par défaut réglée sur une langue spécifique le paramètre langue est automatiquement réglé sur la valeur du paramètre de la page par défaut. Lorsque vous copiez un élément de menu, une catégorie, un article, etc…, d’une langue A vers une langue B la création de l’association des langues entre l’article original et la copie se fait automatiquement. NE ME FAITES PAS CROIRE !
Améliorer la gestion des ACL
J’ai utilisé ACL Manager sur les sites que j’ai construits ou créés car cette extension a une fonctionnalité fondamentalement manquante nativement : le debugguer ACL.
Nous avons besoin d’un débugger ACL. Donne moi en fin de nœud (élément de menu, article, catégorie,…) un nom d’utilisateur qui me montre le résultat des privilèges ACL. Pour la règle Refusé, montre moi quelles règles causent le Refusé. Permets moi également d’entrer mes propres autorisations ACL (p. ex. comm_foobar.quelquechose) et effectue la même analyse. Encore mieux, laisse moi sélectionner un nœud ACL et montre moi toutes les autorisations de groupes. Aide-moi à comprendre ce qu’il se passe sur mon site !
Import et export de contenu
Comment transférez-vous actuellement du contenu entre deux sites ? En faisant des copier coller comme dans les années 1950.
Nous pouvons faire mieux que cela. Nous devons faire mieux que cela. Je sais que c’est un sujet délicat pour deux raisons. Premièrement à cause des ACLs et de l’incompatibilité de faire correspondre les Groupes d’Utilisateurs et les Niveaux d’Accès entre deux sites différents. Mais ce n’est pas un problème. Essayer de voir si les données correspondent, et si ce n’est pas le cas, avertir l’utilisateur et continuer l’import avec les privilèges/accès par défaut. L’autre point délicat est que la longueur de l’import/export peut mener à un timeout, une insuffisance de mémoire ou quelque chose de pire. Nous ne pouvons rien faire d’autre que de permettre les exportations partielles, p. ex. en sélectionnant un nombre spécifique d’articles ou de catégories à exporter. En parlant de cela , si nous voulons ajouter le support pour l’importation du format XML de WordPress, cela permettrait aux utilisateurs d’importer à partir de sources variées, pas seulement WordPress. Une migration simple conduit à une conversion simple.
A suivre : ma vision pour les designers et développeurs. Crédits photo
Image by Free-Photos from Pixabay