(only) imprecise timestamps in the user changesets and on object history pages are not useful #5045
Comments
Author: TomH Hover over a time and it will show the precise value in a tooltip. |
Author: aseerel4c26 Sure, the attention catching dotted underline and the on hover mouse pointer makes that clear. Still the concerns are not addressed. |
Author: TomH The point is that design is always a trade off - we can't always do everything that everybody wants if for no other reason that different people may have conflicting views. We have chosen to show a concise and user friendly rough date and give those people who really need to see the full time a way to do so. Yes it may break some odd edge cases like searching for a date, but I really find it hard to believe that is a common thing for people to do. I don't see that there is any way to make the search work other than going back to showing full dates, hence regrettably I don't think we will be able to fix this. |
Author: aseerel4c26 Many times "vor etwa 5 Jahre" at http://www.openstreetmap.org/node/123456/history How to see the timespans between the single edits? Was it rather like one day or several months inbetween? Hard with the current setup. Where is the workaround or, better, the user setting?! I was fiddling (about an hour in total yes, I also could have been mapping!) with it (already some days ago) ... but was stuck at
Inserted via NoScript's script surrogates this did not'' work. And will not since these surrogates are executed after page load ''once. But the new object histories are loaded without a full page load. If I run it manually via Firefox' JavaScript console it works as intended. Maybe it is possible to run this path via GreaseMonkey or something but I am not really willing to install another addon just for fixing the openstreetmap page ... Maybe someone has another idea or - well, make that time display thing at least (!) a user setting. |
Author: aseerel4c26 the resolution was set to "fixed"? No, it is not fixed, really not. At best it is "wontfix". However, I hope that someone else may be willing to provide a fix. That does not need to be you, Tom. |
Author: TomH I'm sorry, who exactly gave you the power to decide who can and can't provide a fix? |
Author: aseerel4c26 Replying to [comment:7 TomH]:
sorry, I confused "must not" and "need not" (it is the other way round in German ). Fixed in the above comment. |
Author: aseerel4c26 Those about:config entries ([http://hackademix.net/2011/09/29/script-surrogates-quick-reference/ for NoScript]) work at least for nearly* all pages (if not loaded via JavaScript navigation). You may be able to use these snippets also for other tools (e.g. GreaseMonkey or browser user profile-specific .js files).
This expands the "abbr" tag (containing the relative timestamps):
To remove the imprecise time interpretation completely just (but keeping the JS syntax correct) the the [] part. E.g. this:
Or even have an (unordered) list for the timestamps (biggest visual effect in case of [http://www.openstreetmap.org/changeset/19281117 changeset pages]). Includes an ugly CSS line to overwrite the globally disabled bullets for li objects (list elements) I see no reason why this is done anyway (makes the lists not easy to read in case of line wraps)
* except for [http://www.openstreetmap.org/user/aseerel4c26/history user changeset lists] which contain no content (the content gets loaded via JavaScript after the page has been loaded in the browser). |
Author: woodpeck Thank you for providing this. See also openstreetmap/openstreetmap-website#631 |
Author: aseerel4c26 Replying to [comment:10 woodpeck]: |
Author: osm[at]gravitystorm.co.uk Closing here in favour of openstreetmap/openstreetmap-website#631 |
Reporter: aseerel4c26
[Submitted to the original trac issue database at 4.12pm, Saturday, 30th November 2013]
http://www.openstreetmap.org/user/aseerel4c26/history
Just because one CAN display such vague times there is no MUST to do it, right?
Lost functionality: I cannot use in-page search to find an edit from a specific day.
I do not understand why the interface needs to be changed every two months. We want mappers working on our data not testing how good they are in learning new interfaces, right?
The text was updated successfully, but these errors were encountered: