1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales



L'étagère

Le browser du Finder devrait avoir une étagère dans le style NeXT, pour la simple raison que c'est simple à implanter, et qu'elle peut être invisible pour ceux qui ne veulent pas l'utiliser. Une étagère est simplement un endroit où déposer des icônes de proxies. Déposer un item sur l'étagère crée une icône de proxy pour cet item, mais l'item lui-même n'est pas déplacé. En d'autres termes, les icônes de proxy se comportent comme celles des dossiers de recherche actifs (à la différence que les items peuvent être déposés sur l'étagère, alors que dans des dossiers de recherche actifs, on ne peut pas déposer d'items).

Une étagère peut prendre des formes diverses, mais la plus évidente est simplement un espace dans la barre d'outils de la fenêtre du browser. Une autre option serait un tiroir qui glisse sur l'un des bords de la fenêtre du browser du Finder. Ou bien, le Finder pourrait aussi admettre une étagère flottante globale, qui pourrait être positionnée n'importe où, ou entreposée sur un bord de l'écran.

Puisqu'on parle du Dock, l'étagère pourrait lui ressembler beaucoup. Mais rappelez vous que les items que vous ôtez du Dock disparaissent dans un nuage de fumée, alors que les items déplacés depuis l'étagère sont déplacés vers une nouvelle position. (Pour retirer un item de l'étagère, utiliser "Supprimer" dans le menu contextuel -Ctrl-click, ou click et maintenir- de l'item). Notez aussi que de nombreux items peuvent être déposés sur l'étagère, où ils seront représentés par une seule icône, une "collection de proxies", alors que de multiples items dans le Dock ont leur propre icône.

Les lecteurs qui n'ont pas utilisé une étagère de style NeXT dans le passé peuvent se demander à quoi cette caractéristique est utile. La réponse courte (mais signifiante) est que l'étagère fournit une facilité d'IUG pour des opérations de déplacement et de copie en deux étapes. La réponse longue, la voilà.

Pour déplacer ou copier un fichier à un autre endroit dans le Finder (spatial ou non), il est d'habitude nécessaire de faire apparaître à la fois la source et la destination. Les dossiers bondissants, qui s'ouvrent les uns dans les autres atténuent quelque peu cette nécessité, mais la coordination et la concentration mentale qu'il faut pour descendre (ou remonter) avec succès vers une destination distante depuis une position arbitraire dans la hiérarchie rend cette procédure plutôt inconfortable, et entretient souvent la confusion.

L'étagère fournit une étape de repos dans le processus. L'item à déplacer ou à copier est d'abord déposé sur l'étagère. Oui, cela signifie que à la fois la source et l'étagère doivent être accessibles, mais ce sera vraisemblablement le cas si une étagère globale est utilisée, (elle peut flotter sur les fenêtres du Finder), ou si la fenêtre du browser est sur l'écran. L'utilisateur peut alors naviguer jusqu'à la destination, en utilisant le moyen qu'il veut. Il n'y a rien qui ressemble à la "pression" (à la fois littérale et figurée) associée à une opération de déplacement en continu à l'aide des dossiers bondissants.

De plus, comme les lecteurs astucieux l'auront déjà remarqué, l'étagère élimine le besoin de cette perversion de métaphore d'interface que constitue l'utilisation du Copier/coller pour les fichiers. La commande <Edit<Copier le fichier devient alors <Fichier<Mettre sur l'étagère, et la commande <Edit<Coller le fichier se partage en deux commandes, <Fichier<Copier depuis l'étagère, et <Fichier<Retirer de l'étagère, ce qui la rend plus efficace que le copier/coller (où couper n'est pas une option), et est plus sain et plus consistant avec le reste de l'interface utilisateur. Ces commandes doivent avoir aussi une manifestation visuelle. Il peut y avoir une forme d'animation quand les items se déplacent depuis ou vers l'étagère lors de l'exécution de ces commandes. Et à la différence du Copier/coller, les items restent sur l'étagère même si un autre item y est mis aussi. Cela devrait se comporter comme une pile de ce point de vue. Pour finir, évitez une confusion : ces commandes doivent toujours opérer sur l'étagère "globale" plutôt que sur celle attachée à une fenêtre du browser du Finder.

Le browser spatial

Traditionnellement, les fenêtres de type browser sont toutes identiques. Par exemple, il n'y a rien qui puisse distinguer une fenêtre de browser Web d'une autre. Bien sûr, les fenêtres de browser Web peuvent conserver leur position initiale, et peut être aussi des préférences de superposition pour des fenêtres subséquentes. Mais en général, les fenêtres de browser ne sont pas facilement identifiées et mémorisées à partir de signaux spatiaux. Ce n'est pas une situation optimale, bien sûr. Et on peut changer cela.

La première étape est d'autoriser les fenêtres du browser du Finder à être sauvegardées sous forme de fichiers. Imaginez ces fichiers comme des documents dont le possesseur est le Finder, tout comme TextEdit possède des fichiers texte. Double-cliquer sur l'un de ces "browsers sauvegardés" va rouvrir la fenêtre du browser du Finder, en restituant son état exact au moment de la sauvegarde. Cet état inclut la position de la fenêtre et sa taille, l'état du défilement, le style de présentation, les items et la visibilité de la barre d'outils, le contenu de l'étagère, et ainsi de suite.

