[Bf-funboard] Space saving UI proposal

[Paulius Mscichauskas]

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
>>
>
>