The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Better Time-passage Indicators

Indicating time on the web can be improved. Some ideas about how.

An old calendar stamp.
“Calendar” by John Nuttall

One of the things you see quite a bit on the web is indicators of when something was posted, edited, recorded, etc. And they have two predominant forms:

  • Posted two hours ago
  • Posted April 1, 2014

The web could use better time indicators, though. For example, if you are looking for a bug in some software, and there was a major release in March, you probably want to only see things since then. So having time indicators that show relations like that could help. If the site you’re using is showing a time-since indicator, you have to stop: “okay, it is November and this says six months ago, so that’s around the right time.” If it said March, it would be more convenient.

But if it’s a closer-to-now time, what then? A comment posted earlier in the day might say, “posted two hours ago.” Again, you have to do a mental conversion: it’s noon, so 10am. It’s 6pm, so 4pm.

And then you have earlier-in-the-week times. Instead of “three days ago,” why not, “Wednesday?” You remember Wednesday easier than thinking, “it’s Saturday, minus three…”

What will time indicators of the future do instead?

For one, they should age. After a month has passed, it’s better to say month and year versus n months ago. The switch-to-weekday if it’s in the past week thing is probably good, too.

For another, they should eventually (as we begin tracking ourselves) learn to incorporate personal markers. Saying, “this comment was posted just after you ate lunch” might give you better mental context than saying, “four hours ago.”

Intermediate times might be harder to fix. Three weeks ago on a Tuesday? If you keep up with elections, they could say, “on the day of the recent election.” But what if there wasn’t anything significant to tie it to?

The other part of this is the potential benefit of iconic time. We have icons for all sorts of things, but not for time. What is the symbol for an hour, for example? For a day? A week, month, year?

Having icons for these units could simplify visual recognition. A day might be some sort of sunrise-sunset icon. A week might be a seven-pipped design with the pips being suns. And so on. Searching through some of the Unicode symbols, there are:

  • Non-Western symbols (nth day)
  • Alchemical symbols (hour, day, month)
  • Weather symbols (sunrise, sunset, moon phases)
  • Food symbols
  • Holiday symbols
  • Sports/activity symbols

And so on. There are analog clock faces, but they probably wouldn’t simplify much. If a sporting event has a fixed time that everyone knows, it might work. Food symbols could signify specific meals (e.g., pizza for breakfast). Weather symbols for sunrise and sunset could be used, as could holidays under some circumstances. Animal symbols might work, too. A rooster for dawn and a cow for dusk/night. The British could use a teapot for whenever it is they sing “I’m a Little Teapot” every day. A beer mug could be used for happy hour.

But it might really be better to invent new, abstract symbols for times (or at least modernize something like the alchemical symbols for hour, day, and month).

Also, it’s important to note that improving time displays only makes sense for casual viewing. If you’re working in the context of times and dates, say in a spreadsheet, it’s not needed as much. But when your main focus is not time-related, having easily digestible times can save you a few cycles here and there.

The Woes of Color

Colors are difficult to work with, especially for accessibility purposes.

As anyone that’s watched this blog when it’s changed, or looked at Sequlr knows, I’m not the most gifted person when it comes to picking colors.  Part of that is the fact that not all color combinations even work to begin with.  There’s this notion of contrast, and without contrast you simply cannot have a foreground and background at all.  The WCAG 2 guidelines for color contrast makes picking colors something of a minefield.

Many websites (I might even guess a majority, but I haven’t done any serious sampling) completely ignore WCAG/color contrast, assuming all of their users have perfect vision.  They are more concerned with the visual appeal of their design than the functionality.  This goes even for very prominent websites and those that at least pay lip service to accessibility.

But even for the few, the proud that make earnest attempts to comply, to contrast correctly, the obstacles are considerable.  Consider Mozilla Firefox, which is currently in the late beta versions of its fourth release.  They have a CSS color, GrayText, which is hardcoded and bad for accessibility in certain circumstances.  In the case I noticed, it’s used for the hovered link, now that the status bar is going away.  Of course, they shouldn’t be trying to indicate placeholder or non-standard text by making it gray, but it wouldn’t be so bad if they derived its value from the OS theme.

And there’s the second hit: the OS likely doesn’t provide a specific color for this use case.  It probably doesn’t provide guidance for link/visited link colors either.  The OS justification for this is likely that adding more color choices for the theme would complicate it.  That’s true, but you have to choose your direction of complication: either provide the choice that can be ignored by the user or end up with the application developer painting themselves into a corner.  In the latter case you end up harming your users anyway, as they may find their theme incompatible with a variety of software despite it being an otherwise usable theme.

My own experience with color has been that it’s very difficult even if you ignore accessibility.  If you do take contrast into account, it’s harder because you have to pick some colors and then tweak them or at least check them for proper contrast.

I think the solution is better allowance for user choice in colors.  At the OS level, as I’ve noted, but these color choices need to bleed through to the web.  The web application should be able to get a set of colors the OS theme uses, and apply them correctly to the presentation.  This would make the web blend better with the desktop, and it would improve the accessibility of the web a bit.  The other change needed is for the web to get over art.  Where the goal is art, the web can keep going, but where the goal is actually to present information, the tendency for art to trump function is alarming and harmful to the platform.


nxn displays and the web

In general pages should have a very minimal resolution requirement to avoid horizontal scrolling. But every site seems different and that’s no fun.

Obviously (hopefully) I’ve once again made a few changes to the site. They’re all pretty obvious and hopefully self-explanatory so I won’t bore you with them.

But one thing I’ve thought about off and on while working on this site and browsing the web in general is the nature of resolutions and how to accommodate virtually any resolution in the future.

Let me start by saying my resolution is 1680×1050. I _never_ browse full-screen. While people on a 1024×768 or thereabouts (or maybe any 4:3 ratio display) may browse full screen, I’m sure many of them don’t too. For that reason I tend to think that designing pages for “minimum recommended resolution” is silly and bad.

In the future displays will continue to grow _and_ shrink. You may have a three (3) meter diagonal display that’s capable of… 1048576×786432 or something crazy like that. The good news is for smaller devices the resolution will increase too. Hopefully screen sizes even on small devices will grow to maybe 20cm diagonal as the lower bound.

But aside from an extreme constraint (for example, this site starts to scroll horizontally about 640px wide) having a fixed-width is usually pointless. Maybe even arrogant. One place this is pretty common is in forums. They display all those fancy columns in thread lists and forum lists. When the resolution shrinks they should be javascript-css’d to vanish (the superfluous ones). Once any extras are gone, if the width is still too small, go ahead and h-scroll your hearts out.

—-end rant—-