Interesting topic… I”m working in this industry myself and I don”t agree about this in 100%, but I added your page to my bookmarks and hope to see more interesting articles in the future

For example the Texture Editor and the 3D View Ports seem a likely candidate for sharing interaction models, as the user is manipulating meshes of connected points (one space is in 2D the other in 3D) but in XSI they are drastically different.

As an example, selection modes available in the 3D space (like lasso) aren’t available in the 2D space. The way pivots are set in 3D space is much different then the way pivots are set and activated in the 2D space. Tools that are shared in the 3D and 2D space behave differently; the Proportional falloff tool is available in both views but some options such as the ‘consider neighborhood’ option are ignored in the 2D view and the area of influence (both screen icon and point highlighting) aren’t implemented in the 2D view… etc.

Sadly this seems to be the norm between all Editors in XSI. It makes the application feel like many disjointed pieces.

New releases attempt to address the application consistency, like making the ‘S’ a uniform navigation tool for all views and editors. Unfortunately new ways of interaction leave a snail trail of additional inconstancy behind.

In version 5 for example, the new tear off-menus were added… but not all menus in all editors (even some of the submenus within tear-off menus are supported). The switch to MMB to set ‘key-time’ was made… but the Animation Editor still uses the RMB for setting ‘key-time’. The new ‘tweak tool’ was added… but now XSI has on screen icons widgets which XSI has stayed away from as a whole (icons and 3D viewport UI).

Users will adapt to new applications, workflows, and UI’s, as long as the interaction model is kept simple and consistent.

In XSI was puzzled for the spread of keys by the keyboard without apparent logic.

IMHO an interface should be thought about clusters (means keys that are comonly used for a similar propose should be near each other) and Hierarchies. Also keyboard layout could drive logic behind keys. I am not such advanced in XSI to say if it is possible but top keyboard horizontal line for Animating. Middle Line for Camera, Selecting and Transforms and the third line for other options.

For example i maintained A the default Frame but i made Shift+A the Frame seleted. So for Framing i just need to remember A key for framing . The fact that A is near S makes a good “cluster”

I made also one key : move, rotate, scale (last 2 by ,alt, shift) so i can keep the finger in same place for all them.

One key for selecting Polygons with alt for options like raycast, another key for points and alt etc for options and and another key for edges and alt, etc options. Also there is an hierarchy the left key is “more complex” so W is polygons then came Edges in E key and R is the points. This might seem arbitrary but in my mind as an user not as a coder the points “build” the edges and the edges “build” the polygons.

Of course there is a conflict if raycast should be a key in itself. I think for the learning curve we must respect a sort of hierarchy and raycast is at lower level than “default” Polygon select for example.

As you can see there is an apparent inconsistency i choosed diferent main keys for polygons,edges and points but not for move,rotate and scale. The reason is that i dont use options for move, rotate and scale often but i use raycast option often.

For a user that dont use XSI always or is starting less keys to think about better. Also less finger moving and what definitions we can use to help us define the logic behind.

> ../.. 3D applications are converging toward the same
> workflows and manipulations ../..

> ../.. We don’t really care if you use “S” or “ALT” to
> navigate your camera, or “W” or “V” to activate
> transforms, it ends up being the same ../..

That’’s an interresting paradox.

It’’s pretty clear actualy, better stick to what is or what will becomes “standard” ( read windows/words standard ). Sorry for professionals. 3D Democratie they said ? Right.

One could say that standardisation in this matter is an insult to the adaptability of mankind. Adaptability toward something less standard but much more efficient.

The Human Being is pretty good at adapting himself to interact with his environment, however he is pretty bad at trying to process datas.

I would rather like to hear:
“3D applications are converging toward the same datas formats, being 3d objects, animation, scene description, textures and image file fornats, scripting, shading language, ..”

But I”m affraid we will end-up with 3D sofwares having exactly the same interface and workflow, but incompatible, unable to “talk”.

This might be pretty funny.

>Softimage|3D never had context menus (other than the swiftmouse feature
>introduced in v3.7), so to force Softimage|3D mode in XSI to show a context menu on a RMB vs. holding ALT f>or native XSI functions I think is an XSI design flaw

