Introduction
Dans ActivityInfo, la manière dont vous nommez vos formulaires, sous-formulaires et champs détermine la façon dont les utilisateurs interagissent avec votre base de données, de la saisie des données à l'analyse et au reporting.
Une dénomination non structurée entraîne de la confusion, des doublons et peut conduire à des erreurs. Une dénomination structurée apporte de la clarté, de la cohérence et crée un système qui peut évoluer sans devenir difficile à gérer. Elle réduit également le besoin de clarifications répétées lors de la saisie ou de l'analyse des données, car des formulaires et des champs bien nommés communiquent directement leur objectif.
Nommer les formulaires et les sous-formulaires
Les formulaires sont les conteneurs de vos enregistrements. Chaque fois qu'un utilisateur souhaite saisir des données, il doit décider quel formulaire utiliser. Si la dénomination n'est pas claire, cette décision devient incertaine et peut entraîner la saisie de données dans le mauvais formulaire.
Le nom d'un formulaire doit communiquer son objectif sans que l'utilisateur ait besoin de l'ouvrir. Il doit fournir suffisamment de contexte pour le distinguer des autres formulaires de la base de données.
Soyez explicite et non générique, car les utilisateurs doivent pouvoir identifier l'objectif d'un formulaire directement à partir de son nom.
Pour y parvenir, utilisez une approche de dénomination structurée qui inclut des éléments de contexte clés tels que le projet, le secteur, la région, l'activité ou la période.
La dénomination doit également refléter la manière dont le formulaire est utilisé dans le flux de données. Un concepteur de formulaire doit se demander si le formulaire prend en charge une seule étape d'un processus ou plusieurs flux de travail. Par exemple, nommer un formulaire « Formulaire d'inscription » peut être trompeur s'il est également utilisé pour des mises à jour ou des activités de suivi. Dans de tels cas, un nom plus large comme « Registre » est plus approprié.
Dans d'autres situations, un formulaire peut simplement représenter une collection d'une entité de données spécifique. Dans ces cas, nommer le formulaire en utilisant le pluriel de cette entité est souvent plus clair et plus intuitif, comme « Partenaires » ou « Emplacements ».
Dénomination des sous-formulaires
Les sous-formulaires capturent les enregistrements liés à un enregistrement parent.
L'utilisation de noms au pluriel communique que le sous-formulaire représente une collection d'enregistrements liés.
Exemples de sous-formulaires dans le formulaire Enquête auprès des ménages Phase 1 - 2026 :
- Membres du ménage
- Visite_s_
Nommer les champs
La dénomination des champs dans ActivityInfo remplit deux fonctions simultanées. Premièrement, les étiquettes fournissent des indications claires aux utilisateurs lors de la saisie des données. Deuxièmement, les codes de champ permettent des calculs en arrière-plan et la synchronisation des données avec des plateformes tierces. Pour maintenir l'intégrité des données, assurez-vous que l'étiquetage est cohérent entre les formulaires numériques et les questionnaires physiques correspondants utilisés sur le terrain.
Lors de la dénomination des champs :
Utilisez des étiquettes de champ claires et riches en contexte - Les étiquettes courtes sans contexte peuvent devenir peu claires lors de la saisie des données. C'est courant avec des étiquettes telles que « Nom » et « Date ». Pour éviter toute ambiguïté, incluez suffisamment de détails dans l'étiquette pour qu'elle puisse être comprise seule. Exemples :
Date d'inscription
Date de distribution
Prénom
Nom de famille
Appliquez des modèles de dénomination cohérents - Lorsque les champs sont nommés de manière cohérente, la relation entre eux devient plus claire. Exemple de modèle :
Nom du bénéficiaire
Date de naissance du bénéficiaire
Sexe du bénéficiaire
Utilisez les codes de champ pour la cohérence technique - Les codes de champ fonctionnent en arrière-plan mais sont essentiels pour les formules et l'intégration via l'API d'ActivityInfo. Ils doivent suivre un format structuré qui évite les problèmes de compatibilité entre les systèmes. Assurez-vous que les codes de champ sont concis et significatifs. Exemples :
| Étiquette | Code de champ |
|---|---|
| Nom complet | full_name |
| Date d'inscription | reg_date |
Les codes de champ doivent commencer par une lettre et ne contenir que des caractères alphanumériques ou des _tirets bas. Notez que les espaces ne sont pas autorisés.
Regroupement logique avec des en-têtes - Les longs formulaires peuvent submerger l'utilisateur, c'est pourquoi l'utilisation d'en-têtes de section peut diviser logiquement le processus de saisie des données. Vous pouvez également inclure une description pour donner aux utilisateurs plus d'informations sur une section. Exemple :
Section 1 : Identification du bénéficiaire - Nom complet, Numéro d'identification national du bénéficiaire, Date de naissance du bénéficiaire, Sexe du bénéficiaire, Numéro de téléphone du bénéficiaire
Section 2 : Interventions - Type de service, Date du service, Nom du partenaire
Section 3 : Suivi et statut - Date de suivi, Statut actuel, Notes
Standardiser les options dans les champs de sélection
Les options des champs de sélection unique et de sélection multiple doivent être clairement standardisées pour garantir leur cohérence dans toute la base de données. Sans normes claires, le filtrage, l'agrégation ou le reporting pourraient être affectés si vous avez plusieurs variantes de la même option.
Exemple :
- L'utilisation de casses différentes comme « Santé », « SANTÉ » et « santé » dans les formulaires entraînera des données fragmentées, car les systèmes traitent ces valeurs comme des valeurs distinctes lors du filtrage et de l'agrégation.
- L'utilisation de synonymes ou de variations terminologiques entraîne également une fragmentation. Tenez-vous-en à une seule norme, telle que « Transfert d'espèces », au lieu de la mélanger avec « Aide en espèces » ou « Soutien en espèces ».
Conclusion
La dénomination des formulaires et des champs dans ActivityInfo est un élément fondamental de la conception de la base de données qui façonne la manière dont les données sont collectées, comprises et utilisées au fil du temps. Une dénomination claire et structurée garantit que les utilisateurs peuvent identifier où saisir les données, comprendre ce que chaque champ représente et interpréter les résultats sans avoir besoin de conseils supplémentaires.
Tout au long de ce guide, quelques principes cohérents se démarquent. Les noms de formulaires doivent communiquer l'objectif et le contexte. Les étiquettes de champ doivent être descriptives et explicites. Les codes de champ doivent suivre un format structuré qui prend en charge les formules et les intégrations. Les options de sélection doivent être standardisées pour éviter la fragmentation des valeurs. Les en-têtes de section doivent organiser les informations dans un flux logique qui reflète la manière dont les données sont collectées en pratique.
Ces pratiques fonctionnent ensemble pour créer une base de données où :
- La saisie de données suit une structure prévisible
- Les valeurs restent cohérentes entre les formulaires et les utilisateurs
- Les rapports et les exportations conservent leur signification sans transformation supplémentaire
L'application précoce de ces conventions réduit les incohérences et limite le besoin de nettoyage des données par la suite. Elle favorise également la collaboration entre les équipes, puisque tout le monde travaille avec la même compréhension partagée de la structure des données.