Bases de l'apprentissage de la 4e dimension
Le menu Fichier est sans doute le menu le plus important de toute application de base de données et, pour cette raison, il occupe presque toujours la première position dans la barre de menus. C’est le point d’ancrage vers lequel les utilisateurs reviennent pour les opérations les plus fondamentales : imprimer un enregistrement, exporter un ensemble trouvé et quitter l’application. Lorsque vous concevez un ensemble de menus personnalisés dans 4D, le menu Fichier est l’endroit où vous donnez le ton à l’ensemble de l’interface : s’agit-il d’une application métier soignée et spécialement conçue, ou d’une fine enveloppe autour de l’environnement de développement ?
Cet article compare le menu Fichier dans trois environnements : le menu Mode Navigation de FileMaker Pro (FMP), le menu 4D Foundation (par défaut) et un menu personnalisé 4D. Le but n’est pas de copier un menu en gros dans un autre, mais de comprendre pourquoi chaque élément existe afin que vous puissiez décider de ce qui doit être présenté à vos utilisateurs.
Points clés à retenir
- Le menu Fichier est le menu le plus important et se trouve conventionnellement en premier dans la barre de menus.
- Quatre éléments apparaissent dans les trois menus Fichier — Importer, Exporter, Imprimer et Quitter — car chaque utilisateur en a besoin.
- Le menu Fichier par défaut de 4D Foundation ne dispose pas d’une option Mise en page, ce qui constitue une véritable lacune d’utilisabilité.
- Les éléments orientés développement (Définir les champs, Définir les listes de valeurs, Privilèges d’accès, etc.) ne doivent jamais apparaître dans un menu personnalisé destiné à l’utilisateur.
- Ouvrir la base de données et Ouvrir la table sont largement redondants dans un environnement de menu personnalisé 4D, puisque 4D ouvre une seule base de données à la fois.
- Fichier journal / Aucun fichier journal est une question de maintenance et de sauvegarde et appartient à un menu administrateur ou spécifique au programme, et non au menu Fichier de l’utilisateur.
Pourquoi le menu Fichier mérite une conception soignée
Une barre de menus est un contrat avec l’utilisateur. Lorsqu’un utilisateur clique sur Fichier, il s’attend à un ensemble prévisible d’opérations qui agissent sur le document ou l’ensemble de données dans son ensemble — pas sur un seul champ, ni sur la mise en page, ni sur le schéma de la base de données.
Cette convention est ancienne et durable ; elle descend des directives originales d’Apple Human Interface et se retrouve aujourd’hui dans les structures de menus de la plupart des applications de bureau. La violer (par exemple, masquer Imprimer sous un menu personnalisé ou placer des commandes d’édition de schéma dans Fichier) oblige les utilisateurs à rechercher des fonctions de base et érode la confiance dans l’application.
Dans 4D, les menus sont définis comme des objets de barre de menus et des éléments de menu, et ils peuvent être attachés à des formulaires et contrôlés dynamiquement via du code. Cette flexibilité est exactement la raison pour laquelle la discipline est importante : parce que vous pouvez mettre n’importe quoi n’importe où, vous avez besoin d’une justification pour savoir ce qui va où. Le menu Fichier est le meilleur endroit pour instaurer cette discipline.
Les trois menus en comparaison
La comparaison ci-dessous reflète les trois environnements abordés dans cette série. Notez que le Menu personnalisé par défaut de 4D n’est pas affiché dans la figure d’origine car son seul élément de menu est Quitter — un rappel utile qu’un ensemble de menus “personnalisé” n’est aussi bon que les éléments que vous y ajoutez réellement.
Connexes : — Une interface simple sous forme de feuille de calcul reposant sur une véritable base de données relationnelle, avec des automatisations, des vues et des interfaces partageables..
| Élément de menu | Mode Navigation FMP | 4D Foundation (par défaut) | Menu personnalisé 4D |
|---|---|---|---|
| Nouvelle base de données | Oui | — | — |
| Fermer | Oui | — | — |
| Définir les champs | Oui | — | — |
| Définir les listes de valeurs | Oui | — | — |
| Privilèges d’accès | Oui | — | — |
| Partage | Oui | — | — |
| Enregistrer une copie sous | Oui | — | — |
| Récupérer | Oui | — | — |
| Importer des enregistrements/données | Oui | Oui | Oui |
| Exporter des enregistrements/données | Oui | Oui | Oui |
| Imprimer | Oui | Oui | Oui |
| Mise en page | Oui | — | Recommandé |
| Quitter | Oui | Oui | Oui |
| Ouvrir (Base de données) | Oui | — | — |
| Ouvrir la table | — | Oui | Facultatif |
| Préférences | — | Oui | — |
| Administration | — | Oui | — |
| Fichier journal / Aucun fichier journal | — | Oui | — |
Le modèle est clair : le menu du mode Navigation de FMP regorge de commandes de schéma et de gestion de fichiers, car FileMaker exposait historiquement les outils de conception via la même barre de menus. Le menu de 4D Foundation est plus sobre mais omet la Mise en page. Un menu personnalisé 4D bien construit se situe entre les deux : il conserve les quatre éléments universels, restaure la Mise en page et exclut délibérément tout ce qui appartient au développeur ou à l’administrateur.
Éléments qui ne devraient pas apparaître dans un menu utilisateur
Plusieurs éléments du mode Navigation FMP sont exclus de cette comparaison car ils permettent à l’utilisateur d’apporter des modifications de conception ou d’exécuter des fonctions qui n’ont pas leur place dans un environnement de menu personnalisé 4D. Ce sont :
- Nouvelle base de données — la création d’une nouvelle base de données est une action du développeur/administrateur, et non une action de l’utilisateur final.
- Fermer — dans 4D, fermer la base de données signifie généralement quitter l’application ; un bouton Fermer distinct prête à confusion.
- Définir les champs — édition du schéma. Ne l’exposez jamais aux utilisateurs finaux.
- Définir des listes de valeurs — la maintenance des listes de valeurs est une tâche de conception.
- Privilèges d’accès — la configuration de la sécurité appartient à l’administrateur.
- Partage — la configuration du réseau/partage est une préoccupation administrative.
- Enregistrer une copie sous — la duplication au niveau du fichier est une opération de maintenance.
- Récupération — la récupération de base de données est un outil de réparation, pas une fonctionnalité utilisateur.
Le principe sous-jacent : tout ce qui modifie la structure de la base de données, sa sécurité ou ses fichiers sur le disque est une fonction d’administrateur. Un menu Fichier accessible à l’utilisateur ne doit contenir que des opérations qui agissent sur les données avec lesquelles l’utilisateur travaille légitimement.
Si vous faites du shopping : — Un créateur d'applications low-code qui se connecte à la suite Zoho plus large et propose des tarifs par utilisateur plutôt que par application..
Les quatre éléments universels — et pourquoi ils sont importants
Il existe quatre éléments de menu communs aux trois menus Fichier : Importer, Exporter, Imprimer et Quitter. Ce n’est pas une coïncidence. Ces quatre éléments représentent le cycle de vie complet : importer des données, exporter des données, produire un artefact physique ou PDF et mettre fin à la session. Toute application qui en omet un frustrera les utilisateurs.
- Importer (Enregistrements/Données) — permet aux utilisateurs d’importer des données externes (CSV, délimitées par des tabulations ou l’exportation d’une autre base de données) dans une table. Dans 4D, cela correspond naturellement aux commandes d’importation que vous pouvez déclencher à partir d’un élément de menu.
- Exporter (Enregistrements/Données) — la contrepartie. Les utilisateurs doivent souvent transmettre des données à une feuille de calcul ou à un autre système.
- Imprimer — produire un enregistrement, une liste ou un rapport. Il s’agit souvent de la commande Fichier la plus utilisée dans une application professionnelle.
- Quitter — terminer la session proprement, idéalement avec une confirmation et toute logique de sauvegarde/nettoyage nécessaire.
Parce que ces quatre éléments sont si fondamentaux, ils doivent être présents, correctement étiquetés et reliés à un comportement par défaut raisonnable dans chaque ensemble de menus personnalisés que vous livrez.
L’écart de mise en page
Une chose qui manque vraiment dans le menu Fichier par défaut de 4D Foundation est la Mise en page. Il s’agit d’un véritable problème d’utilisabilité, et non d’un problème esthétique. Si un utilisateur ne peut pas choisir la mise en page, l’application réutilise silencieusement la dernière mise en page sélectionnée — laquelle peut correspondre au mauvais format de papier, à une mauvaise orientation ou à des marges incorrectes pour le rapport qu’il est sur le point d’imprimer.
La solution pratique est simple : ajoutez un élément de menu Mise en page à votre menu Fichier personnalisé et reliez-le à la boîte de dialogue de mise en page de la plateforme. Le placer directement au-dessus de Imprimer reflète la convention que les utilisateurs connaissent déjà dans d’autres applications et leur donne la possibilité de corriger la mise en page avant de lancer l’impression. Pour les rapports qui doivent toujours être imprimés d’une manière spécifique, vous pouvez toujours définir la mise en page par programme au moment de l’impression — mais laisser à l’utilisateur une possibilité de modification manuelle est presque toujours le choix le plus judicieux.
Ouvrir la base de données, Ouvrir la table et la réalité d’une base de données unique
Le menu Ouvrir de FMP et le menu User Open Database de 4D ne sont normalement pas nécessaires dans un environnement de menus utilisateur/personnalisés. Le raisonnement est simple : au moment où l’utilisateur consulte vos menus, il a déjà ouvert la base de données. De plus, dans 4D, vous ne pouvez ouvrir qu’une seule base de données à la fois, donc une commande « Ouvrir la base de données » n’a pas de cible significative — il n’y a rien d’autre vers quoi basculer.
L’élément Open Table dans le menu par défaut de Foundation est un cas différent. Cela peut être utile, mais cela ne devrait probablement pas figurer dans le menu Fichier.
La plupart des applications bien conçues offrent aux utilisateurs un autre moyen de naviguer entre les tables — un menu de navigation dédié, une barre d’outils ou des boutons sur un formulaire d’accueil. Garder la navigation entre les tables en dehors de Fichier préserve la signification du menu Fichier (opérations au niveau du document) et maintient la navigation là où les utilisateurs l’attendent.
Si vous décidez d’exposer le changement de table, envisagez plutôt un menu Aller à ou Naviguer, et remplissez-le dynamiquement à partir de la structure de vos tables afin qu’il reste synchronisé à mesure que le schéma évolue.
Préférences, Administration et Fichier journal
Les éléments Préférences et Administration du menu Foundation ne sont, comme le notent les notes originales, pas vraiment destinés à l’utilisateur — ils sont destinés à un administrateur. Les préférences peuvent inclure des paramètres qui affectent l’ensemble de l’installation ; l’Administration peut exposer la gestion des utilisateurs, les sauvegardes ou des tâches de maintenance. Les exposer aux utilisateurs ordinaires invite à des erreurs de configuration accidentelles.
Le menu utilisateur Log File / No Log File mérite une mention particulière. Il est utilisé pour la maintenance et la sauvegarde de la base de données — en activant ou désactivant l’écriture par 4D d’un journal des modifications de données.
Il s’agit d’un paramètre opérationnel sérieux : le fichier journal est ce qui permet à une base de données d’être restaurée dans un état cohérent après un arrêt inattendu, et il interagit avec votre stratégie de sauvegarde. L’activer ou le désactiver avec désinvolture depuis un menu utilisateur est risqué.
La meilleure conception consiste à déplacer le contrôle du fichier journal dans un menu spécifique au programme (ou un menu réservé à l’administrateur) qui est soit masqué aux utilisateurs réguliers, soit protégé par des privilèges d’accès. Si votre application a réellement besoin que les utilisateurs déclenchent une sauvegarde, exposez une seule commande Sauvegarde clairement étiquetée qui exécute une routine contrôlée — et non une simple bascule du mécanisme de journalisation.
Comment décider de ce qui figure dans votre menu Fichier
Utilisez ces critères lorsque vous créez ou révisez un menu Fichier personnalisé :
- Agit-il sur l’ensemble du document/jeu de données ? Si oui, le menu Fichier est un candidat. S’il agit sur un champ, un enregistrement ou une mise en page, il appartient ailleurs.
- S’agit-il d’une opération de données ou d’une opération de schéma/sécurité/fichier ? Les opérations de données peuvent être destinées à l’utilisateur ; les opérations de schéma, de sécurité et de fichier sont administratives.
- L’utilisateur en a-t-il besoin pendant son travail normal ? Importer, Exporter, Imprimer, Mise en page et Quitter passent ce test. Définir les champs ne le passe pas.
- Est-ce redondant étant donné le modèle de base de données unique de 4D ? Open Database échoue à ce test.
- Est-ce dangereux en cas de mauvaise utilisation ? Le basculement du fichier journal échoue à ce test et doit être placé derrière un accès administrateur.
- Existe-t-il un emplacement plus naturel ? La navigation dans les tables appartient à un menu de navigation ; la maintenance appartient à un menu d’administration.
L’application cohérente de ces six questions produira un menu Fichier court, prévisible et fiable — ce qui est exactement ce que devrait être le menu le plus important de la barre.
Questions fréquemment posées
Pourquoi le menu Fichier est-il toujours placé en premier dans la barre de menus ?
Par convention. Dans pratiquement toutes les applications de bureau, le menu le plus à gauche est réservé aux opérations au niveau du document et de l’application, et les utilisateurs ont des décennies de mémoire musculaire les poussant à s’attendre à ce qu’Imprimer et Quitter s’y trouvent. Placer Fichier en premier réduit la charge cognitive liée à l’apprentissage de votre application et assure la cohérence avec les directives de la plateforme.
Quels sont les quatre éléments qui apparaissent dans les trois menus Fichier comparés ici ?
Importer, Exporter, Imprimer et Quitter. Ces quatre éléments couvrent le cycle de vie essentiel : importer des données, exporter des données, produire un artefact imprimé et terminer la session, c’est pourquoi ils subsistent dans chaque conception de menu, quel que soit l’environnement.
Pourquoi la Mise en page est-elle absente du menu Fichier par défaut de 4D Foundation, et dois-je l’ajouter ?
Le menu Foundation ne l’inclut tout simplement pas, ce qui signifie que l’application réutilise la dernière mise en page choisie — potentiellement avec une taille, une orientation ou des marges incorrectes. Vous devriez ajouter un élément Mise en page à votre menu Fichier personnalisé, idéalement juste au-dessus d’Imprimer, afin que les utilisateurs puissent corriger la mise en page avant l’impression.
Pourquoi Open Database ne devrait-il pas apparaître dans un menu personnalisé 4D ?
Parce que 4D ne peut ouvrir qu’une seule base de données à la fois, et que l’utilisateur a déjà ouvert la base de données pour accéder à vos menus. Une commande Open Database n’a pas de cible significative, elle est donc redondante dans un menu personnalisé destiné à l’utilisateur.
Où placer Log File / No Log File au lieu du menu Fichier utilisateur ?
Cela doit être déplacé vers un menu spécifique au programme ou réservé à l’administrateur, car cela contrôle la journalisation utilisée pour la maintenance et la sauvegarde et interagit avec la récupération. Exposer une bascule de journalisation brute aux utilisateurs ordinaires risque de compromettre la capacité de récupération ; si les utilisateurs ont besoin de sauvegardes, donnez-leur plutôt une seule commande de Sauvegarde contrôlée.
Open Table doit-il rester dans le menu Fichier ?
Généralement non. La navigation dans les tables est mieux gérée par un menu de navigation dédié, une barre d’outils ou des boutons sur un formulaire d’accueil, ce qui permet au menu Fichier de rester concentré sur les opérations au niveau du document et place la navigation là où les utilisateurs s’attendent à la trouver.
Questions fréquentes
Pourquoi le menu Fichier est-il toujours placé en premier dans la barre de menus ?
Convention. Dans pratiquement toutes les applications de bureau, le menu le plus à gauche est réservé aux opérations au niveau des documents et des applications, et les utilisateurs disposent de décennies de mémoire musculaire en s'attendant à ce que Imprimer et Quitter soient là. Placer le fichier en premier réduit la charge cognitive liée à l'apprentissage de votre application et la maintient cohérente avec les propres directives de la plateforme.
Quels sont les quatre éléments qui apparaissent dans les trois menus Fichier comparés ici ?
Importer, exporter, imprimer et quitter. Ces quatre éléments couvrent le cycle de vie essentiel consistant à importer des données, à les envoyer, à produire un artefact imprimé et à terminer la session. C'est pourquoi ils survivent dans chaque conception de menu, quel que soit l'environnement.
Pourquoi la mise en page est-elle absente du menu Fichier par défaut de 4D Foundation, et dois-je l'ajouter ?
Le menu Fondation ne l'inclut tout simplement pas, ce qui signifie que l'application réutilise la mise en page choisie en dernier lieu, potentiellement avec une taille, une orientation ou des marges incorrectes. Vous devez ajouter un élément de mise en page à votre menu Fichier personnalisé, idéalement juste au-dessus de Imprimer, afin que les utilisateurs puissent corriger la mise en page avant l'impression.
Pourquoi Open Database n'apparaît-il pas dans un menu personnalisé de 4D ?
Parce que 4D ne peut ouvrir qu'une seule base de données à la fois, et que l'utilisateur a déjà ouvert la base de données pour accéder à vos menus. Une commande Open Database n’a pas de cible significative, elle est donc redondante dans un menu personnalisé destiné à l’utilisateur.
Où doit aller le fichier journal/aucun fichier journal à la place du menu Fichier utilisateur ?
Il doit être déplacé vers un menu spécifique au programme ou réservé à l'administrateur, car il contrôle la journalisation utilisée pour la maintenance et la sauvegarde et interagit avec la récupération. Exposer une bascule de journalisation brute aux utilisateurs ordinaires risque de compromettre la capacité de récupération ; si les utilisateurs ont besoin de sauvegardes, donnez-leur plutôt une seule commande de sauvegarde contrôlée.
Open Table doit-il rester dans le menu Fichier ?
Généralement non. La navigation dans les tableaux est mieux gérée par un menu de navigation dédié, une barre d'outils ou des boutons sur un formulaire d'accueil, qui maintiennent le menu Fichier concentré sur les opérations au niveau du document et place la navigation là où les utilisateurs s'attendent à la trouver.
Essayez FileMaker gratuitement pendant 45 jours
La plateforme de base de données relationnelle de longue date pour les équipes qui ont besoin d'applications personnalisées sur ordinateur, Web et mobile à partir d'un seul fichier.