Glisser-Déposer (2)

Ce que dit Apple :

5- Rétroaction de la destination :

Si un utilisateur glisse un item vers une destination, dans votre application, elle doit fournir une rétroaction qui indique si l'item sera accepté. La rétroaction de la destination ne doit pas simplement intervenir parce que l'application sait gérer le glissement ; elle doit plutôt dépendre de l'aptitude de la destination à accepter le type de données contenu dans l'item glissé. Par exemple, un champ d'entrée de texte, qui n'accepte que du texte, ne doit pas s'éclairer quand il reçoit un item graphique.

Utilisez des pointeurs pour indiquer quel résultat aura le relâchement de la souris. Par exemple, si vous glissez une icône à l'extérieur d'une barre d'outils affichez le pointeur en nuage (poof pointer) quand l'icône déplacée passe en dehors de la barre d'outils pour indiquer que si l'utilisateur relâche la souris, l'item va disparaître. Il y a d'autres pointeurs capables de fournir une rétroaction utile pendant une opération de glissement : alias, copie, pas autorisé (voir les pointeurs).

Avec Carbon, l'apparence réelle de la rétroaction de destination dépend du type de destination. Le Drag Manager fournit quelques outils pour un éclairage simple ; si votre application nécessite un éclairage plus complexe, vous devez utiliser vos propres outils d'éclairage.

a- Les fenêtres

Une région de destination valide, dans la fenêtre d'un document, est en général le contenu de la fenêtre, moins la barre de titre, moins les zones de contrôle (barres de défilement, case de redimensionnement, palettes d'outils, règles et placards). S'il y a de multiples régions de destination possibles dans une fenêtre, une seule région de destination est éclairée à la fois.

Quand un utilisateur glisse un item acceptable dans une région de destination, l'application doit éclairer la région dès que le pointeur entre dedans, et supprimer l'éclairage s'il en sort.

Si une opération Glisser-Déposer se tient entièrement à l'intérieur d'une seule région de destination (par exemple, le déplacement d'une icône de document à l'intérieur du même dossier), n'éclairez pas la région de destination, pour éviter de distraire l'utilisateur. Mais si l'utilisateur glisse un item entièrement hors de la région de destination, et le ramène dans cette même région, celle-ci doit être éclairée.

Vous pouvez fournir une rétroaction plus spécifique dans des régions de destination étendues. Par exemple, si un utilisateur glisse du texte de la fenêtre d'un document à une autre, la fenêtre de destination doit afficher un point d'insertion à l'endroit où le texte sera déposé quand l'utilisateur va relâcher la souris.

Dans de nombreuses situations, éclairer une zone limitée dans une fenêtre est plus approprié que d'éclairer toute la région. C'est le cas pour les tableurs, les boîtes de texte, les formulaires. Dans ces cas, la région de destination doit être adaptée pour indiquer précisément la destination spécifique.

b- Le texte

Quant un utilisateur glisse un item dans une zone de texte, un pointeur d'insertion (barre verticale) doit apparaître dans le texte à l'endroit où l'item sera inséré quand la souris sera relâchée.

c- Les listes

Un pointeur d'insertion doit apparaître dans une liste où un item se trouve glissé, pour indiquer où il sera déposé. par exemple, si un utilisateur glisse un item dans la barre latérale du Finder, un indicateur d'insertion apparaît.

d- Items multiples

Si l'utilisateur glisse des items multiples, la rétroaction de destination ne soit intervenir que si celle-ci peut accepter les items ; si elle ne peut pas les accepter tous, la tentative s'inscrit dans la rétroaction d'un dépôt invalide.

Quand la destination peut accepter tous les items, elle doit le faire dans l'ordre défini par la source. L'application source doit organiser les items dans l'ordre où ils ont été sélectionnés, sauf dans deux cas :
- si les items glissés proviennent de vues ordonnées (comme une vue par Date, ou une liste alphabétique), cet arrangement prévaut sur l'ordre de sélection
- si la source et la destination permettent toutes deux un ordonnancement spatial (comme dans des applications graphiques), l'ordre spatial prévaut sur l'ordre de sélection.

e- Le défilement automatique

Quand un item est glissé, votre application doit déterminer s'il faut faire défiler le contenu ou permettre à l'item d'échapper à la fenêtre. Si votre application autorise les items à être glissés à l'extérieur de la fenêtre, vous devez définir une région de défilement automatique. Ne faites défiler une fenêtre destination que si c'est aussi la fenêtre source, et qu'elle est active. Ne faites pas défiler automatiquement des fenêtres inactives.

f- La corbeille comme destination

