The usability of the spacebar menu in old vs. new interface

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

Moderators: jesterKing, stiv

Post Reply
Posts: 0
Joined: Thu Jul 17, 2008 1:59 pm

The usability of the spacebar menu in old vs. new interface

Post by LokiClock »

I stopped using Blender when the new interface came out, but I try not to make complaints about things that have changed without an argument, and all I could articulate was that it was harder to use, and not just because of bugs. What follows is mainly about the fluidity of using Blender, which is the measure of an interface's effect on someone's ability to truly produce through a program, and for long periods of time, as it's determined mostly by how well one can sequence actions in the program without thinking about the program, without Blender being a problem to solve between the goal and the action.

In the old interface, when space was typed, it would bring up a contextual menu with mouse or hotkeyed selections of tasks that could be performed on that object. In the new interface, this is instead a menu for all tasks in the program, and text input now sieves through the vast space of Blender commands.

To manage all tasks by name requires a verbal frame of the process to be maintained, and realized so physically that no impulse or motivation can be in mind without what you call it to do that being known. In other words, it requires an incredibly speech-minded person to use.

You may disagree that summoning the name of the task you have in mind is any more difficult than memorizing hotkeys or locations for things in menus. However, usability research consistently shows that users tend to be blinded to instructional texts and large menus, and generally navigate by skimming with the eyes for the minimum information required to obtain their goals, and use muscle memory for sequencing basic tasks into a complex procedure.

Instructional text and large navigational menus are usually ignored, because the user isn't really reading what is said, they're reading the location of a purpose. Large menus should always group items by the similarity of goals if they can't be avoided altogether, because the flow of action is always interrupted by memory recall. In the orthodox solution, grouping items by the similarity of goals, it's implicit that the menu is designed so that the goal group and the likelihood one's intended action belongs to it can be inferred from the analysis of one member of each group, in effectively random order.* The contextual menus gave a stronger solution by only showing applicable goal groups, and moreover eliminated most location recall that precedes when it is the current state of the interface can remind you of your intentions - this I loved about Blender. The search menu depends entirely on memory recall, specifically on accepting and internalizing the naming conventions of the program, which are only important after 3 AM when you're in the right set of menu options but you've forgotten what you were doing in the first place, a position you no longer have the luxury of finding yourself in.

Motor skills are the dominant mode of interaction with a tool the instant one requires control of spatial movements, and all things that are considered available must be accessible without recourse to any other mode of execution if the task isn't signal input in that mode. Menu item hotkeys are practically universal because, while the mouse keeps one in the motorial mode, it causes a resort to navigation, which entails the detour of location identification and recall and matching against goal groups. What users really need different names for is to distinguish all actions from one another. As far as the user is concerned, the content of the string is a magic number.** This is because the language is not verbal, it's hardly visual. Physical symbols are needed for a usable program because translation phases are a disruption of thought. The human mind only allows so many tangents and recursions when carrying out an action before they have to stop doing things intuitively to articulate and plan, even in people with an adept tolerance for complications, and in a creative task one wants to reserve all levels of recursion and complexity that can be held on the mental stack for envisioning the goal, the coordination of its construction abstractly, and translating that structure faithfully into the tools one has. There's little to no room in this moment for awareness of the interface, which will result when one has to switch between the motorial and verbal modes of interaction. Ultimately, having to type out the names of the actions slow down performing a sequence of actions far more than the multiplication of a keystroke or button into a word, even before you consider what happens when you forget something you have to know by name to do.

**As mentioned above, the actual names of things are important at 3 AM, which is when the result of "chocolate on cheese Y/N" is immediately recognizable, and looking at "snap reference to loop" leads to an idle screen. They are also important for first exploring the program, and figuring out what the goaloids are. There's nothing more upsetting than the program not telling you how to perform the basic manipulation, and a web of features without an improvizational center invites proficiency in the program's bureaucracy more than in performing the function the program was designed as a tool for.

Clearly, this is what the search bar was designed to address, and in that respect it's a revelation. But it's overlaid on an existing structure, and in trying to subsume it has destroyed the most usable aspect of the interface. Personally, I think it should be Alt+Space. And why not space? Well, space is used for the contextual menus because they're what you have to bring up reflexively and frequently, but rather than scaling or rotating, the command applies in a universal context, and as the space key is a universal key on the keyboard, it rightfully belongs to the most consistently available piece of the keyboard interface. The command search, for the reasons outlined above, is not reflexive, and from the usability perspective, only reflexive interactions are legitimate means of perpetually interfacing with the program.


*After using Flash for 9 years, I can finally tell you the names of any menu option to perform any task and perhaps its location in its menu, but if I imagine the interface I see the menu groups, not the items, and can tell you what type of things you can do from that goaloid, and it's by those goaloids that I actually sequence actions in that program.

The interface seems to try to eliminate what was left of the location recall after the contextual menus by regrouping menus so they're friendlier to sequencing actions across multiple editor groups, reducing those where possible to property lists.

Off the subject, it's a terrible idea to allow menus to uncollapse without being able to collapse them by doing the same thing twice. It means the user can figure out how to make their workspace messy but it takes an entirely new thought process to figure out how to clean it up, which punishes playing with the program. The infinite split window spawning in the first release with the new interface did this also. The same goes for the search bar not closing with space, which is another good reason to trigger it with Alt+Space instead.

Post Reply