GUI opinions sought

Replies to This Discussion

Permalink Reply by Danny Boyes on December 31, 2009 at 4:13am

I'm not sure how well it would work for a Markov feature, since you'd have to click somewhere to find out whether or not there actually is a useful suggestion in the list. The whole point of a Markov chain is to eliminate this additional click

Would it not work to have the panel of options visible in the corner of the screen and then for selection a middle button click and then the widget appears around the cursor and move in the direction of choice?

Also are you intending to release the next version today!

Permalink Reply by David Rutten on December 31, 2009 at 8:10am

I was hoping to release one more version in 2009, so my time is running out!

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Danny Boyes on December 31, 2009 at 8:42am

Well stop answering my stupid questions then!

Permalink Reply by Damien Alomar on December 30, 2009 at 7:31am

I'm not sure that this grouping feature adds much. Personally I don't like the new scheme and wind up typing to get what I want, but that's also because I know its there. If I didn't I may be looking for something or requesting a feature that's already there, but just hidden.

Anyway, I don't think there's a way to get around the amount of real estate needed for all the icons, so the question as I see it is how do you prevent all of these icons wanting or needing to be shown at the same time. My suggestion is to go to a "double layer" tab system. I could see it being expressed several ways, but essentially, after the tabs on the top, each of the sub categories (like geometry and primitive in the example above) would need to be clicked on to show all of its contents. This could literally be another level of tabs, but I think it would me more interesting if each sub category showed 4-6 of its icons, and then when you click on the black bar it would expand to show all of its icons. If there was another sub category that was expanded and there wasn't enough real estate, then that would collapse, but if there is enough space for there to be multiple expanded categories, then let them stay expanded. This way people like myself who tend to use GH with limited screen real estate only see the last expanded category, yet people who may be on a two monitor set up can have all of these subcategories expanded since there's the available space.

One suggestion I will add is that I think it would be quite useful to be able to change the order of the subcategories. I think this will make certain things more flexible, and categories that most people will never use (like complex numbers) can be moved to the last category instead of being the first. Just a suggestion.

Permalink Reply by Suryansh Chandra on December 30, 2009 at 7:42am

Maybe there's some inspiration to take from the Rhino GUI... the ability to turn off toolbars you don't need, make a toolbar with custom commands, and still type and find the command if the toolbar is off.

Also right and left clicks on the button initiate different commands, press and hold reveals even more options (which could also be dragged into a toolbar by itself). There's a lot of grouping that can be done this way - like all the ways of dividing a curve.. or all +-/* scalar operations. Though not everything might be groupable in this fashion.

If the number of icons is only going to go up, we do need a serious strategy of finding more logical ways of 'hiding' stuff so its easy to find as it is no longer possible to reveal everything upfront.

