Bouton "Enregistrer | Sous" segmenté / divisé?

Question

Contexte:

J'ai une application qui a plusieurs options "Enregistrer sous" en plus de "Enregistrer".

Il s'agit d'une application Web sans barre de menus (juste une zone de boutons en haut de l'interface).

La demande:

Est-ce une bonne idée de combiner les fonctionnalités "Enregistrer" et "Enregistrer sous" dans un bouton divisé/un contrôle segmenté?

^{télécharger la source bmml - Wireframes créés avec Balsamiq Mockups}

Cela me semble assez logique, mais je n'ai jamais vu ce modèle dans la nature. Qu'est-ce que je rate?

Answer 1

Il y a une bonne raison pour laquelle cela est rare (je dirais inexistant):

Considère ceci:

^{télécharger la source bmml - Wireframes créés avec Balsamiq Mockups}

Que se passe-t-il lorsque vous appuyez sur 2? Obtenez-vous 2? Ou obtenez-vous 12?

La réponse évidente est que vous obtenez 2, car la disponibilité d'un bouton ou d'un élément de menu est un déclencheur d'action individuel .

Voici un autre exemple:

Que voyez-vous en premier? Deux iris ou deux yeux? Les iris appartiennent-ils au visage ou font-ils partie des yeux qui appartiennent au visage?

Les limites du bouton créent une séparation visuelle claire entre Save et As. Vous créez donc la séparation pour commencer, seulement pour demander aux gens de rejoindre les éléments séparés.

Ce que fait votre proposition, c'est forcez les gens à réfléchir et à comprendre le lien (pas immédiatement évident) entre As et Save .

Tenez compte des problèmes suivants:

• Les personnes qui utilisent beaucoup les calculatrices peuvent conclure que pour Save as ils doivent d'abord cliquer sur Save puis sur as.
• Pourquoi cliquer sur as est égal à save as mais en cliquant sur save c'est juste save?
• Si vous ajoutez plus de boutons à la barre d'outils, vous devez les garder à distance de ce bouton segmenté, afin que les gens ne voient pas le menu comme Save as close.

Le point important est que vous ne gagnez que la suppression du mot Save de Save as, mais vous introduisez un possible point de confusion (contrôle non conventionnel) et vous enlevez quelque chose auquel pratiquement tout le monde est habitué: a Save as... bouton.

Mon point est qu'il n'y a pratiquement aucun avantage mais pas mal de pénalités dans votre suggestion.

Answer 2

Le bouton partagé peut être une solution pour vous, seulement si vous l'implémentez correctement. Je vais essayer de clarifier l'idée:

Le but du bouton fractionné est d'ajouter des commandes secondaires qui sont logiquement regroupées sous une commande principale. Des exemples se trouvent facilement sur le ruban de bureau:

Utilisez le bouton divisé au cas où vous n’auriez pas beaucoup de place sur la barre d’outils et que de nombreux autres boutons l’encombrent. Une autre raison de préférer un bouton partagé est que les commandes secondaires ne sont pas souvent utilisées, ou seulement par les utilisateurs avancés. De cette façon, cela ne gêne pas la plupart des autres la plupart du temps.

L'étiquette du bouton serait le nom de la commande principale. À côté, il n'y a qu'une flèche qui ouvre un menu déroulant (n'utilisez pas l'étiquette secondaire "As"). Dans le menu déroulant, affichez les commandes secondaires, comme "Enregistrer sous", ou d'autres types d'enregistrement:

^{télécharger la source bmml - Wireframes créés avec Balsamiq Mockups}

J'ai tendance à être d'accord avec les réponses ci-dessus selon lesquelles le fait de placer un bouton "Comme" à côté de "Enregistrer" dérouterait les utilisateurs. Il s'écarte également de la convention. Si vous vous en tenez au modèle de conception couramment utilisé, il n'y a aucune raison pour que les utilisateurs le comprennent mal.

Voir aussi Microsoft's guidelines sur le sujet.

Answer 3

Je ne pense pas que le diviser en [Enregistrer | sous] soit une bonne idée. Je n'ai jamais vu un tel modèle, et je pense que c'est la même chose pour les utilisateurs. Donc, j'irais certainement le diviser en [Enregistrer] et [Enregistrer sous ...]. Je suggère définitivement celui-ci.

Une autre solution que vous pourriez trouver intéressante, cependant, consiste à fournir l'enregistrement automatique avec une forte confirmation comme dans Google Drive lorsque vous modifiez un document: "Toutes les modifications enregistrées dans Drive ". Mais dans ce cas, la sauvegarde automatique devrait se produire très souvent (comme quelques secondes après que l'utilisateur a fini de taper/modifier tout ce qui lui concerne). Ensuite, théoriquement, vous pourriez avoir un seul bouton disant [Enregistrer ...] qui ouvrirait une sauvegarde en tant que modal. Mais même dans ce cas, avoir un bouton [Enregistrer] pourrait rendre les utilisateurs moins confus, car ils deviendraient plus conscients du contrôle qu'ils ont sur le processus d'enregistrement.

Une autre idée consiste à fournir une liste déroulante, dans l'une des options:

• [Fichier] qui se développerait en Enregistrer, Enregistrer sous ..., Renommer etc.
• [Enregistrer ▼] qui enregistrerait en cliquant sur "Enregistrer" et développer jusqu'à Enregistrer et enregistrer sous en cliquant sur la flèche vers le bas. Ceci est similaire au modèle que vous avez proposé, mais au moins peut être reconnaissable.

Mais comme je l'ai dit, je suggère d'avoir deux boutons.

Answer 4

@Izhaki fait un travail fantastique pour expliquer les inconvénients. Si vous souhaitez toujours essayer (je pense qu'un test AB serait intéressant, même si j'ai du mal à formuler ce que vous pourriez mesurer comme objectif), je pense qu'un combo déroulant est le chemin à parcourir.

http://getbootstrap.com/components/#btn-dropdowns

Il élimine la possibilité pour quelqu'un de cliquer accidentellement sur le bouton "En tant que" et vous offre également la possibilité d'ajouter des opérations de type fichier supplémentaires, comme renommer ou copier.