[Bf-funboard] Space saving UI proposal

[Jude Jackson]

>
> Needless to say, the floating panels are not consistent with Blender's "no
> overlap" principle


Good grief, I can't get over what a poisonous obsession that "no overlap"
garbage is. Fact is, overlapping interfaces are super good when they're
used appropriately. I'll freely acknowledge that Adobe Illustrator pre-CS3
was clunky, but after CS3 introduced the iconic panel paradigm, it was
basically proven in no ambiguous terms that allowing elements to overlap
appropriately is massively more useful than any system where users are
forced to rearrange their workspace to switch tasks.

Fortunately from what I've read the Blender developers aren't luftmenschian
ideologues and are fully aware how irritating that standard is, and are
working out how to reintroduce overlapping elements.

That said, I like a lot of parts of the proposal, though I think it could
learn a lot from Adobe's UI developments. The 3D/2D viewport could be
treated much more like Illustrator/Photoshop artboard, and have a more
robust UI paradigm within it, allowing more features to be available at a
given time without necessarily taking up excessive space. The tabs, for
example, while not necessarily useful while sculpting, provide an
opportunity for some unobtrusive flexibility accessing marginal features
that in the current paradigm require the user to either memorize shortcuts
or manually rearrange the interface. If you haven't used any of the more
recent versions of Adobe software, I recommend checking it out.


On Sun, Apr 20, 2014 at 11:40 AM, Paulius Mscichauskas <
pauliusmscichauskas at gmail.com> 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
>