Hi Petr,

> I guess the size of button is the reason for natural workflow with UI since I
> can start moving a mouse cursor exactly towards the particular button/tab
> and click it with only cursory glance at the side pane.

Yup, the big button size is a key factor. They're not just big to make them easier to look at for beginners, but also for everyone, experts and beginners alike, to be able to more quickly utilize them.

This is described by Fitts' law: http://en.wikipedia.org/wiki/Fitts'_law

Originally I made those buttons big to help make it easier to click on them with a pen tablet, which is sort of a bit more shaky than a mouse since it is harder to hold perfectly still. But this is one of those areas where tuning something for better targeting with the tablet also helps out for targeting with the mouse as well. I've been lucky that pretty much all of the tablet-oriented design stuff has turned out to be mouse beneficial as well.

Teeny tiny buttons in UI is kind of a pet peeve of mine. Especially on some laptops that have high density screens, it is amazing how tiny many buttons on other applications are.


> I think the command palette - with proper header name - which would be collapsed
> on default and would collapse itself after clicking on a button inside it, could be
> reasonable for less commonly used commands.

That's definitely the plan for the future addition of entire groups of new functionality. Like dimensions and annotations will have a "Dim" palette that is collapsed by default.

But there is still a problem that stuff that is added to a palette has to be in some kind of a group that contains more than one thing in it. If there are a bunch of palettes that only have one or two things in it, then the palette headers aren't providing any real savings over having the buttons somewhere up at the top level.

Sometimes the biggest difficulty is finding a good grouping for stuff - for example ShrinkTrimmedSrf is difficult to place right now.


> If there wasn't space enough in the side pane, other palletes would
> collapse/expand appropriatelly so layout of the side pane would look
> identically before/after using those commands.

The collapsing part of this is implemented right now - you can see this if you shrink the window down (BTW I just found and fixed a bug where the mouse cursor doesn't switch to a sizing cursor when you are on the edge of a non-maximized window. But it still will still size right now if you grab there anyway despite what the cursor looks like) so that there isn't as much vertical room. Now when you activate a palette, other ones will collapse to try and make space and prevent the scroll bar from appearing.


I had thought a few times about making File be a tab on the side pane instead of a pop-up menu type thing, but yes the recent file list on it makes it pretty natural to have as a pop-up menu. It also just seems somehow natural to have as a menu because of similarity to "old fashioned" UI systems that have a menu bar.

- Michael