Prototype de site pour un musée de petites ou moyennes dimensions. Les patterns

Les patterns

Selon le Handbook for quality in cultural Web sites, paragraphe 2.5:

« Une autre approche différente aux problèmes concrets d’élaboration et de réalisation de sites Web de qualité consiste à recourir à des patterns, qui se proposent de résoudre des problèmes récurrents grâce à des solutions connues et éprouvées. Le produit Web a désormais atteint un degré de maturité tel que les solutions à certains problèmes liés à son utilisation sont désormais considérées comme un patrimoine commun à tous les créateurs de projets. »
« En outre, les Patterns peuvent être une référence utile pour ceuxqui doivent s’intéresser aux sites Web, sans être des experts en la matière. Dans ce cas, en effet, les Patterns peuvent constituer un langage commun de communication avec les professionnels pour indiquer ce que l’on veut et pourquoi, indépendamment de la manière de réaliser techniquement la solution. »
« Les Patterns n’éliminent ni ne remplacent la nécessité de l’implication des usagers dont il a été question plus haut : au contraire, cette méthode profite, par définition, d’expériences concrètes faites avec les utilisateurs. »

2.5.1 Définitions

Le paradigme des Patterns a été développé à la fin des années soixante-dix par Christopher Alexander, professeur d’Architecture à l’université de Berkeley, pour faire face aux problèmes complexes liés aux projets dans les domaines de l’urbanisme et du bâtiment. Selon Alexander, la mauvaise qualité de l’architecture des années soixante était due à l’absence de méthodes formelles de projet. Dans la pratique, il constata que les projets d’urbanisme et de bâtiments ne tenaient pas compte des expériences concrètes qui mûrissaient peu à peu et sans lesquelles les projets eux-mêmes finissaient par devenir étrangers aux exigences réelles des usagers. D’où l’idée de définir des Patterns qui établissent des relations entre un contexte, un ensemble de conditions (ou limites) liées à ce contexte et une solution qui résolve le problème avec ces conditions et dans ce contexte.

À partir du milieu des années quatre-vingt-dix, l’idée d’utiliser des langages de Pattern comme support aux concepteurs de projets a reçu un nouvel élan grâce à l’énorme succès remporté par son application dans le domaine de l’ingénierie du logiciel et du projet object oriented. Récemment, le paradigme des Patterns a été appliqué aussi au domaine de la Human Computer Interface (HCI), avec extension au monde Web.

Les Patterns visent à fournir une manière rigoureuse de décrire l’expérience d’un concepteur de projet à travers la formulation d’une solution à un problème commun.

Ce qui caractérise cette approche, c’est le choix de ne pas donner de solutions « précodifiées » au problème, mais d’essayer plutôt de décrire correctement aussi bien le contexte que la solution, en réunissant sous un même titre les expériences et les solutions adoptées dans des situations semblables (y compris par d’autres personnes, en ne se limitant donc pas à ses propres solutions). Un Pattern est constitué d’une triade composée de:

Contexte: c’est l’ensemble des conditions environnantes, le milieu dans lequel on agit; c’est l’ensemble des forces en action dont le Pattern doit tenir compte et qui limitent le choix des solutions;

Problème: c’est une situation qui se présente de manière récurrente dans le contexte et qui crée des déséquilibres entre les forces en action;

Solution: c’est un algorithme, une technologie, une structure d’organisation, une méthode connue, un modèle de référence qui résout de manière récurrente ce problème dans ce contexte.

Soulignons le fait qu’un Pattern est constitué d’une triade : cela veut dire qu’à lui seul, un problème n’est pas un Pattern, et qu’une solution, à elle seule, n’est pas un Pattern.

En un mot: un Pattern est une solution consolidée (well proven) à un problème récurrent dans un contexte spécifique.

Pour compléter la définition d’un Pattern, il faut aussi d’autres éléments:

Nom: un Pattern doit avoir un nom significatif. Donner un nom à quelque chose, c’est la première étape pour pouvoir en parler.

Conditions: description des conditions (ou limites) présentes dans le contexte.

Annotations: considérations (positives ou négatives) sur les conséquences de l’usage du Pattern courant.

Pattern corrélés: relations entre le Pattern courant et d’autres Patterns utilisés dans le système de référence.

Usages connus: références ponctuelles à des applications pratiques du Pattern courant.

Un langage de Pattern rassemble des Patterns qui coopèrent pour résoudre les problèmes dans un certain contexte.

