"browse history" page missing structure, thus hard to read #187

tyrasd opened this Issue Jan 16, 2013 · 12 comments


None yet

7 participants

tyrasd commented Jan 16, 2013

The object history page is currently quite hard to read, as the different versions of the object are just concatenated after each other without any kind of separating element in between (previously there was a horizontal line and some extra whitespace).

Compare: old vs. new

It would be nice to nice to have some structure in this page... maybe by adding the version number as a header in front of each version.

richlv commented Jan 18, 2013

it would also be great to reduce vertical spacing between "Edited at:", "Edited by:" and other lines in that block.
vertical spacing between tags also has increased, would be better to use same spacing as before.

in the example posted above, previously 3 revisions could be displayed in the same vertical space what is now used by two revisions only - much harder to check object history

tyrasd commented Jan 18, 2013

I don't think that the too-large vertical spacing is the real problem here. In my eyes, the old layout (with its almost zero spacings) was also quite hard to read. Good typography uses whitespace to help the user reading the page (but its not so easy to get it right).

I think the history page probably didn't get much love while developing the new layout, as it does whitespacing "wrong" (IMHO) on a number of spots:

  • as already mentioned: no separating structure between the individual elements (=versions of objects)
  • huge amount of unused whitespace below the mini-map right of the "details-table".
  • the left column of the "details-table" uses a variable width (~1/6 of screen width) which can introduce a large amount of horizontal whitespace between the text in the two columns. This makes it very hard to read on wide screens. Better using a fixed (em-based) width left column and letting the right column use the rest (incl. the whitespace below the mini-map).
  • the "details-table" uses a mixture of whitespace and horizontal lines to separate its lines from each other. "Good" typography very seldom uses horizontal lines (apart from separating header/footer from body), as those do only distract the user from the content. Instead, some vertical whitespace is used to guide the reader through the lines of the table. IMHO, the current amount of vertical whitespace is enough to provide a good table layout, so no vertical lines are needed (an could thus be used for separating the individual object versions).

current object history page: osm-historybrowser-current

better object history page: osm-historybrowser-better

Note that I'm not a typography expert, but those are glitches that I can identify even as a layman. Maybe @samanpwbb can give us some input here?

richlv commented Jan 18, 2013

excess vertical whitespace is a problem because history page is used to review history - the less we can see on the page, the more scrolling and remembering we have to do -> hard :)

tyrasd commented Jan 18, 2013

Thats probably another issue here. The current "two-column one-version-after-each-other long-table" layout is probably not the best solution for "reviewing history" after all. Other issues (which cannot be solved by just making the whitespace disappear): Why is the mini-map only showing the newest geometry of the object? Ways with long node-lists do require much scrolling even when the font size is small! Why aren't the actual changes between versions highlighted? When the node list of a way doesn't change between two versions, why printing then twice? etc.

There are (attempts of a) solution for these issues: See http://osm.mapki.com/history/node.php?id=30361827

But this is another issue than the missing structure in the current layout (I updated the issue title to better reflect this), and we probably should open another issue?

richlv commented Jan 18, 2013

absolutely, highlighted diffs etc should not be mixed in here - this is mostly about comparing previous layout with the new one, and concentrating on readability/compactness of them


At the risk of stating the obvious, don't spend too much/any time fretting about the layout of the history page, as it'll be completely replaced when (hopefully soon) Pawel's new OWL-powered panel goes live.


Err, this is about the object history views @systemed, not the changeset history view...

That said, there is a slightly excessive amount of bike shedding here...


/me wakes up. Blame staying up until 3.30am watching Lance Armstrong ;)

richlv commented Jan 18, 2013

bikeshedding is inevitable when there are minor usability regressions


This is happening because styles meant for the normal node page are being duplicated and I didn't check to see how that'd look. Turns out it's confusing.

Rather than create special styles to override the main node page, Lets try to hold onto to the existing styles and just create a stronger separation. I feel like the best way to fix the problem is to add a heading that says something like: "edit #x" at the top of each repeated revision block, with a stronger break (either a darker keyline or just more space - a larger font alone might do the trick).

I'll take a look at it next week.


+1 this definitely needs a little attention. Guess samanpwbb's ideas will work although a little less spacing would probably increase usability - this is essentially a tabular display where usability is strongly influenced by how quickly you can find what you are looking for; most people will want to compare something to an earlier version and the more you have to scroll up and down for that the less useful it is.

pnorman commented Dec 2, 2013

The redesign has completely changed the object history page, and there is reasonable separation between objects now.

@tomhughes tomhughes closed this Dec 2, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment