more-info panel of light(groups) UI/UX

[NovapaX]

I have been looking at (and using) the more-info light panels and I noticed some 'issues'. See image below.

NOTE: This is not about 'getting someone to fix it' but more about getting a discussion started about the UI/UX. I'll be happy to code (some things) myself, but not before there is some consensus on the changes.

[NovapaX]

I would actually switch to a color wheel for the color picker. If possible a programmatically drawn one so it would even be possible to account for the available color spectrum of the lamp. (for example: https://codepen.io/anon/pen/qVXjLN)

[c727]

The color temperatur should be changed to show red on the left and blue on the right

[balloob]

I'm open for improvements. The more info has grown to be a catch all of all functionality added to devices over the years.

The model/serial info etc has already been removed in the next release.

Maybe a good first step would be to just move the history to a new tab in the modal? I like this one from the Material design spec

Not sure how we would approach that by still showing the current entity. Don't see any precedent for it in the spec or any apps I know.

Anyway, I think that redesign approaches should start with mockups, not with code.

[andrey-git]

1. For most of my entities (I don't have complex multi-color lights though) I consider the history to be the most important part of more-info
2. Yeah, too much whitespace, we should decrease that.
3. For turning on/off there is the toggle above. To set low brightness you could drag the slider to a precise position. That said, in my custom UI I allow customization of the slider where the leftmost position is not zero, so you could just click there ;)
4. Yeah, the spectrum selector could be better.
5. I find the concept of attributes at the bottom useful. If some attributes are useless - we should blacklist them.

The downside of tabs is that we take precious (on mobile) space. Maybe we can split into 2 tabs: Info, which is history and attributes. Actions, which are brightness & color controls. However it is not a clear cut, as some things like light color are both actions and info. Maybe (if we go for tabs) such things should be duplicated. I.e. in "Controls" tab we should have a color picker, and in the "Info" tab a small circle with the selected color.

The question is - which tab to open by default. Since @balloob is against customizations - we could remember (on device) which tab was last opened for that specific entity.

[NovapaX]

A little mock up to get started. The tab approach would give some place for future expansion. (device settings or permissions for example?) Tabs would also work nice for more complicated devices, like climate devices, or media players. The scrollable area would be below the tabs, so the current entity / title is always shown.

[c727]

Is color temperature also possible for colored light or only for white?

[NovapaX]

Depends on the lights supported features I guess. I know my Ikea RGB light (via pytradfri) allows both.

[balloob]

Awesome mock ups! Nice touch by adding the logbook to the history tab.

I don't think that it will take too much white space. In fact, it might be actually less since we're going to split more infos into multiple views.

I think that if we remember the last opened tab per entity id, it will satisfies the use case by @andrey-git too.

If there are attributes that are interesting, we should look into what they are and if we can standardize them for the component they belong to.

Tabs are going to open a whole new world.

• Show a mini map for entities that have a location.
• Render custom-ui in a tab
• Allow platform specific tabs ?
• Device details (hass platform, vendor, firmware version - data not stored in the state but in some other place)
• Device settings (Z-Wave?)
• Configure automations / scripts ?

[robbiet480]

Trying to understand what this would look like on mobile, specifically how to get out of the modal assuming that it takes up the entire screen. Also for very tall modals will they be scrollable?

[NovapaX]

• Tall modals are already scrollable
• on mobile a small piece of the backdrop is always visible above the modal where you tap to close it. (see image) On mobile a 'back' or 'close button should be rendered fixed on the bottom of the paper dialog imo. But that is another issue imo. (we can't use the devices default back button/gestures, and tapping that far up is a bit of a pain)

[NovapaX]

I have a functional version (sort of) of those mockups. The color wheel is still very basic, but the drawing and color picking works. I don't like it when the color picker reacts to scroll gestures. Will probably make it so that tapping or clicking the wheel sets that color. And only the marker (to be made) will react to dragging/touchmove. (same applies for the sliders actually)

I also added a dismiss button and made the paper-dialog fixed height on mobile. (that was kind of required for scrolling to work nice)

https://github.com/NovapaX/home-assistant-polymer/tree/mockup ^ this is my messy testy branch, where I merged different feature branches, so don't rely on it to work very well.

[balloob]

The back button totally works on mobile. Spend a lot of time on that one 😏

Instead of doing the empty space as we do now, I suggest we just render a toolbar with a back button on mobile, like the subpages in the config. That way people will think it's just a full screen page on mobile

[NovapaX]

The back button indeed works in the browser. My mistake. The problem is then that the back button is not shown in the app.

I actually like how it is still a modal on mobile, but indeed it is vertical space wasted. And the background showing on that small strip is a bit confusing indeed.

I think we should be placing important navigation and controls in the 'thumb-area' on mobile. So they can be easily reached one-handed. This is typically the app you use on the go, while you don't really have your both hands free.

[balloob]

Well Android has the back button. I prefer to follow the material design guidelines.

[NovapaX]

TRue. Then the iOS app should probably also just display a back button bottom left. (Where iOS safari has it too)

[balloob]

Yeah I don't mind tweaking the design slightly to accommodate iOS users. Although I guess Safari has the swipe from the right to go back?

[balloob]

btw when we implement such a thing, we should break it down in many small PRs. I don't want a single PR with all the changes.

PRs for:

• Showing more info and history in tabs. Hide tab bar if no history loaded.
• Add logbook to history tab
• Update the color picker
• Add a toolbar to the modal

[NovapaX]

The swipe works indeed in the browser. (I guess I've just been using the app so far) And that would work even better if we'd move from dialog to full screen. Way easier to layout too. It's just the iOS app that lacks a bit refinement on the 'go back' part currently. But that should get solved in the app, not in the hass-frontend imo.

I have indeed split those up. The (rough) work I've done so far on the color picker and the tabs is in separate branches. (hence the 'mockup' branche where I merged the two to get a feel of how it would work together.) I know you like your PR's small 😉

[NovapaX]

I've pushed some updates to the combined branch. The color wheel got quite a lot of usability improvements.

• added a marker.
• Did quite some work on getting the touch events not interfere with scrolling.
• You now can drag the marker, or tap anywhere on the wheel to set the color.
• with mouse you can just click and drag anywhere.
• shows a 'tooltip' when dragging the marker on touch devices. (so your finger isn't blocking your view)

That color wheel is almost ready for a PR.

couple of questions still:

• should I make it into a different element, like ha-color-wheel, or just replace the ha-color-picker?
• should the select-color event trigger while dragging or just when finished? That way we also don't need to throttle it. (It could also be a property, or only when you pause for a 0.5 second while dragging it will send the trigger.)

any suggestions always welcome.

[balloob]

I like that right now you are able to drag with your finger over the color picker and the light changes as you go.

I'm fine with killing the old color picker.

[NovapaX]

Agree. I’ll just let it fire the color picked event. The more-info panel (or wherever it will be used) must take care of throttling if needed. (The more-info-light already does this.)

[uchagani]

If we're thinking about tabs, could we add a tab for pre-selected themes that users can save? something like this:

[cgarwood]

Closing since the accompanying PR went stale and was closed.