Parlons de Gladys V4

Oui, je reconnais :smiley:
Ton idée de grouper les actions faites en même temps permettrait de palier à ces problèmes oui !
Reste à voir ce que ça peut donner :slight_smile:

Côté UX c’est chouette, c’est simple et se concentre sur l’essentiel. Je verrai bien des champs « intelligents » qui vérifient en temps réel leur contenu (comme l’adresse mail de l’user ou la correspondance des mots de passe, et passe du rouge au vert quand c’est bon)

Concernant les services, si j’ai bien compris, ils seront tous installés de base, mais activable en fonction des besoins de l’utilisateur. Top !

Du coup, coté UI, je verrai bien également un élément visuel dans la tuile du service (page des intégrations) comme par exemple une barre d’une certaine couleur en bas de la tuile avec marqué le statut :

  • Activé : Barre verte
  • Activé, configuration requise : Barre jaune
  • Activé, Warning : Barre orange (s’il y a un intérêt pour cette fonctionnalité)
  • Activé, Erreur : Barre rouge (s’il y a un intérêt pour cette fonctionnalité)
  • Désactivé : Barre grise

Ensuite, je verrai bien une séparation visuelle entre les services actifs, et les services disponibles, ce qui ferait 2 catégories la première au dessus de la seconde.

Concernant les technologies employées, comment s’organiseront l’intégration des différents objets des différentes marques / créations personnelles ?

Je prends l’exemple du Bluetooth : Y aura t il un service Bluetooth maître qui se charge de faire des connexions, et des services dépendants qui gèreront chaque produit ou fonctionnalité
/marque comme la vérification de présence de l’utilisateur via les Nuts ou autre, les ampoules Awox, et des objets Bluetooth « maison »? Ou ce sera juste une séparation au niveau UI ?

Oh oui oui oui ! Snips :smiley: (je ne dirais pas non à XMPP ou Matrix/Riot d’ailleurs :stuck_out_tongue: )

Et je serai dispo pour tester l’alpha à sa sortie :wink:

1 Like

C’est bon je viens de créer les 18 issues, une par service, à développer pour cette première alpha.

Le milestone est disponible ici =>

https://github.com/GladysAssistant/gladys-4-playground/milestone/4

Si vous voulez donner un coup de main, et avez des disponibilités dans les jours/semaines qui arrivent, n’hésitez pas à mettre un commentaire dans l’issue qui vous intéresse pour indiquer que vous prenez le lead sur le développement de ce service :slight_smile: ça évitera que vous soyez plusieurs à travailler sur un même sujet. Et dès que vous commencez, je vous invite à créer une PR (que vous marquez comme « en cours »).

Je m’occuperais des services restants, mais bon le plus de coup de main vous me filerez, le plus vite Gladys 4 sortira :smiley:

On va faire au cas par cas par service. A priori le service bluetooth ça sera comme le service Z-Wave, tout sera dans le code du dossier « bluetooth ». Il y aura une séparation dans l’UI par clarté, mais derrière ça sera un seul service.

Commençons déjà par l’essentiel. On parle avant tout d’une alpha, et le temps de développement de chacun est limité. Mais si tu veux développer ces intégrations ce sera avec plaisir qu’elles seront intégrées :wink:

2 Likes

Salut @pierre-gilles,

Dans Gladys 4 tu stocks les actions des scenes en base directement au format JSON.
Cela me semble en effet bien pratique a parser et dev.
En revanche, si on supprime un device pour une raison x ou y raison.
Comment gères tu le cas dans ta scene ?

Bonne question!

On pourrait faire un passage à la suppression d’un device sur toutes les scènes pour chercher si le périphérique est utilisé, et si oui empêcher la suppression.

Cela ne risque til pas d’être super lourd ?
Il me semble que dans la communauté un mec a un camping.
Comment cela se passe til s’il a une multitude de scène avec chacune une multitude d’action ?

Les scène sont en RAM. Parcourir même 1 million d’éléments en pure JS, je pense qu’on parle en millisecondes :slight_smile:

Après ça se benchmark, il ne faut pas que ce soit lourd.

L’autre solution serait juste d’assumer que le cas peut arriver, et de gérer le cas intelligement si jamais une scène s’exécute et que le device n’existe pas.

A mon avis il faudrait faire les deux.

Ou peut-être insérer l’information dans le device ?
device = {
…,
scenes: [ 1, 5, 8 ]
}

En gros faire un lien dans les deux sens.

Je pense pas que dupliquer la donnée soit la meilleure des solutions. Là ça veut dire qu’il faut maintenir cette liste en plus de l’avoir dans les scène. On a encore plus de risques de corruptions de données

J’allais le proposer justement :

  • Parcourir les scènes et avertir (ou bloquer) lorsqu’un utilisateur veut supprimer un équipement utilisé
  • Prévoir le cas où un équipement n’existe pas dans une scène (comme s’il ne fonctionnait pas finalement), pour malgré tout permettre son exécution avec un avertissement.
    Car si la scène est complexe et accède à plusieurs équipements, même s’il en manque un il est souvent encore possible de l’exécuter.

Absolument :wink:

On peut imaginer des équipements « nécessaires » et « facultatifs » à l’exécution d’une scène : dans le premier cas, la scène s’arrête et se mets en erreur, dans le second cas, elle s’exécute malgré tout (et renvoie un warning ?)

Je ne vois pas l’idée ^^

