Discussion :

[koala01]

Bonjour,

Afin de pouvoir partir sur de bonnes bases, il est nécessaire de définir un certain nombre de scénarios d'utilisation "typiques" de ce que l'on peut attendre de la bibliothèque.

Ces scénarios nous permettront de déterminer ce qui doit être implémenté ainsi que la priorité à appliquer pour l'implémentation.
Scenario N° 1

Jean est un étudiant de 15-16 ans, venant tout juste de terminer la lecture de (mauvais) tutoriels C++ et n'ayant jamais approché le moindre langage de programmation.

La programmation générique, Les règles, principes et lois de programmation, inconnus: il code "au feeling", en "espérant que ca marche"...

Il souhaite créer une application avec menus, boutons et un "treeview" pour représenter les données qu'il devra gérer.

Les données seront créés sous la forme de chaines de caractères, converties à chaque fois que nécessaire, et, bien sur, Jean souhaite pouvoir enregister et récupérer ces données sous la forme d'un fichier plat.

Scénario N° 2

Arthur est un programmeur C++ expérimenté.

Il maitrise parfaitement les design patterns, la programmation générique et l'ensemble des concepts de bonne programmation (MVC, séparation du corps métier, ...), mais il est très "classique" dans sa vision des IHM.

Il crée aussi bien des applications "stand alone" que des applications destinées à être intégrées dans une architecture client / serveur.

Sa devise est "utiliser les bons outils pour le bon usage", et il veut donc garder l'entière liberté des bibliothèques et des versions de bibliothèques qu'il décide d'intégrer à ses applications.

Il souhaite également le cas échéant être en mesure d'intégrer des bibliothèques développées dans d'autres langages sans avoir plus de difficultés que... s'il le faisait pour la partie métier.

Enfin, il va à l'essentiel et ne s'intéresse que très peu au coté joli de la chose: Ce qu'il cherche en priorité, c'est l'efficacité et l'ergonomie de l'IHM.

Scénario N° 3
Joseph est développeur dans une boite qui crées des jeux 3D.

Son rôle est de développer l'interface du futur en 3D, qui sera utilisée dans le "buzz" de l'année

Il devra en grande partie connecter l'interface de jeu avec le langage de script et les différents formats 3D utilisés (exportations de scènes 3Ds, blender ou autre) pour le jeu.

Scénario N° 4
Henri est designer dans une grande société de création de logiciel.

Son rôle principal est de travailler sur le "look 'n feel", de déterminer la "belle couleur", la "forme sympa" des différents éléments de l'interface graphique.

Il ne touchera jamais à la moindre ligne de code, mais il va créer "l'interface parfaite" en terme de design et de forme

Scénario N° 5
Bernard travaille dans un département R&D.

L'utilisation des écrans tactiles, intégration d'interface dans les différents objets de la vie de tous les jours (miroir de la salle de bain, porte du réfrigérateur,...) ou, pourquoi pas, l'utilisation d'une interface basée sur un hologramme et des pointeurs au bout des doigts sont son dada.

Il devra être en mesure de pointer et de déplacer des parties entières de l'hologramme du bout des doigts.

Ce que j'attends de vous

Vous l'aurez remarqué, ces scénarios sont particulièrement "typés".

Ils devraient, à peu de chose près, être représentatifs de l'ensemble des souhaits que l'on peut attendre de la bibliothèque.

Certains scénarios peuvent manquer, mais, dans un premier temps, je souhaiterais que nous réfléchissions à ce qui sera nécessaire pour permettre à ces scénarios de se dérouler.

Comment faudra-t-il débuter le développement de manière à éviter de devoir "tout refaire" ou de devoir "repartir de zéro" une fois qu'un scénario est complet, au moment de débuter sur la résolution du suivant

N'hésitez pas à donner votre avis ou à demander des précisions sur ces scénarios, plus il seront précis, plus nous aurons de chances de partir de bases saines

Merci d'avance

[Lavock]

Malheureusement, je pense pas qu'il y ai un quelconque moyen pour être sûr de pas tout devoir refaire.

Ne pas les faire 1 par 1 semble une bonne solution. Cela permettrai de détecter les conflits au plus tôt.

[Question]

S. n°1 :

Il faut savoir quel sera le rôle de farfelue (abréger ffl ?) => faire en sorte que ça marche "malgré tout" ou lui donné un but plus didactique ?

S. n°4 :

Le graphiste travaillerai seul ou non ? Généralement, c'est plutôt non, mais il serait intéressant de pouvoir dire oui ^^ !

S. n°5 :

J'ai un peu de mal a voire ce que pourrait attendre une tel personne de l'utilisation de ffl.

[El. de Réponse]

S. n°1 :

Pour ce qui est de la pédagogie (ou didactique, je sais plus trop), je dirai que l'apprentissage à tâtons est efficace si on peut tirer pleinement partie de ces erreurs. Cela passe le plus souvent par la clarté des messages.