Le contexte général de référence auquel nous désirons appliquer le langage des Patterns est le projet et la réalisation de WAI (« Web Accessibility Initative ») accessibles et utilisables, c’est-à-dire de qualité.

Une fois établies les conditions de référence communes, il est nécessaire de donner une certaine organisation aux Patterns pour pouvoir les utiliser.

La méthode que nous proposons ici consiste à construire un véritable Catalogue de Patterns, dont le but est d’identifier des catégories générales de problèmes à affronter. À l’intérieur de chacune de ces catégories s’insèrent des Patterns qui définissent et résolvent un problème particulier.

2.5.2 Le Catalogue des Patterns

Pour construire le Catalogue des Patterns devant être appliqués au projet et à la réalisation d’un WAI accessible et utilisable, nous employons les mêmes catégories générales qui ont servi à regrouper les Critères d’usabilité. Nous leur ajoutons également:

Interagir avec les usager: quand un SCP (« Sujet Culturel Public »)se présente sur l’Internet avec son site Web, il ouvre de fait un portail au citoyen. L’interactivité, qui veut dire ici la possibilité de communication directe entre citoyen et WAI, devient une fonctionnalité importante qui ne peut pas manquer.

Nous présentons dans l’appendice 3 le Catalogue des Patterns et leur définition.

2.5.3 Comment utiliser les Patterns

Enfin, il reste une question à éclaircir : comment « utilise-t-on » les Patterns.

Dans un chapitre de son libre A Pattern Language, Christopher Alexander suggère d’entreprendre un parcours à la fin duquel on devrait avoir rempli une liste de Patterns nécessaires au projet. Les étapes à parcourir sont les suivantes:

Examiner la séquence entière, le Catalogue des Patterns, qui est disponible.
Identifier, à travers son nom, le Pattern qui identifie le mieux le projet/problème que l’on doit affronter.
Lire attentivement sa description. Celle-ci indique les Patterns liés au Pattern actuel. On préparera ensuite une liste, en indiquant sur celle-ci les Patterns de niveau inférieur (plus spécifiques) que l’on rencontre, en négligeant, en général, les Patterns du niveau supérieur (moins spécifiques).
Lire le Pattern suivant mis en évidence sur la liste et marquer de nouveau les Patterns inférieur auxquels il est lié.
En cas de doute sur l’utilité d’un Pattern, celui-ci ne doit pas être inclus. En effet, le liste deviendrait inévitablement trop longue et pourrait être source de confusion ; et elle sera déjà suffisamment longue si l’on n’y inclut que les Patterns que l’on considère utiles.
On continue ainsi jusqu’à l’identification de tous les Patterns que l’on veut inclure dans le projet.
Parvenus à ce stade, il faut ajuster la liste en lui ajoutant, si nécessaires, ses propres éléments.
Enfin, il faut absolument tenir compte de la nécessité d’adaptations et de changements des Patterns, en fonction des exigences propres du projet en cours.

Catalogue des Patterns

Bibliographie

Alexandex C. et al. A Pattern Language – Towns, Buildings, Construction. New York: Oxford University Press, 1977

Norman, Donald. The Design of Everyday Things. New York: Basic Books, 1988

Alexander Christopher. The Timeless Way of Building. New York: Oxford University Press, 1979

Cunningham, Ward – Beck, Kent. Using Pattern Languages for Object-Oriented Programs, presented to the Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), 1987

Gamma Erich – Helm, Richard – Johnson, Ralph – Vlissides, John. Design Patterns – Elements of Reusable Object-Oriented Software. Boston: Addison Wesley, 1995

Patter language for the web
http://c2.com/cgi/wiki?PatternLanguageForTheWeb

Tidwell, Jenifer, COMMON GROUND: A Pattern Language for Human-Computer Interface Design, 1999
http://www.mit.edu/~jtidwell/common_ground.html

Tidwell, Jenifer. ULes patternss and Techniques, 2002
http://time-tripper.com/uipatterns/

Van Welie, Martin, Interaction Design Patterns, 2001
http://www.welie.com/patterns/

En outre, une bibliographie sur les recueils de Patterns sur le Web peut être consultée à:
http://iawiki.net/WebsitePatterns

	Museo&Web Kit d’élaboration d’un site de qualité pour un musée de petites ou moyennes dimensions
	MINERVA - contacts
