web-dev-qa-db-fra.com

représentation textuelle lisible par machine et lisible par l'homme d'un programme récurrent

Nous travaillons sur une fonction "importer depuis Excel" pour accélérer la saisie de données en masse, en particulier lors du transfert de données d'un autre système B2B vers le nôtre.

Sur les 20 champs que nous allons importer, un seul d'entre eux est difficile à formater dans Excel: un calendrier récurrent. J'essaie donc de définir un format de texte qui:

  • est du texte brut non formaté qui peut tenir dans une seule cellule Excel (ou un petit nombre de cellules sur une ligne)
  • est lisible par machine pour éviter les erreurs d'importation
  • est lisible par l'homme pour éviter les erreurs de saisie de données et pour faciliter le dépannage des erreurs de format si l'importation échoue.

De toute évidence, ces exigences sont en tension, ou ce serait une solution plus facile. ;-)

Nos utilisateurs sont des employés de bureau non techniques, donc "il suffit d'utiliser XML ou JSON" ne fonctionnera probablement pas ici - trop complexe pour nos utilisateurs, et trop verbeux aussi.

Bien que l'application soit uniquement en anglais maintenant, nous devrons éventuellement localiser dans les langues européennes (bien que ce ne soit pas RTL ou Asie de l'Est ou d'autres localisations plus difficiles).

Ce que j'essaie de faire est-il possible? Ou est-ce une si mauvaise idée que je ne devrais pas m'embêter?

L'alternative est que chaque fois que nous devons entrer des centaines de plannings dans notre application, nous finirons par demander à nos développeurs d'écrire du code d'importation personnalisé ... et pour des raisons évidentes, nous voulons vraiment éviter cela afin que nos clients puissent se servir eux-mêmes à la place .

Aujourd'hui, les horaires sont très simples: un modèle se reproduit toutes les 1-4 semaines, et pendant ces 1-4 semaines, les mêmes jours sont sélectionnés.

Exemples:

  • Lun, mer, ven (modèle 1 semaine)
  • Chaque 2e lundi (modèle de 2 semaines)
  • Chaque 4ème mardi (modèle de 4 semaines)
  • Modèle de deux semaines, avec lun, mer la première semaine et mar, jeu la deuxième semaine

Idéalement, un format pourrait évoluer au fil du temps, donc si nous voulions prendre en charge les horaires mensuels (par exemple le 1er et le 15 du mois), le format pourrait être étendu.

Je sais que la sérialisation de texte est souvent plus un sujet destiné aux développeurs qu'un sujet UX, mais dans ce cas, je cible le format de texte aux utilisateurs non techniques, pas aux développeurs, j'ai donc supposé que UX StackExchange serait approprié. Si vous n'êtes pas d'accord, n'hésitez pas à voter pour migrer vers StackOverflow.

1
Justin Grant

Le contenu lisible par machine ne doit pas nécessairement avoir un impact sur la représentation visuelle des humains.

Les solutions potentielles pour votre cas particulier incluent Microformatage hCalendar et Microdonnées Dates, Heures et Durées

Ceux-ci sont tous deux écrits dans le code plutôt que dans la représentation visuelle. Cela signifie qu'ils fonctionnent également pour RTL, Asie de l'Est et tout autre format de langue que vous pouvez représenter.

2
Andrew Martin

Il s'agit bien d'un problème d'utilisation, bien que d'autres puissent être en désaccord.

Le meilleur format auquel je peux penser alors qu'un peu lourd sur les colonnes est le seul moyen de garantir sans obliger les utilisateurs à se souvenir des codes de formatage hyper spécialisés:

A              B             C             D             E
FREQUENCY      EVERY 1ST     EVERY 2ND     EVERY 3RD     EVERY 4TH
------------------------------------------------------------------------
Weekly        |Mon, Wed, Fri|
Fortnightly   |              Mon          |
Four Weekly   |                                          Tues          |
Fortnightly   |Mon, Wed      Tue, Thu     |
  • Fréquence: pourrait permettre une très large gamme de synonymes d'entrée utilisateur, ou pourrait être stricte mais l'utilisation de mots est plus conviviale mais sinon la colonne pourrait être convertie en "Fréquence (jours)" et donc toutes les entrées en multiples de 7 [inconvénient des jours est-ce que cela rend la saisie mensuelle difficile, est-ce un mois 28, 30, 30.43, 31 jours?]
  • Quant à "Lun, Mar, Mer, Jeu ..." ou "Lundi, Mardi, Mercredi, Jeudi ...", je serais aussi flexible que possible pour l'utilisateur et le convertirais en ce qui fonctionne le mieux dans Excel, probablement abrégé mais autoriser à la fois la forme courte et longue est immensément meilleur en tant qu'entrée utilisateur.
  • Pas sûr de la connexion entre l'entrée utilisateur via l'interface utilisateur de l'application et une feuille de calcul Excel [stockage des données pas une base de données sauf si l'utilisateur doit y lire/modifier] mais s'il est possible de formater la feuille de calcul [s'il y a une raison de le faire] , si la zone entre les barres de tuyauterie était conditionnellement formatée en BG gris clair [contre BG blanc normal], cela le rendrait beaucoup plus évident pour quiconque lisant la feuille de calcul, par exemple 2 cellules en surbrillance = cycle de 2 semaines, 4 cellules en surbrillance = cycle de 4 semaines sans même avoir à lire la colonne de fréquence sans aller trop loin ce qui serait d'utiliser 28 cellules pour chaque jour de cycle de 4 semaines.
  • Mettre tout le texte dans une seule colonne réduit considérablement la lisibilité s'il y a une raison pour que les utilisateurs le fassent? Le mettre dans une colonne de fréquence et une colonne de jours est toujours un hasard et manque visuellement. Bien qu'il soit difficile de déterminer d'où vient la difficulté de l'utilisateur du côté de l'application si elle ne provient pas d'une version mobile d'Office, une liste déroulante avec fréquence peut être utilisée, puis un calendrier spécial peut apparaître dans la liste déroulante qui n'affichera que 7 jours si l'utilisateur a sélectionné une semaine.
0
Evad