But what changes are we talking about? Nothing on the list of modifiers has been changed yet. Only controls for new features have been added. And since it was not yet clear how the list of modifiers would go, they have been added to the existing system.
That you can go to blender 2.57 and the few modifiers that were there are identical in their layout to the current ones.
How can you be defending that the layout of the modifiers has been changed in each version and to justify it, give an example of a version that has not been released yet?
Also, that’s very funny to me because that UX problem is exactly what was designed to improve UX and users were quite happy, surprisingly.
And no, sometimes going from 1 to 2 clicks is not a problem, and I usually defend it. The “modifier list” addon also adds another click to apply a modifier you haven’t selected and has a much more comfortable UX than the classic blender list. It is one of the most downloaded addons to IMPROVE the UX of the users. And in theory is how it was originally going to be the list of modifiers in 2.90. But one decision, bad imho, changed that design.
Which users, in what user test exactly? I’m not even sure if you agree or disagree anymore. You prefer two clicks when you can have one? I think most people don’t want a puzzle game, they want an application that makes it easy to do what you want to do. I surely have enough time wasted trying to create good looking stuff, I don’t need harder routes to get there
But let’s see, what is this about, that you complain that the modifiers are changed in each version and as you see it is an absurd criticism then you complain about something that has not come out yet?
This is the last of many changes. My point,and the point of this topic is that you can show a test of this new layout to 100 users,many will point out what I said, many won’t have input,many will say other things. Then you decide how the changes are implemented, ONCE. The first time,with a few designs and one code implementation. That is more time for coders to do other tasks. Not the other way around.
A designer or developer can’t speak for users alone. When you test things on users you get surprised even if 90% is what you expect.
Even though they hid the apply modifier button, they added a shortcut (I think it’s command+a) to apply the one the mouse is hovering over. This is super fast for intermediate+ users, but it’s going to stall beginners who don’t know the shortcuts yet. It is kind of a step backwards in terms of UX, especially for people who like to use the mouse a lot.
Yes. I was opposed to modifiers UI changes at 2.80 release but not to addition of Weighted Normal modifiers.
It was a GSoC project of 2017. I was waiting for it.
Weighted Normal modifier was last part of set of tools added to allow user to customize normals of mesh. First phase of this new workflow was integrated in 2.74 in 2015.
And people was expecting those tools since 2.74.
I was expecting modifier nodes to become new UI, quickly in future 2.8 series.
2.8 series was supposed to be series breaking things with lots of quick changes and then stabilization was supposed to happen after that. Like what happened with 2.5 series.
Stabilization of UI and basics happened at the end of series. And then, addition of new stuff happened in 2.6 series.
I was expecting same mess during 2.8 series development and then, everything returning to normal in 2.9 series.
But I was hoping that contrary to 2.5 series who was mainly made of alphas and betas, 2.8 releases would be stable and usable. That is the case. 2.8 releases are widely used. UX may be annoying because of lacking of things. But what is there is bugfixed.
But that care to make 2.8 releases usable is done at the cost of a longer wait for expected, planned changes.
Particle nodes are expected since 2011. That was the first time where an official blender developer talked about adding particle nodes. Project derived into API giving ability to build custom nodes.
And addons like animation nodes became possible.
In 2013, the idea of Everything Nodes was mentioned during Cosmos Laundromat production.
It became a target for the year 2015.
When Jacques Lucke announced that will happen for the end of 2.8. I was disappointed, but, at least, after a decade of wait, something concrete will happen. Work was happening on particles system who had been a scarecrow for developers during a decade.
Modifier nodes becoming a distant target of 3 or 4 years. Addition of modifiers could not continue to be frozen.
In 2.80 what changes was just addition of Weight Normal modifier and some options for Bevel modifier and adaptation to a more recent version of OpenSubdiv to Subdivisions modifiers.
in 2.81, nothing changes about modifiers.
in 2.82, Bevel modifier was gaining a custom bevel profile that before would have require to convert edges of a mesh in curves. That simplified a lot the modeling process. It was a 2018 GSOC project.
Solidify modifier gains a new mode to handle more easily complex cases of non-manifold basemeshes.
And a requested Weld modifier who consists in basic operation, needed to clean geometry of people who wants to model with a non-destructive workflow is accepted.
In 2.83, each modifier is reevaluated to be improved relatively to recent changes.
Modifiers who did not have an Invert button for vertex group influences are gaining one.
Modifies who did not have ability to use Armature Bones as references, now can use them.
And some modifiers like Ocean or Solidify are gaining specific options.
That is still corresponding to a contained evolution of modifier stack.
Since 2013 and announcement of everything nodes proeject, there is an accumulation of abandoned patches on d.b.o about creation of new modifiers who would handle modeling operations that are not handled by current modifier stack (Bisect modifiers, Radial Array modifiers, etc…).
Although that represents few modifications compared to 2.79 modifier stack.
Some modifiers very regularly used like Bevel and Solidify became full of settings.
So, the idea to make Modifiers tab more consistent with rest of Properties UI came up for 2.90.
And at same occasion, developers thought that would be a good opportunity to satisfy a user request older than “everything nodes” idea and very popular on Right Click select.
Drag and Drop for modifiers.
I was opposed to original design but I could not go against the direction of history.
2 single layout for modifiers can not last if pressure to add new modifiers will continue for 3 or 4 years.
I understand that they had to do something.
And with an outliner able to handle modifier stack, we will have an UX for modifier stack closer to behavior in other software like 3DSmax and C4D with an UI respecting 2.8 Design guidelines.
And 2.83 is an LTS that will be supported during 2 years. In that sense, documentation based on 2.83 will be pertinent during a decent period of time.
That is the same order as in previous releases of Blender since decades.
That is also same ordering as most of lists in UI.
The idea was to transfer it to header of modifier to gain one line of space per modifier for settings.
The fact that is hidden is due to a lack of horizontal space in Properties Editor. Nothing else.
But they tried to make it less hurtful. You only need one click.
Not a fast one but a click hold during mouse pointer movement from V button to Apply item in menu.
That is a basic of Blender UI applied for anything. That is the modifier mouse pointer is hovering.
That would not hurt. But that implies to choose a different color than the one used to drag&drop modifier.
I wish we had an apply all modifiers operator. Passing through conversion to mesh to obtain that, is not a clean way to expose this ability.
There is only 3/4 months between each release. And in a certain sense, a 2.8 release is just reflecting what part of job have been reached at moment of release.
Developers are targeting improvements for next release. They is a BCon1 phase where new stuff is added. And at the end of this phase, some things are passing the cut, and some others don’t and will be postponed to future releases.
They are very few users testing features when they are just patches. More are testing specific branches. More are testing master. But there also people who are only testing features, when they end-up in an official release. And generally, a clean-up is following in next release.
So, I believe that would not hurt if someone was able to postpone an entire new set of features if it does not correspond to an harmonious UX.
But, on the other hand, as a user, I am frustrated to wait 4 or 8 months, more, knowing that work done can already improve partially my UX although that does not correspond yet to perfect UX expected.
There is a chance that a big amount of users, testing master could be angry against development if such policy was adopted.
An idea is calling another one.
I almost always think that features could be pushed further when they are officially released.
But at some point, a feature can’t stay ad vitam eternam at WIP status in an experimental branch.
Somebody has to draw a line.
And who ever it is. There is always a chance I have disagreements with that person.
I hope that foundation will engage somebody I will agree with, most of time.
But I have no illusion that some valid motivations behind development may not match what I was expecting.
I know, I was just stating that a different design and layout can improve or create more doubt about order. Which makes the user immediately understand it, or have to stop and think. I don’t think it really helped, it’s not clear that the order IS or ISN’T top down. I’m still fairly new to Blender (2 years). I don’t immediately see that and say oh that’s a list. It’s boxes in a square. A list to me is bullet points, if it’s an ordered list it’s a numbered list. I know I’m being pedantic, but that’s what’s obvious. Obvious saves time.
And in my opinion I like the new look of that area, but at the same time it broke hundreds of YouTube videos. The dropdown where the apply goes is not used consistently enough in the UI for a beginner to immediately find it. Many designers like to make things small and hide things, that’s why UX for me is important, because someone can say, hey I need that there, can we do it differently, I don’t want find everything when I need it.
That may be, but it’s not clear. I get that there’s also a need to think new ways for interfaces, for VR, touch etc. in the future. Or pen that I also use for that matter. But given that the easy to see and click thing is by default usually hidden now, this just gets more advanced, unnecessarily in my opinion.
The “just” was regarding the people involved. It can be talking, having design sessions, doing user testing, whatever. But with people who want to lift things up, who want to bring things to a higher level, who work in a positive way to strengthen what is there and to bring new insights. There is limited value in highlighting what is currently wrong; many of those things are already known anyway. It’s finding ways to solve the issues, in a way that matches the direction and way of working of Blender, that’s the challenge.
That’s true that a numbered list would be obvious.
But there was no space to add apply icon in header.
That would be weird to add a number and have to move delete button to dropdown menu.
And that would imply to automatically adapt renumbering when order of modifiers is changed.
Probably, in outliner’s list, that could be done easily.
But that represents probably a small gain in term of usability compared to needed work to provide to have it.
And there is a chance that such task ends-up with a low priority or a “nice to have” tag.
Because that being said : this is not a hesitation that is persisting a long time when you start to try using modifiers.
When you add a modifier ; there are more cases where you can figure out quickly ; that the effect of last one added is the last effect to be applied.
If you are a complete beginner playing around, not really knowing purpose of modifiers : of course, that is not obvious.
But if you are just switching from another 3D Software, that is not complicated.
And if you are following a tutorial, you are probably guided, step by step, in a way that becomes obvious.
I talked about end of Bcon1. And I think that probably, there should be a call for feedback about features of next release after last developer meeting of Bcon1.
A thread moderated by a developer who could indicate motivations being UX decisions who validated or not features in master for next release and where users could discuss those decisions, expressing their feeling about what is missing or what is not great about UX of new features.
That way, there could be more guidance from community on Bcon2 and Bcon3 polishing phases.
Relatively to amount of features, this could become a huge unreadable thread.
So, this could be centered on identifying features with UX problems, first.
And then, other linked threads would be dedicated to solutions.
I think most of what you say, and the reasoning makes sense to me. I think what I am trying to get across, and we do that by examples to not just use big words, is that it’s too much down to the interested designer/developer/person. A designer and a developer have clear interests, that are not necessarily shared by a user. It’s well known that if you ask people for their feedback you get a feedback bias. Ie. the only people that answer are the ones that like to answer feedbacks. A good broad UX plan would specifically get more types of users, to broaden that picture. And test things, ideas, before they are developed.
If only the people that influence a design decision is the super interested people, Blender will forever be a tool for special people. My impression in the last years is that Blender is being adopted by many types of people, that not necessarily join a forum, I’d assume most of them don’t. It’s probably largely following YouTube tutorials. So by design, removing something, breaks a lot of learning material. (LTS versions probably help with that).
It’s not that it’s so bad, it’s just that I think at this time, Blender has a unique position to be even more. And not only with new fancy features, with making what’s there more accessible. My only interest is that I care about users and usability, and I don’t like repetitive tasks that can be made simpler. So I will try to contribute myself too, but I still back this open letter, for the reasons mentioned.
Objection, your honor. Tutorials are good the first time around but as soon as you try to remember what was said in a tutorial just a week ago you have to find said tutorial and the exact time code, which takes usually longer than it should to find the specific thing you are looking for. At least for me this always takes me out of the flow of creating the models and also takes longer than it should. Then it’s immediately annoying.
Always have everything be as self explanatory as possible.
You’re repeating a debate that took place in 2.79. Everything you’re saying has already been said. Do you really think that in a software with a huge community no one has raised the issue of user feedback?
You are complaining about the bad experience that will give the youtube tutorials break when you started with blender 2.80 that broke the tutorials of a whole decade without special problems.
If someone expects a round of user testing with newbies for every change in UI… It’s that he doesn’t know about blender’s development and its limitations. You’re talking about how a company that has plenty of money and development time would function.
Nope. User testing for a range of users from all experiences. Not only the beginners. You want to have everybody on board.
The question is then rather: How could a Usertest be done for an Open Development like Blender. I could imagine that there would be volunteers if needed. Blender’s development is open, why shouldn’t the tests be conducted in a similar fashion. The question then is: How can you conduct the tests … video recording maybe. Or a questionnaire directly after testing a feature.
Maybe there already are solutions to this how other open software does these kinds of tests?
Also interesting: How much would a user test actually cost if conducted in a controlled fashion?
What would it take to set up and how long would be needed?
Could it also be enough to conduct user tests to set up the UX guidelines once and then proceed in a looser fashion? Maybe it would suffice to not necessarily set up tests for every feature but only on a few regular timeframes. Sort of to update the general guidelines and how they developed until then?
You don’t know what’s possible without identifying the need and looking at how you want to do it. This letter has a very simple question. You keep bringing up things that are changed 5 times, that I claim could be avoided because these changes now happen in the “shadows” of the normal user. You are not a “normal” user, they are not here in these forums. They don’t create bug reports unless something literally makes their scene explode. All users are not involved now, they could be to a larger degree. If Blender wants to.
Doing things correct the first time SAVES development time, so there is no point in droning on about development time and money. It’s very clear you don’t know how a good UX process works, so I’m not going to continue discussing it with you. I’ll agree to disagree.
No. I try to maybe say things that …
… maybe have been said but are worth recalling
… have maybe not been said yet
… make others come up wth a better solution.
That’S why I don’t really need to answer a question where you have determined the answer to be negative, anyways.
