Qu'est-ce qu'une bonne interface utilisateur Web pour capturer une durée de temps de l'utilisateur. Disons que nous voulons capturer une durée de temps en quelques minutes. Mais voudrait le présenter de manière à ce que l'utilisateur puisse entrer en heures et les minutes.
Utilisez simplement 2 boîtes de texte pour HRS \ min? Ou une seule zone de texte et laissez-les taper dans "1h31min" ou "91 min"?
ou y a-t-il quelque chose de mieux?
6 Réponses :
Laissez-les simplement taper les chiffres uniquement dans un format de temps pré-défini.
Placez 2 textes de texte pour heure et minute sans HR ou Min.
Vous devez également définir s'il s'agit d'un système de 24 heures ou de 12 heures.
Eh bien, c'est une durée de temps. Donc, il n'y a pas de concept de 24 heures de 12 heures juste? Ils pourraient entendre théoriquement "32 heures 30 minutes"
D'accord. Que se passe-t-il quand il entrave une minute supérieure à 60?
Si vous avez deux zones de texte étiquetées d'heures et de minutes, vous devez faire face à l'affaire où l'utilisateur tire dans les deux. mais qu'en est-il de J'ai utilisé trop d'UIS ennuyeux où changer un champ zapne d'autres entrées pour avoir confiance que je peux concevoir un ensemble de comportements de non-sons. Par conséquent, j'irais pour une seule boîte dans laquelle nous pouvons taper 3h ou 1h 35m ou 95 m et avoir une affichage en lecture seule distincte de l'interprétation. < P> Il semble y avoir une opportunité pour un bon widget permettant d'autoriser une entrée à la souris, de la même manière qu'un widget de calendrier permet la saisie de la date. Une petite horloge avec des mains glissables?
Bien, les horaires distincts et les minutes sont le plus sûr mais plus lent à utiliser qu'un seul champ. Vous pouvez par défaut les heures à 0 si vous ne vous attendez pas à de nombreuses durées de plus de 1 heure.
Peut-être dépend de votre population, mais je m'attends à ce que les utilisateurs puissent gérer des heures et des minutes dans la même zone de texte si vous fournissez une invite, telle que "Durée de temps (HRS: Min):"
Avec cette invite, acceptez une chaîne initiale ininterrompue de chiffres comme heures et toute chaîne non brisée ultérieure de nombres sous forme de minutes, de sorte que toutes les entrées suivantes sont traitées comme équivalentes.
2:30
02:30
02:30:05
2.30 (ou peut-être pas: tandis que c'est idéal pour l'entrée du clavier, mais vous voudrez peut-être faire une exception pour le point décimal pour permettre à l'utilisateur d'entrer des heures de fraction, telles que 2,75 pendant 2 h 45 min.) < / p>
2 30
2 heures 30 min
2 heures, 30 minutes
2jaqp 30 !!!!
Je ne vois aucune raison d'exiger que les minutes soit inférieure à 60. L'utilisateur devrait également pouvoir exprimer le temps comme:
Lorsque la mise au point quitte le champ, corrigez automatiquement les utilisateurs qui entrent au format spécifié (HRS: Min) pour commenter l'interprétation que vous avez faite.
Si tout ce dont vous avez besoin pour votre objectif est une approximation approximative du temps (ou vos utilisateurs estiment quand même que), puis envisagez des boutons d'option ou une liste déroulante avec des gammes de durée (par exemple, 0 à 5 minutes, 5 à 15 minutes, 5 à 15 minutes. , 15 min à 1 heure, plus d'une heure.). Ou s'il existe des limites définies sur les durées et que les intervalles sont fonctionnellement linéaires, vous pouvez utiliser un curseur marqué.
Quel que soit le format d'entrée ou le contrôle que vous utilisez, il devrait être compatible avec la source d'informations. Où les utilisateurs obtiennent-ils cette durée? Quelles unités, format, intervalles et degré de précision sont utilisés là-bas? Comment les utilisateurs pensent-ils et parlent du temps entre eux?
Votre exemple de: 150 ne fonctionnera pas avec le reste de la réponse tel qu'il sera interprété comme 150 heures. Quoi qu'il en soit, je ne pense pas que cette liberté soit bonne pour l'utilisateur car elle ne s'attendra pas et ne saura généralement pas comment l'utiliser
Par "chaîne initiale de chiffres", je voulais dire la chaîne initiale lorsqu'elle commence par un chiffre, donc: 150 n'a pas de chaîne initiale de nombres, les heures de 0 et sont de 150. Je ne vois pas comment une liberté inattendue sera un problème . La plupart des utilisateurs ne le découvriront jamais (ils ne penseront jamais à taper "2 30"), mais ceux qui peuvent la trouver utiles (en tapant un côlon est relativement gênant sur de nombreux claviers). Inattendu Limitations --NOW C'est un problème.
Je pense qu'il ne devrait y avoir aucune correction latérale du client pour les minutes supérieures à 60 comme suggérées. Il ne serait déroutant que des problèmes inutiles.
Utilisateur entré dans les données afin qu'il devrait comprendre ce qu'il a tapé et qu'il n'est pas nécessaire de le corriger.
Je quitterais ces champs comme rempli par l'utilisateur. Sur le côté serveur, je calculerais simplement les minutes totales comme suit:
Merci pour tous les commentaires.
Qu'est-ce que j'ai finalement fini par faire était, avoir une seule zone de texte qui affiche la durée de la durée du format "XXHRS Yymin"
L'utilisateur peut le modifier et lorsque la mise au point s'éloigne de la zone de texte, elle recalcule la durée et reforma le texte sur la forme canonique.
L'analyseur à interpréter le texte entré est assez libéral.
C'est un ensemble d'expressions régulières pour correspondre à n'importe quel nombre suivi de "H" ou "M" ou "D" pour représenter des heures, des minutes et des jours. Si cela ne trouve aucune "unité" avec un nombre devant celui-ci, il suppose que vous avez saisi un nombre pur sous forme de minutes et l'interprétera comme telle.
Donc, si les types d'utilisateurs:
"1.5h", il se reformatera à "1h30min" lors de la sortie de la zone de texte.
"90 min" sera également reformaté comme "1h30min"
L'analyseur regarde uniquement le premier caractère suivant le numéro, ce qui signifie que vous pouvez entrer "1 jour, 7 heures et 19 minutes" et il le reconnaîtra correctement.
Bien sûr, cela reconnaîtrait également "2 trous et 19 souris" comme "2h et 19min".
Je pense que je peux vivre avec ça.
Je pensais juste à cela et je me suis rendu compte d'une interface utilisateur familière pour ce genre de chose est un four à micro-ondes. Pour des utilisations telles que des utilisations iPhone, un clavier peut être meilleur que la chose à défilerelle de roulement que je vois souvent.
Dans mon cas, je pense que je vais aller avec un champ de texte pour "numéro" et une boîte de sélection pour "Unité" (années, mois, semaines, jours, heures).
Les curseurs (JQueryui, HTML5) pourraient également être une option, en fonction de quel type de portée dont vous parlez.