Ran into a problem today on my surface where the layer list panel isn’t big enough to show the layers nested wayyy in. It only happens once I get super deep into the layers but once I hit that certain point I can no longer control those layers in the Tree.
Some ways to fix this would be to make the Tree panel horizontally scrollable, another way would be to make the Tree panel resize-able.
A bug!?! This sounds like a feature request =P
Totally agree. Ryan and I have talked about it but it always got pushed to the end of our TODO lists. I’ll take a look and see if we can get it in soon.
It’s not clear if resizing or scrolling would be better.
I’m leaning towards the former, but the latter may be necessary to have when using drag and drop (OS X finder has a nice automatic scroll when you are holding an item to drop elsewhere.)
There may be some other alternatives like reducing the indent too.
Will do some research and get back to you on this, thanks for the post.
We actually had dual-axis scrolling in an earlier build, but we removed it due to some technical tradeoffs.
My initial preference would be to allow resizing of the panel, as well.
Pros:
Cons:
It’s also possible we could implement both, but I know there are some technical issues we’ll have to work around for that.
I think both options are good solutions but resizing the layer panel seems like the better of the two. One problem this causes is a smaller workspace when you’re deep in the layer panel but that trade-off seems fair and consistent throughout other design tools.
@rrbarry11 Ryan and I implemented horizontal resize of the tree panel today, so it will be in the next release. Thanks again for bringing it to our attention!
@kevin @Ryan to expand on this and add panel resizing to the history panel? So by that I mean, I want the ability to make it smaller in height, so it would in the end give more room to the layers panel.
Reason being, I don’t find myself using the history panel often, only in special cases when I need to go wayyy back.
But this could be completely opinion based, which is why resizing would fix this.
This ties into a larger discussion of how we should handle the UI “chrome” in Subform. There are two general approaches in most design tools:
Fixed UI The design app’s panels are mostly fixed in place. The UI can be shown or hidden, but it can’t be customized or moved. Sketch falls into this category. I think a lot of folks like the simplicity of this approach—you don’t have to spend time customizing your workspace or constantly toggle panels on and off to do your work. Every option is (more or less) visible at once.
Workspace-style UI The design app’s panels are fully customizable in their placement and size. Most advanced tooling uses this approach (all the Adobe apps, lot of CAD and 3D tools, etc.) because there’s just too much UI to fit onto the screen at once. Different users have different needs and preferences, which customization supports well. (e.g. you don’t use the history panel much, so don’t need it to be visible at all times) Screen real-estate can be limited, though, so you can spend a lot of time tab-switching and panel toggling to perform actions.
Subform’s UI is a bit in limbo between these two approaches right now and probably not gaining the advantages of either. Kevin and I have had discussions about approaches, but we’ve decided to punt on this for the time being until a) Subform’s basic feature set is pretty baked and b) we have a better sense of what would work best for Subform users.
One of the ideas we’ve been tossing around is actually a third approach: moving to more of a “information at the point of need” contextual UI. Panels take up a lot of screen real estate at the cost of seeing the design that you’re working on. In a perfect world, you’d only have UI at hand for the action you need to take at any given time. This approach isn’t a slam dunk: discoverability is impacted, some panels probably need to be visible most of the time, etc.
That’s a long answer to your feature request. 
tl;dr: I think we probably won’t add any more UI resizing in the short term, but the issues of screen real-estate and UI customization are on our radar. If you have thoughts on what approaches you like in other tools, we’d love to hear them.