BLENDer Interface Roadmap (improve blender usability)

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

greasyScott
Posts: 16
Joined: Fri Dec 20, 2002 6:43 am
Contact:

BLENDer Interface Roadmap (improve blender usability)

Postby greasyScott » Mon Feb 03, 2003 9:33 pm

Whoever wishes to improve the usability of Blender, I am welcoming any and all suggestions. I have just submitted a project proposal to create a Blender Interface Roadmap. Before setting out to create such a map, I need your comments.

What do you like about the Blender Interface? How would you improve workflow? Is there a way to make it easy to learn for the newbie AND powerful for the experienced user?

My intent is to create a recommendation as to where Blender could improve. The key is improving usability and not necesarily changing the look of the buttons. Though that may happen as well.
Good judgement
tends to precede
good fortune

Pablosbrain
Posts: 356
Joined: Wed Jan 28, 2004 7:39 pm

Tabable

Postby Pablosbrain » Mon Feb 03, 2003 9:45 pm

I would love the ability to tab from one button/entrybox to another... if some way (not necessarily the tab key alone) could be devised to jump from one entry field to another and just cycle through those that are visible... this would help a lot... Currently I have to use the mouse to click a field and then let go and usually hit shift-backspace to clear the field and enter a new value... doing that several times wastes the time I have to keep picking the mouse back up.

Other than that... make things consistent! If it makes sense to combine several radio type buttons into a drop down... do it... I'm sure more buttons will eventually me made to fill the space! :D

slikdigit
Posts: 213
Joined: Wed Oct 16, 2002 3:52 am
Location: Northampton, MA (US)

Postby slikdigit » Mon Feb 03, 2003 10:01 pm

I made some suggestions along these lines in this post
http://www.blender.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=885
do you think these are useful?

matt_e
Posts: 898
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Postby matt_e » Tue Feb 04, 2003 12:13 am

We need standards for:
  • usage of UI controls
  • window/button/etc. layout (also a reference for python GUI authors)
  • usage of language (in button labels, dialogs, etc. etc)
  • hotkeys (there is already a good amount of consistency with hotkeys eg. grab rotate and scale working in other windows than the 3D window. We do need documented standards though for future developments)
  • menu/toolbox conventions
  • icon guidelines
  • terminology
  • user input/selection

Nice and easy :P

leinad13
Posts: 216
Joined: Wed Oct 16, 2002 5:35 pm

Skins

Postby leinad13 » Tue Feb 04, 2003 4:10 pm

I recently posted a similar suggestion on another thread about the usage of skins.

