Piste de réflexion pour le prochaine version majeure de Jeedom (4 ou plus)

Salon des Bêta-Testeurs Core
1

Bonjour,

J’ouvre ce sujet pour exposer nos pistes de réflexion à long terme sur Jeedom pour les évolutions.

IMPORTANT : c’est juste des pistes donc ça peut être fait comme ne pas être fait, je ne rentrerais donc volontairement pas dans les détails (pour éviter des débats sur des fonctionnalités qui ne seront ou pas faite).

IMPORTANT : c’est une vision a long terme, sur du 2 ans. C’est pas forcement l’habitude de Jeedom de faire ca on essaye pour essayer de mieux prévoir l’avenir

Voila ce à quoi on a pensé :

  • Suppression des ajax et de l’api (sauf api url) pour un passage en mode REST
  • Séparation de l’interface en 2 : une de visualisation (toute la partie Acceuil) et une de config
  • Réécriture de l’interface de visualisation avec un framework moderne (type reactjs) en mode « webpack » (qui passerai donc par l’api rest)
  • Nettoyage de code jugé redondant :
    • les actions sur valeur
  • Nettoyage des pages en supprimant les fonctionnalités trop complexe et peu utilisée

Voila pour le moment, tout ca c’est que de l’étude il n’y a rien d’acté pour le moment on veut juste essayer d’avoir une roadmap en grosse lignes pour les années a venir.

N’hesité pas a proposer vos idées (toujours en pensant que la on est en grosse maille)

1 « J'aime »
2

J’applaudis la démarche.

Pas d’avis sur les éléments techniques tels que ajax, reactjs … car incompétent.

Par contre comme déjà évoqué, Jeedom mériterait d’être plus ergonomique. C’est un sujet complexe, car chacun a sa vision de cette science :smiley:

Le choix de séparer l’interface end-user de la partie configuration est probablement une des pistes. Le constat est que l’application mobile ne répond pas à ce jour a certains usages et de l’autre la webapp pourrait gagner en ergonomie. Mais si changement il y a côté Jeedom sur l’interface user, la webapp devrait en hériter.

Et une refonte du OnePage pour qu’il soit efficace dans toutes les situations serait bien. En gros signer la mort de la touche F5 du clavier serait une grande victoire.

Le fonctionnement des plugins pourrait aussi être revu. Avec la possibilité le lier leurs fonctions dans les scénarios. Un plugin de notification (telegram, SMS, Slack, …) serait identifié comme tel, et une fonction (brique) des scénarios pourrait appeler ces sous-ensembles. Sans pour cela faire une usine de boucles IF/THEN/ELSE qui pour le commun des mortels est tous sous intuitifs.
En gros une grosse réflexion sur les scénarios, scènes, et interactions entre eux.

Concernant la suppression de certaines fonctionnalités, l’expérience montre que par exemple le retrait du menu de gauche n’a pas toujours été opportun. Mais comme tout c’est des avis personnels qui ont du mal a se rejoindre.

Il reste l’harmonisation des widgets. Aujourd’hui chacun refait ces widgets pour suivre l’évolution du core. Cette capacité de créer des widgets est un réel plus pour Jeedom. Mais la dérive est le market qui fournit encore des widgets incompatibles.
A voir quelle réflexion il peut y avoir sur cette fonctionnalité.

1 « J'aime »
3

Faudra faire très attention avec çà… Au risque de frustrer les 5% qui les utilisent, mais qui sont aussi souvent les 5% les plus connaisseurs et ambassadeurs de Jeedom … Il faudra en discuter avant, fonction par fonction je pense. Quitte à proposer une autre solution à chaque fois.

Perso, niveau fonctionnalités c’est déjà assez ouf ce qu’on peux faire et aujourd’hui, je ne me sens absolument pas limité, au contraire. Ce qui est rare, car j’ai l’habitude de pousser ce que j’utilise …

Le gros à mon avis, devrait être sur le coté ergonomie mais c’est déjà pas mal du mal, et surtout UI. Là çà pêche, et çà ne reflète pas le qualité de ce qu’il y a derrière. Mais c’est aussi un énorme sujet. Mood board, inspirations etc tout en sachant que tout le monde ne sera jamais d’accord. Et derrière beaucoup de dev évidemment.

