Conseils pour l'ancrage de fenêtres pour Mac

Question

Je viens d'un environnement de programmation Windows lorsque j'écris des outils, mais j'ai programmé avec Carbon et Cocoa depuis un an. Je me suis présenté à Mac par, je le reconnais, en se cachant de la programmation de l'interface utilisateur. J'ai essentiellement vidé mon code OpenGL dans une vue, puis je suis resté dans ma zone de confort en utilisant mon code OpenGL C++ agnostique comme d'habitude. Cependant, maintenant je veux commencer à porter l'une de mes applications plus sophistiquées sur Mac OS.

Typiquement, j'utilise l'approche standard MDI ancrable de Visual Studio, qui est excellente, mais très semblable à Windows. De l'utilisation d'un Mac principalement maintenant pour un moment, je n'ai pas tendance à voir ce genre de méthode utilisée pour les interfaces utilisateur Mac. Même Xcode ne supporte pas l'idée de drag and drop/dockable, malheureusement. Je vois des vues ancrées avec des panneaux séparateurs, mais c'est à peu près tout.

La chose la plus proche que j'ai vue de l'approche Visual Studio est Photoshop CS4, ce qui est plutôt sympa.

Alors, quel est le consensus général à ce sujet? Est-ce qu'il y a plus de façon de réaliser la même chose que celle que je n'ai pas vue? Si ce n'est pas le cas, je suis heureux d'écrire moi-même un gestionnaire de fenêtres dans Cocoa, afin que je puisse enfin découvrir ce qui ressemble à une excellente API.

Remarque, je ne souhaite pas utiliser QT ni aucune autre bibliothèque multiplateforme. Tout le problème est que je veux que l'application Mac ressemble à une application Mac, que l'application Windows ressemble à une application Windows. Je trouve toujours que les bibliothèques multi-plateformes tendent à perdre cet effet, et quand je vois une interface utilisateur native Mac, avec des transitions et des animations de Cocoa fantaisie, je souris toujours. C'est aussi une bonne excuse pour apprendre le cacao. Cela dit, s'il y a une bibliothèque Open Source Cocoa pour cela, j'aimerais bien le savoir! J'aimerais voir comment quelqu'un d'autre réalise cela, et aiderait à lisser la courbe d'apprentissage de Cocoa.

Cheers,

Shane

MISE À JOUR: J'ai oublié de mentionner un point critique. Je supporte les plugins, qui peuvent avoir leur propre interface utilisateur pour afficher diverses informations spécifiques au plugin. Je ne sais pas quels plugins seront chargés et je ne sais pas où leur interface va vivre, si je ne supporte pas l'amarrage. J'aimerais entendre les pensées des gens à ce sujet, en particulier: Comment puis-je soutenir une architecture de vue de plugin, si l'interface utilisateur ne peut pas changer? Où puis-je mettre les vues du plugin?

Answer 1

En venant d'un environnement Windows, vous ressentez le besoin d'avoir des fenêtres d'ancrage, mais est-ce vraiment essentiel pour l'application? La philosophie d'Apple (à mon avis) est que le concepteur sait mieux que l'utilisateur à quoi les choses devraient ressembler et fonctionner. Par exemple, iTunes est une application assez sophistiquée, mais elle ne vous permet pas de changer l'interface utilisateur, de changer la peau, etc., car Apple veut la garder cohérente. Ils offrent l'affichage complet, le mini-lecteur et une poignée d'options de visualisation différentes, mais ils ne vous permettent pas d'extraire la liste des sources dans une fenêtre séparée ou de l'ancrer dans d'autres positions. Ils pensent qu'il devrait être sur la gauche, donc là il reste ...

Vous avez dit que vous "voulez faire une application Mac ressembler à une application Mac", et comme vous l'avez souligné, les applications Mac ne tendent pas à avoir des fenêtres d'amarrage. Par conséquent, l'implémentation de vos propres fenêtres d'ancrage est probablement un pas dans la mauvaise direction;)

Answer 2

+1 à la réponse de Ken.Du point de vue de l'utilisateur, à moins qu'il ne fasse partie intégrante de l'application, comme dans Adobe CS ou Eclipse, je veux que tout soit aussi concis que possible et que toutes les options et affichages soient éliminés pour que je puisse me concentrer sur le document.

Je pense que vous trouverez chez les utilisateurs mac que ceux qui ont la "compétence utilisateur" pour utiliser des panneaux de réarrangement vont dans la plupart des cas opter pour des raccourcis clavier et ceux qui n'ont pas ce niveau de compétence juste aller à confondre.

Je recommanderais de le garder aussi simple que possible.

Answer 3

(courant au ralenti, tendant la main dans la panique) Nnnnnoooooooo !!!!! Sérieusement, comme je l'ai mentionné en réponse à l'excellente réponse de Ken, essayer de forcer un "Windowsism" sur une interface utilisateur d'OS X est certainement une mauvaise idée. À mon avis, le plus gros problème de l'interface utilisateur de Windows réside dans le fait que les développeurs tiers inventent de nouvelles façons incohérentes de présenter l'interface utilisateur plutôt que d'être cohérents et de respecter les conventions établies. Pour un utilisateur Mac, c'est le signe d'une application terrible. C'est comme ça pour une raison.