I was flamed because people did not understand what i sed :( . Maybe cos i explained it rubbish. :twisted:

My proposal is to someday, probably far in the future, have a blender, where you do not need to be a very experienced programer to change the UI. What im talking about is the usage of XML or a similar scripting language, maybe we could use python. My suggestion is founded on the fact that Winamp3 uses XML for its skins and another scripting language called MAKI (i think), to completly change the layout and often functionality of Blender.

There are a few screen shots below of Winamp3 for those of you who dont use it. It is basically a very cool music and video player, it has more functionality than a Monkeys Head. :lol:

Image

Image

Image

You might completly understand how useful skins could be in blender. What i propose is that a way of changing the UI at runtime be established, either by using XML or Python or by even developing our own dedicated BML (Blender Markup Language).

Im offering a choice now so that any coder who is considering changing the UI, has two choices:
[list=]Change the code and UI to suit their indivual needs.[/list]
[list=]Change the code so that everyone in the future needn't be a fully experieced coder in C++ just to tweak the UI a little.[/list]

I can see one problem with my proposal. I havnt started to even try and change the blender source code, because i am a very inexperienced coder, who has never had a qualification in programming :oops: . But i am currently learning as much as i can.

I know this has been long post and is slightly unstructured. But i would like to think that in any kind of UI roadmap, the ease of use for non C++ coders be taking into account for the future, before we waste time on just changing the UI to suit our individual needs. Lets face it we wont be able to all agree on a new UI and i think that the best programmer will get what he wants, but maybe the rest of us wont.

Over to you boffins
-------------
Over to you boffins

L!13

greasyScott
Posts: 16
Joined: Fri Dec 20, 2002 6:43 am
Contact:

Roadmap won't delve into code

Postby greasyScott » Thu Feb 06, 2003 11:20 pm

With an eye to the source code, the roadmap will make recommendations. Skinning is not a priority for this project. Improving the core usability is. Granted improved usability does at times mean customizability. For that to happen, my best experiences have come from 3D software's many paths to the same end and allowing the user to find their most productive path.

With that, the users "mental map" of the software develops on top of their strengths. I may be more attuned to images so I look for icons. You may be better at spatial relations so something like a hot-box or a marking menu is more your cup of tea. A third person may prefer to do everything command line so MEL (maya embedded language) is their favorite.

Skins are cool for mp3 players but those are more simplistic applications. For now I will not be focusing on skins but be my guest.
Good judgement

tends to precede

good fortune

greasyScott
Posts: 16
Joined: Fri Dec 20, 2002 6:43 am
Contact:

Roadmap won't delve into code

Postby greasyScott » Thu Feb 06, 2003 11:21 pm

Double post. I got an error message the first time and re-submitted. No delete option so I figured a simple explanation would do instead.
Last edited by greasyScott on Thu Feb 06, 2003 11:24 pm, edited 1 time in total.

alt

Postby alt » Sun Feb 09, 2003 1:22 pm

Improvement is a must.

As said before, there needs to be dozens of ways for doing the same task. User can then use whatever he/she finds most comfortable. I understood that some brave soul is currently creating flowchart system for shaders. It could be used for other data too, eg. for editing object relations.

Horde of disgusting litte icons on the row needs to die. There's already too many of them, they are not wanted. They do not fit on the divided screen and there will be more of them as program evolves. Scrolling toolbar to see them slows user down. List of tools and their modifiers need to be shown in some other place instead.

Slightly tinted text can be used instead of icons (color-coding). No need to learn a tiny image anymore. Icons work when there is only a few of them, like listing modes/panels etc. When there's tens of them they became useless, slowing user down because he/she needs to keep cursor still to know what that icon possibly does. Or RTFM.

Mouse-with-keyboard -interaction needs to be redesigned. Why do I need to twist my left wrist to translate the view with middle_mouse_button(!) when I could easily just press one key and use mousebuttons for pan, orbit and dolly. Mousebuttons are easier to reach than ctrlaltshift, use them when possible. Like: one tool-key on keyboard, three modifier-keys on mouse.

    Keys should be logically grouped. Currently they are not, they follow typewriter interaction method - keys that fit in the same category are placed everywhere with long distances. Scale, rotate and grab should be XCV or WER instead of SRG. It would be faster to use. It's also as fast to learn as current system. And if Blender ever gets ported to other languages, SRG will soon have no reason at all.

    CTRL, ALT and SHIFT should be saved for complex tasks like file controls, not for all-the-time operations.

    One-key commands should be used only for changing/using tools. View tool, face tool, edge tool, point tool, scale tool, rotate tool, grab tool..

    Not every action needs a hotkey. If it's rarely used, like 'convert 4-point polygons to 3-point polygons', it doesn't need one. It can be used from a menu.

    And as in Softimage, pressing a key would make that tool active, holding it down would keep tool active until released.


No floating windows. Panel interface is faster and clearer.

No skins. In general, it needs to be decided if Blender is a tool or a toy.

Explorer-style list for scene objects showing everything. Easy deleting of unwanted crap. Drag'n drop for easy hierarchy.

Context-sensitive pie-menus/list-menus which would list only actions that are possible to do at given time, like tools, operations etc.

'Normal' Blender menu (spacebar-menu) which lists everything could be a on the other side of the screen and hidden when not needed. Then there could be dropdown menus (hidden when not needed) on the upper side of the screen.

Every menu needs to list hotkeys also (if any).


Couldn't remember more just now, maybe later ;)
Personally, I wish that whole interface is redesigned and changed where needed. Any designers here?

Dani
Posts: 251
Joined: Fri Oct 18, 2002 8:35 pm

Postby Dani » Sun Feb 09, 2003 2:15 pm

Mouse-with-keyboard -interaction needs to be redesigned.



OMG! nooooooooooooooo!! pleease! it works very well with correctly designed wrists! :)
one hand on the mouse (mine has the middle button under the thumb... on the side! it's really nice) the other over the left side of the keyboard.
I think "G" stands for Grab
"R" for rotate
"S" for scale... i find this logical.

X... like toon's eyes when they die: kill the object.

"A" as for All...
"Z" like Z buffer.
"E" like Extrude...
CTRL+J >> join objects together.

i will not list all the hotkeys... there are loads of them, all they need, imho, is a better explanation. And maybe a message like "HOTKEY NOT AVAILABLE" when you hit a key that is not active in the current mode.
(make this pop-up window exitable with a simple right click anywhere in the interface)

I really do not beleive that modifying the keyboard hotkeys is the way to go.

Maybe Phase's improvements on the Oops window will appear in 2.26 release. The Oops surely needs imrovements.

I agree that the tiny layer butons could be improved (scroll down menu, pop-up ? Maybe the same "M" could pop-up a window displaying layers you want to visualize when you have no objects selected)
And, It might be useless to repeat the toolbar when you split a view (with the same content)

About converting 4>3 polygons... I use CTRL+T, CTRL+F and SHIFT+J extensively! it's EXTREMELY useful when refining a mesh. Using a menu would slow things terribly down!

The use of CTRL, ALT and SHIFT allows for more combos.
Z > Z-buffer
ALT+Z > OpenGL rendering (game engine)
CTRL+Z > rendering of non uvmapped textures too.

Maybe some slight redesigning but no major changes in the hotkeys.

See broken's thread about interface improvements... seems very promising.

No skinning: I agree.
Blender is a tool not a toy... it's like painting you don't have to have a naked woman drawn on your brush for it to be performant.

there surely needs to be a lot of discussion around this theme.
Or a series of polls (maybe somehow less democratical ( majority can be wrong ) )

Dani

alt

Postby alt » Sun Feb 09, 2003 10:54 pm

Dani wrote:it works very well with correctly designed wrists! :)
one hand on the mouse (mine has the middle button under the thumb... on the side! it's really nice) the other over the left side of the keyboard.
I think "G" stands for Grab
"R" for rotate
"S" for scale... i find this logical.

I knew I would stir something up this time :)

