Un utilisateur doit-il pouvoir contrôler le fuseau horaire lors de la planification de quelque chose?
J'ai un produit où les utilisateurs peuvent planifier le contenu à publier sur les réseaux sociaux. Les utilisateurs peuvent avoir leur compte défini sur leur fuseau horaire local, tout en exécutant une campagne qui les oblige à planifier le contenu pour un autre fuseau horaire.
Un exemple de ceci serait un utilisateur qui gère son compte depuis un bureau à New York, mais qui mène une campagne publicitaire ciblant un public à Los Angeles.
L'utilisateur doit-il pouvoir choisir le fuseau horaire de l'heure planifiée lors de la création de la publication planifiée? Ou devraient-ils toujours s'attendre à régler l'heure prévue dans leur propre fuseau horaire, en compensant eux-mêmes le décalage horaire?
Lorsqu'ils consultent la liste des publications qu'ils ont planifiées, quel fuseau horaire doit s'afficher pour l'heure planifiée?
Expliquez clairement que la campagne planifiée se déroulera dans le fuseau horaire de Los Angeles pour réduire toute confusion. MailChimp le fait très bien avec leur fonctionnalité de livraison par fuseau horaire http://mailchimp.com/features/timewarp/
L'utilisateur s'attendra à ce qu'il soit, par défaut, dans son fuseau horaire. Tout autre chose que cela causera de la confusion. Cependant, comme @RizwanJavaid l'a souligné, pour certains marchés/projets (et je dirais que les médias sociaux en sont un), il est tout à fait normal de pouvoir changer cela.
Je me retrouve souvent à un fuseau horaire en voyage et je gère mon calendrier sous OS X ou Windows Office est un champ de mines. Je peux résumer le problème comme "trop de choix": les programmes de calendrier essaient tous de faire quelque chose d'intelligent, et non seulement ils ne font pas quoi [~ # ~] i [~ # ~] besoin mais je ne sais jamais trop à quoi m'attendre. Les options de configuration ne font qu'empirer les choses, car les options ne correspondent pas à ce que je dois contrôler, entraînent invariablement un comportement plus complexe et me laissent toujours me demander si je pourrais résoudre le problème en modifiant un paramètre. Donc, ma suggestion est: faites la bonne chose, mais surtout gardez-la prévisible.
Je m'attends à ce que pour une campagne localisée, ce qui compte, c'est quand le contenu est livré (prime time, heure de pointe, peu importe), c'est-à-dire l'heure locale. Mais certains utilisateurs pourraient être plus intéressés par le moment où l'événement se produira, afin de pouvoir surveiller les problèmes. Quel type d'utilisateurs avez-vous dans votre entreprise? Si vous avez besoin de répondre aux deux types, je commencerais par montrer les deux fois dans la liste des messages programmés. Par exemple, deux colonnes de temps (et peut-être un moyen de masquer les colonnes qui ne vous intéressent pas).
Si aucun de vos utilisateurs ne se souciait du temps sur le marché cible, ce serait un appel facile. Mais en supposant qu'ils le fassent, je modéliserais l'interface pour planifier les événements sur un calendrier de rendez-vous:
Pour les événements dont les participants se trouvent à un certain endroit, choisissez toujours le fuseau horaire à l'endroit de l'événement. Peu importe où je suis lorsque je planifie l'événement, peu importe le fuseau horaire de mon ordinateur. Cela s'appliquerait si vos campagnes sont généralement limitées à un marché (c'est-à-dire un fuseau horaire).
Pour les événements accessibles quel que soit le fuseau horaire (dans votre cas: non limité à un marché local), choisissez un point de référence raisonnable et respectez-le - c'est-à-dire, ne le changez pas lorsque votre utilisateur change d'emplacement. Ce serait un paramètre à l'échelle du compte.
En bref, la règle serait: utiliser l'heure locale à moins qu'il n'y ait pas d '"heure locale". Cela nécessite que le lieu de l'événement peut être déterminé avant le moment de l'événement est choisi.
À mon avis, la meilleure chose que vous puissiez faire dans ce cas est la suivante:
- L'utilisateur configure l'heure d'envoi du message en fonction de son fuseau horaire.
- Le programme affiche immédiatement l'heure correspondante dans les zones suivantes:
- Fuseau horaire du Pacifique;
- Fuseau horaire des États-Unis de l'Atlantique;
- Fuseau horaire britannique
- Fuseau horaire Europe de l'Ouest
- Fuseau horaire du Pacifique australien.
- Chaque fois que l'utilisateur reconfigure l'heure d'envoi, les autres fuseaux horaires sont mis à jour en conséquence.
99% des médias sociaux (essentiellement tout en dehors de la Chine) sont utilisés par les utilisateurs dans plus d'un fuseau horaire. les 5 fuseaux horaires ci-dessus contiennent la plupart des utilisateurs de médias sociaux en dehors de l'Inde et de la Chine, vous pouvez donc planifier en conséquence. La raison pour laquelle vous devez afficher plusieurs fuseaux horaires est que A) votre programme doit pouvoir être utilisé à l'international, sans que l'utilisateur ait besoin de configurer le public cible à chaque fois; et B) Une campagne qui vise un certain fuseau horaire peut être pertinente pour les personnes d'un autre fuseau horaire, même si c'est juste pour que quelqu'un dans un autre fuseau horaire sache ne déranger personne dans ce fuseau horaire participant à un événement de cette campagne.
Comme le dit Golden Krishna, la tinterface n'est pas une interface. Demandez donc à l'utilisateur la localisation de la réunion et demandez-lui l'heure de cette réunion.
Tenez compte ou demandez-lui s'il est l'heure locale.
Demandez d'où il vient et lui spécifiez automatiquement l'heure en deux formats sa localisation réelle et l'heure de la réunion de localisation avec une table avec tout le cadre GMT.
Mais ne lui demandez pas de calculer et de préciser la différence.