Qu'est-il arrivé au modèle de fichier unifié d'Alan Cooper?

13

Depuis longtemps, Alan Cooper (dans les 3 versions de son livre "About Face") promeut un "modèle de fichier unifié" pour, entre autres, se passer de ce qu'il appelle la boîte de message la plus idiote jamais inventée - celle que apparaît lorsque vous appuyez sur le bouton de fermeture d'une application ou d'un formulaire indiquant "Voulez-vous annuler vos modifications?" J'aime l'idée et ses arguments, mais j'ai également la réaction instinctive que la plupart des programmeurs et des utilisateurs chevronnés ont contre elle.

Bien que le livre de Cooper semble assez populaire et respecté, je peux trouver remarquablement peu de discussions sur cette question particulière sur le Web. Petter Hesselberg, l'auteur de "Programming Industrial Strength Windows" le mentionne mais cela semble à ce sujet.

J'ai l'occasion de mettre cela en œuvre dans le projet (de bureau) sur lequel je travaille, mais je suis confronté à la résistance de clients et de collègues, qui sont bien sûr familiers avec la façon de faire MS Word et Excel. Je suis en mesure de passer outre leurs objections, mais je ne sais pas si je le dois.

Mes questions sont:

Y a-t-il de bonnes discussions à ce sujet que je n'ai pas pu trouver? Quelqu'un fait-il cela dans ses applications? Est-ce une bonne idée qu'il n'est malheureusement pas pratique de l'implémenter jusqu'à ce que, disons, Microsoft le fasse?

design programming-practices

— PAUL Mansour
source

2

Google Docs utilise le "modèle de fichier unifié". Il y a toujours un bouton de sauvegarde, mais en réalité c'est un placebo: chaque fois que vous effectuez une modification, le fichier est "sauvegardé". Bien sûr, Google Docs dispose également d'un modèle "historique" très robuste où vous pouvez revenir à n'importe quelle révision précédente que vous aimez.

— Dean Harding

Merci à tous pour les réponses. En particulier ElGringoGrande et Berin Loritsch. J'ai choisi Berin uniquement parce qu'il semblait un peu plus complet. Je réfléchis toujours à la direction à prendre.

— PAUL Mansour

5

La pertinence du système de fichiers unifié dépend vraiment de l'application en question. Des choses comme les applications Web, Microsoft OneNote et les applications iOS se prêtent à ce modèle. Lorsqu'une application est pilotée par une base de données, elle se prête également à ce modèle. Cependant, je peux aussi penser à des domaines où ce n'est pas la meilleure option. En particulier, lorsqu'une application peut consommer des données qui ne proviennent pas de cette application, vous avez besoin du concept d'un système de fichiers pour localiser les informations.

En ce qui concerne la synchronisation de la mémoire et du disque, je le veux, mais je ne le fais pas pour mon traitement de texte. Si j'ai pris le temps de sauvegarder mon fichier, je voudrais peut-être m'assurer que je ne perds aucune information. Ce besoin a été pris en charge par la fonction de sauvegarde automatique que nous avons depuis plusieurs années maintenant. Si quelqu'un trébuche sur le cordon d'alimentation, je peux au moins en récupérer une partie. Cependant, je crée un certain nombre de documents jetables dont je ne veux pas salir mon système de fichiers. Un signe qui ne sera utilisé que pendant une journée, jouant avec des échantillons de polices, etc.

La réponse est "cela dépend". L'UFS de Cooper est utile dans certains cas, et moins dans d'autres. Le savoir-faire technique de vos utilisateurs pourrait également jouer dans votre décision à ce sujet. La plupart d'entre nous ont grandi avec le statu quo, et parfois les avantages du changement ne l'emportent pas sur le coût du changement. J'évaluerais la pertinence de cette approche dans votre application.

— Berin Loritsch
source

7

Microsoft le fait dans OneNote.

Je ne passerais pas outre les désirs des utilisateurs. Nous avons pensé à l'implémenter, mais nous avons découvert que de nombreux utilisateurs font des choses sans réfléchir et utilisent le bouton Fermer le formulaire (ou ctrl-alt-del s'il n'y en a pas) pour éviter que leurs erreurs ne soient enregistrées.

Si vous pouviez l'implémenter d'une manière qui leur permette de revenir à une session précédente (une grosse défaite en quelque sorte), cela pourrait être acceptable. Mais les gens sont conçus pour profiter de l'environnement qui les entoure. Changez l'environnement et vous risquez de détruire l'avantage qu'ils ont découvert.

— ElGringoGrande
source

1

Et la fourniture d'annulations qui traversaient les lignes de session causerait ses propres problèmes. Combien de personnes commencent des lettres disant ce qu'elles pensent et finissent par le rendre diplomatique? Vous auriez besoin d'une fonction d'exportation distincte.

— David Thornley

