Faut-il avertir l'utilisateur que les données seront perdues immédiatement ou lors de l'enregistrement?

Question

J'ai une interface pour gérer les champs de compte dans une application web comme ceci:

mockup

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

Le principe est simple: les champs sont de 2 types (public et privé). L'interface ci-dessus contient 3 listes, dont les champs à l'intérieur sont glisser-déposer. Donc, si je veux faire Field 3 public, je le fais simplement glisser dans la position appropriée dans le Public Fields liste. Si je veux supprimer Field 4, Je le fais glisser dans Deleted Fields.

Il existe 4 types de champs:

Champs par défaut qui ne peuvent pas être supprimés.
Champs par défaut qui ne peuvent pas être supprimés et rendus privés
Les champs créés précédemment et les données ont été saisies et enregistrées (contains data).
Champs qui viennent d'être ajoutés et ne contiennent aucune donnée (pas de texte descriptif dans l'interface).

Pour supprimer un champ, l'utilisateur peut simplement le faire glisser dans la liste des champs supprimés ou, s'il modifie le champ, il peut utiliser le bouton Supprimer:

mockup

^{télécharger la source bmml}

Rien n'est modifié jusqu'à ce que l'utilisateur appuie sur Save Fields. À ce stade, une demande est envoyée au serveur et si des champs supprimés contiennent des données, les données sont également supprimées. Si la demande aboutit, les éléments de Deleted Fields sont alors supprimés et ne sont plus récupérables.

Étant donné ce qui précède:

Je pense qu'il est important d'avertir l'utilisateur que les données seront perdues lorsque les champs contenant les données collectées seront supprimés. L'avertissement serait essentiellement un modal qui apparaît et se comporte comme un Confirmation dialogue. Si cela doit être fait immédiatement (un champ glissé vers des champs supprimés ou un bouton de suppression cliqué) ou si cela doit être fait lorsque l'utilisateur clique sur Save Fields?
Est-ce que le Contains datamicrocopie communiquer le fait que le champ stocke correctement les données précédentes? Je voudrais une phrase suffisamment concise mais qui communique toujours l'idée que le champ contains data correctement.

Itumac · Accepted Answer

Deux endroits sur lesquels vous pouvez vous améliorer.

1. Microcopie: Les commentaires d'Izhaki sont sur place. Je vais y ajouter. Je ne connais pas le public et le privé. Ils peuvent signifier différentes choses sur le Web. Qu'en est-il des champs visibles et masqués ou visibles, des champs masqués ou actifs et désactivés? Afficher dans le classement/Supprimer du classement. (remplacez Leaderboard par ce sur quoi vous montrez les champs :). Cela m'a pris une minute mais j'obtiens ce qui contient des données. Pensez significatif. Au lieu d'un contient des données, essayez "37 entrées" ou "37 entrées dans la base de données". Si vous devez rester concis, "En cours d'utilisation!"

2. Reconsidérez le glisser-déposer dans la section de suppression: Gardez le glisser-déposer pour ce qu'il est censé faire. Une partie de la confusion est que vous avez un poids et une interaction égaux appliqués au conteneur supprimé qui n'est pas le même type de conteneur que les conteneurs publics/privés.

Vous devez le différencier et envisager de supprimer le glisser-déposer. Conservez la suppression reléguée dans la fenêtre contextuelle.

Je soutiens cela: le glisser-déposer sert l'utilisateur car il peut rapidement organiser les champs du public au privé et les organiser dans une pile qui correspondra à l'affichage. La pile du conteneur de suppression n'est pas pertinente et le mouvement de glissement sur l'écran n'est pas très pratique. Je parie que vous pouvez cliquer sur un élément, obtenir la fenêtre contextuelle et cliquer sur supprimer plus rapidement que le glisser. Essayez-le cinq fois. Je parie que ckicl gagne. De plus, vous pouvez également gérer les champs non supprimables sans impoli. "VOUS POUVEZ SUPPRIMER CECI!" sur la traînée. Ou encore quelque chose de plus poli qui semble déplaçable, non pas parce que vous le savez, mais ce n'est pas le cas. Et encore un point. La suppression est-elle souvent effectuée? Si ce n'est pas le cas, n'affichez pas la liste. La liste ne doit apparaître que si quelqu'un a supprimé un champ. Vous avez maintenant une interface utilisateur plus simple.

mockup

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

Cependant, la liste de suppression IS importante. Elle vous permet de savoir ce qui est sur le point de tomber dans les toilettes. Peut-être laissez-les glisser vers l'arrière des éléments. intention mais la fonction de suppression est correctement différenciée par l'affichage.

mockup

^{télécharger la source bmml}

PUIS! Lors de la sauvegarde et uniquement lorsque les données vont être définitivement supprimées, vous proposez un message significatif. "Vous êtes sur le point de supprimer trois champs qui contiennent des données utilisateur. Voulez-vous vraiment le faire?

Énumérez les trois noms avec le nombre de données.

CRÉDIT SUPPLÉMENTAIRE: (puisque je ne développe pas cela) Énumérez les trois, permettez-leur d'être retournés à la liste cachée pour une suppression ultérieure. De cette façon, ils n'ont pas à revenir en arrière.

Facile. J'espère que cela pourra aider.

Izhaki · Answer

J'ai quelques commentaires sur vos idées:

"Enregistrer les champs" n'est pas un nom génial, je pense que "Enregistrer les modifications" ou "Valider les modifications" est préférable. Si l'utilisateur fait glisser un champ vers le bac supprimé, "enregistrer les champs" n'a pas beaucoup de sens (enregistrez-vous les champs qui doivent être supprimés - eah?).
Le bac "Supprimé" n'affiche aucunement les champs supprimés. Si quoi que ce soit, il affiche les champs `` À supprimer '', ou d'une manière plus élégante, je l'appellerais simplement `` Corbeille '' - je pense que les gens n'auront aucun problème à comprendre ce qui se passe lorsque vous faites glisser quelque chose là-bas.
Sur la même note, le bouton "supprimer" ne supprime pas vraiment le champ - il le marque uniquement pour la suppression. Alors peut-être que "passer à la poubelle" est un bien meilleur nom.
Les utilisateurs vous détesteront si vous leur demandez à chaque fois qu'ils glissent quelque chose dans la corbeille s'ils en sont sûrs. Imaginez simplement comment vous sentiriez-vous si après avoir sélectionné plusieurs fichiers dans votre système d'exploitation puis appuyé sur Supprimer, le système d'exploitation vous demandait 'êtes-vous sûr?' par fichier. (Vous pouvez aussi m'imaginer devant votre système; je veux supprimer 3 champs; je fais donc glisser le premier; j'obtiens le message d'avertissement; je le lis; l'obtient; confirmez; faites glisser le deuxième champ; maintenant je reçois le message encore une fois, mais je le sais déjà; donc je suis un peu ennuyé; puis je traîne le troisième champ; maintenant je vous déteste vraiment.) Ce que vous essayez d'empêcher, c'est que les gens ignorent les conséquences de leurs actions. Les sensibiliser une fois est suffisant, pas besoin de le faire par glisser.
Si je suis parfaitement honnête, je ne sais pas vraiment ce que "contient des données" signifie. Cela signifie-t-il que celui qui a créé le champ a entré plus de données que l'on ne peut plus voir? Serait-il préférable de désigner les champs "inutilisés" plutôt que ceux qui contiennent des données?