Blender 2.5 UI workshop results

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

Post Reply
ton
Site Admin
Posts: 350
Joined: Wed Oct 16, 2002 12:13 am
Contact:

Blender 2.5 UI workshop results

Post by ton » Tue Mar 10, 2009 6:19 pm

Hi all,

Check the link below for an overview of the discussion topics and proposals that resulted from last week's "Wintercamp" workshop here in Amsterdam.

http://wiki.blender.org/index.php/Blend ... WinterCamp

Thanks!

-Ton-

b333rt
Posts: 0
Joined: Tue Mar 10, 2009 9:04 pm

Post by b333rt » Tue Mar 10, 2009 10:51 pm

Reading thru the wiki page, there is one topic related to ui design that i am missing.

Controls and their behavior.

Currently many controls in blender have an awkward behavior. Controls should behave like their counterpart OS control to match the expectations of users and ease the usability.
For example, it should be possible to navigate a Drop-Down-List with the Up/Down-Arrow-Keys to be able to change different blendmodes in material/texure-settings quick.
Another example is a text field. Clicking on one of these highlights the whole content.
Whereas in native OS controls the cursor is possitioned at the click position.

Blenders behavior might not even be by design, but a limitation of the windowing/event system?

There is more to add, but i would like to know the oppinion of the devs first.

jesterKing
Site Admin
Posts: 207
Joined: Fri Oct 18, 2002 12:48 pm
Location: Finland

Post by jesterKing » Wed Mar 11, 2009 8:36 am

b333rt wrote:For example, it should be possible to navigate a Drop-Down-List with the Up/Down-Arrow-Keys to be able to change different blendmodes in material/texure-settings quick.
You can already use arrow keys in drop down lists. Whenever you've clicked it open, you can use the arrow keys to select your item.
b333rt wrote: Another example is a text field. Clicking on one of these highlights the whole content.
Whereas in native OS controls the cursor is possitioned at the click position.
Untrue. All browsers I use select the entire text in the URL input. I guess the reasoning behind it is similar: when editing some text in Blender in a text field, you most likely will want to change the entire text, just like in the browser URL field. Clicking twice is exactly the same behaviour as in Blender.

/Nathan

b333rt
Posts: 0
Joined: Tue Mar 10, 2009 9:04 pm

Post by b333rt » Wed Mar 11, 2009 11:10 am

jesterKing wrote: You can already use arrow keys in drop down lists. Whenever you've clicked it open, you can use the arrow keys to select your item.
And i hope changes will happen in realtime in 2.5, at least for DDL's of blend-modes. Are there more candidates worth implementing a real-time change?
jesterKing wrote: Untrue. All browsers I use select the entire text in the URL input. I guess the reasoning behind it is similar: when editing some text in Blender in a text field, you most likely will want to change the entire text, just like in the browser URL field. Clicking twice is exactly the same behaviour as in Blender.
An Address-bar is different from a text input. You don't use the Address-bar frequent, you just change the web page with it and then navigate via links. The main purpose of an Address-bar is to aid orientation.
In Blender you mostly fill in empty text inputs. If you are going to change the text in it, you are prepared to do this and know you have to double click or CTRL-a, or you want to change only a part of it and mark it directly. Its not like an Address-bar where you can almost 100% say the user is going to type a new address, because nobody navigates a page altering index1.html to index2.html, and automate the whole process of selecting the text for him. Long story short in Address-bars its almost 100% percent certainty in Blender it is not.


There is a major distraction involved in blender input controls, that is once the have keyboard focus clicking another control only cancels the input focus from the control that has it, and does not give the clicked control the focus.
Another problem i see with blender controls is with Sliders and Up-Downs. This controls should only gain keyboard input if the mouse was not moved over them, because every time you try to change the value just a little bit you are prone to switch them to keyboard mode.
Those controls are meant to be operated via mouse primely. A slider give you direct feedback about its value in the range its represents.Therefore its desireable to click any position in it and have the slider slider to that position. Clicking and dragging should initiate dragging the slider. To change the value by keyboard there is only Double-Click left.
I know that there are rules like if you click the label you gonna edit with keyboard and if you click left of the slider (or number in an Up-Down) you gonna decrement it, and click right of it to increment it.
But there is no easy way to communicate this to the user. Sometimes Up-Downs are filled with label text so that the only way to decrement is to click that tiny arrow on the left. Just because keyboard input will occur if you click the label.
I have to stress it again. Those controls are meant for mouse input in the first place and are used that way maybe 95% of the time. Keyboard input should be initiated by double clicking. Its a stupid simple principle.

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Wed Mar 11, 2009 1:23 pm

