[Bf-funboard] Space saving UI proposal

[Paulius Mscichauskas]

"What I don't like in this proposal is changing the headers while the panels
are docked. This creates too much visual clutter. The alignment issue with
check boxes is easily solved by offsetting text in panels that don't have
check boxes by one space."

I agree with check boxes.
My speculated changes do not strike me as visual clutter. They were
inspired by the Zbrush menu on the right and the old panel appearance in
2,49. For me, it looks more pleasing. My goal was to tackle these two
points:
The GUI should communicate that floating panels and docked panels are the
same thing.
Each panel is a different entity with boundaries.
However, these changes are not essential for the main point of the proposal
- floating panels.

"Another thing that is a no go is having per 3D view settings for each
modifier."
Could you elaborate on that?

"Tabs design is slightly weird here and lacks any kind of information.
Remembering "feature X is in n tab" is harder and more abstract than
remembering "feature X is in the Tools tab".

The mockups lack icons. There would be icons. I just didn't want to bother
to draw them.
So it would be more like "feature x is in tat marked as *icon*"
Just like it is in the properties editor.
Icons are easy to recognise and read.

"* Cursor settings *is* (potentially) specific the the 3D view; aside
from the scene global setting, each view can have it's own cursor. This
might complicate the proposal a bit."
Can you actually use a different position of the 3D cursor on different 3D
views?
 If you could, I would surely agree with you.
I don't think you can. The location of the 3D cursor right now is a global
setting, not 3D view editor specific.

"* Mirroring transformation in the 3D view and Properties by default is
not 'consistent' or 'compact' but it is very pragmatic, as it is very
handy there, less so in properties. So moving it to properties by
default and not in 3D view has the practical effect of taking something
commonly needed and putting it somewhere more hidden.. (the rest of the
proposal helps you get it back, but not by default - new users will
struggle to find it, experienced ones will be forced to tweak their uis
every time)"

Of course it's consistent and compact.
Consistent, because the panel would not be in the same menu as 3D view
settings, compact because there is no duplicate, less panels in the 3D view
settings.

Is the "transform" panel very handy in the N shelf? Of course!
But the same goes for plenty of other panels in the properties editor.
Why should transform have a bigger priority? Priority depends on what you
are doing.
If you are modelling, it's handy to have the transform panel in the "N"
shelf, but if you are setting up materials, it's handier to have the
materials panel there instead.
There is no objective priority for one over the other.
And that is why, in my proposal, the user is given a free choice on what to
prioritize himself. He can have the materials panel or the tranform panel
in the "N" shelf or as a floating panel, or both, or neither.

Btw, as it is written in the proposal - The "N" shelf would have a "Custom"
tab. All panels that were removed from the 3D view settings because of the
changes, could be placed there by default, just so it would be easier for
users to adapt to the rearrangement.

Also, there are other defaults to be still thought through... For example,
the default blender file could have the transform as a floating panel right
there, on the top right.

Btw, experienced ones will not be forced to tweak their UIs every time.
That's what floating panel layout presets are for. Also, they are not
forced to use floating panels at all, they can reach the same controls when
they are in menus too.

"* I think needs more design and thought, for instance: can you drag/pin
a panel from the UV image editor or node editor into the 3D view? what
happens when node selection/material/image in the original editor
changes? why floating panels in the 3d view only?"

As it is described in the proposal, all editors that have the "N" shelf
would have floating panels in them. Not just the 3D view.
Any panel from the "N" shelf would be able to become a floating panel
within that editor. The 3D view was just used in the mockups as the best
representation of the advantages.

Also, as it is described, the user is not allowed to bring a panel from one
editor to the other. So panels that belong to the UV editor can not be
dragged to the 3D view or any other editor, but itself.
The only exception is, that the user is allowed to bring floating panels
from the "properties editor" to any "3D view". That's because, these two
editors are exceptionally related.

These limitations would make context sensitivity identical to what it is
now.
There should be no context sensitivity problems. Not any more than there
are currently.

"* More design and thought: I see blender in this proposal as a sculpting
application, with no consideration for animation, rigging, compositing,
or any other workflow."

The proposal describes on how things could work. What can be achieved with
floating panels is kind of a matter of the users imagination. The user is
free to use these possibilities any way he wishes, for anything he does,
for any workflow he has.
Sculpting was just a single example. I could've drawn another kind of
example, but I just happened to draw sculpting. One example, i believed,
was enough to convey the possibilities. Mocking out all possibilities is
simply unnecessary.

If it's hard to imagine how floating panels could used for, let's say,
rigging, here's an example:
If you are setting up bones, you could drag out the "constraints list"
panel and "transform" and perhaps "Shape keys" panels out of the properties
editor onto the 3D view for pose mode; "Brush" and maybe "Vertex groups"
for weight paint mode.... You are free to drag out whatever you want/need
after all....


I did post this proposal on developer.blender.org
Brecht closed it and said that i should upload the proposal to the Wiki
(Which I didn't figure out how to do, so if anyone could do it, that would
be great) and then post it to bf-funboard to invoke discussion. He said
that developer.blender.org is for things that developers are actually
working on or plan to work on, not proposals.





On 10 April 2014 00:09, Antony Riakiotakis <kalast at gmail.com> wrote:

> That is a very valid concern that I see often the paint/sculpt community.
> Some people see the software as an exclusive paint/sculpt application and
> prioritize presentation of information relevant to that workflow only, and
> usually similarly to other software.
>
> I will repeat this here, blender is not Bbrush. For instance I often see
> requests about scultping features that can easily be done in edit mode. Of
> course solution there is not to replicate the functionality in sculpting,
> but make edit mode itself faster.
>
> As Bassam said blender has to cater for all different kinds of workflows,
> and while presenting information in a compact way is desirable, doing so in
> a non specialized software is much more challenging.
>
> I have some opinions on the matter but better separate the proposal to sub
> tasks and continue on developer.blender.org,
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard
>