[Bf-funboard] Space saving UI proposal

Paweł Łyczkowski pawellyczkowski at gmail.com
Sun Apr 20 18:31:21 CEST 2014


> I'd love if some developers in the UI team to read this and give their
> thoughts.

Dragging panels into the 3d View seems like a good idea from the design 
standpoint (I'm not sure if it's feasible code-wise atm). I would 
consider it when the 3d view layout/organization will be on the table, 
but in my opinion panel migration form the n-sidebar and the following 
n-sidebar removal (the "one sidebar per window policy"), combined with 
the ability to hide unused panels would be a better solution for 3d 
Viewport cleaning-up (yes, there would be some unused space when there 
will be less panels than the height of the sidebar - not that big of a 
deal IMO with one sidebar).

But if I were to comment on your proposal - it adds quite complicated 
functionality (like the floating panel layout presets). I would go for 
UI simplicity first.

That's how I would envision it:

- drag a panel from the toolshelf or properties panel only (I think 
adding them from other windows would be a coding nightmare, and probably 
has scenarios when it fails)
- place the panels on the edge of the 3d view only (allowing them to be 
placed anywhere would cause problems with collapsing sidebars), in a 
spot that is the percentage of the window width or height (so no panel 
will go out of view - they will be able to overlap though)
- a button to enable/disable floating panels (automatically turned off 
in 3d Views, turns on in a current window when you drag a panel out), no 
floating panel presets (for simplicity's sake)


Paulius Mscichauskas wrote:
> Any one else have thoughts?
> I'd love if some developers in the UI team to read this and give their
> thoughts.
> On 10 April 2014 02:26, Paulius Mscichauskas
> <pauliusmscichauskas at gmail.com>wrote:
>> "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
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard

More information about the Bf-funboard mailing list