Happy New Year to the UI developers. With the new year I bring you a new (fictional, at the moment) UI: Spark UI!
Having experienced the true spaghetti monster (Meteor M43 UI), also the D4 UI, and various clicky UI’s there were some areas of improvement that I felt could be explored.
The abstract criticism I have with the current UI’s is that they don’t adhere to a principle of good UI development: user inputs should cause the same reaction no matter what state the UI is in, and parallel to that, the user inputs should result in the same behavior at all times.
By improving these two areas, the user can better understand the UI and the UI can better understand what intention the user has when pressing buttons.
For example, if a single click turns the light on and off but a double click turns on strobe, then you have already violated a design principle. A double click should conceptually be no more than a fast cycle on then off. A 6x click should result in the power cycling 3x times on-off.
The M43 Meteor is a good example of bad UI in this regard: it has no idea what number of clicks you finally intend to press, so it has to blindly start changing modes each time you click. The user therefore has to content with all kinds of flashes, blinks, awkward pauses before the UI says “Ahh, you wanted six clicks to lockout!”
So how do we maintain 6x click complex UI functionality?
The general theme of Spark UI is that the user is given a small window of time with a visual cue in which the UI accepts advanced user inputs. The visual cue is a metaphoric “spark” that either leads to ignition or burns out, as in to start a fire, you have to act quickly to ignite the spark into flames!
I took inspiration from Toykeeper’s graphics to explain the UI. Without further ado, here it is:
Hopefully you can see that a spark can be accessed from anywhere in the UI; also, the behavior of clicks and holds is mostly predictable (only one deviation, continuous holding from any position results in Turbo EXCEPT in a multi-level; in this case, Turbo hold is repurposed to advance to the next pattern. See the green text)
In summary, the “spark” is the cue that the firmware is telling the user “I’m waiting and listening. Tell me what to do.”
Let me know what you think. Hopefully this sparks some discussion (pun intended).