En tout cas, j’apprécie vraiment ce genre de discussions, et l’avenir de Jeedom passera un jour ou l’autre par l’ouverture des (du) devs.

1 « J'aime »
4

Effectivement l’idée principal de la version 4 est de revoir l’interface pour la rendre plus user friendly. L’idée est déjà de trouvé le framework pour que l’on puisse voir les éléments graphique a notre disposition dans celui-ci puis de faire des design et enfin de le coder. Le soucis étant plus les contraintes :

  • comment faire pour la personnalisation des widgets ? Si on change vraiment de framework tous les anciens ne seront plus compatible, dans ce cas ne vaut-il pas mieux juste passer a bootstrap 4 qui reste proche de bootstrap 3 toujours en jquery ?
  • doit on revoir toute l’interface ou que celle du core ? Ça éviterai une incompatibilité avec tous les plugins qui obligerai tous les dev a refaire leur interface
  • comment simplifier l’interface ?
  • on veut aussi unifier l’interface desktop avec l’interface mobile (ça simplifiera le maintient)

Beaucoup de question mais pour l’instant peu de réponse.

5

Je vais en profiter pour soumettre une idée un peu générale et quelques unes plus précises (mais qui est quelque part un exemple).

L’idée ca serait de standardiser en ajoutant plus de fonctions communes dans le design. L’exemple qui me vient en tête est le bouton « scan » qui dans les plugins le permettant se retrouve sous la forme d’un bouton sur la page équipement. Si ce genre de fonction commune pouvait être ajouter comme les dépendances et daemon, jeedom y gagnerait. Par exemple dans le info.json un « hasDiscovery » true, simplement, et une normalisation de la fonction en imposant un nom ‹ discover › par exemple toujours comme les autres methodes communes qui existent déjà.

La méthode wu watchdog des plugins pourrait être elle aussi implémentable par plugin. Tous ne vont pas dépendre des mêmes critères.

Après côté interface, si c’est jouable dans le choix du framework ou son implémentation, un bon point ca serait là encore allez vers une uniformisation en permettant de définir les pages équipement via un squelette et pas la page html complète. Par exemple un json qui pour un eqLogic et ses commandes définies quels arguments configuration sont visibles ou non, writable ou non, select ou champ libre …
De facon à garder le rendu final toujours sur le thème de jeedom. Et pareil les boutons scan, ajout, meme la page santé pourrait être directement placé par jeedom via le info.json. Le core redevenant responsable de l’affichage de la page, le plugin lui dit juste ce qui doit y apparaitre. Cohésion graphique à travers les plugins.

1 « J'aime »
6

Y’a des trucs sympas sur bootstrap v4 !
çà pourrait être bien, et ne pas casser tout les plugins …

https://themes.getbootstrap.com/preview/?theme_id=1468&show_new=

En plus, theme light / dark !

Perso, plus d’ombre, adieux les bords arrondi, tuiles de taille verticale identiques (au moins par object), et histoire de marquer le coup, theme dark par defaut !!

7

Oui j’ai vu mais le changement de bootstrap 4 est majeur donc ça cassé tout…

8

Et bien tant pis cassons tout, faut bien avancer.

Après c’est de la com et de la prévention. Y’aura des v3 et des v4 pendant qql temps et ça évitera les vieux plugins plus maintenus. Sélection naturelle :joy:

9

Bonjour et bonne année

Y a des choses intéressante et beaucoup de boulot
Bon courage

10

Oui et beaucoup de conséquence en fonction des choix aussi bien pour les dev que les utilisateurs d’où l’idée peut être de soumettre un questionnaire a la communauté pour voir ce que les gens préfèrent.

11

Des conséquence pour les dev est plutôt minim et gérable avec le legacy, par contre pour les utilisateurs si une mise a jours casse tout, j’ai peur que se ne soit pas tres bien vue

12

