Improve Wikidata field formatting

[nyurik]

I propose we improve the format of the Wikibase field. Several variants (with HTML):

<li class="preset-wikidata" style="display: flex;">
   <div class="tag-wikidata-body" style="max-height: 200px; opacity: 1">
      <p class="tag-wikidata-label" style="font-weight: bold; padding-left: 0.6em; padding-top: 0.3em">New York City</p>
      <p class="tag-wikidata-description" style="font-style:italic; padding-left: 0.6em; padding-bottom:0.3em">city in state of New York, largest city in the United States by population</p>
   </div>
</li>

<li class="preset-wikidata" style="display: flex;">
   <div class="tag-wikidata-body" style="max-height: 200px; opacity: 1">
      <img class="tag-reference-wiki-image" src="https://upload.wikimedia.org/wikipedia/commons/thumb/b/bb/NYC_Montage_2011.jpg/100px-NYC_Montage_2011.jpg" style="margin-left:1em">
      <p class="tag-wikidata-label" style="font-weight: bold; padding-left: 0.6em; padding-top: 0.3em">New York City</p>
      <p class="tag-wikidata-description" style="font-style:italic; padding-left: 0.6em; padding-bottom:0.3em">city in state of New York, largest city in the United States by population</p>
   </div>
</li>

Notes:

• Use format similar to the field description - regular text without any extras like the input box or the very weird looking "block" icon (I know it is cool, but it gets in the way of regular usage).
• No "copy" icon - we know how to copy part of website's text :)
• No label/description on the left - no point, takes up a lot of space, not clean
• CSS styling above are a bit hacky (used chrome dev tools), and might need to be adjusted

P.S. For even cleaner implementation, I would actually advise removing the extra line all together for these cases - makes interface much more compact while still being clean and functional. This would work only in cases when the tag value is known to be narrow, e.g. Wikidata ID:

cc: @bhousel @quincylvania

[1ec5]

See #5544 for additional improvements to the layout that would accommodate autocompletion.

[bhousel]

#4382 really contains my thoughts on this.. I'm in favor of making the field nicer, but I really want it to serve a purpose that's more than just "showing the user stuff from Wikidata".

If we could define properties in Wikidata worth looking up, and give the user a simple way to copy that data over to the appropriate OSM tags (population, artist, date_created, material, etc) then the field would be good for more than just looking at things in Wikidata.

Put another way, we should always ask ourselves "How does this feature help users edit OSM?".

[1ec5]

@bhousel, if I’m not mistaken, you’re reacting to the inclusion of the image from Wikidata, correct? I agree that we don’t necessarily want this field to scope-creep into a full-fledged Wikidata viewer.

To me, displaying an image in this field would be distracting most of the time. Consider that the field is displayed even for features that the user has only hovered over or selected but hasn’t edited. The rationale for showing the image would be to help the user better differentiate between similarly labeled Wikidata items, so why not show it only at the moment when the user is trying to choose a Wikidata item? #5544 would introduce an autocomplete popup. That popup would be a more appropriate place for images, if desired. UIs that autocomplete Wikipedia article titles (such as the search bar at wikipedia.org) often do display an image.

I think an image in the autocomplete popup would help mappers who aren’t as familiar with Wikipedia and Wikidata naming conventions. We don’t want people putting in disambiguation pages, after all: #4414.

#5544 would probably necessitate some of the other reshuffling that @nyurik suggests, since we’d make it so that the label is what the user interacts with, rather than the QID.