The context menu on ALT+RMB occurs with Softimage 3D legacy modes, because as you state SI3D uses all three mouse buttons and no context menus. That’’s not how we want it to be and we are not forcing menus on RMB in SI3D mode. Quite the opposite, my point was that the context menu is on ALT when using the legacy switches, which introduces inconsistencies.

RMB is also taken in Extended Component Selection, which is a hybrid mode for SI3D users, so it’’s also for legacy. Without Si3D selection mode and Extended Component Mode, the context menu is on RMB, except Object Selection mode.

In object selection mode, the RMB is taken by Select Tree, one last remaining inconsistency, which is something we might get rid in the future when not in SI3D selection mode.

It makes sense as you say that since people stay in XSI all day, it doesn”t have to be consistent with all other apps. And we use that in some areas.

However SI3D wasn”t forward-looking and works like no other GUI applications, so if we do something like SI3D did, it needs to be because it is really, really better than the not doing that.

It needs to be more than simple muscle memory from SI3D, because Si3D users are a tiny percentage, and shrinking, of the CG out there.

I disagree here. There aren”t too many standards in the computer industry other than just about every OS uses a mouse and possible CTRL-c/v/x to work with files and text. Even in that context alone there are no standards. For the longest time MacOS was primarily a 1-button mouse interface. Windows a 2-button interface. Many UNIX systems a 3-button interface. The basics of working with menus and hotkeys are radically different because of it. So to instill XSI with all these goofy ALT+click combinations for the various interaction modes and claiming they”re based on ‘’standards” is just nonsense. With XSI you should be making a purebreed (make a decision on workflow and stick with it throughout the software), but instead are making a mutt (and confusing the heck out of users). XSI seems to want to support the Windows model whereas it’’s predecessor Softimage|3D was shaped after the UNIX model. Both have their merits, but considering XSI is a 3D system and not a 2D office spreadsheet, it makes more sense to go with the 3-button model as that’’s the expected workflow of a 3D system. It makes too much sense to use all 3-mouse buttons in a key mapping to represent XYZ axes and the like.

As for pen tablet support, just my opinion again, but I think it would be better to offer an interaction mode specifically for pen tablets that makes sense for pen users. Most pen users probably aren”t going to be animators, they”ll be modelling, texturing/rendering artists. So to compromise half the software’’s workflow for pen users at the expense of mousebutton users who use the entire software more heavily seems ridiculous to me. Design to your primary and most experienced user, then make whatever variations you need off of that. While there are a gazillion interaction devices on the market, the most frequently used can be reduced to mouse, trackball, midi, pen, scanner, and some derivative of a monkey (isn”t everything a derivative of a monkey?).

> Item like this can be seen an inconsistency, but at least some
> of these affects mostly people who have been trained in
> Softimage|3D, which is a group of people that is shrinking,
> by definition. Most users are totally new to Softimage nowdays,
> and are not migrating from Softimage|3D. This article doesn’t
> really take a position or have any clear answer on that subject,
> but it certainly raises the question of who the primary interaction
> design should target.

From experience both working in the studios for many years as well as teaching XSI professionally (and in the colleges) I can honestly say Softimage|3D legacy has nothing to do with it. New users who have never seen or heard of Softimage|3D are just as confused as Softimage|3D veterans. What causes the problem is XSI’’s lack of consistency in how to implement it’’s own workflow regardless of whether the tools are new or legacy. A decision needs to be made on the primary user and everything from that point on has to follow suit.

Personally, I think you”re primary user should be the seasoned veteran who has tons of experience in working in various types of pipelines and knows what’’s important to get day-to-day work done fast and with high quality (and most importantly - has clean workflow, not a hack). By molding to that prototype you”re instilling the expected habits and workflows onto rookies and converts. Rookies know what they like, but they don”t know what’’s correct. So to cater to them would only slow everybody else down. The rookie will change his views and opinions frequently as he learns which will only introduce more inconsistency. The convert will be helpful in opening the eyes and exposing you to how other people do things, but will often be short sighted into understanding how or why that older workflow won”t fit into the XSI scheme.

> Again I want to make sure people understand that I’m not
> writing that the software is giving up on Softimage|3D
> users, but rather that it’s best to try to use XSI without
> the legacy switches, so we can all move forward and create
> a consistent and modern application.