What an enormous super crew !

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Wed Mar 11, 2009 1:37 pm

b333rt wrote: In Blender you mostly fill in empty text inputs. If you are going to change the text in it, you are prepared to do this and know you have to double click or CTRL-a...
In blender you'll get a name by blender: Plane.001.
If you are not happy with that name you most likely want to replace it with a complete new name like Arm and not to Plane1.

So selecting Big to Small makes sense to me.
( First the whole sentence, second click the word, third click a cursor )
Also note how selecting changes after the textbox has focus.
Different apps also have different cursor behaviours above text boxes and once text has been selected. Most mac apps even remove the pointer once the user starts typing... Fun details for 2.52 I'd say.

b333rt
Posts: 0
Joined: Tue Mar 10, 2009 9:04 pm

Post by b333rt » Wed Mar 11, 2009 3:15 pm

The more i think about this, it is probably better to have everything highlighted on keyboard focus. This is especially true for Up-Downs and Sliders.
joeri wrote:Different apps also have different cursor behaviours above text boxes and once text has been selected. Most mac apps even remove the pointer once the user starts typing... Fun details for 2.52 I'd say.
Yes this is usually an OS level setting. At least on Windows it is in native Windows controls. But i am sure this is the same case for other OS.

ton
Site Admin
Posts: 350
Joined: Wed Oct 16, 2002 12:13 am
Contact:

Post by ton » Wed Mar 11, 2009 5:33 pm

Thanks for the feedback, we indeed didn't spend much time on the issue, also because there already were design proposals to make functionality of input widgets much more clear.

Just following conventions is disputable though; as you already see in replies, such issues immediately can be countered with other conventions.
I'm more interested in what really works good for the workflow of a 3d artist. The text highlight issue works for naming in general fastest. It's not very rare even, I see more apps doing this.

Making slider buttons (like for color) immediate move to the cursor position is fine, but has to be coded in a way that still allows values to tweak a bit, if you click close to the dragger it shouldn't jump.

The number buttons (which you call UpDowns?) should be tweaked better to prevent confusement, and drawn in a more clear way to visualize its working.
Replacing this with a double click I'd not call a "stupid simple principle"... never heard of that one. BTW: The method we use in Blender has been copied over to other programs, so we might do something good even!

Anyhoo; I realize some of such issues are very close to personal preferences too, the typical case of acquired habits. That's a never ending debate :) Better to first try to make things work consistently, communicated well, and with rationales based on optimal user workflow. When there's real preference conflicts remaining, such issues then can always move to user presets.

VDark
Posts: 0
Joined: Tue Oct 14, 2008 5:36 pm

Re: Blender 2.5 UI workshop results

Post by VDark » Wed Mar 11, 2009 5:37 pm

ton wrote:Hi all,

Check the link below for an overview of the discussion topics and proposals that resulted from last week's "Wintercamp" workshop here in Amsterdam.

http://wiki.blender.org/index.php/Blend ... WinterCamp

Thanks!

-Ton-
I like everything I see with the new UI so far. The one problem I'm not sure of, is the problem I have a lot in 2.48 and below. The toolbar buttons can get cut off when you have a lot of viewports opened.

Even at 1680 wide, I can't split the view into too many windows across, because the buttons on the headers get cut off. Sometimes when I'm modeling, I have to resize the windows to toggle the snap or backface selection modes.

It would be nice to always be able to get access to these things. Maybe a button to have the buttons pop up vertically or something?

b333rt
Posts: 0
Joined: Tue Mar 10, 2009 9:04 pm

Post by b333rt » Wed Mar 11, 2009 9:12 pm

VDark wrote:Even at 1680 wide, I can't split the view into too many windows across, because the buttons on the headers get cut off. Sometimes when I'm modeling, I have to resize the windows to toggle the snap or backface selection modes.
You can drag the header left and right with the middle mouse button.

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Thu Mar 12, 2009 11:59 am

