Peut-il être utile de créer une application commençant par l'interface graphique?

La tendance dans la conception et le développement d'applications semble commencer par les "entrailles": le domaine, puis l'accès aux données, puis l'infrastructure, etc. L'interface graphique semble généralement venir plus tard dans le processus. Je me demande s'il ne serait jamais utile de construire d'abord l'interface graphique ...

Ma logique est qu'en construisant au moins une interface graphique prototype, vous obtenez une meilleure idée de ce qui doit se produire dans les coulisses, et êtes donc mieux placé pour commencer à travailler sur le domaine et le code de support.

Je peux voir un problème avec cette pratique en ce que si le code de support n'est pas encore écrit, il n'y aura pas grand-chose à faire pour la couche GUI. Peut-être que la construction d'objets fictifs ou de classes jetables (un peu comme pour les tests unitaires) fournirait juste assez de bases pour construire l'interface graphique.

Serait-ce une idée réalisable pour un vrai projet? Peut-être que nous pourrions ajouter GDD (GUI Driven Development) à l'acronyme stable ...

Construire des prototypes GUI rapides est une bonne idée, et j'ai entendu dire qu'il était utilisé dans de nombreux projets. Une rétroaction précoce est en effet précieuse. Cependant, il a ses dangers:

• il est très tentant (pour les gestionnaires / utilisateurs) d'utiliser davantage le code prototype et de construire l'application finale sur celui-ci, ce qui peut avoir de très graves conséquences à long terme (cela s'est en fait produit dans l'un des projets sur lesquels j'ai travaillé, et cela a abouti à un produit "fonctionnel" avec une architecture inexistante et beaucoup de problèmes de maintenance pour nous)
• pour l'utilisateur moyen, l'interface graphique est l'application . Ainsi, une fois qu'ils voient une interface graphique agréable, ils ont tendance à croire que la plupart du travail réel est effectué, ils peuvent donc être très contrariés par le "petit travail restant" qui traîne si longtemps: - /

L'atténuation de ces risques nécessite une discussion active et éventuellement la formation de vos utilisateurs et / ou gestionnaires.

Le problème que je vois avec cela est que l'objectif semble être totalement en arrière.

"Mon raisonnement est qu'en construisant au moins une interface graphique prototype, vous obtenez une meilleure idée de ce qui doit se produire dans les coulisses, et êtes donc mieux placé pour commencer à travailler sur le domaine et le code de support."

C'est, à mon avis, la mauvaise façon de voir une couche métier et une GRANDE façon de trouver une conception médiocre et non expansible. Une couche de données bien conçue pour exprimer complètement les données peut être utilisée dans n'importe quelle interface utilisateur. Une couche de données conçue pour fonctionner pour les besoins d'une interface utilisateur spécifique peut ne pas être adaptable à autre chose, pas même des ajouts de fonctionnalités mineures à cette interface utilisateur.

L'expérience des systèmes conçus de la manière dont vous parlez m'amène à conclure que la plupart des conceptions qui utilisent cette méthodologie finissent par être de courte durée et / ou trop compliquées. Ils ont également tendance à créer un couplage entre l'interface utilisateur et la couche de données qui ne devrait jamais, jamais être là.

L'indépendance de la couche de données et de la couche d'interface utilisateur doit être encouragée. C'est pourquoi la construction de la couche de données pour simplement représenter l'ensemble des données plutôt que de cibler une interface utilisateur spécifique fonctionne tout simplement mieux à long terme.

La construction d'un prototype peut être bonne pour la collecte et l'accord des exigences, mais il devrait ensuite être jeté. N'utilisez en fait rien du code prototype dans le produit réel.

Je pense que @ Péter a raison de suggérer que la construction de prototypes GUI est une bonne idée. J'aimerais compléter avec les pièges potentiels de fournir l'expérience utilisateur de manière inversée, c'est-à-dire en se concentrant sur les ontologies, l'architecture et l'infrastructure en premier et l'expérience utilisateur immédiate en dernier:

• L'utilisateur que vous avez poussé à l'extrémité de la chronologie de développement invalide vos estimations des données et la façon dont votre application est utilisée.
• Vos conceptions élaborées que vous avez développées prématurément se révèlent être des machinations auto-conçues qui n'ont finalement que très peu ou pas d'utilité.
• Votre application peut être amenée à un tel état où la fourniture d'expériences utilisateur médiocres devient la norme.

Vous faites le courage, puis l'utilisateur obtient ce qui est sorti de vos hypothèses, tandis que vous devez vous soucier de ce dont l'utilisateur a besoin et construire les tripes en conséquence. La raison pour laquelle les gens recourent à l'inverse est simplement parce que la présentation, celle avec laquelle l'utilisateur interagit, d'où les comportements de l'application bouillonnent naturellement, est la partie la plus complexe du système qui n'est jamais complètement explorée ou les gens se sentent tout simplement très heureux de se construire des choses pour éviter d'avoir à réfléchir à pourquoi / quoi / pour qui ils le construisent. Ériger une énorme structure structurellement saine est un jeu d'enfant, la faire satisfaire les besoins fonctionnels (et esthétiques) de chacun est la partie la plus difficile.

Pour chaque expérience craptique, flux décalé, informations mal colocalisées, manque de fonctionnalités évidentes, choses qui sont tout simplement erronées, cas où vous avez demandé à demander "quel génie est venu avec ça ?", Réside quelque chose qui a été ignoré, nié ou a révélé que l'utilisateur était à l'avant-garde des efforts de développement.

En général, le modèle doit être développé avant la vue. Une fois que vous avez une base logique de votre application, vous pouvez créer une ou plusieurs vues de ce modèle (par exemple, vous pouvez afficher les données sous forme de tableau ou de graphique). Habituellement, le modèle est plus important que l'interface graphique. Cela est particulièrement vrai pour le développement d'entreprise où l'interface graphique est généralement effectuée de manière standard.

Cependant, parfois l'interface graphique est vraiment la partie la plus importante de l'application. Parfois, vous voulez regarder des données d'une manière nouvelle et spécifique - et vous les prenez à partir de là, puis développer le modèle. Par exemple, CashCurve est une telle application où le point est dans l'interface graphique, tandis que le modèle de données lui-même est un truc ennuyeux standard que n'importe qui peut modéliser en quelques minutes. (Avertissement: je ne suis pas affilié à CashCurve, juste un utilisateur très satisfait.)

Ceci est également pertinent pour la conception de services Web ou d'autres API - seulement là, il est connu sous le nom de conception " contract-first ".

Donc, comme pour tout, il n'y a pas de règle sur quoi concevoir en premier; parfois c'est un modèle, et parfois c'est une interface graphique. En règle générale, j'opterais pour «concevoir la partie la plus importante en premier».

Il y a des mises en garde à prendre en compte lors de la conception de l'interface graphique, comme cet utilisateur aura probablement du mal à comprendre que l'application est loin d'être complète lorsque seul le prototype de l'interface graphique existe, mais d'autres réponses ont assez bien couvert cela, donc je n'entrerai pas dans les détails.

Je pense que c'est une très bonne façon d'aborder la conception d'applications, en particulier dans un environnement de développement agile. La plupart des projets réussis sur lesquels j'ai travaillé ont commencé avec un prototype qui est finalement devenu la vraie chose.

Vous devez comprendre que l'interface graphique est la fenêtre sur le système (c'est-à-dire la base de données, le système de fichiers, etc.). Dans une situation où les exigences du projet sont à peu près aussi vagues qu'un tas de neige fondue, vous n'aurez aucun espoir en enfer pour obtenir une solution correcte en commençant par le backend. Presque toujours, le développeur backend bien intentionné développe un tas d'API qui n'a aucune pertinence pour les interactions des utilisateurs.