Ce que cela signifie, c'est que des changements sur une fenêtre particulière du browser du Finder ne sont pas automatiquement répercutées sur les autres fenêtres de browser. C'est différent de ce qui existe dans le Finder de Mac OS X, où les changements dans la barre d'outils du Finder affectent toutes les fenêtres du Finder, par exemple. Au lieu de cela, tout browser de Finder se comporte comme un document, mais avec une option sauvegarde automatique pour les browsers qui ont déjà été sauvés sur disque. Il devrait aussi y avoir une option pour permettre à de nouvelles fenêtres de browser de prendre par défaut l'état d'un browser donné.

Pour finir, un browser peut être désigné comme "browser par défaut" pour un dossier particulier. De ce point de vue, à chaque fois qu'une fenêtre de browser est ouverte dans ce dossier (à l'aide du menu contextuel "Un nouveau browser ici", ou d'un item de menu, par exemple), le browser préalablement sauvegardé sera utilisé.

Tout cela doit permettre à l'utilisateur de se créer des environnements familiers adaptés à des tâches spécifiques. Si toutes les fenêtres de browser sont identiques, le résultat est un browser médiocre, qui est touche à tout et bon à rien. Par exemple, s'il n'y a pas assez de place dans une barre d'outils pour chaque application sur laquelle un utilisateur pourrait avoir envie de déposer un fichier, elle finit par n'être occupée que par les plus importantes.

Quand chaque browser est indépendant et peut être sauvegardé pour un usage ultérieur, l'utilisateur est encouragé à personnaliser spécifiquement chaque browser pour une tâche donnée. Un browser affecté à la photographie pourrait remplir sa barre d'outils d'applications pour éditer des images, par exemple, et son étagère pourrait contenir les dernières photos éditées. Si on combine la possibilité d'associer des browsers sauvegardés à des dossiers particuliers, un utilisateur n'a plus à traîner avec lui un environnement générique de navigation quand il parcourt le système de fichiers. Au lieu de cela, son environnement préféré pour un sous-ensemble du système de fichiers surgit en réponse à sa navigation.

Considérez cela comme une "navigation spatiale". De la même façon qu'il est efficace et rassurant de voir les mêmes dossiers aux mêmes places dans le même état jour après jour, les utilisateurs vont aussi bénéficier de fenêtres de browsers faciles à reconnaître, à mémoriser, et à personnaliser. Cette possibilité peut même être étendue avec la caractéristique qui suit.

Les greffons du Finder

Le système de présentation du Finder devrait reposer sur une architecture de greffons. C'est aussi une idée d'Apple, dans le passé, mais comme je ne peux pas me souvenir de la source exacte, (ce pourrait être Copland, mais aussi Rhapsody), vous avez le droit de prétendre que c'est une idée qui m'est propre.

Chaque style de présentation est défini par un module de greffon : la vue en icônes, la vue en liste, etc... Les greffons peuvent fonctionner dans des dossiers, dans des fenêtres de browser, ou les deux. C'est au développeur de greffon (et à l'utilisateur) de maintenir l'intégrité du Finder Spatial, en n'utilisant pas, par exemple, un greffon de vue en colonnes qui fonctionne sur des dossiers normaux (le greffon par défaut de la présentation en colonnes ne le fera pas). Mais ce n'est pas vraiment un gros problème, étant donné que ceux qui aiment la vue en colonnes voudront certainement l'utiliser dans une fenêtre de browser complète plutôt que dans un dossier standard comparativement anémique.

Comme promis, la combinaison de greffons de présentation avec la navigation spatiale est réellement payante. Imaginez qu'un browser sauvegardé orienté photo utilise aussi un greffon de présentation qui affiche des vignettes, tout comme le fait iPhoto par exemple.

La barre d'outils du browser du Finder devrait aussi accepter des greffons. (Bien que j'espère que cela va sans dire, toutes ces APIs de greffons devraient être ouvertes aux développeurs tiers). L'ensemble par défaut des greffons devrait inclure des items comme des boutons arrière/avant/stop, la barre d'adresse, et autres, aussi bien que des rajouts indépendants à la barre d'outils, comme l'étagère. A ce propos, je crois qu'au moins quelques utilisateurs de Windows XP voient où je veux en venir, si bien que je vais m'arrêter là.

Utiliser une présentation du Finder et des greffons dans la barre d'outils, et le support, au niveau du système d'exploitation, de méta-données extensibles à volonté à hautes performances, c'est seulement un petit effort vers la création d'une fenêtre de browser du Finder, c'est à dire, pour l'essentiel, iPhoto.

Je ne suggère pas que le browser du Finder devrait remplacer iPhoto car une application dédiée se comportera toujours mieux pour une tâche donnée (ce qui est la raison pour laquelle le Finder a son propre browser, rappelez-vous). Je cherche seulement à montrer tout ce qu'on peut faire avec un Finder modulaire si on admet un système de stockage robuste de méta-données. Si vous y réfléchissez, le stockage et la récupération de méta-données représente presque la moitié de la fonctionnalité d'iPhoto et d'iTunes. Déplacer cette possibilité depuis des applications particulières (chacune devant trouver ses propres solutions) vers l'OS lui-même est très utile et prometteur. C'est une situation gagnant-gagnant : iTUnes et iPhoto s'amincissent, et le Finder devient beaucoup plus puissant.