I can’t comment in as much detail as I’d like right now, so I’m sorry if this is a bit short and to the point, but one point I’d love to contribute:
Don’t re-invent the wheel on things that are time-tested and researched!
This is something Blender had traditionally done quite poorly on in the pre-2.5 days, and I think we’re all reaping the benefits of leaving that behind and reaching a larger audience.
Fitt’s law, radial menus, sliders… all of this has been researched and shouldn’t be thrown out.
Some thoughts on what I’m seeing:
-A radial menu becomes less functional with every entry above 8 that you add to it. In fig.7 I see 24!
-Fig 11 shows angled sliders. What fault of regular sliders does this solve, and are any extra problems it creates worth it?
-Why do the Brush Settings ‘pie’ menus have a big icon in the middle which splits the important parts (the settings) alongside it… making users travel further? What problem does this solve that a regular rectangular menu does not?
-Not every brush can be adequately condensed into a thumbnail, so text is definitely useful to have. In the screenshots the sea of gray blobs makes it hard to see what’s what.
-You’ve removed a lot of the discoverable locations that settings live in (the topbar most of all), and hidden them behind hotkeys. While this can be desirable for power users, it’s something that stands in the way of those who are new to the program. Power Users would be in a far better place to make a small adjustment to the program to tweak it to their desire and hide the top/side bar if it helps their workflow.
Fig.13 shows a radial menu that uses North, South (two cardinal directions), and then all the intercardinal directions. The most memorable/functional directions are the cardinals, so I’d always strive to use those first.
Fig.14 uses none of the intercardinal, and instead has cardinals and then odd subdivisions. In your (muscle) memory, it’s easy to remember ‘This tool is up, this tool is to the left’, but much harder to remember 'It’s kind of up and to the left, but not fully North-West)
The more entries and therefore the less space between them, the bigger the failure rate of muscle memory ‘flicks’.
I’m loving the idea of being able to create radial menus in Blender though, and brush sets sound like they’d be great for customisation!
Oh, now I understand your point. Don’t get me wrong I like consistency, but the thing is that pie-menu can contain very different options, some of which are to be used very fast, and some require more time for making a decision. With that I think having pie-menus with slightly different behaviour is a good thing, but it is debatable.
I agree with you, and the topbar with all advanced options is still present in my proposal, thou I didn’t put much effort in showing it fully. Look at Fig.23 (pink color).
Also I don’t think that having more lean, optional interface element (pie-menu) with the most important settings that can be accessed with a shortcut is a bad thing here. With topbar present no one force you to use pie-menus. You can rely solely on Asset Browser and topbar for choosing a brush and changing its settings.
That I think would work the best. The drawback from fully automatic options is not worth it imho.
That would be very nice, althou Blender should be shipped with some sane defaults.
That is a very good point!
I’m not sure I’m following you here. Inside pie-menu there is only one button (bottom texture glyph). Top one is only an indicator of default brush. Probably I should have made it clearer. I think that issue is moot thou, because of what Julien wrote about abandoning the concept of default brushes.
I prefer those too. I putted those settings in pie-menu mainly for beginners.
You can discard that mockup, it is a design experiment. I even thought about another design with left and right handed versions tilted in different angles. Main point is that the most natural movement for a hand with pen and tablet is diagonal, not horizontal. So for left handed people the sliders could go from top left to bottom right, and vice-versa for right handed.
But I agree that pure gesture based solution is the best. The problem with it is that its harder to discover those functions. I think Blender should have some kind of quick helper with gestures and shortcuts layed out for specific workspaces.
Now that I think of it, yes, that makes sense.
I think that problem is going away, as Julien mentioned that there will be no distintion between default and custom brushes.
I also thought about rectangular design for brush changing, and it should be better in this example. On the other hand radial design gives you more flexibility with custom brush sets shown in Fig.3-4-5. I didn’t wanted to mix different layout shapes, so I went with circular for default brushes. Tho I agree that there are drawbacks for having too imuch items in a circle.
This isn’t only an icon. It can show you how the brush looks and behaves in real time. If you are working with more detailed brush having a big preview can be helpful. Cursor travel can be improved with moving the brush preview upwards and joining two settings parts together.
That’s why they are in Asset Browser brush section. If you have lets say 20 or 30 brushes in one brush set having text descriptions can make the pie-menu UI very crowded.
I didn’t removed the topbar!1
Look closely on Fig.23 (pink color). Hell, I explicitly included this functionality inside UX structure:
That can be solved with adding two more empty places for future dyntopo and remesh functions (8 instead of 6).
Thats the problem with random and constantly changing number of functions. I went with what you see, which is dividing circle into the number of functions required. The other way which you are describing is to design layouts based on particular subdivisions. I say both have pros and cons. For example with the second approach how would you design a radial pie menu for any odd number of items or even number that is not 2, 4, 8.
Your personal experience or hunch counts for less than the research that has already gone into this. A radial menu with random subdivisions serves no proven purpose that a regular menu doesn’t do equally well or better.
Don Hopkins has a lot of research on this, sadly his website is down. Here are some excerpts though: https://ux.stackexchange.com/a/154
Note the first response: Radial Menus have a poor perception because of bad implementations. This is what I’m trying to avoid!
More than 8: You wouldn’t! 12’s the accepted maximum. I haven’t seen studies on how effective a 12-slice pie is, but from personal experience I’d say it’s already less practical than 8. There’s a reason there can be a linear runoff menu at the bottom.
An odd number: simple. You start with filling the main ones (up, down, left, right), and then the ones inbetween. You decide how to logically group them.
Compliments for the mockups, they look great. Positive feedback: consider to help out on existing code projects we have to help improving UIs (asset browser, geometry nodes, etc). It’s rewarding to contribute designs to areas that are fleshed out already and will (likely) be accepted.
A radical change as you present with overlays here is not a topic we can quickly decide on. I think it’s overshooting on practical usability and it’s a big step away from core UIX concepts we use in Blender. I think it’s better to first agree on a general direction we should go to with overlays (pie menus, button panels) before going into detail as this. During the upcoming 3.x series there’s plenty of time and space for such discussion and design reviews.
I also want to see more developers/designers to join the team. We need to find people who bring in many years of experience in the 3d tools field, people who fully grasp the history of what we did (what’s good, what to improve) and develop a well supported vision where UIs in Blender will go to in the next years.
For that reason the UI module is kept on a short leash - they should first assist on existing projects and module teams, to work on generally accepted concepts, finish what’s not fully fleshed out, work on quality, do all the essential maintenance.
This concept can be easily be implemented as an addon with BGL drawing and a modal operator. However drawing images as Buttons or Menus in Panels is not feasible.
If you consider the two options that are “develop addon” or “develop in core c”, that are both experimental and time consuming, the only feasible solution is to re-use every possible existing infrastructure that Blender provides, thus you go with Pie menus or Panels (same as making custom addon though).
Plus the most important, to consider, if is really helpful to draw custom images on Operator buttons, other than setting the standard icon= parameter to use an existing internal icon.
So to recap, what can be examined:
Develop addon: easily done by anyone for research purposes, the most possible outcome is to consider the possibility of a BGL based GUI to emerge that it would be presented in more flexible and creative ways.
Develop core c: super difficult in terms of not-development.
Develop core c to support custom image drawing: if there are many uses cases and actual need to support such a feature, weighting the pros and cons, thus you can get Pie Menus or floating panels ( bpy.ops.wm.call_panel) with custom images that will make them look good. But the final point if actually #1 makes more sense.
It’s good (in docks on right). When imagine the other tools on right, next to menu after change sides (gizmo to left) then work can be more comfy and faster.
The brushes can be more easy understand with role, and adding new/own or custom can be comfy here.
The basic tools with icon on left can be as option if somebody want old style.
Maybe grouping new, or favorites can be more useful, this same “last used” list.
Not sure about implementation search by name here or filter (eg. with proposed groups), especially if many new. In plans “online brushes” as addon? Then management need more expetations.
The solution touching problem around material management from online asset addons, can be included in to this as some “template” to usage around UX/GUI. On RCS was propositions with this.
About “Fig.11 Another layout variant of custom Brush Settings pie-menu”
can be option to test, and after experiments user can grab new experience, this can be ok on tablets, etc. where screen can have changed orientation by angle not like on PC/Laptops. On 1st look reaction was “why”, but “maybe”…
this same on center… but imagine… some AR/VR solutions…
About custom parameters around brush in center… I think this sould be more “pure” as tool panel on right side GUI and next to whole menu (as ctr+t).
Blender 3.1 is well underway, i would like to ask if there has been any talk of developing discussing this further, any plans to tackle this proposal ?
I just want to say this is such a WINNER in the mockup. This should be very much considered, if not, reconsidered. *All of the ones shown are great, but this one definitely encompasses what Blender has, and the users of Sculpt mode are already accustomed to. This just happens to appear more streamlined. Lovin it, I hope its being considered.
hii, tbh it looks more like a stylized Uix of a nice addon. It doesnt match with the current UI/UX of Blender. The proposal has to be more streamlined with blender’s UIX . The mockup’s UIX is good for an addon!
I disagree.
That does not go against Blender’s UI or UX.
That would make a great UI for a global menu in this mode.
Menus have to be in phase with the mode.
In object mode, right click menu can adjust a spot light size which is also available by gizmo.
In edit mode, right click menu is corresponding to specials of selection mode.
In currrent texture and vertex paint mode, right click menu is showing a color disk.
That is totally in phase with a new advanced sculpt&paint mode to have a right click menu showing basics of active brush and a quick way to switch to another one or go back to last one used.
That is what is represented in the mock-up that is important. Not the graphic style used by mock-up’s author.
This is a very radical change for the current Blender UI.
This means “Let’s first have an agreement on the overall design principles first before making such a overwhelmingly different UI”.
I agree that it looks out of place. It doesn’t look like “Blender” to me. I think we either discuss this proposal’s design principles and see if the entire Blender UI design can adapt, or have this design be modified to be more like “Blender”. Otherwise I don’t think we are getting anywhere.
What Eary said is 100% correct, and you arguing against it isn’t going to get this implemented.
The first step to getting something into Blender is studying the software’s design and seeing where they could be improved without breaking its rules. Tacking something like this on (with all the issues that I bring up a few posts above) just isn’t going to be accepted for anything other than an addon.
And: an addon is still an option, in fact there are already several that resemble this one
You’re phrasing all of this too forcefully too. ‘A community involved with developers discussion is a must’… you had developer interaction already, in fact the person in charge of the Blender Institute responded.
None of that means that developers need to ignore all the problems with a mocked-up image and just… what, implement it or the community gets upset?
As for all of the disagreements happening. Here’s what I want to drill down on, because nobody here who disagrees with the mock up I re-uploaded that was posted earlier is stating anything in simple terms for myself as a Artist to get a grasp as to why this should not be implemented.
Right now, I’m reading there are Blender “rules” to design and UI.
What are they?
Why do they matter?
What is the intention of the long-term design of Blender, and its feature-set and functionality?
I totally get the opinions of those who are compiling code here, who have fixed views on what they would rather do, and not do. But if I may… As a veteran in the games industry who is proactively seeking to voice as much as I can see benefiting those in it, and out of it. As to where Blender can and would shine brighter. These disagreements that are in the tune to shutdown discussion are not helping anybody understand things better, and certainly those of us whom are doing our best to stray away from the Autodesk side. Because we see the potential Blender can be that other DCC software chooses not to.
In my opinion, If I were able to write a DCC software and allow sectional tabs that are labeled as editable mode types from Model, Retopo, UV, Sculpt, Render, etc.
I would try to write that software in a way that shares the common language across all sections, but distinctively respects that each of those tabs does things much different at their bests which would entail them uniquely having their own user Interfaces of functions that are best suited for the type of work they entail the user to do. One size fits all doesn’t work, and in real-life this is true on every fundamental level. If applied that way, I see more problems that are just in queue for the future to resolve. Less is more would do, if Blender was a solely sculpt focused only application, but it isn’t. What I think serves great about the mock-up UI, is that I don’t have to navigate the rest of blender when sculpting at any capacity. When I can sculpt, I only want to focus on creating and refine at a rapid pace. Fine tuning things should be focused in the brush presets, and if there was a brush property section to be more tenacious with brush behavior, etc. Great! Overall, Artists in the 3D space who sculpt want to see as little UI in their way as possible, and ZBrush does this well by having a right-click pop up menu as this Mock-up serves, plus it adds onto the existing Blender theme with UI buttons already there, uniquely to sculpt mode of course. Whether that breaks the Blender UI rules or not, it will have to be addressed in future at some point.
What I would like to understand from those who don’t agree (devs included) is what the top ^ 3 questions raised would be, and what is your intended design?
