Galerie d'interfaces utilisateur écrites en MQL - page 79

Nouveau commentaire
 
6 principes de base (courts et clairs)

1. Copier des éléments.

2. Supprimer des éléments.

3. Édition manuelle (déplacement, étirement, impression).

4. Édition via des contrôleurs (obtenir des propriétés dans les éditeurs d'éléments et les modifier).

5. Chargement de modèles et de projets d' interface graphique à partir de fichiers.

6. Sauvegarde des modèles et des projets d'interface graphique dans des fichiers.
 

Besoin d'une bonne instruction, de tutoriels vidéo sur la façon de créer un panneau de A à Z. Interface en russe ;)

Sinon l'abondance des fonctionnalités est effrayante.

 
Aleksey Vyazmikin créer un panneau de A à Z. Interface en russe ;)

Sinon l'abondance des fonctionnalités est effrayante.

Oui, je m'attends à faire des tutoriels vidéo et à écrire quelques articles. Mais la tâche principale est peut-être de rendre l'éditeur auto-explicatif. Par exemple, lorsque le curseur se trouve au-dessus d'un élément, des flèches apparaissent et l'utilisateur comprend qu'il peut le saisir par ses bords et en modifier la taille. Et si un réticule apparaît, il comprendra que l'élément est déplacé sur le canevas. Lorsque l'on clique sur un élément, ses dimensions - hauteur et largeur - sont également très claires. Le texte et l'icône peuvent être déplacés à l'intérieur de l'élément. Lorsque vous les pointez, des flèches apparaissent également. La taille du texte peut être modifiée en l'étirant. Les distances entre les éléments lorsqu'ils sont déplacés, ainsi que la coïncidence de leurs positions verticales et horizontales, apparaissent également sur le canevas sous la forme de lignes rouges. À cet égard, tout est clair à la fois.

Pour ce qui est de l'édition des éléments, je placerai les éléments responsables des propriétés principales en haut, et je déplacerai les autres vers le bas. De plus, les éléments qui n'appartiennent pas à l'instance en cours d'édition seront automatiquement verrouillés. Cela simplifiera le travail dans la fenêtre des éditeurs d'éléments.

En outre, des infobulles apparaîtront au-dessus des noms de propriétés obscures. Elles expliqueront à l'utilisateur la signification de telle ou telle propriété de l'élément en cours d'édition. À ce stade, tout est clair.

Quant au canevas d'édition au centre. Alors que le concept final n'est pas encore formé. Je suppose que l'utilisateur y rassemblera les modèles d'éléments ou de groupes et les transférera dans les fenêtres. Autrement dit, à partir de la sous-fenêtre gauche des modèles, il copiera l'élément par glisser-déposer, en modifiera la taille, la couleur, le texte, etc., puis clonera plusieurs éléments de ce type et les enregistrera dans un fichier en tant que modèle ou les transférera immédiatement dans sa fenêtre. Je pense qu'une courte vidéo suffira à expliquer ce processus aux utilisateurs.

D'une manière générale, presque rien dans cet éditeur ne nécessitera de longues explications ou tutoriels et sa maîtrise ne prendra pas plus d'une heure. Et c'est là son avantage indéniable par rapport au langage de balisage).


 
Реter Konow #:
D'une manière générale, presque rien dans cet éditeur ne nécessitera de longues explications ou tutoriels et sa maîtrise ne prendra pas plus d'une heure.
Et c'est là son avantage indéniable sur le langage de balisage) .

Un bon objectif ! Il faut recruter des testeurs qui maîtriseront vraiment les fonctionnalités de A à Z, alors il sera plus évident de savoir à quoi faire attention dans l'ergonomie de l'interface....

 
Aleksey Vyazmikin #:

Bon objectif ! Il est nécessaire de recruter des testeurs qui apprendront vraiment la fonctionnalité à partir de zéro, ce qui rendra plus évident ce à quoi il faut prêter attention dans l'ergonomie de l'interface.