But yes. 'S' stands for scale, 'R' for rotate etc. What does it stand for when i18n kicks in? When languages change, meaning vanishes. And when program evolves there's not enough keys to keep this logic.

About ctrlaltshift:
Look at your keyboard.
It probably has 'ctrl' under 'shift' and 'windozekey' between 'ctrl' and 'alt'. Result is, these keys are not in line. But, mostly, my fingers are. Now there is a little clash between human and machine. And there is a whole science dedicated to it: ergonomics.

Try it out: is it easier to keep your three midmost fingers on ctrlaltshift or 'XCV'? For me, it is 'XCV'. Or 'SDF'. Or some other linear keygroup.

Dani wrote:About converting 4>3 polygons... I use CTRL+T, CTRL+F and SHIFT+J extensively! it's EXTREMELY useful when refining a mesh. Using a menu would slow things terribly down!

Well, agreed, if you say so.

But as I said, those actions are complex. Using ctrlaltshift for variating complex actions is okay. Using those for simple, one-key tasks (like panning view) is just cruel.

And once again, keys should be grouped by their usage, not by the names of their actions. At least when desperately needed. This keeps access time minimal.

Dani wrote:there surely needs to be a lot of discussion around this theme

I doubt there will be any. :(
People seem to prefer skins over usability.

slikdigit
Posts: 213
Joined: Wed Oct 16, 2002 3:52 am
Location: Northampton, MA (US)

Postby slikdigit » Sun Feb 09, 2003 11:11 pm

It would be a nice (and it seems not impossible ) thing if the hotkeys were (optionally) selected from a user created config file. Many CAD packages allow this, and it facilitates moving keys around to an individual's need (e.g. right handed vs. left handed) and even sometimes creation of hotkeys for new actions.
The defualts could be left intact, so as not to force current users to relearn everything.
that way we could all be happy.

matt_e
Posts: 898
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Postby matt_e » Mon Feb 10, 2003 2:30 am

I agree with slikdigit. Leave the main hotkeys as-is, but allow for customisation.

alt, even though the grab/rotate/scale hotkeys are not directly in line, they are not the only operations that hotkeys are useful for. I constantly use Akey, Wkey, Xkey, Fkey, Zkey, Bkey when I'm modelling. These are nice and easy to get to from the S-R-G arrangement. And although it doesn't translate, it does at least make the keys easier to remember for some of us.

That's not to say that there isn't a better way of doing things (proper research and investigation of alternatives is always a good thing!), just that you're overlooking some of the positive aspects of the current hotkey layout.

slikdigit wrote:It would be a nice (and it seems not impossible ) thing if the hotkeys were (optionally) selected from a user created config file. Many CAD packages allow this, and it facilitates moving keys around to an individual's need (e.g. right handed vs. left handed) and even sometimes creation of hotkeys for new actions.
The defualts could be left intact, so as not to force current users to relearn everything.
that way we could all be happy.

Dani
Posts: 251
Joined: Fri Oct 18, 2002 8:35 pm

Postby Dani » Mon Feb 10, 2003 4:26 pm

I agree with slikdigit... let the users define them. this has been proposed many times.

Also it's easier to build tuts on this "standard" config.
This doesn't mean it shouldn't be customizable... and there are surely ways to go around this issue.
(let's say the PHP code would ask for the user's config file and read the hotkey config and change them in the tut if they do not match... something like this :)

Ciao
Dani

Noorah
Posts: 4
Joined: Sun Dec 15, 2002 10:50 pm

Postby Noorah » Tue Feb 11, 2003 7:51 am

I have been thinking about the way I want a program designed, and I don't know how many other people would like this, but this is what I suggest:

1. As in Apple Mac OS X, make sure that all actions can be performed through a simple and easy to understand menu bar, this could also be the space bar menu, either would work, however, I don't like both, I think that is a waste of screenspace.

2. Though this would simplify things for the newbie, it would not help the workflow of an experienced user. It is this last point that I truly worry about. I am afraid that as people try to make the program user friendly, they will accept defeciencies in effeciency and other such problems, I couldn't stand this! I want a program that accomodates new-users, but I want the main focus to be on the development of a powerful and effecient workflow.

3. I find that the hotkey system works very well, however, a little more logical structure to it, and a list of the available hot-keys in a help file somewhere would be good. The way I imagine the coders could accomodate extra features and not run into the "no more hotkeys left to assign" problem is by having heirarchical modes, where you start at a top mode and it performs actions, then you go into a mode to perform other actions of a more specific nature. I would propose that hotkeys be separately assigned for each mode, allowing the user to access all the effeciency of hotkeys without running out of hotkeys.

4. I don't want to change the mouse in one hand, keyboard in the other idea. I love it, I find it the best way to work. The way I would want to work is to develop a sort of rythm in the way ou would work, going from one hand to the other. For example, hit a hotkey, perform an action with the mouse, hit a hotkey, perform an action with the mouse . . . . When it comes to typing, I find it very acceptable to bring my hand off the mouse and type, however, I don't wan to go back and forth, so I propose that there be a way to edit fields of data using only the keyboard, so that when the majority of work is being done, the user will not have to go to the mouse to work with that.

5. To implement something like this, I like the way Lynx does it with numbers assigned to each field and button, that way you can just type the number or tab through and perform actions that way.

6. I want to use a more graphical and drag-and-drop flow as well.

7. The amount of controls that are actually placed on the screen should be kept to a minimum, so that most of the screenspace may be dedicated to the object windows, and the buttons perhaps show up when needed as pull out drawers that can either stay open or retract.

8. Another way that I like quite a bit is the way Softimage does their XSI program. I find that quick a good way to run a program work flow, with a center window full of the object, and around being little boxes of text, not floating windows, but very consistent and comapct boxes. I like that workflow very much, but I think hot keys are a better way to go than that. Perhaps there could be two interfaces, one where the controls were more visible, and the other, where you hit hotkeys, and the controls popped up. For example, one interface would be more newbie friendly, and closer to XSI, while the other set-up would allow you to have almost no visible controls, but rather, you could just hit a hotkey and have the control pop up, which could be adjusted using the mouse, and then you could continue working and it would close or it would stay at the side of the window and lock there for reference or repeated access.

wavk
Posts: 255
Joined: Wed Oct 16, 2002 9:58 am
Location: The Netherlands
Contact:

Postby wavk » Tue Feb 11, 2003 7:42 pm

Just one simple thing to start with, easy to implement, lower the contrast of the buttons. The high contrast buttons make the view messy and it looks like there are even more buttons than there are already(about a hundred for the material window alone).

Also, a lot of stuff has to be in pop buttons, like the render resolutions. I think the amount of buttons is the most daunting for new users.

Also check out my material editor, I based the interface loosely on Blender, but I ended up coding my entire new interface.

http://www.funnyfarm.tv/thelab/crafter.htm


Return to “Interface & Tools”

Who is online

Users browsing this forum: No registered users and 1 guest