Open-EO / openeo-hub

Source code for openEO Hub, a centralized platform to explore openEO back-end providers.
https://hub.openeo.org
Apache License 2.0
8 stars 3 forks source link

More space for file formats and service types. #62

Closed m-mohr closed 4 years ago

m-mohr commented 4 years ago

The next release of the Vue components for file formats and service types will show some more information (e.g. titles and for file formats the GIS data types). This needs a bit more space and thus I'd recommend to change the three column view into two columns.

m-mohr commented 4 years ago

Also note that the "Supported" in the component name has been dropped.

christophfriedrich commented 4 years ago

Thanks for the heads-up, very convenient to be notified by the developer himself about changes in one's dependencies :D

This is what it looks like in the Hub with no changes:

grafik

:/

When I remove the columns it's okay:

grafik

So I'll probably have to do that.

Where's the point of something like "PNG - PNG"?!

m-mohr commented 4 years ago

Hmm, why does it look so strange in multi-column layout? Is it due to flexbox or so? I thought we could still go with at least two columns, but it seems one of the sides would need some more CSS tweaks.

The bold text is the actual name to be used in process graphs, the normal text is the title a back-end can assign. I'm not 100% sure whether I should actually should show both or just the title (and the name as fallback).

christophfriedrich commented 4 years ago

why does it look so strange

I wondered about that too and only understood it at the second look: It's because the JSON's <li> is broken across two columns -- in the screenshot you see 4 columns.

I tried to tell the browser to stop that by applying break-inside: avoid but it didn't change anything :(

:bulb: after two minutes of research: Seems like it would've worked if I wouldn't use Firefox: https://stackoverflow.com/questions/7785374/how-to-prevent-column-break-within-an-element But I don't really like any of the workarounds there.

Everything's okay if the column width is increased so that every item fits into a single line. On my screen 20em works fine for this use case. So either that or just drop the columns.


How about not displaying the title if it is identical to the name? The JPG example in the screenshot is okay, but the PNG one is just confusing rather than enlightening.

m-mohr commented 4 years ago

💡 after two minutes of research: Seems like it would've worked if I wouldn't use Firefox: https://stackoverflow.com/questions/7785374/how-to-prevent-column-break-within-an-element But I don't really like any of the workarounds there.

Interesting, that's some new fancy CSS stuff...

Everything's okay if the column width is increased so that every item fits into a single line. On my screen 20em works fine for this use case. So either that or just drop the columns.

The question is whether there are cases that exceed 20em? Then it would break again, right? I guess it could also work okay if you remove the columns. Except for R, there's never more than 10 file formats or so at the moment so a 1 column list should be fine for now.

How about not displaying the title if it is identical to the name? The JPG example in the screenshot is okay, but the PNG one is just confusing rather than enlightening.

True, but simply doing name === title wouldn't properly work if the name is lower-case and the title upper-case, for example. So better would probably be localeCompare. I'm also thinking about removing the name completely. In theory the user doesn't really need it, I think.

christophfriedrich commented 4 years ago

The question is whether there are cases that exceed 20em? Then it would break again, right?

Yes. So I'll go for no columns -- it's easier and doesn't really have a downside.

True, but simply doing name === title wouldn't properly work if the name is lower-case and the title upper-case, for example. So better would probably be localeCompare. I'm also thinking about removing the name completely. In theory the user doesn't really need it, I think.

The nice thing about the names is that they are identical across backends. I'd go for the case-insensitive equality check.