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.

Started public testing the Mac version

Finally I finished the first public beta of the mac version. You can download it from http://www.mekanimo.net/downloads/. This version will expire on April 1st, 2001 (no joke). You need to keep in mind that this is the first beta release. I am planning to release another public beta version prior to the commercial release.

There are several new features and bug fixes in this release. I think the most significant new feature is the XML export option. XML export was the easy part thanks to Python's xml library (specifically xml.etree.ElementTree). The difficult part was creating an XML schema editor that could enable users to customize the XML format without pulling their hair out. I think the included XML Tag and Structure Editor (under the Settings menu) does the job well. I don't think a tutorial is needed to learn how to use it but I may be wrong. If you try it please give me some feedback. Another new feature is the C++ export with Box2D version 2.1 format. Soon I will release a new Windows version and this version will include these additions as well.

There are several issues that I know of and hoping that testers will discover some other issues that I am not aware of. Since I am not a long time mac user I don't know if it feels like a native mac application. Even if you find a tiny glitch please let me know so that I can fix it. I may end up setting up a Trac account (a bug tracker) but initially you can send me emails for the bug reports. Without your feedback it cannot get better fast enough.

I use Amazon's web services (AWS) for file storage. I created a .pkg file as an installer and tried to upload it to my repository at AWS but it was being shown as a directory so I ended up with a compressed .pkg.zip file. Now users need to unzip it first then install it. I am not sure if this will create any issues with the new users. Since most of my users are developers this should not be a big deal but I would like to reduce the installation process to a one click action. If you have any suggestions about how to improve the installer please let me know.

Simulation and fabrication of ingenious mechanisms

That is the title of the seminar I will be leading at Sprout. Sprout is a hacker space founded by three MIT graduates (Nagle, Shaunalynn, and Alec) in Somerville, Massachusetts. For more information see their website. If you live around the area you must check this place out. I found it when I was looking for a place for my son to work on some electronics projects. One of the unique aspects of this place is their eclectic approach to education and technology. You will find a place to fabricate your plans into hard matter and more importantly someone to help you or work with you in almost any field. Wonderful place wonderful people.

The seminar is going to be about simulation, mostly simulation of mechanisms but depending on the participants' backgrounds and interest areas we will be covering a lot of other topics as well. We will look at the simulation process as a vehicle to help us go from math/physics to physical objects. Mekanimo will be our main tool for computer simulation. I will cover the basics of Mekanimo at the beginning of the seminar. We will be using the book How Round is Your Circle as our guide. This is a very interesting and unique book that I enjoyed reading. It will provide us a starting point but where we may end up is going to be up to the participants.

We will be frequently visiting problem solving methodology and computing as well. Learning from failure is going to be another hot topic. Anyone who simulated a process/product and then physically built them could tell you how things almost never work as planned. To be able to identify the reason why it didn't, we need to thoroughly understand the topic at hand. I think failures are opportunities for deep level understanding.

If this sounds interesting to you then join us.

What's in the pipeline

I am currently working on the Mac release. It is a little bit more work than I anticipated. There are some minor issues like widgets not retaining focus, popup menus functioning slightly different, etc. Investigating why things behave different in different platforms is time consuming. I am using Wing IDE and it is helping me a lot debugging. If you haven't tried it yet give it a shot. Not being an experienced Mac developer doesn't help but I should be able to speed up the pace gradually. Of course watching FIBA 2010 is not helping either. I am hoping that creating an installer for Mac is not going to be a major issue but we shall see. By the end of September (more realistically in October) I should be able to start public testing. If you would like to become a beta tester please let me know.

After the Mac release I will add support for Box2D version 2.1. This should be fairly straight forward. After that I will add "Scenes" feature. Currently there is only one scene and this is shown under "Sytstem" in object tree. Scenes can be different things in different context. For example, if you are developing a game then you can use them for different levels, or different sections in the same level. When you climb down a pipe in a Mario game you go to a different place; this would be modeled with a different scene in Mekanimo. "Go to a new scene" will be an action that can be assigned to behaviors. I may be able to add some transition effects like fade-in, slide from right to left, grow from the center, etc. In Box2D terms, each scene will hold a separate world. I haven't decided if I should let two scenes run simultaneously or not. I can think of several scenarios that could use such a feature but have no idea how difficult the implementation would be. Naming conventions is another issue. Should each scene have their own name-space or should they share a common name-space? I can see advantages and disadvantages for both cases. Haven't decided yet.

I have already implemented several widgets like buttons, labels etc. I will add a user interface for adding these GUI widgets to a scene. These will help creating complete games. Speaking of games, I will also add a "Game" object with support for displaying and keeping track of common game elements like score, ammo, health, etc. Game object will hold levels as well. You will be able to manipulate the Game object via the object tree. Once you have a complete game you will be able to export this game as a windows/mac executable or HTML5/Android executable. I am hoping to be able to create some simple but complete games in a matter of hours if not minutes. Sounds awesome eh?

This will conclude the second phase of Mekanimo development. Maybe in another post I will talk about what I am planning for the third phase.