Capability: display useful error messages from server / graceful fallback

[AmeliaBR]

From some musings over our own broken examples…

Me:

Sigh… the worst part is knowing that authentication issues for accessing proprietary data are one thing we can't ever expect to 100% standardize away. Keeping map data up to date will always cost money & that means companies want to get paid.

@Malvoz's reply:

Agreed, but I definitely think there are benefits in standardization, for one thing, Map API keys issue could perhaps utilize the Reporting API, making it easier for developers to retrieve notifications. Or how things should behave on the client when an API key has expired, for example Bings Maps API is displaying some information, although developer-oriented (fails due to localhost in this instance):

where other map tools would just cease to function silently:

I can think of a couple things that could be integrated into the browser widget to improve situations:

1. Have a way to indicate to users that content specified by the website author failed to load. Like the broken image icon, at least. Need to consider how this should look, especially with tiles and layers — don't want broken-image icons all over!

2. Maybe, have a way to display a text error message from the server to users (like the Bing maps screenshot above). Not sure about this, or whether that belongs better in the console.

3. Have a way to fallback to a different source, whether that's a default map layer (re Capability: Default map provider #8), an author-specified fallback. Or at least indicate whether a missing layer should be replaced by something opaque like basic graticule lines, so that overlays could still make some sense.

[prushforth]

1. Have a way to indicate to users that content specified by the website author failed to load. Like the broken image icon, at least. Need to consider how this should look, especially with tiles and layers — don't want broken-image icons all over!

What about disabling the layer in the layer control or something like that. It would be good to have a way of flagging the fact that the layer is broken non-visually as well.

2. Maybe, have a way to display a text error message from the server to users (like the Bing maps screenshot above). Not sure about this, or whether that belongs better in the console.

Tricky, usually the console will have HTTP errors, but I can't think of having seen browser messages there. They could be quite informative to authors though.

3. Have a way to fallback to a different source, whether that's a default map layer (re Capability: Default map provider #8), an author-specified fallback. Or at least indicate whether a missing layer should be replaced by something opaque like basic graticule lines, so that overlays could still make some sense.

In the <layer-> element currently allows and prefers the @src attribute, but I was wondering what you all might think about falling back to the content of the <layer->...</layer-> if present? Currently I don't do anything with content if the @src element is present, IIRC. But, I also currently don't do anything if the document referred to by @src fails in some way.