Refined covers more info dialog

[mkerstner]

What this is

A concept for an improved more info screen for covers targeting multiple variations and aiming for a consistent UX.

Each cover type gets its own illustration set against a window of daylight, so the control maps to reality instead of one upside-down slider.

Further options to tweak the visualization further but keeping them to a minimum.

More info about this opportunity can be found on this roadmap item OpenHomeFoundation/roadmap#33.

Try prototype

Key design decisions

• One illustration per device class
• Clear and consistent animations for all variations

What to poke at

• Does the structure clearly map the purpose?
• Grab + sliders or just one option?
• Do we miss something?

[No-DNS]

add option to use own images for doors/windows?

[mkerstner]

Good point and yes was thinking about that one initially as well - but kept it out of scope tbh.

Regardless, prototype is updated and offers option to select a background image - either from a pre-defined selection or upload a custom one to fully personalize the view. The previous option to just have day- and night-mode as background is still available by not setting a background image and using the "Warm daylight" toggle.

Curious on your thoughts.

[mkerstner]

Update

We have expanded the prototype to cover all cover types (pun intended) available by the cover integration (https://www.home-assistant.io/integrations/cover/)

Going into this direction we'd aim to have consistent animations and behavior for all types.

As always, please provide your feedback. Thanks!

[jlpouffier]

Awning feel a bit weird (This one)

Maybe going 3D would be better.
Showing it like so basically

[mkerstner]

Could be an option.
The main idea for this first iteration was to have coherent visualization albeit potentially being simplified.
As there are multiple different types of awnings as well.

[jlpouffier]

That interaction (up and down drag) feels weird for some device classes

[mkerstner]

That's improved in the lastest prototype, feedback is welcome thanks

[oerix]

Great work on the new UI! However, regarding the bottom sheets on mobile, it feels like a step backward for UX, especially with the new cover screens and larger buttons. We are limiting ourselves using this method.

They don't really work well for 'complex' controls:

• Shifting layout: The sheet resizes based on content, moving the close button and ruining muscle memory.
• Too much scrolling: Cutting off the top forces vertical scrolling on things that should fit on one screen.
• Feels claustrophobic: Shoving extra sub screens and giant buttons into a tiny sheet means extra tapping and scrolling.
• Wasted space: It cramps content vertically while leaving empty gaps on the sides.
• Poor UX: Other smart home ecosystems use the full width of the screen as it is better UX overall for mobile devices.

Why not just use the full screen with a simple close button? It felt much more practical before this change. If the concern is reachability, we can always just shift the controls lower on a full screen window rather than cutting off the top of the viewport entirely.

[mkerstner]

Thanks for the feedback!

What about making these bottom sheet options optional and rely more on the dragging?

There's a new version of the prototype available where you can chose what variant you prefer - with or without those options shown. Tilting for now would remain as a slider. Something we can discuss further if needed.

Essentially, by providing the option to hide these interaction elements full focus would be on the draggable interaction element itself and using the full space available for it.

It will now show in a reduced version by default - focusing on the draggable interaction element.

About the button size - for sure we can refine them as this is not a final design.

Curious about your thoughts.

[oerix]

My main concern is still the bottom sheet pattern on mobile, not just how many UI elements are inside it. Even in the reduced version, the changing sheet height and partial viewport still cause some of the issues mentioned before (layout shift, extra scrolling, and a cramped feeling).

Draggable bottom sheets also work best when the initial height is consistent across all device types, similar to how Google Maps always opens its place sheet at the same level before you drag it further. In the current demo, each device type appears to start at a different height with a different amount of content visible, which makes the interaction less predictable.

For these more complex cover controls, a full screen view with a simple close button still seems like the more robust option, as it avoids these height and consistency issues and provides a more stable layout on mobile.

[mkerstner]

Agreed.

The initial focus was primarily on the interactive element and the animations, not so much on the remainder parts.
There was another round of polishing the demo around these aspects reflecting the existing layout more.

Tilting I believe needs another loop as also @AlCalzone mentioned.

[AlCalzone]

Just so I understand this correctly - this project is only about redesigning the dialog, right?

Because I have blinds where open is the middle state, with two different closing directions (inside up, outside up) at the 0 and 100% states respectively.

[mkerstner]

Yes, it's aiming to provide a consistent UX across this dialog given the variations of covers available.

Because I have blinds where open is the middle state, with two different closing directions (inside up, outside up) at the 0 and 100% states respectively.

Maybe I don't get that one but you are not talking about the combined top-down variant by any chance?

[AlCalzone]

No, I meant this (which I later found all the way at the bottom, but not in the hero section):

Screencast.From.2026-07-08.18-21-22.mp4

This is how tilt is defined in Z-Wave, btw. - Our tilt controls today do not map cleanly to Z-Wave. This version in the video would be a better fit.

[mkerstner]

Ah I see, it's about the tilt control. We can of course have a more dedicated look at the tilt controls.
I've kept it as a slider for now to keep it simple. Let's maybe wait for further feedback on tilting control before
taking a next step.

[mkerstner]

There's a further exploration on tilting in section 4a-c as a starter.

[AlCalzone]

The slider (A) feels significantly more direct and fluid to use

[AlCalzone]

It feels like the handle and shade should have their roles reversed.

Screencast.From.2026-07-08.15-48-21.mp4

At first glance I would expect the shade rendering should show the actual state, while the handlebar should show the desired state that the shade "catches up" with.

[AlCalzone]

I would say it feels better. It doesn't work on all hero examples though. The top-down one is just broken, and the curtain still uses the old behavior.

I'm missing some immediate feedback though that can tell me whether the device has started doing what I told it. Or that HA has accepted my command at least.

[mkerstner]

What do you mean by top-down is broken? The fact that only dragging it as a whole words rather than separately top and bottom rail?

Curtain - you're right the catch-up animation seems to be not reflected there.

Regarding the immediate feedback - that would be the "bar" being set to the respective target position and the rest catching up to it. What do you have in mind?

[AlCalzone]

The fact that only dragging it as a whole words rather than separately top and bottom rail?

This. Feels unexpected.

Also it looks like I'm only grabbing the "folds" of the sheet, rather than the handles:

Screencast.From.2026-07-09.13-36-41.mp4

Regarding the immediate feedback [...] What do you have in mind?

I'm not certain, I'm going off gut feeling here. Maybe something visual that indicates the motor moving.
The live version in HA currently changes the status text (on supporting covers) to "closing" / "opening".

[mkerstner]

Yes, agreed.

There's a new version of the demo available that improved this behavior, also focusing on the interaction element primarily and hiding the top-down rail sliders to be coherent with the other types.

Concerning the immediate feedback there essentially are 2 options available now:

1. Use the catch-up animation to set the target position and the fabric/gate/etc. catches up displaying the progress along the way (like it's showing now)
2. Don't use the catch-up animation but still have the progress update displayed like now

[AlCalzone]

This feels better to me. Only one minor bug: Some of the status display seems to be derived from the target state, not the current state.

Screencast.From.2026-07-09.14-34-17.mp4

[rovo89]

I like that the More Info dialogs are getting more than realistic 😊

One bug in the prototype, the cover sometimes doesn't go all the way to the bottom, also seen for 50%:

That said, the picture isn't really accurate for the actual situation in our house (Germany). Our shades reach the bottom at ~20% open (differs a bit based on window size), but they still have those little gaps between the slats. As it hits the bottom, these gaps close from the bottom up until they're all closed at 0% open. Therefore, showing 20% open as an uncovered area at the bottom of the window is actually wrong and confusing for us.

We're using that "breakpoint" a lot (complete window covered, all gaps open, we call it "auf Schlitz") since it it lets the air circulate a bit. Our shades started to bend and the house manufacturer told us was our fault because we completely closed the shades in hot sun - the temperature difference between inside and outside puts much stress on the shade material.

That's actually one of the main reasons why I still keep an instance of ioBroker in parallel which can also access the Shelly: It has actions to move the shades to the four favorite positions that you can define in the Shelly firmware (via web or API), and it has sensors to retrieve the position % for each of them. So for each window (we have 19), I manually drove the shades to that position and saved it as favorite 1. I think I could even name it "Schlitz" in the Shelly. And now I could use that in automation to drive all shades to their individual favorite 1 position. I built a custom UI with react (I think even based on @AlCalzone's work) which mapped not only 0% to "open" and 100% to "closed", but also each window's individual favorite 1 position to "Schlitz" (using icons for each, plus the percentage if somewhere in between).

I'm not sure how common this behavior of shades is, but it was this way in Germany before shades had motors, and honestly I can't imagine how they could work/roll up without the gaps between them.

Not sure if you can and want to support that, just wanted to leave my feedback here. Apart from the inaccurate animation, my previous approach would benefit from named favorites (single one in my case), but also the actions to move to a favorite by number, not percentage, and then of course buttons to do that from the dashboard and cover groups, and recognize the special percentages when it comes to displaying the state there.

By the way, does the frontend have any support for "hooks" to partly modify and extend it? In my past, I developed an Android framework called "Xposed" which let you do that for any app, and that was great because even niche needs could be fulfilled with the right "plugin" that redirected a certain method call to its own code.

[AlCalzone]

Second the favorites approach. I can't see myself moving shutters to 25/50/75 % just for the numbers, but rather for a goal that accomplishes: almost closed (like @rovo89 outlined), closed to a point where the sun is blocked but light still gets in, etc.
Those are likely ugly numbers compared to the prototype, but far more useful.

[rovo89]

I started several times to reply, but each time I got side-tracked 😅

The ideas for the favorites all share the issue that I mentioned above: For our shades, down doesn't necessarily mean 0% open, in fact my shades are between 18% and 27% when they reach the bottom, and then the gaps start to close from the bottom up. A visualization has a chance of considering that if it knows the percentage with "down, but all gaps still open", but I can't imagine a way how this could work for an interactive control alongside the cover visualization. And tbh, I'm not even asking for that. I'm totally fine with buttons, would just want a name for the favorites (plus the things outside of the more info dialog, such as recognizing and displaying when a shade is currently in its favorite position, being able to move several shades to their individual favorite positions,...)

[No-DNS]

maybe add option to add the time in seconds for opening and closing each roller/shutter/whatever, use build-in percentage then. ?

[mkerstner]

So, having custom favorite % values could solve your case @rovo89 @AlCalzone , right?

I like the idea of having optional custom favorites (name, value) - but would potentially see that as a second step regarding further optimizing the visualization aspect (while being a real one of course).

Also, I'd like to refrain from introducing new concepts (e.g. adding timing options) to solve potential visualization issues. The overall aim of this opportunity is to leverage current visualization in a coherent form, well knowing that we might need to further optimze along the way.

[rovo89]

There are many aspects mentioned here.

First, regarding the timing - that's what Shelly already does internally. If you want to drive from closed to 20% open, it knows how many seconds to enable the "open" relay. And if you open via physical switch, it translates seconds to percentage.

To make the visualization reflect the reality better, I think the only thing needed would be the definition of a "reaches bottom at x%" or "ventilation position". If that is >0%, the animation could show little horizontal gaps between the slats, which close when that position is reached.

Named favorites - in my opinion, that makes much more sense than raw percentage numbers. If we had a way to define the ventilation position, that would be one favorite already, and it would probably be all I need for my case. For all the favorites, I think named buttons to trigger them would be totally fine. I see the design challenge though that they would need an unknown amount of space, depending on how many favorites are defined and how long the names are.

But favorites (including the ventilation position) in general reach far beyond the "more info" dialog. I rarely go into that dialog to control a single shutter. I have 19 of them, so I control them from the dashboard, via automations and via groups. It would be fantastic if favorites were available there - an additional icon button next to close/stop/open in the dashboard, an action to drive a shutter to a named favorite (so there's a single definition instead of hardcoding 23% into every automation), the ability to drive a group of covers to a favorite position (if all of them have a favorite with the same name). And for displaying, detect when a cover (or a group) is at a favorite position and show a special icon in the dashboard.

Probably this discussion focuses only on the first aspect. But the others can only be realized in core, so if you could forward it to a more appropriate place, that would be great.

[mkerstner]

Update: We've slightly optimized the prototype based on further feedback:

1. Tilt-only version is now also available in the interactive hero
2. Added first ideation on how favorites could be surfaced and interacted with - feedback is welcome!

[AlCalzone]

Re 1) I understand the more info implementation mirrors how it works today where 0 is closed and 100 is open, but this directly contradicts how this section models tilt:

Re 2) IMO the proposals all work for nicely spaced favorites, but what if the favorites are close together? For example something like 2% for venting and 7% to use a mobile A/C unit? I can see the visuals getting cramped.
How about reusing these buttons as favorites?

