Les applications Mac et les projets Mac sont des axes d'organisation différents. Les groupes d'applications répondent à la question « de quel programme s'agit-il ? » Les groupes de projets répondent à la question « à quel résultat cette fenêtre m'aide-t-elle à aboutir ? » Choisissez l'axe qui supprime l'ambiguïté à laquelle vous êtes réellement confronté.
Utilisez les groupes d'applications lorsque l'application définit déjà le travail
Une vue basée sur les applications est efficace lorsque chaque application a un rôle stable. Si Mail ne sert qu'à la communication, qu'un navigateur ne sert qu'à la recherche et qu'une application de traitement de texte contient un seul brouillon actif, Commande-Tabulation et App Exposé fournissent déjà un moyen simple. Ajouter des étiquettes de projet créerait de la maintenance sans améliorer l'identification.
Le modèle commence à échouer lorsqu'un même navigateur contient deux clients, ou lorsqu'un éditeur possède des fenêtres pour des dépôts non liés. Le nom de l'application est alors vrai mais insuffisant.
Utilisez les groupes de projets lorsque le travail dépasse les limites des applications
Prenez deux livrables pour des clients qui nécessitent chacun une fenêtre de navigateur et un document. Regrouper par application produit une pile de navigateurs et une pile de documents. Regrouper par livrable produit deux ensembles complets :
| Livrable | Fenêtres |
|---|---|
| Revue Client A | page de commentaires, brouillon, dossier de ressources |
| Lancement Client B | page de préproduction, liste de contrôle, note analytique |
Cela ne nécessite ni de déplacer ni de redimensionner les fenêtres. Cela change l'étiquette que vous utilisez pour les trouver.
Appliquez un test en deux questions
Demandez-vous si vous pouvez identifier le bon travail à partir du seul nom de l'application. Demandez-vous ensuite si un même résultat implique régulièrement plus d'une application. Si la première réponse est oui et la seconde non, restez sur une organisation par application. Si la première est non ou la seconde est oui, une couche de projet est utile.
Une approche hybride suffit souvent : conservez Commande-Tabulation pour le changement global d'application, puis utilisez un groupe de projets uniquement pour les quelques résultats actifs qui partagent des applications. Révisez le groupe lorsqu'un livrable change. Ne traitez pas le groupe comme une séparation de comptes, un contrôle d'accès ou une session enregistrée ; ce sont des responsabilités distinctes.