+1, surtout pour le dernier paragraphe. N'écrasez pas le contenu précédent lors de l'enregistrement, mais ajoutez une nouvelle "version", en gardant les anciennes versions intactes. Pour économiser de l'espace, plusieurs versions peuvent partager des données (immuables).

— Joey Adams

1

@David: c'est un bon exemple de vouloir vraiment une commande "publier" plutôt qu'une commande "enregistrer une nouvelle version dans ce flux de version".

— Alex Feinman

1

@Alex: Précisément - sauf que la plupart des gens n'iront pas à la recherche d'une commande "publier" ou "exporter". Il n'y a pas de différence immédiatement visible, après tout, et ils sont habitués à simplement envoyer la version finale du fichier.

— David Thornley

Je suis d'accord que vous devez avoir une option "revenir à la version précédente" si l'on veut utiliser le modèle unifié - c'est fondamental pour cela. En fait, dans mon cas, toutes les données (ce sont des éléments spécifiques à l'application, pas vraiment des fichiers, mais c'est tout de même) sont dans un SGBD qui ne permet pas de mises à jour destructrices, j'ai donc chaque version jamais enregistrée. C'est l'une des raisons pour lesquelles j'envisage même le modèle unifié, car c'est un freebee pour rappeler les anciennes versions d'un article.

— PAUL Mansour

6

Le système de fichiers unifié a déjà gagné!

Toutes les applications iOS * fonctionnent de cette façon. Il n'y a pas de «fichiers», il n'y a pas de système de fichiers, il n'y a pas d'enregistrement, seulement des applications qui contiennent des données auxquelles vous pouvez toujours revenir à moins de les supprimer. Étant donné que MacOS pourrait tomber sur iOS un jour, je dirais que le modèle a définitivement fait son chemin.

Les sites Web fonctionnent également de cette façon: vous enregistrez rarement un document, vous parcourez rarement un ensemble de documents et vous partagez très rarement des documents entre des sites Web. Les documents sont intégrés dans le site, la façon dont ces questions et réponses sont intégrées dans StackExchange.

Historiquement, il y a eu quelques tentatives maladroites pour éviter cela dans Windows et Mac, et cela a repoussé les gens à l'idée. Mais le passage à une nouvelle plate-forme où personne ne s'attend à ce qu'il y ait un navigateur de fichiers a libéré les entreprises pour une transition complète.

(* Je ne sais pas d'Android ou d'autres systèmes d'exploitation de téléphone; peut-être aussi.)

— Alex Feinman
source

2

Des systèmes de fichiers existent cependant (en bonne partie) pour séparer les données et les interfaces des programmes et des applications. Il y a des arguments des deux côtés.

— Jé Queue du

2

@Alex, sauf que vous ne pouvez pas partager d'informations entre les applications. Un fichier de sauvegarde ne peut pas être ouvert par un éditeur de texte sur iOS, car cette autre application n'a pas accès au bac à sable.

— Stephen Furlani

@Stephen, c'est vrai, et un aspect essentiel de l'élimination d'un modèle mental basé sur des fichiers. Si vous souhaitez déplacer des données entre des applications, vous devez recourir soit au partage direct entre les applications ("partagez-le sur Facebook!"), Soit à un intermédiaire les deux peuvent parler (comme le presse-papiers). Je suis confus par votre "sauf".

— Alex Feinman

Vous pouvez partager des informations entre les applications - iOS prend en charge les gestionnaires de fichiers et transmet également des informations via des gestionnaires d'URL. Cela se fait uniquement à un niveau où les utilisateurs connectent les données entre les applications, sans être l'intermédiaire dans le processus de transfert.

— Kendall Helmstetter Gelner

1

@Alex, attendez, donc l'utilisation du presse-papiers (temporaire) est acceptable, mais l'utilisation d'un système de fichiers commun (permanent) ne l'est pas?

— Stephen Furlani

1

Allez-vous conserver leurs données dans des fichiers ou dans une sorte de base de données?

Si vous vous attendez à ce qu'ils aient un accès physique aux fichiers, vous devrez leur apprendre que vos fichiers sont «spéciaux». Dans leur modèle mental actuel, ils peuvent copier, coller, renommer et supprimer. Je suis sûr que certains d'entre eux utilisent déjà le renommage comme un moyen de «versionner» leurs données (par exemple resume2010.doc, SalesDataFromBob2.xls).

S'il s'agit d'une base de données, je suis sûr qu'ils voudront exporter / importer des fichiers à un moment donné.

— rperetti
source

0

L'option «enregistrer toujours» affichée en évidence pour l'utilisateur est-elle difficile à mettre en œuvre?

— JeffO
source

1

Non, ce n'est pas difficile à mettre en œuvre du tout. Mais est-ce vraiment une bonne idée de créer une option et de prendre en charge deux modèles ici? Je ne pense pas. Je pense que je préfère en choisir un et m'en tenir à lui.

— PAUL Mansour