[sassy-lily]

I'm with @jlpouffier in saying the awning commands are "wrong".

For external awnings (e.g. https://www.somfysystems.com/en-us/products/awnings-screens-pergolas/motorized-awnings) what "open" usually means is the awnings is extended, and "closed" means the awning is retracted.

Currently the prototype works the opposite way: clicking the "close" button extends the awning, shows a "closing" operation, with an "extended" status at the end, and an extended awning; clicking the "open" button retracts the awning, shows an "opening" operation, with a "retracted" status at the end, and a retracted awning.

[mkerstner]

Thanks for the feedback @sassy-lily

That was fixed in the updated demo. Feel free to check it out.

[Misiu]

I use exterior roller shutters at home, which are very common in Poland and other parts of Europe.

The current Roller shutter illustration looks quite similar to the Venetian blind because of the visible gaps between the slats. In a typical exterior roller shutter, the horizontal slats are connected and form an almost solid surface when lowered.

I think showing the slats closer together, with only thin horizontal lines between them, would make the illustration much easier to recognize and also distinguish it better from Venetian.

I’m attaching a photo of roller shutters as a real-world reference.

[mkerstner]

Thanks @Misiu - good and valid point.

We've updated the demo for shutters reflecting that better in the animation used. Feel free to check it out.

There is also a further exploration section further down in the demo to get more context on the ideas / options tried.