As a Softimage user since 1993, I”ve never had any problem with doing away with Softimage|3D workflows and ideas if they didn”t work. What I don”t want to see is for XSI to re-invent the wheel in areas that Softimage|3D was already very successful in terms of ergonomics and functionality. The rest can be tossed and replaced at will and not a tear will be shed. I”m sure if you poll a number of Softimage|3D users, they”d say the same thing. What many have taken issue with is the XSI replacements for many of the older Softimage|3D tools have been a regression from previously available functionally. That should never be the case, especially after all the reassuring and campaigning in the ‘’sumatra” days.

Softimage|3D never had context menus (other than the swiftmouse feature introduced in v3.7), so to force Softimage|3D mode in XSI to show a context menu on a RMB vs. holding ALT for native XSI functions I think is an XSI design flaw rather than a Softimage|3D legacy issue. In this particular example there is no reason why ALT+RMB couldn”t behave the same for both Softimage|3D and XSI modes as it wouldn”t confuse older users. If anything, it would”ve eased their transition to the XSI way of doing things despite their groans.

> Selection is also pretty consistently using SHIFT and Controls in
> editors and controls, but it can be different in other parts of XSI
> if softimage|3D compatibility keys are used. Not having to deal
> with legacy can make new applications like Modo look more
> elegant and gives them an advantage in interaction design.

Again, an XSI design flaw as Softimage|3D didn”t have much to speak of in terms of using ALT and CTRL. Softimage|3D only used CTRL or ALT for swiftkey mappings to menus (eg: ALT + M to open material editor). This is one area it would have made more sense to force users to the XSI method.

> With S-Z-O-P that ends up meaning that XSI has 4 different keys assigned
> to navigations which makes the UI unclear about how it should be
> used - and sometime failing to please all the users it’s trying to.
> For example, P uses the three mouse buttons in a certain way
> that is not then in other tools, so it adds an inconsistency. These
> are sometimes obvious to new users, less so when we’ve been
> using the tools for many years.

Yes, and this is where XSI becomes very inconsistent as many tools only utilize the LMB and MMB, while a bunch of others use all 3. Just my opinion, but I think it’’s best the application be optimized for the context in which it’’s used rather than trying to conform to everybody else’’s software. While it’’s certainly useful to reuse conventions such as CTRL-C to copy, or CTRL-V to paste, it doesn”t make much sense to go too far beyond that because those using an application like XSI are going to be spending heavy amounts of time there and not in many other places. Therefore, behaving like everybody else is rather irrelevant other than for the hooks which XSI connects with everybody else (eg: browsers, file manipulation, etc…).

> In the case of the Texture Editor, I *think* you’re asking for the
> support of “P”. That’s totally reasonable and you should log that
> with support; it’s a good example of legacy support, where the
> team isn’t looking as much at the very small group of people
> still using Softimage3D keys.

My comment was targetted at XSI as a whole, not the texture editor or modelling tools specifically - although I could certainly go into detail within each. My point is that from a user’’s POV, XSI behaves as a discrete palette of toolsets that don”t see outside their own box to how other toolsets are functioning. It’’s as if they”re oblivious to what other toolsets are doing at times which makes it difficult to put together a cohesive workflow.

I”m certainly not rejecting your comment, but for this particuliar problem I would say that its context menu on the right mouse click button is pretty much the industry standard and it adds a lot of frustation to most users when XSI is inconsistent by for example putting this on keyboard modifiers there is no way of discovering. Adding content menu on ALT+RMB is re-inventing the wheel, not the other way around. Another user could easily ask, why is Softimage’’s context menu not like other applications, why did they re-invent the wheel.
Three mouse button-optimize workflows like this can also block Softimage from making better use of pen tablets as serious input devices, for example.

Item like this can be seen an inconsistency, but at least some of these affects mostly people who have been trained in Softimage|3D, which is a group of people that is shrinking, by definition. Most users are totally new to Softimage nowdays, and are not migrating from Softimage|3D. This article doesn”t really take a position or have any clear answer on that subject, but it certainly raises the question of who the primary interaction design should target.

Again I want to make sure people understand that I”m not writing that the software is giving up on Softimage|3D users, but rather that it’’s best to try to use XSI without the legacy switches, so we can all move forward and create a consistent and modern application.