Blender's User Interface

Since creating user interfaces and APIs interests me a lot, I study other software to see the latest trends. Blender is one of those packages that I have been keeping an eye on. If you haven't seen it before you can take a quick look at it at www.blender.org. The examples they show in their showcase look very impressive. I am not a blender user, so I won't be able to make any first hand comments about its user interface (UI) but many people seem to have strong opinions about it. I really like that they are using Python as a scripting engine. Their main window looks too busy for my taste but since I don't use it I am not sure how it feels once you get used to it a little bit. From what I read in several forums, advanced users seem to love it and many others claim that its UI is a show stopper. One day I will take the plunge and try it out but nowadays I do not have any time at all.

Today, I would like to talk about a statement they make "Non-overlapping and non-blocking UI delivers unsurpassed workflow". I find this very interesting since I don't think it is a good idea to base a user interface on this principal. Most of the UI widgets I like do not conform to this. For example a tree view is a blocking widget. When you collapse a node then that node's children are blocked. A drop-down box overlaps a portion of the form it is located in when it is clicked and when you let go the items in the box are blocked. A pop up menu is both an overlapping and blocking widget. A form is both blocking and overlapping widget as well. Trying to create a UI with non-trivial functionality without using any forms would be very challenging and I don't think the end result would be better than using some overlapping and blocking forms. I can give many other examples but I think this is enough. I am not sure why they think it is such a big deal to have a user interface that is non-overlapping and non-blocking? Since we can see that they use tree-views and drop-down boxes maybe they mean that they have no blocking and/or overlapping forms. If you keep opening multiple forms on top of each other that would be pretty bad but I don't think that opening a form on top of the main window is necessarily a bad thing as long as users cannot lose that form behind the main window. If you are working with applications similar to Blender then you probably have one or more large screen monitors so screen real estate is not like what it used to be either. I am not even sure if Blender uses any forms but I am just curious why they seem to be very proud of this non-overlapping and non-blocking UI design.

IMHO, a good UI should be familiar, easily discoverable (I wanted to use the term "affordance" here but it seems like it has ten different meanings so I will refrain from using it), memorable (if you group UI items in a hierarchy this helps a lot), programmable (preferably with Python) and uncluttered. There should also be multiple ways to accomplish the same task. Menu items, pop-up menus, keyboad shortcuts should have redundant functionality. The most frequently used features should be awarded with prime screen real-estate. Displaying a whole bunch of buttons on the main window and then claiming that that UI provides one-click access to any functionality sounds kind of silly. Many engineering software designed by engineers seem to suffer from this "show everything to the user immediately" tendency. Finding the right balance seems very tricky, we shouldn't show everything but we shouldn't hide everything either.

Since users have all kinds of habits and preferences the designer should avoid any personal biases and cater to as many different interfaces as possible. If scripting can be added along with the GUI then I think this makes the perfect user interface. These are the principles I was following while designing Mekanimo's UI.

If you are a blender user please tell me what you like and dislike about it, and if you are a Mekanimo user please tell me about the parts that bug you too. Maybe later I will revisit this when I have some personal experience with blender.

What is new in Mekanimo

Several people asked me if Mekanimo is abandoned. The short answer is no it isn't. How can you abandon your baby? There was a break but now we are back to business as usual. There are several major additions in the pipeline.

• We are adding "scenes" to Mekanimo. With this capability it will be possible to create complete games with Mekanimo. "Go to scene" will be a new action in behaviors.
• GUI controls like simple buttons, text boxes, sliders etc will be available. Later we will add more sophisticated controls as well.
• Third addition is the game elements like scoreboards, live, health, ammo, displays etc.
• There will be multiple backgrounds with possible parallax effect.
• Mekanimo will be able to export full games in HTML5 format. "Export HTML5" will be an option in the File menu.
• The code will use an optional separate namespace. I think it is easier to explain this with a simple line of code.

Currently:

circle(x=20, y=30, radius=2)

would create a new circle. With the new namespace, the code will be

import mekanimo as mek

mek.circle(x=20, y=30, radius=2)

If you want to work the old way then the first line of your code would be.

from mekanimo import *

This will make sure that Python's own namespace will not be polluted. This was a big design mistake on our part but it is not too late to correct it.

We are also trying to make sure that Mekanimo's simple user interface will be protected from being spoiled by the new features. This is more difficult than it seems but we are doing our best.

So as you can see, we have a full plate. I know your next question is "When can we have it?", my answer for now is "When it is available." ; )

Peace.