Je suis d'accord, mais nous devons y arriver. Une personne s'est déjà portée volontaire pour être bêta-testeur sur les pages de la branche, j'espère qu'il y en aura d'autres, mais il est trop tôt. Dans le courant du mois prochain, les tests initiaux de l'éditeur deviendront pertinents. Il y a encore beaucoup de travail de routine qui ralentit considérablement les choses. Toutes ces tables de propriétés, ces groupes de modèles, ces assignations d'onglets et de groupes, ces décisions de conception, ces bugs mineurs... mais personne n'a dit que ce serait facile).
 
Реter Konow #:
Je suis d'accord, mais nous devons en arriver là. Une personne s'est déjà portée volontaire pour être bêta-testeur sur les pages de discussion, j'espère qu'il y en aura d'autres, mais il est trop tôt. Dans le courant du mois prochain, les tests initiaux de l'éditeur deviendront pertinents. Il y a encore beaucoup de travail de routine qui ralentit considérablement les choses. Toutes ces feuilles de propriétés, ces groupes de modèles, ces assignations d'onglets et de groupes, ces décisions de conception, ces bugs mineurs... mais personne n'a dit que ce serait facile).

Quoi qu'il en soit, vous passez du temps sur un produit qui remplit son objectif, contrairement à beaucoup d'autres personnes ici qui écrivent les mêmes AE sans garantie de résultats.

 
Реter Konow #:
Pourquoi il n'y a pas lieu de développer davantage le langage de balisage :

1. Seuil d'entrée élevé.

Pour que les utilisateurs puissent construire des panneaux complexes, ils doivent connaître les règles du langage. Mais ils ne pourront les connaître qu'après avoir étudié ~20 tutoriels que je dois écrire dans les 6-7 prochains mois.

Je pense qu'il y a là une erreur, après tout, celui qui utilisera la base développée n'est pas un utilisateur ordinaire, et pour un développeur, le besoin d'apprendre les principes de l'application technologique est un phénomène normal.

 
Aleksey Vyazmikin #:

En tout cas, vous consacrez votre temps à un produit qui remplit sa fonction, contrairement à beaucoup d'autres personnes ici qui écrivent les mêmes conseillers sans garantie de résultats.

Oui, mon produit remplit sa mission, mais il n'a pas de sens sans les gens qui écrivent des EA sans garantie de résultats. Je ne peux donc pas les critiquer, laissons-les continuer à écrire).
 
Реter Konow #:
Oui, mon produit remplit la tâche, mais il n'a pas de sens si les gens n'écrivent pas de conseillers sans garantir le résultat. Je ne peux donc pas les critiquer, laissons-les continuer à écrire).

Il ne s'agit pas de critique, il s'agit de la joie de parvenir à un résultat tangible.

 
Kuzma Shevelev #:

Je pense qu'il y a là une erreur, après tout, celui qui utilisera la base développée n'est pas un utilisateur ordinaire, et pour le développeur, la nécessité d'apprendre les principes de l'application de la technologie est un phénomène normal

Pour un développeur, c'est tout à fait vrai. Cependant, en regardant objectivement l'expérience des auteurs d'articles et de bibliothèques d'interfaces graphiques, on ne peut s'empêcher de remarquer une certaine difficulté de vulgarisation à laquelle ils ont dû faire face. Pour une raison qui m'échappe, ce sujet ne retient pas l'attention du grand public. Peut-être parce que le pourcentage de développeurs chevronnés n'est pas élevé, mais il est également probable que la complexité des grandes bibliothèques et des articles effraie quelqu'un. Regardons les choses en face : la POO n'est pas une simple abstraction et lorsqu'elle se dresse sur le chemin, la motivation de chacun est mise à l'épreuve.

Mon langage de balisage est bien sûr beaucoup plus simple que le concept OOP, mais il nécessite également une présentation divisée en plusieurs parties et étalée sur plusieurs mois. Pour populariser quoi que ce soit, c'est une approche très inefficace. J'en suis donc arrivé à la conclusion qu'un langage de balisage subira presque inévitablement le même sort que les bibliothèques graphiques.

En revanche, un éditeur visuel au sein de la plateforme de négociation est une nouvelle façon de faire. Cela n'a jamais été fait auparavant. On peut donc espérer qu'il connaîtra un sort différent.

1...727374757677787980818283
Nouveau commentaire