En démarrant sur l'interface graphique, le client a une meilleure idée de ce qu'il veut. Au fur et à mesure que cette étape progresse, le développement de l'interface graphique (à l'aide de maquettes et de stubs) donne naissance à un modèle de domaine. Ce modèle de domaine peut ensuite être transféré vers le backend et les développeurs backend peuvent commencer à développer la persistance et la logique transactionnelle.

Et pourquoi voudriez-vous jeter le protoype? Il ne s'agit pas de stades construits en allumettes. Il suffit de refaçonner la fichue chose en quelque chose de bien.

Cela ne me semble pas mal du tout si la personne qui regarde l'interface graphique comprend que c'est juste un shell et que les boutons et les processus ne fonctionnent pas littéralement (lancez une nouvelle NotImplementedException ();;)).

Si vous vous en tenez à l'utilisation d'une architecture de style MVC, je ne prévois aucun problème futur de maintenance ou de construction car la "Vue" ne définit aucunement ce genre de chose. Les "Contrôleurs" et "Modèle" peuvent venir plus tard avec n'importe quelle infrastructure dont vous avez besoin pour des besoins d'évolutivité / conception, etc.

En ce qui concerne la gestion, dessinez-les un grand diagramme à secteurs avec 3 portions, étiquetez-les "M", "V" et "C". Donnez au V environ 20% et expliquez que le reste du gâteau est "TBC";).

Dans tout système de taille raisonnable, ce qui doit se produire dans les coulisses est vaguement lié à l'apparence de l'interface graphique. L'interface graphique vous donnera seulement certaines des exigences. Il existe souvent de nombreux composants qui n'ont pas d'interface graphique.

Une fois le système développé, des interfaces supplémentaires (y compris de nouvelles interfaces graphiques) peuvent être nécessaires. La compréhension et la mise en œuvre des exigences métier sont essentielles pour que cela réussisse.

La conception de l'interface graphique et d'autres mécanismes d'entrée et de sortie peut aider à valider le modèle. Les attributs qui ne sont jamais sortis peuvent ne pas être requis. (Il peut y avoir des raisons de les conserver, mais ce seront probablement des exigences d'audit ou de réglementation.)

Comme d'autres l'ont mentionné, une fois que vous avez une interface graphique fonctionnelle, de nombreux clients penseront que vous avez terminé. Cependant, vous ne disposez peut-être d'aucune infrastructure derrière. Les prototypes papier peuvent être une bonne option pour valider la mise en page et le contenu de l'interface graphique.

N'oubliez pas que vous devrez peut-être ajuster l'interface après le développement. J'ai entendu rapport d'un échec de remplacement de l'interface de paiement pour un processus de paiement en cinq étapes. Une interface beaucoup plus simple ne donnait pas aux utilisateurs le sentiment de sécurité approprié et avait un taux d'achèvement beaucoup plus faible. Écoutez les ralentisseurs: l'ingrédient magique du marketing .