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

Mac OS X 10.1




12- Méta-données

La section des extensions de noms de fichiers.

Dans un article précédent, j'ai passé beaucoup de temps à aborder l'histoire des méta-données, et son rôle dans Mac OS X. Je l'ai fait, en partie parce que c'est un sujet si énorme que je ne voulais pas qu'il submerge ce rapport sur Mac OS X. Mais depuis que cet article sur les méta-données a été écrit, il y a eu une clarification publique de la politique d'Apple, qui confirme quelques unes de mes pires craintes sur le futur des méta-données sous Mac OS X.

Dans l'article sur les méta-données, j'ai écrit que la politique des méta-données d'Apple pour Mac OS X jusqu'à présent "semblait reposer sur l'affirmation que le type méta-données d'un fichier sera toujours encodé dans le nom de fichier". Hélas, il s'est révélé que j'avais raison.

La déflagration est d' abord apparue sur une liste de nouvelles d'Apple, et a plus tard été confirmée dans les notes de livraison de Mac OS X. Lisez l'un de ces liens si vous ne l'avez pas déjà fait (1), parce que le comportement précis du système de gestion des méta-données sous Mac OS X 10.1 est très complexe, et que je ne crois pas qu'il puisse être expliqué de façon plus concise qu'il ne l'est dans ces documents. Mais s'il devait être condensé en une seule phrase, ce serait celle ci :
Les extensions de noms de fichiers sont obligatoires sous Mac OS X.

Pour se conformer aux nouvelles règles de méta-données de 10.1, tous les fichiers créés par des applications de Mac OS X doivent comprendre une extension de fichier.

La complexité évoquée précédemment est due à un système élaboré pour cacher les extensions de noms de fichiers en fonction de l'utilisateur, du fichier, du contexte, pour empêcher les conflits et les confusions, et à une longue liste de règles pour les applications qui créent des fichiers ou affichent des noms de fichiers. Mais la base est que chaque nouveau fichier créé par une application Mac OS X doit être créé avec une extension de fichier adéquate.

Le raisonnement derrière cette politique est simple. Si chaque fichier créé sous Mac OS X dispose d'une information sur le type de fichier encodée dans son nom, il n'y a pas besoin (de la part de l'OS ou de l'utilisateur) d'action supplémentaire quand un fichier est partagé par un autre système d'exploitation qui s'attend à ce que l'information sur le type de fichier soit encodé de cette façon (par exemple, Windows).

Les règles pour cacher ou éditer l'extension du nom de fichier ont pour objet d'empêcher l'utilisateur de Mac OS X 10.1 de connaître quelles extensions sont associées effectivement à un fichier à un moment donné, et à les empêcher de supprimer ou de modifier cette information. Le principe de base est défini par Apple comme "ce que vous voyez est ce que vous avez tapé", ce qui signifie que le nom exact entré par l'utilisateur dans une boite de dialogue d'enregistrement, ou quand il édite un fichier depuis le Finder doit être ce que montre l'IUG. (consultez les règles officielles pour une explication plus détaillée.)

En outre, des types de fichiers traditionnels, stockés séparément , et des méta-données de créateur (sous la forme des codes créateur de HFS/HFS+) sont optionnels, dans cette nouvelle politique. Les développeurs d'applications "ont le droit" de définir cette information "s'ils le veulent". Le seul intérêt qu'Apple mentionne pour cela est "d'accroître l'inter-opérabilité avec les applications Mac OS 9".


La sous-section des méta-données en action sous Mac OS X 10.1.

Le tableau ci-dessous donne un bref aperçu des règles de méta-données en action dans Mac OS X 10.1. il montre une séquence d'actions de l'utilisateur, le nom de fichier qui en résulte (à la fois le nom réel, et celui affiché par le Finder), les codes de type et de créateur, l'icône, l'association à l'application, et d'autres alertes ou interactions.

figure

