I am tinkering on a logic for a model to build an intuitive-as-it-can-be control interface for WLED based lamps. My goal is to use a single push-button wheel (the thing a mouse has) to create a highly accessible and easy to understand interface that neither lacks in (necessary) options nor is too complicated to be controlled by our grandparents.
If we can build an interface that suffices Usability and UX requirements with such a minimal UI where input is limited to a push-button and output (feedback) is nearly non existent, then we can extend it with additional input (buttons, interfaces etc) and output (information, feedback etc) options.
As a rule of thumb, the more and the better the feedback, the easier it is to build a good and easy to understand UI. But I want to take advantage of a minimal (or even non-) feedback interface. But lets take a look at possible feedback types here:
On state change
–> you push a button, sth. Happens. Most common form. Works fine for command executing, but not for moving within a hidden menu
(Preview) LEDs (Single/Set/Ring of ws2812b LEDs)
–> Even a single RGB LED (or even a single color LED) can be a great source of information. They could be an index for the actual menu location, and with only a few LEDs most of the effects could be outputted adequately before you chose one to apply.
The lighting LEDs themselves
–> Parts of the strip or (as in mine case) the matrix function as a „screen“. This would be a great resource for a menu, but as a downside depending on the diffuser you use it can be quite fuzzy and would probably require some tinkering to harmonize it for different matrices, strips and other forms. Could work as color and effect preview, but hardly for indexing menu locations.
A dedicated display
–> Would be the most straight forward option, and there are already one or some usermods taking advantage of this with an ESP by TTGO. But besides the additional costs (not important for one light, but for the production of a series) it limits the design of a generic controller (that development is also an important part of my work) pretty much (e.g. having an 2,5 cm wide TTGO ESP with a display built in would exceed the aimed 2 cm height of the controller box). Another disadvantage is the additional power consumption, as the first prototype I want to get in MVP status is a mobile light running on an internal battery or a common powerbank)
I havent thought it through yet, but a simple buzzer could also be used as a part of menu navigation/orientation or state-change-feedback. The crux here would lay in finding a matching code (i.e. what beep means what) that wont lead to irritation instead of making things clearer.
Control Use-Cases: State-Change vs. Search vs. Play
To better understand what a Light UI is used for, it can be helpful to refine the reasons why it is used.
The most common type. There is a defined goal someone is trying to achieve: Increasing brightness, Choosing an effect, decreasing effect speed and so on. As no one wants to cycle through dozens (or hundreds) of options there should be a short pathway to reach everything within a couple of clicks. It may be tempting to subdivide everything into a branching tree structure, but even with a clear navigational feedback (knowing at what menu point one currently is) it requires classificational conditions like exhaustion and disjunction (or selectivity in simpler words). Every effect has a brightness level, but only most effects have an effect speed (not the static ones). All effects have a color (in some kind), but some have a single color, some have two colors, some have color palettes. This to dissolve isnt trivial, the biggest „chaos“ indeed is caused by the „Intensity“ parameter. Some examples what it can mean: Nothing, Smoothness, Duration, Number, Pastel/Saturated colors, size, Wavelength, width, fade rate, density, frequency, speed… This is a UI/UX designers nemesis :-X
Some of you may think here „so what?“ To be in control of something implies to know what parameter one is actual changing/manipulating before(!) doing this (keyword: conformity to expectations) This can either be reached by clear information (e.g. on a display) or by a mental model in the users head that fits the actual UI logic. But to reach this, the UI composition has to follow clear rules, otherwise it would require a huge amount of memory to not irritate the user and to avoid mistakes.
This gets even more confusing when the outcome of a state-change is of delayed or fine-grained nature („Did I just change anything, and if I did, what did I change?“).
I have no clear solution how to tame the Intensity chaos here, some considerations (that require some more research) that crossed my mind until this point:
- Make it some kind of a fuzzy-magic-function that simply acts as an unclear effect modifier. But here also all effects should have such a function, not only a part.
- As a variation of this, it could be hidden within a random button/function. Given a specific effect, a „magic“ button changes colors, speed and (if available) intensity randomly within all possible options or within a pre-selected subset of options.
- Delete the Intensity modifier from the haptic UI. Could still be accessed within the app, nevertheless a pretty hard trade-off.
Sometimes a user is looking for something familiar that she can enclose more or less. This may be a saved preset, an effect or a color (palette). Most of you may know this „Wait, there was this one effect/preset that fits into this moment“ situation. „We know it when we see it“ can also describe this. In this case we have to cycle through all options to brute-force-find our wanted goal. Sometimes we have a clue about the position of our goal (e.g. one of the first presets, somewhere within the last third of the effect list, etc), sometimes not. Going through a list of 16 presets seems quite fair to me, but these 120+ (and still growing) effects are way too much if on a single list.
How can we reduce this number?
- Hardcut some of them out. In my case I would deliberately choose effects that doesnt fit proper to my built lights.
- Softcut them out. Meaning they are not available within the PushbuttonUI, but from within the app. Or they are limited within the Kiosk-Control mode with preselections, and can be added to it via a configuration mode.
- Classify them to make a branching tree via subdivision. This is a tricky one… There are (some) static and (most/many) animated effects. There are (some) sound-reactive and (most/many) non-sound-reactive effects. There are (some) static, (some) sound-reactive animated and (most/many) non-reactive animated effects). Also (not so clear): There are ambient and fast-paced effects. And: there are effects that have one color, two colors, or specific color palettes. There are (many) moving effects, (some) fading effects, (some) static effects and (some) XXX effects? Ah, and of course there are effects with an intensity modifier and there are effects without one.
Quiz question: What are clear categories (and maybe sub-categories) we can divide the effects into?
Another motivational use. In most use cases we change a parameter or some; more or less randomly until they fit our situation. A common way would be: Choose an effect, choose a color, choose the speed, choose (if available) the „intensity“. Normally we would either save the result as a preset or just go back to our preset-main menu. There are several ways to handle the save function, especially regarding the kiosk-control mode vs backend-config mode question. My intuitive approach would be: Besides X presets there is one „free“ slot at the end of the list, so while cycling through the presets from left to right the user doesnt get annoyed/irritated by the placeholder light (thats of cause our lovely static ambient orange´esk one). But from the starting point just one click/move to the left one can accessed the free slot. As a general rule I would suggest: Long Press while in a menu of a preset –> Save and exit to the start (or the saved preset). Otherwise one is just clicking out of the menu without any state-change. Alternatively normal clicks just lead to cycle within a preset menu, and only a short double press exits it without state-change. Additionally, after exiting the placeholder menu with a save, a new free save slot is created next to it.
So narrowing my thoughts down, I would conclude with these questions
What you think may be good (exhaustive/disjunctive) classifiers for effects? E.g.: Static, Smooth/Flowing, Running/Moving, Blinking. Question here always are the same: Does it subsume ALL effects? Is every effect only subsumed under ONE classifier?
How can we get rid of the intensity chaos? One possibility could be correlating them to another classifier, e.g. all effects that has their intensity slider making X are also all effects that may be classified by effect class Y
As I like to have a display optionally installed I wonder if some guys already built a menu for navigation with one (A display should support navigation/feedback, but navigation mustn’t completely rely on a display)
Attached a first model of a minimal menu logic that should be consistent and intuitive. Thoughts and ideas how to further improve this?