Not surprisingly, there was quite a bit of a discussion during today's developer meeting on the Tabs design. Read the details of this meeting below.
Ton Roosendaal writes:
Hi all,
Here's the notes from today's meeting in irc.freenode.net, #blendercoders
1) 2.70 stuff
- We're still in "BCon3" - bug fix, stabilize new features.
- Tamito Kajima has a patch ready for Freestyle Python API reorganization, which will break older scripts. Suggested is to involve Lee Posey from http://blendernpr.org/ to write about it, and make sure the change is well supported and understood by everyone.
- Bastien is still working on solving FBX issues, which hopefully gets in the next release.
- Most of the meeting time then went on about the toolbar/tab topic!Ton Roosendaal expressed concerns that the new tabs are not clearly presented (or even designed) well, which causes too much discussion and opposition. Some people consider it work-flow centric, other see it as a fixed navigation feature. Some think most tools should be now become availble as button, others just want to be able to make custom tabs. Some think it's only for the toolbar region, others think it now will be added everywhere. Also the quite strong opposition against the "ui clutter" with vertical bars has not answered to in a satisfying way yet.
In order to respect our release cycles, this topic should have been settled already... or we should postpone that to 2.71. It might be better to have design and code teams explore ways to handle these tabs (and other toolbar proposals) better.
With the next "BCon" still 4 weeks away, we can wait a week with final decions on planning here. Jonathan Williamson thinks he knows how to get everyone (well almost all) happy with it. Will come back on the agenda to decide next week.
2) Other projects
Thanks,
-Ton-
32 Comments
A rose by any other name...
For the sake of consistency, shouldn't the tab design look like what already exists within Blender? The header in properties window functions in pretty much the same way as tabs, giving you different options based on which button in the header is active. Isn't that the whole idea behind tabs? Calling them tabs or buttons doesn't really change their functionality. Since they function the same way, shouldn't they also have the same appearance?
As far as the properties window goes, I think it should take a clue from the current tab proposal. I'd like to see the panels made pin-able so only one was open at any given time by default. It seems to me that could eliminate a lot of scrolling, much like what we're trying to do with tabs.
And could someone please explain why pinning a panel should work differently with tabs than it does anywhere else in Blender?
The current tabs (such as Property Editor, User Preferences, etc) use really poor tab design. Primarily because there's nothing that visually indicates that they're tabs. So rather than work purely with the current design, I'm proposing the new design along with updates to the existing tab-like areas.
As to pinning panels, you've never been able to pin panels. You can pin entire Regions, but not panels. So this functionality is new and currently restricted to the toolbar (although this should be made global probably.)
It seems I haven't followed closely enough. I underestimated the depth to which the UI team is working on the tabs project. My biggest concern was that this project was going to break consistency, based mainly on outdated snippets I read weeks ago. I appreciate the links you've added to some of the other comments. It's not always easy to know where to get the most current info on these subjects.
Overall I don't really hate the direction these tabs are heading, but I wonder if there will be a logical (consistent) way of determining which tabs are text and which ones are icons. I think both can have their place so long as there is some sort of contextual logic involved. Even panels could be viewed as tabs (or at least sub-tabs) which is why I like the idea of having only one open by default with the option to pin them. And you're right, the properties tabs currently look more like buttons, or even too much like the editor selection drop-down next to them. I looked at your proposed update to that and would encourage you to push it just a little further. Simply getting rid of the rounded corners on the bottom may be too subtle.
As far as pinning, I see that is still evolving too. My question was referring to an earlier proposal which would have the pin icon replaced by a plus button, which would seem to be inconsistent with current pinning options (panel or region, pinning is pinning). I see that plan didn't stick. Again, a victim of old info...
On another note, I'd love to eventually see some optimizations for dual screen work-flows. Currently Blender recognizes input based on which editor the cursor is over, but if your using multiple windows, you have to click a window to activate it. It would be great if window could be treated more like floating pallets. Not sure how that all works, my coding experience is mostly limited to BASIC on an Apple 2. Not sure how much of that I would even remember twenty-some years later. Custom screen layouts would also be much cooler if they worked on a multiple window basis. Maybe someday...
If the tabs feature still cannot be considered stable, then perhaps it should come out for now.
By the way, following up my comment about greater use of branches on the previous developer meeting notes, looks like this is happening, in a way, except in the form of entirely separate repos. Like this one.
The feature is stable, its just nobody agreed on layouts for each space-type.
Wouldn't it be more efficient to have the saved views as tabs rather than dissecting the properties panel?
I would prefer to have a Modelling Tab, a UV tab, Animation tab. I find the current dropdown list rather slow.
Also it is something that could be done very quickly in terms of development
That's part of my larger proposal that goes along with the toolbar tabs: http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Tab-Interface#Properties_Editor
Note: I'm actively updating that proposal, so it's sketchy in some places.
The tab thing worries me. Don't we already have tabs in properties panel? Why these differ?
Also everything in blender is pinnable/adjustable, which is good for for ever-growing interface. I hope this system won't be a rigid one.
Most importantl - could it be that switching between tabs will be obligatory? Like, say, taking 0.5 seconds to switch for every few actions? Looking and being consistent are two different things - being consistent gives free time not takes it.
Are tabs available for testing?
Sorry for ignorance, it seems tabs went far from where I've seen them last :)
Are there any test builds?
The toolbar tabs are in the Build Bot versions right now. Note, they are not finished and are subject to change. Some areas, such as the Edit Mode tabs have barely been touched. You can download a build from here: http://builder.blender.org
As for the other tab-like things in Blender, this is being covered in my full proposal. My hope is to update all tab-like areas in Blender to be more consistent and to improve them. You can find my proposal here (I'm still flushing out some areas, so it's not fully complete): http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Tab-Interface
And most importantly, tabs are not designed to be a rigid feature. The end goal is great customizability than we have today.
Tried it. Feels friendlier for sure!
Not sure on performance still - it's hard to distinguish which is a problem of my habits and which an objective one without thorough testing.
One thing that seems could dial the speed quite a bit is a shortcut to up/down tab switching, like Ctrl+Scroll, when mouse over the whole panel.
Perhaps, you could place the panels and tabs on the top as a drop down feature..
A couple of things I noticed after having a quick look.
key navigation through tabs doesnt exist, I immediately wanted to use the 'tab' key to cycle through tabs, with 'ctrl+tab' to enable more than one tab at a time and 'shift+tab' to switch to tab element selection.. thats just my immediate reaction to the interface and not one I believe would be universal.. but it would bear thinking about.
in the wiki page under "What if scrolling is needed due to too many tabs?" you have an option not mentioned in the wiki but demonstrated higher up with examples that you have a second row/column of tab headers appear. which I personally would prefer than some hiding or scrolling.
Tabs main purpose is to organize tools. But the proposal/guideline written is very primitive that it don't cover Blender as a whole. Which made a lot of experienced users having the notion that current implementation is patch work.
The main concerns with the tabs:
1. Divergent in UI = bad; Convergent in UI = better.
2. What other area where tabs can be located? What limitations and freedom of design there?
3. Will it work with different modes where tools differ in design (ie: edit mode vs Tex Paint mode)?
4. What other menu (and shortcut keys) based tools can be added into the new toolbar (and wherever tabs are)?
5. In what logical way tools are organized (grouped)?
6. UX: number of clicks, amount of mouse travel, tools interaction, what about addons
7. Interaction between tabs to other area of the UI (operator redo, N panel, header drop-down menu etc)
With most big design change, there will be areas where the community will agree and disagree. With tabs, we mostly agreed that the guideline is sniper scope (narrow but deep). We also don't want tabs to behave like a shotgun (wide and shallow). By addressing the concerns above, tabs can be designed with depth and wider POV. Which means the result is high resolution vista (if you get my metaphor ;) ). We don't want to "fix a plane in mid flight" in the case of "we focus on 3D view edit and object mode toolbars for now."
1) Nobody will want to argue otherwise
2) I think the designers should take a look at Visual Studio 2013, where everything is not only tabbed, but also tabbable (any toolbar or window can be joined by tabbing). Although it may be very difficult to program such a system, using that as a goal would open the system up to user customization without the need for scripting.
3) The schizophrenic nature of blender is certainly an issue, but finding the lowest common denominators will be necessary. The ideal program would be one where there is no difference between the modes, as each and every action would have an analogue elsewhere.
4) Ideally they should do it Office 2010/13 style, where any action can be assigned to a custom ribbon (in blender it would be toolbar) using a simple interface
5) Good question, and Blender Foundation should offer a grant to study the use patterns of professionals, enthusiasts, and novices alike. The only way to tell what the "logical way" is is to do proper scientific studies.
6) See 5
7) See 6
The main issue with the UI proposals right now is that they are being conducted blind, by people who do not represent a diverse enough group of the user base. Before people start making UI "improvement" claims they need to actually do the research and explain why, using more than "because I created it for group A and don't care about groups b,c,d,e,and f, and g can suck one for even bothering".
There seems to be this implicit assumption that point-and-click is good, typing text commands or scripts is bad.
Let me point out that point-and-click doesn’t allow for collaboration. How do you publish your work for others? How do you accept patches from them for changes? How do you keep track of your own changes?
We know how to do all of these for text. We can’t do it for point-and-click.
I think you fell into the development first fallacy, where you take apart tiny statements out of context without reading the meaning of the whole. I merely stated that for an end user, being able to move tool tabs without programming knowledge is undeniably beneficial. The vast majority of Blenders users are not developers, and many have no "programming experience" (they do but don't know it). Again, this is only dealing with access to existing tools, not the creation of new ones!
I never said get rid of scripting, and in fact to be able to make custom tool bars/tabs or even just custom locations you will likely need to develop a scripting method anyway (certainly other ways to do it, but it's far easier to use existing code rather than making everything from scratch). But at the same time, you don't need to accept patches or track changes to the end result, only the code to allow the system to work!
"We know how to do all of these for text. We can’t do it for point-and-click."
You can already move them, just double check the newest build and move the tool section around, it moves just fine. The issue is that you can't currently re-arrange between tabs or move the tabs and detach them and attach to a different section like you can with other parts of the program. I'm sure that swapping between tabs will be addressed soon enough, I just hope that development will be ambitious to not leave it at that and allow you to drag tools out as well (though not really a high priority). A simple click and add prompt for custom tool bars would also make the program much easier to use than making a script for something that is taken for granted in many other programs (again, low priority).
Wasn’t what I was referring to. This is what I was referring to:
Like I said, we know how to do all of these for text. We can’t do it for point-and-click.
"Like I said, we know how to do all of these for text. We can’t do it for point-and-click."
Looks like you keep missing the point. Perhaps we need more documentation. Either way, your comments are a clear sign that there is a significant communications issue between end users and the developers, with developers assuming they are right and all users are clueless, and some users also failing to see the technical limitations of the backwards compatibility focused core.
I don't think the issue is that it being conducted blind, the issue is that they are trying to fixed blender without being radical, they trying to design a new interface whilst at the same time they are building it, and they are trying to keep the community on side. This let not rock the boat to much is going to mean we will still be stuck with a mess of a interface 5 years from now.
People can talk deeper in details forever. At the same time one can write code.
Notice - "people" and "one" :)
Though what you wrote is happening, being cynical in the way to solve this isn't beneficial to anyone. It is more of the balance of "I want these in the tabs" then "Ohh, it is added, these tabs are perfect" to "Do we research well enough that the way these tabs designs are serving more than just artistic organization, done with clarity from development POV, and understandable even by the n00best of users."
Have you learn a new software and notice that, there is a time when one explain the paradigm in the UI and tools then the receiving end of the explanation got a light bulb (or LED) lights up with the grand "AHA moment." Toolbar and tabs in blender clearly missing that, no matter how well it is explained.
How about this for service? A little more than 2 hours from bug report to resolution.
Of course, it took me 2 days to figure out enough of what was going on to file that bug report...
I just want to thank everyone involved in this collaborative and extensive effort, I hope you solve the problems well, and I'll also to say that whatever you do settle on, I'm confident it'll be a product of thought behind it. Good luck--I think you guys will need it!
Just ran a few simple tests (on the newest build) on a low res model I regularly use, and CPU rendering is incredibly fast now even with the same settings. What was 22 secs/frame is now just 11. Might not be as fast as GPU rendering, but it's now feasible to ignore low-end GPU rendering. Great job on the back end optimization!
Am glad there are changes (e.g. ... some more hidden ones. Like "Add" - Menu moved away from Info-Window to 3D-Window).
I like much vertical toolbar tabs. It helps to overcome the need to scroll. Playing with it. Shrinking 3D-Window, tabs scale too. Until labels from tab vanish and get unreadable. The design of vertical toolbar tabs conflict with scalability of the 3D-Window, thats the only problem I notice about the toolbar.
I enjoy how Blender changes.
Regards, Siebeneicher
Just downloaded the test build and messed around with it. It has potential. What about moving the tabs to the inside near the work space. While they probably look better where they are it would make more sense to have them on the inside. Both so they don't get cut off when the window gets moved around and from a least mouse movement standpoint.
I realize that this first incarnation of tabs is not perfect but I'd like to applaud the UI team and everyone else involved for a great effort. Just the fact that there is some order introduced into the tool panel is already a major feat. The icons are also a huge bonus and will likely go a long way to aid new users and adopters from other software alike.
great job guys!:)
My main concern from testing dev builds:
Why the heck was movement behavior changed in edit mode? In the default scene, go to one of the orthro views (top, left, right, whichever), go to edit mode on the cube, and hit "G" then "X", "Y", or "Z". For some reason, only vertical mouse movements matter, instead of locking the selection to the mouse like has always been the case. This is a *huge* usability issue, and just does not make sense.
Edit: it happens in orthro and perspective views, which makes it an even bigger issue.
Nothing regarding movement behavior has changed. Try loading factory setting and then testing. It may be a keymap conflict.
never ever gonna make all happy with any of the new designs, there's so much out there to choose from, some like it this way some like it another. looks like daz from the build i got a couple days ago.just say'in don't want bash anyone. well, good luck to all working on this cluster &%*#. i like it just the way it is. its just been redisigned a few years ago anyway.hey, what if we go back to the 2.49b UI. WOHO. now would'nt that be a hoot. happy blending.:)))))
It's nice to know they're debating the tabs thing. It's reassuring that when they do finally decide on something, it'll be after considering all possible options.