vai al contenuto english italiano Museo&Web Architecture Communication Gestion Accessibilité Usabilité Interopérabilité Copyright Ressources utiles	Vous êtes à: Accueil - Tutorial - Architecture - Les patterns Les patterns Selon le Handbook for quality in cultural Web sites, paragraphe 2.5: « Une autre approche différente aux problèmes concrets d’élaboration et de réalisation de sites Web de qualité consiste à recourir à des patterns, qui se proposent de résoudre des problèmes récurrents grâce à des solutions connues et éprouvées. Le produit Web a désormais atteint un degré de maturité tel que les solutions à certains problèmes liés à son utilisation sont désormais considérées comme un patrimoine commun à tous les créateurs de projets. » « En outre, les Patterns peuvent être une référence utile pour ceuxqui doivent s’intéresser aux sites Web, sans être des experts en la matière. Dans ce cas, en effet, les Patterns peuvent constituer un langage commun de communication avec les professionnels pour indiquer ce que l’on veut et pourquoi, indépendamment de la manière de réaliser techniquement la solution. » « Les Patterns n’éliminent ni ne remplacent la nécessité de l’implication des usagers dont il a été question plus haut : au contraire, cette méthode profite, par définition, d’expériences concrètes faites avec les utilisateurs. » 2.5.1 Définitions Le paradigme des Patterns a été développé à la fin des années soixante-dix par Christopher Alexander, professeur d’Architecture à l’université de Berkeley, pour faire face aux problèmes complexes liés aux projets dans les domaines de l’urbanisme et du bâtiment. Selon Alexander, la mauvaise qualité de l’architecture des années soixante était due à l’absence de méthodes formelles de projet. Dans la pratique, il constata que les projets d’urbanisme et de bâtiments ne tenaient pas compte des expériences concrètes qui mûrissaient peu à peu et sans lesquelles les projets eux-mêmes finissaient par devenir étrangers aux exigences réelles des usagers. D’où l’idée de définir des Patterns qui établissent des relations entre un contexte, un ensemble de conditions (ou limites) liées à ce contexte et une solution qui résolve le problème avec ces conditions et dans ce contexte. À partir du milieu des années quatre-vingt-dix, l’idée d’utiliser des langages de Pattern comme support aux concepteurs de projets a reçu un nouvel élan grâce à l’énorme succès remporté par son application dans le domaine de l’ingénierie du logiciel et du projet object oriented. Récemment, le paradigme des Patterns a été appliqué aussi au domaine de la Human Computer Interface (HCI), avec extension au monde Web. Les Patterns visent à fournir une manière rigoureuse de décrire l’expérience d’un concepteur de projet à travers la formulation d’une solution à un problème commun. Ce qui caractérise cette approche, c’est le choix de ne pas donner de solutions « précodifiées » au problème, mais d’essayer plutôt de décrire correctement aussi bien le contexte que la solution, en réunissant sous un même titre les expériences et les solutions adoptées dans des situations semblables (y compris par d’autres personnes, en ne se limitant donc pas à ses propres solutions). Un Pattern est constitué d’une triade composée de: Contexte: c’est l’ensemble des conditions environnantes, le milieu dans lequel on agit; c’est l’ensemble des forces en action dont le Pattern doit tenir compte et qui limitent le choix des solutions; Problème: c’est une situation qui se présente de manière récurrente dans le contexte et qui crée des déséquilibres entre les forces en action; Solution: c’est un algorithme, une technologie, une structure d’organisation, une méthode connue, un modèle de référence qui résout de manière récurrente ce problème dans ce contexte. Soulignons le fait qu’un Pattern est constitué d’une triade : cela veut dire qu’à lui seul, un problème n’est pas un Pattern, et qu’une solution, à elle seule, n’est pas un Pattern. En un mot: un Pattern est une solution consolidée (well proven) à un problème récurrent dans un contexte spécifique. Pour compléter la définition d’un Pattern, il faut aussi d’autres éléments: Nom: un Pattern doit avoir un nom significatif. Donner un nom à quelque chose, c’est la première étape pour pouvoir en parler. Conditions: description des conditions (ou limites) présentes dans le contexte. Annotations: considérations (positives ou négatives) sur les conséquences de l’usage du Pattern courant. Pattern corrélés: relations entre le Pattern courant et d’autres Patterns utilisés dans le système de référence. Usages connus: références ponctuelles à des applications pratiques du Pattern courant. Un langage de Pattern rassemble des Patterns qui coopèrent pour résoudre les problèmes dans un certain contexte. Le contexte général de référence auquel nous désirons appliquer le langage des Patterns est le projet et la réalisation de WAI (« Web Accessibility Initative ») accessibles et utilisables, c’est-à-dire de qualité. Une fois établies les conditions de référence communes, il est nécessaire de donner une certaine organisation aux Patterns pour pouvoir les utiliser. La méthode que nous proposons ici consiste à construire un véritable Catalogue de Patterns, dont le but est d’identifier des catégories générales de problèmes à affronter. À l’intérieur de chacune de ces catégories s’insèrent des Patterns qui définissent et résolvent un problème particulier. 2.5.2 Le Catalogue des Patterns Pour construire le Catalogue des Patterns devant être appliqués au projet et à la réalisation d’un WAI accessible et utilisable, nous employons les mêmes catégories générales qui ont servi à regrouper les Critères d’usabilité. Nous leur ajoutons également: Interagir avec les usager: quand un SCP (« Sujet Culturel Public »)se présente sur l’Internet avec son site Web, il ouvre de fait un portail au citoyen. L’interactivité, qui veut dire ici la possibilité de communication directe entre citoyen et WAI, devient une fonctionnalité importante qui ne peut pas manquer. Nous présentons dans l’appendice 3 le Catalogue des Patterns et leur définition. 2.5.3 Comment utiliser les Patterns Enfin, il reste une question à éclaircir : comment « utilise-t-on » les Patterns. Dans un chapitre de son libre A Pattern Language, Christopher Alexander suggère d’entreprendre un parcours à la fin duquel on devrait avoir rempli une liste de Patterns nécessaires au projet. Les étapes à parcourir sont les suivantes: Examiner la séquence entière, le Catalogue des Patterns, qui est disponible. Identifier, à travers son nom, le Pattern qui identifie le mieux le projet/problème que l’on doit affronter. Lire attentivement sa description. Celle-ci indique les Patterns liés au Pattern actuel. On préparera ensuite une liste, en indiquant sur celle-ci les Patterns de niveau inférieur (plus spécifiques) que l’on rencontre, en négligeant, en général, les Patterns du niveau supérieur (moins spécifiques). Lire le Pattern suivant mis en évidence sur la liste et marquer de nouveau les Patterns inférieur auxquels il est lié. En cas de doute sur l’utilité d’un Pattern, celui-ci ne doit pas être inclus. En effet, le liste deviendrait inévitablement trop longue et pourrait être source de confusion ; et elle sera déjà suffisamment longue si l’on n’y inclut que les Patterns que l’on considère utiles. On continue ainsi jusqu’à l’identification de tous les Patterns que l’on veut inclure dans le projet. Parvenus à ce stade, il faut ajuster la liste en lui ajoutant, si nécessaires, ses propres éléments. Enfin, il faut absolument tenir compte de la nécessité d’adaptations et de changements des Patterns, en fonction des exigences propres du projet en cours. Catalogue des Patterns Bibliographie Alexandex C. et al. A Pattern Language – Towns, Buildings, Construction. New York: Oxford University Press, 1977 Norman, Donald. The Design of Everyday Things. New York: Basic Books, 1988 Alexander Christopher. The Timeless Way of Building. New York: Oxford University Press, 1979 Cunningham, Ward – Beck, Kent. Using Pattern Languages for Object-Oriented Programs, presented to the Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), 1987 Gamma Erich – Helm, Richard – Johnson, Ralph – Vlissides, John. Design Patterns – Elements of Reusable Object-Oriented Software. Boston: Addison Wesley, 1995 Patter language for the web http://c2.com/cgi/wiki?PatternLanguageForTheWeb Tidwell, Jenifer, COMMON GROUND: A Pattern Language for Human-Computer Interface Design, 1999 http://www.mit.edu/~jtidwell/common_ground.html Tidwell, Jenifer. ULes patternss and Techniques, 2002 http://time-tripper.com/uipatterns/ Van Welie, Martin, Interaction Design Patterns, 2001 http://www.welie.com/patterns/ En outre, une bibliographie sur les recueils de Patterns sur le Web peut être consultée à: http://iawiki.net/WebsitePatterns retour haut de page
MINERVA - contacts torna alla navigazione

Museo&Web

Les patterns

2.5.1 Définitions

2.5.2 Le Catalogue des Patterns

2.5.3 Comment utiliser les Patterns

Bibliographie