Glisser des items dans la corbeille revient à les déplacer de la source vers la corbeille. Par exemple, glisser une sélection de texte depuis un traitement de texte et la déposer dans la corbeille efface le texte de l'application, et une coupure qui contient ce texte est créée dans la corbeille. Notez que l'item est déplacé, bien qu'il soit glissé entre deux conteneurs. Cette exception aux règles décrites précédemment se justifie parce que l'utilisateur peut défaire l'opération en sortant la coupure de la corbeille, pour la remettre dans sa source initiale ; c'est cohérent avec le principe de la prévention d'une perte accidentelle de données.

Il est important de conserver cette propriété de la corbeille ; n'effacez pas simplement des données d'une source sans créer une coupure, ou un autre item dans la corbeille.

6- Rétroaction du dépôt :

Quand un utilisateur relâche le bouton de la souris après un glissement, la rétroaction doit l'informer que l'opération Glisser-Déposer a réussi. Cette rétroaction peut être visuelle, mais elle est par nature comportementale. Le comportement tient à l'opération sémantique indiquée par la séquence Glisser-Déposer.

a- Les icônes du Finder

Quand l'utilisateur déplace un item en déposant son icône dans un dossier, l'icône déposé disparaît et l'éclairage de l'icône dans le dossier destination est annulé.

Si une icône représente une tâche (comme une impression), vous pouvez fournir une rétroaction de progression pour indiquer que la tâche est en cours.

b- Les graphiques

Quand on dépose des graphiques, la rétroaction de dépôt est normalement le mouvement de l'item jusqu'à la position de l'évènement mouse-up.

c- Le texte

Après qu'un texte a été déposé, il est éclairé dans sa destination.

Si du texte est déposé dans une destination qui accepte un texte enrichi, le texte déposé doit conserver sa police, sa graisse, et ses attributs de taille. Si la destination ne supporte pas du texte enrichi, le texte déposé doit adopter la police, la graisse et la taille du point d'insertion.

Les opérations Glisser-Déposer sur du texte doivent supporter les règles du Couper-Copier intelligent.

d- Transfert d'une sélection

Après une séquence Glisser-Déposer réussie dans une fenêtre unique, la rétroaction de sélection est maintenue à sa nouvelle position. Ce comportement fournit à l'utilisateur un signal important, et lui permet de changer la position sans refaire une sélection.

Si l'utilisateur glisse un item d'une fenêtre active vers une fenêtre inactive, l'item glissé devient une sélection en arrière plan ; la sélection dans la fenêtre active reste sélectionnée. Cette règle s'applique aussi à la situation inverse, quand un item est glissé d'une fenêtre inactive à une fenêtre active.

Quand un contenu est déposé dans une fenêtre où quelque chose est sélectionné, votre application doit tout dé-sélectionner dans la destination avant le dépôt, plutôt que de remplacer la sélection par l'item déposé.

e- Rétroaction d'un dépôt invalide

Si un utilisateur tente de déposer un item dans une destination qui ne l'accepte pas, l'item doit revenir en arrière, de la position mouse-up à sa position initiale dans la source (c'est un zoomback). Le Zoomback doit aussi intervenir quand un dépôt dans une destination valide ne réussit pas.

Si un utilisateur tente un glissement multiple dans une destination qui ne l'accepte pas, aucun des items ne doit être accepté. Dans un tel cas, vous pouvez afficher un dialogue pour informer l'utilisateur du type de données que la destination accepte, et quels items dans l'ensemble qui a été déposé ne peuvent pas être acceptés.

7- Les coupures (clippings) :

Quand un item est glissé d'une application vers le bureau, une coupure est créée, qui contient les données contenues dans l'item glissé. Si des sélections discontinues sont glissées depuis une source vers le Finder, des coupures séparées sont créées pour chaque item sélectionné.

Votre application doit fournir des représentations (formats, comme TEXT, PICT, des formats natifs) différentes pour assurer la flexibilité avec des destinations différentes. Quelles que soient les représentations qui sont stockées, l'intégrité des données doit être conservée : une coupure, ramenée à sa source, doit être identique à l'item original.

Mes commentaires :

Cette section est (logiquement) dans la même veine que la précédente consacrée à l'édition de texte. Un luxe de détails très précis sur le comportement du Glisser-Déposer dans toutes les circonstances possibles. Bien que ces considérations soient d'abord destinées aux programmeurs, je crois qu'un utilisateur lambda y apprendra beaucoup de choses : en fait, cela l'aidera à prendre conscience d'opérations qu'il a toujours faites machinalement sans se poser de questions, et à comprendre pourquoi cela se passe (et doit se passer) ainsi.

Du grand art, digne d'Apple.