UI, Icons, Etc.

 From:  Michael Gibson
11.4 In reply to 11.3 
Michael, thanks very much for the feedback!

> However i think if the toolbars always stayed in place instead of
> shifting up and down depending on which tab or tool is chosen, i
> think it would be easier to use the tools (one could almost use
> them blindly after a short while).

Yes, I agree that this is the main problem with the current UI structure. I had earlier designs where the subtools showed up all the way at the top of the side pane above the command prompt area. This kept things from shifting around, but it was pretty awkward to use since you had to move your mouse a long distance away from the launching button to reach the subtools, it was especially bad for stuff where the start button was near the bottom of the pane. There was also a discoverability problem because it was pretty easy to just not notice the subtools way at the top. I felt that these were quite a bit worse problems than the shifting, so I decided to have the shifting as a lesser of two evils. The other factor is that I have unusually large squarish buttons, they should be significantly easier to target than regular buttons, so that should help as well. The final straw was that just the entire side pane is not fixed even without the subtools since you can activate different tabs within the pane, changing its configuration. So really the entire system is just not a fixed-place thing altogether, that also made me more willing to incorporate the subtool shift as well.

The only other alternative that I could think of for the sub-tools would be to try and show a little pop-up / flyout menu there. But that has other problems of its own since the pop-up would cover up other tools. It would be kind of visually weird also when you didn't need to actually access the pop-up in the case where you wanted to use the default activated sub-tool, which I hope to be the case pretty frequently. There were some other possibilities such as the more standard way where the sub-tools are only shown if you do something special such as hold down and wait for a moment... I really don't like that type of hidden mechanism for something that is pretty basic bread-and-butter functionality though.

Having the subtools really easily accessible has made it much easier to organize things, I've been much more willing to group things there which has helped keep the UI more streamlined.

Anyway, that's the story behind the current design with the shift. Each design including the current design has its weak points, but I think that the current one has less problems than any of the other variants that I have been able to come up with so far.

> The double fuction of clicking the tabs either for collapsing between tabs
> or switching tabs seems rather confusing (collapsing seems unnecessary
> at this point, i do realise this might change, once the number of tools
> increases).

Yeah, the second click for collapsing the pane is not really necessary at this point, but I thought it would be nice to have some mechanism to have explicit control over collapsing the palette. I considered having some kind of expand/collapse icon to the right of the tabs, but it was visually distracting and annoying since it will not need to be used very frequently, I think. Clicking on an already active tab just otherwise did nothing at all, so I went ahead and made that the collapse mechanism.

The panels do automatically collapse if there is not enough space to show them - since there are not too many right now this is only really seen if you size the main window down quite a bit.

Definitely the collapsing will become more prevalent as the number of tools increases. Over time there will be many new palettes added over there. The nice thing about this UI system is that it is set up in advance to be scalable as more stuff is added over time.

> The typical alt-middle mouse button shortcut to rotate-view would be nice to
> have as well, just in case i do have a keyboard available.

For a mouse you can use the right mouse button drag in the 3D viewport to rotate in the way that you like. The rotate button is sort of more intended for tablet users, the continuous motion helps with the tablet use because you can't really pick up the pen and "scrub" it like you do with a mouse since it uses absolute positioning. So for the pen it is nice to only need to make pretty small motions to manipulate the view.

For mouse users, the middle button, right button, and scroll wheel also can be used within a viewport for manipulating the view. So there is not much need for mouse users to use the Pan, Rotate, or Zoom buttons in the little panel, although they are certainly available if you want to have the different feel. The Area and Reset buttons in that panel are still quite useful for mouse users as well.

Thank you so much for the feedback!

- Michael