Il semble exister une certaine ambiguïté lorsqu'une vue multi-éléments basée sur une table doit combiner la navigation ("Fermer"/"Retour"), le changement de mode d'édition ("Modifier") et l'agrégation ("+"/"Ajouter") dans une seule barre de navigation.
Apple semble éviter le problème en insérant une ligne dédiée "Ajouter" dans une vue de tableau et en plaçant le bouton "Modifier" soit sur le côté gauche d'une barre de navigation (dans le cas d'une vue racine) soit sur le côté droit (?) d'une barre de navigation (dans le cas d'une vue empilée).
Je n'aime pas l'idée d'une ligne liée aux fonctionnalités dans une vue de tableau que les utilisateurs doivent rechercher partout dans le tableau entier et le bouton "Modifier" change de position dans une barre de navigation.
La solution que j'envisage est plus d'un bouton dans une barre de navigation, soit: 1.) sur le côté gauche, ["Retour" | "Modifier" ---- TITRE --- "+"], ou 2.) sur le côté droit, ["Retour" ---- TITRE --- "Modifier" | "+"].
Contexte: une vue de table avec une fonction de bascule en mode édition (analogue, par exemple, à iOS 7 Clock >> Alarm -s). En mode sans modification, un tapotement sur une ligne signifie une sélection, un "zoom avant" sur cette ligne, comme suggéré par un indicateur de divulgation (un accessoire de ligne). En mode édition, un tap de ligne effectue une modification de ligne, une ligne "-" supprime la ligne.
Pensées?
Voteriez-vous pour (1.) ou (2.)?
C'est un peu délicat sans le contexte - un croquis aiderait, mais en général je ne recommanderais pas d'avoir trois boutons dans la barre de navigation. En partie parce que cela peut prendre trop de place, selon la façon dont vous prévoyez de concevoir les boutons et en partie parce que cela "semblerait" incohérent selon les directives de l'interface utilisateur.
Si je devais choisir entre vos options, j'irais avec le numéro 2. Le coin supérieur droit est généralement réservé aux actions relatives à la vue actuelle. Le coin supérieur gauche est réservé à la navigation.
Je sais que c'est une étape supplémentaire, mais je pourrais envisager de créer un seul bouton dans le coin supérieur droit qui déclenche une fenêtre contextuelle avec la possibilité de modifier ou de créer un nouveau.
De plus, je me demande si vous pourriez peut-être réserver le coin supérieur droit pour ajouter de nouveaux éléments, puis peut-être intégrer la modification dans les lignes du tableau à la place? Que signifie modifier? Avez-vous la possibilité de modifier l'intégralité du tableau ou juste une seule ligne? Vous connaissez le modèle où vous pouvez sélectionner une ligne en appuyant n'importe où et l'inspecter en appuyant sur une icône sur le côté droit? Sinon, voir l'onglet du réseau Wi-Fi sur iOS. Ce n'est pas mon modèle préféré, mais cela pourrait vous aider ici.
Une approche entièrement différente pourrait être de regarder à la place à l'aide de gestes. Les gestes ont tendance à avoir le problème que les gens oublient de fournir suffisamment d'indices visuels pour créer une possibilité pour le geste. Alors faites attention à ça.
Après beaucoup de recherches sur l'âme et de nombreuses captures d'écran, je dois convenir avec funkylaundry que plus d'un seul bouton du même côté d'une barre de navigation ne semble pas standard dans une application iOS.
J'ai donc décidé de m'en tenir à l'idée d'Apple d'une ligne "Ajouter ..." liée aux fonctionnalités dans une vue de table, dans une section "+" distincte en bas (qui semble être la plus courante). L'emplacement le plus bas peut nécessiter un défilement plus qu'un écran pour même remarquer la ligne "Ajouter ...", de sorte que le problème UX de mauvaise facilité de découverte reste non résolu. Le problème secondaire d'avoir à "rechercher" à travers une vue de table entière pour la ligne "Ajouter ..." peut être atténué en utilisant une "barre d'index" à l'extrême droite avec un bouton de déclenchement "+" en bas, permettant pour un défilement simple vers le bas.
Une autre solution consisterait à placer la ligne "Ajouter ..." en haut d'une vue de tableau (suivie de sections et de lignes spécifiques aux données). L'emplacement le plus haut peut servir d'indice immédiat quant aux fonctionnalités disponibles via un mode d'édition de vue de table, donnant la priorité à la facilité de découverte UX. Cependant, l'inconvénient est le fait qu'une vue sous forme de tableau représentant une liste d'éléments semble quelque peu "artificielle" avec la ligne "Ajouter ..." au début de celle-ci. (Je pourrais être en train de passer à cette approche à l'avenir, de toute façon.)
Une solution entièrement différente serait un bouton graphique "+" (au lieu de la ligne "Ajouter ...") au-dessus d'une vue de table qui ne défile pas avec la vue elle-même. Cependant, un tel bouton "flottant" peut masquer le contenu de la ligne ou les boutons de suppression/déplacement de ligne, ce qui peut s'avérer lourd.
Sur une note philosophique, le basculement d'un mode d'édition de vue de table ne semble PAS être une application spécifique commande qui devrait nécessiter un bouton "Modifier" défini par l'utilisateur n'importe où, mais plutôt un changement d'un propriété innée d'une vue de table. Les directives d'interface humaine iOS (HIG) devraient peut-être reconnaître cette distinction, par le biais, par exemple, d'un bouton à bascule dédié intégré quelque part dans une vue de table elle-même, ou en décrivant et en autorisant le cas d'utilisation spécifique de plusieurs boutons du même côté d'un barre de navigation (boutons "Edition" et "+" à droite).