Pour ces manipulations on obtient :
• Quatre noms différents de fichiers affichés
• Cinq noms différents de fichiers réels
• Trois situations dans lesquelles le nom de fichier réel est différent de celui affiché
• Quatre icônes différentes (dont l'une ne donne aucune indication sur l'application qui peut ouvrir le fichier)
• Trois applications différentes qui se sont lancées et ont essayé d'ouvrir le fichier quand on double-clique dessus
• Quatre dialogues d'alerte dans le Finder
• Un dialogue d'erreur dans Aperçu
• Deux exemples d'affichage incohérent par TextEdit.

(A aucun moment, les codes HFS/HFS+ type ou créateur n'ont été définis).

Les actions de l'utilisateur qui ont provoqué tout cela sont un "Enregistrer" à partir d'une application, ou une série d'opérations pour renommer le fichier dans le Finder.

En guise de comparaison, une séquence équivalente d'opérations dans Mac OS Classique aurait provoqué :
• Une seule icône affichée dans le Finder
• Une seule application lancée au moment où on double clique le fichier
• Le nom de fichier affiché correspond toujours au nom de fichier réel.

Je répète, tout cela est le résultat d'un simple enregistrement, et d'opérations de changement de nom du fichier sous 10.1. Et oui, il y a eu beaucoup de dialogues d'alerte, mais le fait est, que renommer un fichier n'est pas inquiétant, qu'il y ait des alertes ou pas.

En outre, les dialogues d'alerte affichés par le Finder indiquent seulement que renommer peut entraîner le document à "s'ouvrir dans une autre application". Il n'y a eu aucune mention de l'impossibilité de visionner le document ou d'une perte de la portabilité entre les plateformes, en dépit du fait que, dans cind des six cas de cette séquence, le fichier ne se serait pas ouvert correctement sur un système Windows.


La sous-section des gros problèmes.

Inutile de dire qu'il y a eu une forte et bruyante opposition à cette politique des méta-données de Mac OS X 10.1, de la part d'une grande partie de la communauté mac. Et il n'est pas surprenant que j'aie pris part à cette opposition. Je ne pense pas qu'on puisse contester l'amélioration de l'inter-opérabilité que la stricte adhérence à cette politique permet. Ce qui est discutable, c'est d'avoir mis en priorité cette inter-opérabilité, au dessus de toute autre chose. La conséquence normale de ce système de valeurs est tout simplement d'utiliser Windows.

Apple semble vouloir tout à la fois : une inter-opérabilité parfaite entre les plateformes, combinée à une expérience utilisateur "locale" riche, correspondant à celle du Mac. Mais étant donné l'état actuel des plateformes "étrangères" avec lesquelles Apple veut inter-opérer, des sacrifices sur une partie (ou les deux) de l'équation sont nécessaires. La police de méta-données de 10.1 sacrifie la simplicité et le contrôle (à la fois pour les développeurs d'application et les utilisateurs) de l'expérience utilisateur en local, pour essayer d'améliorer l'inter-opérabilité entre les plateformes. C'est un sacrifice déraisonnable pour de multiples raisons.

Bien que l'inter-opérabilité soit améliorée, elle n'est toujours pas parfaite. Les millions de fichiers créés sous Mac OS Classique existent toujours sur les disques des utilisateurs de Macs- des fichiers qui n'ont pas d'extension de fichier, ou pire, des fichiers qui semblent avoir une extension (1). Et n'oubliez pas les fichiers qui ont une fourche de ressources, et qui devront être encodés pour passer correctement d'une plateforme à une autre, qu'ils aient ou non une extension de fichier.

La capacité de choisir des noms de fichiers significatifs pour l'utilisateur plutôt que pour l'OS et d'avoir sur eux un contrôle complet (pas simplement l'illusion d'un contrôle) a été une des caractéristiques distinctive de l'expérience utilisateur du Mac depuis 1984. Cela a aussi été un de ses plus importants avantages. Si les utilisateurs de Macs valorisaient d'abord et en premier lieu l'inter-opérabilité, au dessus de l'expérience utilisateur locale, ils n'utiliseraient pas des Macs.

Si ce sacrifice d'un avantage historique important de la plateforme Mac est sensé attirer plus d'utilisateurs d'autres plateformes, il est voué à l'échec. D'abord, parce que les modifications affectent une portion substantielle de la base des utilisateurs de Macs, si bien que beaucoup d'entre eux devront changer de plateforme pour rester simplement opérationnels.

Ensuite, dans l'ambitieux dessein des choses, l'obligation des extensions des noms de fichiers est une goutte d'eau dans l'océan du changement de plateforme. Les convertis à la plateforme Mac devront encore acheter un tout nouveau matériel, de tout nouveaux logiciels, apprendre un nouveau système d'exploitation, convertir, transférer et perdre des milliers de fichiers existants, puis se trouver confrontés avec tous les désavantage de leur nouvelle plateforme : moins de choix dans le matériel, une sélection réduite de logiciels, des matériels plus chers, etc...

De plus, le "bénéfice" de cette conversion réside dans tous les avantages historiques de la plateforme Mac qui n'ont pas réussi à attirer cet utilisateur dans le passé, moins l'un des plus gros avantages qui a justement été sacrifié dans l'effort fait pour provoquer la conversion !

Si la nouvelle politique a pour but d'améliorer l'expérience utilisateur de la base actuelle d'utilisateurs de Macs, les réactions à ce problème démontrent clairement jusqu'à présent que c'est un échec pour beaucoup.

Paradoxalement, cette nouvelle politique menace l'inter-opérabilité avec la plateforme qui est la plus susceptible d'être utilisée par les utilisateurs de Macs : Mac OS classique. Des fichiers créés sans les codes type/créateur par des applications Mac OS X peuvent n'être pas utilisables sous Mac OS classique, ou dans le propre environnement classique de Mac OS X.

Pire, la politique de méta-données de 10.1 ferme aussi la porte, en fait, à beaucoup de possibilités de méta-données dans le futur, en n'exigeant pas que toutes les méta-données soient incorporées à tout fichier créé sous Mac OS X. Moins de méta-données signifie dans le futur moins d'interprétations possibles, et par conséquent moins de possibilités pour les associations avec des applications, l'affichage d'icônes, et ainsi de suite.


Les solutions.

La solution évidente est qu'Apple en vienne à un nouveau système de méta-données pour Mac OS X qui améliore l'inter-opérabilité tout en conservant tous les avantages de la façon de faire du mac. Ce nouveau système devrait être compatible avec les codes type/créateur, mais être une implémentation entièrement nouvelle allant au delà des limitations de ses prédécesseurs. Une caractéristique possible de ce nouveau système pourrait inclure l'utilisation des méta-données du système de fichiers extensible de style BeFS, des types MIME, des identificateurs d'applications de type Java (par exemple "com.adobe.Photoshop"), etc... L'inter-opérabilité de ce nouveau système, quoique importante, ne devra jamais sacrifier l'expérience utilisateur en local.

C'est une barre haute, bien sûr, et personne ne s'attend à ce qu'un tel système surgisse, complètement terminé, des cerveaux d'Apple (surtout quand ils encore à se battre apparemment avec la position des fenêtres et des icônes dans le Finder. Soupir désolé ;-). Mais il y a une solution intermédiaire plus simple qui réclame beaucoup moins de travail.

Partir de la politique de méta-données de Mac OS X , mais faire les modifications suivantes :
• Toutes les applications Mac OS X doivent écrire les codes HFS/HFS+ type et créateur en créant un fichier.
• Rendre la politique d'association à une application configurable par l'utilisateur. Inclure des configurations prédéfinies qui correspondent aux pratiques traditionnelles de Mac OS et de Windows, et permettre des pratiques personnalisables, créées par l'utilisateur, qui référencent (ou ignorent) les méta-données de l'utilisateur, en déterminant dans quelle application un fichier va s'ouvrir, et quelle icône sera affichée pour ce fichier dans le Finder.
• Ajouter des APIs de "services de méta-données" à l'OS, pour convertir les représentations de méta-données variées dans les deux sens : rajout d'extensions au nom de fichier (basées sur une autre méta-donnée de type de fichier, ou même sur le contenu du fichier), ou suppression des extensions de nom de fichier (en définissant convenablement d'autres méta-données sur le type de fichier). Ces APIs se rapporteraient à une table de correspondance sur la représentation des méta-données configurable par l'utilisateur, et pour chaque utilisateur.
• Modifier les boîtes de dialogue "Ouvrir/Enregistrer" pour exploiter les APIs de service de méta-données, et fournir à chaque utilisateur, des préférences au niveau du système et par application, pour qu'il puisse contrôler quelles applications ajoutent une extension par défaut et celles qui ne le font pas. Toutes les boîtes de dialogue "Ouvrir/Enregistrer" devraient avoir une case à cocher pour permettre de supplanter le choix par défaut pour chaque fichier.
• Ajouter des commandes de menu et des menus contextuels au Finder qui utilisent les nouveaux services des APIs de méta-données pour permettre à l'utilisateur de convertir des fichiers sélectionnés (ou des dossiers pleins de fichiers, ou des volumes complets pleins de fichiers) dans l'une ou l'autre des représentations des méta-données.
• Modifier chaque application ou service système qui dépend de la présence d'extensions de noms de fichiers pour comprendre aussi les méta-données de type de fichier stockées dans des emplacements autres que le nom de fichier.
• Rendre le nom de fichier, y compris toute extension, visible et éditable à tout moment.

Pour améliorer l'inter-opérabilité, une future version de Mac OS X incluant les changements listés ci-dessus pourrait être proposée avec des réglages par défaut qui correspondent étroitement au comportement actuel de 10.1 : l'option au niveau du système pour ajouter des extensions de nom de fichier pourrait être mise par défaut, et la pratique d'une association personnalisable pourrait être définie pour correspondre au comportement de 10.1.

Un tel système aurait pratiquemnt tous les avantages de l'inter-opérabilité, en procurant aussi aux utilisateurs expérimentés de Macs, qui veulent (et sont capables de) gérer l'inter-opérabilité par eux-mêmes, la possibilité de le faire en conservant un contrôle complet, direct et simple sur tous les noms de fichiers. Les nouvelles APIs de service pour les méta-données, leur utilisation dans le Finder, et les boîtes de dialogue standard "Ouvrir/Enregistrer" fourniraient encore plus de puissance aux utilisateurs expérimentés, en les libérant de quelques unes des tâches les plus ennuyeuses de conversion manuelle.


Sous-section Conclusion sur les méta-données.

La politique de méta-données sous Mac OS X 10.1 est complexe dans son implémentation (au point d'en devenir parfois mystérieuse), mal orientée dans ses motivations apparentes, et n'atteint pas la qualité de l'expérience de l'utilisateur du Mac traditionnel, qu'elle est sensée remplacer. En plus, elle rendra de futures améliorations plus difficiles, parce que des fichiers créés avec des méta-données partielles par des applications Mac OS X qui respectent cette politique vont proliférer. Je voudrais paraphraser quelque chose que j'ai écrit dans l' article sur les méta-données, parce que ce sentiment semble encore actuel dans la situation présente :

Il y a le sentiment dans une partie de la communauté Mac que les avantages d'utiliser un Mac sont érodés lentement par Mac OS X ; étant donnée la faible part de marché d'Apple, des compromis sont souvent nécessaires pour conserver des niveaux acceptables d'inter-opérabilité. Mais dans les cas où des solutions alternatives fournissent des améliorations similaires d'inter-opérabilité, sans sacrifier les aspects favorables de l'expérience utilisateur du Mac, Apple devrait faire tout ce qui est en son pouvoir pour les implémenter telles quelles. Tout élément de l'expérience utilisateur de Mac OS X qui répète l'expérience sur une autre plateforme cesse d'être une bonne raison d'acheter un Mac.




(1) Note du traducteur : ces liens Apple ont disparu de la toile, et n'ont donc pas été reproduits ici. Je les ai parfois remplacés par des liens opérationnels plus récents.