S. n°2 :
Je ne pense pas que l'ergonomie soit de notre ressort... Par contre, ce qui nous est indue, c'est d'avoir une bibliothèque optimisée pour une bonne ergonomie.

S. n°4 :
Si la réponse est oui => pensée à facilité l'interfaçage avec des solutions de dessin (gimp/toshop par exemple)... ainsi qu'un edi/rad de la mort qui tue (le tout réalisé avec farfelue bien sûr !).

[koala01]

Malheureusement, je pense pas qu'il y ai un quelconque moyen pour être sûr de pas tout devoir refaire.

C'est en grande partie le *gros* défi du projet, et j'ai la conviction, justement, qu'il sera possible de ne pas tout devoir refaire en déterminant correctement les différents aspects orthogonaux et en créant les politiques et les traits de manière cohérente.

L'idée est donc, par exemple, de se dire "il y a un système de positionnement dans l'espace" et de pointage.

L'espace considéré peut être:

• Le plus souvent celui (2D) de l'écran de l'utilisateur
• Eventuellement (c'est là qu'intervient le R&D ) dans un espace réellement 3D défini par les limites de l'hologramme dans lequel il fait ses manipulations

Bon, j'admets être en pleine science fiction avec mon R&D ... Mais, au vu de la vitesse des évolutions, cela pourrait être pour demain (pour la petite histoire, un épisode des experts montrait un truc identique... Si même les scénaristes de séries télé se mettent à y penser, qui dit que nous ne trouverons pas un inventeur capable de le mettre au point )

Le système de positionnement dans l'espace peut donc être:

• basé sur un système de coordonnées x et y, dont l'origine est le coin supérieur gauche de l'écran
• basé sur un système de coordonnées x, y et z dont l'origne est (le point de vue )

Nous avons donc une politique de positionnement et ... deux traits particuliers mettant cette politique en oeuvre

La gestion des couleurs peut être envisagée de manière exactement similaire.

Nous pouvons envisager:

• la "simple" gestion RGB 24bits
• la gestion de couleurs 32bits RGBA
• un système basé sur la teinte, la luminosité et que sais-je encore
• ...

Nous avons donc, là encore, une politique basée sur deux (ou trois, ou plus de) traits particuliers.

Rajoutons-y la politique de gestion de formes, en permettant la définition, pour les formes 2D, de

• rectangles pleins / vides
• triangles pleins / vides
• cercles/disques
• polygones réguliers pleins / vides
• polygones irréguliers (étoile à cinq branche ) pleins /vide

pour les formes 3D, la définition de

• parallélépipèdes pleins/vides
• sphères pleines/vides
• cones pleins/vides
• polyèdres réguliers pleins /vides
• polyèdres irréguliers pleins /vides

Cette politique sera dépendante de celle de positionnement utilisée (il est difficile de représenter une forme 3D avec un système de positionnement en deux dimensions uniquement), mais, avec seulement trois politiques clairement distinctes et une quinzaine de traits clairement identifiés, nous en arrivons à une palette de possibilité énorme

Ne pas les faire 1 par 1 semble une bonne solution. Cela permettrai de détecter les conflits au plus tôt.

Il faut tout prévoir et prévoir la possibilité de rajouter des politiques et / ou des traits, mais si on commence à tout faire d'un seul coup, on ne s'en sortira pas...

Par contre, je viens de mettre trois politiques en évidence, ce qui serait intéressant, c'est de mettre les autres également en évidence

[Question]

S. n°1 :

Il faut savoir quel sera le rôle de farfelue (abréger ffl ?) => faire en sorte que ça marche "malgré tout" ou lui donné un but plus didactique ?

Le but est de lui permettre d'évoluer...

Tôt ou tard, il sera confronté au fait de devoir "tout casser" parce qu'il a trop fortement mélangé la partie graphique et la partie métier de son application.

Comme c'est généralement le genre de décision très chiante à prendre, il essayera de se promettre de ne plus refaire la même erreur.

C'est à ce moment là qu'il décidera (peut-être) de se tourner vers la documentation, les exemples, les démos ou... les forums () pour améliorer sa conception...

Ce sera donc "à nous" de lui présenter les choses "aussi bien que possible"

S. n°4 :

Le graphiste travaillerai seul ou non ? Généralement, c'est plutôt non, mais il serait intéressant de pouvoir dire oui ^^ !

En sachant qu'il sera, de toute façons vraisemblablement toujours en relation d'une manière ou d'une autre en relation avec les développeurs, l'idéal est qu'il puisse décider de placer, par exemple, un bouton en forme d'étoile à cinq branches rose bonbon dans l'interface qu'il crée (voir de "dessiner" un bouton de forme particulière) si l'envie lui prend sans que cela n'implique d'aller pleurer auprès du développeur pour que celui-ci daigne écrire le code correspondant.

Cela répond il à ta question

S. n°5 :

J'ai un peu de mal a voire ce que pourrait attendre une tel personne de l'utilisation de ffl.