C’est pour ça qu’on veut en discuter avant pour voir ce qu’en pensent les bêta-testeur les dev et les utilisateurs

1 « J'aime »
13

Oui vous avez bien raison

14

Attention quand même avec le sondage. C’est louable de demander l’avis des utilisateurs et il faut bien sur en tenir compte, mais la vision à moyen/long terme de Jeedom c’est à vous et personne d’autre de la définir, donc ne vous perdez pas en chemin non plus. Le meilleur moyen de ne satisfaire personne, c’est de vouloir satisfaire tout le monde…

Passer en bootstrap V4 me semble une bonne solution, puisqu’on est terrain connu (et pas en terre inconnu) et c’est légitime, la suite logique à laquelle il faudra de toute façon passer.

Cela dit, si on a une V4 qui casse les plugins, çà veux dire que sur le market il va falloir développer deux versions des plugins, une V3 comme actuellement et une V4 pour les Jeedom V4. Au moins pendant un temps, 1 an ou 2 je dirai. Donc y’a déjà du boulot en amont, car tout les développeurs de plugins vont devoir passer sur un core V4 beta pour produire des beta puis stable de plugins V4.

Il faudrait donc balancer rapidement une dernière version stable du core V3, qui ne bougera plus sauf bugfix/security en attendant la V4.

Graphiquement parlant, faut-il tout casser et changer de theme, je ne sais pas.
J’ai regardé pas mal de choses (envato etc) et pas trouvé qql chose qui répondrai à tout les besoins. Entre les trucs super lents, les statiques, ceux qui n’ont pas toutes les fonctions, etc … Par contre il y a de très bonnes idées, mais qui sont faisable actuellement.

Le gros truc qui peu faire un bon en terme de design, ce n’est pas les tuiles, mais les widgets (les jauges, etc…).

Globalement il faut quelques chose de fin, de sobre, de classe :kissing_smiling_eyes:

Un exemple de mon dashboard perso, avec un darksobre customisé et qql css, un fond uni avec un léger dégradé mais sans texture, etc. Je dit pas que c’est le top, loin de là :smirk:, juste qu’on peu peut être pousser le design avec ce qu’on a déjà.

flat
flat1489×788 604 KB

Et sur mobile

flat_mobile
flat_mobile402×749 149 KB

J’aime bien çà sinon

dashboard
dashboard800×600 81.6 KB

fa79acc98680cfcfb314e6ab01260303
fa79acc98680cfcfb314e6ab012603031200×1882 253 KB

Sobriété et finesse en somme.

Je pense aussi qu’il faudrait virer les thèmes actuels, et en avoir un très bon avec un switch light / dark.
Tout en permettant d’en faire des custom comme aujourd’hui.

3 « J'aime »
15

Oui oui mais le sondage va nous orienté faut attendre les résultats définitifs mais la on commence a voir que les gens ont du mal entre la webapp, l’App mobile et la version desktop…

J’ai donc commencé a travailler sur l’Alpha a rendre la version desktop responsive pour voir si elle peut potentiellement renplacer la webapp.

Une fois ça fait je pensais simplifier les widget avec widget vue/dashboard identique et widget design. Ça permet de simplifier pas mal je pense. Au passage revoir le dashboard pour qu’il gère la taille des widgets lui même (et donc le resize ne se fera que sur les design)

Ensuite une fois je pensais dans toute les pages d’utilisation passer en full js.

Enfin une fois que c’est fait séparer l’utilisation pour la passer en bootstrap 4 et la configuration pour la laisser comme maintenant.

Tout ça c’est des idées pour le moment rien de fixé et je sais même pas si tout est faisable…

16

Oui çà ne m’étonne pas, mais j’ai vue beaucoup de thème bootstrap 4 qui fonctionnent parfaitement en desktop et en mobile, c’est plutôt bon signe.

Par contre faudrait voir à supprimer les css en px je pense non ? Que des calc, %, em
A voir si on conserver aussi des inline style partout. Pour les templates des plugins, pourquoi pas un fichier desktop/plugin.css
Faut structurer et simplifier à mort la partie css/js quitte à être plus stricte.

