[Bf-funboard] Thought on improving panels

[Jude Jackson]

Thought: could mouse-over on a closed panel bring up a preview of its
contents? Would that be hard to do, and would it actually be an
improvement? How could the preview information be maximized while visual
obstruction is minimized?

On Friday, September 27, 2013, Jude Jackson wrote:

> 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
> > To: bf-funboard at blender.org
> > 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
> > 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>
>
>