The future of Grasshopper User Interfaces?

Grasshopper
,
22

I would guess that the slider is indeed the most used input control in Grasshopper, and I also agree that a software slider has many problems. Especially if it gets laggy. I see the point of using potis and hardware sliders to better control a definition. I did this at well, but all my hardware just became covered in dust quickly…

Because the underlying problem is that people misuse Grasshopper as a design finding tool. So they don’t know what they want, throw away the pen and create a definition where everything is super flexible. With this they quickly over-parameterize a definition, which are more or less minor calibrations.

I think if you use more than 10 sliders you might already have problem in your definition. Limiting parameters and the definition is beneficial to build reliable and sustainable, reusable definitions. For calibrations a textbox/panel or even a settings file is a much better choice.

I also believe that the widespread one-definition-builds-it-all dogma is not a good choice either. If you have a rather simple, well-performing definition, you have little need to improve the UI. But I see that many people use 1000+ component definitions which are super difficult to handle. With a bit of coding you can already reduce many of these definitions to a minimum. So that the only need for a GUI is more or less related to presentation purposes.

So sure, its valid. But building UI’s on top of GH or to use hardware to enhance user experience will not solve any problem…

23

Hi @TomTom

My personal requirement for a Grasshopper UI system is in packaging and delivering GH scripts as Rhino Plugins - where the user has no view/interaction with the GH canvas.

I find sliders - either in GH or in external UI’s to be the LEAST USEFUL of any user input. I tend to relegate them to ‘controls of little importance’ - Sound Volume, Opacity etc - where getting in the ball park is ‘close enough’.

One of the big issues I find with sliders as inputs in GH itself is the fact they output all intermediate values when moved. On small, fast to run GH scripts this is no issue, but put a couple of Boolean operations into the mix and the whole script can hang for 30 second on a single slider movement.

In my own projects Number Inputs are the most common user input, followed by Pull Down Menus.

Cheers

DK

2 Likes
24

However, sliders are fast and intuitive for form finding. Horizontal and vertical sliders can be related visually to the X and Y axis in a view for faster correlation and association. They do suffer from scaling insensitivity, larger the range, the lower the ultimate resolution, the longer UI space required for decent results.

In my process of form finding and the design “head space” I’d like to maintain, anything that reminds me of SolidWorks and Pro-E like entering a number in a dialog box I am phobic of. Naturally, if the process requires a specific number, a dialog is ideal, and for a small subset of static numbers, a drop-down suits perfectly.

The main issue we face is Grasshopper going “deaf” to inputs during the time it calculates the solution. Sliders, especially ones that output at a fast rate, output a lot of needless recalculations, creating lag.
One successful method to deal with this overloading is to buffer the slider messages and output at a slower rate (180 - 300ms work for my purposes), and/or waiting for a sufficient pause in the message flow before sending a signal to Grasshopper. User adaptation is also to tap on a slider location instead of manually moving it through the range. However, this is expert, not intuitive behavior.

I’ve tried a few approaches, buttons for upshifting and downshifting values by different increments. Major, minor, fractional. I was unsatisfied with that process, sometimes one wants to see the comparative result of a major variable change. That required an excessive amount of clicking buttons on the UI.

Another approach I tried was a dual slider approach, one for coarse control, the second for fine control. Middleware control for resetting the fine to centerline when a coarse slider adjustment was made. Again, it did function well, just did not feel like a satisfying or particularly intuitive process. It does have historical precedent in some physical pieces of equipment with two stages like potentiometers and micrometers.

03-252-S-800w
03-252-S-800w691×518 16.5 KB

My bottom line, so far. Nothing beats a correctly managed touchscreen slider for coarse immediacy, and nothing beats a physical dialbox for finetuning variables.

25

My definitions requires dozens and dozens of sliders and UI rotary dials and I am using Grasshopper as a form-finding tool.

There are different use cases and it’s my strong and considered opinion that complexity should not be shied away from in some expert models. Certainly there are many cases when taken to excess, but reduction, while a mainstay of modern computing, is not always the answer.

A stop along the sidetrack of “less is more”.

apple_mice_evolution-800x285
apple_mice_evolution-800x285800×285 24.6 KB

“It looked like a grey blob,” Farag says. “We were going to put that model into a box so people wouldn’t see it.” However, when Jobs turned up things went awry.

“Steve looked at the lineup of potential forms and made straight for the unfinished one,” Farag says.

“That’s genius,” he said. “We don’t want to have any buttons.”
“That’s right, Steve,” someone else piped up. “No buttons at all.”
The meeting, it seemed, was over.

“[Afterwards], Bart Andre, Brian Huppi and I left the room and huddled outside with each other, [saying] ‘how are we going to do that?’” Farag recalls. “Because of that unfinished model we had to invent a way to make a mouse with no buttons.”

Managing sliders inside Grasshopper, yes a UI and workflow disaster .

26

Sure, there are always use-cases. And of course everyone is free to use as many sliders as wanted. Luckily no rules are preventing us to do so! My point is just that there is little benefit to extend UI’s either by creating more UI Builders or by connecting exotic hardware devices if people just need it to manage their bloated definitions. Because in my opinion, the problem is more or less a software-design related thing. You shouldn’t underestimate it.
Using your interesting analogy. If you create a mouse with 50 buttons you’ll need a couple more fingers. I don’t know if a good solution then to connect robot fingers. A mouse with a couple of buttons is totally fine. Sure it would be an interesting extension to try out. How could I demotivate people in creating more tools. Yet, Grasshopper is notorious for having a rich variety of poor plugins.

1 Like
27

I manage my 104 button input device with my standard 10 evolved digits.

design-large
design-large1920×1080 94.3 KB

2 Likes
28

This is the point when such threads get really stupid.

29

Pffft… Amateur! I only need 2 digits!

3 Likes
30

Suimple is another GH UI project that showed promise but has not had further development:

31

In my opinion, without McNeel’s involvement in the successor of the Remote Control Panel, all efforts will be almost in vain. Creating a user interface using e.g. Human UI makes sense, but it’s usually an additional portion of spaghetti when we’re already fed up… A simple control panel should be available both as a sidebar in Rhino and in a Grasshopper document, and changes should be bidirectional - i.e. a slider in Grasshopper changes values ​​in the GUI and vice versa.

Unfortunately, the number of components needed for even a simple interface is overwhelming and time consuming. Of course, if someone wants very sophisticated solutions, then they can attach a big definition responsible only for the GUI, but in general I’m a bit skeptical.

I would really like to see improvements and changes in this area in Grasshopper 2 and in the context of Rhino.Inside.Revit. I think this is a known issue and we can only hope that McNeel will lay a good foundation for solving it.

Ah, and Grasshopper Player of course… this is where it really gets tricky.

3 Likes