I did not mean that they will solve those problems during production. But that feedback from artists of Blender Studio will help them to prioritize what BA, right click select and devtalk proposals should be implemented first.
to be honest…UX problems and workflow problems will never be a problem to developers. Having done some addon development…I kind of understand them…I mean they want a button for everything and every button to be there. I mean…just look at the UI design at any software where developers are left to their idea of design…it’s buttons,sliders,text fields everywhere…and a lot of comand line(operators) stuff hidden where no one can see.
Thanks for the clarification. So it seems we are pretty much on the same page
That is not true. They are solving many UX issues during GSOCs between periods of UI refactoring like 2.5x and 2.8x series.
If you take for ambition to make a software only usable with a stylus ; you have to provide at least, a button or an item in a menu or a gizmo for everything.
Being usable on tablets is just 2.8 Design promise.
That is a little bit contradictory to complain at same time about buttons everywhere and hidden stuff.
It is true that there are old operators that are not exposed into a menu like Extrude Repeat Mesh.
Many times, it is because there is something more recent doing same job.
For Extrude Repeat Mesh, it is Array modifier.
This operator can be called by using search like the other ones.
User can open Operator Cheat Sheet in a text editor after generating it from Help menu.
By default, Python Console displays a message indicating there is a bpy.ops builtin module and that shortcut for autocompletion is Ctrl Space. User can discover them that way.
Of course, that don’t make those operators obvious but minimum effort was done to make them discoverable.
Some are described into manual.
@zeauro The fact that they have to have a separate run on the GSOC just to fix the UX issues proves that I’m correct.
As for wanting buttons yet not having the UI be overly cluttered with buttons,ridal menus, drop down menus,text fields etc…I don’t think it’s a self contradicting statement.Not everything should be visible all the time,but this does not mean that you have to dig through the python API code so you access the feature.
I don’t think that forcing the user to use the python console and digging through the API,so he can get his work done, is something to brag about. Not everyone has,needs,wants to have knowledge of a programing/scripting language.The whole point of a UI is so that the user/artist does not have to deal with code.
But this is not really on the topic so I’ll end it here.
It is not unusual in coding projects that the UI/UX is tackled last. First a feature needs to work. Having a fancy UI only makes sense once you understand how the feature can be used and what a reasonable way is to interact with it. Depending on the project, this isn’t always obvious early on.
Uh-huh, like this monstrosity?
@DeepBlender again…proves my point. Usually developers don’t have time or don’t care about UI/UX, because it usually comes afterwards. But there is also the argument, that if they don’t know how the feature will behave,what inputs it will require, and how it should look visually(if any visual representation), then they are just wasting their time. As with anything…you usually have to start with a clear idea on how things will behave,what is the starting point and what is the end goal. Thus you can predict fairly well what the workflow with the tool or feature could be.Thus having the right button at the right place isn’t that hard to do. Yet no one thinks about this. A clear example I can give with the greasepencil’s onion skin toggle. It’s in the layer menu(ok), but not in the dope sheet.The question one should as here is “how often the user will select a layer via the layer editor, and how often from the dope sheet”. Anyone who animated with grease pencils will confirm that he works more with the dope sheet than with the properties panel.Not to mention that you have to get out of DRAW mode in to OBJECT mode to chane onion skin toggles for different GPs. Now I made a operator that fixes this workflow issue. But I’m asking “why am I forced to make a operator for something that should had been there from the get go”.
In any case I will bring it back on topic and agree with @Stan_Panckaes , which brings my point. A lot of UI changes in Blender 2.8 were made to bring studios to blender. Which isn’t bad. But now these studios are dictating how blender should look or behave. One case of this is with the Video Editor. After the talk on BCON I joined in that channel in blender chat. Everyone there were somehow pissed at each other. But later someone said that I think Unity is willing to donate developers to help develop the VE. But then they said that first they will have to go around studios and ask what they want the VE to be. Totally neglecting individual ideas, and I don’t think that’s right. But that’s my opinion. You can always discard it as coming from an inexperienced blender user.
Please don’t misrepresent my statements!
Even if there are cases where the UI/UX is dealt with after the actual feature, you can’t draw the conclusion that the developers don’t have time or don’t care.
Of course there are developers who are not interested in UI/UX and there are certainly cases where the developers could not properly finish because of other pressing issues. Nevertheless, making general and very simple statements when it comes to UI/UX feels very dishonest to me.
There are developers who care a lot and there are people like William Reynish who invest a lot of time to bring Blender forward in that regard!
Perhaps do it the Ubuntu way, consider 2.79 as the LTS (long term support) version, and move to the last version of 2.8x series for your next LTS? I would like to see the UI stack completely removed from Blender, more like an addon, the UI schema a plain text file that can be edited with an external application, similar to SVG which can be edited with Inkscape and a code/text editor so can be tweaked inside Blender too. You could choose from the standard Blender schema or hopefully multiple schemas from optionally paid outside contributors. I would like to switch from a desktop/keyboard/mouse workflow to a tablet/touch/stylus workflow without compromise.
I also would have thought removing the asset conversion stack from the Blender code base and having an external library like AssImp (tee hee) was a good idea. Other software could use the same stack, including integrating all the new open interchange formats. Eevee could have be used as previs before import, if it was properly separated from the codebase like Cycles was originally intended to be. But I guess not…
there was a GSOC about AssImp and I think it even succeeded I Just don’t know what happen to it afterward
Sometimes when I see a post like this, I try to guess how long before it turns into a dumpster fire.
The following opinions expressed in my reply can be hurtful and “potentially” seen as conservative and/or fascistic nationalism hate-speech based on extreme racism, violating european censorship laws. Please select the appropriate link if you feel encouraged to read my “$0.02” or Zero US Dollars and Two Cents.
Blender is awesome, but there is certainly some things that could be improved.
Non Censored Opinion
Blender now as it stands, feels a bit rushed.
Tossing features at it, is one thing, but finishing them, is another.
They are doing a good job, but I feel Blender is under pressure… and it shows greatly.
Other than that I agree with most of what has been written.
In my opinion, the hazard of designing the UI before work on the feature even starts is that you can box yourself in as development goes on.
You are coding an awesome new feature and realize that to make it shine, changes to your planned UI is needed, but instead let’s listen to those who say the UI should be final (from the first commit) and try to cram some square pegs into round holes. Perhaps the best way is to have an initial plan, but with ample room for revision while making sure you don’t fall into the trap of mission creep.
Granted this is more for production industries but…from what I’ve seen blender and coding as a whole does tend to follow this format. People sometimes over focus on this or that singular thing and don’t look at it in the big picture. Each feature, UI, workflow and all of that are not isolated things, they are all part of a larger whole.
If you want to be helpful for the process, give critiques, if there is something wrong then be accurate and concise when you complain about it, if you don’t like something then offer a solution when you voice your complaint.
It is not enough just to say that the UI feels rushed, although that is a start. Take a moment to find individual things that would be very useful. Would a feature such as having a click to add custom button to a side panel help mitigate the rushed feeling? If so then broach that when you offer your feedback.
Right now the hardest thing the Blender Foundation has to do is not improve blender, it is to not fuck it up in the process of development and that is a major thing that we the users of it need to be involved with. Voice opinion on what you like, on what works for you and what is a deal breaker.
All in for keybindings for everything. But not those dumb hints in the UI. I’d rather hide that toolbar all together.
Window->Show Status Bar toggles it on/off, but it seems to be per workspace.
No. They don’t run GSOC just to fix issues. They fixed some issues while GSOCs. There is a nuance, here.
But they mostly care about coding for UX issues during big UI design refactor like 2.5 or 2.8 series.
They produced a document that comes from years of thinking.
Community analyzed it.
Members of Community said : “that was great !”
Others said : “I doubt it will work but that makes sense.”
A second iteration of document is proposed.
Members of Community said : “I don’t see big problems!”
Other members said : “I want it, right now! Let’s go !”
2.8 starts. Hero is done. EEVEE is making Buzz. Spring is done.
Amount of Community members have doubled.
Old users are lost and new users are requesting that everything works without putting any effort into learning anything.
Developers are working a lot to satisfy us. But in front of them, they have to deal with a monster with thousands of mouths saying one thing and its opposite.
Perfect example. That is not a monstrosity. That is a solution similar to shift space to call toolbar that satisfies people that are not satisfied by shift space and annoys people that uses shift space.
It is not supposed to create keys conflict. You should be able to ignore it.
Currently, it is only available as an experiment into master.
If you have an issue with it, just express yourself in a way understandable by a developer.
If you take a look at developer.blender.org, you can see that there are something like 3 thousands tasks open. One hundred per developer.
They can not solve everything in a glimpse.
I don’t know in which order they are picking those tasks. I agree that is probably not a priority for a user with current amount of bugs, lacks of gizmos, etc…
But who am I to tell how Campbell should organize his time. He is maybe testing this before being forced to freeze something.
It is a statement that does not take into account complexity of a professional 3D software.
It is not the case. Between 2.79 and 2.8, many things were transferred to popovers and regions that can be hidden. You can hide every editor and region by pressing Ctrl Alt Space.
You can hide gizmos.
In properties, you have now subpanels that can be closed.
You still have a solo mode to only open one of them at a time.
You can create your own workspace and remove from them what you want.
Simply because Rome was not build in one day.
Grease Pencil evolved from an annotation tool to a 2D animation one during 2.7x series.
Ability to create interpolations between Grease Pencil frames was added just after 2.79 release.
The fact that GP became an object means that exposing its animations in dopesheet, NLA and graph editor is a big task. It means that animations of its materials, its modifiers, … all its data have to find a place in animation editors. They did most of that. But GPO actions are not similar to armature actions.
If they had to wait everything to be perfect to release 2.80, you would have to wait 2 more years.
You had to dig into python to do work that was not accomplished by lack of time for a task in stand-by.
That is not because they did not thought at all about workflow. That is because it is difficult to see big picture and amount of work needed when you launch such project.
If you want to provide a patch to display onion skinning in dopesheet on d.b.o, it probably will be accepted.
It is not because they will collect ideas from studios ; that remarks made on devtalk or here will be neglected.
There is a big probability that forums and studio critiques will cover same issues.
I agree with your post, but I am struggling to understand what you mean with the quoted section. Do you have some actual examples where this is or might become an issue?
You’re a bit all over the place here. You were talking about artist feedback helping to prioritize features. Well, I pointed out a particular “feature” that is being worked on because an artist (or artists?), apparently, didn’t like a menu. Some prioritization. Now you’re going to defend that?..
Did you actually try that feature? There’s exactly zero difference between hitting space, g and alt, g. None. Zero. Zip. Menu is just a non-argument. You hit two keys, it’s gone before you even notice it, or, in your own words, “you should be able to ignore it”. But if you want to notice it, it’s right there. “One of the major issues with the tool system, is that switching tools isn’t easy enough using the keyboard with the default keymap.” Two keystrokes. Either way.
“We want to make it obvious that a leader key has been entered, so that users know that the following key stroke will differ from normal.” If a giant menu in the middle of the screen where you’re already looking 99% of the time doesn’t make it obvious, yeah, surely a cryptic and prematurely-terminated string in a status bar will fare better… Where users won’t even know to look unless they already know to do so; so much for “making it obvious”.
In its current form, that feature doesn’t add any value to the application. And, as you yourself point out, there’s bigger fish to fry.
So? Experiment or no, this is something Blender could do without, at least at this point in time, IMHO, as an identical feature already exists.
I already have.
And they never will if tasks such as the above would keep popping up.