openstreetmap / openstreetmap-website

The Rails application that powers OpenStreetMap
https://www.openstreetmap.org/
GNU General Public License v2.0
2.22k stars 919 forks source link

Timestamps across the web site / make format user selectable #631

Open woodpeck opened 10 years ago

woodpeck commented 10 years ago

This is a feature request for user-selectable date/time styles across the web site. A detailed explanation follows below.

For a long time we've been using vague timestamps like "about 5 years ago" in several places in the UI. - I see where the motivation comes from (less clutter, nicer on the eye, easier to translate, no time zone issues) but I've always hated it.

The reason is that more often than not, I was using the web site to investigate something. Was a certain edit before or after a certain other edit? Did they make that change after I sent them the message? Was this account created before or after I blocked that other account? Was the block they got a reason for the edit, or was the edit the reason for the block? And so on. Precise time stamps make this kind of work much easier, especially if you're looking at a time ranger where everything is "about one year ago".

With the recent UI change, these imprecise time stamps are used in even more places, occasionally augmented by a hover facility that will show a precise time stamp. In this trac ticket https://trac.openstreetmap.org/ticket/5045 the issue has been discussed, and the complainant has made available a hack that would allow people to have precise time stamps at least where the hover code is enabled.

So far, so good, and you'll say that my use case is niche and anyway I could build tools for myself to find out what I need to know. BUT, and I say this from my DWG background: Going forward, we will need more "ordinary users" taking stewardship if data, investigating strange edits and wrongdoings, reporting or flagging bad ones, even dealing with them themselves. The "niche" that DWG currently occupies will have to widen in the future, with more and more people looking at the finer details of what is going on in OSM.

While "5 hours ago" is nice for the casually browsing user, it makes life harder for those who actually want to do some sleuthing, and we don't want to make it harder for them.

Yes it would be terrific if we could have a second web site that was specifically aimed at experts but we won't any time soon. So in the mean time it would be great if the needs of more analytically inclined users were kept in mind when changing things. It would be great if, in their profile settings, users could choose whether they want precise timestamps throughout, or the reader-friendly "5 hours ago" variant.

smsm1 commented 10 years ago

If you hover over the text giving the approximate time, it'll give a tooltip with the exact details e.g. openstreetmap___changesets

smsm1 commented 10 years ago

See also https://trac.openstreetmap.org/ticket/5045#comment:9

pnorman commented 10 years ago

If you hover over the text giving the approximate time, it'll give a tooltip with the exact details

Can't copy/paste from them. Also, I don't believe you can search for text in the tooltip.

This isn't to say this is an issue introduced in the redesign, we have been, and remain inconsistent about date formatting. It would be nice to get formats consistent, then allow the user to select their format.

SomeoneElseOSM commented 8 years ago

(re the comments above about tooltips) they don't appear everywhere. See for example:

http://www.openstreetmap.org/user_blocks/493

HolgerJeromin commented 8 years ago

Just another topic are mobile browsers where you have no way to get the exact Information.

polarbearing commented 8 years ago

I fully support @woodpeck's arguments, as an "ordinary user" checking changes in my neighbourhood. The current vague timestamps make my life difficult as well, along with the lack of clear page numbers for a user's history, as in #1089. As said there, we should have at least the option to switch to classic timestamps and pagination, with page one on the oldest changesets, as it is typical in forums, of course showing the latest first.

HolgerJeromin commented 3 years ago

We could implement somthing like https://bitsofco.de/making-abbr-work-for-touchscreen-keyboard-mouse/ But moving to data-title to prevent duplicate tooltip on devices with a mouse as mentioned in the comments.

boothym commented 1 year ago

Yes please, let's implement the CSS tooltip mentioned above. It's a bit annoying if you want to know the exact timestamp when using your phone.

lgommans commented 1 month ago

Been meaning to find the right file to commit this into and propose it as pull request but I keep not getting around to it...

Simple CSS-only solution that doesn't change anything else except lets you see the title text for abbr elements on mobile and desktop consistently:

screenshot of a webpage, the URL bar shows test.html and the page contains a sentence with a tooltip in the middle, triggered (in this case) by positioning the mouse over it

(The cursor is actually a hand/pointer; screenshot software does not capture that.)

<style>
    abbr[title] {
        position: relative;

        /* ensure consistent styling across browsers */
        text-decoration: underline dotted;
    }

    abbr[title]:hover::after,
    abbr[title]:focus::after {
        content: attr(title);

        /* position tooltip like the native one */
        position: absolute;
        left: 0;
        bottom: -30px;
        width: auto;
        white-space: nowrap;

        /* style tooltip */
        background-color: #1e1e1e;
        color: #fff;
        border-radius: 3px;
        box-shadow: 1px 1px 5px 0 rgba(0, 0, 0, 0.4);
        font-size: 14px;
        padding: 3px 5px;
    }
</style>
<a href="/issues/">There are <abbr title="seven!" tabindex=0>how many?</abbr> issues with this approach!</a>

CSS from https://stackoverflow.com/a/69353021/1201863. Tested that the code works in normal text and also nested, for example in an <a> link

The tabindex makes it selectable such that screen reader users can hopefully also open it. Regarding the value, MDN says tabindex=0 "means that the element should be focusable in sequential keyboard navigation" -- it does not put it at the top of the tab stack!

Hopefully this covers everyone's (accessibility) requirements by looking like what people expect from a tooltip while also not requiring javascript. I'm kind of blown away that mobile browsers, after all these years, still can't just do tooltips natively...