[Bf-funboard] Thought on improving panels

Jude Jackson syzygy6 at gmail.com
Sat Sep 28 00:34:07 CEST 2013

I was not aware of the Ctrl+click feature, that is handy. As for your other
suggestion, well, maybe it would be easier to implement (obviously I don't
know much about these things) but that hardly seems like a good reason in
itself to make it.

Automatic behavior may very well be tricky and I can't blame the developers
for not fiddling with it when just making a consistent UI is already a
challenge, but I would like to see people warm up to it more because it
helps when it's done right.

Actually, more than just making panels less dumb, it would be sweet to have
expandable icons like Photoshop and Illustrator have. The way they have it
set up, you have a list of icons on the side of the screen, and you click
one to expand one of those tab groups that would normally clutter the
screen. If you need a tab to stay open, you just rip it out of the icon
list. That way, only the amount of screen space that *needs* to be used at
a given moment is used. With the current region system, a panel has to take
up a chunk of screen real-estate whether it's in use or not.

I wonder, would it be possible to make it so all panels can behave like
tabs in photoshop? The region system isn't bad, but I don't see why it
would hurt to also allow users to open the 3D view full-screen and just put
a bunch of tab groups on the side, if that's what they prefer. It's a valid
workflow and it seems to me, as an ignorant yokel, that it's not mutually
incompatible with the current system. The only conflict that comes to
mind is that photoshop tabs were designed to fit in a particular-sized
space, while blender panels can be however long they want (but that
wouldn't be a problem in the expandable icon system).

On Friday, September 27, 2013, Bol Bib wrote:

> Automatic behaviour is hard to get right and might annoy more then it
> solves .
> You can however already have 1 panel open and all other closed via
> CTRL+click on tabs. Not automatic but very handy.
> There is also a GSOC student that is working on the toolbar and has
> introduced an icon on the panel header that you can access  it's contents
> without opening it. I'm crossing my fingers that this will be used in all
> panels,everywhere.
> other then that automatic opening on mousover could also be more
> problematic then it's worth. It could be tested,sure.
> I myself would prefer to be able to switch between 2 states of a tab or
> shelf. 1 with frequently used panels. 1 With not frequently used panels.
> You should be able to customize at will.
> That would be a much clearer and straightforward solution without
> resorting to hard-to get right automatic features.
> And some icons here and there couldn't hurt  (but not too much)
> > Date: Fri, 27 Sep 2013 17:27:25 -0400
> > From: syzygy6 at gmail.com <javascript:;>
> > To: bf-funboard at blender.org <javascript:;>
> > Subject: [Bf-funboard] Thought on improving panels
> >
> > I'm talking about panels as defined here:
> > http://wiki.blender.org/index.php/Doc:2.6/Manual/Interface I think I've
> > seen panel used to mean region so I want to clarify.
> >
> > So I think that there's a few tweaks that could be made with panels
> within
> > the current design paradigm. Right now there are a few minor annoyances
> > that come with panels that could be fixed with some minor redesigns.
> >
> > First, I think it would be nice if the region auto-scrolled when you
> expand
> > a panel. It's a minor touch, but the only reason to expand a panel is if
> > you want to look inside, so it makes sense to make all the panel contents
> > visible instantly. This would simply entail, when a panel is expanded,
> > scrolling so that the entire panel is visible, or until the beginning of
> > the panel is at the far top or left side (right, I suppose, in left-hand
> > languages). It's a minor automation that would save a lot of scrolling.
> >
> > Another thing that might be more controversial but would be helpful to
> > users with limited screen space is to automate the opening and closing of
> > panels. For almost all menus, the total information does not fit within
> the
> > height of my screen. For me, it is actually more useful to have an
> overall
> > view of the entire menu than to have immediate access to one set of
> > controls but have to scroll to see the rest. What might help is if I
> could
> > enable a feature that automatically keeps all but one panel minimized at
> a
> > time. In effect, this would make panels behave like tabs.
> >
> > This leaves a bit of room still for designing the UI. One, how do users
> > switch between active panels? My first thought was to make it
> instantaneous
> > with mouse-overs, minimizing the need for precise clicking. However, for
> > some layouts this could cause problems with users idly moving their mouse
> > over multiple regions (although this problem is minimal with small
> screens
> > because there isn't room to have lots of regions arranged next to each
> > other).
> >
> > Another option is to use the scroll wheel. Although there could be
> > some ambiguity if a user is scrolling through a large panel as to where
> one
> > panel ends and the next opens, good feedback design could minimize that
> > (consider on iOS the swipe to reload feature, which is often accompanied
> by
> > an elastic bubble to show if you scrolled enough).
> >
> >
> > Even though these might reduce scrolling, they still don't solve the
> > problem of information density. Perhaps there could be an entirely
> > different solution. Perhaps collapsed panels could display some
> information
> > (maybe even collapse into a miniature version of themselves). Perhaps in
> > more cases information needs to be separate from functions. Maybe Blender
> > just needs icons. But perhaps that's for another time. In any case, I
> look
> > forward to thoughts and feedback.
> > _______________________________________________
> > Bf-funboard mailing list
> > Bf-funboard at blender.org <javascript:;>
> > http://lists.blender.org/mailman/listinfo/bf-funboard
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org <javascript:;>
> http://lists.blender.org/mailman/listinfo/bf-funboard

More information about the Bf-funboard mailing list