[Bf-funboard] Space saving UI proposal

[Jim Cantley]

I don't mean to sound rude and very much enjoy this email subscription but this is the greatest number of emails I have ever received in such a small time period and think this is better reserved for forums or ICQ or something. I may be mistaken here and apologize if I am but I wake up to a load of emails and this has happened recently as well as it has today. Blender rulz, the ideas rulz, just not in large amounts in my mailbox! :P

> Date: Sun, 20 Apr 2014 10:38:10 -0700
> From: joeedh at gmail.com
> To: bf-funboard at blender.org
> Subject: Re: [Bf-funboard] Space saving UI proposal
> 
> Isn't this sort of situation what RNA is for?  IIRC, sharing panels across
> editors should be as simple as storing the context for the editor the panel
> came from in the panel.  I could be remembering wrong, though, and I
> imagine there would still be problems and conflicts (e.g. you wouldn't want
> the user to drag panels that reference a specific editor instance outside
> of that editor).
> 
> 
> On Sun, Apr 20, 2014 at 9:31 AM, Paweł Łyczkowski <pawellyczkowski at gmail.com
> > wrote:
> 
> > Hi
> >
> > >
> > > 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)
> >
> > Cheers
> >
> >
> > 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
> > _______________________________________________
> > 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