I'm tempted to like it, because the timezone offset is obviously much more related to the time than the date, but moving it closer to the date really couldn't hurt, could it? Placing the offset in the middle of the full time string together with 22:36 requires thought. I might be tempted to start trying to lay this out so the math works out for (+5) adding directly to the hour as 5+03:36 = Z22:36, but now I realize a larger problem with all this. We do use more characters, especially if we want to be able to extend this to local times too (e.g. For example, would it not be better to simply prefix the timezone information directly? For example, it's currently Z22:36. My concern is that there are better solutions to the first thing, despite any improvements made to the second. Secondly, it's a tool for helping people with world clocks and scheduling. On the other hand, world times are the same as local times for everyone within earshot of me, so I would never bother prefixing things locally. You can rightfully argue that the locale is needed to interpret the rest of the time, so this is the correct way to format world times. The most interesting part to me is that, since I read left to right, I also see the locale information first as opposed to last. To give you an idea about how I'm thinking of this, first and foremost hTime is a time format, meaning it's just some mapping of letters to a local time's hour. but to be perfectly honest, I haven't yet decided if I love or hate this idea yet. > Would you like to give hTime a go and test it for some days? You just need to decide which way to rotate ) I hate most animations, however smoothly rotating the ring would do wonders for people understanding what's going on here. I actually had a really simple idea that would have helped me a lot while discovering the tool. Unfortunately time requires that I remember one additional piece of information, namely UTC: X=24, before I can index into the alphabet and calculate the difference myself, whereas UTC simply requires I add the offset to the time and move on with my life. Depending on your use one might be better than the other. Leading with a letter helps people not start reading as a local time, whereas with 8061 formatted times you only notice it's not in your own locale at the very end of the time. Both UTC and your htime thing are a way to solve that problem. The problem is that they might want to interpret what they see in a different way. This is true of any clock (unless fancy optics are involved, or we get too deep into physics), two people looking at the same wall clock will see the same time. "So all users when they look at the clock at the same time no matter where they are, they'd see the same time." That being said, the interface should really put the location closer to the letter ring, because it's somewhat easy to forget you're looking at a localized mapping and what the letters mean, since they are in another UI element. I was actually arguing that the letter makes it easier to comprehend in a sense, because it forces you to do the mapping, instead of assuming the same zone.
0 Comments
Leave a Reply. |