ton wrote: Just following conventions is disputable though; as you already see in replies, such issues immediately can be countered with other conventions.
I'm more interested in what really works good for the workflow of a 3d artist. The text highlight issue works for naming in general fastest. It's not very rare even, I see more apps doing this.
Another idea for text buttons could be:
On a hover and rolling the wheel advice on nice names from an external xml file.
So when hoovering a bone button and rolling the wheel blender could start suggesting names like: Head, Arm.L, Hand.L Leg.L etc. All out of a xml changeble by the artist.

Code: Select all

<declare>
 <bone>
   <suggest name="Head" />
   <suggest name="Arm" />
   <suggest name="Leg" />
etc...
 </bone>
 <mesh>
   <suggest name="" />
   <suggest name="" />
 </mesh>
 <material>
   <suggest name="Wood"   apply="mat.wood.xml">
   <suggest name="Plastic" apply="mat.plastic.xml" >
   <suggest name="Carbon"  apply="mat.carbon.xml" >
 </material>
</declare> 
left click confirm, right click applies the settings in the apply.xml :P

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Thu Mar 12, 2009 12:01 pm

Hmmm, I guess mat.carbon.xml should be mat.carbon.py to make it more feasable.

Eclectiel
Posts: 0
Joined: Thu Nov 08, 2007 4:28 pm

Post by Eclectiel » Sat Apr 04, 2009 5:33 pm

I could listen the audio (parts of it) of March 06 morning from Wintercamp (it wasn't uploaded yet when I listened the others the first time). I did like some of the things discussed there, especially when someone, I think Jean-Luc (french accent), talked about having 3D widgets for each setting of 3D tools. In some of my proposals there is some notion of that, but I never thought it in such a general way, and I really love that.

Among other things, I like the cleanliness which the new buttons are being designed with. Also the graphical system for adding keyframes (right click), is quick and solves well the graphical addition of keyframes in an everything-animatable program.


In the Auto-Layout page there is a generic way to handle groups:
Image

In this case I would suggest a different approach, at least for shape keys. It doesn't necessarily have to be exactly like in my proposals, but what I think is important is to have always visible the settings (or some) of each shape key.

An example: Image
And how it would look proportionally in a screen: Image


Some reasons why I think this:

When working with shape keys, for instance doing lip-sync, sometimes may happen that all the shape keys are well modelled but when the character must say "A" the mouth is still shut.
Without all shapekeys' settings visible at a glance users don't know if they forgot to put a keyframe for that shapekey, if the "A" phoneme's shape key was muted for some reason, if the "A" phoneme is right but there is another that shuts the mouth that is having a greater (incorrect) weight value and steps on the "A" phoneme (for instance a previous "T" phoneme that was never weighted down), or if there is a mix of these issues, or just the jaw bone had a wrong keyframe there.

The way to check what the problem is, is to click on each shape key to see if it is muted, or has an erroneous weight.

With a list of shape keys always showing their settings, the user would see the problem at a glance.


Lip-sync is just an example, same goes for driven shape keys, where the user can check at a glance if there is a problem in the skinning setup, or if the character is activating a shape key even if it is in rest pose, just because the angle of the driver bone is not well settted.
If the character has 30 or more shape keys for pose correction, selecting each shape key every time that is needed to check if everything is ok may become overwhelming.
If the character will be exported to another soft and the base pose is slightly altered by shape keys it may bring some problems.

Always visible settings would give the user a fast way to check that everything is as it should be. And would also favour drag-and-drop.


In a layout like the one in the Shapekeys-panel proposal, the space usage could be handled using grouping methods to reduce vertical space (i.e. when working with lip-sync hide the body corrective shape keys), and as a way to reduce horizontal space usage it may help a proposal I posted about number-widgets without arrows (Image)

But again, it doesn't have to be necessarily as my proposal, the important thing I think is the settings are always visible and accessible to the user.


This may be valid for other groups, like vertex groups. For instance to see at a glance how much weight they have in a specific part of the mesh: The user selects some vertexes, checks the vertex groups panels and sees how much weight each vertex-group has on those selected vertexes (not included in my vertex-groups panel mockup), verifying if there is any vertex group affecting an area that it should not affect. Like SHIFT+LMB in Weight Paint mode, although with more control since the users would be able to choose exactly the vertexes they want to check. And also giving the ability to check bigger zones than the SHIFT+LMB alternative.

Post Reply