Les interfaces de programmation visuelles sont-elles efficaces pour les utilisateurs non techniques?
Je suis en train de concevoir une solution sur le système IVR (Interactive Voice Solution) qui devrait permettre à l'utilisateur de concevoir ses propres flux en fonction de ses besoins. Dans cette solution, l'utilisateur devrait avoir besoin d'organiser les questions, les réponses, les messages et leur relation avec le clavier ou les commandes vocales en fonction de leur flux commercial.
Après avoir pris un certain temps à rechercher des options, nous concluons que les interfaces de programmation visuelles peuvent être une bonne option. D'après mes recherches, j'ai trouvé quelques bibliothèques liées aux flux de show:
NoFlo- http://noflojs.org/
Meemoo- http://meemoo.org/
jsPlumb- http://jsplumbtoolkit.com/home/jquery.html
ThreeNodes - http://idflood.github.io/ThreeNodes.js/
Dynamo - http://autodeskvasari.com/dynamo
mxGraph- http://www.jgraph.com/mxgraph.html
Node-RED- http://nodered.org/
GoJS- http://gojs.net/latest/index.html (payé)
Ma propre expérience avec MAX MSP, Grasshoper (plug-in de modélisation générative fonctionne pour Rhino), les interfaces de programmation visuelles peuvent être vraiment compliquées lors de la construction de structures complexes. D'un autre côté, c'est plus facile car cela crée une meilleure boucle de rétroaction par rapport à la programmation basée sur du texte.
Il existe également des outils de programmation visuels comme, un exemple populaire de nos jours, Scratch, http://scratch.mit.edu/ développé pour apprendre à coder.
Un sujet de prédilection pour le doctorat. les dissertations en génie logiciel sont de programmation graphique ou visuelle. […] Rien de convaincant, encore moins passionnant, n'est encore ressorti de tels efforts. Je suis persuadé que rien ne le fera. (Frederick Brooks Le Mont de l'homme mythique)
Il existe des jeux qui utilisent également des éléments de programmation visuels comme (glisser-déposer, connexions en caoutchouc, regrouper plusieurs éléments en un, parties d'entrée et de sortie - ex: puzzle)
Après avoir collecté toutes ces informations, au lieu d'être plus clair sur le chemin, je sens que je suis perdu dans de nombreuses vues différentes et que je n'ai pas pu trouver d'informations solides sur le fait qu'elles fonctionnent bien pour les utilisateurs non techniques. Pouvez-vous faire plaisir à vos connaissances ou à votre expérience si vous avez déjà travaillé sur un tel projet?
Merci,
J'ai travaillé sur des systèmes/langages de programmation visuelle et je suis d'accord avec Frederick Brooks. Les langages graphiques ou schématiques ou tout autre type de langage non textuel ne font pas de bons langages de programmation à usage général. Le texte est très efficace pour décrire des choses complexes, en particulier les comportements et les actions, généralement beaucoup mieux que le non-texte. Une image ne vaut 1000 mots que dans des cas particuliers.
Mais les langages graphiques à usage spécial peuvent être bien appliqués à des problèmes limités et spécifiques à un domaine. Par exemple LabVIEW a été appliqué avec succès à de nombreux problèmes dans sa niche cible.
Ces langages graphiques spécifiques à un domaine sont parfois tout à fait utilisables par des personnes non techniques, mais ils ne sont pas une solution miracle. Ils nécessitent (généralement) un investissement important dans l'apprentissage de la langue et du système, et même alors, le problème doit être clairement compris pour tenter de l'exprimer dans le langage/système graphique.
Je travaille depuis longtemps sur des logiciels d'écriture pour le secteur financier, et je dois dire qu'Excel est de loin l'interface de programmation visuelle la plus réussie pour les non -utilisateurs techniques.
- Les utilisateurs novices commencent à travailler avec des lignes et des colonnes simples.
- Ils commencent à "programmer" par simple glisser pour sélectionner et additionner une colonne (ou une autre opération simple), et passent progressivement à des tâches plus complexes (par exemple des formules plus complexes, référençant des valeurs dans d'autres feuilles, créant des tableaux croisés dynamiques).
- Les utilisateurs experts peuvent ajouter divers contrôles (par exemple des boutons, des zones de liste), écrire leurs propres macros et ajouter d'autres sources de données (serveurs RTD, etc.)
Je suis constamment étonné de ce que les gens en font *.
Je ne prétends pas qu'Excel est le meilleur design jamais conçu. Je ne dis pas que tout le monde devrait l'utiliser, ni prétendre que des personnes non techniques proposent des conceptions de logiciels élégantes en l'utilisant ...
... mais Excel doit faire quelque chose de bien pour être omniprésent et aimé **.
Je soupçonne que avoir une grande grille de chiffres est la clé. La plupart de la programmation concerne la manipulation de données, mais la plupart des langages de programmation graphiques semblent concerner la manipulation de workflows/de chaînes de composants ensemble.
*c'est à dire. Parfois, nous obtenons un ensemble de classeurs "château de cartes" pour en faire une application
** cependant détesté c'est parmi les vrais développeurs.
im toujours fasciné par le logiciel http://en.wikipedia.org/wiki/MeVisLab . Il aide à voir le flux de l'application dans une sorte d'arborescence, mais permet également de développer des modules extrêmement complexes, qu'un utilisateur non technicien peut ensuite utiliser pour ses propres idées.
J'ai trouvé que le projet le plus réussi sur le terrain est un plugin pour Unity 3D: meneur de jeu. Playmaker est une machine à états visuels qui met l'accent sur l'aide aux jeux devellopper sur les tâches principales et permet d'itérer rapidement avec feedbak visuel en temps réel.
En fait, les nœuds ne sont peut-être pas le meilleur système visuel pour aider les personnes non programmeuses à comprendre la logique du code. Chaque domaine doit inventer des systèmes qui sont davantage liés à l'expérience que l'utilisateur a l'intention de créer.
Un bon exemple est moamilla appamaker. La toile visuelle est un smartphone. les préfabriqués sont des écrans. ils travaillent également à rendre l'auditeur visuel avec une bonne rétroaction et une rétroaction. Je pense que le système visuel qu'ils ont créé est plus facile à comprendre.
la conception générique mène à l'échec.
Je pense que l'approche adoptée lorsqu'ils ont conçu le langage visuel DRAKON est quelque chose à considérer lors du choix ou de la conception d'un langage de programmation visuel.
Pour DRAKON, ils ont conçu un ensemble de règles ou de contraintes appliquées de manière visuelle qui tentent d'émuler ou d'améliorer les règles utilisées pour les langages de programmation basés sur du texte.
Dans les langages de programmation basés sur du texte, nous suivons généralement le processus suivant lors de la lecture d'un programme:
Lorsque nous ouvrons le fichier texte avec le code source, nous recherchons immédiatement la fonction ou la méthode qui initialise le programme, puis nous suivons le chemin que le programmeur a déterminé comme étant le meilleur scénario, avec des cas d'angle placés à des endroits spéciaux comme au fin de la fonction. Si nous trouvons un appel de sous-routine, nous commençons à chercher sa définition et passons au bloc de texte où il se trouve. Lorsque nous atteignons la fin de ce sous-programme, nous revenons à la routine de l'appelant. Le processus est répété jusqu'à la fin du programme.
Donc, ce qu'ils ont fait avec DRAKON était de mettre des lignes entre ces appels aux sous-programmes et de remplacer les sous-programmes par des nœuds tout en ajoutant des règles spécifiant comment les lignes et les nœuds sont placés dans un diagramme.
Le système Unreal Engine 4 Blueprint est le langage de programmation visuelle le plus complet et le plus réussi que je connaisse.
Il s'agit essentiellement d'une couche au-dessus de c ++, qui est une couche au-dessus du code machine.
Certaines de ces interfaces que vous avez montrées ne semblent pas aussi complètes, mais tout script visuel supplémentaire au-dessus du code est bénéfique les rend plus efficaces pour tout le monde, y compris les utilisateurs non-tech.
Les avantages ne sont pas seulement pour les utilisateurs non techniques, pour un langage de script visuel complet comme UE4 Blueprints, les utilisateurs sophistiqués bénéficient également des avantages du prototypage visuel, du développement et du débogage fournis par cette couche supplémentaire.
Tant que l'interface est vraiment une couche supérieure, et pas seulement un remplacement maladroit, elle est bénéfique pour tous les utilisateurs.
Quand j'ai travaillé dans le forex, nous avons fait des tests et des formations pour une application création de stratégie de trading visuel . Il s'est avéré plus facile d'entrer et plus rapide de créer des stratégies non complexes (ce que la plupart sont).
Un autre bon exemple est générateur de workflow de Jira . La plupart des chefs de projet avec lesquels j'ai travaillé - y compris dans les services juridiques, marketing et comptables - n'ont eu aucun problème à le comprendre et à l'utiliser pour eux-mêmes.
D'après mon expérience, oui, les interfaces visuelles sont efficaces pour les utilisateurs non techniques, car elles:
- ne cause pas un "je ne suis pas programmeur" bloc mental
- encourager l'expérimentation
- donner un sentiment d'appartenance à votre création et de satisfaction
Pour les renforcer, nous avons jugé essentiel de
- rendre l'interface utilisateur découvrable et indulgente
- avoir des capacités Annuler, Copier/Coller
- fournir un tutoriel, des exemples et des modèles
- fonctionnalité d'exportation/importation pour partager des exemples et fournir un support plus facile
Enfin, beaucoup de gens ont fait une forme de programmation visuelle sans s'en rendre compte. Par exemple, en créant des cartes mentales, des organigrammes et des diagrammes de processus.