<Mode SF on> Et s'il veut créer une interface qui réagisse avec l'utilisateur dans son hologramme <Mode SF off>
[El. de Réponse]

S. n°1 :

Pour ce qui est de la pédagogie (ou didactique, je sais plus trop), je dirai que l'apprentissage à tâtons est efficace si on peut tirer pleinement partie de ces erreurs. Cela passe le plus souvent par la clarté des messages.

Aussi...

S. n°2 :
Je ne pense pas que l'ergonomie soit de notre ressort... Par contre, ce qui nous est indue, c'est d'avoir une bibliothèque optimisée pour une bonne ergonomie.

Je pensais justement préciser ce scénario (je le ferai rapidement ), mais, effectivement, il faut que Arthur puisse créer des applications de qualité et que la bibliothèque lui permette de les créer facilement

S. n°4 :
Si la réponse est oui => pensée à facilité l'interfaçage avec des solutions de dessin (gimp/toshop par exemple)... ainsi qu'un edi/rad de la mort qui tue (le tout réalisé avec farfelue bien sûr !).

avec un RAD et un système de "traçage de composants", surement.

Avec des solutions de dessins pur, ce sera à voir

[Lavock]

• Eventuellement (c'est là qu'intervient le R&D ) dans un espace réellement 3D défini par les limites de l'hologramme dans lequel il fait ses manipulations

Pardonnez-moi l'expression, mais "omg" oO !
Il va falloir bien plus que de la simple inventivité pour savoir ce qu'est une bonne interface (ergonomiquement parlant) 3D !
Rien que ça relève d'un projet a part entière...

Déjà, imagine la galère pour le graphiste : une forme inimaginable, même pas vectorielle. Comment faire correspondre la zone d'event à une forme pareil si on sépare tout ?
Cela veut clairement dire que on devrait être capable de lire depuis une image deux informations : une zone et un graphisme. Sans quoi se scénario ne pourra-t-être validé. Il est hors de question de laisser le développeur faire du dessin-en-code non ?
Et maintenant, imagine la même contrainte AVEC de la 3D ?

Je sais pas comment faire, mais ça donne envie !

[koala01]

Je crois que, sur ce coup là, tu accroche beaucoup trop sur les détails...

Le but de ce scénario bien particulier, c'est que l'on se pose la question de savoir "comment arriver à déjà préparer le travail" pour quand "de nouvelles techniques", dont on peut imaginer n'importe quoi, feront leur apparition.

Dans le cas présent, cela implique qu'il faut arriver à prévoir "une certaine facilité" d'ajout de nouveau périphériques de pointage ou d'affichage, et donc de voir comment on peut "préparer le terrain" pour quelque chose dont on ignore à peu près tout, si ce n'est que l'imagination est sans limite

[minnesota]

Salut,

Pour que la Lib soit performante (en termes de temps de développement pour l'utilisateur) et attractive, il faut qu'elle soit intuitive. Je pense, mais ça n'engage que moi, qu'il faudrait jouer la carte du tout objet. En d'autres termes, modéliser l'ordinateur.

Par exemple, la surface d'affichage de l'écran est un objet. Sur cet objet, on peut dessiner un objet fenêtre, lui même contenant d'autres objets tel qu'un bouton, etc. Ici, je ne décris pas une notion d'héritage ou de superObjet, mais seulement des objets autonomes et communiquant qui ont le potentiel de s'interfacer.

[dourouc05]

Aussi, c'est très bête comme truc, mais tellement utile quand c'est utilisé : vous avez pensé à un truc pour les traductions (donc l'encodage), le changement de langue à l'exécution ? Perso, ça me tenterait bien, de voir une fonction changeLanguage("en") qui charge le fichier de traduction en anglais et retraduit toute l'IU !

[Invité]

Perso, ça me tenterait bien, de voir une fonction changeLanguage("en") qui charge le fichier de traduction en anglais et retraduit toute l'IU !

Oui, et dans les choses que ce système devrait gérer :

1- un système permettant le "retaillage" des composants, quand on passe d'une langue à libellés courts (l'anglais, ou pire le chinois) à une langue à libellés longs (le français, ou l'allemand). Parce que bon, avoir un truc qui traduit tout bien, pour constater qu'il faut ensuite refaire tout l'alignement des composants...

2- un système qui permet de gérer la traduction dans l'EDI si nécessaire, et surtout d'éviter les "codes internes", parce que bon

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MessageBox(MSG601,MSG53,MSG2314);

On peut faire moins pratique, mais il ca demande du boulot!
Idéalement, il faudrait que l'on puisse faire le SelectLanguage() dans l'EDI, en conception...


Deux autres choses qui ont toujours été pour moi prohibitive pour le changement de librairie :

1- pouvoir construire sans efforts un programme test débile: un hello world qui ne prend que deux lignes
2- pouvoir intégrer un petit bout "made in Farfelue" dans un gros programme utilisant une autre lib.

Francois