Simplifiez une interface pour appliquer de manière flexible des règles à des périodes de temps
Nous avons un module dans une application où les utilisateurs définissent des périodes de temps pour différents critères qui seront utilisés plus tard pour filtrer certaines listes.
Par défaut, chaque critère s'applique à tout moment. Sa validité peut être limitée à la fois en restreignant les périodes où elle s'applique et en ajoutant des périodes d'exclusion. Les périodes d'application et d'exclusion déjà définies peuvent être modifiées ou supprimées.
L'interface actuelle est la suivante:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Les utilisateurs ont du mal à comprendre la logique des périodes "application" vs "exclusion", ce que je comprends parfaitement. Je ne trouve pas de solution pour simplifier l'interface tout en conservant toutes les possibilités existantes.
Que peut-on faire pour améliorer l'expérience utilisateur ici?
Essayez de les montrer visuellement, car ils établissent les délais de restriction et d'exemption. Avec chaque critère ajouté, la chronologie est mise à jour.
Je ne suis pas sûr de bien comprendre votre cas d'utilisation, mais il semble que les utilisateurs doivent voir clairement les résultats de leurs restrictions et exceptions. Je me concentre un peu sur la façon de voir le résultat comme rétroaction.
Les obliger à lire et à calculer les dates (et les allocations proportionnelles) semble alourdir leur charge de travail. Ils pourraient également devoir examiner des périodes pour chaque critère également.
Pourriez-vous avoir une visualisation qui aide à les montrer lorsqu'ils ajoutent des critères?
Un exemple de carte thermique:
Github est un exemple de présentation de données d'une année. En un coup d'œil, vous pouvez voir les périodes d'activité.
Ne les faites pas lire; fournir des visuels en tandem.
S'il y a un autre état (je ne suis pas trop clair à ce sujet): celui de temps illimité et non déclaré, le heatmap peut également montrer ces lacunes.
J'espère que je ne comprends pas mal vos besoins, mais ma recommandation est de supprimer les périodes d'exception/d'exclusion, car elles rétablissent simplement le défaut (le critère * s'applique) dans une période de "restriction" (le critère ne s'applique pas). Intuitivement, il pourrait sembler plus simple de dire (comme dans votre 3ème exemple) "Le critère devrait s'appliquer toute l'année, sauf pour les vacances d'été", mais vous avez besoin de deux lignes pour le dire, et vous pourriez aussi bien dire (dans le même espace, sans la gymnastique mentale): Applies from 2019-01-01 to 2019-07-13 Applies from 2019-08-16 to 2019-12-31
Pour permettre l'insertion d'une exception plus facilement, je recommanderais un bouton split (ou un nom similaire) (en plus de edit et delete), qui doublerait la ligne actuelle et préremplissez le début de la première et la fin de la deuxième ligne avec le début et la fin de la ligne d'origine. Un calendrier à code couleur pour aider à visualiser cela (comme suggéré dans d'autres réponses) serait certainement utile mais n'est pas strictement requis.
Soit dit en passant, votre critère d'exemple 1 est simplement l'équivalent de Applies from -infinity to infinity.
*) "Critères" est le pluriel de " critère " (un standard ou un trait) ou de "critère" ( une course de vélo).
Chevauchement des règles
Je m'excuse si j'ai mal compris la [~ # ~] demande [~ # ~] , mais je pense que c'est un cas classique de [ ~ # ~] et [~ # ~] & [~ # ~] ou [~ # ~] opérations (type de: P).
- Les utilisateurs ajoutent une règle (définir la période de temps), c'est-à-dire l'application
- Les utilisateurs peuvent ajouter une autre règle en plus de la règle ci-dessus, à savoir l'exception, qui peut ou non se chevaucher avec la période de temps définie.
Étant donné que l'application et l'exception sont étroitement liées à la carte mentale lors de la création, au lieu de leur donner des hiérarchies distinctes, je pense qu'elles devraient avoir une relation parent/enfant.
Ma proposition
J'adore la façon dont Zapier visualise les opérations AND/OR. 
Dans la conception ci-dessus, votre interface peut ressembler à 
Au lieu de placer des boutons d'action en bas, placez des boutons "Ajouter" dans chaque section.
Applies:
From 2019-01-01 to 2019-12-31 edit delete
+ Add
Except:
From 2019-07-14 to 2019-08-15 edit delete
+ Add
Habituellement, la simplification de la langue de copie aide (quelque chose comme "ajouter une plage de temps valide" & "bloquer des dates spécifiques".
Une deuxième option serait d'ajouter des couleurs telles que le vert (pour les heures restreintes) et le rouge (pour les heures d'exception), en suivant la logique:
Vert => allez, Rouge => arrêtez
Une troisième option consiste à ajouter une icône (+ pour ajouter, - pour restreindre).
Mieux si vous faites les trois ensemble, cela vous assure de couvrir plus de logiques d'utilisateurs (c'est-à-dire orientés graphiques vs lecteurs) Essayez de penser à l'utilisateur comme si vous parliez à un enfant;) cela m'aide toujours!
Le problème est que vous présentez les règles, mais pas le résultat.
Comme test décisif, essayez de répondre à la question: le critère est-il appliqué le 23 mars?
Au lieu de:
Applies from 2019-01-01 to 2019-12-31
Except from 2019-07-14 to 2019-08-15
L'affichage suivant est plus facile à raisonner ... surtout lorsque les exceptions s'accumulent:
Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31
Il pourrait également être utile de rendre cela plus visuel. Les calendriers seraient très utiles; en particulier en cliquant pour activer/désactiver et MAJ + clic ou CTRL + clic pour sélectionner/désélectionner en masse.
Si l'espace est limité, même avec du texte, vous pouvez ajouter des informations supplémentaires pour aider l'utilisateur:
Applies from 2019-01-01 to 2019-07-13 (x days)
-- y days later --
Applies from 2019-08-16 to 2019-12-31 (z days)
Cette vérification de l'ordre de grandeur peut aider l'utilisateur à identifier les fautes de frappe.