[Bf-committers] Tool Shelf Toggling On/Off Tab Mockup

Jim Williams sphere1952 at gmail.com
Mon Jun 13 15:54:15 CEST 2011 

I've nothing against icons as an option that can be toggled on/off (or
at least minimized) in order to get more real estate.  I just object
to them as the initial, only, or default interface.

(BTW -- My Gmail is all buttons and text.)

On Mon, Jun 13, 2011 at 9:25 AM, Luke Frisken <l.frisken at gmail.com> wrote:
> I think you are right in one sense. But, I look up here at a toolbar in my
> gmail and see icons that I have never clicked on and I'm pretty sure I know
> what they do. I'd call that self explanatory... I guess it takes a knowledge
> before hand of the function, or a previous encounter with a similar looking
> icon to be able to guess what it means. So, for a tool shelf you could use
> something that looks like a tool... Either way it can be hard to guess
> exactly what it is, even after clicking on it, or finding it in a menu and
> clicking on it; like you suggest. This is where tooltips are fantastic at
> filling in the gap between proper wiki documentation, and none at all. It
> allows people who know vaguely what they are doing to have a better guess at
> what the function is supposed to do.
>
> The sense in which I think you are certainly right is that the current
> menu hierarchy is the standard way of finding this functionality, and is
> something we shouldn't change, because many users rely on this to find what
> they need, and this is also standard behaviour in any software. This is a
> good thing I think. Buuut, the thing is, that T and the N panel are toggled
> on and off very frequently in my workflow (and I would guess others, because
> otherwise this issue wouldn't have been raised), so having as
> a separate icon in the corner, (like where the plus sign was), would help
> greatly for people who prefer to use the mouse (less clicks and mouse
> movement required), and be an even bigger improvement for people who use the
> tablet. Or, do we want to take the direction of favouring keyboard support?
> I'm not personally against that, but I know people who are better at
> remembering positions of icons than random letters on a keyboard. I think I
> can guess T, but what does N even stand for!? For Non-English, or English as
> a second language users I reckon this would be even harder, because they
> would have a harder time guessing what T stood for and associating it with
> the functionality in blender.
>
> On Mon, Jun 13, 2011 at 9:21 PM, Jim Williams <sphere1952 at gmail.com> wrote:
>
>> I have never found any icon scheme self-explanatory.  I think
>> absolutely everything should be available through a menu hierarchy so
>> everyone, even beginners, knows that there is at least one way to find
>> anything.  (I do mean everything, including text fields, checkboxes,
>> and dropdowns.  It doesn't have to be a shallow hierarchy.)  If you
>> have that then you can provide the hotkeys in the menu and do
>> everything with hotkeys and pop-ups too. People will look up the
>> hotkeys in the menu and learn them for anything they use a lot.  If
>> you don't have everything on a menu then there will be a constant
>> stream of questions asking where and how for simple stuff.  With
>> everything somewhere on a menu people will groan and hunt it down.
>>
>> On Mon, Jun 13, 2011 at 6:59 AM, Felix Schlitter
>> <felixschlitter at gmail.com> wrote:
>> > I couldn't agree more with Michael. Hotkeys for restoring headers, or
>> > locking them would be wonderful!
>> >
>> > And on topic: I also never use the toolshelf for anything during
>> modelling
>> > other than getting access to the operator panel. F6 is awesome but it
>> would
>> > be more convenient to have it sitting in a compact shelf (especially for
>> > complex operators like the tree generator and stuff).
>> >
>> > I like the proposal, however it would mean that the user has to learn yet
>> > another hotkey or move the mouse all the way over. Atm, I kinda like the
>> > whole N/T hotkey scenario where I press the T, which lays on the left
>> side
>> > of the keyboard (for english keyboards anyway) to hide the left sidebar
>> and
>> > vice versa.
>> >
>> > Maybe a "Maya toolshelf" could be taken into consideration, which sits on
>> > top of the screen and can also be hidden like a header. Then we could use
>> > icons instead of text in order to save space. We would just need to make
>> > sure that the icons are a bit more self explanatory than those used in
>> Maya.
>> > Then the operator would sit in the left sidebar by itself, or could get
>> > company some of the items from the right toolbar.
>> >
>> > Just an idea
>> >
>> >
>> >
>> > On Mon, Jun 13, 2011 at 9:44 PM, michael williamson <
>> > michaelw at cowtoolsmedia.co.uk> wrote:
>> >
>> >> Sadly there's no key to restore a minimised header! (they're all to easy
>> >> to close when using a tablet with no way to restore in the cycles
>> >> branch! (for headers I'd like to see the old 2.49 way and disable
>> >> minimising them....)
>> >>
>> >> ON TOPIC,
>> >> I'd prefer tool props to be its own panel.... it's too small when at the
>> >> bottom of the toolshelf  I always use F6 in preference....
>> >>
>> >> The toolshelf itself is invaluable in paint, sculpt etc but something I
>> >> don't use ever when modelling... the operator panel on the other hand is
>> >> something I'd very much like to have on screen all the time when
>> >> modelling but hardly ever when painting!
>> >>
>> >>  I only mention to illustrate that people are different and like
>> >> different things and a flexible UI should accommodate ;-)
>> >>
>> >>
>> >> On 13/06/11 10:01, M.G. Kishalmi wrote:
>> >> > I like how Brecht solved this in the cycles branch:
>> >> >   he removed the (+) icons all together.
>> >> >
>> >> > there are keys for props [N] and tools [T]
>> >> >   and menu entries (in view) for all 3.
>> >> > maybe we can simply add a key for tool-props? suggestion: [ALT]+[N]
>> >> >
>> >> > or maybe.. don't allow the tool-props to be hidden at all?
>> >> >   just find a way to have it sit there at the top/bottom of the tools
>> >> nicely.
>> >> >
>> >> > cheers,
>> >> >   mario
>> >> >
>> >> >
>> >> > On Mon, Jun 13, 2011 at 6:19 AM, Jonathan Smith<j.jaydez at gmail.com>
>> >>  wrote:
>> >> >> You are probably right, using a lot of space doesn't seem to be the
>> best
>> >> >> answer.. back to drawing board.
>> >> >>
>> >> >> On Sun, Jun 12, 2011 at 11:31 PM, Jim Williams<sphere1952 at gmail.com>
>> >>  wrote:
>> >> >>
>> >> >>> I'd agree.  Find ways to use less real estate, not more.
>> >> >>>
>> >> >>> On Sun, Jun 12, 2011 at 9:04 AM, Aurel W.<aurel.w at gmail.com>
>>  wrote:
>> >> >>>> Hi,
>> >> >>>>
>> >> >>>> I think that this would be rather unpractical, it takes way to much
>> >> >>>> visual space for what it represents. If i want to collapse those
>> >> >>>> panels, i want them gone, not taking a lot of space on the screen
>> like
>> >> >>>> those huge buttons.
>> >> >>>>
>> >> >>>> Blenders gui already got way too unefficient in 2.5, especially
>> when
>> >> >>>> it comes to, space needed for certain gui elements and panels.
>> >> >>>>
>> >> >>>> aurel
>> >> >>>>
>> >> >>>> On 12 June 2011 13:28, Jonathan Smith<j.jaydez at gmail.com>  wrote:
>> >> >>>>> I have written up a mockup/proposal on a different way to do the
>> >> closing
>> >> >>> and
>> >> >>>>> opening of the Tool Shelf and Properties Shelf UI, other than
>> using
>> >> the
>> >> >>>>> little plus icons, on my talk page.
>> >> >>>>>
>> >> >>>>> http://wiki.blender.org/index.php?title=User_talk:JayDez
>> >> >>>>>
>> >> >>>>> I am, unfortunately, not a good enough coder to actually implement
>> >> this,
>> >> >>> so
>> >> >>>>> I'm just putting it out there as an idea, either for another coder
>> to
>> >> >>>>> implement, or just to promote discussion about the way this works,
>> >> since
>> >> >>> I
>> >> >>>>> don't think that it is done very well in the current version of
>> >> Blender.
>> >> >>>>>
>> >> >>>>> Any comments on or critiques of the mock up would be welcome.
>> >> >>>>>
>> >> >>>>> Cheers,
>> >> >>>>> Jonathan
>> >> >>>>> _______________________________________________
>> >> >>>>> Bf-committers mailing list
>> >> >>>>> Bf-committers at blender.org
>> >> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >> >>>>>
>> >> >>>> _______________________________________________
>> >> >>>> Bf-committers mailing list
>> >> >>>> Bf-committers at blender.org
>> >> >>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> No essence.  No permanence.  No perfection.  Only action.
>> >> >>> _______________________________________________
>> >> >>> Bf-committers mailing list
>> >> >>> Bf-committers at blender.org
>> >> >>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >> >>>
>> >> >> _______________________________________________
>> >> >> Bf-committers mailing list
>> >> >> Bf-committers at blender.org
>> >> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >> >>
>> >> > _______________________________________________
>> >> > Bf-committers mailing list
>> >> > Bf-committers at blender.org
>> >> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >>
>> >> _______________________________________________
>> >> Bf-committers mailing list
>> >> Bf-committers at blender.org
>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>
>> > _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>>
>>
>>
>> --
>> No essence.  No permanence.  No perfection.  Only action.
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> >From Luke
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
No essence.  No permanence.  No perfection.  Only action.

More information about the Bf-committers mailing list