Les interfaces utilisateur on INF1410 - Initiation au génie logiciel

Perspective historique

Mon, 01 Jan 0001 00:00:00 +0000

Perspective historique des interfaces utilisateur#

L’interface utilisateur est le point de contact entre un humain et un logiciel. C’est la partie visible, celle que l’utilisateur touche, voit et manipule. On distingue aujourd’hui l’UI (User Interface) de l’UX (User Experience) : l’UI désigne l’ensemble des éléments visuels et interactifs (boutons, menus, formulaires), tandis que l’UX désigne l’expérience globale de l’utilisateur, qui englobe non seulement l’aspect visuel mais aussi la facilité d’apprentissage, la fluidité de navigation et la satisfaction à l’usage. Un produit peut avoir une belle UI et une mauvaise UX si, par exemple, les menus sont visuellement soignés mais difficiles à trouver. Pourtant, la manière dont on conçoit cette interaction a radicalement changé au fil des décennies. Les premiers programmeurs interagissaient avec leurs machines par des cartes perforées et des imprimantes ; aujourd’hui, on glisse du doigt sur des écrans tactiles ou on parle à des assistants vocaux. Cette évolution n’est pas qu’une question de technologie, elle reflète des changements profonds dans notre conception de ce qu’un ordinateur peut et devrait être. Comprendre cette histoire permet de mieux saisir pourquoi les interfaces modernes sont construites comme elles le sont, et quelles tensions fondamentales continuent de les façonner.

L'architecture des applications web

Mon, 01 Jan 0001 00:00:00 +0000

L’architecture des applications web#

Le web a été conçu comme un système de documents. Un navigateur envoie une requête HTTP (dont nous avons examiné le protocole en détail dans la section sur les APIs) à un serveur, qui répond avec un document HTML. L’utilisateur clique sur un lien, le navigateur envoie une nouvelle requête, et reçoit un nouveau document. Ce modèle requête-réponse, simple et élégant, a fonctionné remarquablement bien pour le web documentaire. Mais à mesure que le web s’est transformé en plateforme d’applications, ce modèle a montré ses limites. Comment construire une boîte de réception Gmail, avec ses messages qui apparaissent en temps réel, dans un système conçu pour afficher des pages statiques ? La réponse à cette question a donné lieu à une succession d’architectures, chacune tentant de résoudre les problèmes de la précédente.

Les frameworks JavaScript

Mon, 01 Jan 0001 00:00:00 +0000

Les frameworks JavaScript#

La section précédente a décrit les grandes architectures des applications web : SSR, SPA, hybride. Mais ces architectures ne se construisent pas à la main. Manipuler directement le HTML d’une page depuis JavaScript pour créer une application interactive est techniquement possible, mais rapidement ingérable dès que l’interface devient complexe. C’est pourquoi, depuis le milieu des années 2000, une succession de bibliothèques et de frameworks JavaScript ont émergé pour structurer le développement côté client. Leur histoire est traversée par une tension fondamentale entre deux approches : l’approche impérative (dire au navigateur comment modifier l’interface, étape par étape) et l’approche déclarative (décrire ce que l’interface devrait être, et laisser le framework se charger des modifications). Pour comprendre cette tension, il faut d’abord comprendre ce qu’est le DOM.

Desktop, web et mobile

Mon, 01 Jan 0001 00:00:00 +0000

Desktop, web et mobile : tensions et convergences#

Les sections précédentes ont retracé comment le web est devenu la plateforme dominante pour les interfaces utilisateur, portée par des frameworks de plus en plus sophistiqués. Mais le web n’est pas la seule plateforme. Les applications desktop natives continuent d’exister pour les cas qui exigent des performances maximales ou un accès direct au matériel (éditeurs vidéo, jeux, outils de développement). Les applications mobiles, apparues avec l’iPhone en 2007 et l’Android Market en 2008, ont créé un nouvel écosystème avec ses propres langages (Swift pour iOS, Kotlin pour Android), ses propres conventions d’interface, et ses propres canaux de distribution (les app stores). Le résultat est un paysage fragmenté où un même service doit souvent exister sous plusieurs formes : un site web, une application iOS, une application Android, parfois une application desktop. Cette fragmentation relance, à une échelle bien plus grande, la tension qu’on a identifiée dans la section historique à propos des toolkits desktop : faut-il écrire du code natif pour chaque plateforme, au prix de la duplication, ou chercher une solution universelle, au prix de compromis sur l’expérience utilisateur ?