Je vous encourage à repenser votre UImise en œuvre de l'application à partir du sol avec le Mac OS à l'esprit. Si vous avez bien fait votre travail, l'architecture et le modèle (sans implémentation spécifique à la plate-forme) doivent clairement se traduire sur n'importe quelle plate-forme.

En termes d'interface utilisateur, vous utilisez un Mac depuis un an, vous devriez donc avoir une bonne idée de "la norme". Si vous avez des doutes, il est préférable de poster une question détaillant spécifiquement ce que vous devez présenter et vos pensées sur la façon dont vous pourriez le faire (ou demander comment si vous n'avez aucune idée). Ne bloquez pas votre application avec l'horrible stick en le forçant à se comporter comme s'il fonctionnait sous Windows alors que ce n'est clairement pas le cas. C'est le baiser de la mort pour une application pour les utilisateurs de Mac.

Answer 4

Une chose qui est commune parmi de nombreuses applications Mac est la possibilité de masquer tout le chrome et de se concentrer sur votre contenu. C'est le point derrière le contrôle de barre d'outils "tic tac" dans le coin supérieur droit de nombreuses fenêtres. Une faiblesse sérieuse de nombreuses interfaces utilisateur d'ancrage est qu'elles s'attendent à ce que la fenêtre occupe la plus grande partie de l'écran, car les panneaux ancrés peuvent masquer le contenu. Même si les panneaux ancrés sont rétractables, l'espace laissé par eux est souvent juste gaspillé et rempli d'espace blanc. Donc, si vous construisez un panneau d'accueil dans votre interface, vous devriez vous attendre à ce qu'il soit visible la plupart du temps. Par exemple, la liste des sources d'iTunes est clairement conçue pour être visible tout le temps, mais vous pouvez double-cliquer sur une playlist pour l'ouvrir dans une nouvelle fenêtre. Pour vous habituer à la gamme des contrôles Mac, je vous suggère de faire un travail sérieux avec certaines applications qui n'ont pas d'interface utilisateur multiplateforme; par exemple, les applications iWork, Interface Builder ou Preview. Prenez note de l'endroit où les contrôles apparaissent et dans les barres d'outils, dans les barres inférieures, dans les inspecteurs, dans les listes/barres latérales, dans les panneaux tels que Bibliothèque IB ou les panneaux Police et Couleur, dans les HUDs contextuels. Ne pas oublier la barre de menu non plus. Obtenez une idée de la sensation des contrôles: leur réactivité, leur modalité, leur taille, leur regroupement et leur cohérence. Essayez de développer du goût - tout n'est pas parfait; Essayez iCal si vous voulez vous amuser. Notez qu'il n'y a pas de «taille unique» pour les contrôles, ce qui peut poser un problème avec les interfaces utilisateur d'ancrage. Il est important de penser au flux de travail: comment le contrôle serait-il utilisé, si vous pouviez le remplacer par une manipulation directe, si une indication visible de son état est nécessaire, si le clavier et la souris peuvent fonctionner, etc. Découvrez comment le positionnement et le comportement du contrôle permettent à l'utilisateur de travailler plus efficacement.

En tant qu'exemple simple d'un placement et d'un comportement de contrôle bons ou mauvais dans des applications autrement décentes, comparez le masquage d'image dans OmniGraffle et Keynote. Dans OmniGraffle, ceci utilise l'inspecteur d'image où vous devez d'abord cliquer sur un bouton sans étiquette ("Taille naturelle") afin d'activer les contrôles appropriés, puis ajuster la taille et la position de manière basse fidélité avec une vignette d'image ou par en tapant des pourcentages dans des champs. Essayer de redimensionner le cadre se comporte directement d'une manière bizarre et contre-intuitive. Dans Keynote, le masquage commence par un élément de menu ou un élément de barre d'outils judicieusement nommé, utilise un HUD qui apparaît à l'instant où vous cliquez sur une image masquée et permet une manipulation directe, y compris un affichage sensible de l'étendue de l'image. re masquer. Pendant que vous faites glisser une image masquée, elle suit même les guides. Les utilisateurs avancés peuvent ignorer complètement le HUD, en double-cliquant simplement sur l'image pour basculer l'édition du masque et en utilisant les poignées pour le dimensionnement. Il devrait être facile à voir, avec quelques mises en garde (par exemple l'état du mode "Modifier le Masque" devrait être visible dans le HUD plutôt que seulement à partir de l'image, la bordure extérieure de l'image masquée devrait être utilisée plus efficacement) Keynote est nettement mieux à ce sujet, en partie parce qu'il n'utilise pas un inspecteur. Cela dit, si vous avez un grand nombre d'options et que la disposition de l'inspecteur à onglets standard ne fonctionne pas pour vous, consultez le framework OmniInspector d'Omni Group. Essayez de l'utiliser pour de bon, et j'espère que vous comprendrez comment obséder sur l'interface utilisateur autant que vous faites sur les graphiques maintenant :-)