Annuler l'historique - Pourquoi le limiter?
Pourquoi la plupart des applications ont-elles une fonctionnalité d'historique d'annulation assez limitée?
J'ai été rattrapé à plusieurs reprises (étant donné que c'est techniquement ma faute) où j'ai dû annuler un certain nombre de modifications (que ce soit dans Photoshop ou autre) pour être frappé par un bouton d'annulation grisé - aucun autre historique disponible . Je ne sais pas pour vous, mais perdre potentiellement beaucoup de travail à cause de cette limitation se traduit par une expérience utilisateur terrible.
Y a-t-il une raison pour laquelle les applications ne peuvent pas simplement contenir au moins un historique de session complète? Un fichier temporaire suffit-il pour stocker les modifications et ledit fichier temporaire pourrait être configuré selon les préférences de l'utilisateur (en termes de taille maximale, etc.)?
Faites-moi confiance quand je dis cela - annuler/rétablir est l'un des plus gros maux de tête de mise en œuvre, de test et de maintenance dans toute application de taille significative.
Certes, c'est une chose merveilleuse de pouvoir annuler/refaire quelque chose car cela détend l'utilisateur et lui permet de tester et d'explorer son environnement sans souci. Cependant, l'utilité d'un historique d'annulation commence à diminuer juste après la première annulation. Lentement, l'esprit - mais sûrement.
Bravo à ceux qui fournissent un historique d'annulation complet, mais c'est presque certainement le résultat d'une approche bien planifiée et bien exécutée avec un cadre de support travail, mis en œuvre dès le premier jour, et autour duquel tourne toutes les fonctionnalités.
Si ce cadre n'est pas introduit en premier, c'est un défi majeur de le verrouiller ensuite, et il est facile de s'enliser dedans.
Les problèmes résident dans:
- La complexité croissante des tests d'annulation/de rétablissement avec toute action possible dans toute séquence possible de changements de n'importe quelle taille .
- Veiller à ce que l'état du système après l'annulation de chaque étape soit le même qu'avant sa réalisation initiale, par ex. prêt pour la prochaine annulation ou la prochaine annulation
- Prise en compte correcte de ce qui est une action impossible
De plus, il est presque universel que si vous annulez une chaîne d'actions, puis effectuez un autre changement, vous ne pouvez pas refaire toutes les étapes que vous venez d'annuler, car le système a changé d'état et le rétablissement peut fort bien ne pas être valide.
Maintenant, une utilisation populaire de la longue histoire d'annulation/restauration est de revenir en arrière et de regarder quelque chose comme c'était, puis de continuer à avancer.
Je dirais que l'ennui de ne pas pouvoir annuler plus de 10 étapes n'est pas aussi ennuyeux que d'annuler 50 étapes, puis d'appuyer accidentellement sur un bouton du clavier qui jette l'historique de rétablissement afin que vous ne puissiez pas refaire tout ce qui vous fonctionne juste fait. Pour ma part, je suis très nerveux quand j'ai annulé quelque chose sur beaucoup d'étapes, et j'ai tendance à enregistrer d'abord comme solution de repli, et c'est peut-être là que réside la leçon: enregistrer souvent et enregistrer des versions.
Je suis tout à fait d'accord avec le fait qu'un historique complet d'annulation est hautement souhaitable - c'est juste pas simple, et c'est pourquoi il est supprimé de la liste des fonctionnalités lorsque les contraintes de temps et budgétaires sont en jeu.
Il existe des facteurs techniques et commerciaux pour ce problème.
Techniquement, annuler/refaire est très complexe à implémenter pour une application de toute complexité raisonnable. Non seulement il doit gérer la complexité de l'application, mais il nécessite un suivi de l'état dans le temps et la possibilité de réinitialiser cet état. Dans certains espaces d'application, notamment l'édition graphique, la véritable annulation n'est pas techniquement réalisable, vous pouvez uniquement prendre un instantané après chaque action et revenir à l'instantané précédent. Si vous insérez une lettre dans le bloc-notes, annuler peut relativement facilement supprimer cette lettre. Si j'applique une transformation mathématique sur une image graphique, je ne peux pas nécessairement rejouer le processus mathématique inverse et obtenir l'image d'origine. Le stockage d'un nombre illimité d'instantanés des données et de l'état deviendra limité en ressources.
D'un point de vue commercial, si je peux appliquer 100 jours-homme (par exemple) pour implémenter l'annulation illimitée, ou que je peux appliquer 100 jours-homme pour fournir 3 nouvelles fonctionnalités utilisateur demandées, je peux obtenir un meilleur retour sur mes 100 jours en implémentant le 3 nouvelles fonctionnalités. Cela peut être à courte vue, mais nous avons certainement déjà vu des décisions d'affaires à courte vue.
Le livre Design Patterns décrit comment implémenter la fonctionnalité annuler/rétablir (voir le Command Pattern ). C'est un design élégant, ce serait facile à tester, et avoir des annulations illimitées ne serait probablement pas un gros problème. Cependant, cela se fait au détriment de la conception de votre système entier autour du modèle et l'annulation/la restauration semble devenir extrêmement difficile pour les modèles de données complexes.
Cependant, le simple stockage de tous les états d'application pertinents, à chaque point de révision, serait facile à concevoir et à mettre en œuvre. Vous pouvez même l'ajouter à l'application à des stades de développement ultérieurs sans trop d'effort. Cependant, cette stratégie plus simple se fait au détriment de la mémoire, que vous géreriez probablement avec un nombre limité d'annulations/rétablissements. ... d'où la "fonctionnalité d'historique" d'annulation "limitée".
Je préfère le versioning comme par exemple Offres Google Docs. Vous pouvez basculer entre les différentes versions de votre document et revenir à l'une d'entre elles. À mon avis, c'est souvent une approche plus utile, bien qu'il ne soit pas raisonnable pour tous les types d'applications de conserver un historique complet des modifications.
Parce que votre RAM est limité :-)
PS - Je sais que vous disposez de 8 Go de RAM aujourd'hui, mais toujours si vous utilisez des applications comme Adobe Photoshop ou peut-être un logiciel 3D, qui économisent beaucoup d'informations si vous avez des changements importants, alors cela peut être un énorme porc de ressources.
Il est difficile de concevoir une annulation appropriée pour une application complexe après coup, et pour de nombreuses applications, il est simplement impossible de l'implémenter efficacement dans le temps (c'est-à-dire des délais raisonnables de l'interface utilisateur) ou dans l'espace (c'est-à-dire une utilisation excessive du stockage sur disque ou mémoire). Les éditeurs vidéo me viennent à l'esprit; mais pour de nombreuses applications, une grande partie ou la totalité du document en mémoire devrait être sauvegardée entre chaque modification, et cela coûte cher assez rapidement. La simple sauvegarde des modifications est souvent très difficile, car c'est une préoccupation transversale; chaque modification de l'état de l'application doit être classée selon qu'elle peut être annulée ou notée, et doit avoir un inverse (pour effectuer l'annulation).
J'en ai tellement marre du manque d'annulations appropriées pour l'édition de texte que j'ai écrit mon propre bloc-notes, qui enregistre en fait le journal complet des modifications avec le fichier texte sous-jacent. De cette façon, mon annulation/rétablissement persiste à travers les instances de l'application. Pour éviter tout le problème "Annuler 50 étapes, puis perdre accidentellement l'historique de rétablissement avec une nouvelle action", le journal d'annulation est strictement cumulatif - si vous commencez par foo, puis annulez et remplacez-le par une barre, il enregistre trois versions - foo, vide et la barre, pour ne jamais perdre de version.
Il n'y a aucune raison UX de limiter les annulations. La raison pour laquelle les annulations sont limitées est due à des limitations matérielles et logicielles (qui étaient plus importantes dans le passé qu'aujourd'hui).
Il n'y a absolument aucune bonne raison à part l'incompétence des développeurs. Un bon logiciel a généralement une implémentation solide annuler/refaire car il est construit sur des principes de conception qui séparent les actions des données et de leur présentation. Je l'ai fait moi-même et je ne suis pas d'accord avec la réponse de Roger - ce n'est certainement pas terriblement complexe à tester, du tout, si l'application est conçue dès le départ avec annuler à l'esprit.
En termes de convivialité non, vous ne devriez pas être limité, mais comme cela a été bien souligné, ce n'est pas facile. D'après mon expérience Notepad ++ a une excellente fonction d'annulation. Je soupçonne que cela fait partie du composant Scintilla sur lequel Notepad ++ est basé. Son tout open source afin que vous puissiez comprendre comment ils l'implémentent.
MS Word, OneNote et Outlook 2010 ont, sous certaines conditions, un historique d'annulation plus limité que la plupart des gens ne le pensent.
Essayez ceci: démarrez un nouveau document Word et tapez une ou deux lignes de texte, puis appuyez et maintenez la touche Retour arrière pour supprimer les derniers mots. Maintenant, appuyez sur Annuler ou Ctrl-Z ... pour récupérer ce texte en arrière-plan, vous constaterez que vous avez maintenant perdu non seulement cela, mais la plupart du texte que vous tapé!
La leçon ici est que l'annulation est difficile et que vous devez avoir une stratégie de test solide. Même les gros gars peuvent se tromper terriblement.