Une autre piste, moins colorée mais en conservant les couleurs de catégories avec un border-left. C’est fait à l’arrache en live hein, mais c’est une idée. Bon du coup je perd le padding, les couleurs de boutons sont pas belles etc… J’ai bien dit à l’arrache.

Par contre j’arrive pas à affiner les jauges, faudrai modifier le innersize du hightchart mais je ne sais pas quel fichier les génère, pas envie de tout casser non plus.

Loic, actuellement tu est partie d’un template ? Si oui lequel ?

vv
vv1179×598 298 KB

1 « J'aime »
17

Si on est sur que les plugins ne fonctionneront plus en V4, ne crois tu pas qu’avant il faudrait préparer le terrain ?

  • Une fois les résultats du sondage ok, prendre une décision et communiquer dessus. Annoncer le principe des changements, tout en rassurant sur une V3 toujours fonctionnelle
  • Nettoyer les branches du repo Jeedom Core
  • Sortir une stable du core 3.3.x
  • Préparer le market: Faut-il, pour les plugins V4, un autre repo, ou ajouter dans mes créations/éditer deux branches stableV4 et betaV4, et que le market affiche les compatibilités et la version à prendre en fonction de la version du core de l’utilisateur ? Donc en tant que dev de plugin on ajoute ces deux branches dans nos repos.
  • Créer deux branches du core alphaV4, betaV4 (stableV4 plus tard)
  • Pouvoir dans Jeedom, configuration, mise à jour, version du core : switcher sur alphaV4 / BetaV4
  • Une fois ok, les devs/betas qui sont prêt (plugins finalisés qui ne bougeront plus) switchent sur la V4. Alpha pour ceux qui veulent participer, beta pour ceux qui veulent tester et commencer à switcher leur plugin en V4 (beaucoup trop tôt encore mais c’est le concept)

Pour le coté desktop / mobile / app mobile en effet peut-être faut-il en V4 ne plus parler d’app mobile pour la version mobile. Ce serait simplement l’affichage responsive sur mobile (css @screen size) avec bien sur certains menus et fonctions non visibles en mobile. L’app mobile fera donc référence à la vrai application mobile android/iOS.

Et là on pourra je pense discuter tranquillement des changements profonds et tout casser sans impact pour ceux qui restent en V3. Et ceux qui le souhaitent pourront participer aux réflexions / dev du coreV4.
A voir comment se dispatcher le boulot aussi, savoir qui regarde quoi, quand tester quoi, etc. Donc pas sur le forum public, car il y aura trop de monde à gérer.

Et bien sur, fixer des objectifs très clairs : design, performance, fonctionnalités : où va t on ?
Si la V4 n’est pas rétro compatible, peut-être aussi en profiter pour nettoyer le code, qui traine peut-être d’anciens trucs ici et là.

Petit aparté d’ailleurs, mais quel est l’intérêt réel des Vue par rapport aux Design ? J’utilise pas mal de design, notamment avec l’app mobile (la vrai app) et c’est super pratique et complet. Du coup, même si j’ai déjà regardé, je n’utilise jamais les vue. Doit-on conserver les deux concepts ?? En plus avec les Design3D maintenant … çà va devenir compliqué !

Question subsidiaire : en tant qu’utilisateur, comment demain passer sa V3 en V4 ? Un outil qui check avant si tout les plugins installés sont dispo en V4 ? Une conversion des fonctions dépréciées si il y en a, etc. Il faudra une grosse com sur les changements, pour ne pas refroidir les utilisateurs qui pourraient en profiter pour aller voir ailleurs.

Et le sujet qui fâche : Quid de la doc ? Faut-il mettre en place une docV3 et une docV4 ? çà me parait compliqué quand même … Dans la mesure où les fonctionnalités ne vont pas changement drastiquement est-ce nécessaire.

Voilà pour les réflexions du dimanche matin … :beers:

18

Que veut tu dire par là ?

19

Sinon, avant de tout casser… qu’est ce qui fait que passer en bootstrap 4 casse les plugins ?

Parcequ’on pourrait aussi faire un thème propre sans tout casser non ?

20