search

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

Move crawling error icon to the top #49

Closed m-mohr closed 4 years ago

m-mohr commented 4 years ago

I think this is a "problem" that was not considered when restructuring the discover section to include multiple versions under a single endpoint header. The "icon" that indicates a crawling error is only shown once expanded, but in this case there's already the red text with the full information shown. Therefore it seems more valuable to move the icon one level up and make it either:

  1. a "summary", so if any version was not crawlable show this icon.
  2. only show the information if the most recent production version was not crawlable.

The second option has the advantage that it doesn't show a misleading error if a legacy version is shut down. Or how does the Hub handle if a version gets removed from the well known discovery? Does it (a) stay on the Hub or (b) gets removed, too? In general, I'd prefer if it does B, but that's not the issue here. If it's A, I guess we should implement option 2. If it's B, implement option 1.

image

christophfriedrich commented 4 years ago

Yep you're right, this wasn't thought about when restructuring the Discover section (and I didn't identify it as an issue so far, but you're right, the value of the icon isn't very high when it's only shown once the explanatory text is visible anyway).

how does the Hub handle if a version gets removed from the well known discovery? Does it (a) stay on the Hub or (b) gets removed, too?

The Hub does a mixture of both: For the time being it stays on the Hub, but after failing to crawl it for X times it's removed. That X can be set in the config with the unsuccessfulCrawls.deleteAfter option. See also section 5.6.3 of my thesis :nerd_face: :wink:

BTW back in the day when this was implemented we didn't have well-known discovery yet.

If it's A, I guess we should implement option 2. If it's B, implement option 1.

I would like to propose an option 3: How about moving that icon into the tab pill? Example screenshot:

image

m-mohr commented 4 years ago

Moving to the pill is good.

Regarding unsuccessfulCrawls.deleteAfter: See the new issue #52

christophfriedrich commented 4 years ago

I was starting to do that, but struck an issue: The pill's title is passed via the Tab component's name attribute, which must be a string (see docs). I guess I could pass the HTML for the warning sign there, but I wouldn't find that to be very nice. Especially not when compared to the current way of generating that icon (see BackendName.vue).

Do it anyway? Or choose option 1 or 2 instead? Or stay with option 3 and refactor the Tab component so that it's possible to specify its name via a slot?

m-mohr commented 4 years ago

For now, you could simply pass the unicode sign ⚠️ without explanation and wait for upstream changes in the tab component. I don't think you can pass HTML to the component.