Gardons les choses simples :slight_smile: Là on parle d’un edge case qui faut gérer, l’utilisateur n’a pas à se préoccuper de tout ça.

Salut à tous!

Aujourd’hui j’ai travaillé sur l’UI notamment sur la façon dont le/les dashboard seront organisé et la façon dont l’utilisateur pourra les éditer.

Et, j’ai un petit dilemme.

Remarque importante

Dans Gladys 4, je compte rendre possible la création de deux types de dashboard:

  • Le dashboard qu’on connait tous, le dashboard d’accueil. Il est fait pour des box assez large et présente 3 colonnes. Il sera probablement possible de créer plusieurs dashboard d’accueil, mais pas des millions non plus pour que ça reste organisé. En gros, c’est ça:

  • Un dashboard “full screen”, pratique pour les tablettes ou écrans muraux Gladys, avec des box plus petites et plus serré. Pratique pour condenser de l’information sur un mur, et avoir des contrôles rapides. En gros, un truc de ce style (image prise sur google image, ce sera pas ça):

33a3ff5cc5499ed9d25d6b58c66ca1ef

Ici, je parlerais du dashboard d’accueil.

La question

Le débat se situe au niveau de la grille utilisée, pour cela deux façons de faire.

  • System n°1: Soit on a 3 colonnes, et sur chaque colonne l’utilisateur répartie et fige lui même ou chaque box ira.

C’est à dire:

Chaque box a donc 2 coordonnées, X et Y. Rien de sorcier.

  • Système n°2 : Soit on a 3 colonnes, et l’utilisateur choisi juste l’ordre des box, et ensuite c’est le navigateur qui place intelligemment les boxs en fonction de l’écran et de la taille dynamique de chaque box.

La box n’a plus qu’une cordonnée, X.

Le placement est fait grâce aux “column-card” de bootstrap. C’est super smart et ça tente de mettre le maximum de donnée à l’écran en condensant tout.

C’est ce que j’utilise pour le Gladys Gateway par exemple.

Question: Qu’en pensez vous?

Le mode édition

Pour éditer les box, contrairement à Gladys 3, il ne sera plus nécessaire d’aller dans les paramètres, ce sera directement dans l’interface.

Je pense à un bouton “Edit”:

Qui quand on clique dessus, mets toutes les boxs en mode édition:

(juste la box user presence ici, c’est un exemple)

Pour l’instant je n’ai pas encore réussi à faire du drag and drop propre malheureusement, si quelqu’un est expert je suis preneur ^^ En attendant j’ai mis un système de flèche “Up” et “Down” pour bouger la box.

J’aimerais votre avis sur tout ça :slight_smile:

Je suis partisan du « drag-and-drop » sur 3 colonnes. Je trouve que niveau utilisateur et à l’utilisation c’est beaucoup plus parlant.
Quand je choisi de mettre une box « là », elle restera presque toujours « là ». Sauf si l’écran devient soudainement plus petit ou plus grand, bien sur.

En fait, j’aime bien pouvoir paramétrer mon dashboard et le retrouver toujours dans le même état.

1 Like

Salut, Perso je préfère la solution X et Y. Ça ressemble pas mal à Gladys 3 et surtout, comme dit plus haut, j’aime que les choses restent où je les aient mises ^^.

Après pour l’édition un drag on drop c’est top, mais les fleches ne me dérangent pas :slight_smile:

J’aime bien la deuxième solution, moins de taf en config, Gladys fait un premier jet et si ça convient pas, il suffit de réarranger par la suite en drag’n drop.
Si j’ai bien compris, une fois qu’on les bouge, elles restent fixes ?

A priori je vais partir sur la solution X, Y.

Justement, non! En fonction de la taille du contenu et de la taille de l’écran, les boxs sont arrangés différemment.

Dans l’exemple que j’ai donné, par exemple disons que si la box 5 était bien plus grosse, le CSS fait que ça irait se réarranger et mettre par exemple la box 7 au dessus de la box 8 pour que l’écran soit bien couvert de façon homogène.

Je pense que ça risque d’être pas clair. La solution « X, Y » est plus claire et le dashboard bougera pas. (sauf sur mobile mais ça c’est autre chose)

Drag and drop, je me met à la place de l’utilisateur qui je penses en 2019 s’attend à ça plutôt qu’un système de coordonnées. ( je sais c’est pas simple)

1 Like

A moins qu’il y ai un motivé, je suis prêt à prendre le sujet du Drag&Drop, avec preact, on doit pouvoir trouver facilement des exemples, mais je pense que ce sera dans un second temps, une issue sur GitHub fera l’affaire :wink:

J’ai pas dis que ce sera un système de coordonnée :slight_smile:

Pour l’instant l’interface d’édition ressemble à ça:

Tu as les petites flèches (up/down) qui te permettent de bouger les boxs.

J’ai commencé à jouer avec le drag and drop, j’ai pas trouvé de librairie sympa mais je pense qu’en natif on devrait s’en sortir. Après j’aurais sûrement besoin d’aide si on veut des animations sympas, c’set pas ma spécialité :slight_smile:

@AlexTrovato C’est gentil, après j’ai besoin de toi plus pour le bluetooth pour l’instant :smiley:

1 Like

Petite démo vidéo du mode édition actuelle :

https://gifyu.com/image/9iEa

Attention le gif fait 22 Mo donc je l’ai pas mis ici :slight_smile:

3 Likes