The way plugins work right now by creating their own tabs is also not the best as there is valuable screen estate lost because they all come with their own tabs, but may only contain 2-3 icons. This is where I think toolbars might make a lot more sense (nearly every software uses it, only that the office suite and now the new AutoDesk lineup is shifting to this tabbed interface, personally I think the new acad interface is like a formerly adept user's worst nightmare). I understand that this might imply a whole lot of interface re-writing, but perhaps the limitless expandability it offers makes it worth a consideration?

Permalink Reply by Luis Fraguada on December 30, 2009 at 8:23am

Hmm, I think what Damien and Suryansh have commented on could be a flexible way for the future. Currently in Rhino we have nested menus and nested toolbars, and the ability to create toolbars, etc. What about nesting these things?

Permalink Reply by taz on December 30, 2009 at 9:02am

Some clarifications...

Rabbit and ModeTools have their own tab while WeaverBird lives under the existing Mesh tab. That's a bit confusing so maybe there should be a dedicated plug-in tab where they all live?

The AutoDesk interface works in a couple different ways which may be worth considering:

_Panels that flyout to expand the panel area without duplicating what is already displayed. This flyout can be "pinned" in the expanded position.

_Individual components (within a panel) can also flyout.

_There's a quick access toolbar to which anything can be added.

_Both toolbars and panels can be used, but this might be a more custom configuration.

I'm still giving this some topic some thought....

Permalink Reply by bg on December 30, 2009 at 8:36am

I am always for streamlining and simplification. What about getting rid of the glossy effects, the clunky hexagonal buttons, the wide swaths of empty space around everything for separators, menu titles, etc.? I think everything can become a lot more compact and minimalist. Simple color contrast can keep things easy to see even if they are small.

In any case, I think its always faster to just type a few letters to call a command rather than aiming with the mouse and clicking through menus. I like that you can minimize the menu altogether. I would just request that instead of having to doubleclick to call up the "search keyword" window, cant you just type it straightaway? Just like with rhino's own command line.

Permalink Reply by David Rutten on December 30, 2009 at 9:52am

Hi bg,

Do you mean glossy effects on the toolbars or on the canvas? Hexagonal buttons indicate Parameters instead of Components. I felt it was important to visually distinguish between the two. If not hexagons, then what?

Everything can easily become more compact, or more minimalist, but compact does not equal minimalist. Either we remove a lot of empty pixels and we end up with a GUI that requires fewer screen real estate but which is very difficult to navigate, or we remove a lot of buttons from the foremost GUI layer which means we get a cleaner GUI but you'll have to click more often on average to reach something.

At the moment I'm relegating pressed keys directly to the Rhino command line. If Grasshopper is active and you type "Line ", you actually start the Line command in Rhino. I love the command-line interface, but having two competing command-lines within a 'single' application is awkward in my opinion. I can add an optional Grasshopper command line to the window, that much is easy, but I doubt it solves more issues than it causes.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by bg on December 30, 2009 at 10:19am

I meant the glossiness of the buttons, but i feel the same way about it on the canvas. Consider the look of Max MSP, maybe thats not so appropriate for beginners, but its really tight and simple. Its just my own preference. Maybe eventually you can just open it up to having skins, maybe thats the simplest way?

bg

Permalink Reply by David Stasiuk on December 30, 2009 at 9:36pm

I think the convenience of having a GH-based command line FAR outweighs any awkwardness its competition with the Rhino command line might create.

In fact, I agree with the sentiment that GH interface more like Rhino itself. Each tab could be re-expressed as a menu, and that menu could have sub-menus where groups of components apply. The component icon could be drawn next to the text on the menu, and one could call specific toolbars, either for docking or floating. This seems to me the most expandable option as new components are added and user-developed content becomes available, plus it has the benefit of more directly relating to the current rhino environment. In a pipe dream: How sweet it would be to have Rhino + GH fully integrated? My goodness...imagine replacing, say, the "Right" view with the GH window and having a parameters toolbar permanently docked? The command line could use, for example, a "GH_" prefix to create new components...

If I have one vote, though, it's all about the command-line. I hate component-hunting when I know the one I want but have to stop my train of thought to remember where it lives in tab-land. The command line lets you cut through these types of delays.

Permalink Reply by David Rutten on December 31, 2009 at 4:15am

Hi Dave,

you do know that the Grasshopper command line is only a double-click away right? That's about a quarter second delay.

Older versions of Grasshopper didn't send keystrokes to Rhino, so you always had to be very careful when typing Rhino commands to see which window was active. I found this to be very annoying. But, as mentioned, having a permanent GH command line on screen as opposed to a floating one is not that difficult to implement and we can switch that feature off by default.

A hierarchical menu/toolbar structure is indeed more efficient with screen area, but it has two drawbacks: it requires more mouse clicks/moves to get to a certain tool and it's less discoverable. People who don't know which tool would best suit their needs are better off using a search feature which is smart enough to handle keywords and fuzzy searches and people who do know exactly where to find what they need are better off with an exact command line or a large tool palette. We see this behaviour in Rhino already, a lot of the hard-core users I know use the command line for most invocations or they have dozens of custom toolbars stacked all over the place.

I don't mean to beat down on your ideas, I know I'm the one who asked for opinions. Some of this stuff is probably exactly what a certain percentage of users want. It's almost impossible to design a GUI that works well for everyone, so perhaps I should start to offer different kinds of toolbars in future releases...

--
David Rutten
david@mcneel.com
Poprad, Slovakia

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page