Our users sometimes mistakenly create invalid/unsupported layouts. Example: a layout with only a background and nothing else.
I honestly thought you brought up valid points.
Well, by default every layout starts from scratch, until you edit it and schedule that layout.
To me, it makes sense that the CMS allows you to create a scratch layout so that you can continue your edits later.
However, if you are talking about the CMS allowing scheduling of this layout said to be “invalid” (with no content/invalid regions) i don’t even know how to explain why 
It’s worth a search in the community.
Hi @Natasha, I hope you’re doing well!
Could you clarify this point for us? I didn’t know how to answer this 
I disagree with this one…
I don’t think a layout with only a backgroud is valid.
If you placed a full screen image within a region (instead of using backgroud) it would already solve your problem.
The background is just a background. I don’t think it should be understood as “valid” content in itself.
Yeah, it basically allows users to try to schedule stuff that cannot be scheduled. And then we (in IT) get calls saying Xibo isn’t working correctly.
Why not? It would just show an image. We have so many users who think, “Oh, I just want to show an image, so I can just use a background and don’t need any content.” So it’s apparent that it’s natural human inclination to do so, since we get this request so often. Why not just comply and let the user publish a background image? What is the harm?
I am aware that using a full-screen image is a workaround, but I see no reason not to let users just publish it without content (without it being considered “invalid”). We have to repeatedly show users that blank layouts won’t work, so users obviously expect this to function as-is.
We used to prevent publishing an invalid layout, but ended up reverting that change after lots of user feedback. The popular opinion, which does make sense, is that you might want to publish and schedule an invalid layout, on the understanding that it won’t be shown but might be later. For example you might have an empty playlist on the layout which will be populated at a later date, or you might want to do a lot of scheduling in advance, without having the content produced yet.
I think it would be nice to allow a background only layout, and automatically convert that on the Display so that it acts the same as if you’d added the background image via a widget. The reason we have not done this is duration - as a “background only layout” we do not know how long the layout should occupy in the schedule loop.
Perhaps we could popup and ask them for a duration when they publish?
Would these users be better off scheduling from the Library page and skipping the Layout Editor entirely?
I’ve never understood this concept in Xibo. If nothing else is scheduled to a player, it should never have to refresh the layout in the first place until it receives an update message over XMR. I would say over 25% of our players are just Digital Building Directories and there is no need to reload the layout every 60s or whatever the default might be. This limitation completely ruins widgets such as the Clock, Weather and Ticker, as they can take up to a second to appear on a layout refresh.
All users have ever want is a simple way to add a background image and razor crisp text without the player reloading itself or crashing every couple of hours.
The most common use case we see by far is showing more than one thing in a loop, in which case you need to know how long to show each of those things.
There is a case to be made for not refreshing a layout if it is the only thing in the schedule loop; the thing holding us back there is making sure there is a mechanism to ensure that data widgets are kept fresh (you don’t want out of date weather information or news for example).
We have made some advances in this area recently, with v4.0 separating the delivery and rendering of data, which paves the way for that data to be updated independently of the widget loading.
This gives us the capability to do what you suggest, and keep a loop of 1 on screen without reloading.