Make options more discoverable (UX - provide affordance)

[jjdeprisco]

I've been going through the Starling GateSeq tutorials in detail. I'm trying to understand these cryptic modules a bit more. I've come a long way in the past couple years with a variety of modules and techniques (thanks to the many great tutorials our group supplies). I always like learning new things, and can never know everything of course.

I just find the interface very distracting on these Starling modules, and so many options are hidden under the hood under CTRL+Click. Wouldn't it be better to put more of those options in a menu, rather than "under" a CTRL+Click? Or at least make it more obvious that the options are there?

This is an issue with a number of modules, but in this case it really impacted any enjoyment of using the modules themselves, and got in the way of the flow of the creative process.

[liquidcitymotors]

Thank you for raising this issue and sorry for the late reply. I agree that the current menu implementation is not ideal, but I also wonder if that is a fundamental flaw with the modules, both hardware and simulated. Originally the thought was to simulate the hardware modules as closely as possible including any potentially frustrating UI elements.

@jjdeprisco would it help if the button parameters could be selected from the context (right click) menu?

[jjdeprisco]

Thanks for the late reply. As much as we all love Rack, one of the big issues it has is that it basically *relies on* skeuomorphism. So for users who are not familiar with the obscure pieces of hardware that are being replicated, this is a distinct downside. I think there should be a happy medium somewhere to address that. Skeuomorphism https://www.interaction-design.org/literature/topics/skeuomorphism#:~:text=Skeuomorphism%20is%20a%20term%20most,user%20can%20interact%20with%20them.&text=Skeuomorphism%20makes%20interface%20objects%20familiar%20to%20users%20by%20using%20concepts%20they%20recognize .

…

On Tue, Sep 28, 2021 at 8:17 PM Will Mitchell ***@***.***> wrote: Sorry for the late response. Originally the thought was to simulate the hardware modules as closely as possible, but I think your suggestion of better/alternate Rack UX approach could be a net positive. A 'button mode' submenu in the context menu sounds like a reasonable approach, I will give that a try. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIR54JWY4GIAWQT3VMKNEPLUEJLKTANCNFSM4LVFRT2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

--

----------GMAIL------------------ *Jeremy J. dePrisco* ***@***.*** ***@***.***>* *https://linktr.ee/jjdeprisco* <http://jeremydeprisco.com> "I've never known a musician who regretted being one. Whatever deceptions life may have in store for you, music itself is not going to let you down."

-- Virgil Thomson

[liquidcitymotors]

Thanks for the extra context, I understand the problem more fully. As I see it now, we want to first give the user the idea to interact with the buttons. Then, we need to present information allowing the user to develop an understanding of how each parameter button can be used in their creative process. I think its safe to say the current design fails to do that.

I'll experiment with this next version and see if any improvements can be made. Its far from perfect, but it seems like laying out all the options in a dropdown menu could help a little. I still think the designs might have some structural issues that prevent this issue from being truly resolved without a prohibitive overall.

Either way, we will definitely address this general problem earlier on in the design process of any future modules.